Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
Extracted elements (29)
Re-INVITE requests to the conference URI (not the factory URI) are rejected with 420 when they carry 'recipient-list' bodies because the conference URI resource does not support the extension, unlike the factory URI that does.
The mechanism allows a UAC to request conference creation and supply initial participants in a single INVITE operation to meet environments with tough requirements on conference establishment time, avoiding a separate add-participant phase.
The RFC 4826 XML resource list format is used as the default despite supporting hierarchical lists and entry-by-reference, because conferencing only needs a flat URI list; implementations may discard unsupported extra information.
A 200 (OK) response to the initial INVITE only confirms conference creation and that the server understood the URI list; it provides no information about whether individual participants in the list were successfully added.
The initial INVITE is sent to the conference factory URI (which supports 'recipient-list-invite'), whereas re-INVITEs within the established dialog are sent to the conference URI (which does not support this extension).
A UAC sending an initial INVITE to create an ad hoc conference with a participant list MUST include the 'recipient-list-invite' option-tag in a Require header field.
Conference servers receiving a re-INVITE with a 'recipient-list' body and 'recipient-list-invite' option-tag MUST reject it with 420 (Bad Extension) carrying an Unsupported header listing the option-tag.
Conference servers that support INVITE requests with 'recipient-list' bodies SHOULD include 'recipient-list-invite' in a Supported header field when responding to OPTIONS requests.
Conferencing servers able to handle 'recipient-list' bodies MUST support the XML resource list format (RFC 4826) extended with the copyControl extension (RFC 5364), and MAY support other formats.
Conferencing UACs generating or understanding 'recipient-list-history' bodies MUST support the XML resource list format (RFC 4826) extended with RFC 5364, and MAY support other formats.
Conferencing UACs generating 'recipient-list' bodies MUST support both the XML resource list format (RFC 4826) and the copyControl extension (RFC 5364), and MAY support other formats.
If the conference server includes a URI list in an outgoing INVITE, it MUST include a Content-Disposition header with value 'recipient-list-history' and a 'handling' parameter set to 'optional'.
If the UAC wishes to obtain information about the status of other users in the conference after receiving a 200 OK, it SHOULD use general conference mechanisms such as the conference package defined in RFC 4575.
If the URI list includes resources tagged with 'copyControl' set to 'to' or 'cc', the conference server SHOULD include a URI list in each outgoing INVITE request formatted per RFC 4826 and RFC 5364.
Implementations of conference servers handling URI lists MUST follow the security-related rules in RFC 5363, including opt-in lists and mandatory authentication and authorization of clients.
On reception of an INVITE with a 'recipient-list' body, a conference server MUST follow RFC 4579 rules to create ad hoc conferences and then SHOULD attempt to add participants from the URI list.
The UAC adds a body with disposition type 'recipient-list' (as defined in RFC 5363) containing the initial participants to the INVITE request sent to the conference factory URI.
The URI-list service MUST follow RFC 5364 procedures for handling the 'anonymize', 'count', and 'copyControl' attributes.
UACs SHOULD NOT include 'recipient-list' bodies in re-INVITE requests sent to a conference server, as no semantics are currently defined for that context.
When using the default resource list document, conferencing UAs SHOULD use flat lists (no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
A 'recipient-list-history' body in outgoing INVITE requests sent by the conference server contains the (possibly anonymized and counted) list of recipients, formatted per RFC 4826 extended with RFC 5364.
Each URI in the recipient list may be tagged with a 'copyControl' attribute ('to', 'cc', or 'bcc') indicating the role in which the recipient receives the INVITE, and optionally an 'anonymize' attribute to prevent URI disclosure.
The INVITE request to the conference factory URI may carry a multipart/mixed body comprising an application/sdp session description and an application/resource-lists+xml URI list with disposition 'recipient-list'.
The 'recipient-list-invite' SIP option-tag is used in a Require header field of an initial INVITE to signal that the request body contains a URI list of intended conference participants.
This document registers the 'recipient-list-invite' option-tag in the SIP Option Tags subregistry under the SIP parameter registry; its description is 'The body contains a list of URIs that indicates the recipients of the SIP INVITE request'.
Authorization rules about who can join a conference and what media is permitted SHOULD be enforced by the focus using normal SIP authentication mechanisms (Digest, certificates) to admit or deny participation.
Conference servers handling URI lists act as URI-list services and MUST follow RFC 5363 security rules, including opt-in lists and mandatory client authentication and authorization, to prevent abuse such as unsolicited INVITE storms.
The recipient list body uses Content-Type 'application/resource-lists+xml' with Content-Disposition 'recipient-list'; the document is an XML resource list per RFC 4826 extended with the copyControl namespace 'urn:ietf:params:xml:ns:copycontrol'.
The recipient-list-history body uses Content-Type 'application/resource-lists+xml' with Content-Disposition 'recipient-list-history; handling=optional', containing anonymized URIs and using the 'count' attribute to aggregate collapsed entries.