Summary:	ASTERISK-17210: The response to a CANCEL request does not always comply with RFC3261
Reporter:	Jacco van Tuijl (jacco)	Labels:
Date Opened:	2011-01-06 09:54:21.000-0600	Date Closed:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The response to a CANCEL request when the original request was an INVITE does not always comply with RFC3261. It sometimes send a 200 OK as the answer to the INVITE instead of responding with a 487 to the INVITE request. Quote from paragraph 9.2: "If the original request was an INVITE, the UAS   SHOULD immediately respond to the INVITE with a 487" this bug is timing/load dependend ****** ADDITIONAL INFORMATION ****** tshark: 189.286944 xxx.123.202.27 -> xxx.34.68.140 SIP/SDP Request: INVITE sip:436@xxx.34.68.140, with session description 189.289270 xxx.34.68.140 -> xxx.123.202.27 SIP Status: 100 Trying 189.289599 xxx.34.68.140 -> xxx.123.202.27 SIP Status: 180 Ringing 189.289738 xxx.34.68.140 -> xxx.123.202.27 SIP/SDP Status: 200 OK, with session description 189.437552 xxx.123.202.27 -> xxx.34.68.140 SIP Request: CANCEL sip:436@xxx.34.68.140 189.437728 xxx.34.68.140 -> xxx.123.202.27 SIP Status: 200 OK 189.791266 xxx.34.68.140 -> xxx.123.202.27 SIP/SDP Status: 200 OK, with session description 189.850026 xxx.123.202.27 -> xxx.34.68.140 SIP Request: ACK sip:436@xxx.34.68.140:5060 the next dialplan sometimes gives an incorrect result depending on timing and or server load: [dailplan] exten = _X.,1,ringing() exten = _X.,n,answer() exten = _X.,n,wait(3) exten = _X.,n,hangup() the next dialplan does give the correct result: [dailplan] exten = _X.,1,ringing() exten = _X.,n,wait(1) exten = _X.,n,answer() exten = _X.,n,wait(3) exten = _X.,n,Hangup()
Comments:	By: Jacco van Tuijl (jacco) 2011-01-07 03:42:25.000-0600 The client send a CANCEL request as soon as it recieves the 180 RINGING