Network Working Group L. Tian Internet-Draft Q. Sun Expires: November 2, 2007 Huawei Technologies Co., Ltd. May 2007 Session Initiation Protocol (SIP) INVITE with Conference Info draft-linyi-sipping-invite-with-conf-info-01 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 November 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Tian & Sun Expires November 2, 2007 [Page 1] Internet-Draft invite with conference info May 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 . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. re-INVITE Request Generation . . . . . . . . . . . . . 8 4.3. Conference Server Procedures . . . . . . . . . . . . . . . 8 4.3.1. re-INVITE Request Handling . . . . . . . . . . . . . . 9 5. INVITE: Sending URI-List with conference info to Conference Server . . . . . . . . . . . . . . . . . . . . . . 10 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Creation of Conference with initial Conference Info . . . 11 6.2. Creation of a Conference with initial URI-List and Conference Info . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. MIME Information . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 Appendix A. History of change . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Tian & Sun Expires November 2, 2007 [Page 2] Internet-Draft invite with conference info May 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'. This specification respects this consideration and further defines a mechanism for UAC to be able to provide the Conference Server with the initial conference information and simple policy. This specification further provides a mechanism for Conference Server to distribute the conference infromation and policy generated from ad hoc conference creation request as the history information to invitees. The mechanism defined in this specification can be used either standalone or together with other mechanisms, e.g. URI-List conferencing mechanism defined in RFC XXX {URI List Conferencing} [2] Tian & Sun Expires November 2, 2007 [Page 3] Internet-Draft invite with conference info May 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 November 2, 2007 [Page 4] Internet-Draft invite with conference info May 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 before the conference is created or during the conference. If URI-List conferencing mechanism is used, the Conference Server will provide URI-List history to invitees by including a 'recipient- list-history' body which contains the manipulated list of invitees. The same principal could be applied here. When Conference Server sends INVITE to invitees, e.g. triggered by REFER request or URI-List conference creation, the Conference Server can provide the them with the conference info and policy as history information. This will help invitees to deterime whether to join this conference which may or may not fall into their interest. In current art when the invitees get an INVITE request with 'isfocus' feature tag he may subscribe to the conference event package as defined in RFC 4575 [4] and get notification before joining. Consider the fact that the main criteria for invitees to determin whether to join a conference may be some simple information, e.g. subject, it is more efficient and convenient for invitees to get information from the incoming INVITE rather than using subscription to the conference event package. This mechanism could be considered as complementary to conference event package subscription mechanism. 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 via one operation. REQ 2: The conference mechanism MUST allow the Conference Server to distribute the conference information and policy to invitees contained in the URI-List. Tian & Sun Expires November 2, 2007 [Page 5] Internet-Draft invite with conference info May 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 invitees 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 messages. 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 November 2, 2007 [Page 6] Internet-Draft invite with conference info May 2007 The 'state' and 'version' attributes SHOULD NOT be used. Other elements defined in RFC 4575 [4] SHOULD NOT be included in initial INVITE request and subsequent INVITE requests to invitees. 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. | |-- | |-- | |-- | |-- | |-- | |-- | | | |-- | | |-- | | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | |-- | |-- | |-- | |-- | |-- | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- 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 November 2, 2007 [Page 7] Internet-Draft invite with conference info May 2007 included in initial INVITE request and subsequent INVITE requests to invitees. 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. There are no semantics associated with conference info bodies in re- INVITE requests. 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 conference. 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. The Conference Server SHOULD include the same conference info from Tian & Sun Expires November 2, 2007 [Page 8] Internet-Draft invite with conference info May 2007 incoming INVITE request to the invitees as the history information using an INVITE-contained conference info request. If some values of initial conference information are changed, the Conference Server SHOULD include history information with updated values in outgoing INVITE requests. The Conference Server SHOULD NOT add new elements to history information. If the Conference Server includes conference info history 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". 4.3.1. re-INVITE Request Handling There are no semantics associated with conference info bodies in re- INVITE requests. 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 November 2, 2007 [Page 9] Internet-Draft invite with conference info May 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 and Conference Server MUST follow the procedures defined in RFC XXX {URI List Conferencing} [2] and section 4 of this specification respectively. In addition, the UAC MUST ensure the number of URIs in the URI-List will not exceed the number specified in element if it presents. A Conference Server receiving a INVITE request with a URI-List body and a conference info body while the number of URIs exceed maximum user count, consequently, rejects it with a 403 (Forbidden). Tian & Sun Expires November 2, 2007 [Page 10] Internet-Draft invite with conference info May 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 conference info history. Then Bob can know the information of this specific conference directly when he receives the request F7, such as subject, 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 | | |------------------------------>| | | 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; o 'application/conference-info+xml' body: contains the initial conference info. Tian & Sun Expires November 2, 2007 [Page 11] Internet-Draft invite with conference info May 2007 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 three other bodies: o 'application/sdp' body: describes the session; o 'application/conference-info+xml' body: contains the conference info history. Tian & Sun Expires November 2, 2007 [Page 12] Internet-Draft invite with conference info May 2007 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 10 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 history in each of the outgoing INVITE requests. Tian & Sun Expires November 2, 2007 [Page 13] Internet-Draft invite with conference info May 2007 Alice Conference Server Bob Alice Carol | | | | | | F1:INVITE with URI-List and conference info | | |---------------------->| | | | | F2:200 OK | | | | |<----------------------| | | | | Conference Server distributes URI-List and confernce info history | | F3:INVITE | | | | |---------------->| | | | | F4:200 OK | | | | |<----------------| | | | | F5:INVITE | | | | |------------------------->| | | | F6:200 OK | | | | |<-------------------------| | | | F7:INVITE | | | | |---------------------------------->| | | F8:200 OK | | | | |<----------------------------------| | | | | | Figure 7: Creation of a conference with initial URI-List and conference info Figure 8 shows an example of the INVITE request F1, which carries a 'multipart/mixed' body composed of three other bodies: o 'application/sdp' body: describes the session; o 'application/resource-lists+xml' body: contains the list of target URIs 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 Tian & Sun Expires November 2, 2007 [Page 14] Internet-Draft invite with conference info May 2007 Require: recipient-list-invite, conference-info-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: ... --boundary1 Content-Type: application/sdp (SDP not shown) --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list --boundary1-- --boundary1 Content-Type: application/conference-info+xml Content-Disposition: conference-info Agenda: This month's goals http://sharepoint/salesgroup/ web-page 10 Tian & Sun Expires November 2, 2007 [Page 15] Internet-Draft invite with conference info May 2007 Figure 8: Initial INVITE request received at the Conference Server The INVITE requests F3, F5, and F7 are similar in nature. Figure 9 shows an example of the INVITE request F3, which carries a 'multipart/mixed' body composed of three other bodies: o 'application/sdp' body: describes the session; o 'application/resource-lists+xml' body: contains the list of target URIs manipulated by Conference Server o 'application/conference-info+xml' body: contains the history conference information. 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: recipient-list-invite, 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/resource-lists+xml Content-Disposition: recipient-list-history; handling=optional Tian & Sun Expires November 2, 2007 [Page 16] Internet-Draft invite with conference info May 2007 --boundary1-- --boundary1 Content-Type: application/conference-info+xml Content-Disposition: conference-info-history; handling=optional Agenda: This month's goals http://sharepoint/salesgroup/ web-page 10 Tian & Sun Expires November 2, 2007 [Page 17] Internet-Draft invite with conference info May 2007 7. Security Considerations .... Tian & Sun Expires November 2, 2007 [Page 18] Internet-Draft invite with conference info May 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 November 2, 2007 [Page 19] Internet-Draft invite with conference info May 2007 9. Acknowledges ....... Tian & Sun Expires November 2, 2007 [Page 20] Internet-Draft invite with conference info May 2007 10. MIME Information The MIME type for the Conference Info is: application/ conference-info+xml Tian & Sun Expires November 2, 2007 [Page 21] Internet-Draft invite with conference info May 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 November 2, 2007 [Page 22] Internet-Draft invite with conference info May 2007 Appendix A. History of change This is the first version of this draft. Tian & Sun Expires November 2, 2007 [Page 23] Internet-Draft invite with conference info May 2007 Authors' Addresses Linyi Tian Huawei Technologies Co., Ltd. Bantian Longgang Shenzhen, Guandong 518129 P.R China Phone: +86 755 28780808 Email: tianlinyi@huawei.com Qian Sun Huawei Technologies Co., Ltd. Bantian Longgang Shenzhen, Guandong 518129 P.R China Phone: +86 755 28780808 Email: sunqian@huawei.com Tian & Sun Expires November 2, 2007 [Page 24] Internet-Draft invite with conference info May 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 November 2, 2007 [Page 25]