Subject: RE: [SIP] a stupid question on 3way handshake

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 19 Nov 2000 17:04:02 -0500

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Sunday, November 19, 2000 4:42 PM
> To: Vijay Gurbani
> Cc: Billy Biggs; Jonathan Rosenberg; SIP List
> Subject: Re: [SIP] a stupid question on 3way handshake
> 
> 
> Vijay Gurbani ([email-masked]):
> 
> > >   The behavior is the same as for INVITE requests.  If you receive
> > > multiple 200 OK responses, you MUST forward them up.  That has
> > > been the consensus from everyone I've ever spoken with.
> > 
> > Hmmm, let's see...the RFC does indicate that a forking proxy MAY
> > terminate pending INVITE requests on other branches when it 
> gets a 200
> > OK for at least one branch.  Following this logic, it 
> proxies the 200
> > OK it got _first_ up- stream and sends a CANCEL on all 
> other branches.
> > Say it gets another 200 OK (INVITE) after it has send a CANCEL; the
> > proxy can rest assured that the CANCEL and the 200 OK (INVITE)
> > "crossed each other on the wire."  Thus it can locally ACK 
> the 200 OK
> > (INVITE) and then send a BYE on that branch.
> 
>   Sorry, but that would be really really evil.

Well, its not evil, but its not correct. Proxies don't initiate requests on
their own, excepting the "special" ones of BYE and ACK (and for ACK, its
only for non-200 responses. Proxies don't ACK 200 responses, only the UA
does).

>   The text reads that the proxy MUST not ACK the response locally to
> protect the UA.  That is for any 2xx responses received.  
> There might be
> reasons why the proxy would choose not to cancel the other 
> branches (if
> there are no other branches?  if the other branch is a call 
> logger?  who
> knows), and I think that is why the MAY is there.

Yes. In fact, some time back, one of the request-disposition parameters in
the caller preferences specification was something like "don't cancel". The
point is that this is good for requests where you want to reach everyone,
rather than just the first person to answer.

> 
>   This behavior is the same for non-INVITE requests.  I guess it could
> be stated more explicitly though.

I agree that forking behavior for non-INVITE is not well specified enough.
In fact, you previously write:

> > Except when multiple downstream UASes return a "best" response to a
> > forked non-INVITE request.  A while ago, we had a similar dialog
> > regarding the forking of a non-INVITE request like OPTIONS. 
>  A forking
> > proxy would send the initial OPTIONS to several branches downstream;
> > suppose 2 branches returned a 200 OK.  Then the proxy would send the
> > first 200 OK received up- stream; absord the second 200 OK and send
> > CANCEL on the remaining branches.  Or the proxy could simply send
> > multiple 200 OKs upstream and hope the UAC can sort them 
> out and pick
> > the "best".
> 
>   The behavior is the same as for INVITE requests.  If you receive
> multiple 200 OK responses, you MUST forward them up.  That 
> has been the
> consensus from everyone I've ever spoken with.

I'm sorry, that is not correct.

A proxy cannot forward multiple non-INVITE responses upstream.

A proxy cannot forward multiple non-INVITE responses upstream.

Just to be sure:

A proxy cannot forward multiple non-INVITE responses upstream.

I'll put a FAQ entry in there too.

It just doesn't work, plain and simple. The reliability mechanism as defined
just doesn't work for multiple responses, and there is no way to fix it
without pretty much adding in an ACK for non-INVITE requests. 

Billy also writes:
> > [...] Forking of non-INVITEs is therefore useful for 
> requests where it
> > isn't important to know how many places received the request; simply
> > knowing the best response is adequate. [...]
> > 
> > I would argue that SUBSCRIBE meets this criteria as well. The caller
> > really doesn't care who many servers are going to be handling the
> > subscription. So long as some server accepts it, and generates
> > notifications for it, thats all that matters.
> 
>   It matters when trying to unsubscribe.  To be intelligence-
> at-the-edges correct, an unsubscribe should be sent within 
> the call-leg
> created by the original SUBSCRIBE.  However, to be forking-safe, the
> unsubscribe should be sent to the orignal address which was subscribed
> to, without a tag.

Actually, I thought about this some more, and am not so sure that forking of
SUBCSRIBE is such a great idea. THe problem is not just unsubscribes, but
refreshes. One of the subscribe responses will come back, and it will likely
be record-routed. As a result, subsequent subscribes will go to just the one
server whose 200 response was forwarded upstream. Now, thats OK, but only if
the multiple servers are all *equal*, that is, each is providing
notifications for exactly the same set of devices for a particular
presentity. 

So, to modify my description somewhat, "forking of non-INVITE requests works
well when the client doesn't care from whom the response comes, and when the
services provided by each of the servers that receives the request is
identical."

-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.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Sun, 19 Nov 2000 16:28:03 -0600

Jonathan Rosenberg ([email-masked]):

> [...] Proxies don't initiate requests on their own, excepting the
> "special" ones of BYE and ACK (and for ACK, its only for non-200
> responses. [...]

  When would a proxy ever send a BYE?

> A proxy cannot forward multiple non-INVITE responses upstream.

  I'm ok with this as long as it's clearly specified.

> Actually, I thought about this some more, and am not so sure that
> forking of SUBCSRIBE is such a great idea. THe problem is not just
> unsubscribes, but refreshes. One of the subscribe responses will come
> back, and it will likely be record-routed. As a result, subsequent
> subscribes will go to just the one server whose 200 response was
> forwarded upstream. Now, thats OK, but only if the multiple servers
> are all *equal*, that is, each is providing notifications for exactly
> the same set of devices for a particular presentity. 

  Similarily, if I get a NOTIFY and I don't recognize the tags, I can't
accept it and then unsubscribe since I don't have the route information
(nor do I have a Contact address, since NOTIFY can't have a Contact. ??)
The only sane thing to do is return a 481 and have that cancel the
subscription.

  It would be wrong to ask that proxies not fork SUBSCRIBEs, or to
suggest that SUBSCRIBE should always put in some 'don't-fork' caller
preferences parameter.  Forking of SUBSCRIBEs is useful.  For example,
subscribing to my voicemail status without using caller-preferences: the
SUBSCRIBE forks to all my phones and my voicemail, and hopefully only
the voicemail will accept it.

  Aside: Yet another reason you shouldn't always use the same local tag:
         You send a SUBSCRIBE and it comes back to yourself. ;-)
         Please take this error-prone suggestion out of bis.

  So, I guess we could suggest that when designing a SUBSCRIBE/NOTIFY
system, make sure that the URIs used don't fork to multiple subscription
handlers which handle the same event?

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 20 Nov 2000 10:46:35 -0000

Jonathan Rosenberg wrote:
>
> Well, its not evil, but its not correct. Proxies don't initiate 
> requests on their own, excepting the "special" ones of BYE

Do you mean CANCEL?

> So, to modify my description somewhat, "forking of non-INVITE 
> requests works well when the client doesn't care from whom the
> response comes, and when the services provided by each of the
> servers that receives the request is identical."

I'm playing Devil's Advocate here, but isn't that better
achieved by SRV?

I like forking -- it's very powerful; however, I might be
inclined to suggest that we warn in bis that proxies
shouldn't be too keen to fork on non-INVITE requests, since
in a number of cases, it's probably not going to be so
helpful.

Cheers,

 - Jo.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 20 Nov 2000 12:23:57 +0100

> in a number of cases, it's probably not going to be so

Hmmm. If it's OK to register multiple SIP addresses at a registrar and
have a proxy fork INVITEs to those addresses it pretty much follows that
OPTIONS, SUBSCRIBE, and other requests must also be allowed to fork in
order to be useful.

Anders

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 20 Nov 2000 11:38:05 -0000

> OPTIONS, SUBSCRIBE, and other requests must also be allowed to fork in

I think it's OPTIONS that bothers me the most.  You try to gather
some information on the UA you're about to call with an OPTIONS,
and it forks.  The result of the OPTIONS could be completely
useless, because it may well not be from the UA that you would
actually have ended up talking to if you'd done an INVITE instead.

I don't know -- maybe it's a silly point, but forking just seems to
slightly spoil OPTIONS.

Okay, so maybe Billy's suggestion was better: suggest sequential
forking as nominal behaviour for non-INVITE.  This doesn't help
at all with the OPTIONs case, but it's probably better for
things like BYE, for instance.

 - Jo.

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 09:25:42 -0600

Jo Hornsby ([email-masked]):

> forking as nominal behaviour for non-INVITE.  This doesn't help at all
> with the OPTIONs case, but it's probably better for things like BYE,
> for instance.

  That's funny, because it seems completely reasonable to me to parallel
fork a BYE.

  You would get a BYE at a proxy when the stupid UA at the other end
didn't put in a Contact.  You want to shut down the call quickly, so you
parallel fork to all registrations knowing that all but one will return
a 481.

  So much for my suggestion.