Network Working Group L. Tian Internet-Draft Q. Sun Expires: December 28, 2007 Huawei Technologies June 26, 2007 Session Initiation Protocol (SIP) INVITE with Conference Info draft-linyi-sipping-invite-with-conf-info-02 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 December 28, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Tian & Sun Expires December 28, 2007 [Page 1] Internet-Draft invite with conference info June 2007 Abstract This specification defines a mechanism that allows a SIP User Agent Client (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 . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Conference-Info Format derived from XCON Data Model . 7 4.2. UAC Procedures . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. MIME Information . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. History of change . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Tian & Sun Expires December 28, 2007 [Page 2] Internet-Draft invite with conference info June 2007 1. Introduction Section 5.4 of RFC 4579 [1] describes how to create a conference using ad-hoc SIP 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. This specification extends the above mechanim to allow UAC to be able to provide the Conference Server with the initial conference information and policy (referred as conference-info below). This specification further provides a mechanism for Conference Server to distribute the conference-info 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 December 28, 2007 [Page 3] Internet-Draft invite with conference info June 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 [9] "conferencing Framework". Tian & Sun Expires December 28, 2007 [Page 4] Internet-Draft invite with conference info June 2007 3. Requirements Analysis RFC 4579 [1] defines a mechanism to provide the conference server with the initial set of participants in a single operation during the ad hoc conference creation. In addition the invoker may want to provide simple conference information and policy referred as conference-info below, for example the subject and maximum numbers of participants, for an ad hoc conference in the same operation. In ad hoc conference scenario they rarely desire to manipulate the conference policy, whether before the conference is created or during the conference. RFC XXX {URI List Conferencing} [2] defines a mechanism for Conference Server to provide URI-List history to invitees by including a 'recipient-list-history' body which contains the manipulated list of invitees. The same principle could be applied to conference-info. When Conference Server sends INVITE to invitees, e.g. triggered by REFER request or URI-List conference creation, the Conference Server can provide them with the conference-info as history information. This will help invitees to determine whether to join this conference which may fall into their interest. In current art when the invitees get an INVITE request with 'isfocus' feature tag they 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 determine 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. Invitees can also use confernce event package subscription mechanism to get more detail information. 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 December 28, 2007 [Page 5] Internet-Draft invite with conference info June 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- info, e.g. and . The conference-info 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 so that invitees are aware. 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 which could be carried in SIP INVITE method. The amount of data MUST be limited to avoid overload of SIP messages. The element has three attributes 'entity', 'state' and 'version'. The 'entity' and 'version' attributes MUST be included. The 'state' attribute is MAY be included and the default value is "full". In this specification, there are some restrictions for attributes of element as follow: o 'entity': In initial INVITE request from invoker the value MAY be any URI and MUST be ignored by Conference Server. In subsequent INVITE requests from Conference Server the value MUST be the conference URI that identifies the conference created by the Conference Server. The invitees can subscribe this URI for receiving Conference Event Package. o 'state': This attribute MAY not be present in all INVITE requests. If it is present, it MUST be ignored by the Conference Server and invitees. o 'version': This attribute MAY contain any version number and MUST be ignored by the Conference Server and invitees. Tian & Sun Expires December 28, 2007 [Page 6] Internet-Draft invite with conference info June 2007 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-info. Other elements or attributes defined in RFC 4575 [4] SHOULD NOT included in initial INVITE request and subsequent INVITE requests to invitees. | |-- | |-- | |-- | |-- | |-- | | | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- Figure 1: Conference-Info Format derived from Conference State Package 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-info. Other elements or attributes defined in RFC XXX {XCON Data Model} [5] SHOULD NOT included in initial INVITE request and subsequent INVITE requests to invitees. Tian & Sun Expires December 28, 2007 [Page 7] Internet-Draft invite with conference info June 2007 | |-- | |-- | |-- | |-- | |-- | |-- | | | |-- | | |-- | | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | | |-- | | | |-- | | | |-- | |-- | |-- | |-- | |-- | |-- | |-- | | |-- | | | |-- | | | |-- | | | |-- | | | |-- Figure 2: Structure of Conference-Info derived from XCON Data Model 4.2. UAC Procedures A UAC that wants to include the initial conference-info 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 Tian & Sun Expires December 28, 2007 [Page 8] Internet-Draft invite with conference info June 2007 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 MUST NOT include conference-info bodies in re-INVITE requests sent to a conference server (although it may become useful at some future time and future extentions may define them). 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 is present, 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 MUST ignore 'state' attribute if it is present. The Conference Server MUST ignore 'version' attribute. The Conference Server MUST include the same conference-info from incoming INVITE request to the invitees as the history information using an INVITE-contained conference-info request. The Conference Server MUST 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". Tian & Sun Expires December 28, 2007 [Page 9] Internet-Draft invite with conference info June 2007 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, MUST reject 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 December 28, 2007 [Page 10] Internet-Draft invite with conference info June 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 when it is present. A Conference Server receiving a INVITE request with a URI-List body and a conference-info body where the number of URIs exceed maximum user count, consequently, rejects it with a 403 (Forbidden). Tian & Sun Expires December 28, 2007 [Page 11] Internet-Draft invite with conference info June 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-info. 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 knows the conference-info of this specific conference, such as subject, directly when he receives the INVITE request F7 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 December 28, 2007 [Page 12] Internet-Draft invite with conference info June 2007 INVITE sip:32132219811205@conf.example.com SIP/2.0 Via: SIP/2.0/TCP beijing.example.com ;branch=z9hG4bKa38ssa8s Max-Forwards: 70 To: "Conference Factory" 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://www.example.com/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: Tian & Sun Expires December 28, 2007 [Page 13] Internet-Draft invite with conference info June 2007 o 'application/sdp' body: describes the session; o 'application/conference-info+xml' body: contains the conference info history. Tian & Sun Expires December 28, 2007 [Page 14] Internet-Draft invite with conference info June 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://www.example.com/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 identified by the URIs included in the URI-list. Tian & Sun Expires December 28, 2007 [Page 15] Internet-Draft invite with conference info June 2007 The Conference Server includes a manipulated URI-list and conference- info history in each of the outgoing INVITE requests. 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: "Conf Factory" From: Alice ;tag=13323 Call-ID: b01766e67c4b48af234 CSeq: 1 INVITE Tian & Sun Expires December 28, 2007 [Page 16] Internet-Draft invite with conference info June 2007 Contact: Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog Accept: application/sdp, message/sipfrag 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 Tian & Sun Expires December 28, 2007 [Page 17] Internet-Draft invite with conference info June 2007 http://www.example.com/salesgroup/ web-page 10 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-info. Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKt34932hw Max-Forwards: 70 To: From: Conference Server ;tag=234332 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 --boundary1-- --boundary1 Content-Type: application/conference-info+xml Content-Disposition: conference-info-history; handling=optional Agenda: This month's goals http://www.example.com/salesgroup/ web-page 10 Tian & Sun Expires December 28, 2007 [Page 19] Internet-Draft invite with conference info June 2007 7. Security Considerations SIP Conferencing 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. This specification defines a mechanism to setup ad hoc SIP conferences using a INVITE-contained conference-info which may contain additional policy for focus to control the conferences. Implementations of conference servers MUST follow the policy contained in conference-info. The mechanism defined in this specification can be used together with URI-List Service. The Framework and Security Considerations for SIP URI-List Services (which is documented in RFC XXXX [8] ) discusses issues related to SIP URI-list services. Given that a conference server sending INVITE requests to a set of users acts as an URI-list service, implementations of conference servers that handle lists MUST follow the security-related policy in RFC XXXX [8] . These rules include mandatory authentication and authorization of clients, and opt-in lists. Tian & Sun Expires December 28, 2007 [Page 20] Internet-Draft invite with conference info June 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 | | | | policy for a specific | | | | conference. | | +------------------------+------------------------------+-----------+ Figure 9: Registration of the 'conference-info-invite' Option-Tag in SIP. +------------------------+------------------------------+-----------+ | Name | Description | Reference | +------------------------+------------------------------+-----------+ | conference-info | The body contains the | [RFC XXXX]| | | conference information and | | | | policy for a specific | | | | conference. | | +------------------------+------------------------------+-----------+ Figure 10: Registration of the 'conference-info' Disposition Type. +------------------------+------------------------------+-----------+ | Name | Description | Reference | +------------------------+------------------------------+-----------+ | conference-info-history| The body contains the history| [RFC XXXX]| | | conference information and | | | | policy for a specific | | | | conference. | | +------------------------+------------------------------+-----------+ Figure 9: Registration of the 'conference-info-history' Disposition Type. Tian & Sun Expires December 28, 2007 [Page 21] Internet-Draft invite with conference info June 2007 9. Acknowledges Henning Schulzrinne, Spencer Dawkins, Even Roni, Oscar Novo and Peili Xu provided useful comments on this document. Tian & Sun Expires December 28, 2007 [Page 22] Internet-Draft invite with conference info June 2007 10. MIME Information The MIME type for the conference-info is: application/ conference-info+xml as defined in RFC 4575 [4] Tian & Sun Expires December 28, 2007 [Page 23] Internet-Draft invite with conference info June 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. [8] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", draft-ietf-sipping-uri-services-06 (work in progress), September 2006. 11.2. Informative References [9] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. Tian & Sun Expires December 28, 2007 [Page 24] Internet-Draft invite with conference info June 2007 Appendix A. History of change This is the first version of this draft. Tian & Sun Expires December 28, 2007 [Page 25] Internet-Draft invite with conference info June 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 December 28, 2007 [Page 26] Internet-Draft invite with conference info June 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 December 28, 2007 [Page 27]