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

[Adam Roach <[e-mail]>]

Ian Elz wrote:
>
> Sections 4.5 and 4.5.1 define how to target SUBSCRIBE to a device 
> using gruu. Is it worth including in this section that to target a 
> SUBSCRIBE to a dialog at the device you need to use the Target-Dialog 
> header? The use of T-D would depend upon the event package but 
> including it here would provide a reminder that event packages should 
> consider this if necessary.
>

I agree that this kind of guidance would indeed be useful. I've added 
some text to 4.5:

   This dialog-sharing technique has also historically been used as a
   means for targeting an event package at a dialog.  This usage can be
   seen, for example, in certain applications of the REFER method
   [RFC3515].  With the removal of dialog re-use, an alternate (and more
   explicit) means of targeting dialogs needs to be used for this type
   of correlation.  The appropriate means of such targeting is left up
   to the actual event packages.  Candidates include the "Target-Dialog"
   header field [RFC4528], the "Join" header field [RFC3911], and the
   "Replaces" header field [RFC3891], depending on the semantics
   desired.  Alternately, if the semantics of those header fields do not
   match the event package's purpose for correlation, event packages can
   devise their own means of identifying dialogs.  For an example of
   this approach, see the Dialog Event Package [RFC4235].


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

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

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

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


/a