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

From: "Ian Elz" <[email-masked]>
Date: Fri, 14 Aug 2009 15:20:59 +0200

Adam,

A few of comments on the draft.

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.

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?

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.

This proposal to establish route sets by separate Record-Route actions
is in variance to the actions specified in RFC3261 and should be
described in the draft.

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

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? What does the notifier end do if it then receives this
Record-Route?

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. 

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 118 9024948
[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Aug 2009 14:57:09 -0500

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

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

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

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.

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

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

> 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

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 17 Aug 2009 10:35:33 +0200

Adam,

1st of 2 responses

Easy one first.

This sounds fine - better than I would have expressed it.

Ian

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 17 Aug 2009 12:19:11 +0200

Hi,

It's a while since I read the subscribe stuff, but I have some
questions/comments.

>>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 Record-Route which establishes the UAS route set but 
>>that the NOTIFY also has Record-Route performed by proxies. This
leaves the 
>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. 
>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.

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

>relevant: the answer to "but what if they differ?" was a 
>resounding "I have no clue!"
> 
>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:
> 

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

>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

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 17 Aug 2009 12:40:26 +0200

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:[email-masked]]
Sent: 14 August 2009 20:57
To: Ian Elz
Cc: [email-masked]; Christer Holmberg
Subject: Re: draft-roach-sipcore-rfc3265bis-00

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

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

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

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

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.

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

[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

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Aug 2009 14:41:24 -0500

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

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

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

> establish multiple dialogs and to set up the route sets for each of

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.

> NOTIFY or 2xx arrives first, and for other dialogs it is taken from the

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Aug 2009 16:11:37 -0500

> SUBSCRIBE 200 responses instead?

That ship sailed over a decade ago, when we published RFC 2543. 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.

> initiation requests.

Because method names are one SIP's extension points, proxies don't 
inherently know which requests can form dialogs. For example, if a proxy 
forks a XYZZY request, how would it know whether to return a single 200 
response or all of them? It has know way of knowing whether XYZZY is a 
dialog-forming request.

>  Because, what does a proxy do if it receives

It's going to drop them. See RFC 3261, section 16.7, step 5.

> it does in the 200 response. That way the proxies would not need to add

That would make a mess -- currently deployed proxies that are aware of 
3265 would add themselves a second time, resulting in a route set that 
passes through each proxy twice. That's really not what we want to happen.

> SUBSCRIBE request, but they will not Record-Route the NOTIFY.

See RFC 3265, section 3.1.5.

> configured to Record-Route all dialog initiation requests.

For a proxy to have the first clue that SUBSCRIBE is a dialog initiation 
request, it has to be aware of the semantics of SUBSCRIBE. Otherwise, it 
doesn't know SUBSCRIBE from XYZZY.

And if a proxy is blindly Record-Routing unknown methods, it will 
Record-Route the NOTIFY also. Either way, everything works.

I've worked with enough implementors to know that there's never enough 
accounting for crazy, but the failure you're describing would require a 
certain amount of malice: enough understanding to know what SUBSCRIBE 
means, but a bewildering level of willful ignorance to then pretend not 
to understand NOTIFY.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 17 Aug 2009 23:48:51 +0200

Hi, 

inherently know which requests can form dialogs. For example, if a proxy
forks a XYZZY request, how would it know whether to return a 
>>single 200 response or all of them? It has know way of knowing whether
XYZZY is a dialog-forming request.
>
>Because, what does a proxy do if it receives additional 200 responses?
I can't find any text about that in 3261.
>It's going to drop them. See RFC 3261, section 16.7, step 5.

Maybe I'm just too blind to find it, but could you copy the text which
says that? :)

In the beginning there is generic text which says that any 2xx response
is forwarded.

Further down there is INVITE specific text, which says that non-2xx
responses are not immedialtly forwarded - instead the choose-the-best
procedures are used.

I see no text saying that additional 2xx responses for non-INVITEs are
dropped. 

------

>>>>That's certainly the intention of 4.3. It's a bit tortured to
imagine 

>>>>Record-Routing a NOTIFY unless you've also Record-Routed the 
>>>>associated SUBSCRIBE; I'll add:
>>>>
>For a proxy to have the first clue that SUBSCRIBE is a dialog
initiation request, it has to be aware of the semantics of SUBSCRIBE.
Otherwise, it doesn't know SUBSCRIBE from XYZZY.
>And if a proxy is blindly Record-Routing unknown methods, it will
Record-Route the NOTIFY also. 

Doesn't the NOTIFY contain a To tag? The proxy would assume it is an
in-dialog request, so it would not Record-Route it.

What does a stateful proxy do with an in-dialog request it doesn't find
state for, btw?

------

accounting for crazy, but the failure you're describing would require a
certain amount of malice: enough understanding to know what 
>SUBSCRIBE means, but a bewildering level of willful ignorance to then
pretend not to understand NOTIFY.

I agree that if the proxy is SUBSCRIBE aware, there should be no
problem.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Aug 2009 18:54:22 -0400

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 18 Aug 2009 15:24:43 +0200

Christer wrote

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

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.

regards

Keith 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Monday, August 17, 2009 11:19 AM
> To: Adam Roach; Ian Elz
> Cc: [email-masked]
> 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.
> 
> in 3265 -- 
> >requests -- this is not new in the 3265bis draft.
> >
> removing the 
> >ability for a SUBSCRIBE 200 response to create a dialog.
> >
> 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.
> 
> that the 
> >route set established by the NOTIFY.
> >Route header fields that guarantee that the NOTIFY traverses the 
> >proxies that Record-Route the SUBSCRIBE.
> 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.
>  
> 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.
> 
> establishes 
> anyway. Even 
> >least one of the dialogs from the NOTIFY -- so I may as well always 
> >take it from the NOTIFY.
> >
> 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.
> >>
> > 
> 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
> 
> 
> 
> 
> 
> 
> 
> that doesn't 
> >Record-Route, the vast majority of SUBSCRIBE dialogs will
> be

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 18 Aug 2009 19:51:51 +0200

Hi, 

>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

> it does in the 200 response. That way the proxies would not need to 
> add it.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 18 Aug 2009 20:18:31 +0200

Hi,

Do we need some guidance based on the problems in the record-route fix
draft? 

Since the 200 response is not used, there will be no possibility to do
record-route re-write, and I guess there is no idea in doing double
record-routing either.

So, I guess it would be good to indicate that the proxy, when
Record-Routing the SUBSCRIBE only needs to think about the
notifier-to-subscriber route set. And, when the proxy Record-Routes the
NOTIFY, it only needs to think about the subscriber-to-notifier route
set.

Maybe the above is obvious, but since record-routing has caused interop
problems, and since the record-route fix draft doesn't talk about
subscriptions, I don't think some more detailed text than just "the
proxy shall Record-Route" would harm.

----
 
Also, related to the text saying that adding a new R-R to the SUB cannot
change the route set, and eventhough the text says that the SAME R-R
must be added to all NOTIFY requests, it would probably be good to say
that adding a new R-R to a NOT would not change the route set either.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Tuesday, August 18, 2009 1:54 AM
To: Ian Elz
Cc: [email-masked]
Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route
and tranaction state model.

Ian,

For instance,

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

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

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

> 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

> 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 

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

> [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.
> 
> It ignores it. There is no way to change a dialog route set (other 
> than the remote target) mid-dialog.
> 
> 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.
> 
> 
>> 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 
> 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 

> want the system behavior to vary based on which 200 response wins the
race to the proxy.

---

From: "Ian Elz" <[email-masked]>
Date: Tue, 18 Aug 2009 23:20:19 +0200

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:

   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:[email-masked]] 
Sent: 17 August 2009 20:41
To: Ian Elz
Cc: [email-masked]; Christer Holmberg
Subject: Re: draft-roach-sipcore-rfc3265bis-00 - Record-Route and
tranaction state model.

received.

> NOT update the route set. Thus asymmetric route sets will result.

subscription e.g.

> the NOTIFY.

No.

/a

---

From: "Ian Elz" <[email-masked]>
Date: Tue, 18 Aug 2009 23:20:19 +0200

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.

Ian  

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 17 August 2009 23:54
To: Ian Elz
Cc: Adam Roach; [email-masked]
Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route

Ian,

For instance,

	Thanks,
	Paul

received.

SUBSCRIBE.

subscription e.g.

race to the proxy.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Aug 2009 17:28:33 -0400

> headers will be used for establishing the dialog, record-route, contact

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

---

From: "Ian Elz" <[email-masked]>
Date: Tue, 18 Aug 2009 23:34:16 +0200

Paul,

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?

Do we also need to rewrite RFC3515?

Ian 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 18 August 2009 22:29
To: Ian Elz
Cc: Adam Roach; [email-masked]
Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route

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

	Thanks,
	Paul

> Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - 
> Record-Route and tranaction state model.
> 
> Ian,
> 
> 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,
> 
> 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.
>>

>> This

>> However,

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Aug 2009 19:22:30 -0400

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

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 19 Aug 2009 14:20:09 +0200

Hi, 
 
>>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.
>> 
>>created when the 202 Accepted is received. Is  this going to be the 
>>case or should the NOTIFY be used?
> 
>I worked on an impl of SUBSCRIBE and REFER, and definitely 
>shared code between them.
> 

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

Regards,

Christer

> >>> 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
> >>> [ige] I understand that you are not adding any 
> functionality which 
> >>> is
> > 
> >>>> 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.
> >>>>
> >>> 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 
> describe a 
> >>> [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
> > 
> >>>> 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?
> >>>>
> >>> at least one of the dialogs from the NOTIFY -- so I may as well 
> >>> always take it from the NOTIFY.
> >>>
> >>> 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.
> 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 
> >>> themselves to the Record-Route in the SUBSCRIBE MUST add 
> themselves 
> >>> to the Record-Route in subsequent NOTIFY requests for the same 
> >>> dialog
> >> (?).
> >>>> 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.
> >>>
> >>> 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.
> >>>
> >>>
> >>> 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
> > 
> >>> [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
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Aug 2009 08:59:09 -0400

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

I don't know. I think dialog reuse for REFER is quite institutionalized, 
so it would be very difficult to remove it now.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 19 Aug 2009 15:33:33 +0200

Hi, 

>>>>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?
>>>I worked on an impl of SUBSCRIBE and REFER, and definitely shared 
>>>code between them.
>>>
>I don't know. I think dialog reuse for REFER is quite 
>institutionalized, so it would be very difficult to remove it now.

I agree. 

But, that means that dialog re-use for subscriptions are still
possilble, even if invovled entities otherwise are 3265bis compliant.
Maybe that should be mentioned in 3265bis.

Regards,

Christer