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 a REFER request 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 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.

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.