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

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

Hi, 
 
>>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? :-(

Would we then also deprecate dialog re-use for REFER?

Regards,

Christer




> > -----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
> >>>
> > 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>