Subject: RE: [SIP] Further editorial nit in the bis draft

From: Igor Slepchin <[email-masked]>
Date: Fri, 27 Apr 2001 12:45:52 -0400

Well, the original motivation for sending a BYE instead of a CANCEL to
terminate call setup was PSTN connectivity, since PSTN gateways may
apparently want to send ISUP in SIP call termination messaging. 

With CANCELs being hop by hop and the note in 8.1 specifically prohibiting
sending payloads in CANCELs, it was somehow assumed that they are not suited
for conveying that ISUP payload. I never really bought into that argument so
I am fine with the proposed wording. However, at this point it may become a
compatibility issue if lots of folks have already implemented sending the
BYE. I'd recommend saying that UASs should be prepared to receive either a
BYE or a CANCEL but UACs SHOULD send a CANCEL and only BYE the 200 responses
if any.

---
Igor Slepchin

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, April 27, 2001 11:21 AM
> To: 'Sean Olson (EUS)'; 'Vijay Gurbani'; Jonathan Rosenberg
> Cc: Christer Holmberg (LMF); [email-masked]'
> Subject: RE: [SIP] Further editorial nit in the bis draft
> 
> 
> 
> 
>   
> -----Original Message-----
> From: Sean Olson (EUS) [mailto:[email-masked]]
> Sent: Friday, April 27, 2001 11:02 AM
> To: 'Vijay Gurbani'; Jonathan Rosenberg
> Cc: Christer Holmberg (LMF); [email-masked]'
> Subject: RE: [SIP] Further editorial nit in the bis draft
> 
> >>Jonathan: 
> >> 
> >>I misinterpret many thing, but definitely not this one :-)  In 
> >>some earlier 
> >>posting, I made the same point: a BYE should be sent after a 
> >>CANCEL iff 
> >>the 200 OK (INVITE) from the UAS and the CANCEL pass each 
> >>other on the wire. 
> >
> >This is not what Jonathan is saying. He is referring to the 
> >possibility of sending a BYE *instead* of a CANCEL, not sending 
> >a BYE in the event a CANCEL crosses on the wire. 
> 
> Everyone loves to put words into my mouth...
> 
> I was saying that the preferred approach is to send CANCEL 
> first, and then
> iff you get a 200 OK anyway (which happens if the CANCEL and 
> 200 OK pass on
> the wire) then send BYE. I was also saying we should keep 
> "just send BYE" as
> a MAY. Vijay seems to be saying we should not even mention 
> that possibility.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Apr 2001 08:46:10 +0300

Hi all,

>BYE or a CANCEL but UACs SHOULD send a CANCEL and only BYE the 200 responses

By saying that "UASs should be prepared to receive either a BYE or a
CANCEL" would not solve anything, and soon we would have this discussion
again, since many implementations would probably not implement support
to receive BYE. My suggestion would be to say that "A UAS MUST be
prepared to receive either a BYE or a CANCEL". A UAC can then send
either BYE or CANCEL (no SHOULDs needed), depending on the functionality
(Igor gave an example why a PSTN GW may want to use BYE instead of
CANCEL).

However, it should be clearly written that BYEs are used to terminate
whole calls/call setups, so that people don't start using them to
"cancel" transactions, ie re-INVITEs.

I know that my MUST-proposal may have some backward compability issues,
but solving those issues (not only in this case) by adding a lots of
SHOULDs will in many cases only move the problems to a later stage...

Regards,

Christer Holmberg
Ericsson Finland