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

[Paul Kyzivat <[e-mail]>]

Ian Elz wrote:
> Paul,
> 
> Agreed.
> 
> Where the establishment of a SUBSCRIBE dialog is different from other
> dialog types I think that the draft should be explicit. E.g. It should
> indicate that all the UAS actions for the 200 Ok should be taken but the
> UAC will ignore this for establishing the dialog. That the NOTIFY
> headers will be used for establishing the dialog, record-route, contact
> etc.

That is the one thing I don't like about this approach - that it makes 
entirely new rules for dialog establishment for SUBSCRIBE. But 
interestingly, this makes it more consistent with REFER. And it was 
already a special case because of the NOTIFY forking.

	Thanks,
	Paul

> Ian  
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: 17 August 2009 23:54
> To: Ian Elz
> Cc: Adam Roach; [e-mail]
> Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route
> and tranaction state model.
> 
> 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
>>
>