Subject: [SIP] CANCEL/200 OK/BYE

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 14 Oct 2000 12:28:23 -0500

All:

The bis RFC says that when an INVITE is to be terminated (either by the
UAC timing out after sending 7 requests out or by the caller associated 
with the UAC hanging up) a BYE or CANCEL request may be sent; it 
recommends sending both.

I know the reason BYE is preferred is if CANCEL and 200 OK "cross each
other on the wire".  But what if they don't?  Why send the BYE if after
sending a CANCEL, the UAC gets a 487 Request Terminated (which it will
have to ACK, of course).  There are two cases (let's assume a lossless
network with in-order delivery of packets):

Case 1: CANCEL and 200 OK DO NOT "cross each other on the wire":

  UAC
    INVITE------->
    <----------- 100 Trying
    <----------- 180 Ringing
    CANCEL ------>
    <----------- 487 Request Terminated
    ACK---------->
    <------------ 200 OK (CSeq: xxx CANCEL)

  As far as I can see, no need to send BYE here.  (Last 4 exchanges are 
  as per the behavior of a UAS when it gets a CANCEL and has NOT send a 
  final response -- Section 4.2.5 "CANCEL")

Case 2: CANCEL and 200 OK DO "cross each other on the wire":

   UAC
     INVITE------->
     <----------- 100 Trying
     <----------- 180 Ringing
     CANCEL-----> <------ 200 OK (CSeq: xxx INVITE)
     ACK --------->
     BYE --------->
     <------------- 200 OK (CSeq: xxx BYE)

   Clearly, here, the CANCEL has no effect on the state machine of the
   UAS since it has already sent out the final response.  The UAC, on
   receiving the 200 OK notes that this is OK'ing an INVITE, thus the
   CANCEL it send out has no meaning.  It ACKs the 200 OK and THEN sends
   a BYE.

So, it looks to me as if a CANCEL results in a 487 Request Terminated,
a BYE may not be sent.  Is that accurate?  Comments?

What are other implementors implementing?

If, as the RFC suggests, both a CANCEL and BYE were to be sent, then 
some timing issues arise in a real-world network which is lossless.  
These timing issues may be crucial for stateful proxies, with their need 
to maintain state for 32 seconds after sending an ACK to a non-200 
response.  

Assume that the UACs discussed in cases 1 and 2 above were branches of a 
forking proxy.  Then, in case 1, sending a BYE after getting a 200 OK to 
a CANCEL seems redundant; and in case 2, should the proxy wait 32 
seconds after sending the ACK (to ensure that it got there) before 
sending the BYE?  32 seconds seems to be a lot of time to wait before 
tearing the call down.  Comments?

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