[Home]

Summary:ASTERISK-05711: SIP SDP message of Answer() on a G729 channel prevents DTMF from working
Reporter:Kristopher Lalletti (kris2k)Labels:
Date Opened:2005-11-25 17:53:38.000-0600Date Closed:2011-06-07 14:10:10
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Problem: Asterisk cannot interpret DTMF punched-in from my Cisco 7960 phone, because the phone doesn't send the digits in the RTP stream.

For a while, I thought the issue was in the RTP, until I noticed that there were no RFC2833 RTP packets listed in the RTP debug on a G729 channel, but on a G700, there were.

Thought that phone might be the cause, but other extensions programmed on phone are registered to other Asterisk boxes with HEAD and 1.2.0rc2 and DTMF works fine in 729.

Problem seems to have inserted itself in the SIP message, and changed between 1.2.0rc2 and 1.2.0 release.

****** ADDITIONAL INFORMATION ******

I think it has to do with the SDP message discrepancy on an ulaw channel, and a g729 channel.. Take a look:

ULAW:
   -- Executing Answer("SIP/tmc-cisco-602-fadc", "") in new stack
We're at 209.217.98.198 port 11110
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 64.26.175.221:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.26.175.221:5060;branch=z9hG4bK26f6124a;received=64.26.175.221
From: "Kristopher Lalletti" <sip:tmc-cisco-602@sip.tmcsolutions.net>;tag=000d6527b85370fe3241366d-03be38c7
To: <sip:850@sip.tmcsolutions.net;user=phone>;tag=as34c4be35
Call-ID: 000d6527-b853007d-3e032849-6808bbc0@64.26.175.221
CSeq: 102 INVITE
User-Agent: TMC-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact: <sip:850@209.217.98.198>
Content-Type: application/sdp
Content-Length: 220

v=0
o=root 15406 15406 IN IP4 209.217.98.198
s=session
c=IN IP4 209.217.98.198
t=0 0
m=audio 11110 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

---
So far, so good, looks like normal.

G729:
   -- Executing Answer("SIP/tmc-cisco-602-cb67", "") in new stack
We're at 209.217.98.198 port 19740
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 64.26.175.221:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.26.175.221:5060;branch=z9hG4bK0573afbb;received=64.26.175.221
From: "Kristopher Lalletti" <sip:tmc-cisco-602@sip.tmcsolutions.net>;tag=000d6527b85370c74aabbe53-2d81b74b
To: <sip:850@sip.tmcsolutions.net;user=phone>;tag=as26d3ff14
Call-ID: 000d6527-b853007c-32125ab4-532c2c3c@64.26.175.221
CSeq: 102 INVITE
User-Agent: TMC-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact: <sip:850@209.217.98.198>
Content-Type: application/sdp
Content-Length: 241

v=0
o=root 15406 15406 IN IP4 209.217.98.198
s=session
c=IN IP4 209.217.98.198
t=0 0
m=audio 19740 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=noa=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -


What's fmtp: ?  Oddly enough, Polycom seemed to have coped with this, Sipura has the same behaviour as my Cisco 7960 phone.
Comments:By: Andrew Lindh (andrew) 2005-11-25 18:03:27.000-0600

Looks like you may be affected by bug ASTERISK-5725780

Why? Because of the line from your debug:
a=fmtp:18 annexb=noa=rtpmap:101 telephone-event/8000

cisco (and others) need to see the annexb=no correctly and this
bug also affects digit (DTMF) sending.

Upgrade to the 1.2 CVS code (to become 1.2.1) and try again.


By: Clod Patry (junky) 2005-11-25 18:46:25.000-0600

After a quick discussion with reporter, he told me it's fixed in latest head.
If someone has similar problem, feel free to report in #asterisk-bugs on freenode.