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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Apr 2001 14:34:46 -0400

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, April 25, 2001 2:23 PM
To: 'Jonathan Rosenberg'; 'Drage, Keith (Keith)'; 'Henning G. Schulzrinne'
Cc: [email-masked]'
Subject: RE: [SIP] Further editorial nit in the bis draft

>>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. 
>> 
>Do you mean to remove the option of sending a BYE prior 
>to the conclusion of the INVITE transaction signalling that 
>the INVITE transaction should be "cancelled"? Or do you mean 
>simply the idea that a BYE sent in this case means that the 
>INVITE does not need to be responded to (with a 487)? 

The idea that BYE in this case means that the INVITE doesn't need
to be responded to.

-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: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2001 09:55:27 +0300

Hi,

>The idea that BYE in this case means that the INVITE doesn't need

I don't know if this is related to the issue, but just to clarify:

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?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 26 Apr 2001 09:31:17 -0500

> will be intermediate proxies handling the INVITE know that there will be

A Route list is only created from Contact/R-R headers at the UAC end when
it gets a final response (2xx, some 4xx ones).  It is not created on a
provisional response.

As far as intermediate proxies are concerned, the UAC will presumably send
a CANCEL when it hangs up (before receiving a final response); the CANCEL
should get propagated and acted upon by intermediate stateful proxies.

Oh, that brings up an interesting point:   If a stateful proxy
forked and one of the branches reached a stateless downstream server, when
the statful proxy gets a CANCEL, it will propogate the CANCEL to the state-
less downstream proxy.  What do statless proxies do on getting a CANCEL?  
Since they do not have state associated with the INVITE they received 
earlier, how do they handle the CANCEL?  Am I missing something obvious?

- 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: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2001 17:48:25 +0300

Hi,

>it gets a final response (2xx, some 4xx ones).  It is not created on a

I hate to bring it up again, but this is something we discussed in the
overlap dialing and send-INFO-before-the-final-response-has arrived
threads. Especially for PSTN GWs, I think we agreed that the UAS GW can
send a provisional response, WITH a Contact/R-R, when the initial INVITE
is received, if the UAC needs to send INFO (or another INVITE with
additional digits, if overlap dialing is used) BEFORE it has received
the final response.
 
>should get propagated and acted upon by intermediate stateful proxies.

Yes, but we are (at least at the moment) also allowed to send BYE
instead of CANCEL.

I don't see any reason why we can't use BYE instead of CANCEL, if we
want to terminate the call setup before the final response is received.
If people then use BYE to cancel other transactions, eg a re-INVITE
during a call (but they don't want to terminate the call) I think it's a
bug in their implementation. 

My personal view is that if I try to call someone, and put on the hook,
I should be able to send BYE no matter if I have received a 200 (or
another final response) or not.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 26 Apr 2001 10:29:46 -0500

[Trimmed the CC list]

Christer Holmberg wrote:
[...]
> threads. 

OK; my apologies.  I did not keep up with that thread.  But regardless,
the core RFC's behavior is to create a Route list on a 2xx response.

> >As far as intermediate proxies are concerned, the UAC will presumably 
> >send a CANCEL when it hangs up (before receiving a final response); the 
> >CANCEL should get propagated and acted upon by intermediate stateful 
> >proxies.
> 

And Jonathan's proposal was to do away with this behavior.  To the extent
that it makes the protocol simpler and less ambiguous, I think it is worth
working through this scenario only.

> bug in their implementation.

Incidentally, the fact that you would use a CANCEL to cancel a re-INVITE
(and not a BYE since it will tear the session down) begs for the same 
behavior for cancelling a pending (first) INVITE.  We should try to keep
the behavior as orthogonal as possible for first INVITEs and re-INVITEs.
 
> another final response) or not.

I don't see why you as a user cares if a BYE or a CANCEL is sent when you
hang up.  You as an implementor of the stack *know* that a final response 
has not yet arrived to the INVITE, so why can't you just send a CANCEL and 
not a BYE?

- vijay

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2001 19:02:20 +0300

Hi,

>the core RFC's behavior is to create a Route list on a 2xx response.

I know, and I think that that should be changed. I think it should be a
MUST to include it in a 2xx response, but that you MAY include it also
in the 18x provisonal responses (if one wants to support the features
related to overlap dialing, "early" INFOs, etc).
 
>the behavior as orthogonal as possible for first INVITEs and re-INVITEs.

Well, that depends on from what point of view you look at it. Yes, if we
are talking about cancelling INVITEs and re-INVITEs, which both happen
to be the same SIP method, why not use the same method (CANCEL) to
cancel them? However, if we are talking about terminating a call, why
not use the same method (BYE) regarless of if we have received a final
response or not?

>has not yet arrived to the INVITE, so why can't you just send a CANCEL and

Of course I can, but I don't see why you as a user cares if a BYE or a
CANCEL is received when I want to hang up :)

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? If there
are no really standard related problems by using BYE instead of CANCEL,
I think people using BYEs in a wrong way (ie by trying to cancel a
re-INVITE) should fix their implementations instead...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 26 Apr 2001 11:36:26 -0500

Christer Holmberg wrote:
[...]
> CANCEL is received when I want to hang up :)

I as a user (callee) don't, but I as a UAS stack implementor do.

To me, BYE has the semantics of "tear this session down"; sending a BYE to
a pending INVITE (in which case no session has been established yet*), does 
not make too much sense within the context of the sematics I outlined above.

* you may argue that early media, overlap signaling, etc. implies some sort 
  of a session, but a final 2xx response is what actually signifies the 
  acceptance of a session.  A compromise could be that if you support 
  100rel, then you can send a BYE to terminate early media streams, 
  otherwise use CANCEL (ugh! ugly)

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

> If there are no really standard related problems by using BYE instead of 
> CANCEL, I think people using BYEs in a wrong way (ie by trying to cancel a

This is an issue that the SIP WG must come to a consensus on and reflect the
final behavior (as non-ambiguously as possible) in the bis (and ensuing
RFC).  

Best regards,

- vijay

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2001 20:00:43 +0300

Hi,

>not make too much sense within the context of the sematics I outlined above.

I guess this is a matter on how we define a session, if "tear this
session down" is also 
valid for a session still not completely setup. For example, one could
argue that it is
partly setup from the UAC point of view, if he is ready to receive media
once he has
sent the INVITE... Anyway, I don't want to go in to those kind of
discussions - let's try
to solve this from a technical point of view instead :)
 
>  otherwise use CANCEL (ugh! ugly)

Maybe not... :)

BTW, 100rel is also another example why one could want to insert
Contact/R-R in the provisional 
response, for the PRACKs.
 
>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.
 
>final behavior (as non-ambiguously as possible) in the bis (and ensuing

I agree. Also, I think this is a relatively small issue, so we should
not spend that much time (why is everybody thinking of the overlap
dialing discussion?) on it.

Regards,

Christer Holmberg
Ericsson Finland