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

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Jul 2001 11:05:48 -0400

Jonathan,

If you really want to push the call state to the edge, then there should
be forking redirect servers, not proxies.  If forking is needed, the
associated information should be sent back to the UAC and let it do the
forking of requests and handling responses.  Some of the previous
discussion indicates ambiguity over whether the forking proxy is handling
the transaction responses or the UAC.  Doesn't seem clean to
me.

The reason for the forking is service related, not session setup related
and as such you open pandoras box to other service-related
"cruft" being introduced to the base protocol.  It seems
that the main advance of SIP over legacy protocols was that adherence to
general purpose mechanisms that are not service specific.  Where the
legacy systems made a distinction between basic call setup and
supplementary services, they did not keep the protocol elements
associated with each separate.

Now, it appears that SIP has addressed the basic session setup elements
and is facing the same issues of how to do more advance services as
before.  Question is, do you start adding protocol elements that are
needed by only certain classes of services?  After that, when do you
stop?  Is there another way to handle service-specific data that is
peculiar to an application (e.g. supplementary service) but not general
to all sessions?

Mike

At 02:05 AM 7/11/2001 -0400, Jonathan Rosenberg wrote:

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

_______________________________________________
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: Jay Batson <[email-masked]>
Date: Wed, 11 Jul 2001 17:18:46 -0400

Very thoughtful response, Michael.

I find it interesting that server companies aren't making much more 
extensive use of redirect.  It scales well, it keeps (potentially 
unnecessary) servers out of a long list of Route-Recorded waystations that 
delay message delivery.  Etc.

I suspect it is because of business issues, not technical issues.  If one 
is building a server, one needs insure that the server adds lots of value 
and stays "in the loop" sufficiently in order that that server pulls in 
enough revenue....

Especially if you don't make clients/UAs as well.  Which is why folks like 
Sylantro, Broadsoft, and others (whom I'm not letting see this by virtue of 
*not* copying the list) are basically *not* implementing even Proxies, but 
full, big-honkin B2BUAs as their core architecture (I think).

There is, in the product world, a deep temptation to be in the control loop 
wherever possible -- vs. wherever necessary....

Cheers
-jb

At 11:05 AM 7/11/01, you wrote:
>the transaction responses or the UAC.  Doesn't seem clean to me.
>
>and as such you open pandoras box to other service-related "cruft" being 
>introduced to the base protocol.  It seems that the main advance of SIP 
>over legacy protocols was that adherence to general purpose mechanisms 
>that are not service specific.  Where the legacy systems made a 
>distinction between basic call setup and supplementary services, they did 
>not keep the protocol elements associated with each separate.
>
>peculiar to an application (e.g. supplementary service) but not general to 
>all sessions?
>
>Mike
>
>
>> > From: Dean Willis [mailto:[email-masked]]
>> > Well, I've made the less modest proposal before that forking could be
>> > removed entirely from the specification. It seems to be an unpopular
>>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,
>>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
>>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
>>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
>_______________________________________________ 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

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:[email-masked]
781-938-5306 (office)

---

From: Jay Batson <[email-masked]>
Date: Wed, 11 Jul 2001 17:37:58 -0400

Well, that email wasn't, in fact, actually intended to go to the list.  In 
fact, it was plain and simple bad form to *NOT* make my comments publicly 
in the first place, vs. making them instead in a private email.  For this I 
dutifully suck up to, and offer my apologies to our buddies at Broadsoft 
and Sylantro.

Despite this, I stand by my observations on the use of B2BUAs, redirect 
servers, etc. in my prior email.  I know that, as far as I am concerned, I 
don what little bit of Engineering Hat I have left to me when I contribute 
to this forum.  In that role, I use the list to speak my mind -- without 
particular regard to how it might sound to our partners.

I simply remind our partners to remember that I *do* wear a different hat 
-- a business / strategic relationship hat.  And in that role, I remain 
fully committed to cause Pingtel to work hard to grow this market with 
*all* SIP product vendors -- technical differences aside.

On a continuing basis, though, I trust that all of us -- myself included -- 
can feel free to make use of this kind of forum to have healthy 
disagreements about things *on the way to* working together.

Cheers
-jb

At 05:31 PM 7/11/01, you wrote:
>Jay Batson wrote:
> > unnecessary) servers out of a long list of Route-Recorded waystations
> > that delay message delivery.  Etc.
> >
> > I suspect it is because of business issues, not technical issues.  If
> > one is building a server, one needs insure that the server adds lots
> > of value and stays "in the loop" sufficiently in order that that
> > server pulls in enough revenue....
> >
> > Especially if you don't make clients/UAs as well.  Which is why folks
> > like Sylantro, Broadsoft, and others (whom I'm not letting see this by
>
>Actually, you did copy [email-masked] - unless this was meant as a joke...
>
>
> > virtue of *not* copying the list) are basically *not* implementing
> > even Proxies, but full, big-honkin B2BUAs as their core architecture
> > (I think).
> >
> > There is, in the product world, a deep temptation to be in the control
> > loop wherever possible -- vs. wherever necessary....
> >
> > Cheers
> > -jb
> >
> > > If you really want to push the call state to the edge, then there
> > > should be forking redirect servers, not proxies.  If forking is
> > > needed, the associated information should be sent back to the UAC
> > > and let it do the forking of requests and handling responses.  Some
> > > of the previous discussion indicates ambiguity over whether the
> > > forking proxy is handling the transaction responses or the UAC.
> > > Doesn't seem clean to me.
> > >
> > > The reason for the forking is service related, not session setup
> > > related and as such you open pandoras box to other service-related
> > > "cruft" being introduced to the base protocol.  It seems that the
> > > main advance of SIP over legacy protocols was that adherence to
> > > Now, it appears that SIP has addressed the basic session setup
> > > elements and is facing the same issues of how to do more advance
> > > services as before.  Question is, do you start adding protocol
> > > elements that are needed by only certain classes of services?  After
> > > that, when do you stop?  Is there another way to handle
> > > service-specific data that is peculiar to an application (e.g.
> > > supplementary service) but not general to all sessions?
> > >
> > > Mike
> > >
> > >
> > > 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
> >
> > -------------
> > PingMe!
> > Jay Batson
> > CEO
> > Pingtel Corp.
>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.