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

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 25 Apr 2001 13:22:52 -0500

>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)?

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

/sean

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Thu, 26 Apr 2001 12:06:38 -0500

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

Is there any reason why the stateless proxy would do something
other than forward the CANCEL request? I don't understand
what the alternative might be.

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

/sean
--
Sean Olson <[email-masked]>
Ericsson Inc.

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 27 Apr 2001 10:02:02 -0500

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

/sean

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 27 Apr 2001 11:02:22 -0500

Not mentioning it is not sufficient. 
If you don't want to allow this, then
add a "MUST NOT" regarding sending a BYE
before the INVITE transaction has completed.

/sean

>-----Original Message-----
>From: Vijay Gurbani [mailto:[email-masked]]
>Sent: Friday, April 27, 2001 10:48 AM
>To: Jonathan Rosenberg
>Cc: 'Sean Olson (EUS)'; [email-masked]'
>Subject: Re: [SIP] Further editorial nit in the bis draft
>
>
>Jonathan Rosenberg wrote:
>[...]
>> sean>This is not what Jonathan is saying. He is referring to the
>> sean>possibility of sending a BYE *instead* of a CANCEL, not sending
>> sean>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. 
>
>Right on!
>
>I could spend some time and come up with time-line diagrams if 
>anyone is
>interested (or if you want them to go in the -04 bis).  But it 
>is simple 
>really: If after sending CANCEL, a UAC gets a 200 OK (INVITE), 
>ACK it and 
>send a BYE (remember: CANCEL has no effect on a UAS state 
>machine if it has 
>already sent a final response).
>
>If after sending a CANCEL, a UAC gets a non-2xx response to the INVITE,
>just ACK it; no need to send the BYE -- session was never established.
>
>> 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.
>
>Right.  We should not even mention it; a MAY will lead to the 
>same ambiguity 
>we are facing now.
>
>Regards,
>
>- vijay
>--