Clarifications for the use of REFER with RFC6665

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

An accepted SIP REFER method creates an implicit subscription using the SIP-Specific Event Notification Framework. That framework was revised by . This document highlights the implications of the requirement changes in RFC6665, and updates to clarify and disambiguate the impact of those changes.

Section 4.5.1 of makes GRUU mandatory to implement and use as the local target in the subscription created by the REFER request. A user agent constructing any REFER that can result in an implicit subscription MUST populate its Contact header field with a GRUU. As RFC6665 details, this is necessary to ensure that NOTIFY requests sent in the implicitly created subscription arrive at this user agent without creating a second usage inside an existing dialog. Using the "norefersub" option tag does not change this requirement, even if used in a "Require" header field. Even if the recipient supports the "norefersub" mechanism, and accepts the request with the option tag in the "Require" header field, it is allowed to return a "Refer-Sub" header field with a value of "true" in the response, and create an implicit subscription.

As a direct consequence of requiring the use of GRUU, and the requirements in section 4.5.2 of RFC6665, sending a REFER that might result in an additional dialog usage within any existing dialog is prohibited. A user agent constructing a REFER request MUST built it as an out-of-dialog message as defined in . Thus, the REFER request will have no tag parameter in its To: header field. A user agent wishing to identify an existing dialog (such as for call transfer as defined in MUST use the "Target-Dialog" extension defined in to do so. If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription), the REFER request MAY be sent within an existing dialog. Such a REFER will be constructed with its Contact header field populated with the dialog's Local URI as specified in section 12 of .

This document introduces no new security considerations directly. The updated considerations in apply to the implicit subscription created by an accepted REFER request.

This document has no actions for IANA.