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

["DRAGE, Keith (Keith)" <[e-mail]>]

Christer wrote

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

It can only do this if it understands that SUBSCRIBE is a dialog initiation request, and it can only do this if it implements either RFC 3265 or 3265bis. 

As I understood it, the behaviour described by Adam is already in RFC 3265, and therefore it is a non-conformant implementation of RFC 3265 if it does something difference.

regards

Keith 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Christer Holmberg
> Sent: Monday, August 17, 2009 11:19 AM
> To: Adam Roach; Ian Elz
> Cc: [e-mail]
> Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00
> 
> 
> 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.
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>