[Home]

Summary:ASTERISK-09270: SIP dtmf signaling failing due to bad INVITE
Reporter:Matthew Crawford (mcrawford)Labels:
Date Opened:2007-04-16 17:32:44Date Closed:2007-07-11 19:59:04
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) debug-1.4.0.log
( 1) debug-1.4.2.log
( 2) debug-SVN-branch-1.4-r61781.log
Description:
When upgrading from 1.4.0 to 1.4.2 we ran into a problem where dtmf no longer was being detected by the asterisk system. The asterisk system has no handsets and serviced directly as a device that is sip trunked to by our Cisco Callmanager.

In doing debugging and testing it was found that starting with 1.4.1 asterisk no longer broadcast that it supported type 101 audio format in the INVITE so the Cisco Callmanager does not return that it supports type 101 either. With 1.4.0 it provided (m=audio 17700 RTP/AVP 3 0 8 101) in its INVITE and now with 1.4.1 and above (including current trunk SVN) only provides (m=audio 18762 RTP/AVP 3 0 8) causing the issue.

I have provided (attached) detailed debug of both the good working 1.4.0 session as well as the bad 1.4.2 session. All configuration was the same with the exception of the make install of the other version. Let me know if there is any other debug information I can provide to assist.


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

BAD INVITE (1.4.1+):
v=0
o=root 26216 26216 IN IP4 192.168.100.18
s=session
c=IN IP4 192.168.100.18
t=0 0
m=audio 18762 RTP/AVP 3 0 8
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

BAD ACK (1.4.1+):
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 192.168.108.101
s=SIP Call
c=IN IP4 192.168.100.205
t=0 0
m=audio 29100 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20

Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)

GOOD INVITE (1.4.0):
v=0
o=root 25629 25629 IN IP4 192.168.100.18
s=session
c=IN IP4 192.168.100.18
t=0 0
m=audio 17700 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

GOOD ACK (1.4.0):
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 192.168.108.101
s=SIP Call
c=IN IP4 192.168.100.205
t=0 0
m=audio 18462 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Comments:By: Joshua C. Colp (jcolp) 2007-04-24 11:40:49

Fixed in 1.2 as of revision 61771, 1.4 as of revision 61772, and trunk as of revision 61773.
By: Matthew Crawford (mcrawford) 2007-04-24 14:52:06

Pulled down latest on 1.4 branch (SVN-branch-1.4-r61781) and problem continues. Attaching debug of event but it looks the same as original debugs. :)

As below * thinks it has type 101 but doesn't report it in its audio line of its import:

Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)

m=audio 17862 RTP/AVP 3 0 8
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000


Thanks for taking a look at it and let me know if you need anything else.


By: Joshua C. Colp (jcolp) 2007-04-24 14:53:51

The problem itself is that there is no SDP in the initial INVITE. chan_sip was not designed to handle that scenario, and the code right now just happens to sort of work under some circumstances.
By: Matthew Crawford (mcrawford) 2007-04-24 15:01:24

It indicates the telephone-event SDP under 1.4.0. Something changed between 1.4.0 and 1.4.1 that created this issue.

In the 1.4.0 debug proved in the attachments it shows the properly working session.
By: Joshua C. Colp (jcolp) 2007-05-24 09:43:45

Fixed in 1.2 as of revision 65837, 1.4 as of revision 65839, and trunk as of revision 65840.