| Summary: | ASTERISK-18147: SIP Phone (Cisco)-> Asterisk 1.4.31 -> IAX-> Asterisk 1.6.2.19 > SIP provider -> PSTN IVR DTMF - DTMF broken after upgrade 1.4 to 1.6 or 1.8 | ||||||
| Reporter: | Alexey Ostrovsky (aostrovsky) | Labels: | |||||
| Date Opened: | 2011-07-18 07:47:26 | Date Closed: | |||||
| Priority: | Major | Regression? | Yes | ||||
| Status: | Open/New | Components: | Channels/chan_iax2 | ||||
| Versions: | 1.6.2.19 1.8.4 13.18.4 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | Linux Cent OS 5, 2.6.18-164.el5 | Attachments: | ( 0) capture-broadvox-aster1.8-IAX-ast1.8-Aug-18-2011.dump ( 1) capture-broadvox-aster1.8-sip-ast1.8-Aug-18-2011.dump ( 2) capture-broadvox-first1.4-second1.6-Aug-18-2011.dump ( 3) DTMF-issue.jpg ( 4) IAX_between_ast.png ( 5) SIP_between_ast.png | ||||
| Description: | Hello, We have two asterisks 1.4 and 1.6 and IAX between them The second asterisk is connected to VoIP provider thru SIP. When I calling to conference service on some company and dialling DTMF there in some IVR menu al works fine. But recently we decided to upgrade that 1.4 to 1.6.2.19 or 1.8.4 And we got issues with DTMFs after that. Now remote IVR is not able to detect DTMF correctly. Sometime detects wrong digits but mostly it just ignore some. In 5% of times when I am pushing buttons for about 1 sec and keep gap between them about 1 sec I can get success with remote IVR. But with 1.4.31 I can push DTMFs really fast all works perfectly. With 1.8.4 I even noticed that even our second asterisk on other end of IAX start having issues with detecting digits. All sip configs have rfc2833 dtmf mode enabled. I am not changing any configs after upgraded or downgrade. And it always do not work with 1.6 and working with 1.4.31 Other strange thing that in any cases I still can see correct DTMF digits events if enabling debug on outgoing SIP channel to our SIP provider. Also one thing. When I am replacing IAX with SIP between asterisks then DTMS start detecting correctly with upgraded asterisk. So clearly something broken since 1.4.31 related to DTMF. | ||||||
| Comments: | By: Leif Madsen (lmadsen) 2011-08-08 12:46:07.696-0500 You'll need to provide some debug information and configuration in order to permit this issue to be replicated. What is the exactly topology and end-points in use? It's not entirely clear what the physical topology is. Please provide pcap traces and Asterisk console output with debug level logging, including the SIP traces from a working and non-working configuration so we can determine what is different. Thanks! By: Leif Madsen (lmadsen) 2011-08-09 09:03:38.012-0500 Assigned to reporter after requesting data. By: Alexey Ostrovsky (aostrovsky) 2011-08-18 03:29:16.730-0500 Attached topology of connections and test cases. By: Alexey Ostrovsky (aostrovsky) 2011-08-18 03:44:39.238-0500 Attached dump for each of 3 test cases. By: Alexey Ostrovsky (aostrovsky) 2011-08-18 03:47:01.631-0500 I've posted more info and pcaps Best case scenario when DTMF always detected correctly that is when IAX not used between asterisks. By: Alexey Ostrovsky (aostrovsky) 2011-08-18 03:53:44.473-0500 Our SIP provider commented that issue on our site and happening because in IAX case e are bursting media packets. And they are really right as in case when we replace IAX by SIP between asterisks I do not see bursting of packets. Here is what they say: ------start-------------- Unfortunately we are unable to move forward with this ticket. The DTMF failures you are experiencing are occurring over multiple routes and underlying equipment, while at the same time are not able to be duplicated by either ourselves or our ULC support staff. Looking over the media captures that were taken of your traffic we see the audio packets consistently sent in an bursts with long delays in-between the bursts. In the abstract I agree that most jitter buffers should be able to clean this up and it should not contribute to DTMF failures (especially when RTP-Events are being used). However this is not normal jitter as the packets are clearly queued up and then bursted out in what appears to be a deliberate regular pattern. Since with a negotiated p-time of 20 this is clearly incorrect none of the affected carriers or vendors will pursue the issue while this behavior is present. My questions to you: 1. What is causing this bursting of the audio packets? It’s clearly not simple jitter. 2. When sending DTMF from a device that does not burst the audio packets in this incorrect manner, does the DTMF continue to fail? If the packetization issue is not present and the DTMF continues to fail we can obtain new captures and continue to pursue this with our vendors. Please let us know if we can assist in testing with a clean media stream. ------end----------------------- By: Alexey Ostrovsky (aostrovsky) 2011-08-18 04:34:40.921-0500 You can see on attached wireshark screens of outgoing media that traffic really burst with no reasons when IAX used. By: Alexey Ostrovsky (aostrovsky) 2011-08-18 04:46:17.621-0500 So clearly most interesting case here if using IAX between asterisk we have an issue. And if SIP all the way then not. For any asterisk versions. Please note that during debug I always can see correct DTMF in pcap dumps and in console. So issue is not that DTMF are not send. They always present on outgoing SIP to provider and correct. But in IAX case between asterisks media traffic become different along with DTMF. And remote side is not able to detect it correctly. The only differences that I and SIP provider noticed that is burst media traffic with IAX in use between asterisk. Thank you By: Alexey Ostrovsky (aostrovsky) 2011-08-30 10:24:44.814-0500 Anything else that I can provide? By: Leif Madsen (lmadsen) 2011-09-14 09:12:01.232-0500 Marking possibly related issue | ||||||
