|Summary:||ASTERISK-12493: DTMF RFC2833 via SIP is not working|
|Date Opened:||2008-07-31 08:23:00||Date Closed:||2008-12-09 13:47:13.000-0600|
|Environment:||Attachments:||( 0) 13209.diff|
( 1) capture.txt
( 2) rfc2833_dtmf.pcap
( 3) vp_rtp_debug.txt
( 4) wrong_DTMF_duration.txt
|Description:||Using provider bandwidth.com which support RFC2833. Configure outbound trunk to use dtmfmode=rfc2833 and we receive double digits on a different asterisk servers IVR. American Express IVR does not accept any digits (used main customer service line to test entering credit card number). Other IVR functions do not work.|
Changing to inband works but inband should not be required by bandwidth.com, they support rfc2833.
Configuration is using SIP devices and SIP trunks only. A search in issue tracker found similar problems in January of 2008 but no currently open issues.
|Comments:||By: Leif Madsen (lmadsen) 2008-08-13 15:14:55|
In order to debug this issue, we'll need a full trace of the call, including the RTP stream since that is where the RFC2833 information will reside. This is probably best provided through a wireshark trace. In addition to that, could you provide the 'rtp debug' information from the console so we can compare what Asterisk thinks it is sending, and what the wireshark trace is actually showing happening?
By: rwnboh (rwnboh) 2008-08-23 01:35:04
The attempt was to send DTMF digits 12345678#, what was sent was 1111112333333444444566666678###
By: daniel g (revolution) 2008-08-24 09:25:43
I can confirm this issue as well... sending DTMF from one * box to another (and capturing on the second) shows pretty much what rwnboh is reporting... repeated digits for each keypress.
Would you like me to provide cap/debug as well?
By: rbosch (rbosch) 2008-08-29 15:55:36
I did a real-time capture on the IP from a snom 320. The snom 320 has two identities set up. One uses Asterisk 22.214.171.124 and doesn't have the issue, the other does. Same provider. RTP capture shows multiple RFC2833 packets being sent. The capture is from pressing a digit one time on the phone...not multiple times.
Log attached as capture.txt.
By: rbosch (rbosch) 2008-08-29 18:31:44
When I downgraded the system to 126.96.36.199 the issue went away. Downgrade to 188.8.131.52 still had the problem. Appears to be something introduced after 184.108.40.206.
By: rbosch (rbosch) 2008-09-02 09:49:07
We had Level3 capture the real-time traffic they were seeing on their side to troubleshoot the issue. They reported this capture showed both inband and out-of-band DTMF which was contributing to the issue. The configuration of the SIP trunk had rfc2833 defined, not auto or inband. Only rfc2833 should have been sent.
By: Leif Madsen (lmadsen) 2008-09-02 10:12:20
After talking to Joshua Colp on IRC, he has explained that chan_sip only has the capability to send DTMF with one method at a time, so if you turn on rfc2833 it will only send rfc2833. But if there is inband DTMF coming into the system and then trying to go back out via RFC2833, the channel is suppose to mute that DTMF in the stream. If your phone is sending inband DTMF, then Asterisk may not be muting it at all.
So in the scenario:
phone --inband--> Asterisk --rfc2833--> Level 3
It could be that the inband is getting passed through in addition to it being detected and sent in the RTP packets out of band as well
As a test, could you use Monitor() and record the stream to see if you hear the DTMF in the stream?
By: rbosch (rbosch) 2008-09-02 10:19:41
During the testing for the real-time capture we could hear multiple tones. The target was a mobile phone to make sure our termination point was not using *.
We used the same phone on two * configurations. We have the SIP configuration for the phone set to rfc2833 on both * setups. The phone is a snom320 running firmware 7.3.7. All phones using the "good" * configuration have no issue (snom 320's, snom 300's and zoiper softphones). The other * configuration has the multiple DTMF issue with all phones (all configured for rfc2833) which include snom 320's and zoiper softphones. Any other information I can provide on this front? Moving the problematic * install to 220.127.116.11 completely eliminated the issue for all phones.
We could clearly hear the multiple tones when testing.
By: Leif Madsen (lmadsen) 2008-09-02 10:22:50
Do you get the same issue when going from SIP phone to SIP phone as well? I'd like to try and reproduce the issue locally if possible.
By: rbosch (rbosch) 2008-09-02 10:22:57
I should also note that I couldn't talk to the level3 techs directly and I did not receive their trace. The bandwidth.com technical engineer was coordinating with them and he reported that they recieved both the inband and DTMF signals.
The * sip config for the phone is:
callerid=Rob Test <4545>
The * sip config for the trunk is:
By: rbosch (rbosch) 2008-09-02 10:24:18
I didn't test phone to phone...I can try that but won't have the information until later when I can test the problem system again. I'm also setting up a secondary system now so I can replicate it again.
By: Florian Decher (fdecher) 2008-09-10 05:28:32
We have the same problem with our server.
Asterisk version 18.104.22.168 with snom360´s, 320´s, 300´s and some siemens gigaset c47h´s
using the snom phones the dtmf codes are multiplied when going through a trunk. (you can submit single tones by hitting the buttons VERY fast.)
using the siemens phones the dtmf codes are not multiplied?!
when we downgrade to version 22.214.171.124 erverything works fine. you can hold down buttons as long as you wish and there are no multiple dtmf´s
we tried the last 1.4.22 rc5. same behaviour like version 126.96.36.199
By: moseby (moseby) 2008-09-24 22:29:36
I have similar issues with 188.8.131.52. Looking at your, and my own, packet capture files, it appears that the RTP timestamps are changing within a single telephony event. From RFC2833, it looks like the RTP timestamp should reflect the start of the event and be the same in all packets for that event. In contrast, the duration field is updated every packet. I think it is a fair guess to say that some of the gateways receiving this are interpreting this change in timestamp as an indication that multiple key press events have occurred. It is a reasonable assumption given the effects that packet loss could have on the stream.
By: Daniel Lynes (dlynes) 2008-09-29 16:44:48
I thought I would note that I too, am noticing this issue.
When the DTMF comes into my 1.4.18 box via SIP RFC2833, everything is A-OK.
However, when it traverses to my 184.108.40.206 box via IAX2, I get duplication of tones. If I set relaxdtmf=yes on my incoming SIP lines on my 1.4.18 box, by the time the tones make it to the other end of the IAX2 channel, a number of the digits end up as other digits, not just duplicated. Without relaxdtmf=yes, the digits will get the odd repetition. It doesn't happen to be as severe as the original poster, but any amount of repetition and/or corruption is unacceptable. When someone types in a string of digits, it should work 100%, 100% of the time.
However, one thing I am noticing different from the original reporter is that it doesn't work on ULAW with inband, either.
By: Leif Madsen (lmadsen) 2008-10-06 10:49:52
Setting this back to acknowledged as it seems enough people are having this issue. Appears to be something introduced after 1.4.18 was released.
By: jackfritt (jackfritt) 2008-10-29 05:46:11
I have similar problems here. I use 1.4.22.
If i press a tone for just a sec. I get durations of 104640 ms or more.
See attached "wrong DTMF duration.txt"
If I use SIP to mISDN channels sometimes the voice from one side is completely muted if I press a DTMF key for one second. I only can hangup and dial again.
By: Stephen Monk (stephenmonk) 2008-11-10 17:58:55.000-0600
We are havingthe same issues. We are running Asterisk 220.127.116.11 using VoicePulse. When we set the DTMFMODE=RFC2833 inbound DTMF works fine, but outbound does not work at all. Typically we see it duplicating the number multiple times. If we set he DTMFMODE=INFO outbound DTMF works great, but inbound stops working. We have had this issue since 1.4.22.
By: Mark Hamilton (yourname) 2008-11-12 21:04:46.000-0600
Same story here, DTMF doesn't work on other IVRs. Using voicenetwork.ca and using any other modes doesn't seem to help either. Trying to keep rfc2833 across the board, and still no go. I have two phones, Linksys Sipura SPA941 that has AVT as an option (which is rfc2833 in other words) and Aastra 57i uses RTP as a DTMF option (which is also rfc2833 in other words)
If I call into another Asterisk IVR of some other company, it won't work for sure.
Using Asterisk 18.104.22.168. Can't upgrade because it's part of PIAF and this is the last stable version with the new Zaptel/dahdi thing as they're still trying to get it working, so please don't ask to upgrade as that might break a host of other things.
By: Ksheets (sheets) 2008-11-14 17:17:01.000-0600
Same story here too, I can grab traces of this issue past 1.4.18 all day where you press 1 digit and get 6... While DTMFMODE=INFO works most of the time for Trunks I have seen problems where you call an IVR and they do a `*1` transfer.
When Asterisk hears the `*1` asterisk disconnects the call. The other issue with DTMFMODE=INFO is when doing Follow ME when the call comes into certain cell phones and you have it setup to "press 1 to accept" Asterisk does not recognize the "1". I will be more than happy to provide some dev machines, traces or anything else I can to help get this issue resolved...
Is this due to changes in app_dial.c ?
By: Alexander Burke (alexburke) 2008-11-29 23:02:24.000-0600
For what it's worth, I've confirmed this is the case with my Asterisk 1.4.22 installation; when a SIP endpoint initiates a call through Asterisk 1.4.22 and uses RFC2833 for DTMF, it appears to be horribly broken -- duplicated DTMF tones (six times in rapid succession per buttonpress seems to be the most common manifestation) appear at the other end (landline, whatever).
Switching to inband DTMF solves the problem immediately and completely, as does downgrading to 22.214.171.124 while leaving RFC2833 in use.
This drove me nuts, and took a LONG time to nail down.
By: Ksheets (sheets) 2008-11-30 12:37:33.000-0600
Same issue exists in Asterisk Version 126.96.36.199 as well...
We are rolling back to Asterisk version 188.8.131.52 since it appears to be something introduced after 184.108.40.206 as stated earlier...
This issue is not limited to provider "bandwidth.com" as all my traces show good DTMF from the SIP endpoint and bad DTMF "duplicated DTMF tones, six times in rapid succession per button press appearing at the other end" sent to whatever trunk you may have rfc28333 configured..
By: moseby (moseby) 2008-11-30 14:17:08.000-0600
This issue exhibits the RTP packet behavior that I described in my previous post. It is not limited to any particular provider (mine is VoicePulse), nor is it limited to a particular endpoint type. I see similar behavior for zap, unistim, and sip originating lines.
By: Jeff Peeler (jpeeler) 2008-12-01 14:27:41.000-0600
Is it possible that this is related in any way to 13458?
By: rbosch (rbosch) 2008-12-01 15:15:55.000-0600
I'm not sure how it would be related since it happens with every call on my test systems. There is no on-hold/off-hold issue. The only way to resolve it is to make DTMF inband.
By: Buddy Jones (bujones) 2008-12-03 14:49:54.000-0600
I have been having the same issue with 1.4.22 since I installed last month. I have looked at the traces and from what I can tell is that the END packet when retransmitted it is using the same sequence number for each packet. I am not sure this is an issue but looking at traces coming in using RFC2388 the sequence number are incrementing.
By: Buddy Jones (bujones) 2008-12-03 15:08:41.000-0600
Forgot to mention. While on a call with Bandwidth.com support they were testing the issue on their end. When the support rep dialed the number I could hear the digits and that all worked correctly. When he started to dial a digit to go into the menu I heard at least 6 repeats of each digit. The the line quality was nearly unintelligible. He called me back and the call was ok and I asked him to do the test again and the same thing happened. I don't know if this helps.
By: Buddy Jones (bujones) 2008-12-05 17:20:25.000-0600
I did some testing today since I was told that having the same sequence number for the END packets was a bad thing. I read RFC2833 and from my read of it the sequence number of the last packet should not matter. So to prove my point I changed rtp.c to increment the sequence number of the END packet and got the same results.
I was also told that a packet gap of 20ms was not a good thing either. Again according to RFC2833 a packet gap of up 50ms should not result in a gap in the tone. So 20ms is within the range.
By: Mark Hamilton (yourname) 2008-12-06 10:53:53.000-0600
Guys, I think we've provided enough information to the Asterisk developers to get this rectified. Although I think it's taken too long and it's still not responded to (leave alone fixed), maybe we should now give it a rest and wait for some response.
At this point, I doubt they need more info than more time to fix it. May the force be with with developers.
By: Joshua C. Colp (jcolp) 2008-12-08 11:10:25.000-0600
Please give the attached patch a go. It fixes some issues with timestamps. If it does not work please attach the following: complete console output, wireshark capture, rtp debug, sip.conf configuration file, plus an explanation of what you hit versus what actually happened.
By: Buddy Jones (bujones) 2008-12-08 13:05:21.000-0600
It looks like the patch resolved the issue. I have tested it on several IVRs that were giving me the most grief.
By: rbosch (rbosch) 2008-12-08 14:02:30.000-0600
In my tests the patch resolves the issue!
By: Digium Subversion (svnbot) 2008-12-09 13:47:03.000-0600
r162204 | file | 2008-12-09 13:47:03 -0600 (Tue, 09 Dec 2008) | 7 lines
Make sure that the timestamp for DTMF is not the same as the previous voice frame and do not send audio when transmitting DTMF as this confuses some equipment.
(closes issue ASTERISK-12493)
Reported by: ip-rob
13209.diff uploaded by file (license 11)
Tested by: ip-rob, bujones