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

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

Hi, 

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

Yes, when thinking about it that is probably true.

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

I know it is already in 3265.

I had some problems finding the text in 3261/16.7 which says that
additional 2xx respones for non-INVITEs are dropped. But, the text says
that additional 2xx responses for an INVITE are forwarded, so I guess
that implicitly means that 2xx responses for other methods are
dropped...

Regards,

Christer


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