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

From: "Christian Huitema" <[email-masked]>
Date: Mon, 2 Jul 2001 11:20:57 -0700

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: [email-masked]
Date: Mon, 2 Jul 2001 13:58:02 -0500

> From: Christian Huitema [mailto:[email-masked]]
> 

The problem, of course, with requiring a three-way handshake involving
the response to the method is that forking proxies drop all but the first
response (except for INVITEs), so sending a forward indication to
complete the handshake is impossible. Any non-INVITE three-way handshake
which will survive forking must be something like a request in the
forward direction, a request in the backwards direction, and a response
to the second request.

> requested before any notification is sent.

I don't think it's the notification you're worried about; as you just
stated, NOTIFY is one of a class of "methods that... have no side effect."
Your concern is installation of long running state at the notifier node;
my proposal to the forked SUBSCRIBE issue can be implemented in such a way
that such state is not created.

> We could possibly achieve

As I pointed out above, using a response code for this isn't possible,
since only the first response survives the forking proxy.

However, if I take the intention of your statement instead of the
implied implementation, this is fundamentally what I have been proposing
all along: I send a SUBSCRIBE; the response is merely for reliability. I
then receive multiple NOTIFYs. If I am willing to have these subscriptions
outstanding, I send a 200 class response; it's then my responsibility to
make sure they each get updated as appropriate. If I want them not to
exist, I send a 400 class response (nominally a 481).

There's your three way handshake: SUBSCRIBE/NOTIFY/200. It works very
elegantly.

But there are people who counterargue that, even though this is
a technically feasible solution (and, in fact, one we will have to
outlaw by fiat if we don't want it to happen, since we basically
get it for free), there are some philosophical problems yet to be
solved about having multiple subscriptions outstanding.

I'll admit that, in certain circumstances, this might not make sense;
those packages can dictate that all but one NOTIFY be answered with
a 481. I argue that this mechanism can be useful in other circumstances,
and disallowing it merely makes the protocol less flexible.

My intention in this thread wasn't to fight this battle; in fact, my
intention was explicitly to avoid it. I believed that all parties
involved had an understanding of the current situation and viewpoints,
and that we could remove the problem instead of solving it. If that
isn't the case, we can take the philosophical discussion of whether
forked subscriptions are legal on the SIP events list.

/a