Subject: RE: [Sip] Forking: a modest proposal.

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2001 02:05:26 -0400

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Friday, July 06, 2001 9:30 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Sip] Forking: a modest proposal.
> 
> 
> Well, I've made the less modest proposal before that forking could be
> removed entirely from the specification. It seems to be an unpopular
> suggestion in some quarters, but I like to bring it up before 
> IETF meetings
> as a matter of tradition (and in hopes that someday certain 
> critical parties
> will agree).

Well, "some quarters" includes me, at least (maybe only me, but I hope not
:) ).

The reason its in the spec is, as Henning has pointed out, to avoid the
propagation of call state into the network. SIP was designed, first and
foremost, as a rendezvous type of protocol that could find a user at a
multitude of locations, and connect the caller to the called party across
different devices. In its role as a user discovery and connection protocol,
supporting the ability to reach a user at several devices is a big
reuqirement. Since we were also in the business of designing Internet
protocols, we wanted to push state to the edges, so that one could build a
system to do basic functions without all this cruft in the middle of the
network. Indeed, Jay has raised the flag on that in a separate note on this
thread. Removing forking from SIP means more of those B2BUAs. Lots more, I
think (in fact, pretty much all proxies will turn into B2BUAs as a default
mode). So, given its there already, I'd rather keep it, and instead, do a
far better job of explaining it in the spec. Its not really THAT hard, its
just that the spec is not exactly lucid on this, and many other, topics.

Now, back to the original question: to fork, or not-to-fork, non-INVITEs. I
agree with Christian, and I think there is consensus on this, that forking
of a non-INVITE only makes sense if (1) that request establishes no state at
the UASes, and the set of servers that are reached are homogeneous, so that
a response from any are equivalent, or (2) a 3-way handshake can be created
in some other way, specific to the method. Now, I think its fair to say that
the usefulness of a method that meets (1) is not too high, and worse, we
can't guarantee this property for all methods. So, indeed, the question is
whether we feel its useful to define, on a method by method basis (or
perhaps there is a general purpose solution lurking somehwhere?), a
three-way handshake to deal with forked non-INVITE.

But, if its something that has to be done on a method-by-method basis,
perhaps that belongs in the application space, using a B2BUA. Now, maybe
this is contradicting myself, since I just argued above that forking of
INVITE belongs in the protocol, and not in the application space. But,
forking of these non-INVITEs is presumably a much less common ocurrence, so
that putting it in the application space is not as much a burden.

I'll be sure to put this topic on my running open-issues list for London.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                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

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 13 Jul 2001 12:48:49 +0100

Jonathan wrote:
> Dean wrote:
> > IETF meetings as a matter of tradition (and in hopes that
> > someday certain critical parties will agree).
>

I'm not sure that it is possible to entirely remove it.
Isn't SRV(or whatever)-based server selection a sort of
forking?  I realise it's not quite the same, but there
are certainly elements of commonality.

[...]
> a response from any are equivalent,

Which is probably better served by SRV though, right?

> or (2) a 3-way handshake can
> be created
> can't guarantee this property for all methods.

Indeed.

The best justification for forking of a non-INVITE that
I ever heard was for the old CANCEL + BYE to quickly
tear down a call.  However, a BYE is pretty unlikely to
work if CPL appeared somewhere in the equation, and
this is only an optimisation, so....

> So, indeed, the question is

Well, I'm by no means an expert on sip-events, but
something very similar to what Adam proposed with his
SUBSCRIBE + immediate NOTIFYs seems an excellent starting
block.

Still, I'm not sure that this should be in baseline.
Since we suspect that it's far less often the case, it
would perhaps be more prudent to make this a draft a la
SUB/NOT that does delivers nothing in itself, but rather
provides a useful generic framework for other drafts.
(Is there chance that SUB/NOT would become dependent
in such an instance?  This might cause real pain time-
wise.)

> that putting it in the application space is not as much a burden.

I think I'm ambivalent.

 - Jo.