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

["Christer Holmberg" <[e-mail]>]

Hi,

Do we need some guidance based on the problems in the record-route fix
draft? 

Since the 200 response is not used, there will be no possibility to do
record-route re-write, and I guess there is no idea in doing double
record-routing either.

So, I guess it would be good to indicate that the proxy, when
Record-Routing the SUBSCRIBE only needs to think about the
notifier-to-subscriber route set. And, when the proxy Record-Routes the
NOTIFY, it only needs to think about the subscriber-to-notifier route
set.

Maybe the above is obvious, but since record-routing has caused interop
problems, and since the record-route fix draft doesn't talk about
subscriptions, I don't think some more detailed text than just "the
proxy shall Record-Route" would harm.

----
 
Also, related to the text saying that adding a new R-R to the SUB cannot
change the route set, and eventhough the text says that the SAME R-R
must be added to all NOTIFY requests, it would probably be good to say
that adding a new R-R to a NOT would not change the route set either.


Regards,

Christer


 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Paul Kyzivat
Sent: Tuesday, August 18, 2009 1:54 AM
To: Ian Elz
Cc: [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
> 
_______________________________________________
sipcore mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sipcore