| 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-0600 | Date Closed: | |||
| Priority: | Minor | Regression? | No | ||
| Status: | Open/New | Components: | Core/RTP | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| 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: http://svn.digium.com/svn/asterisk/team/oej/rana-dtmf-rtp-duration-1.6.0 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. 192.168.100.119 DEVICE A 192.168.100.27 Asterisk 192.168.100.19 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 Olle: 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. | ||||