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

[Paul Kyzivat <[e-mail]>]

Ian,

3265 wasn't very explicit about some of this, and the end result was 
that for several things there were two different mechanisms for 
obtaining information, and no clear rules about which took precedence.
This typically isn't a problem *as long as both mechanisms yield the 
same result*. But whenever you "replicate" something there is always the 
possibility that the results aren't really replicas, and then questions 
about which is the *true* one.

For instance,

1) suppose the first NOTIFY arrives before the 200 (SUBSCRIBE) does.
    and suppose the two contain different Contact URIs. After both
    have been received, which value is the remote target for the dialog?

2) Similar to (1), but for Record-Route.

By eliminating one source of information for the dialog (the 200), there 
are a number of questions than then need not be either asked or answered.

	Thanks,
	Paul

Ian Elz wrote:
> 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
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>