Hello world
Thanks for the help in advance, I’m kinda a asterisk noob but I think I’ve exhausted my resources and need some help on this one.
I’ve been working on an issue of duplicated DTMF tones from my carrier when the call is initiated from an outside number. It duplicates from 2 to 6 times. This however will not happen if I initiated the call from a phone connected to our PBX. I have all DTMF set to RFC2833. The only thing I can tell is that a get a few less RTP EVENT packets from my carrier if the call is initiated externally and this causes my SBC to try and compensate. I tried changing mindtmfduration in asterisk.conf to 40ms (mindtmfduration = 40) but that didn’t seem to help. I’ve also changed the tones that asterisk looks for so that it would not detect inband DTMF, astrecipes.net/index.php?n=248, in case that was the cause. Still no luck. I’ve tried having the carrier switch from RFC2833 to SIP INFO. Again no luck. I upgraded a test SBC to Asterisk 11.12.0 and got the same results. The carrier seems convinced that it is due to inband DTMF tones being picked up but I disagree. The thing that is throwing me off is that it is fine if I dial out but if an external dials in everything is duplicated and the number of duplicates vary. We have a second carrier that we use for Canadian inbound calls and those work flawlessly and have never had an issue. So I’m leaning towards the problem being with our main carrier.
Our infrastructure looks like this:
Outbound from my desk:
Digium D40 > Switchvox 5.8.5 (10.0.0.27) > sbc.klim.com Asterisk 11.7.0 (10.0.0.35) > 192.168.198.250 Asterisk 1.4.21.2 > PSTN > Verizon Cell 208-403-****
Inbound is the same but reversed.
I’m pretty sure I found the issue… just not sure why it is an issue or what to do about it. Every DTMF that is correctly processed is sent as an RTP EVENT packet with a payload type of “telephone-event (101)” without quotes works. All DTMF when I initiate the call internally are this type but when the call is initiated externally the DTMF I receive from my ITSP come in as RTP EVENT packets with a payload type of “DynamicRTP-Type-101 (101)” without quotes and get duplicated. Everything else is 100% identical. Screenshots of these payloads are available via the link above.
Has wireshark seen the SDP from the remote end? If it has, there is probably an error in that SDP. The RTP itself only has the 101. The text is coming from the SDP, but, in this case, I suspect that RFC 2833 is being used without being negotiated, so there is no SDP from which to capture the name.
Yes, here are two screen captures of an SDP packet message body. The one to the provider initiates a call that all DTMF works. The one from the provider duplicates and inbound DTMF but outbound works.
To provider:
From provider:
The difference in name is an artefact from wireshark. They will both be 101 which is mapped to telephony events in both cases.
As far as I know, if you are getting repeat events over 2833, it means you are being sent multiple start/stop pairs.
After combing through packet captures all day I’ve seen that if the tone extends past 80ms, my sbc sends 3 end packets and starts a new DTMF until the original finishes then emulates till it gets the second DTMF to 80ms then sends a second set of end packets. What should I change to make asterisk either not care about length and simply forward everything or extend the maximum DTMF tone so it stops cutting it and splicing in extra DTMF? Thanks for your help so far!
Asterisk counts end packets. The inband to RFC 2833 gateway should not be sending end packets unless the tone ends.
Thanks @david55 but The provider is sending me RFC2833 not inband.
Which means the inband to 2833 gateway is outside your direct control but not that it isn’t the source of the problem.
Which means the inband to 2833 gateway is outside your direct control but not that it isn’t the source of the problem.[/quote]
Touché. I believe that it is also not under the control of my provider but rather his provider. Is there a way to adjust my system to process these correctly?
Let me throw in another wrench. My log file is registering an RFC2833 packet that I received from the provider as “mark 1” when wireshark shows the packet as “Marker: False”. The duration in the frame and log still match up but the sequence numbers don’t. In fact, none of the sequence numbers match between the log and the packet capture. In this test I received 12 frames from the provider (3 of them DTMF end frames). Excluding the end frames, 6 of the 8 DTMF frames had “mark 1” in the log but wireshark only shows “Marker: True” for the very first frame. My SBC thinks these “mark 1” frames are new DTMF sequences so it ends up sending 6 DTMF sequences to the PBX.
Log:
[2014-08-21 15:06:26.077] VERBOSE[21363][C-0000000f] res_rtp_asterisk.c: Got RTP RFC2833 from 208.76.198.250:10906 (type 101, seq 039643, ts 000160, len 000004, mark 1, event 00000003, end 0, duration 00640)
Wireshark:
Seems this might be related since I see SSRC changes in the RTP EVENT stream from SBC to my PBX.
I got this in my log:
[2014-08-22 16:00:10.011] DEBUG[26055][C-00000001] res_rtp_asterisk.c: Changing ssrc from 1276058455 to 632840008 due to a source change
https://issues.asterisk.org/jira/browse/ASTERISK-20098
The issue was with my provider’s provider. I didn’t get all the details but we were able to work around it by changing the codec from ulaw to gsm to force translation. Once the issue is fixed then we’ll go back to ulaw.