Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

From: Adam Roach <[email-masked]>
Date: Mon, 04 Nov 2013 16:34:35 -0800

On 10/29/13 11:54, Christer Holmberg wrote:
>
>
> In my view it is ok to send a REFER within an INVITE dialog, if the 
> sender *knows* that the receiver will not create a subscription.
>
> HOW the sender knows that (whether usage of Require:norefersub would 
> guarantee it, or whether the knowledge is based on some other 
> information) is outside the scope, I think.
>

The problem is that there's not really a way for the sender to know that 
this is the case. "Require: norefersub" doesn't even get you there, 
since all you're doing is ensuring that the other end supports that 
extensions, not guaranteeing that it will apply it.

In other words, there is know way to absolutely know that the receiver 
will not create a subscription.

> Having said that, I do agree that the text in RFC 5057 seems 
> misleading, as it seems to generally indicate that a subscription will 
> never be created when a REFER utilizes norefersub.
>

I agree that the cited language from RFC5057 can be a bit confusing 
because of its imprecision. I read it to say that any REFER that uses 
the "norefersub" extension -- /which includes//having a "Refer-Sub: 
false" in the response/ -- doesn't create a new usage.

But you don't know what the response will look like /a priori/, so an 
RFC6665 implementation must plan for either outcome. This means that the 
use of REFER with RFC6665 absolutely requires the use of RFC4538 instead 
of dialog re-use whenever the remote target is a GRUU.

/a

> Regards,
>
> Christer
>
> *Lähettäjä:[email-masked] [mailto:[email-masked]] 
> *Puolesta *Andrew Allen
> *Lähetetty:* 29. lokakuuta 2013 19:31
> *Vastaanottaja:* [email-masked]
> *Aihe:* [sipcore] Questions regarding use of REFER by RFC 6665 
> compliant UAs
>
> Recently there has been some offline discussion regarding the impact 
> of RFC 6665 on the use of REFER. Particularly on whether an RFC 6665 
> compliant UA can send a REFER using a dialog created by another SIP 
> method other than for interoperability with UAs that don’t support 
> GRUU and RFC 6665.
>
> RFC 6665 deprecates dialog reuse for subscriptions. REFER can create 
> also create an implicit subscription.
>
> RFC 6665 states:
>
>         ….the dialog reuse technique described in RFC 3265 is now 
> deprecated.
>
> 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 reuse, 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 [RFC4538], the "Join" header field [RFC3911], and the
>
> "Replaces" header field [RFC3891], depending on the semantics
>
>    desired.
>
> And
>
> Further note that the prohibition on reusing dialogs does not
>
> exempt implicit subscriptions created by the REFER method. This
>
> means that implementations complying with this specification are
>
> required to use the "Target-Dialog" mechanism described in
>
> [RFC4538] when the remote target is a GRUU.
>
> However RFC 4488 provides a means to request a REFER recipient not to 
> create an implicit subscription through the use of Refer-Sub: false. 
> However the text of RFC 4488 does not require that the REFER recipient 
> not create an implicit subscription since RFC 4488 states:
>
> If the REFER-Recipient supports the extension _and is willing to 
> process the REFER transaction without establishing an implicit 
> subscription_, it MUST insert the "Refer-Sub" header field set to 
> "false" in the 2xx response to the REFER-Issuer.
>
> The key words here are “and is WILLING to process the REFER 
> transaction without establishing an implicit subscription” so there is 
> always the possibility that a subscription will be created even if 
> norefersub is supported and Refer-Sub header field is set to FALSE.
>
> However RFC 5057 seems to be in conflict with RFC 4488 in this regard 
> stating:
>
>    Dialogs with multiple usages arise when a usage-creating action
>
>    occurs inside an existing dialog.  Such actions include accepting a
>
>    REFER or SUBSCRIBE issued inside a dialog established with an INVITE
>
>    request.  Multiple REFERs within a dialog create multiple
>
>    subscriptions, each of which is a new dialog usage sharing common
>
>    dialog state. _(Note that any REFER issued utilizing the_
>
> _   subscription-suppression mechanism specified in [2] creates no new_
>
> _   usage.)_  Similarly, an endpoint in a dialog established with an
>
>    INVITE might subscribe to its peer's Key Press Markup Language (KPML)
>
>    [3] and later issue a REFER, resulting in three dialog usages sharing
>
>    common dialog state.
>
> So the first question is if an RFC 6665 compliant UA indicated either 
> Require: norefersub or knows that the REFER recipient supports 
> norefersub and also indicates Refer-Sub: False in the REFER request 
>  can that REFER request be sent on a dialog created by another Method 
> (in the safe knowledge that no subscription will be created)?
>
> If the answer to the first question is no – an implicit subscription 
> could still be created.
>
> Can some other knowledge that the REFER recipient will not create an 
> implicit subscription - such as the definition in another 
> specification outside of IETF of a feature that mandates that no 
> subscription be created by the REFER recipient and the indication of 
> the support of such a feature by the REFER recipient in a global tree 
> media feature tag has been received by the REFER sender. Does this 
> allow an RFC 6665 UA to send the REFER on a dialog created by another 
> Method?
>
> I have discussed the issue with Adam Roach offline and his view and 
> mine is that RFC 6665 UAs do not send REFER requests sent on a dialog 
> created by another Method except for interoperability with UAs that 
> don’t support GRUU and RFC 6665.
>
> What is the view of the rest of the community?
>
> Andrew
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Andrew Allen <[email-masked]>
Date: Tue, 5 Nov 2013 00:56:24 +0000

As I previously indicated I share a similar view on this as Adam.

I would further add that having some application level knowledge outside of the SIP protocol that a REFER recipient will definitely not create a subscription is a protocol layering violation creating a coupling between the application layer and the SIP layer which potentially has significant impacts on SIP stack implementations (e.g. APIs, complexity etc).

Whether the REFER is sent on an existing dialog or not is a SIP layer issue and according to SIP (as updated per RFC 6665) if the Remote target is a GRUU then the REFER request is required not to be sent on an existing dialog and to used RFC 4538 mechanism instead.

The Application layer should not be telling the SIP stack how to send the REFER request (on an existing dialog or outside the existing dialog) even if the application knows (or thinks it knows) what the REFER recipent will do.

Andrew

From: Adam Roach [mailto:[email-masked]]
Sent: Monday, November 04, 2013 06:34 PM Central Standard Time
To: Christer Holmberg <[email-masked]>; Andrew Allen; [email-masked] <[email-masked]>
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

 In my view it is ok to send a REFER within an INVITE dialog, if the sender knows that the receiver will not create a subscription.

HOW the sender knows that (whether usage of Require:norefersub would guarantee it, or whether the knowledge is based on some other information) is outside the scope, I think.

The problem is that there's not really a way for the sender to know that this is the case. "Require: norefersub" doesn't even get you there, since all you're doing is ensuring that the other end supports that extensions, not guaranteeing that it will apply it.

In other words, there is know way to absolutely know that the receiver will not create a subscription.

 Having said that, I do agree that the text in RFC 5057 seems misleading, as it seems to generally indicate that a subscription will never be created when a REFER utilizes norefersub.

I agree that the cited language from RFC5057 can be a bit confusing because of its imprecision. I read it to say that any REFER that uses the "norefersub" extension -- which includes having a "Refer-Sub: false" in the response -- doesn't create a new usage.

But you don't know what the response will look like a priori, so an RFC6665 implementation must plan for either outcome. This means that the use of REFER with RFC6665 absolutely requires the use of RFC4538 instead of dialog re-use whenever the remote target is a GRUU.

/a

Regards,

Christer

Lähettäjä: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Puolesta Andrew Allen
Lähetetty: 29. lokakuuta 2013 19:31
Vastaanottaja: [email-masked]<mailto:[email-masked]>
Aihe: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

Recently there has been some offline discussion regarding the impact of RFC 6665 on the use of REFER. Particularly on whether an RFC 6665 compliant UA can send a REFER using a dialog created by another SIP method other than for interoperability with UAs that don’t support GRUU and RFC 6665.

RFC 6665 deprecates dialog reuse for subscriptions. REFER can create also create an implicit subscription.

RFC 6665 states:

        …. the dialog reuse technique described in RFC 3265 is now deprecated.

And

However RFC 4488 provides a means to request a REFER recipient not to create an implicit subscription through the use of Refer-Sub: false. However the text of RFC 4488 does not require that the REFER recipient not create an implicit subscription since RFC 4488 states:

   If the REFER-Recipient supports the extension and is willing to process the REFER transaction without establishing an implicit subscription, it MUST insert the "Refer-Sub" header field set to "false" in the 2xx response to the REFER-Issuer.

The key words here are “and is WILLING to process the REFER transaction without establishing an implicit subscription” so there is always the possibility that a subscription will be created even if norefersub is supported and Refer-Sub header field is set to FALSE.

However RFC 5057 seems to be in conflict with RFC 4488 in this regard stating:

   Dialogs with multiple usages arise when a usage-creating action
   occurs inside an existing dialog.  Such actions include accepting a
   REFER or SUBSCRIBE issued inside a dialog established with an INVITE
   request.  Multiple REFERs within a dialog create multiple
   subscriptions, each of which is a new dialog usage sharing common
   dialog state.  (Note that any REFER issued utilizing the
   subscription-suppression mechanism specified in [2] creates no new
   usage.)  Similarly, an endpoint in a dialog established with an
   INVITE might subscribe to its peer's Key Press Markup Language (KPML)
   [3] and later issue a REFER, resulting in three dialog usages sharing
   common dialog state.

So the first question is if an RFC 6665 compliant UA indicated either Require: norefersub or knows that the REFER recipient supports norefersub and also indicates Refer-Sub: False in the REFER request  can that REFER request be sent on a dialog created by another Method (in the safe knowledge that no subscription will be created)?

If the answer to the first question is no – an implicit subscription could still be created.

Can some other knowledge that the REFER recipient will not create an implicit subscription - such as the definition in another specification outside of IETF of a feature that mandates that no subscription be created by the REFER recipient and the indication of the support of such a feature by the REFER recipient in a global tree media feature tag has been received by the REFER sender. Does this allow an RFC 6665 UA to send the REFER on a dialog created by another Method?

I have discussed the issue with Adam Roach offline and his view and mine is that RFC 6665 UAs do not send REFER requests sent on a dialog created by another Method except for interoperability with UAs that don’t support GRUU and RFC 6665.

Andrew
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 5 Nov 2013 11:03:45 +0000

Hello,

> The problem is that there's not really a way for the sender to know that this is the case. "Require: norefersub" doesn't even get you there,
> since all you're doing is ensuring that the other end supports that extensions, not guaranteeing that it will apply it.

There is a way to know.

REFER sender knows that implicit subscription will not be created if:
            - a feature description document:
                        - states that REFER recipient does not create an implicit subscription when REFER with Support: norefersub (or with Require: norefersub) is received; and
                        - defines a media feature tag related to this feature; and
            - if the remote UA in the session included the media feature tag in its Contact header field.

> I would further add that having some application level knowledge outside of the SIP protocol that a REFER recipient will definitely not create a subscription is a protocol layering
> violation creating a coupling between the application layer and the SIP layer which potentially has significant impacts on SIP stack implementations (e.g. APIs, complexity etc).

RFC4488 defines two methods, out of which one is profiled by the feature description document above. See no layer violation in that.

> Whether the REFER is sent on an existing dialog or not is a SIP layer issue and according to SIP (as updated per RFC 6665) if the Remote target is a GRUU then the REFER request is required not to b…

I don't agree with this either.
The only thing we need to ensure is that dialog re-used does not occur which the method above ensures.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 5. listopadu 2013 1:56
To: [email-masked]; Christer Holmberg; [email-masked]
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

Andrew

From: Adam Roach [mailto:[email-masked]]
Sent: Monday, November 04, 2013 06:34 PM Central Standard Time
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

/a

Regards,

Christer

RFC 6665 states:

And

Andrew

sipcore mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Nov 2013 18:24:39 +0000

Hi,

I am not sure what you mean by “outside the SIP protocol”.

You can have a media feature tag, and/or a feature-capability indicator, where the associated feature description states that a subscription dialog is not created.

Regards,

Christer

From: Andrew Allen<mailto:[email-masked]>
Sent: ‎Tuesday‎, ‎November‎ ‎5‎, ‎2013 ‎2‎:‎56‎ ‎AM
To: 'Adam Roach'<mailto:[email-masked]>, Christer Holmberg<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Andrew

/a

Regards,

Christer

RFC 6665 states:

And

Andrew

---

From: Andrew Allen <[email-masked]>
Date: Tue, 5 Nov 2013 18:36:52 +0000

Christer

That's exactly what I mean by "outside the SIP protocol". If the feature tag ior feature capability indicator s not in the SIP tree then its functional descriription is outside of SIP and instead is at the application layer.

The SIP stack does not understand the application layer sematics indicated by a global tree feature tag or featur capabiity indicator.

Andrew

From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 12:24 PM Central Standard Time
To: Andrew Allen; 'Adam Roach' <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

Hi,

Regards,

Christer

Andrew

/a

Regards,

Christer

RFC 6665 states:

And

Andrew

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Nov 2013 18:41:04 +0000

Hi,

I don't think the SIP stack decides whether to create a subscription or not - the application has to instruct it what to do.

Regards,

Christer
From: Andrew Allen<mailto:[email-masked]>
Sent: ‎Tuesday‎, ‎November‎ ‎5‎, ‎2013 ‎8‎:‎36‎ ‎PM
To: Christer Holmberg<mailto:[email-masked]>, 'Adam Roach'<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Christer

Andrew

Hi,

Regards,

Christer

Andrew

/a

Regards,

Christer

RFC 6665 states:

And

Andrew

---

From: Andrew Allen <[email-masked]>
Date: Tue, 5 Nov 2013 19:02:14 +0000

Andrew

I think it should be a SIP stack decision wether to send the REFER request on an existing dialog or not based on the properties of the remote target according to the rules in RFC 6665. At least the stack should not be required to provide the application with the ability to control such behavior.

If GRUU and Target-Dialog are supported what is the good reason to ever send REFER on a dialog created by another method?

Andrew

From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 12:41 PM Central Standard Time
To: Andrew Allen; 'Adam Roach' <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

Hi,

Regards,

Christer

Christer

Andrew

Hi,

Regards,

Christer

Andrew

/a

Regards,

Christer

RFC 6665 states:

And

Andrew

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 6 Nov 2013 11:15:00 +0000

Hello,

> I think it should be a SIP stack decision wether to send the REFER request on an existing dialog or not based on the properties of the remote target according to the rules in RFC 6665.

Today, it is application decision whether to send in-dialog REFER or out-of-dialog REFER.

Today, there are existing applications which send in-dialog REFER using RFC4488 and which can guarantee that implicit subscription is not created by use of the feature tag (see attached).

In those applications, dialog re-use does not occur.

Thus, I see no reasons to prevent such application from sending in-dialog REFERs. Nothing is broken.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 5. listopadu 2013 20:02
To: Christer Holmberg; [email-masked]; [email-masked]
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

Andrew

Andrew

From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 12:41 PM Central Standard Time
To: Andrew Allen; 'Adam Roach' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

Hi,

Regards,

Christer

Christer

Andrew

From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 12:24 PM Central Standard Time
To: Andrew Allen; 'Adam Roach' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

Hi,

Regards,

Christer

Andrew

/a

Regards,

Christer

RFC 6665 states:

And

Andrew

sipcore mailing list

Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs
From: Ivo Sedlacek <[email-masked]>
To: Andrew Allen <[email-masked]>, "[email-masked]" <[email-masked]>, Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 5 Nov 2013 11:03:45 +0000
List-Id: SIP Core Working Group <sipcore.ietf.org>

Hello,

There is a way to know.

Kind regards

Ivo Sedlacek

Andrew

   /a

   Regards,

   Christer

   RFC 6665 states:

      desired.

   And

      common dialog state.

   Andrew

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 6 Nov 2013 14:58:41 -0500 (EST)

> (in the safe knowledge that no subscription will be created)?

I think the question is poorly put.

I would describe a UA as "compliant with RFC 6665" if it does not
create new usages in an existing dialog.  However, sending a REFER
with norefersub does not *create* such a usage; it is the recipient of
the REFER that might do so.  (If norefersub is not present, you could
argue that the UA has *compelled* the remote UA to violate RFC 6665.)
And in any case, a UA has to be prepared (to some degree) to handle
attempted reuse of the dialog, unless it has out-of-band knowledge
that every possible far-end UA is compliant with RFC 6665 -- which it
doesn't.

(Note that handling the SUBSCRIBE could be as crude as rejecting it
with a 4xx.)

I think the category of UAs you want to describe is not "compliant
with RFC 6665", but "ensuring that no action it takes will cause the
remote UA to reuse a dialog, even if that UA is not compliant to RFC
6665".  That's a harder task, and it's not clear to me why you want to
do it.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Nov 2013 20:24:18 +0000

Hi Dale,

> I would describe a UA as "compliant with RFC 6665" if it does not create new usages in an existing dialog.  However, sending a REFER with norefersub does not *create* such a usage; it is the recipient of the REFER that might do so. 

Correct, and that is what the issue is about.

> (If norefersub is not present, you could argue that the UA has *compelled* the remote UA to violate RFC 6665.) And in any case, a UA has to be prepared (to some degree) to handle 
> attempted reuse of the dialog, unless it has out-of-band knowledge that every possible far-end UA is compliant with RFC 6665 -- which it doesn't.

In the use-cases we are discussing "norefersub" IS present.

Regards,

Christer

(Note that handling the SUBSCRIBE could be as crude as rejecting it with a 4xx.)

I think the category of UAs you want to describe is not "compliant with RFC 6665", but "ensuring that no action it takes will cause the remote UA to reuse a dialog, even if that UA is not compliant to RFC 6665".  That's a harder task, and it's not clear to me why you want to do it.

Dale

---

From: Andrew Allen <[email-masked]>
Date: Fri, 8 Nov 2013 20:22:10 +0000

Dale

My responses inline

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Wednesday, November 06, 2013 2:59 PM
To: [email-masked]
Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs

I would describe a UA as "compliant with RFC 6665" if it does not create new usages in an existing dialog.  However, sending a REFER with norefersub does not *create* such a usage; it is the recipient of the REFER that might do so.  (If norefersub is not present, you could argue that the UA has *compelled* the remote UA to violate RFC 6665.) And in any case, a UA has to be prepared (to some degree) to handle attempted reuse of the dialog, unless it has out-of-band knowledge that every possible far-end UA is compliant with RFC 6665 -- which it doesn't.

[AA] My understanding is that a primary objective of RFC 6665 is to ensure that there is no creation of a new usages of an existing dialog going forward (i.e dialog reuse is only allowed for interoperability with legacy UAs). IMHO use of norefersub cannot ensure that that there is no creation of a new usage of an existing dialog as RFC 4488 indicates that as well as understanding norefersub the REFER receipient also needs to  be "willing" not to create a subscription. Therefore the only way in SIP to ensure that there is no creation of a new usage of an existing dialog is to send the REFER outside of a dialog.

Dale