If the "calling party" is trying to invoke some feature via DTMF, it would probably be undesirable for the "called party" to hear the tones. I imagine this would apply for any out-of-band DTMF mechanism on a gateway ex. KPML. Similarly, let's suppose the "called party" is a VoIP application that is recording the audio from the "calling party" ex. a voicemail platform. If "calling party" presses some DTMF key to submit the message it would be undesirable for the message to have DTMF tones appended to it because of leakage.
I believe that 40ms is the minimum duration for a DTMF tone to be considered valid (in general). That would suggest that the DSP needs to wait at least 40ms before declaring it a valid event, so in the absence of some buffering there is 40+ ms of leakage. Thoughts ? James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, May 04, 2007 10:55 AM To: Jackson, James Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] RFC2833 Implementations - Inband Leakage vs. Latency ? OK, this is the PSTN-to-IP side, I was answering from receiving side (IP-to-PSTN). The unambiguous detection of the DTMF digit by the "called party" is the more important requirement in comparison to an attempt in minimizing the end-to-end transfer delay for DTMF signaling IMHO. Thus, there isn't any principal issue to delay packet transmission on the transmitter side in order to minimze leakage on the receiver side. (Assumption: the additional buffering is just for the period of DTMF signalling.) A bound for a maximum delay is given by the maximum signal duration of DTMF digits (which is 40 ms in my understanding). The minimum delay is given by the performance of the DTMF detection logic. Any signal detector is principally facing the issue of the two controversial requirements of "detection as fast as possible" versus "maximum probability of a correct detection". Any implementation must find a tradeoff here (between "time accuracy" and "frequency accuracy"). Conservative detection logic is just waiting "a little longer". Thus it comes down to the specific algorithm and efficient implementation of the DTMF detector. There's a famous algorithm used for DTMF detection, the Goertzel and modified Goertzel algorithms as far as I know. I'm not an expert on digital signal processing, but arround ten years ago, such DTMF detectors did consider a window of arround 10 to 15 ms. The experts may comment the minimum amount of samples required. Perhaps a much faster detection is in the meanwhile possible. Albrecht "Jackson, James" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <[email protected]> Sent by: cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] RFC2833 Implementations - Inband Leakage vs. olumbia.edu Latency ? 03.05.2007 05:24 Perhaps I have not stated the problem well. When a Media Gateway receives a call from the PSTN and it is using RFC2833/4733 for DTMF, it typically suppresses the sending of the DTMF tone as encoded audio and sends only the RTP event. It takes some time for the Media Gateway to actually detect the DTMF tone before it can suppress the encoded audio. During that time, some of the DTMF tone can leak into the encoded audio. The leakage can be reduced by additional buffering but this in turn adds latency. I'm trying to determine if there is a generally acceptable range for this leakage. I have seen values ranging from 5ms which is not too significant, up to 50ms, which is quite significant and which creates problems for some VoIP applications. Thanks, James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, May 02, 2007 9:16 PM To: [email protected] Subject: Re: [Sip-implementors] RFC2833 Implementations - Inband Leakage vs. Latency ? From: [EMAIL PROTECTED] In case of DTMF digits, a single RFC 4733 packet carries a single DTMF digit in my understanding. Triple redundancy is the basic means to target RTP packet losses, i.e. the receiver must receive at least one out of three. Be careful -- An RFC 4733 packet carries state information about a DTMF sound, either that the sound is on (and if so, how long it has been on) or that the sound has stopped. E.g., it is up to the recipient to decode this information into DTMF digits, and in some cases, to distinguish how long the digit was. Multiple packets are used to defeat packet loss, but also to allow transmitting the initiation of the digit before the finish of the digit has been seen, and to allow the transmission of the real length of the digit. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
