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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Apr 2001 03:33:35 -0400

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, April 26, 2001 1:01 PM
> To: Vijay Gurbani
> Cc: [email-masked]'
> Subject: Re: [SIP] Further editorial nit in the bis draft
> 
> 
> >>Also, from a standardization point of view: first BYE was 
> not allowed,
> >>then it was allowed, and now we want to make it not allowed 
> again... How
> >>long is it then going to take before we want to allow it again?
> > 
> >I thought the genealogy was that "BYE was allowed in RFC 2543 to
> >terminate a pending INVITE, but current thinking is that it 
> should not be".
> >I do not remember it being "not allowed, then it was 
> allowed, and now we
> >want to make it not allowed again."
> 
> I guess I put my words wrong. I meant the way we want to 
> handle the BYE,
> ie if a
> final response should be sent for the INVITE if a BYE is 
> received, etc.
> First that
> was the case, then it was decided to handle it like a BYE, and now we
> want to forbid it.

There has been a lot of misunderstanding about what I was saying.

No matter what, the original INVITE request is responded to. Period.
Christer somehow misunderstood my post to imply that the INVITE need not be
responded to if a BYE is used to "cancel" the call. This was my
interpretation of his post, at least, when he wrote:

> What if we get a Contact/Record-Route in a provisional response to the
> INVITE, which means the BYE could be sent another route (using other
> proxies) than the INVITE. If there is no response to the INVITE, how
> will be intermediate proxies handling the INVITE know that 
> there will be
> no response?

To be clear, the INVITE is ALWAYS responded to, so there is no issue above.

Vijay also misinterpreted my post to mean that we were getting rid of the
ability to terminate a call before 200 OK, using BYE. I was not proposing
that either. Before a final response is received (or a provisional response
with RR), the best way to hang up the call is to send CANCEL, and then if
you get any 200 OK, send BYE. Sending BYE first can cause unusual failure
conditions when the routing logic at intervening proxies is not
deterministic, or is deterministic, but based on variables outside of the
SIP request (like time of day). However, lots of people preferred this
approach since its easiest to implement. These issues have been discussed
and pointed out many times over a long period. THe current bis draft does
instruct a UA to send CANCEL and BYE at the same time. I actually don't like
this, since you can still get into conditions where you don't know whether
the call is hung up. 

It would be my proposal to have the spec say that the right behavior is
CANCEL, followed by BYE for any 200 OK that happen to pass the BYE on the
wire. If you get a non-200 response to INVITE after the CANCEL, you're done,
and the hangup was successful. However, the spec would also say that a basic
implementation MAY just send BYE right away, and point out the potential
issues.

Now, back to my original post on this, where I said:

>>>Actually, I would rather remove the reference to cancelling a
>>>request with
>>>BYE. Thats legacy from the old days when, in fact, sending a
>>>BYE meant you
>>>didn't need to respond to the original INVITE.

All I meant was that the following text from bis:

>Strictly speaking, CSeq header fields are needed
>for any SIP request that can be cancelled by a BYE
>or CAN-CEL request or where a client can issue several
>requests for the same Call-ID in close succession.
>Without a sequence number, the response to an INVITE
>could be mistaken for the response to the cancellation
>(BYE or CAN-CEL). Also, if the network duplicates packets
>or if an ACK is delayed until the server has sent an additional response,

this text seems to imply that BYE cancels a sip request, which is not really
true. BYE will trigger a final response to INVITE if none has been sent yet,
but thats not a general CANCEL operation. Nor is this text even correct,
that the response to BYE could be confused with the CANCEL response. All I
was saying, therefore, was to remove the reference to BYE in this paragraph.

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

---

From: Vijay Gurbani <[email-masked]>
Date: Fri, 27 Apr 2001 09:27:16 -0500

Jonathan Rosenberg wrote:
[...]
> that either. Before a final response is received (or a provisional 
> response with RR), the best way to hang up the call is to send CANCEL, and 
> then if you get any 200 OK, send BYE. 

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.

> wire. If you get a non-200 response to INVITE after the CANCEL, you're 
> done, and the hangup was successful. 

Fine; just a small nit: if you get a non-200 response to the INVITE after 
sending the CANCEL, there is no hangup -- no session was established.  The 
UAC ACKs the non-200 response for the INVITE and waits for the 200 OK 
(CANCEL).  That's it.

> However, the spec would also say that a basic implementation MAY just send 
> BYE right away, and point out the potential issues.

Ummm, if you do this, chances are that many UA implementations will trade
off complexity for time and implement sending BYE only.  Pretty soon we will 
be back to debating the same issue a few months from now.  My input (for 
what its worth) would be not to even mention that a basic implementation MAY 
just send BYE right away.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 27 Apr 2001 10:43:54 -0400

> wire. If you get a non-200 response to INVITE after the CANCEL, you're
done,
> implementation MAY just send BYE right away, and point out the potential

I believe you meant "followed by BYE for any 200 OK that happened to pass
the CANCEL on the wire" in the first sentence.

I agree. You should not send two messages (CANCEL and BYE) when one will
suffice.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "'Christer Holmberg'" <[email-masked]>; "Vijay
Gurbani" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 27, 2001 3:33 AM
Subject: RE: [SIP] Further editorial nit in the bis draft

> that either. Before a final response is received (or a provisional
response
> wire. If you get a non-200 response to INVITE after the CANCEL, you're
done,