| Summary: | ASTERISK-19821: DTMF conversion SIP INFO to RFC2833 changes duration | ||||
| Reporter: | i2045 (i2045) | Labels: | |||
| Date Opened: | 2012-05-01 06:17:31 | Date Closed: | |||
| Priority: | Major | Regression? | |||
| Status: | Open/New | Components: | Channels/chan_sip/Interoperability | ||
| Versions: | 1.8.12.0 10.4.0 13.18.4 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) sip_info_to_rfc2833_10.4.0.pcap ( 1) sip_info_to_rfc2833.pcap | |||
| Description: | The setup: 192.168.178.2 Endpoint: Zoiper softphone 192.168.178.23 Endpoint: Asterisk 192.168.178.22 Asterisk 1.8.12.0-rc2 + make samples + these changes: extensions.conf [default] exten => 666,1,dial(SIP/${EXTEN}@192.168.178.23) sip.conf [general] canreinvite=no The test: - .2 (softphone) calls 666 to .22 (Asterisk 1.8.12.0-rc2). - .22 (Asterisk 1.8.12.0-rc2) calls 666 to .23 (other Asterisk machine). - .2 (softphone) sends SIP INFO DTMF with duration of 250. - .22 (Asterisk 1.8.12.0-rc2) sends RFC2833 DTMF with a duration of 2560 or 2720 (!). The problem: The converted DTMF has a duration over 10 times as high as the original. | ||||
| Comments: | By: i2045 (i2045) 2012-05-01 06:19:10.616-0500 Added a pcap of the described test call. By: Matt Jordan (mjordan) 2012-05-01 08:14:25.994-0500 Is this having a negative impact on any aspect of the operation of the UAs involved in the transaction? By: i2045 (i2045) 2012-05-01 14:45:41.317-0500 Yes, some UA's can't/won't process such long duration DTMF tones. Probably their fault but i can't change that and my users experience bad DTMF performance. More importantly applications (for example opening a garage door) do not work correctly. I would really like the converted DTMF duration to be comparable to the original DTMF duration. By: Matt Jordan (mjordan) 2012-05-01 15:36:51.832-0500 There is some stickyness here. Asterisk has always sent out three DTMF BEGIN packets with an increasing duration, which is not really the intent of RFC 2833. However, since its pretty much always done that, we've been reticent to change it. What that means is that the duration of a DTMF signal that goes out from Asterisk may not match what comes in. That being said, the duration should be able to be made closer to what is passed in the SIP INFO message. What tolerance do the SIP clients you're operating with have? What duration ranges are they capable of handling? By: i2045 (i2045) 2012-05-01 16:13:31.669-0500 I have had no errors reported when sending a duration of 960 and lower. In this example, if a duration of 250 could be converted to 3*160=480 that would work fine. By: Mark Petersen (roadkill) 2012-05-03 10:18:24.601-0500 is probably related to ASTERISK-19772 as we in that branch is trying to fix asterisk DTMF duration problem By: i2045 (i2045) 2012-05-03 18:17:10.463-0500 If the minimum duration of a DTMF tone would be set to 3*160=480 by default then the current behaviour of Asterisk stays intact. Users can change that minimum limit to whatever they find suitable. This would however not fix the error when converting from INFO to outband. The conversion should set the outband duration to the closest multiple of 160 calculated from the INFO duration with a minimum of 'option_dtmfminduration'. By: i2045 (i2045) 2012-05-10 07:58:48.520-0500 If i apply a few modifications to res/res_rtp_asterisk.c the problem seems to be solved: /* if (duration > 0 && (measured_samples = duration * rtp_get_rate(rtp->f.subclass.codec) / 1000) > rtp->send_duration) { ast_debug(2, "Adjusting final end duration from %u to %u\n", rtp->send_duration, measured_samples); rtp->send_duration = measured_samples; } */ rtp->send_duration = 20; //160; rtp->send_duration += 20; //160; rtp->send_duration += 20; //160; Please comment if this is an acceptable solution. By: i2045 (i2045) 2012-05-11 08:20:10.607-0500 An addition to this bug; the timestamp and sequence numbers of the generated rtpevents are not correct. I apply the filter (ip.src == 192.168.178.22 && ip.dst == 192.168.178.23) && (rtp || rtpevent) to the attached pcap file. Up to packet #552 the timestamp and sequence number increments each packet. The values are 433696700 (timestamp) and 26281 (sequence number). Packet #555 is the first rtpevent. It's timestamp is 160 (not higher than 433696700 as i would expect) and sequence number is 20906 (not 26282 as i would expect). The following rtpevents all have a timestamp of 160, the sequence number increments. By: i2045 (i2045) 2012-05-29 06:39:44.645-0500 I also tested with 10.4.0. Problem is the same: - RTP timestamp of the RTP events are all 160. The timestamps of the RTP events should increment with the RTP audio packets they are injected in between. - The sequence numbers of the RTP events do increment but the values have no relation to the sequence numbers of the RTP audio packets. - The DTMF duration is 2560 instead of something near 250. Due to these 3 bugs (the first 2 for sure) the DTMF we send is not accepted by a telco we want to route traffic to. Is a workaround or an easy fix possible for these bugs? Thanks! By: i2045 (i2045) 2012-06-11 08:47:19.114-0500 Can someone tell if this bug report is correct? What happens next? Thanks! By: Olle Johansson (oej) 2012-07-05 09:11:09.785-0500 I can confirm that this is a bug. THe issue is that we emulate the DTMF and the emulation doesn't bother with real milliseconds somehow. So the emulation turns out to be a random length more or less. By: Olle Johansson (oej) 2012-07-05 10:36:10.451-0500 Don't mix 160 samples with milliseconds. It's 20 milliseconds per packet, 160 samples. By: Olle Johansson (oej) 2012-07-05 10:37:41.099-0500 The timestamp of 160 is definitely wrong though. I see that in your pcap. Need to test this with our branch - rana-dtmf-duration. | ||||