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

["Ian Elz" <[e-mail]>]

Adam,

I think that I understand what you are trying to simplify and why. I
just think that we need to ensure that the new draft does not leave open
the interpretations which are possible from RFC3265.

"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] Yes - I think that it is necessary to describe the differences
from RFC 3261.

"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] OK - any proxy which fails to do this does so at its own peril.
The requirement to record-route subsequent SUBSCRIBE and NOTIFY is I
assume for simplicity in implementation, so the proxy does not have to
wok out which are for new dialogs and which for existing.

Ian

-----Original Message-----
From: Adam Roach [mailto:[e-mail]] 
Sent: 17 August 2009 20:41
To: Ian Elz
Cc: [e-mail]; Christer Holmberg
Subject: Re: draft-roach-sipcore-rfc3265bis-00 - Record-Route and
tranaction state model.


[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