Subject: [SIP] CANCEL - response sequence issue (again)

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Oct 2000 18:49:11 -0500

Jonathan/Dr. Schulzrinne: possible backward compatibility scenario 
listed below.  If you please, could you go through this email...

All:

Sorry to beat a (maybe not so) dead horse; but I think that the 
INVITE/{CANCEL,BYE} issue may lead to interoperability problems.  On
October 16th, Piotr Kossowski and I had an email exchange included in 
this URL: http://lists.bell-labs.com/pipermail/sip/2000q4/003311.html

Based on some of my call flows, Piotr had asked if his call flows (rep-
roduced as 3 and 4 below) were correct:

> My question is about correctness of next sequences:
> 
> 3.
> 
>   UAC
>     INVITE----->
>     <----------- 100, 18x..
>     CANCEL----->
>     <----------- 487 (CSeq: xxx INVITE)
>     <----------- 200 (CSeq: xxx CANCEL)
>     ACK--------> (for 487 response)
> 
> Is it allowed to send 200 response just after sending 487, before
> getting ACK for 487 response ?
> 
> If yes, what about:
> 
> 4.
>   UAC
>     INVITE----->
>     <----------- 100 , 18x..
>     CANCEL----->
>     <----------- 200 (CSeq: xxx CANCEL)
>     <----------- 487 (CSeq: xxx INVITE)
>     ACK--------> (for 487 response)
> 

To which I had replied, both were correct and the order did not matter
since these were two distinct transactions.  But I am not so convinced 
any more.  I think we may have a backward compatibility issue here.  
First off, response 487 was not present in the original RFC 2543, it is 
new to the bis.  Thus, the UAS coded according to the original RFC would 
exhibit this behavior:

   UAC
     INVITE------>
     <------------ 100, 18x, ...
     CANCEL ----->
     <------------ 200 OK (CSeq: xxx CANCEL)

and that's it (and this is the behavior I am observing of the UASes I 
have in my lab).  

Now, if we have a UAC (actual UAC or a virtual UAC branch on a proxy)
that's coded according to the new bis but dealing with a UAS that's 
coded according to the original RFC, the order of delivery suddenly
becomes important if the UAC wants to clean state correctly.

Consider a UAC coded to the bis spec dealing with an old UAS coded to
the RFC 2543 spec.  If the UAC sends a CANCEL, it will only get the 200 
OK (CSeq: xxx CANCEL).  So, it is done with the CANCEL/200 OK 
transaction.  But it will never get the 487 Request Terminated response 
for it's original INVITE.  The UAC will not retransmit the INVITE (since 
it got the provisional responses), leading to inconsistent call state in
the UAC.

I think the bis should, in section 4.2.5 stress that, "...If the server
has not issued a final response for the original request, it immediately
sends a 487 Request Terminated for the original request.  The UAC 
confirms receipt of any final response for the original request as 
normal with an ACK request.  CANCEL request is answered with a 200 OK
response in either case after the original transaction has completed."
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        My suggested wordings; please re-word if needed

In this case, if the newly minted UAC sends a CANCEL after the INVITE,
and gets a 200 OK (CSeq: xxx CANCEL) instead of a 487 Request 
Terminated, it can figure out that it is dealing with an older UAS which
will NOT send it a 487.  Thus it can close all its transactions on 
getting a 200 OK (CSeq: xxx CANCEL).

If I am mistaken in my analysis (which won't be the first time), please 
let me know.

Thanks,

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software Group/Intelligent Network and Messaging Systems
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip