Subject: RE: [SIP] CANCEL/200 OK/BYE

From: [email-masked]
Date: Mon, 16 Oct 2000 10:19:42 -0500

> -----Original Message-----
> From: EXT Vijay K. Gurbani [mailto:[email-masked]]
[ . . . ] 
> 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").
> 
> 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
>

The note in section 4.2.5 of the RFC-bis draft makes it fairly clear that
BYE may be used instead of CANCEL. 

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. 

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.

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

---

From: [email-masked]
Date: Tue, 17 Oct 2000 17:24:38 +0300

> has answered, BYE has to be used.

Well, this is not that simple. There are still open issues here
that we are 
currently resolving. The new mapping draft will contain the
solutions chosen.
 
> ensure that the UAS that received the INVITE will also get
the BYE.

The problem is that a stateful proxy (transaction stateful)
does not know where 
the INVITE went. INVITE and BYE are two unrelated transactions.
Stateful proxies 
will route correctly the CANCEL though, because CANCELs can be
related to 
INVITEs examining the Cseq.

Regards,

Gonzalo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Oct 2000 10:00:41 -0500

> > 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  [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