Referring to Multiple Resources in the Session Initiation Protocol (SIP)
updated by
- rfc-8262 — Content-ID Header Field in the Session Initiation Protocol (SIP)
Extracted elements (25)
No mechanism is provided for REFER-Issuers to receive per-target result status via the REFER itself; result tracking is application-specific (e.g., subscribing to the conference state event package RFC 4575). A future extension could enable per-target reporting without the norefersub suppression.
The implicit subscription of REFER is suppressed because applications using multiple REFER typically already subscribe to other event packages (e.g., conference state per RFC 4575) that report transaction results, making an additional implicit subscription redundant and unscalable across multiple targets.
The specification recommends against using RFC 4826 hierarchical lists and <entry-ref> elements because the multiple REFER service does not need those features, keeping the service simple and avoiding unnecessary complexity in the REFER-Recipient.
The 'copyControl' attribute from RFC 5364 is applicable to INVITE requests but lacks meaning for mid-dialog requests such as BYE; implementations should apply it only when the target SIP method makes it semantically appropriate.
A SIP REFER-Issuer generating a REFER request with multiple REFER-Targets SHOULD include the 'norefersub' option-tag in a Require header field and SHOULD include a Refer-Sub header field set to 'false' to suppress implicit subscription notifications.
A user agent generating a REFER with a pointer to a URI list in its Refer-To header field MUST include the 'multiple-refer' option-tag in the Require header field of the REFER.
If the REFER-Recipient includes a URI list in an outgoing request, it MUST include a Content-Disposition header field with value 'recipient-list-history' and a 'handling' parameter set to 'optional'.
Implementations of REFER-Recipients acting as URI-list services MUST follow the security-related rules in RFC 5363, including opt-in lists and mandatory authentication and authorization of clients.
REFER-Recipients handling 'recipient-list' bodies MUST support both RFC 4826 and RFC 5364 formats as the default format for recipient-list bodies.
REFER-Recipients MUST follow RFC 5363 procedures to avoid sending duplicate requests to the same target when duplicated URIs appear in the URI list.
REFER-Recipients MUST NOT accept REFER requests for methods they do not understand; they should only accept REFER requests within the context of an application they understand (e.g., conferencing).
The REFER-Issuer SHOULD NOT include any particular URI more than once in the URI list to avoid duplicate requests.
The REFER-Recipient MUST follow RFC 4826 procedures with respect to handling of the 'anonymize', 'count', and 'copyControl' attributes in outgoing URI lists.
The REFER-Recipient SHOULD honor the norefersub suggestion and include a Refer-Sub header field set to 'false' in the 200 OK response, suppressing implicit subscription creation.
The Refer-To header field of a REFER request with multiple REFER-Targets MUST contain a Content-ID URL pointer (per RFC 2392) to the body part carrying the URI list.
When using the default resource list document, REFER-Issuers SHOULD use flat lists (no hierarchical lists) and SHOULD NOT use <entry-ref> elements, since those RFC 4826 features are not needed by multiple REFER.
A REFER-Issuer is a user agent issuing a REFER request. A REFER-Recipient is an entity (typically a URI-list server/network entity) receiving the REFER and forwarding SIP requests to REFER-Targets. A REFER-Target is the UA of the intended final recipient.
The 'multiple-refer' SIP option-tag is defined for use in Require and Supported header fields. A UA including it in a Supported header indicates compliance with this specification; a UA generating a REFER with a URI-list pointer in Refer-To MUST include it in the Require header.
The REFER-Issuer includes the set of REFER-Targets in a 'recipient-list' body part (disposition type 'recipient-list' per RFC 5363), formatted as RFC 4826 extended with RFC 5364 copyControl attributes.
The REFER-Recipient generates one new SIP request per REFER-Target entry in the URI list, acting as if it had received a regular (single-target) REFER for each URI. The response code to the REFER itself follows RFC 3515 Section 2.4.2.
This document registers the 'multiple-refer' option-tag in the SIP Parameters 'Option Tags' registry. The tag indicates support for REFER requests containing a resource list document describing multiple REFER targets.
A REFER-Recipient accepting multiple-target REFER requests acts as a URI-list service and therefore MUST apply RFC 5363 security rules, including opt-in lists and mandatory client authentication/authorization, to prevent abuse such as amplification attacks or unauthorized fan-out.
REFER-Recipients SHOULD only accept REFER requests within a known application context and MUST NOT accept REFER requests for unknown methods, preventing them from being used as dumb fan-out servers for arbitrary or malicious messages.
The Refer-To header field carries a Content-ID URL (cid: scheme, RFC 2392) pointing to the URI-list body part. The body part is of Content-Type 'application/resource-lists+xml' with Content-Disposition 'recipient-list'.
URI list entries may carry a 'copyControl' attribute ('to', 'cc', or 'bcc') from RFC 5364 indicating the role of each REFER-Target, and an 'anonymize' attribute to prevent the REFER-Recipient from disclosing the target URI.