I'm not sure whether there is a tight correlation between
minimum signal duration
and
mimimum detection time
in case of DTMF.
My understanding of some of these DTMF detection algorithms is, that an
unambiguous detection may be already based on a window of approx. 100 to
150 PCM sample. This would relate to detection times between roughly 12 to
19 ms (i.e., smaller than 40 ms).
Albrecht
"Jackson, James"
<[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>
Sent by: cc:
[email protected]
[EMAIL PROTECTED] Subject: Re: [Sip-implementors]
RFC2833 Implementations - Inband Leakage vs.
olumbia.edu Latency ?
04.05.2007 21:36
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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
