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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 3 Jul 2001 08:53:37 -0700

> > > 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.
> >
> > This is not quite true. If you require a 3 ways handshake, then the
> > forking proxy will only carry the first positive response, and will
> > reject the other ones; but in a 3-ways handshake mode, it should
reply
> > with a "cancel" if it drops a positive response.
> 
> What? You lost me there. Who is sending the cancel, and to whom?
> The proxy to the subscriber? The proxy to the node receiving the
> SUBSCRIBE request? The node receiving the SUBSCRIBE request to the
> proxy? The subscriber to the proxy? I can't envision any scenario
> in which this makes sense without some radical changes to the way
> that SIP works.

In the case of "subscribe", a proxy that drops a definitive & positive
response is doing something harsh to the responding user agent. The UA
has installed state as a result of the SUBSCRIBE, and by dropping the
response the proxy is making sure that this state will become useless.
It seems that sending back some form of cancellation would be
appropriate.

Indeed, as you point out, we cannot expect all proxies to be modified to
a new behavior. This is why we have to have an end-to-end mechanism that
confirms that a subscription is valid, the equivalent of an ACK. In the
absence of such confirmation, the presentity can clear the subscribe
"session."

Indeed, the three-ways handshake is only needed if we want to ensure
that we have exactly one respondent for any given subscribe session.
Another possibility is to leave a session active on every UA that sent a
positive response. The watcher will receive several NOTIFY, from various
presentity, and may be able to sort it out.

On the other hand, I don't believe that just banning fork is an option.
Fork may happen "naturally", e.g. if an acknowledgement is lost, the
subscribe is repeated, and a stateless proxy routes the repeated
subscribe to a different presentity. Fork also happens naturally if the
subscribe request is sent over a multicast channel. We must have a way
to go from there to a deterministic behavior.

-- Christian Huitema

_______________________________________________
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: Tue, 3 Jul 2001 11:25:58 -0500

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

You can implement it in such a fashion that the session isn't
"active" until the first (required, immediate) NOTIFY is
answered with a 200 class response. It **IS** a three-way
handshake.

> to go from there to a deterministic behavior.

The major difference between your "natural" forks and an intentional
fork is that *all* responses to your "natural" forks will be
received by the node that sent the request (unless suppressed by
the remote end, in which case there is no problem); intentional forks
will go through a proxy which drops all but the first positive
response.

/a