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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 27 Apr 2001 09:23:50 -0700

Just thought I'd butt in. 

While we are at it: we should put into the bis that a UA or proxy MAY
receive multiple 200 OK's and really MUST be able to handle them. 

Consider a forking proxy where two or more branches pickup at the same time
(eg both connected to automated answering services). Both branches will send
200 OK's and neither can be CANCELLED by the forking proxy. So the bis text
should describe the situation and the fact that the proxy MUST pass both 200
OK's back to the UA (violating the rule that the proxy can only return a
single final response). The UA should send an ACK & BYE to the 200 OK callee
it does not want. This should also be described in the bis. 

[In my mind it would make things cleaner if the proxy just BYE'd the
subsequent 200 OK's but I'm sure that won't be a popular suggestion given
that proxies aren't supposed to send BYE's. On the other hand, they're not
supposed to send multiple final responses either and I think that is a
greater evil.]

Regards,

Robert.

-----Original Message-----
From:	Vijay Gurbani [mailto:[email-masked]]
Sent:	Friday, April 27, 2001 4:48 PM
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
-- 
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

_______________________________________________
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 12:21:50 -0500

> "Fairlie-Cuninghame, Robert" wrote:
> 

Welcome to the party :-)

> Consider a forking proxy where two or more branches pickup at the same 
> time (eg both connected to automated answering services). Both branches 
> will send 200 OK's and neither can be CANCELLED by the forking proxy. 

Actually, they can be CANCELled by the proxy, except the CANCEL has no
effect on the UAS since it has already generated a final response.

> So the bis text should describe the situation and the fact that the proxy 
> MUST pass both 200 OK's back to the UA (violating the rule that the proxy 
> can only return a single final response). 

The bis does attempt to describe this (in a somewhat obfuscated manner -- 
you have to read between the lines).  It makes a distinction between 2xx 
responses to INVITE and non-2xx responses (see Section 12.4, -02 bis).  2xx 
responses (as many as the proxy sees) to INVITEs MUST be forwarded upstream 
immideately.  On the other hand, a proxy returns a single (best) final 
response IFF ALL the branches have reported a final response AND none of 
these responses was a 2xx response.

> The UA should send an ACK & BYE to the 200 OK callee it does not want. 
> This should also be described in the bis.

The -02 bis has text to this effect in Section 16.5 (not where you would
normally look for it).  For the PDF version, see page 106 - towards the
bottom. 

> that proxies aren't supposed to send BYE's. 

I won't even touch this :-)

- vijay