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

[Adam Roach <[e-mail]>]

[I've elided some of the original message because it was based on a 
misunderstanding. Instead of citing RFC 3265 section 3.1.5 several 
times, I've cited it once and removed the other paragraphs that related 
to this misunderstanding]

Ian Elz wrote:
> 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.
>   

So what you'd really like to see is explicit language describing when 
and how the subscriber and notifier form their route sets. That seems 
useful to add. I'll try to get some language explicitly describing this 
in the next draft.

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

You've missed some important text in section 3.1.5 of RFC 3265:

   If a proxy wishes to see all of the SUBSCRIBE
   and NOTIFY requests for a given dialog, it MUST record-route the
   initial SUBSCRIBE and any dialog-establishing NOTIFY requests.  Such
   proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY
   requests.


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

Because 3261 forbids it. We really can't require proxies to treat 
extension methods as special cases: proxies treating SUBSCRIBE as an 
arbitrary non-INVITE message must do the right thing.


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

No.

That's what 3265 said, and it proved too confusing. We're simplifying 
that. In 3265bis, the client never uses a SUBSCRIBE 200 to establish a 
dialog. Now it always uses the NOTIFY.


/a