Re: [sipcore] draft-roach-sipcore-rfc3265bis-00

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

Hi,

It's a while since I read the subscribe stuff, but I have some
questions/comments.

>>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.

Has it been considered that a forking proxy would forward multiple
SUBSCRIBE 200 responses instead?

Also, I know that 3261 says that only one final response is forwarded
for non-INVITE requests. I just wonder whether it means non-dialog
initiation requests. Because, what does a proxy do if it receives
additional 200 responses? I can't find any text about that in 3261.

>>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.

I guess the UAS could simply copy the Record-Route into the NOTIFY, as
it does in the 200 response. That way the proxies would not need to add
it.

But, again, wouldn't the easiest way be to make sure that all 200/202
responses are forwarded to the UAC?

I guess another option would be to send a 18x, in order to provide the
Record-Route.
 
>>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.

I am not really sure what is meant by "compliant system". A system may
be RFC3261 compliant, which means they may add Record-Route the
SUBSCRIBE request, but they will not Record-Route the NOTIFY.

>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.
>
>>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.

Don't you need a Proxy-Require option tag for that? 

Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, but that
doesn't mean it will Record-Route the NOTIFY. It may simply be
configured to Record-Route all dialog initiation requests.

Regards,

Christer







>>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.
> 
>>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.
> 
> 
>>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.