Comment 1 Mikhail Zabaluev 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.

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..

Comment 6 Mikhail Zabaluev 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"}

(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).

Comment 9 Mikhail Zabaluev 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 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.

(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.

Comment 14 Mikhail Zabaluev 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 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.

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.

Comment 19 Andre Klapper 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.

(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. ***

Comment 22 Mikhail Zabaluev 2009-11-18 14:01:14 UTC

*** 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?

Comment 26 Andre Klapper 2010-01-14 17:45:38 UTC

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.

Comment 29 Andre Klapper 2010-01-15 18:42:02 UTC

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