SIPPING Working Group Ranjit Avasarala Internet-Draft Nataraju Alilaghatta Expires: October 08,2004 Sreeram Kanumuri Ravikiran Basavaraj Wipro Technologies April 08, 2004 Session Initiation Protocol (SIP) Conferencing draft-ranjit-sipping-conference-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 September 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the conference service using Session Initiation Protocol. This document explains a mechanism for initiating, modifying and terminating a SIP based conference session. Ranjit, et al Expires October 08, 2004 [Page 1] Internet Draft SIP Conference April 2004 Table Of Contents 1. Introduction..................................................... 2. Terminology...................................................... 3. Overview of conference mechanism................................. 4. Motivation for new method........................................ 5. Initiate method.................................................. 5.1 Confer-To................................................... 6. Types of conferences.............................................. 6.1 user intiated................................................ 6.2 pre-configured............................................... 6.3 open ended................................................... 7. Actions in Conference............................................. 7.1 Initiator adding users dynamically .......................... 7.2 Modifying participants' modes................................ 7.3 Removing a participant dynamically........................... 8. Usage Examples................................................... 1. Introduction This document builds upon the conferencing requirements speified in [4] and explains the mechanism to initiate, modify and teardown conference. It also describes a mechanism to add,remove and modify one or more participants To/From the SIP conference. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Overview of conference mechanism In a SIP based voice conference the SIP User Agent which wants to initiate a conference becomes the Initiator of the conference. The Initiator can then add other users into the conference. The initiator of the conference has some exclusive privileges on the conference session. - Initiator can add participants to the conference session. - Initiator can modify the mode of the existing participants. - Initiator can remove the participants from the conference session. - Initiator can close the conference session. Note: The Initiator maps to focus-owner as defined in [4]. Ranjit, et al Expires October 08, 2004 [Page 2] Internet Draft SIP Conference April 2004 4. Motivation for new Method and Header The INVITE method of SIP [1] protocol helps in establishing and tearing down of voice calls between SIP user agents. Also the SIP INFO [2] helps in carrying application level information along the SIP signaling path during a SIP Session and SIP Method MESSAGE [3] sends an instant message to remote UA. Neither of these methods do not fulfill the requirement of conveying SIP Client's intention of initiating multiparty SIP session. Hence INITIATE method been introduced. Also there is no SIP header through which a list of URIs can be provided to the server or to the conference server. So the Confer-To header is introduced. A Method called INITIATE is proposed. The INITIATE method does not establish any session nor carries any media information. It conveys the users intention to start the conference session with the list of participants mentioned in the Confer-To header. 5. The INITIATE Method INITIATE is a SIP method as defined by RFC 3261 [1]. The INITIATE method indicates that the initiator (identified by From URL) wants to initiate a session (Conferencing) with the server. 5.1 Definition of INITIATE Method The semantics of the INITIATE method are described as follows. This extension adds another value to the Method BNF described in RFC3261[2]. INITIATEm = %x49.4E.49.54.49.41.54.45; INITIATE in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / UPDATEm / INITIATEm / extension-method. Table 1 extends Table 2 of RFC 3261 [2] for the INITIATE method. Table 2 extends Table 3 of RFC 3261 [2] for the INITIATE method. 5.2 Confer-To Header This header indicates to the Proxy or Conference server the list of participants, which need to be added to the conference. Only a single Confer-To header field value SHOULD be present in the INITIATE request. Along with the participants URI, this header contains an Action paramater which indicates the action to be taken for the URI. The default action paramater will be "ADD". The Confer-To header follows the Route header syntax defined in [1] .The Confer-To header specifies the set of users with which the caller wants to initiate a session. Ranjit, et al Expires October 08, 2004 [Page 3] Internet Draft SIP Conference April 2004 Header field where proxy INITIATE ------------ ----- ----- -------- Confer-To R o The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. Confer-To = "Confer-To" HCOLON ConferTo-Param * (COMMA ConferTo-Param) ConferTo-Param = name-addr *( SEMI confer-to-params ) confer-to-params = action-param / generic-param action-param = "action" EQUAL ("add" / "hold" / "remove") E,g Confer-To: sip:sreeram@wipro.com;action=add, sip:nataraju@wipro.com;action=hold Header field where proxy INITIATE ____________________________________________ Accept R o Accept 2xx o Accept 415 o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 o Accept-Language R o Accept-Language 2xx o Accept-Language 415 o Alert-Info - Allow R o Allow 2xx o Allow r o Allow 405 o Allow-Events (1) - Authentication-Info 2xx o Authorization R o Call-ID c r m Call-Info ar o Confer-To R m Contact R m Contact 1xx - Contact 2xx o Contact 3xx d - Contact 4xx o Content-Disposition o Content-Encoding o Content-Language o Content-Length ar o Content-Type o CSeq c r m Ranjit, et al Expires October 08, 2004 [Page 4] Internet Draft SIP Conference April 2004 Date a o Error-Info 300-699 a o Event (1) o Expires o From c r m In-Reply-To - Max-Forwards R amr m Min-Expires - MIME-Version o Organization ar o Table 1: Summary of header fields, A--O ; (1) defined in [5]. Header field where proxy INITIATE ______________________________________________ Priority - Proxy-Authenticate 407 ar m Proxy-Authenticate 401 ar o Proxy-Authorization R dr o Proxy-Require R ar o RAck R - Record-Route R ar o Record-Route 2xx,18x mr o Reply-To - Require ar o Retry-After 400 -699 o Route R adr c RSeq - - Server r o Subject - o Subscription-State (1) - Supported R o Supported 2xx o Timestamp o To c r m Unsupported 420 o User-Agent o Via R amr m Via rc dr o Warning r o WWW-Authenticate 401 ar m WWW-Authenticate 407 ar o Table 2: Summary of header fields, P--Z. 6. Types of Conferences 6.1 User Initiated Conference Here the user who wants to initiate a conference becomes the initiator and sends INITIATE request to the conference server with the list of participants in Confer-To header. Ranjit, et al Expires October 08, 2004 [Page 5] Internet Draft SIP Conference April 2004 The call flow for this scenario is depicted in Figure 6.1 On receiving INITIATE request, the conference server sends INVITE to all the users listed in the Confer-To header. The server sends notifications as described in section 3.6 of [5]. On receiving INVITE the UAs (participants) send 200 OK to join the conference. The server on receiving 200 OKs from the participants sends notification using NOTIFY to the initiator. For more details on frequency of notifications and how they are sent refer sections 3.2 and 3.4 of [5]. Originator Conference UA1 Server UA2 UA3 UA4 | F1 INITIATE | | | | |------------->| | | | | F2 202 | | | | |<-------------| | | | | | F3 INVITE | | | | |-------------->| | | | | F4 200 | | | | |<--------------| | | | | F5 ACK | | | | |-------------->| | | | |<======RTP====>| | | | | | | | | | F6 INVITE | | | | |-------------------------->| | | | F7 200 | | | | |<--------------------------| | | | F8 ACK | | | | |-------------------------->| | | |<===============RTP=======>| | | F9 INVITE | | | | |<-------------| | | | | F10 200 | | | | |------------->| | | | | F11 ACK | | | | |<-------------| | | | |<===RTP======>| | | | | | | | | | F12 NOTIFY | | | | |<-------------| | | | | F13 200 | | | | |------------->| | | | | | | | | Figure- 6.1 Ranjit, et al Expires October 08, 2004 [Page 6] Internet Draft SIP Conference April 2004 Message Details F1 INITIATE from Initiator to Conference Server INITIATE sip:sip-conf@domain.com SIP/2.0 From: ;tag=100 To: Call-Id: ab12cd34@domain.com Contact: Confer-To:sip:user2@domain.com;action=add,sip:user3@domain.com; action=add,sip:user4@domain.com;action=add CSeq: 1 INITIATE Accept: application/conference-info+xml F2 202 From Conference Server to Initiator 202 sip:initiator@domain.com SIP/2.0 From : To: sip:initiator@domain.com>;tag=100 Call-Id: ab12cd34@domain.com Contact: CSeq: 2 INITIATE F3 INVITE from Conference Server to UA2 INVITE sip:ua2@domain.com SIP/2.0 From : To: ;tag=200 Call-Id: de24ab23@domain.com Contact: CSeq: 1 INVITE Content-Length: Ranjit, et al Expires October 08, 2004 [Page 7] Internet Draft SIP Conference April 2004 F12 NOTIFY from Conference Server to Initiator NOTIFY sip:user1@domain.com SIP/2.0 From: sip:sip-conf@domain.com To: ;tag=100 Call-Id: cd23ef12@domain.com CSeq: 1 INITIATE Event: Conference Subscription-State: active;expires=3600 (depends on local policy) Content-Type: application/text Content-Length: xx connected dialed-in RTP/AVP 583398 on-hold on-hold sip:conf@domain.comconf-uri> For mode details on conference-info event package, refer [5]. 7. Actions In Conference 7.1 Adding Users to Conference When the initiator wants to add a new user to the conference, Ranjit, et al Expires October 08, 2004 [Page 8] Internet Draft SIP Conference April 2004 it sends a REFER to the Conference server with Refer-To header containing the URI of the new participant and action parameter with value as æaddÆ.The server then reads the Refer-To header and action parameter and if the value is æaddÆ sends INVITE with SDP [2] parameter a=sendrecv to indicate that the user to be added The participant upon receiving the INVITE sends 200 OK to join the conference to send and receive the media. The server on receiving the 200 OK, sends NOTIFY to the initiator indicating the joining of new participant. In the call flow depicted below, the initiator (UA1) is placing on the participants' UA2 on hold. UA1 Server UA4 | | | | REFER F13 | | |------------->| | | 202 F14 | | |<-------------| | | | INVITE F15 | | |----------------- | | 200 F16 | | |<---------------- | | ACK F17 | | |----------------- | |=====RTP======>| | NOTIFY F18 | | |<-------------| | | 200 F19 | | |------------->| | F13 REFER from Initiator (UA1) to Conference Server REFER sip:sip-conf@domain.com SIP/2.0 From: ;tag=100 To: Call-Id: pq25ed@domain.com CSeq: 1 REFER Contact: Refer-To: sip:ua4@domain.com;action=add F15 INVITE from Conference Server to UA4 INVITE sip:ua4@domain.com SIP/2.0 From: To: ;tag=234 CSeq: 1 INVITE Call_id: 23rf45@domain.com Contact: 7.2 Removing Users from Conference The initiator sends a REFER to the Conference Server with the URI of the participant to be removed in the Refer-To header with action=remove. The server then reads the Refer-To header and action parameter with value æremoveÆ sends BYE to the participant. On receiving 200 from the participant, the server sends NOTIFY to the initiator indicating the removal of the participant. Conference UA1 Server UA2 | | | | REFER F20 | | |------------->| | | 202 F21 | | |<-------------| | | | BYE F22 | | |-------------->| | | 200 F23 | | |<--------------| | NOTIFY F24 | | |<-------------| | | 200 F25 | | |------------->| | | | | | | | F20 REFER from Initiator (UA1) to Conference Server REFER sip:sip-conf@domain.com SIP/2.0 From: ;tag=100 To: Call-Id: aq23ed@domain.com Contact: CSeq: 1 REFER Refer-To: sip:ua2@domin.com;action=remove F25 BYE from Conference Server to UA2 BYE sip:ua2@domain.com SIP/2.0 From: ;tag=100 Call_id: 124fer@domain.com CSEq: 1 BYE Contact: sip-conf@domain.com Ranjit, et al Expires October 08, 2004 [Page 10] Internet Draft SIP Conference April 2004 7.3 Placing Participant on Hold The initiator sends a REFER to the Conference Server with the URI of the participant to be kept on hold in the Refer-To header and action=hold. The server then reads the Refer-To header and action parameter with value æholdÆ sends INVITE with SDP parameter a='recvonly' to indicate that the user should go on hold Here the user can only recv (can hear) and cannot send media. The participant upon receiving the INVITE sends 200 OK to the conference server. The server on receiving the 200 OK, sends NOTIFY to the initiator indicating that the participant is on hold UA1 Server UA2 | | | | REFER F26 | | |------------->| | | 202 F27 | | |<-------------| | | | INVITE F28 (Hold) | | |-------------------->| | | 200 F30 | | |<--------------------| | | ACK | | |-------------------->| | |===ON-HOLD===========| | NOTIFY | | |<-------------| | | 200 | | |------------->| | F26 REFER from Initiator (UA1) to Conference Server REFER sip:sip-conf@domain.com SIP/2.0 From: ;tag=100 To: Call-Id: yz25ed@domain.com CSeq: 1 REFER Contact: Refer-To: sip:ua2@domain.com;action=hold Ranjit, et al Expires October 08, 2004 [Page 11] Internet Draft SIP Conference April 2004 F28 INVITE from Conference Server to UA2 INVITE sip:ua4@domain.com SIP/2.0 From: To: ;tag=234 CSeq: 1 INVITE Call_id: 23rf45@domain.com Contact: 7.4 Resume Participant from Hold The initiator sends a REFER to the Conference Server with the URI of the participant to be removed in the Refer-To header and action=resume. The server then reads the Refer-To header and action parameter with value æresumeÆ sends INVITE with SDP parameter a=sendrecv to indicate that the user receive and send media. The participant upon receiving the INVITE sends 200 OK to the conference server . The server on receiving the 200 OK, sends NOTIFY to the initiator indicating that the participant has resumed Conference UA1 Server UA2 | | | | REFER F29 | | |------------->| | | 202 F30 | | |<-------------| | | | INVITE F31 (Resume) | | |----------------------->| | | 200 | | |<-----------------------| | | ACK | | |----------------------->| | |======RESUME============| | NOTIFY | | |<-------------| | | 200 | | |------------->| | Ranjit, et al Expires October 08, 2004 [Page 12] Internet Draft SIP Conference April 2004 F29 REFER from Initiator (UA1) to Conference Server REFER sip:sip-conf@domain.com SIP/2.0 From: ;tag=100 To: Call-Id: yzabed@domain.com CSeq: 1 REFER Contact: Refer-To: sip:ua2@domain.com;action=resume F31 INVITE from Conference Server to UA2 INVITE sip:ua4@domain.com SIP/2.0 From: To: ;tag=234 CSeq: 1 INVITE Call_id: 23rf45@domain.com Contact: 7.5 User wants to exit from Conference The participant who wants to exit from conference sends a BYE to the conference server and the server sends NOTIFY to the initiator indicating the action. 8. Normative References [1] 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. [2] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 9. Informative References [4] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-01 (work in progress), October 2003 [5] Rosenberg, J, Schulzurrine, H. "Conference Package". draft-ietf-sipping-conference-package-03 (work in Progress), February 2004. Ranjit, et al Expires October 08, 2004 [Page 13] Internet Draft SIP Conference April 2004 10. Authrors Address Ranjit Avasarala Nataraju Alilaghatta Ravi Kiran Basavaraj Sreeram Kanumuri Plot No 72, Electronics City Hosur Main Road Bangalore, India Phone: 8520408 e-mail: ranjit.avasarala@wipro.com nataraju.alilaghatta@wipro.com ravikiran.basavaraj@wipro.com sreeram.kanumuri@wipro.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this Ranjit, et al Expires October 08, 2004 [Page 14] Internet Draft SIP Conference April 2004 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.