[asterisk-bugs] [Asterisk 0011800]: asterisk 1.6-beta1 destroys cisco 7960 (sip firmware 7.4) outbound calls after 20sec due to no response to 200 OK
noreply at bugs.digium.com
noreply at bugs.digium.com
Sun Jan 20 21:07:55 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=11800
======================================================================
Reported By: hmodes
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 11800
Category: Channels/chan_sip/Interoperability
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.6.0-beta1
SVN Branch (only for SVN checkouts, not tarball releases): 1.6
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 01-19-2008 23:04 CST
Last Modified: 01-20-2008 21:07 CST
======================================================================
Summary: asterisk 1.6-beta1 destroys cisco 7960 (sip firmware
7.4) outbound calls after 20sec due to no response to 200 OK
Description:
Version tag on this report is incorrect as there is no 1.6-beta1 tag yet.
1.6-beta1 appears to have an issue with sip timers that causes cisco 7960
sip firmware 7.4 clients to be disconnected after 20 seconds for not
responding to 200 OK (marked as 'critical packet') once call setup is
complete. See debug. Incoming calls to the client do not experience the
disconnect. This is reproducible on two phones both on the lan with
asterisk and at a remote site.
======================================================================
----------------------------------------------------------------------
hmodes - 01-20-08 21:07
----------------------------------------------------------------------
More info on this. I went back and looked at a tethereal dump at the phone
between 1.4.0 and 1.6.0-beta1 with the same configuration and same phone,
and it appears that in 1.4.0, the 7960 does ACK the 200 OK, but it doesn't
in 1.6.0-beta1
1.4.0:
427.901661 172.27.28.127 -> 172.27.28.2 SIP/SDP Request: INVITE
sip:12152223456 at 172.27.28.2;user=phone, with session description
427.902660 172.27.28.2 -> 172.27.28.127 SIP Status: 407 Proxy
Authentication Required
427.991555 172.27.28.127 -> 172.27.28.2 SIP Request: ACK
sip:12152223456 at 172.27.28.2;user=phone
428.058475 172.27.28.127 -> 172.27.28.2 SIP/SDP Request: INVITE
sip:12152223456 at 172.27.28.2;user=phone, with session description
428.059474 172.27.28.2 -> 172.27.28.127 SIP Status: 100 Trying
428.063467 172.27.28.2 -> 172.27.28.127 SIP Status: 180 Ringing
430.137626 172.27.28.2 -> 172.27.28.127 SIP/SDP Status: 200 OK, with
session description
430.304460 172.27.28.127 -> 172.27.28.2 SIP Request: ACK
sip:12152223456 at 172.27.28.2:5066
443.796524 172.27.28.2 -> 172.27.28.127 SIP Request: BYE
sip:hmodes at 172.27.28.127:5068;transport=udp
With sip_state debug enabled on the phone, it reports the following when
receiving 1.6.0-beta1's 200 OK:
[21:35:34:19959] sip_sm_determine_ccb: Matched to_tag
[21:35:34:19959] sip_sm_ccb_match_branch_cseq: Method index not found
[21:35:34:19960] SIPTaskProcessSIPMessage: Error: sip_sm_determine_ccb():
bad response. Dropping message.
As far as I can tell, the likely candidate for why the phone is dropping
the 200 OK is the port in the Contact: field. I spent some time comparing
the 1.4 200 OK and 1.6 200 OK and ruled out differences in the Supported:
(1.6 includes timer, 1.4 only has replaces) and s= (1.4 sets session, 1.6
sets Asterisk PBX 1.6.0-beta1) Below is the 1.4 200 OK followed by the 1.6
200 OK (after changing the mentioned differences to match 1.4's). I have
_NO_ idea where 1.6 is getting port 51731 for in the contact field. The
phone is transmitting from port 50750 for this transaction (<--- SIP read
from UDP://172.27.28.127:50750 --->)...
#### 1.4.0 200 OK
<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
172.27.28.127:5068;branch=z9hG4bK3e4b42ba;received=172.27.28.127
From: "hmodes"
<sip:hmodes at 172.27.28.2>;tag=0002fdaeee6f09f40a923727-2ca7742d
To: <sip:12152223456 at 172.27.28.2;user=phone>;tag=as7738c114
Call-ID: 0002fdae-ee6f000a-12a7ddcc-25320b0f at 172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:12152223456 at 172.27.28.2:5066>
Content-Type: application/sdp
Content-Length: 236
v=0
o=root 8875 8875 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 44702 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
##### 1.6.0-beta1 200 OK
<--- Reliably Transmitting (no NAT) to 172.27.28.127:5068 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
172.27.28.127:5068;branch=z9hG4bK3728f458;received=172.27.28.127
From: "hmodes"
<sip:hmodes at 172.27.28.2>;tag=0002fdaeee6f00394f1cea50-1f4aa646
To: <sip:12152223456 at 172.27.28.2;user=phone>;tag=as02b797d7
Call-ID: 0002fdae-ee6f000b-14a62878-104c655e at 172.27.28.127
CSeq: 102 INVITE
User-Agent: matrix.gs asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:12152223456 at 172.27.28.2:51731>
Content-Type: application/sdp
Content-Length: 248
v=0
o=root 2055288498 2055288498 IN IP4 172.27.28.2
s=session
c=IN IP4 172.27.28.2
t=0 0
m=audio 46746 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
Incidentally, changing XMIT_CRITICAL to XMIT_RELIABLE in sip_answer()
functions as a temporary workaround to this bug. The 200 OK is still
ignored by the 7960 but asterisk does not destroy the call as a result.
Issue History
Date Modified Username Field Change
======================================================================
01-20-08 21:07 hmodes Note Added: 0080923
======================================================================
More information about the asterisk-bugs
mailing list