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

[Paul Kyzivat <[e-mail]>]

Ian Elz wrote:
> Paul,
> 
> REFER is an odd case. It is always described as creating an implicit
> subscription. I think this means that it is not a SUBSCRIBE. My view is
> that REFER creates an explicit subscription to a specific event package,
> "dialog progress". If REFER is not creating a subscription the
> 'norefersub' should be included.
> 
> 3625bis does create an interesting case for REFER, REFER dialogs are
> created when the 202 Accepted is received. Is  this going to be the case
> or should the NOTIFY be used?

It makes at least as much sense in the REFER case as the SUBSCRIBE case.
I worked on an impl of SUBSCRIBE and REFER, and definitely shared code 
between them.

It will be bad enough to migrate an implementation from 3265 to 3265bis. 
It will be much worse if REFER creates a dialog but SUBSCRIBE does not.

> Do we also need to rewrite RFC3515?

I don't suppose it could be part of 3265bis? :-(

	Paul

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