RFC 5366
Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
(part 1 of 3, more coming!) 💖
Title Block ✨
Okay bestie, this is RFC 5366, called Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) 🎀 It was written by G. Camarillo from Ericsson and A. Johnston from Avaya, it's on the Standards Track, and it's dated October 2008. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here 💅
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community and asks for discussion and suggestions for improvements. If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Abstract ✨
This document explains how to create a conference using SIP URI-list services. The main idea is a mechanism that lets a User Agent Client hand a conference server its initial list of participants using a URI list carried inside the INVITE 🦋
Table of Contents ✨
1. Introduction ....................................................2
2. Terminology .....................................................2
3. User Agent Client Procedures ....................................2
3.1. Response Handling ..........................................2
3.2. Re-INVITE Request Generation ...............................3
4. URI-List Document Format ........................................3
5. Conference Server Procedures ....................................5
5.1. Re-INVITE Request Handling .................................6
6. Example .........................................................6
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. Acknowledgments ................................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................121. Introduction ✨
Okay so, [RFC4579] Section 5.4 explains how to make a conference with ad hoc SIP [RFC3261] methods 💅 The client sends an INVITE request to a conference factory URI and gets back the real conference URI. That URI has the isfocus feature tag and shows up in the Contact header field of a response, usually a 200 (OK) response ✨
Once the UAC (User Agent Client) has the conference URI, it can add participants in several ways, and [RFC4579] covers those too 🦋
Some environments are super strict about how fast a conference has to be set up 😭 They need the UAC to ask for an ad hoc conference and give the conference server the starting list of participants in one single operation. This document shows how to pull that off using the URI-list transport mechanism in SIP messages from [RFC5363] 🎀
2. Terminology ✨
Here's the lowdown on the key words. 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 [RFC2119] 🌈
3. User Agent Client Procedures ✨
So here's the plan for a UAC that wants its squad in the very first INVITE 🫶 It adds a body whose disposition type is recipient-list (defined in [RFC5363]). That body holds a URI list of the participants the UAC wants the conference server to invite. On top of that, the UAC MUST include the recipient-list-invite option-tag in a Require header field. That option-tag is registered with IANA in Section 8 💖 Then the UAC sends this INVITE request to the conference factory URI 🧚
The INVITE transaction is also part of an offer/answer exchange that sets up a session between the UAC and the conference server, as specified in [RFC4579]. So the INVITE request may carry a multipart body: a session description and a URI list 💜
3.1. Response Handling ✨
Here's the tea ☕ The status code in the response to the INVITE does not tell you whether the conference server actually got the users in the URI list into the conference 😳 A 200 (OK) response only means three things: the conference was created successfully, the UAC that sent the INVITE is in the conference, and the server understood the URI list. If the UAC wants to know what's going on with the other users, it SHOULD use general conference mechanisms, like the conference package defined in [RFC4575] 👑
3.2. Re-INVITE Request Generation ✨
By now we've covered how to put a URI list in an initial INVITE to a conference server 🍓 Once the INVITE-initiated dialog between the UAC and the conference server is up, the UAC can send later INVITE requests (usually called re-INVITE requests). For example, it might change the characteristics of the media it's exchanging with the server 🦋
Right now, recipient-list bodies don't have any semantics in re-INVITE requests, although future extensions may define them 🙈 So UACs SHOULD NOT include recipient-list bodies in re-INVITE requests sent to a conference server 💀
Note that an initial INVITE request and a re-INVITE request are different in one big way. The initial INVITE goes to the conference factory URI, but the re-INVITE goes to the URI the server gave in aContactheader field when the dialog was set up. So from the UAC's point of view, the resource behind the first URI supportsrecipient-listbodies, while the resource behind the second one does not 🌸
4. URI-List Document Format ✨
As [RFC5363] explains, URI-list services like this conferencing one need to specify a default format for the recipient-list bodies they use 🧚
For conferencing UAs (User Agents), the default format for recipient-list bodies is the XML resource list format from [RFC4826], extended with the "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" from [RFC5364] 💖 So conferencing UACs generating recipient-list bodies MUST support both of these formats and MAY support other formats. Conferencing servers that can handle recipient-list bodies MUST support both of these formats and MAY support other formats 🎀
As [RFC5364] describes, each URI can be tagged with a copyControl attribute set to "to", "cc", or "bcc". That tells you the role the recipient plays when they get the INVITE request ✨ URIs can also get an anonymize attribute, which stops the conference server from revealing the target URI in a URI list 🫣
[RFC5364] also defines a recipient-list-history body that holds the list of recipients 📜 The default format for recipient-list-history bodies for conferencing UAs is also the XML resource list document from [RFC4826], extended with the [RFC5364] copy control stuff. So conferencing UACs able to generate recipient-list-history bodies MUST support these formats and MAY support others. Conferencing UAs able to understand recipient-list-history MUST support these formats and MAY support others. Conferencing servers able to handle recipient-list-history bodies MUST support these formats and MAY support others 🌈
Now, the XML resource list document from [RFC4826] has features like hierarchical lists and entries pulled in by reference relative to the XML Configuration Access Protocol (XCAP) root URI 🤯 This conferencing service doesn't need any of that. It just needs to move a flat list of URIs between a UA (User Agent) and the conference server 🦋 So when using the default resource list document, conferencing UAs SHOULD use flat lists (no hierarchical lists) and SHOULD NOT use <entry-ref> elements 🙅♀️ If a conference factory application gets a URI list with more info than that, it MAY discard all the extra information 🧹
Figure 1 is a little example of a flat list that follows the XML resource list document from [RFC4826], extended with [RFC5364] 💅
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
</list>
</resource-lists>
Figure 1: URI listPart 2 is coming next, with Section 5 onward 🫶🦋
5. Conference Server Procedures 🎀
Okay so conference servers that can take in INVITE requests with a 'recipient-list' body SHOULD include a 'recipient-list-invite' option-tag in a Supported header field when they respond to OPTIONS requests. 💖
When a conference server gets an INVITE request with a 'recipient-list' body (the kind described in Section 3), it MUST follow the rules in [RFC4579] to create ad hoc conferences. ✨ Once that ad hoc conference exists, the conference server SHOULD try to add the people in the URI list to it, as if they had asked to join using any of the methods in [RFC4579]. Main character energy, fr 👑
The INVITE transaction is also part of an offer/answer exchange that sets up a session between the UAC and the conference server, as [RFC4579] lays out. 🦋 So the INVITE request can carry a multipart body with a session description AND a URI list, both together.
After the conference server has made the ad hoc conference and tried adding the first batch of participants, it just acts like a regular conference server, and it MUST keep following the rules in [RFC4579]. 🌸
The incoming INVITE will have a URI-list body or a reference to one (as specified in [RFC5363]) with the actual list of recipients. 🍓 If that list has resources tagged with the 'copyControl' attribute set to "to" or "cc", the conference server SHOULD put a URI list in each outgoing INVITE request. That list SHOULD be formatted using the XML format for resource lists (from [RFC4826]) plus the copyControl extension from [RFC5364]. It's giving organized 💅
The URI-list service MUST follow the procedures in [RFC5364] for handling the 'anonymize', 'count', and 'copyControl' attributes. No skipping, bestie 🫶
If the conference server does include a URI list in an outgoing INVITE request, it MUST include a Content-Disposition header field (specified in [RFC2183]) whose value is 'recipient-list-history', plus a 'handling' parameter (specified in [RFC3204]) set to "optional". 🧚 This part is literally non-negotiable, iykyk 💀
5.1. Re-INVITE Request Handling
Right now there are no semantics attached to 'recipient-list' bodies in re-INVITE requests, though future extensions may define them. 🙈 So if a conference server gets a re-INVITE with a 'recipient-list' body (and therefore a 'recipient-list-invite' option-tag), it follows standard SIP procedures and rejects it with a 420 (Bad Extension). That response carries an Unsupported header field listing the 'recipient-list-invite' option-tag. 🚫💜
Why? The resource identified by the conference URI doesn't actually support this extension. 🥺 The resource identified by the conference factory URI does, though, so it would include the 'recipient-list-invite' option-tag in things like its responses to OPTIONS requests. Factory gets the glow-up, conference URI does not 💅
6. Example 🌈
Figure 2 shows how it all works. A UAC sends an INVITE request (F1) with an SDP body and a URI list to the conference server. ✨ The conference server replies with a 200 (OK) response, then generates an INVITE request to each UAS (User Agent Server) whose URI is in the URI list. Each outgoing INVITE includes SDP and a manipulated URI list. 🎀
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | confer. | |SIP UAS | |SIP UAS | |SIP UAS |
| | | server | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 INVITE | | | |
| ---------------->| | | |
| F2 200 OK | | | |
|<---------------- | F3 INVITE | | |
| | ------------->| | |
| | F4 INVITE | | |
| | ------------------------>| |
| | F5 INVITE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 2: Example of operationFigure 3 shows the INVITE request F1 in detail. It carries a multipart/mixed body with two parts: an application/sdp body that describes the session, and an application/resource-lists+xml body with the list of target URIs. 🦋
INVITE sip:conf-fact@example.com SIP/2.0
Via: SIP/2.0/TCP atlanta.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conf Factory" <sip:conf-fact@example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 INVITE
Contact: <sip:alice@atlanta.example.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Require: recipient-list-invite
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copyControl">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
--boundary1--Figure 3: INVITE request received at the conference server
The INVITE requests F3, F4, and F5 are basically the same vibe. 💕 Each one has a multipart/mixed body with two parts: an application/sdp body describing the session, and an application/resource-lists+xml body containing the recipients. 🌸 The resource-lists bodies are NOT identical to the one in F1, though, because the conference server anonymized the URIs tagged with 'anonymize' and removed the URIs tagged with a "bcc" 'copyControl' attribute. 🙈 Figure 4 shows what message F3 looks like.
INVITE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8as454
Max-Forwards: 70
To: <sip:bill@example.com>
From: Conference Server <sip:conf34@example.com>;tag=234332
Call-ID: 389sn189dasdf
CSeq: 1 INVITE
Contact: <sip:conf34@conference.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog, conference
Accept: application/sdp, message/sipfrag
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690
--boundary1
Content-Type: application/sdp
v=0
o=conf 2890844343 2890844343 IN IP4 conference.example.com
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 40002 RTP/AVP 31
a=rtpmap:31 H261/90000
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
--boundary1--Figure 4: INVITE request sent by the conference server
7. Security Considerations 🔐
This document is about setting up SIP conferences using a URI list that's contained in the request. 💜 Both conferencing and URI-list services have their own specific security needs, and we're summarizing them here. Conferences usually have authorization rules about who can or can't join, what kinds of media can or can't be used, and so on. The focus uses this info to let people in or turn them away. 🚪 It is RECOMMENDED that these kinds of authorization rules are used to secure a SIP conference. 🛡️
For the focus to use that authorization info, it has to be able to authenticate potential participants. 😤 Normal SIP mechanisms work here, including Digest authentication and certificates. ✨ The conference-specific security requirements get a deeper dive in the requirements and framework documents, [RFC4245] and [RFC4353].
Creating a conference from a list adds some extra security concerns. 😱 "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services" [RFC5363] covers issues related to SIP URI-list services. Since a conference server that sends INVITE requests to a set of users is acting as a URI-list service, conference server implementations that handle lists MUST follow the security-related rules in [RFC5363]. Those rules include opt-in lists and mandatory authentication and authorization of clients. 🔒💅
8. IANA Considerations 📋
This document defines the 'recipient-list-invite' SIP option-tag. 🦋 It has been registered in the Option Tags subregistry under the SIP parameter registry. The registration description is below:
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-invite | The body contains a list of | [RFC5366] |
| | URIs that indicates the | |
| | recipients of the SIP INVITE | |
| | request | |
+------------------------+------------------------------+-----------+Table 1: Registration of the 'recipient-list-invite' option-tag in SIP
9. Acknowledgments ✨
Huge thanks to Cullen Jennings, Hisham Khartabil, Jonathan Rosenberg, and Keith Drage, who gave really useful comments on this doc 🫶. Miguel Garcia-Martin put together the dependencies for the copyControl attribute extension, which is literally iconic work 👑.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents", BCP
119, RFC 4579, August 2006.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) URI-
List Services", RFC 5363, October 2008.
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup
Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists", RFC 5364, October
2008.10.2. Informative References
[RFC4245] Levin, O. and R. Even, "High-Level Requirements for
Tightly Coupled SIP Conferencing", RFC 4245, November
2005.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, February
2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
Session Initiation Protocol (SIP) Event Package for
Conference State", RFC 4575, August 2006.Authors' Addresses
Here's where you can find the authors 💌
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Alan Johnston
Avaya
St. Louis, MO 63124
USA
EMail: alan@sipstation.comFull Copyright Statement
Copyright (C) The IETF Trust (2008) 🦋.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This is the legal part, so here it is word for word:
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Basically, the document comes as-is, and the contributors, their organizations, the Internet Society, the IETF Trust, and the IETF all say they're not promising anything beyond that. 💀
Intellectual Property
Okay, IP stuff 🌸. The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) might cover the technology in this document, or how much of a license might or might not be available for it. It also hasn't claimed to have independently looked for any of those rights. For the procedures around rights in RFC documents, check out BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr.
And if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, please tell the IETF at ietf-ipr@ietf.org 🫶✨.
📦 where this page comes from
- ietf: rfc5366 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms