maemo.org Bugzilla – Bug 5505
DTMF tones are not sent through SIP
Last modified: 2010-03-06 03:17:09 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 1.2009.41-10 STEPS TO REPRODUCE THE PROBLEM: 1. Start call application 2. Select SIP account and call to a SIP conference number (this one is an Asterisk deployment). 3. Call the number 4. The conference service asks for a PIN code to be entered using DTMF 5. Tap on DTMF keyboard button and enter the PIN EXPECTED OUTCOME: Access to the conference room is granted. ACTUAL OUTCOME: Conference service says PIN code is invalid. Note: it says the same if no PIN code is provided so this could be both transmiting badly the PIN code, or no transmiting the DTMF at all. REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: Conference service: an Asterisk service in my company. It works with the same PIN code without problems in n810. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090924 Ubuntu/9.10 (karmic) Firefox/3.5.3
There are many examples where our SIP implementation doesn't have any means negotiated to send DTMF, or where it actually does, but the recipient does not recognize the events. Could you attach a relevant SIP traffic log from Asterisk, or a tcpdump on the device? You can mail me directly if you don't want the logs posted on this public Bugzilla.
Created an attachment (id=1435) [details] SIP session debug log This is a dump of the Asterisk console with verbosity=4 and auth hashes stripped. User "jdapena" is trying to create a conference room (which also needs DTMF codes to set-up the PIN). As DTMF is configured in RFC-2833 mode tones should be added as payload in the RTP stream, that's why they do not appear here.
Created an attachment (id=1436) [details] RTP Asterisk debug log Dump of what the Asterisk console prints when enabling RTP debug with "rtp debug ip V.X.Y.Z"
Created an attachment (id=1437) [details] Pcap dump of RTP+SIP traffic This is a packet dump taken at the server in Pcap format, taken with: # tcpdump -w rtp-dump.pcap dst <ipaddress> or src <ipaddress> You can inspect packets replaying them with: $ tcpdump -r rtp-dump.pcap <usual-tcpdump-options>
Arg, we seem to just never send any DTMF events at all..
The fmtp attribute from Asterisk looks odd: a=rtpmap:99 telephone-event/8000 a=fmtp:99 0-16 It misses the events= parameter name and the range is 0-16 vs. our 0-15. Olivier, it's up to you, whether you think we can work around this. Telepathy-sofiasip would pass this parameter string to S-E as {"" => "0-16"}
(In reply to comment #6) > The fmtp attribute from Asterisk looks odd: > > a=rtpmap:99 telephone-event/8000 > a=fmtp:99 0-16 > > It misses the events= parameter name Should that be there at all? It doesn't seem to agree with RFC2833 3.9. BTW, Diablo (working fine) doesn't send an fmtp line for telephone-event, maybe that's relevant? > and the range is 0-16 vs. our 0-15. That should be fine, it just means asterisk also supports the flash event in addition to 0-9, *, # and A-D.
Actually, what Asterisk is sending is fine according to RFC 4733 (the events= is there in the mime-type, but not in the SDP).
(In reply to comment #8) > Actually, what Asterisk is sending is fine according to RFC 4733 (the events= > is there in the mime-type, but not in the SDP). How do we deal with that? Would S-E send the connection manager "" => "0-15" in codec parameters? Will it work in Jingle if done this way?
(In reply to comment #7) > > and the range is 0-16 vs. our 0-15. > > That should be fine, it just means asterisk also supports the flash event in > addition to 0-9, *, # and A-D. This makes 0 to 15. What is the 16th event? :) I don't think we shouldn't survive this, however.
(In reply to comment #10) > This makes 0 to 15. What is the 16th event? :) Line flash in RFC2833, deprecated in RFC4733.
Currently, the streaming layer just ignores the events= entirely, so this is not the cause of our bug. But I guess if we wanted to do it correctly, maybe the SDP writer in sofiasip should know about mimetype->sdp conversion.
I also need this function to work. If you call someone using the normal cellular account, you can clearly hear tones when you push the dialing pad buttons, but if you use a sip account to call someone, then pressing the keys on the dialing pad doesn't produce any tones. On the Internet Tablet N800 DTMF tones work perfectly using the same SIP account. Also I think DTMF tones should be working because otherwise you should get the message "Call does not support DTMF tones". That is what happens if you use Skype on the N900 to call to a normal landline and press the dialing pad.
It seems we can make the Asterisk case work Real Soon Now, but our SDP non-compliance is disconcerting. I should file some smaller upstream bugs about it.
(In reply to comment #13) > Also I think DTMF tones should be working because otherwise you should get the > message "Call does not support DTMF tones". That is what happens if you use > Skype on the N900 to call to a normal landline and press the dialing pad. Ironically, that happens because we don't yet support DTMF as a feature for Skype calls.
This now works for me after setting "session-timers=refuse" in sip.conf for the N900's SIP account (thanks to bug 5614 comment 9 for the suggestion). It seems that without that the N900 doesn't think a call has been established and doesn't send audio or DTMF. Does that fix things for anyone else?
I can confirm this bug. @lucas where is the sip.conf located?
I found and fixed the problem causing DTMF tones to not be sent. It should be fixed in the first bugfix release of Maemo.
This has been fixed in package farsight2 0.0.15-0maemo4+0m5 which is part of the internal build version 2009.43-2 (Note that 2009 is the year and the number after is the week.) Any public update released with or after this build version will include the fix. Please verify that the new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time.
(In reply to comment #17) > @lucas where is the sip.conf located? /etc/asterisk/, on the server side.
*** Bug 6171 has been marked as a duplicate of this bug. ***
*** Bug 6912 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > This has been fixed in package > farsight2 0.0.15-0maemo4+0m5 > which is part of the internal build version > 2009.43-2 This bug is still valid in 2.2009.51-1.
(In reply to comment #24) > This bug is still valid in 2.2009.51-1. Hm, it now works for me on the same version even without "session-timers=refuse". Tested with asterisk 1.4.21.1 and 1.6.1.11 on the remote end, what are you using?
A third comment is welcome here whether it works now or not...
Works for me using 2.2009.51-1
I can verify this bug. DTMF tones are sent through SIP successfully.
Thanks! Closing...
Marking as verified. It works now. Thanks!
Doesn't work on my unit, I checked SIP (asterisk) and skype, no DTMF whatsoever. Version 3.2010.02-8.002 Best Regards