Clarifications for the Use of REFER with RFC 6665
updates
- rfc-3515 — The Session Initiation Protocol (SIP) Refer Method
Extracted elements (14)
Dialog reuse for REFER is prohibited because accepting a REFER within an existing dialog creates a new, problematic multiple dialog usage (per RFC 5057). The norefersub extension (RFC 4488) cannot prevent implicit subscription creation even if accepted with Require, so dialog reuse must be avoided at the sender.
GRUU is made mandatory for REFER-created subscriptions because RFC 6665 requires notifiers to use GRUUs, and accepting a REFER implicitly makes the UA an RFC 6665 notifier. Without a GRUU, out-of-dialog REFER requests for a resulting dialog may not reach the correct UA.
The 202 response code is deprecated for REFER because RFC 6665 Section 8.3.1 already deprecated it for SUBSCRIBE; since REFER creates an implicit subscription, the same deprecation applies consistently.
Backwards compatibility with older RFC 3515 implementations that have not adopted RFC 6665 is handled by checking whether the remote target contains a GRUU: absence of a GRUU indicates a legacy peer, and in-dialog REFER may be used as a fallback.
Certain specialized environments (e.g., 3GPP) use out-of-signaling agreements and media feature tags to suppress implicit subscriptions for in-dialog REFER with RFC 4488, but this does not prevent additional dialog usages when interoperating with non-supporting implementations; RFC 7614 provides a standardized alternative.
Using the norefersub option tag (RFC 4488) does not relax the out-of-dialog requirement for REFER, even if placed in a Require header field, because the recipient is still allowed to return Refer-Sub: true and create an implicit subscription.
A UA accepting a REFER that creates a subscription MUST populate its Contact header field with a GRUU. This is a direct consequence of RFC 6665 Section 4.5.1 making GRUU mandatory for notifiers.
A UA constructing a REFER request that could result in an implicit subscription in a dialog MUST build it as an out-of-dialog message (no tag parameter in the To header field), unless the remote endpoint is an older RFC 3515 implementation without a GRUU in its remote target.
A UA that might possibly become a notifier (e.g., by accepting a REFER that creates a subscription) needs to include a GRUU in the Contact header field of dialog-forming and target-refresh methods such as INVITE, per RFC 7621.
A UA wishing to identify an existing dialog (e.g., for call transfer per RFC 5589) MUST use the Target-Dialog extension defined in RFC 4538, and UAs accepting REFER MUST be able to process that extension.
An element accepting a REFER request MUST NOT reply with a 202 response code and MUST treat any 202 responses received as identical to a 200 response. Wherever RFC 3515 requires sending a 202, a 200 MUST be sent instead.
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, as required by RFC 6665 Section 4.5.2.
If a UA can be certain that no implicit subscription will be created (e.g., by requiring an extension such as RFC 7614), the REFER request MAY be sent within an existing dialog regardless of whether the remote target is a GRUU.
RFC 7647 introduces no new security considerations directly. The updated security considerations in RFC 6665 apply to the implicit subscription created by an accepted REFER request.