Network Working Group L. Tian Internet-Draft Q. Sun Expires: October 15, 2007 Huawei Technologies April 13, 2007 Session Initiation Protocol (SIP) INVITE with Conference Info draft-linyi-sipping-invite-with-conf-info-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 15, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Tian & Sun Expires October 15, 2007 [Page 1] Internet-Draft invite with conference info April 2007 Abstract This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Analysis . . . . . . . . . . . . . . . . . . . . 5 4. INVITE: Sending conference info to Conference Server . . . . . 6 4.1. Conference Info Format . . . . . . . . . . . . . . . . . . 6 4.1.1. Conference Info Format derived from Conference State Package . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Conference Info Format derived from XCON Data Model . 7 4.2. UAC Procedures . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. re-INVITE Request Generation . . . . . . . . . . . . . 9 4.3. Conference Server Procedures . . . . . . . . . . . . . . . 9 4.3.1. re-INVITE Request Handling . . . . . . . . . . . . . . 10 5. INVITE: Sending URI-List with conference info to Conference Server . . . . . . . . . . . . . . . . . . . . . . 11 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Creation of Conference with initial Conference Info . . . 12 6.2. Creation of a Conference with initial URI-List and Conference Info . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. MIME Information . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. History of change . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Tian & Sun Expires October 15, 2007 [Page 2] Internet-Draft invite with conference info April 2007 1. Introduction RFC XXX {URI List Conferencing} [2] defines a mechanism for UAC to provide a conference server with the initial set of participants to address the specific need as follow: 'some environments have tough requirements regarding conference establishment time'. With respect to this kind of consideration, this specification further defines a mechanism for UAC to be able to provide the conference server with the initial conference information and policy. This specification also provides a mechanism for Conference Server to relay the conference infromation and policy to the new participants being invited to allow them be aware of the information regarding this conference at the beginning. The mechanism defined in this specification can be used either standalone or together with other mechanisms, e.g. URI-List conferencing mechanism. Tian & Sun Expires October 15, 2007 [Page 3] Internet-Draft invite with conference info April 2007 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 RFC 2119 [3] This document uses the conferencing terminology defined in RFC 4353 [8] "conferencing Framework". Tian & Sun Expires October 15, 2007 [Page 4] Internet-Draft invite with conference info April 2007 3. Requirements Analysis some environments have tough requirements regarding conference establishment time. This is true especially when a user wants to create a conference in ad hoc manner. In addition user may only want very simple conference information and policy, for example the subject and maximum numbers of participants, to be provided for an ad hoc conference via only one operation. In this case they rarely desire to manipulate the conference policy during the conference. In current art there is no mechanism for new participants to be aware of the conference information they are being invited to. It causes difficulty for them to decide whether to accept this invitation which may not fall into their interest. The requirements to support invitation with conference info may be summarized as follows: REQ 1: The conference mechanism MUST allow the invoker to provide the Conference Server with the initial conference information and policy in order to create an ad-hoc conference. REQ 2: The conference mechanism MUST allow the Conference Server to relay the conference information and policy to new participants being invited. Tian & Sun Expires October 15, 2007 [Page 5] Internet-Draft invite with conference info April 2007 4. INVITE: Sending conference info to Conference Server RFC 4575 [4] defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for SIP specific conferencing. RFC XXX {XCON Data Model} [5] extends the data format to support more call signaling protocols besides SIP and cover the functionality defined in the XCON conferencing framework. A sub-set of both data formats can be used to represent conference information and policy, e.g. and . The conference information and policy can be included in the body of initial SIP INVITE request to create an ad-hoc conference. Hence it can be included in the follow-up SIP INVITE requests to allow new participants being invited to be aware of. 4.1. Conference Info Format The sub set of data format defined in RFC 4575 [4] and extended in RFC XXX {XCON Data Model} [5] can be used to represent the conference info and policy which could be carried in SIP INVITE method. The amount of data MUST be limited to avoid overload of SIP message. 4.1.1. Conference Info Format derived from Conference State Package Following is the sub set of data format defined in RFC 4575 [4] representing the conference information and policy. | |-- | |-- | |-- | |-- | |-- | | | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- Figure 1: Conference Info Format derived from Conference State Package Tian & Sun Expires October 15, 2007 [Page 6] Internet-Draft invite with conference info April 2007 The 'state' and 'version' attributes SHOULD NOT be used. Other elements defined in RFC 4575 [4] SHOULD NOT be included in initial SIP INVITE request since they would be generated by the Conference Server, but MAY be included in follow-up SIP INVITE requests to new participants. 4.1.2. Conference Info Format derived from XCON Data Model Following is the sub set of data format defined in RFC XXX {XCON Data Model} [5] representing the conference information and policy. Tian & Sun Expires October 15, 2007 [Page 7] Internet-Draft invite with conference info April 2007 | |--! | |-- | |-- | |-- | |-- | |-- | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | |-- | |-- | |-- | |-- | |-- | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- Figure 2: Structure of Conference Info derived from XCON Data Model Other elements defined in RFC XXX {XCON Data Model} [5] SHOULD NOT be Tian & Sun Expires October 15, 2007 [Page 8] Internet-Draft invite with conference info April 2007 included in initial SIP INVITE request since they would be generated by the Conference Server, but MAY be included in follow-up SIP INVITE requests to new participants. 4.2. UAC Procedures A UAC that wants to include the initial conference information and policy in its initial INVITE request MUST add a body whose disposition type is 'conference-info' as defined in section xxx of this specification. Additionally, the UAC MUST include the 'conference-info-invite' option-tag, which is registered with the IANA in Section xxx in a Require header field. The UAC sends this INVITE request to the conference factory URI. A 200 (OK) response means that the conference was created successfully, that the UAC that generated the INVITE request is in the conference, and that the server understood the conference information. 4.2.1. re-INVITE Request Generation The previous section has specified how to include the conference information 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 re-INVITE requests to the conference server to, modify the characteristics of the media exchanged with the server. At this point, there are no semantics associated with conference info bodies in re-INVITE requests(although future extensions may define them). Therefore, UACs SHOULD NOT include conference info bodies in re-INVITE requests sent to a conference server. 4.3. Conference Server Procedures Conference Server that is able to receive and process INVITE requests with a 'conference-info' body MUST include a 'conference-info-invite' option-tag in a Supported header field when responding to OPTIONS requests. On reception of an INVITE request containing a 'conference-info' body as described in Section 3, a conference server MUST follow the rules described in RFC 4579 [1] to create ad-hoc conferences. Once it is requested to add new participants into this specific conference, the Conference Server MUST attempt to relay the conference info which may be manipulated to the new participants being invited using an INVITE- contained conference info. Tian & Sun Expires October 15, 2007 [Page 9] Internet-Draft invite with conference info April 2007 If the conference server includes conference info in an outgoing INVITE request, it MUST include a Content-Disposition header field (which is specified in RFC 2183 [6] ) with the value set to 'conference-info-history' and a 'handling' parameter (as specified in RFC 3204 [7] ) set to "optional". If element presents, the conference server MUST reject the requests to add new participants to the conference when the number of participants has reached the number specified in this element. 4.3.1. re-INVITE Request Handling At this point, there are no semantics associated with conference info bodies in re-INVITE requests (although future extensions may define them). Therefore, a Conference Server receiving a re-INVITE request with a conference info body and, consequently, a 'conference-info- invite' option-tag, following standard SIP procedures, rejects it with a 420 (Bad Extension), which carries an Unsupported header field listing the 'conference-info-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 'conference- info-invite' option-tag in, for example, responses to OPTIONS requests. Tian & Sun Expires October 15, 2007 [Page 10] Internet-Draft invite with conference info April 2007 5. INVITE: Sending URI-List with conference info to Conference Server The mechanism defined in section 4 of this specification can be used together with other mechanisms, e.g. URI-List conferencing mechanism defined in RFC XXX {URI List Conferencing} [2] . The initial INVITE request can carry a 'multipart/mixed' body composed of three bodies: o 'application/sdp' body: describes the session; o 'application/resource-lists+xml' body: describes the list of target URIs; o 'application/conference-info+xml' body: contains the conference information. The UAC MUST ensure the number of URIs in the URI-List will not exceed the number specified in element if it presents. The UAC and Conference Server MUST follow the procedures defined in RFC XXX {URI List Conferencing} [2] and section 4 of this specification respectively. Tian & Sun Expires October 15, 2007 [Page 11] Internet-Draft invite with conference info April 2007 6. Example 6.1. Creation of Conference with initial Conference Info Figure 3 shows an example of ad-hoc conference creation with initial conference information and policy. A UAC sends an INVITE request F1 that contains SDP body and conference info to the Conference Server. The Conference Server answers with a 200 (OK) response. Then Conference Server is requested to add new participant Bob to the specified conference using REFER method. The UAC sends a REFER request F3 to the conference URI with a Refer-To containing the URI of Bob. The Conference Server sends an INVITE request F7 to Bob containing the manipulated conference info. Then Bob can know the information of this specific conference when he receives the request F3, such as subject and conference presentations,and decides to join it. Alice Conference Server Bob | | | | F1:INVITE sip:Conf-Factory with initial conference info | |----------------------------->| | | F2:200 OK Contact:Conf-ID;isfocus | |<-----------------------------| | | | | | F3:REFER sip:Conf-ID Refer-To:Bob | |----------------------------->| | | F4:202 Accepted | | |<-----------------------------| | | F5:NOTIFY (Trying) | | |<-----------------------------| | | F6:200 OK F4 | | |----------------------------->| | | | F7:INVITE with conference info| | |------------------------------>| | | F8:200 OK | | |<------------------------------| | | | Figure 3: Creation of a conference with initial conference info using ad-hoc SIP method Figure 4 shows an example of the INVITE request F1, which carries a 'multipart/mixed' body composed of two other bodies: o 'application/sdp' body: describes the session; Tian & Sun Expires October 15, 2007 [Page 12] Internet-Draft invite with conference info April 2007 o 'application/conference-info+xml' body: contains the conference information. INVITE sip:32132219811205@conf.example.com SIP/2.0 Via: SIP/2.0/TCP beijing.example.com ;branch=z9hG4bKa38ssa8s Max-Forwards: 70 To: sip:32132219811205@conf.example.com From: Alice ;tag=13323 Call-ID: b01766e67c4b48af234 CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog Accept: application/sdp, message/sipfrag Require: conference-info-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: ... --boundary1 Content-Type: application/sdp (SDP not shown) --boundary1 Content-Type: application/conference-info+xml Content-Disposition: conference-info Agenda: This month's goals http://sharepoint/salesgroup/ web-page 10 Figure 4: Initial INVITE request received at the Conference Server Figure 5 shows an example of the INVITE request F7, which carries a 'multipart/mixed' body composed of two other bodies: Tian & Sun Expires October 15, 2007 [Page 13] Internet-Draft invite with conference info April 2007 o 'application/sdp' body: describes the session; o 'application/conference-info+xml' body: contains the conference information. This body may not equal to the 'application/ conference-info+xml' body in the initial INVITE request F1 because the Conference Server may manipulate it. Elements other than those listed in section 4.1 may present in manipulated conference info. For example the Conference Server can fill the "entity" attribute of with appropriate conference URI. It can also add ,, etc. Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKt34932hw Max-Forwards: 70 To: From: Call-ID: 849392fklgl43 CSeq: 1 INVITE Contact: ;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Accept: application/sdp, message/sipfrag Require: conference-info-invite Supported: replaces, join Content-Type: multipart/mixed;boundary="boundary1" Content-Length: ... --boundary1 Content-Type: application/sdp (SDP not shown) --boundary1 Content-Type: application/conference-info+xml Content-Disposition: conference-info-history; handling=optional Agenda: This month's goals http://sharepoint/salesgroup/ web-page Tian & Sun Expires October 15, 2007 [Page 14] Internet-Draft invite with conference info April 2007 10 Macy's Host http://sharepoint/salesgroup/hosts/ sip:macy@conf.example.com 1 Alice connected dialed-in 2007-03-18T20:00:00Z main audio audio 534232 sendrecv 6.2. Creation of a Conference with initial URI-List and Conference Info Figure 6 shows an example of ad-hoc conference creation with initial URI-List and conference info. A UAC sends an INVITE request F1 that contains initial participants list and conference info to the Conference Server. The Conference Server answers with a 200 (OK) response. Then Conference Server generates an INVITE request to each of the participants identifies by the URIs included in the URI-list. The Conference Server includes a manipulated URI-list and conference info in each of the outgoing INVITE requests. Tian & Sun Expires October 15, 2007 [Page 15] Internet-Draft invite with conference info April 2007 Alice Conference Server Bob Alice Carol | | | | | | F1:INVITE with URI-List and conference info | | |---------------------->| | | | | F2:200 OK | | | | |<----------------------| | | | | Conference Server relays manipulated URI-List and confernce info | | F3:INVITE | | | | |---------------->| | | | | F4:200 OK | | | | |<----------------| | | | | F5:INVITE | | | | |------------------------->| | | | F6:200 OK | | | | |<-------------------------| | | | F7:INVITE | | | | |---------------------------------->| | | F8:200 OK | | | | |<----------------------------------| | | | | | Figure 6: Creation of a conference with initial URI-List and conference info Tian & Sun Expires October 15, 2007 [Page 16] Internet-Draft invite with conference info April 2007 7. Security Considerations .... Tian & Sun Expires October 15, 2007 [Page 17] Internet-Draft invite with conference info April 2007 8. IANA Considerations This document defines the 'conference-info-invite' SIP option-tag. It should be registered in the Option Tags subregistry under the SIP parameter registry. The following is the description to be used in the registration. +------------------------+------------------------------+-----------+ | Name | Description | Reference | +------------------------+------------------------------+-----------+ | conference-info-invite | The body contains the | [RFC XXXX]| | | conference information and | | | | poliy for a specific | | | | conference. | | +------------------------+------------------------------+-----------+ Figure 3: Participant Requests That the Focus Add a Participant to the Conference. Tian & Sun Expires October 15, 2007 [Page 18] Internet-Draft invite with conference info April 2007 9. Acknowledges ....... Tian & Sun Expires October 15, 2007 [Page 19] Internet-Draft invite with conference info April 2007 10. MIME Information The MIME type for the Conference Info is: application/ conference-info+xml Tian & Sun Expires October 15, 2007 [Page 20] Internet-Draft invite with conference info April 2007 11. References 11.1. Normative References [1] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", RFC 4579, August 2006. [2] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC xxxx, January 2007. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [5] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC xxxx, January 2007. [6] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field", RFC 2183, August 1997. [7] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 3204, December 2001. 11.2. Informative References [8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. Tian & Sun Expires October 15, 2007 [Page 21] Internet-Draft invite with conference info April 2007 Appendix A. History of change This is the first version of this draft. Tian & Sun Expires October 15, 2007 [Page 22] Internet-Draft invite with conference info April 2007 Authors' Addresses Linyi Tian Huawei Technologies Bantian Longgang Shenzhen, Guandong 518129 P.R China Phone: +86 755 28780808 Email: tianlinyi@huawei.com Qian Sun Huawei Technologies Bantian Longgang Shenzhen, Guandong 518129 P.R China Phone: +86 755 28780808 Email: sunqian@huawei.com Tian & Sun Expires October 15, 2007 [Page 23] Internet-Draft invite with conference info April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Tian & Sun Expires October 15, 2007 [Page 24]