Summary:ASTERISK-17329: [branch] DTMF on outbound call leg does not match inbound DTMF duration
Reporter:Olle Johansson (oej)Labels:
Date Opened:2011-02-01 05:41:55.000-0600Date Closed:
Versions:Frequency of
is duplicated byASTERISK-16774 Dial with use of feature options corrupts rfc2388 DTMF durations
Environment:Attachments:( 0) dtmf.patch
( 1) dtmf-capture-1.pcap
Description:If two SIP phones is bridged over Asterisk, Asterisk will always have the wrong length to the DTMF audio. The primary causes are:

- DTMF duration is added with 160 ms for each BEGIN packet. The DTMF Begin is transmitted three times and should have the same duration
- One extra DTMF continue packet is generated directly after the BEGIN packets and adds another 160 ms
- The END packet shows the actual inbound duration + 160 since the CONT code adds 160 after sending
- For longer DTMF, we actually cut DTMF short since we cut DTMF off as soon as we received the DTMF END on the inbound channel.

The attached patch solves these issues.

This seems to affect all released versions of Asterisk

Branch: http://svn.digium.com/svn/asterisk/team/oej/rana-dtmf-rtp-duration-1.6.0
Comments:By: Olle Johansson (oej) 2011-02-01 05:43:14.000-0600

I have only tested this code with SIP-2-SIP calls. I don't know how the changes affects DAHDI-SIP or other channels in combination with SIP. I believe the same issues apply regardless.

By: Olle Johansson (oej) 2011-02-01 06:30:08.000-0600

THis is still not perfect, as Asterisk sends out continue packets without any relation to incoming continue packets. We should really handle incoming continue over the bridge in frames and only send out when we get incoming for sip-2-sip calls.

By: Olle Johansson (oej) 2011-02-01 07:27:19.000-0600

Ok, got a case where the inbound was paced at 400 ms, which made asterisk make the DTMF shorter... This code just doesn't work properly. We should honor the inbound time stamps.

By: Olle Johansson (oej) 2011-02-01 07:55:18.000-0600

RFC 2833 says: "An audio source SHOULD start transmitting event packets as soon as it
  recognizes an event and every 50 ms thereafter or the packet interval
  for the audio codec used for this session, if known."

This gateway sends 50 ms...

And yes, I have confused "timestamp units" and "ms" above.

By: Olle Johansson (oej) 2011-02-01 08:02:06.000-0600

Ok, we just have to send all these frames over the bridge. Yahoo.

By: Olle Johansson (oej) 2011-02-02 04:41:00.000-0600

Opened a new branch to continue this work, that grew bigger than expected:


Please test!

By: Claudio Villalobos (devmod) 2011-02-05 14:08:11.000-0600

I have the same issue on svn/asterisk/branches/1.6.2

I have one endpoint that starts at 160 and ends at 960, Asterisk console shows like it has been recognized but nothing is going out the wire to the other end....

[Feb  5 20:54:37] DTMF[25354]: channel.c:3051 __ast_read: DTMF begin '1' received on SIP/acme.com:5060-000001ac
[Feb  5 20:54:37] DTMF[25354]: channel.c:3061 __ast_read: DTMF begin passthrough '1' on SIP/acme.com:5060-000001ac
[Feb  5 20:54:38] DTMF[25354]: channel.c:2966 __ast_read: DTMF end '1' received on SIP/acme.com:5060-000001ac, duration 120 ms
[Feb  5 20:54:38] DTMF[25354]: channel.c:3006 __ast_read: DTMF end accepted with begin '1' on SIP/acme.com:5060-000001ac
[Feb  5 20:54:38] DTMF[25354]: channel.c:3035 __ast_read: DTMF end passthrough '1' on SIP/acme.com:5060-000001ac

I also tested with this other endpoint which starts at 0 and ends at 1296, asterisk recognizes it correctly and sends to to the other side as (160-1760 (1760 x3 marked as end))

By: Claudio Villalobos (devmod) 2011-02-10 16:22:16.000-0600

I tested the branch (oej) with the same endpoints and I think it is still not working properly. Please refer to the capture attached. DEVICE A Asterisk DEVICE B

By: David Brillert (aragon) 2011-02-14 08:42:09.000-0600

DTMF on 1.4 is a mess.  I tested oej's patch on today's subversion to see if it would have any effect on a bug report of mine ASTERISK-17364
Unfortunately it had no effect on my bug report.

By: Olle Johansson (oej) 2011-02-14 08:47:52.000-0600

I don't think PRI has DTMF duration at all. See asterisk-dev list.

By: Matt Jordan (mjordan) 2012-02-22 14:13:43.209-0600


Just curious, but what adverse behavior in other systems does this cause?  If SIP phone A sends a DTMF event with a total duration of 1280, and Asterisk reproduces this DTMF event and sends it to SIP phone B with a duration of 1440, does that cause a problem in SIP phone B?  Does it cause a problem in some other system?

I'm basing these questions off of Asterisk 1.8, which - although the RTP handling has changed significantly and is now in res_rtp_asterisk - still sends the begin event three times as three distinct events with different sequence numbers and durations.

By: Olle Johansson (oej) 2012-04-27 03:41:20.681-0500

Matt: If you use three asterisk platforms in the same call, this turns really bad. A short DTMF turns into something very noisy. And DTMFs collapse on each other, since we're missing DTMF begins. This is critical for systems that communicate in DTMF, like alarms and home automation systems.

By: Olle Johansson (oej) 2012-04-27 03:41:45.534-0500

BTW, I'm working on upgrading this patch to 1.8.

By: i2045 (i2045) 2012-05-20 16:25:08.721-0500

Could this be related to ASTERISK-19821?

By: Olle Johansson (oej) 2013-09-05 04:58:11.509-0500

My code has been running in production for a long time on many servers. This is really something that should have been part of 12.

By: Olle Johansson (oej) 2014-11-10 04:04:20.412-0600

The branch for 1.6 and 1.8 has been running in production for a long time and fixes a lot of issues with DTMF duration.