Bug 5505 - (int-136360) DTMF tones are not sent through SIP
(int-136360)
: DTMF tones are not sent through SIP
Status: VERIFIED FIXED
Product: Chat & Call & SMS
SIP
: 5.0/(1.2009.44-1)
: N900 Maemo
: Low major with 3 votes (vote)
: 5.0/(2.2009.51-1)
Assigned To: Olivier Crête
: sip-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-10-16 10:39 UTC by José Dapena Paz
Modified: 2010-03-06 03:17 UTC (History)
11 users (show)

See Also:


Attachments
SIP session debug log (13.79 KB, text/plain)
2009-10-16 15:07 UTC, Adrian Perez
Details
RTP Asterisk debug log (195.46 KB, text/plain)
2009-10-16 15:29 UTC, Adrian Perez
Details
Pcap dump of RTP+SIP traffic (319.70 KB, application/octet-stream)
2009-10-16 15:53 UTC, Adrian Perez
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description José Dapena Paz (reporter) 2009-10-16 10:39:14 UTC
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
Comment 1 Mikhail Zabaluev nokia 2009-10-16 13:41:29 UTC
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.
Comment 2 Adrian Perez 2009-10-16 15:07:29 UTC
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.
Comment 3 Adrian Perez 2009-10-16 15:29:08 UTC
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"
Comment 4 Adrian Perez 2009-10-16 15:53:22 UTC
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>
Comment 5 Olivier Crête 2009-10-16 19:15:42 UTC
Arg, we seem to just never send any DTMF events at all..
Comment 6 Mikhail Zabaluev nokia 2009-10-16 19:53:14 UTC
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"}
Comment 7 Lucas Maneos 2009-10-16 20:25:16 UTC
(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.
Comment 8 Olivier Crête 2009-10-16 20:26:10 UTC
Actually, what Asterisk is sending is fine according to RFC 4733 (the events=
is there in the mime-type, but not in the SDP).
Comment 9 Mikhail Zabaluev nokia 2009-10-16 20:31:22 UTC
(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?
Comment 10 Mikhail Zabaluev nokia 2009-10-16 20:33:40 UTC
(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.
Comment 11 Lucas Maneos 2009-10-16 20:45:16 UTC
(In reply to comment #10)
> This makes 0 to 15. What is the 16th event? :)

Line flash in RFC2833, deprecated in RFC4733.
Comment 12 Olivier Crête 2009-10-16 20:47:59 UTC
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.
Comment 13 Bernard Schendstok 2009-10-17 18:48:56 UTC
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.
Comment 14 Mikhail Zabaluev nokia 2009-10-19 15:08:23 UTC
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.
Comment 15 Mikhail Zabaluev nokia 2009-10-19 17:31:10 UTC
(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.
Comment 16 Lucas Maneos 2009-10-22 21:39:43 UTC
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?
Comment 17 Giorgos Logiotatidis 2009-10-28 16:02:01 UTC
I can confirm this bug.

@lucas where is the sip.conf located?
Comment 18 Olivier Crête 2009-10-28 16:14:05 UTC
I found and fixed the problem causing DTMF tones to not be sent. It should be
fixed in the first bugfix release of Maemo.
Comment 19 Andre Klapper maemo.org 2009-11-05 14:57:33 UTC
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.
Comment 20 Lucas Maneos 2009-11-07 20:14:05 UTC
(In reply to comment #17)
> @lucas where is the sip.conf located?

/etc/asterisk/, on the server side.
Comment 21 Lucas Maneos 2009-11-14 11:13:44 UTC
*** Bug 6171 has been marked as a duplicate of this bug. ***
Comment 22 Mikhail Zabaluev nokia 2009-11-18 14:01:14 UTC
*** Bug 6171 has been marked as a duplicate of this bug. ***
Comment 23 Lucas Maneos 2009-12-13 15:46:07 UTC
*** Bug 6912 has been marked as a duplicate of this bug. ***
Comment 24 Uwe Kaminski 2010-01-07 14:59:50 UTC
(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.
Comment 25 Lucas Maneos 2010-01-07 18:15:29 UTC
(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?
Comment 26 Andre Klapper maemo.org 2010-01-14 17:45:38 UTC
A third comment is welcome here whether it works now or not...
Comment 27 Giorgos Logiotatidis 2010-01-14 21:31:50 UTC
Works for me using 2.2009.51-1
Comment 28 Venomrush 2010-01-15 02:22:29 UTC
I can verify this bug.

DTMF tones are sent through SIP successfully.
Comment 29 Andre Klapper maemo.org 2010-01-15 18:42:02 UTC
Thanks! Closing...
Comment 30 José Dapena Paz (reporter) 2010-01-15 19:06:02 UTC
Marking as verified. It works now.

Thanks!
Comment 31 gyptzy 2010-03-06 03:17:09 UTC
Doesn't work on my unit, I checked SIP (asterisk) and skype, no DTMF
whatsoever.

Version 3.2010.02-8.002

Best Regards