From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5366.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc5366.txt (limited to 'doc/rfc/rfc5366.txt') diff --git a/doc/rfc/rfc5366.txt b/doc/rfc/rfc5366.txt new file mode 100644 index 0000000..ddd534f --- /dev/null +++ b/doc/rfc/rfc5366.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group G. Camarillo +Request for Comments: 5366 Ericsson +Category: Standards Track A. Johnston + Avaya + October 2008 + + + Conference Establishment Using Request-Contained Lists + in the Session Initiation Protocol (SIP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes how to create a conference using SIP URI-list + services. In particular, it describes a mechanism that allows a User + Agent Client to provide a conference server with the initial list of + participants using an INVITE-contained URI list. + +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 ...................................12 + + + + + + + + + +Camarillo & Johnston Standards Track [Page 1] + +RFC 5366 INVITE-Contained Lists October 2008 + + +1. Introduction + + Section 5.4 of [RFC4579] describes how to create a conference using + ad hoc SIP [RFC3261] methods. The client sends an INVITE request to + a conference factory URI and receives the actual conference URI, + which contains the "isfocus" feature tag, in the Contact header field + of a response -- typically a 200 (OK) response. + + Once the UAC (User Agent Client) obtains the conference URI, it can + add participants to the newly created conference in several ways, + which are described in [RFC4579]. + + Some environments have tough requirements regarding conference + establishment time. They require the UAC to be able to request the + creation of an ad hoc conference and to provide the conference server + with the initial set of participants in a single operation. This + document describes how to meet this requirement using the mechanism + to transport URI lists in SIP messages described in [RFC5363]. + +2. Terminology + + 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 + + A UAC that wants to include the set of initial participants in its + initial INVITE request to create an ad hoc conference adds a body + whose disposition type is 'recipient-list', as defined in [RFC5363], + with a URI list that contains the participants that the UAC wants the + conference server to invite. Additionally, the UAC MUST include the + 'recipient-list-invite' option-tag (which is registered with the IANA + in Section 8) in a Require header field. The UAC sends this INVITE + request to the conference factory URI. + + The INVITE transaction is also part of an offer/answer exchange that + will establish a session between the UAC and the conference server, + as specified in [RFC4579]. Therefore, the INVITE request may need to + carry a multipart body: a session description and a URI list. + +3.1. Response Handling + + The status code in the response to the INVITE request does not + provide any information about whether or not the conference server + was able to bring the users in the URI list into the conference. + That is, a 200 (OK) response means that the conference was created + successfully, that the UAC that generated the INVITE request is in + + + +Camarillo & Johnston Standards Track [Page 2] + +RFC 5366 INVITE-Contained Lists October 2008 + + + the conference, and that the server understood the URI list. If the + UAC wishes to obtain information about the status of other users in + the conference, it SHOULD use general conference mechanisms, such as + the conference package, which is defined in [RFC4575]. + +3.2. Re-INVITE Request Generation + + The previous sections have specified how to include a URI list in an + initial INVITE request to a conference server. Once the INVITE- + initiated dialog between the UAC and the conference server has been + established, the UAC can send subsequent INVITE requests (typically + referred to as re-INVITE requests) to the conference server to, for + example, modify the characteristics of the media exchanged with the + server. + + At this point, there are no semantics associated with 'recipient- + list' bodies in re-INVITE requests (although future extensions may + define them). Therefore, UACs SHOULD NOT include 'recipient-list' + bodies in re-INVITE requests sent to a conference server. + + Note that a difference between an initial INVITE request and a + re-INVITE request is that while the initial INVITE request is sent + to the conference factory URI, the re-INVITE request is sent to + the URI provided by the server in a Contact header field when the + dialog was established. Therefore, from the UAC's point of view, + the resource identified by the former URI supports 'recipient- + list' bodies, while the resource identified by the latter does not + support them. + +4. URI-List Document Format + + As described in [RFC5363], specifications of individual URI-list + services, like the conferencing service described here, need to + specify a default format for 'recipient-list' bodies used within the + particular service. + + The default format for 'recipient-list' bodies for conferencing UAs + (User Agents) is the XML resource list format (which is specified in + [RFC4826]) extended with the "Extensible Markup Language (XML) Format + Extension for Representing Copy Control Attributes in Resource Lists" + [RFC5364]. Consequently, conferencing UACs generating 'recipient- + list' bodies MUST support both of these formats and MAY support other + formats. Conferencing servers able to handle 'recipient-list' bodies + MUST support both of these formats and MAY support other formats. + + As described in "Extensible Markup Language (XML) Format Extension + for Representing Copy Control Attributes in Resource Lists" + [RFC5364], each URI can be tagged with a 'copyControl' attribute set + + + +Camarillo & Johnston Standards Track [Page 3] + +RFC 5366 INVITE-Contained Lists October 2008 + + + to either "to", "cc", or "bcc", indicating the role in which the + recipient will get the INVITE request. Additionally, URIs can be + tagged with the 'anonymize' attribute to prevent the conference + server from disclosing the target URI in a URI list. + + In addition, "Extensible Markup Language (XML) Format Extension for + Representing Copy Control Attributes in Resource Lists" [RFC5364] + defines a 'recipient-list-history' body that contains the list of + recipients. The default format for 'recipient-list-history' bodies + for conferencing UAs is also the XML resource list document format + specified in [RFC4826] extended with "Extensible Markup Language + (XML) Format Extension for Representing Copy Control Attributes in + Resource Lists" [RFC5364]. Consequently, 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. + + Nevertheless, the XML resource list document specified in [RFC4826] + provides features, such as hierarchical lists and the ability to + include entries by reference relative to the XML Configuration Access + Protocol (XCAP) root URI, that are not needed by the conferencing + service defined in this document, which only needs to transfer a flat + list of URIs between a UA (User Agent) and the conference server. + Therefore, when using the default resource list document, + conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists) + and SHOULD NOT use elements. A conference factory + application receiving a URI list with more information than what has + just been described MAY discard all the extra information. + + Figure 1 shows an example of a flat list that follows the XML + resource list document (specified in [RFC4826]) extended with + "Extensible Markup Language (XML) Format Extension for Representing + Copy Control Attributes in Resource Lists" [RFC5364]. + + + + + + + + + + + Figure 1: URI list + + + + +Camarillo & Johnston Standards Track [Page 4] + +RFC 5366 INVITE-Contained Lists October 2008 + + +5. Conference Server Procedures + + Conference servers that are able to receive and process INVITE + requests with a 'recipient-list' body SHOULD include a 'recipient- + list-invite' option-tag in a Supported header field when responding + to OPTIONS requests. + + On reception of an INVITE request containing a 'recipient-list' body + as described in Section 3, a conference server MUST follow the rules + described in [RFC4579] to create ad hoc conferences. Once the ad hoc + conference is created, the conference server SHOULD attempt to add + the participants in the URI list to the conference as if their + addition had been requested using any of the methods described in + [RFC4579]. + + The INVITE transaction is also part of an offer/answer exchange that + will establish a session between the UAC and the conference server, + as specified in [RFC4579]. Therefore, the INVITE request may carry a + multipart body: a session description and a URI list. + + Once the conference server has created the ad hoc conference and has + attempted to add the initial set of participants, the conference + server behaves as a regular conference server and MUST follow the + rules in [RFC4579]. + + The incoming INVITE request will contain a URI-list body or reference + (as specified in [RFC5363]) with the actual list of recipients. If + this URI list includes resources tagged with the 'copyControl' + attribute set to a value of "to" or "cc", the conference server + SHOULD include a URI list in each of the outgoing INVITE requests. + This list SHOULD be formatted according to the XML format for + representing resource lists (specified in [RFC4826]) and the + copyControl extension specified in [RFC5364]. + + The URI-list service MUST follow the procedures specified in + [RFC5364] with respect to the handling of the 'anonymize', 'count', + and 'copyControl' attributes. + + If the conference server includes a URI list in an outgoing INVITE + request, it MUST include a Content-Disposition header field (which is + specified in [RFC2183]) with the value set to 'recipient-list- + history' and a 'handling' parameter (as specified in [RFC3204]) set + to "optional". + + + + + + + + +Camarillo & Johnston Standards Track [Page 5] + +RFC 5366 INVITE-Contained Lists October 2008 + + +5.1. Re-INVITE Request Handling + + At this point, there are no semantics associated with 'recipient- + list' bodies in re-INVITE requests (although future extensions may + define them). Therefore, a conference server receiving a re-INVITE + request with a 'recipient-list' body and, consequently, a + 'recipient-list-invite' option-tag, following standard SIP + procedures, rejects it with a 420 (Bad Extension), which carries an + Unsupported header field listing the 'recipient-list-invite' option- + tag. + + This is because the resource identified by the conference URI does + not actually support this extension. On the other hand, the + resource identified by the conference factory URI does support + this extension and, consequently, would include the 'recipient- + list-invite' option-tag in, for example, responses to OPTIONS + requests. + +6. Example + + Figure 2 shows an example of operation. A UAC sends an INVITE + request (F1) that contains an SDP body and a URI list to the + conference server. The conference server answers with a 200 (OK) + response and generates an INVITE request to each of the UASs (User + Agent Servers) identified by the URIs included in the URI list. The + conference server includes SDP and a manipulated URI list in each of + the outgoing INVITE requests. + + + + + + + + + + + + + + + + + + + + + + + + +Camarillo & Johnston Standards Track [Page 6] + +RFC 5366 INVITE-Contained Lists October 2008 + + + +--------+ +---------+ +--------+ +--------+ +--------+ + |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 operation + + Figure 3 shows an example of the INVITE request F1, which carries a + multipart/mixed body composed of two other bodies: an application/sdp + body that describes the session and an application/resource-lists+xml + body that contains 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" + From: Alice ;tag=32331 + Call-ID: d432fa84b4c76e66710 + CSeq: 1 INVITE + Contact: + 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 + + + + + +Camarillo & Johnston Standards Track [Page 7] + +RFC 5366 INVITE-Contained Lists October 2008 + + + --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 + + + + + + + + + + + + + + --boundary1-- + + Figure 3: INVITE request received at the conference server + + The INVITE requests F3, F4, and F5 are similar in nature. All those + INVITE requests contain a multipart/mixed body that is composed of + two other bodies: an application/sdp body describing the session and + an application/resource-lists+xml containing the list of recipients. + The application/resource-lists+xml bodies are not equal to the + application/resource-lists+xml included in the received INVITE + request F1, because the conference server has anonymized those URIs + tagged with the 'anonymize' attribute and has removed those URIs + tagged with a "bcc" 'copyControl' attribute. Figure 4 shows an + example of the message F3. + + + + +Camarillo & Johnston Standards Track [Page 8] + +RFC 5366 INVITE-Contained Lists October 2008 + + + INVITE sip:bill@example.com SIP/2.0 + Via: SIP/2.0/TCP conference.example.com + ;branch=z9hG4bKhjhs8as454 + Max-Forwards: 70 + To: + From: Conference Server ;tag=234332 + Call-ID: 389sn189dasdf + CSeq: 1 INVITE + Contact: ;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 + + + + + + + + + + + --boundary1-- + + Figure 4: INVITE request sent by the conference server + + + + +Camarillo & Johnston Standards Track [Page 9] + +RFC 5366 INVITE-Contained Lists October 2008 + + +7. Security Considerations + + This document discusses setup of SIP conferences using a request- + contained URI list. Both conferencing and URI-list services have + specific security requirements, which are summarized here. + Conferences generally have authorization rules about who can or + cannot join a conference, what type of media can or cannot be used, + etc. This information is used by the focus to admit or deny + participation in a conference. It is RECOMMENDED that these types of + authorization rules be used to provide security for a SIP conference. + + For this authorization information to be used, the focus needs to be + able to authenticate potential participants. Normal SIP mechanisms, + including Digest authentication and certificates, can be used. These + conference-specific security requirements are discussed further in + the requirements and framework documents -- [RFC4245] and [RFC4353]. + + For conference creation using a list, there are some additional + security considerations. "Framework and Security Considerations for + Session Initiation Protocol (SIP) URI-List Services" [RFC5363] + discusses issues related to SIP URI-list services. Given that a + conference server sending INVITE requests to a set of users acts as a + URI-list service, implementations of conference servers that handle + lists MUST follow the security-related rules in [RFC5363]. These + 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 following is the description used in the + registration: + + +------------------------+------------------------------+-----------+ + | 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 + + + + + + +Camarillo & Johnston Standards Track [Page 10] + +RFC 5366 INVITE-Contained Lists October 2008 + + +9. Acknowledgments + + Cullen Jennings, Hisham Khartabil, Jonathan Rosenberg, and Keith + Drage provided useful comments on this document. Miguel Garcia- + Martin assembled the dependencies to the 'copyControl' attribute + extension. + +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. + + + + + + + + + +Camarillo & Johnston Standards Track [Page 11] + +RFC 5366 INVITE-Contained Lists 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 + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + Alan Johnston + Avaya + St. Louis, MO 63124 + USA + + EMail: alan@sipstation.com + + + + + + + + + + + + + + + + + + + + +Camarillo & Johnston Standards Track [Page 12] + +RFC 5366 INVITE-Contained Lists October 2008 + + +Full 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 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Camarillo & Johnston Standards Track [Page 13] + -- cgit v1.2.3