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. A UA that will accept a REFER request needs to include a GRUU in the Contact header field of all INVITE requests. This ensures that out-of-dialog REFER requests corresponding to any resulting INVITE dialogs arrive at this UA. Future extensions (such as ) might relax this requirement by defining a REFER request that cannot create an implicit subscription.

If a peer in an existing dialog has provided a GRUU as its Contact, sending a REFER that might result in an additional dialog usage within that dialog is prohibited. This is a direct consequence of requiring the use of GRUU, and the requirements in section 4.5.2 of that document. A user agent constructing a REFER request that could result in an implicit subscription MUST build 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, and user agents accepting REFER MUST be able to process that extension in requests they receive. 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 . As described in section 4.5.2 of , there are cases where a user agent may fall back to sharing existing dialogs for backwards-compatibility purposes. This applies to REFER only when the peer has not provided a GRUU as its Contact in the existing dialog (i.e. when the peer is a pre-RFC6665 implementation).

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.