Dtmf duration on 2833

hi, i am having a dtmf issue and am looking for some background on dtmf and 2833. My users are complaining about missed digits on conference calls (webex etc). my phones are using 2833 and i am using 2833 on my sip trunk but in working with the provider, they did packet captures and found that all my digits are coming through with a tone duration of 1600ms. This is a problem for them as often, the second digit comes through before the 1600ms is up.

My question is this; when using 2833 all the way through (handset to pbx to sip trunk), does the pbx change the duration or is the pbx passing through the duration from the originating device (handset).

If the pbx is setting the duration, is this configurable? where, I cannot find this in the gui?

I would appreciate any help!

2833 does not have a ^duration", the individual digits are sent as dialed in SDP packets, you will see them in the sip conversation . You can add DTMF to your logs and you should see both the SDP packet followed by the DTMF logging as asterisk decodes the SDP stream. 1600 is just wrong, my guess is they told you 160ms and you are actually using inband signalling, but even that is twice as long as the normal 80ms. I would confirm that you are definately using 2833 on your equipment and try to discover whrere it is being transcoded.

At least with matching codecs (no transcoding), Asterisk just forwards the RTP stream without modification.

Run tcpdump on your PBX, make a failing call, move the capture file to your PC and open it in Wireshark. Check the tone durations received from the phone and those sent to the trunk.

As @dicko said, the duration is not explicitly encoded. There are RTP packets to start the tone, followed later in the stream by packets marking the end.

Dicko, thanks for replying. I have seen the packet captures (below). the event timer is 1600ms. also, i have double checked, my phones and pbx are using 2833. the provider is converting 2833 to tones and this is where the 1600ms becomes an issue. I guess what I am trying to understand is, where is 1600ms coming from? is it coming from the phone or the pbx?

That would normally be caused by someone mashing a key for a second and a half , the rfc (no longer technically 2833) specifies a minimum duration of 40ms with a minimum interdigit delay of 40ms, asterisk generates all its packets at 80ms , looking closer at your wireshark dump from the beginning of the event and listening to the audio stream at the same time might help here.

(It is human nature to mash that key if the system says it doesnt understand you but that is analagous to shouting at a foreigner who doesnt speak english)

Sorry, I was confused. There is a duration field, but it’s in ‘timestamp units’, i.e. samples; see section 3.5 of https://www.ietf.org/rfc/rfc2833.txt . For G.711, there are 8000 samples per second.

Here is a capture from a Yealink T26P:

You can see that the actual elapsed time from the first event to the first ‘end’ is 120 ms, reasonably close to the 1120 samples = 140 ms in the duration field.

Assuming that what your Asterisk sent on the trunk is similar, I don’t see why your DTMF should be garbled. Have you tried another trunking provider? Or, tried sending the tones from Asterisk, rather than the phone?

so, you are saying an event duration of 1600 is not 1600 ms, but 1600 samples…so .2s or 200ms?

Yes. Look at your capture to confirm that the time from the first packet for the event to the first ‘end’ packet is about 200 ms.

Stewart1, thanks, this is very helpful, i will go back to the provider.

btw, i am not sure i heard an answer to this…does asterisk change the duration or does it pass that through from the phone?

I only know that when not transcoding, it passes through what it gets from the phone. If your system requires Asterisk to transcode, it may do something different. In any case, you can capture what goes out to the trunk to be sure.

Just for laughs, I made test calls to 18664329903 and 14085256800 (numbers found at https://collaborationhelp.cisco.com/article/en-us/WBX25713 ). Digits entered rapidly were played back correctly. Are either of these destinations causing you trouble?

the problem seems to be inconsistent. but i have experienced it myself occasionally.

btw, i stumbled upon this and found it helpful https://thetestcall.blogspot.com/ this site has 2 dtmf test (2 and 8) 2 batches up the dtmf’s and reads them back to you (this always works for me). The other test is realtime dtmf, this often skips digits, not sure what that means.

I observed the same issue. I believe that’s an artifact of the dialplan that thetestcall uses to implement it (it simply isn’t listening during playback) and is unrelated to your primary trouble.

Do you observe a problem with either of the numbers in my previous post (both read back what you enter)? If not, can you post (or PM me) the failing number so I can see if I’m similarly affected?

I just wanted to thank you for taking the time. Armed with the info you provided, I went back to centurylink and much to my surprise, they admitted they had made a mistake. They re-read the RFC and we are investigating further.

thanks again.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.