| Summary: | ASTERISK-15931: SIP DTMF problem using RFC2833 between 1.2 <-> 1.4 <-> Unknown-brand/model SBC | ||||
| Reporter: | Dayton Turner (dayton) | Labels: | |||
| Date Opened: | 2010-04-08 17:18:06 | Date Closed: | 2011-07-26 15:22:35 | ||
| Priority: | Minor | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) ast12-to-ast14-iaxtest.pcap ( 1) ast12-to-ast14-sip.pcap ( 2) ast14-to-sip-telco-sbc.pcap ( 3) ast14-to-sip-telco-sbc-iaxtest.pcap ( 4) sip-to-ast12.pcap ( 5) sip-to-ast12-iaxtest.pcap | |||
| Description: | Basic rundown: Call from SIP Phone (RFC2833) -> Asterisk 1.2 via SIP and RFC2833 = Digits are read correctly. Packet trace reveals single digit being transmitted with event duration 0 on the digit. This is as expected. Call from SIP Phone (RFC2833) -> Asterisk 1.2 via SIP and RFC2833 -> Asterisk 1.4.30 via SIP and RFC2833 = Digits are read correctly, with rfc2833compensate set on the sip peer between 1.2 and 1.4. Single Digits being transmitted with event duration 0 on each digit. As expected I believe. Call from SIP Phone (RFC2933) -> Asterisk 1.2 via SIP and RFC2833 -> Asterisk 1.4.30 via SIP and RFC2833 -> Unknown Make/model SBC at my ITSP, not asterisk) with rfc2833compensate set on the peer between asterisk 1.2 and 1.4.30, as well as on the peer to my ITSP, the packets get passed along as usual, single digits instead of the 6 that asterisk 1.4+ does now, with event duration 0 = ITSP does not acknowledge valid DTMF. Presumably due to the fact that their SBC does not understand event duration = 0. Workaround: Use IAX between asterisk 1.2 and 1.4 boxes, to force the 1.4 box to craft its own RFC2833 packets to the ITSP in the correct format. Is there a way to force Asterisk 1.4 in this chain to not simply "forward" on the broken RFC2833 DTMF from asterisk 1.2, and instead accept the "non compliant" DTMF, and re-create the packets that are leaving towards the ITSP? I dont know if this should qualify as a bug or a feature request, considering I dont believe it should be standard procedure to forward along non-rfc compliant RFC2833. FYI canreinvite=no is set on all peers as well. I have packet captures to back this all up, and configs if necessary. I havent included them yet because i believe this behavior is possibly intended, or at least expected, unless I am missing an option that does what I am looking for and i simply havent found it. | ||||
| Comments: | By: Paul Belanger (pabelanger) 2010-04-09 11:16:45 We are going to need some debug logs and SIP traces for this issue. Specificity from your Asterisk 1.4 box. Then attach them to the issue tracker. By: Leif Madsen (lmadsen) 2010-04-12 10:04:12 Not sure if this is a feature request either. I think some debug logs showing what is going on would help here. Thanks! By: Dayton Turner (dayton) 2010-04-12 12:41:35 I will be sure to post the captures later on today. Like i said, im not sure if this is how its "supposed to work" and therefore becomes a feature request, but.. We'll figure that out :) By: Leif Madsen (lmadsen) 2010-04-19 15:08:34 Is it later today? :) By: Dayton Turner (dayton) 2010-04-19 15:21:37 Sorry! I'll get it out to you asap!!! :) By: Dayton Turner (dayton) 2010-04-21 06:21:26 I've attached 6 pcaps, based on two calls. First Call: -- SIP Phone (RFC2833) -> Asterisk 1.2 (sip-to-ast12.pcap) Asterisk 1.2 -> Asterisk 1.4 via SIP/RFC2833 (ast12-to-ast14-sip.pcap) Asterisk 1.4 -> Unknown SBC @ SIP Telco (ast14-to-sip-telco-sbc.pcap) The call is answered, I wait to hear the IVR. I press "1" three times with about a 2 second delay between them, incase its intermittent. The IVR doesnt recognize the DTMF. Second Call: (I use IAX between asterisk 1.2 and 1.4 boxes) -- SIP Phone (RFC2833) -> Asterisk 1.2 (sip-to-ast12-iaxtest.pcap) Asterisk 1.2 -> Asterisk 1.4 via IAX2/RFC2833 (ast12-to-ast14-iaxtest.pcap) Asterisk 1.4 -> Unknown SBC @ SIP Telco (ast14-to-sip-telco-sbc-iaxtest.pcap) I dial the same number, call is answered, I wait for hte IVR and press "1" and it immediately recognizes my button press. Notice the difference in the DTMF packet sent between call one and call two in the "ast14-to-sip-telco-sbc" pcap files. My suggestion is to add an option to have DTMF packets rewritten the way its being done when I'm not using SIP the whole way through, as a way to 'cleanse' the DTMF packets SIP sends out when talking to an aging DTMF implementation (asterisk 1.2). Unless of course, im simply doing something wrong. By: Leif Madsen (lmadsen) 2010-04-21 13:14:49 Have you tried rfc2833compensate=yes in sip.conf? By: Dayton Turner (dayton) 2010-04-21 13:19:50 rfc2833compensate=yes Is active on both sides of Asterisk 1.2 / 1.4 and is also active on the sip peer from asterisk 1.4 to the telco SBC. Doesnt seem to make a difference. By: Leif Madsen (lmadsen) 2010-04-21 13:24:24 OK. Then I believe the next step is for someone to analyze the pcap traces to see what is different. Perhaps an option needs to be added here. By: frawd (frawd) 2010-04-21 13:39:41 The bug is in the RFC2833 implementation of Asterisk 1.2, so it either should be fixed there, or you will need to use inband or info between 1.2 and 1.4. By: Dayton Turner (dayton) 2010-04-21 13:41:29 I can appreciate that rfc2833 is broken in 1.2, but is that not the point of the rfc2833compensate option in asterisk 1.4? By: Leif Madsen (lmadsen) 2010-04-21 14:56:34 I think the purpose is to make it so Asterisk 1.4 can speak with Asterisk 1.2, but not to fix the DTMF going out on the other side (I believe). By: Dayton Turner (dayton) 2010-04-21 15:08:26 Oh I see. I suppose thats also a factor. Presumably there's already code (the code that is used when i call in over IAX!) that can re-create SIP/DTMF information that would fix this. Couldn't we just add an option like reconstructrfc2833=yes to the far end SIP SBC to instruct asterisk 1.4 that regardless of what it got on previous legs of the call, it should discard received dtmf values and substitute its own? Ultimately we need to get away from Asterisk 1.2, sure, but time is of course a factor, on large production boxes. I suppose the SIP INFO/Inband workaround is an option, but both have their own challenges to deal with, arguably. I am using G729 through all legs so inband is already out. By: frawd (frawd) 2010-04-22 05:47:42 I think Asterisk 1.4 only rebuilds DTMF if necessary, and will passthrough the DTMF whenever it can. It would probably cost you less to configure SIP INFO (if not broken in 1.2) than to try changing this behavior or convincing somone to implement a reconstruct feature in 1.4. Still, being able to configure a passive dtmf mode (only detect and do not touch to force passthrough) and an active dtmf mode (force reconstruction whatever happens) would be a cool feature to have in 1.8! By: Leif Madsen (lmadsen) 2011-07-26 15:22:30.323-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks! | ||||