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
