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

From: "Sean Olson (EUS)" <[email-masked]>
Date: Mon, 2 Jul 2001 14:01:46 -0500

Hmmm. It would sound like we have a few options
for forking of a non-INVITE:

1) Disallow it

This seems to be easiest, even if there are potential
benefits to forking non-INVITEs. It certainly makes
things easier for forking proxies.

2) Wrap it in a INVITE "signalling session"

ala MESSAGE. This allows us to find a path to a
"single best" destination (first come, first serve)
By wrapping it in INVITE, we allow multiple destinations
to actually answer. There is a small issue here with
overhead in signalling.

3) Describe the semantics of forking of a non-INVITE
   for each possible extension

We hack a solution together specific to each extension.
Highly undesireable.

4) Create a PROBE method that allows us to find
   a single threaded path through. Similar to (2) above,
   but only one party could answer. PROBE == OPTIONS provided
   we allow forking of OPTIONS.

This is ugly. Just listed for completeness.

I prefer (1) or (2), leaning towards (1). I don't think
adding three-way handshakes to other extensions is the
way to go. Unless people want to allow ACK for non-INVITEs 
(no flames please, just a bit of humor)

/sean

>-----Original Message-----
>From: Christian Huitema [mailto:[email-masked]]
>Sent: Monday, July 02, 2001 1:21 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: RE: [Sip] Forking: a modest proposal.
>
>
>The problem is not so much INVITE vs. SUBSCRIBE than a classic case of
>state management. The reason INVITE supports forking is the three ways
>handshake in the INVITE/200/ACK sequence, which allows for cancellation
>of branches that are not selected. We can only subscribe forking in
>methods that either have no side effect (e.g. Notify) or that include a
>three ways handshake.
>
>There are quite a few reasons to support forking -- think for 
>example of
>doing discovery through a multicast channel. But we must make sure that
>if a SUBSCRIBE request is multicast or forked, a three ways 
>handshake is
>requested before any notification is sent. We could possibly achieve
>that by having a specific acceptation code, e.g. "I received a forked
>subscribe, I am ready to serve you, but please confirm first."
>
>-- Christian Huitema
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Monday, July 02, 2001 9:45 AM
>> To: [email-masked]
>> Subject: [Sip] Forking: a modest proposal.
>> 
>> I'm putting together the SUB/NOT draft (we should go into nits
>> on Monday), and am currently wrestling with the issue of forking.
>> 
>> I have what I think is an elegant solution, given the immediate
>> NOTIFY mechanism that we have agreed on. Certain camps have 
>objections
>> to this mechanism, and thinks that all but the first SUBSCRIBE should
>> be made to fail (by sending a 400 class response). I don't see this
>> difference of opinion as intractable, but it is something that will
>> take a considerable amount of time (discussion, work, etc) to reach
>> consensus.
>> 
>> On reflection, I realize that this entire situation just highlights
>> a thorn we've had in our paw the entire time.
>> 
>> Given that all transactions complete (basically) immediately (with
>> the exception of INVITEs), forking *any* non-INVITE request is just
>> a race waiting to happen. It usually just leads to heartburn when
>> you attempt to analyze how it's going to work with non-INVITE methods
>> (as in the SUBSCRIBE example).
>> 
>> Since there seems to be a general feeling that all but the first
>> received request should "fail" in some general sense (usually by
>> the request initiator not finding out about the response), I'd
>> like to float a proposal:
>> 
>> Deprecate forking of non-INVITEs.
>> 
>> Despite my tongue-in-cheek subject line, I'm serious.
>> 
>> SIP is not going to Draft Standard this time around, so maintaining
>> absolute compatibility with RFC 2543 isn't strictly required. No one
>> has come up with a useful application of forking non-INVITEs (except,
>> arguably, my proposal that a forked SUBSCRIBE can install several
>> subscriptions, with the subsequent NOTIFY messages establishing the
>> legs, routes, and contacts as necessary). Forking non-INVITEs adds
>> complexity to the protocol, extra work to all extensions, and
>> headaches all around. And as long as people insist that 
>nothing useful
>> can come from forking anything but an INVITE, there is no gain to be
>> had by leaving this "feature" in the protocol.
>> 
>> As long as it is understood at a general protocol level that forking
>> of non-INVITEs is disallowed, I have no problem rejecting the
>additional
>> NOTIFY legs we find out about. If we continue to pretend that forking
>> of non-INVITEs is a useful concept, I can't see the logic behind
>refusing
>> to allow successful forking of SUBSCRIBEs.
>> 
>> Comments, etc, encouraged -- even if just to voice assent.
>> 
>> /a
>> 
>> 
>> _______________________________________________
>> 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: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Tue, 10 Jul 2001 15:14:56 -0600

> Of course, *that* problem could be solved by deprecating B2BUAs, which
are 
> truly and deeply evil IMHO....  Watching the list from afar as I do, I

> observe that there is a significant and growing temptation to fall
back on 
> doing everything via B2BUAs now, less and less of a discipline to
force
> things into the proxy/server model, with the resulting behavior / 
> architecture starting to feel more and more like Megaco.  This is a
bad thing.

While I sympathize with your concern, I think we have painted ourselves
in a 
corner with respect to B2BUAs. There are a lot of bridging and 4+ party 
conferencing scenarios that simply aren't workable in SIP without a
B2BUA. 
Regardless, even if we did depreciate them, there isn't much we could do
to 
prevent them from being implemented because a B2BUA is still a valid
user agent.
The key to preventing SIP from becoming Megaco isn't banishing B2BUAs,
but rather
it is ensuring that clients remain clients and not slaves. 

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

---

From: Igor Slepchin <[email-masked]>
Date: Tue, 17 Jul 2001 14:16:31 -0400

Well, redirect is not as perfect as it may first sound. It has at least the
following two problems:

1. Increased call setup latency (the redirect response has to travel all the
way back to the client before it can be acted upon)

2. It's not always possible to have the call redirected. For example, in ACD
environment the only address available to the UAC should be
sip:[email-masked]; you would not want to give away individual
addresses of your customer reps by sending them back in a 3xx response.
Besides, those addresses may not even be reachable outside of company.com
network.

Thank you,
Igor Slepchin

-----Original Message-----
From: Jay Batson [mailto:[email-masked]]

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:

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:

> 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 
-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:[email-masked]
781-938-5306 (office)