Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model.

["Ian Elz" <[e-mail]>]

Adam.

I understand that most of what I commented on was included in RFC3265.
The problem with RFC3265 was that a lot of the detail was missing. The
concept of the new draft is to correct those omissions and to simplify
and clarify what was included in RFC3265.

RFC3265 does not include anything about how the subscriber (I will use
subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and
NOTIFY.) obtains his route set. If the new RFC does not explicitly state
that the subscriber route set is obtained from the Record-Route header
contained in the NOTIFY then RFC3261 applies the subscriber route set is
obtained form the 2xx to the SUBSCRIBE. This will make for an
interesting dialog if the 2xx to the SUSCRIBE is never received.

Specific responses in-line [ige].

Ian

-----Original Message-----
From: Adam Roach [mailto:[e-mail]]
Sent: 14 August 2009 20:57
To: Ian Elz
Cc: [e-mail]; Christer Holmberg
Subject: Re: draft-roach-sipcore-rfc3265bis-00

Ian Elz wrote:

> Now a more complex issue:
>
> You are proposing that the first NOTIFY establishes the SUBSCRIBE
> dialog. What impact does this have on the establishment of the route
> set at the UAC as defined in RFC3261?
>

 From a practical perspective, it's the same as what we have in 3265 --
except that it's a little easier to implement at the subscriber.

Keep in mind that 3265 describes dialogs being established by NOTIFY
requests -- this is not new in the 3265bis draft. The only difference in
dialog establishment is that we're removing the ability for a SUBSCRIBE
200 response to create a dialog.

This is an extremely important point, so I'll repeat it: this change is
not *ADDING* new behavior. It is *REMOVING* unnecessary behavior that
has been shown to cause problems.

[ige] I understand that you are not adding any functionality which is
different from RFC3265. The problem is that what was in RFC3265 changed
the actions specified in RFC3261 but did not state how they hade been
changed. This is part of what caused the problems in RFC3265. The
updated RFC MUST include this detail or we will end up with inconsistent
implementations.

> Normal RFC3261 has the UAS route set taken from Record-Route in the
> initial request. The UAS then copies the Record-Route back into the
> 2xx response (or reliable provisional response) which is then used by
> the UAC to set its the route set. This ensures that the route sets in
> the UAC and UAS align.
>
> Section 4.3 of the draft proposes that the initial SUBSCRIBE has the
> normal Record-Route which establishes the UAS route set but that the
> NOTIFY also has Record-Route performed by proxies. This leaves the
> possibility that the route set at the UAC and UAS may not align.
>

Actually, it doesn't. As long as proxies follow the guidance in 4.3,
then the route set in the SUBSCRIBE will be precisely identical to the
route set established by the NOTIFY. Because of the Record-Route in the
SUBSCRIBE, the NOTIFY will contain Route header fields that guarantee
that the NOTIFY traverses the proxies that Record-Route the SUBSCRIBE.
These proxies, by the normative requirement in 4.3, will then
Record-Route the NOTIFY, which guarantees that the route set in the
subscriber matches that of the notifier.

If you think I'm confused about this in some way, please describe a
concrete set of compliant proxy behaviors that can result in an
asymmetrical route set, preferably using a sequence diagram.

[ige] The problem we have is backward compatibility. If the subscriber
and notifier support the proposed new functionality but an intermediate
proxies does not then this may result in an asymmetric route sets. The
SUBSCRIBE will be seen by the proxy as a dialog initiating request and
will add itself to the Record-Route in the SUBSCRIBE. When the NOTIFY is
handled however there is no requirement in RFC3261 to include itself in
the Record-route as RFC3261 is explicit in the fact that any
Record-route added to the NOTIFY will NOT update the route set. Thus
asymmetric route sets will result. This will result in SUSCRIBE messages
being passed via different proxies than the NOTIFY with the result that
some proxies will see a subscription termination resulting from a
SUBSCRIBE but not from a NOTIFY or as the result of a rejection of a
NOTIFY.


> I also have a concern as to what will happen with the route set if the
> SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also
> includes a Record-Route. Which one is used to establish the route set
> at the subscriber. Do we take the one which arrives first? Do we take
> the one which arrives second? There is no issue if they are the same
> but what if they differ?
>

As I mention above: In a compliant system, they can't differ. However,
as we all know, systems don't always do the right thing. SBCs can tinker
with Route/Record-Route in ways that create asymmetric route sets, even
for normal INVITE/200/ACK transactions.

With 3265, if there *were* a difference, your question is highly
relevant: the answer to "but what if they differ?" was a resounding "I
have no clue!"

Which is one of the key reasons why we made this change.

In 3265bis, the answer is straightforward: since the NOTIFY establishes
the dialog, the NOTIFY is where the route set comes from.

Really, the 200 response is kind of a throw-away message anyway. Even
with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it
establishes two dialogs, I'm going to have to take the route set for at
least one of the dialogs from the NOTIFY -- so I may as well always take
it from the NOTIFY.

[ige] Agree that with forking only a single 200 OK will mean that NOTIFY
will be used to establish other SUBSCRIBE dialogs. This appears to be an
issue with forking and RFC3261 where only a single 2xx response is
returned. If I subscribe and multiple nodes accept the subscription e.g.
I subscribe to the dialog-event mechanism for all dialogs for a user,
why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to
establish multiple dialogs and to set up the route sets for each of
those dialogs.

> Should there be a requirement that proxies MUST include themselves in
> the NOTIFY Record-Route if they included themselves in the SUBSCRIBE
> Record-Route and to exclude themselves in the NOTUFY if they were not
> in the SUBSCRIBE Record-Route.
>

That's certainly the intention of 4.3. It's a bit tortured to imagine
that a proxy might be on the path of the NOTIFY without having
Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting
Record-Routing a NOTIFY unless you've also Record-Routed the associated
SUBSCRIBE; I'll add:

  Proxies that did not add a Record-Route header field to the
  initial SUBSCRIBE request MUST NOT add a Record-Route header
  field to any of the associated NOTIFY requests.

[ige] But there is nothing to indicate that proxies which did add
themselves to the Record-Route in the SUBSCRIBE MUST add themselves to
the Record-Route in subsequent NOTIFY requests for the same dialog (?).
This does not remove the compatibility issue where the proxy does not
support the updates included in the draft.


> If we are to use the Record-Route in the NOTIFY then the draft should
> explicitly state what should happen at the subscriber end. Should the
> 2xx response to the NOTIFY include a copy of the Record-Route taken
> from the NOTIFY?
>

It doesn't matter.

[ige] If you don't include normative text which specifies that the route
set is established from the Record-Route in the NOTIFY then RFC3261
applies and the route set at the subscriber is obtained from the 2xx to
the SUBSCRIBE.

> What does the notifier end do if it then receives this Record-Route?
>

It ignores it. There is no way to change a dialog route set (other than
the remote target) mid-dialog.

[ige] Is what you are saying is that for one dialog you may take the
route set from the 2xx to the SUBSCRIBE, depending upon whether the
NOTIFY or 2xx arrives first, and for other dialogs it is taken from the
NOTIFY. In the forked case you may then end up with one symmetric route
set and multiple asymmetric route sets; i.e. all the proxies may see
subsequent SUBSCRIBE requests for one dialog but not for the others. I
am not sure what this will do to the proxies handling of the dialogs if
anything but we need to consider it to be sure.


> There is one more related issue:
>
> What happens if the 2xx to the SUBSCRIBE transaction is never received
> by the subscriber. Based upon the non-INVITE client transaction in
> RFC3261 the termination of the transaction upon expiry of Timer F will
> inform the TU. In normal cases the TU would terminate the transaction
> and drop the dialog In this case if the NOTIFY has been received
> before the 2xx then this should be treated as the 2xx from the
> transaction perspective. This almost goes as far as defining a
> separate client SUBSCRIBE transaction.
>

Again, this behavior was present in 3265, and quite deliberately so.
Keep in mind: for any network that has even a single proxy that doesn't
Record-Route, the vast majority of SUBSCRIBE dialogs will be established
by the NOTIFY, not the 200 (since the NOTIFY will follow a shorter path
than the 200). And, with forking, all but one of the 200 responses will
be discarded by the proxy anyway. You *really* don't want the system
behavior to vary based on which 200 response wins the race to the proxy.

[ige] No we don't want the behaviour based upon whether the 2xx of the
NOTIFY wins the race. This is why the draft needs to be explicit upon
how the route set is determined at the subscriber end.

/a