[asterisk-bugs] [Asterisk 0011737]: Cancel sending not conform to SIP RFC 3261

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11737 
====================================================================== 
Reported By:                gasparz
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11737
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.13 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-11-2008 03:58 CST
Last Modified:              01-11-2008 04:02 CST
====================================================================== 
Summary:                    Cancel sending not conform to SIP RFC 3261
Description: 
See the following call flow.

Src ip is asterisk
Date              Src IP Dst IP Packet type 
2008-01-10 10:57:24 ip1 ip2 INVITE sip:number at ip2 SIP/2.0. 
2008-01-10 10:57:24 ip2 ip1 SIP/2.0 100 Trying. 
2008-01-10 10:57:26 ip2 ip1 SIP/2.0 180 Ringing. 
2008-01-10 10:57:49 ip2 ip1 SIP/2.0 180 Ringing. 
2008-01-10 10:57:49 ip1 ip2 CANCEL sip:number at ip2 SIP/2.0. 
2008-01-10 10:57:49 ip2 ip1 SIP/2.0 200 OK. (CSeq: 102 INVITE.!!!!)
2008-01-10 10:57:49 ip1 ip2 ACK sip:number1 at ip2; SIP/2.0 
2008-01-10 10:57:49 ip1 ip2 BYE sip:number1 at ip2; SIP/2.0 
2008-01-10 10:57:49 ip2 ip1 SIP/2.0 481 Call/Transaction Does Not Exist.
(CSeq: 102 CANCEL.!!!)
2008-01-10 10:57:49 ip2 ip1 SIP/2.0 200 OK. (CSeq: 103 BYE.)
2008-01-10 10:57:50 ip1 ip2 CANCEL sip:number at ip2 SIP/2.0. 
2008-01-10 10:57:50 ip2 ip1 SIP/2.0 200 OK. (CSeq: 102 CANCEL.)
2008-01-10 10:57:51 ip1 ip2 CANCEL sip:number at ip2 SIP/2.0. 
2008-01-10 10:57:51 ip2 ip1 SIP/2.0 200 OK. CSeq: 102 CANCEL.
2008-01-10 10:57:53 ip1 ip2 CANCEL sip:number at ip2 SIP/2.0. 
2008-01-10 10:57:53 ip2 ip1 SIP/2.0 200 OK. CSeq: 102 CANCEL.
2008-01-10 10:57:57 ip1 ip2 CANCEL sip:number at ip2 SIP/2.0. 
2008-01-10 10:57:57 ip2 ip1 SIP/2.0 200 OK. CSeq: 102 CANCEL.
2008-01-10 10:58:01 ip1 ip2 CANCEL sip:number at ip2 SIP/2.0. 
2008-01-10 10:58:01 ip2 ip1 SIP/2.0 200 OK. CSeq: 102 CANCEL.
2008-01-10 10:58:05 ip1 ip2 CANCEL sip:number at ip2 SIP/2.0. 
2008-01-10 10:58:05 ip2 ip1 SIP/2.0 200 OK. CSeq: 102 CANCEL.

so we want to cancel after we received the 180 ringing from ip2. But while
we send the first cancel (sending this cancel is correct) the ip2 accepts
the call (200 ok). Now we have a strange situation. Asterisk confirms the
200 ok for the invite with an ACK, then imidiatly sends a BYE request. The
ip2 accepts the bye with a 200 ok, great.

Now the strange things:
ip2 sends 481 Call/Transaction Does Not Exist. for the cancel request. I
don't know how good is this message, but this is not the issue.

After the ip2 sends the 200 ok for the bye we resend the cancel. I
understand asterisk sees no 200 ok for the cancel and it resends it after
exactly 1 second, a normal packet retransmision, BUT it shouldn't. In this
case the 200 ok that accepts the invite, or at least the 200 ok for the bye
should block the sending, retransmision of the cancel packet.

Because: (sip RFC 3261)
page 42:
"Once the CANCEL is constructed, the client SHOULD check whether it has
received any response (provisional
or final) for the request being cancelled (herein referred to as the
“original request”).
If no provisional response has been received, the CANCEL request MUST NOT
be sent; rather, the client
MUST wait for the arrival of a provisional response before sending the
request. If the original request has
generated a final response, the CANCEL SHOULD NOT be sent, as it is an
effective no-op, since CANCEL
has no effect on requests that have already generated a final response."

But anyway after the second cancel we receive a 200 ok message
acknowlegeing the cancel so the cancel retransmition should be stoped at
least at this point.

But no the rettransmission continues another 5 times (I think until it
reaches max_retrans for the packet).

====================================================================== 

---------------------------------------------------------------------- 
 gasparz - 01-11-08 04:02  
---------------------------------------------------------------------- 
About how to reproduce this: this is really not easy, I captured this
behavior from a production sistem, it is really timing sensitive. Maybe
building a state machine that responds with this message flow or just put
the patched version in production and let it run until the conditions
become right again :). I don't have better ideas sorry. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-11-08 04:02  gasparz        Note Added: 0076703                          
======================================================================