[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [SIP] CANCEL/200 OK/BYE
From:       "Vijay K. Gurbani" <vkg () lucent ! com>
Date:       2000-10-17 15:00:41
Message-ID: 39EC6999.9578143 () lucent ! com
[Download RAW message or body]

Cliff.Harris@nokia.com wrote:
> 
> > -----Original Message-----
> > From: EXT Vijay K. Gurbani [mailto:vkg@lucent.com]
> [ . . . ]
> > I think the spec should state that a UAC MUST send a  BYE iff after
> > having sent a CANCEL (for an in-progress INVITE), it got a 200 class
> > response to the INVITE (which means that the 200 OK and
> > CANCEL "crossed
> > each other on the wire").
[...]
> The note in section 4.2.5 of the RFC-bis draft makes it fairly clear 
> that BYE may be used instead of CANCEL.

I am not sure I understand that paragraph; or let me rephrase -- based
on my understanding of the paragraph, I don't agree with it.  Unless a 
UAC has received a 200 OK for an INVITE, there is no session (or a call) 
established yet.  Now, if the UAC hangs up before receiving a 200 OK,
it SHOULD send out a CANCEL to the next downstream server, not a BYE.

If the next downstream server happens to be a proxy, the CANCEL will 
reach the same destinations that the INVITE did, which is what we would 
want to happen, I would think.  If the next downstream server is the 
intended UAS, the CANCEL should halt its state-machine so it does not 
send a 200 OK (in case it already has by the time it gets the CANCEL, 
the CANCEL has no effect on its state machine and the UAC will ACK the 
200 OK and THEN send a BYE -- the route has been established through the 
200 OK so the BYE can reach it's intended destination without further
"forking").
 
> One very good reason for using BYE instead of CANCEL is that BYE may 
> have an attachment and CANCEL may not. In the SIP-T case, if the UAC 
> wants to include an attached PSTN message when the caller hangs up 
> before the far end has answered, BYE has to be used.

Out of curisority, why can't the attachment be sent within the CANCEL?

> I guess there are issues with tags and routes and all that. I don't 
> know if the spec addresses this, but in my naive view it would make 
> sense if a proxy that received a BYE without a tag sent it to all 
> possible destinations, to ensure that the UAS that received the INVITE 
> will also get the BYE.

What you describe above is "forking" the BYE request.  IMHO, "forking" 
the INVITE makes eminent sense; I am not convinced that forking of other 
requests (namely, BYE, OPTIONS and CANCEL) makes equal sense.  What is 
the effect of forking an OPTIONS request (if that is the VERY FIRST 
request to arrive at a forking proxy?)  I bought up this point on the 
list a few weeks ago (interested parties can search the archive).

- vijay
-- 
Vijay K. Gurbani  vkg@lucent.com vkg@research.bell-labs.com vkg@acm.org
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
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

[prev in list] [next in list] [prev in thread] [next in thread]