Internet Engineering Task Force ftw. Internet Draft I.Miladinovic, J.Stadler draft-miladinovic-sip-multiparty-ext-00.txt IKN, Vienna University February 06, 2001 of Techonlogy Expires: August 2002 SIP Extension for Multiparty Conferencing 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document proposes an extension to the Session Initiation Protocol (SIP) that extends SIP for the CONF method and the participant header field. The extension provides that the identity of each participant in a multiparty conference is known by other participants all the time, from the initialization to the end of the conference. Examples of using this extension with different SIP conferencing models are also described. Miladinovic, Stadler [Page 1]
Internet Draft SIP Extension for Conferencing February 2002 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Extension Syntax . . . . . . . . . . . . . . . . . . . . . 4 3.1 CONF Method . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Participant Header Field . . . . . . . . . . . . . . . . . 5 4 Extension Semantics . . . . . . . . . . . . . . . . . . . . 6 4.1 Behavior of User Agent Clients (UAC) . . . . . . . . . . . 6 4.2 Behavior of User Agent Servers (UAS) . . . . . . . . . . . 6 4.3 Behavior of Proxy and Redirect Servers . . . . . . . . . . 7 4.4 Behavior of Conference Servers . . . . . . . . . . . . . . 7 5 Compatibility Issues . . . . . . . . . . . . . . . . . . . 7 6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1 End System Mixing . . . . . . . . . . . . . . . . . . . . . 8 6.2 Dial-In Conference Server . . . . . . . . . . . . . . . . . 10 6.2.1 Initialization of the Conference . . . . . . . . . . . . . 10 6.2.2 Inviting Users to Join the Conference . . . . . . . . . . . 11 6.3 Ad-hoc Centralized Conferences . . . . . . . . . . . . . . 12 6.4 Dial-Out Conference Server . . . . . . . . . . . . . . . . 12 6.5 Centralized Signaling, Distributed Media . . . . . . . . . 13 7 Security aspects . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . 14 Miladinovic, Stadler [Page 2]
Internet Draft SIP Extension for Conferencing February 2002 1 Introduction Session Initiation Protocol (SIP) [1] has been originally developed as a signaling protocol for large multicast conferences. Nowadays, SIP is mostly used for signaling of point-to-point conferences. There are also several possibilities for signaling of multiparty conferences in SIP, as described in [2]. One important issue for multiparty conferences is the discovery of participant identities. Conferencing models described in [2] use Real Time Transmission Protocol (RTP) and Real Time Transmission Control Protocol (RTCP) [3] for that purpose. More exactly, the Session Description messages (SDES) of RTCP, which specify the identity of the sender, are used. Participant discovery with the RTCP works very well especially for large multicast conferences. However, there are two problems when using RTCP SDES: -) A Participant in "stealth" mode can suppress RTCP SDES. In this case this participant is invisible for others in the conference. -) When SIP is used for signaling, a session must be established (SIP uses a three way handshake: INVITE, OK, ACK) in order to start media transmission via RTP. There is no possibility to distribute participant identities before the conference starts. Therefore a user that is invited to a conference has to make decision about joining the conference without knowing the identities of other participants. Moreover, this user even does not know that this call is a multiparty conference. In order to solve these problems, the discovery of participant identities has to be accomplished either by the signaling protocol (SIP) or by another protocol that is used in addition to SIP and RTP. The use of such a protocol would increase overhead and complexity of a conference session. Therefore, the information about participants' identities should be distributed by SIP. In a two party call, SIP uses the header field "from" to specify the identity of the caller. Multiparty conferences cannot use this header with a list of participants because this header specifies only the sender of the request. Neither is any other SIP header suitable to transmit this information. This document proposes a SIP extension for participant discovery in a multiparty conference. It extends SIP for one method called CONF and one header field called participant. With this extension a SIP UA is able to indicate the list of conference participants to the user when the conference is being initialized and all the time of the conference duration. 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. Miladinovic, Stadler [Page 3]
Internet Draft SIP Extension for Conferencing February 2002 3 Extension Syntax This part specifies the syntax of the CONF method and of the participant header field. 3.1 CONF Method The purpose of this method is updating of participant lists between conference participants. A CONF request is usually sent when a user joins or leaves the conference. The CONF method SHOULD NOT contain any body. Unless other specified in this document, the reliability mechanisms for the CONF method are the same as for the BYE request defined in [1]. Tables 1 and 2 extend tables 4 and 5 in [1] for a column that describes the header fields used in the CONF method. Header Where CONF ------ ----- ---- Accept R o Accept-Encoding R o Accept-Language R o Allow 200 - Allow 405 o Authorization R o Call-ID gc m Contact R o Contact 1xx - Contact 2xx - Contact 3xx - Contact 485 - Content-Encoding e - Content-Length e - Content-Type e - CSeq gc m Date g o Encryption g o Expires g o From gc m Hide R o Max-Forwards R o Organization g o Table 1: Summary of header fields, A-0 A cancellation of the CONF method is allowed and can be done by sending a CANCEL request after the CONF request. In that case any information about conference participants carried in the CONF request MUST be ignored. The CONF request MUST be sent within a call. A CONF request without a corresponding call MUST be refused with a 481 (Call Leg/Transaction Does Not Exist) response. Miladinovic, Stadler [Page 4]
Internet Draft SIP Extension for Conferencing February 2002 Header Where CONF ------ ----- ---- Priority R o Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Require R o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Response-Key R o Record-Route R o Record-Route 2xx o Route R o Server r o Subject R o Timestamp g o To gc(1) m Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o Table 2: Summary of header fields, P-Z 3.2 Participant Header Field The participant header is an additional general header in SIP. The syntax for the participant header is: Participant = ( "Participant" | "p" ) ":" 1# (( name-addr | addr-spec ) [ *( ";" participant-params ) ]) participant-params = ("status" "=" "active" | "invited" | "joining") | extension-attribute extension-attribute = extension-name [ "=" extension-value ] The definitions of name-addr and addr-spec are given in [1]. This header contains URIs of all participants in the conference, except the sender and receiver of the CONF request, which are specified in the from and to header fields respectively. The status parameter can be optionally used to specify status of participants. Currently there are three types of status defined: -) active - user is an active participant of the conference -) invited - user is being invited to this conference -) joining - user is trying to join to the conference If the status parameter is not specified for a participant, the status active is assumed. Miladinovic, Stadler [Page 5]
Internet Draft SIP Extension for Conferencing February 2002 Table 2 defines a new row in the table 5 in the [1] for the participant header: where enc. e-e ACK BYE CAN INV OPT REG ___________________________________________________ Participant g c e o o - o - - Table 2: Participant header Additionally, this header can be used in the REFER method, specified in [4]. The CONF method, as defined in this document, MUST use participant header field. 4 Extension Semantics This part describes behavior of SIP components that support the conferencing extension. The behavior of each SIP component including the conference server is described in a separate section. 4.1 Behavior of User Agent Clients (UAC) A SIP UAC MUST use the CONF method whenever the UAC changes list of conference participants e.g. by inviting a user to a conference. The UAC MUST send this method with the updated list of participants to all participants in the conference except the new one and those participants that do not support this method. The participant header MUST be used in a CONF request. It SHOULD also be used in an INVITE request when it: -) initiates a multiparty conference -) adds a new user to an existing conference. Finally, the participant header field SHOULD be used in a REFER request when referring to a conference with a conference server. 4.2 Behavior of User Agent Servers (UAS) A UAS that receives a CONF request MUST firstly check if there is an active session (call) this request is referring to. If there is no such session or if the request is not valid, the UAS MUST reply with a 481 (Call Leg/Transaction Does Not Exist) response. If an active session exists, the participant header field is used to update the participant list of the UAS. The UAS SHOULD indicate this information to the user. Finally, the CONF request is responded by a 200 (OK) response. If a UAS receives an INVITE or REFER request, it SHOULD look for the participant header field and if there is any, the value of this header SHOULD be used to create the list of participants and to inform the user about the conference call. The user is then aware that it is a conference and can than decide to accept or decline the invitation to participate in the conference. Miladinovic, Stadler [Page 6]
Internet Draft SIP Extension for Conferencing February 2002 4.3 Behavior of Proxy and Redirect Servers There is no special requirement to proxy and redirect servers caused by this extension. Both of them SHOULD forward a CONF request like a BYE request. The participant header field SHOULD be ignored by these servers. 4.4 Behavior of Conference Servers A conference server can be either dial-in or dial-out. When a dial-in conference server receives an INVITE request from a user that wants to join in an existing conference and when the conference server allows this user to join, it SHOULD check if there is a participant header field in this request. If yes, the value of this header field is compared with the participant list of the conference server. If there is no difference, the 200 (OK) response is sent without the participant header field. If there is a difference or if the participant header field is missing in the INVITE request, the conference server SHOULD insert the participant header field with an actual list of participants in the 200 (OK) response. A dial-out conference server SHOULD insert the participant header field in each INVITE request it sends. Following applies for both, dial-in and dial-out conference server. A conference server changes its participant list when a new user participates in the conference or when a conference participant leaves the conference. In both cases, the conference server MUST send a CONF request to all conference participants, except the new one (in the first case) and those participants that do not support this extension. 5 Compatibility Issues A UA that does not support this extension will not be able to indicate conference participants. It ignores the participant header field and responds to a CONF request with a 501 (Not Implemented) response. Any other functionality of such a UA will be the same as without this extension. The UA that supports this extension and is in a conference with a UA that does not support it, will be able to know about the identity of the UA that does not support the extension (the only exception is the case of an end system mixing conference where the UA that does not support the extension is used as the mixing UA). If a conference server does not support this extension, the discovery of participant identities will not be possible for conferences that use this conference server, even for the UA that supports the extension. 6 Examples This section describes usage of the conferencing extension in different conferencing models described in [2]. Note that this extension is not suitable for large multicast conferencing and Miladinovic, Stadler [Page 7]
Internet Draft SIP Extension for Conferencing February 2002 therefore this conferencing model will not be treated here. Participant discovery for these conferences should be done by RTCP, as proposed in [2]. For the first conferencing model complete SIP messages will be given. However, for other examples only the message part that is important for understanding of this extension (and not of particular conferencing model) will be denoted. 6.1 End System Mixing In this conferencing model the conference is created from a two party call. An UA in a two party call invites another user and creates the conference. Both, signaling and media data is mixed by this UA. Consider the example where A and B are in a two party call. Later on, A decides to invite another user C to the conference (Figure 1). User A User B User C | RTP Media | | |<==================>| F1 INVITE | |---------------------------------------->| | | F2 200 OK | |<----------------------------------------| | F4 CONF | | |------------------->| | | F5 200 OK | | |<-------------------| | | | F3 ACK | | --------------------------------------->| | | RTP Media | |<=======================================>| | | | Figure 1: End system mixing conference All messages are supposed to go directly from one UA to the other without passing any server. A sends following request to C: F1 INVITE A->C INVITE sip:c@c_machine.example.com SIP/2.0 Via: SIP/2.0/UDP a_machine.example.com From: sip:a@example.com;tag=34523 To: sip:c@example.com Call-ID: 3428760@a_machine.example.com Contact: sip:c@a_machine.example.com CSeq: 1 INVITE Subject: Conference Participant: <b@example.com>;stauts=active Content-Type: application/sdp Contact-Length: 123 (A's SDP not shown) Miladinovic, Stadler [Page 8]
Internet Draft SIP Extension for Conferencing February 2002 Now C is able to make a decision whether to accept or decline this call. Note that, because of the participant header field, C is aware that it is a conference and also sees the identity of the other conference participant(s). Suppose that C accepts this call by sending the following response: F2 200 OK C->A SIP/2.0 200 OK Via: SIP/2.0/UDP a_machine.example.com From: sip:a@example.com;tag=34523 To: sip:c@example.com;tag=52848 Call-ID: 3428760@a_machine.example.com Contact: sip:c@c_machine.example.com CSeq: 1 INVITE Participant: <b@example.com>;stauts=active Content-Type: application/sdp Contact-Length: 123 (C's SDP not shown) A sends a CONF request to B in order to inform B about the new conference participant. Note that B is aware of the new participant before receiving any media data from the new participant. If B does not want to communicate with C, B can simply send a BYE request and leave the conference. F3 CONF A->B CONF sip:b@b_machine.example.com SIP/2.0 Via: SIP/2.0/UDP a_machine.example.com From: sip:a@example.com;tag=43223 To: sip:b@example.com;tag=451248 Call-ID: 34200014@a_machine.example.com CSeq: 2 CONF Participant: <c@example.com>;stauts=active F4 200 OK B->A SIP/2.0 200 OK Via: SIP/2.0/UDP a_machine.example.com From: sip:a@example.com;tag=43223 To: sip:b@example.com;tag=451248 Call-ID: 34200014@a_machine.example.com CSeq: 2 CONF Participant: <c@example.com>;stauts=active The Call-ID and the tag parameter in the from and to header fields are the same as in the initial invite transaction of this session. The status parameter is set to active, because C has already sent the 200 (OK) response. The last step is the ACK request from A to C: Miladinovic, Stadler [Page 9]
Internet Draft SIP Extension for Conferencing February 2002 F5 ACK A->C ACK sip:c@c_machine.example.com SIP/2.0 Via: SIP/2.0/UDP a_machine.example.com From: sip:a@example.com;tag=34523 To: sip:c@example.com;tag=52848 Call-ID: 3428760@a_machine.example.com CSeq: 1 ACK 6.2 Dial-In Conference Server In this conferencing model users participate the conference by sending an INVITE request to the conference server (CS). The conference is identified by the request URI of the INVITE request. A conference participant can invite any user to join in the conference by sending a REFER request. 6.2.1 Initialization of the Conference The identifier of these conferences is the SIP URL and it must be distributed to all users that participate in the conference. Let us assume that users A, B and C want to initiate a conference and that the SIP URL has already been distributed to all of these users. They send an INVITE request to the CS. Suppose the requests from A, B and C arrive at the same time. User A User B User C Conf. Server | | | | | INVITE | | | |------------------------------------------------->| | | INVITE | | | |-------------------------------->| | | | INVITE | | F1 200 OK | |--------------->| |<-------------------------------------------------| ... | F2 CONF | | | |<-------------------------------------------------| | 200 OK | | | |------------------------------------------------->| ... Figure 2: Initialization of a conference with a dial-in server The answer of the CS to A is a 200 OK response that contains following header field: F1 200 OK CS->A ... Participant: <b@example.com>;status=joining, <c@example.com>;status=joining ... Now A knows that B and C are also trying to join the conference and that the conference is just being created (because there are no Miladinovic, Stadler [Page 10]
Internet Draft SIP Extension for Conferencing February 2002 active participants). B and C also receive a 200 OK with corresponding participant header field. After finishing the initialization (by receiving ACK requests form all participants), the CS sends the CONF request to A, B and C with an updated participant list, for example following request is sent to A (only the participant header field is shown): F2 CONF CS->A CONF a@a_machine.example.com SIP/2.0 ... Participant: <b@example.com>, <c@example.com> ... This request is responded with a 200 OK and the participant list is updated. 6.2.2 Inviting Users to Join the Conference Consider the example where A, B and C are in a conference using a dial-in CS and A wants D to join in the conference (Figure 3). User A User B User C User D Conf. Server | | | | | | F1 REFER | | | | |------------------------------------->| | | 200 OK | | | | |<-------------------------------------| F2 INVITE | | | | F3 CONF |----------->| | | CONF |<------------------------| | CONF |<-------------------------------------| |<--------------------------------------------------| ... | | | | 200 OK | | | | |<-----------| | | | | ACK | | | | |----------->| ... Figure 3: Inviting user to join the conference with a dial-in server A sends a REFER request to D that contains following header field: F1 REFER A->D REFER d@d_machine.example.com SIP/2.0 ... Participant: <b@example.com>, <c@example.com>;status=active ... (Note that the status parameter is optional) If D wants to join in the conference, this request is responded with a 200 OK and D sends an INVITE request to the CS using the URI given in the Refer-to header field of the REFER request (this URI is the Miladinovic, Stadler [Page 11]
Internet Draft SIP Extension for Conferencing February 2002 conference identifier). This INVITE request also contains the participant header field: F2 INVITE D->CS INVITE confe_ID@confserver.com SIP/2.0 ... Participant: <a@example.com>, <b@example.com>, <c@example.com>;status=active ... The CS verifies the conference and if D is allowed to join (according to some rules that are not specified in this document), it sends the CONF request to A, B and C. For example, the CONF request that is sent to C contains the following header field: F3 CONF CS->C CONF c@c_machine.example.com SIP/2.0 ... Participant: <a@example.com>;status=active, <b@example.com>;status=active, <d@example.com>;status=joining ... These requests are responded with a 200 OK response (not shown in figure 3). If some participants (A, B or C) do not want to communicate with D, these participants can now leave the conference. After receiving all responses to the CONF request, the CS replies the user D with a 200 (OK) response. Finally, user D sends an ACK request to CS. The CS can now send the CONF request to A, B and C in order to update status of the user D (the status of user D is now active). If it is not necessary that conference participants be informed about a new participant before participation, the first CONF request (where the status of the new participant is set to joining) should not be sent in order to reduce signaling traffic. 6.3 Ad-hoc Centralized Conferences These conferences start as a two party call. Later on, a call party decides to invite another user using a CS. Firstly, the two party call is transformed to a two party call over a CS. Secondly, the new user is invited to join in the conference using a REFER request. For applying this extension there is no difference to the dial-in CS model, as described in 6.2. The participant header field is also used in the REFER request to notify the new user about conference participants. After joining of the new participant, the method CONF is used to inform current participants about the new one. 6.4 Dial-Out Conference Server In a dial-out conference only the CS is able to invite users to the conference. These conferences are usually pre-arranged with a specified begin time and a list of participants. The server sends an Miladinovic, Stadler [Page 12]
Internet Draft SIP Extension for Conferencing February 2002 INVITE request to all participants. These INVITE requests contain the participant header field that specifies identities of invited participants. For example if A, B and C are invited to a conference, A will receive the INVITE request with following header field: INVITE CS->A: INVITE a@a_machine.example.com SIP/2.0 ... Participant: <b@example.com>;status=invited, <c@example.com>;status=invited ... With this information A is aware that this conference is being created and A also knows the identities of all invited participants. As in 6.2.1, after finishing the initialization of the conference, the CS sends a CONF request to all participants in order to update the list of conference participants. Only the users that have accepted the invitation will be present in this list. Inviting a new user to join an existing conference is done by sending a REFER request to the CS. If it is necessary to inform conference participants about this invitation before participation, the CS should send a CONF request to all current participants, where the status of the new participant is set to invited. Afterwards, the CS sends an INVITE request to the new user specified in the refer-to header field. This request contains a participant header field that indicates current conference participants. If the new user accepts the invitation, the CS will send a CONF request to all conference participants (except the new one) where the status of the new participant is set to active. 6.5 Centralized Signaling, Distributed Media These conferences use the same signaling mechanism as 6.2 or 6.3 with the difference that the media data is sent directly between participants and not over the CS. For the discovery of participant identifies there is no difference to 6.2 or 6.3. 7 Security Aspects The security mechanisms specified in the SIP specification [1] apply also to this extension. If the list of conference participants is private, the end-to-end encryption can be used to encrypt the participant header field. References [1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg: "SIP: Session Initiation Protocol", Request for Comments 2543, Internet Engineering Task Force, March 1999. [2] J. Rosenberg, H. Schulzrinne: "Models for Multi Party Conferencing in SIP", Internet Draft, Internet Engineering Task Force, November 2001, Work in progress. Miladinovic, Stadler [Page 13]
Internet Draft SIP Extension for Conferencing February 2002 [3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: "RTP: A Transport Protocol for Real-Time Applications", Request for Comments 1889, Internet Engineering Task Force, January 1996. [4] R. Sparks: "The Refer Method", Internet Draft, Internet Engineering Task Force, October 2001, Work in progress. Authors' Addresses Igor Miladinovic Institute of Communication Networks Vienna University of Technology Favoritenstrasse 9/388 A-1040 Vienna email: igor.miladinovic@tuwien.ac.at Johannes Stadler Institute of Communication Networks Vienna University of Technology Favoritenstrasse 9/388 A-1040 Vienna email: johannes.stadler@tuwien.ac.at Full Copyright Statement Copyright (C) The Internet Society (2001). 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 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 assigns. 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. Miladinovic, Stadler [Page 14]