Internet Engineering Task Force O. Abouabdalla Internet-Draft National Advanced IPv6 Center (NAv6) Expires: February 1, 2007 R. Sureswaran University Science Malaysia A. Helweh Multimedia Research Lab August 2, 2006 Multipoint Session Initiation Protocol (MSIP) draft-abouabdalla-multisip-00.txt 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 February 1, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract Session Initiation Protocol (SIP) is passed on point-to-point protocol. This document describes a Multipoint Session Initiation Protocol. This protocol is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. The protocol is based on distributed network entities architecture, and the use of the server is mandatory. Abouabdalla, et. al. Expires February 1, 2007 [Page 1] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 2 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Multipoint Session Initiation Protocol (MSIP) entities . . . . 3 4.1 MSIP Reflector behavior . . . . . . . . . . . . . . . . . . 3 4.2 MSIP Server behavior . . . . . . . . . . . . . . . . . . . 3 4.3 MSIP Client behavior . . . . . . . . . . . . . . . . . . . 4 5. Control messages . . . . . . . . . . . . . . . . . . . . . . . 4 6. Messages flow . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Session messages flow . . . . . . . . . . . . . . . . . . . 6 6.1.1 Registration phase . . . . . . . . . . . . . . . . . . 7 6.1.2 Session initiation phase . . . . . . . . . . . . . . . 9 6.1.3 Session establishment phase . . . . . . . . . . . . . . 11 6.1.4 Joining a session phase . . . . . . . . . . . . . . . 12 6.1.5 Controlling the session and session updates phase . . . 13 6.1.6 Terminating a session phase . . . . . . . . . . . . . . 15 1. Introduction In the distributed network entities environment, a message-passing distributed algorithm is needed. This document describes a multipoint session initiation protocol. This protocol is a signaling protocol based on client-server architecture. The server here is the main entity, and it communicates with the other network entities using the standard communication protocol (TCP/IP). 2. Conventions used in this document 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 [RFC2119]. 3. Terminologies The following terminologies are used in this document: - MSIP Server: is a software that runs on a central machine and whose main functions are to control and manage the session. - MSIP Client: is a software that runs on end users devices and is used by users to start a new session, to join a session, or to participate in a session. - User: is a person who is registered to a MSIP Server. He may or may not be taking part in a session run by the MSIP Server. Abouabdalla, et. al. Expires February 1, 2007 [Page 2] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 - Chairman: is a user who starts a new session and invites other users to join the session. - Participant: is a user in a session who can actively participate or contribute to the session. - Observer: is a user in a session who is allowed to only view and listen to the session but is not allowed to take active part in it. Based on the above, the chairman, participants and observers are all users who are participating in a session via MSIP client entities with the session being managed by the MSIP Server entity. 4. Multipoint Session Initiation Protocol (MSIP) entities The general network architecture contains MSIP Server, MSIP Client, and MSIP Reflector. The architecture SHOULD contain at least one MSIP Server and at least two MSIP Client. The MSIP Reflector is OPTIONAL. 4.1 MSIP Reflector behavior The MSIP Reflector is in charge of reflecting all session control messages to all MSIP servers involved in the session. Once it is started, it waits for connections from MSIP Servers. The MSIP Reflector MUST only accept connections from MSIP Servers. MSIP Reflector MUST hold information on MISP Servers as well as information on sessions handled by MSIP Servers. The information MAY be stored in two different tables. The tables are: - Session Data List - Remote MSIP Servers List 4.2 MSIP Server behavior MSIP Server is the heart of the session. It SHOULD control all the entities involved in the session. MSIP Server MUST hold information on the users and sessions handled by MSIP Server. It also MUST hold information on MSIP Reflector that can be used. The information MAY be stored in three different tables. The tables are: - Session Data List - MSIP Reflectors List - Users Info List MSIP Server SHOULD take full control of all entities involved. The input and output transmissions from MSIP Server consist of control communications (TCP/IP). Once started, MSIP Server SHOULD search for MSIP Reflector (if available) and open connection to it. Abouabdalla, et. al. Expires February 1, 2007 [Page 3] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 The main MSIP Server is the MSIP Server that the chairman (the user who starts the session) is login to. This is the MSIP Server that will manage the entire session. The user’s local MSIP Server is the MSIP server that a user is login to. 4.3 MSIP Client behavior The main (?) functions of the MSIP Client entity are the Control and Session Monitor, which do all the coordination and synchronization for the MSIP Client entity. It Provides controls for the following: - login/logout. - Create session and join session. - Switch status (Available, Busy, or Away). MSIP Client provides communication interface with MSIP Server. It also provides users list and servers list. Finally, it provides feedback of MSIP Client and MSIP Server messages to users. The local MSIP Clients are the client entities connected to the local MSIP Server’s LAN, while the client entities from different LANs SHOULD be known as remote MSIP clients. 5. Control messages Since MSIP is an application layer signaling protocol, it uses the data field in TCP/IP to send its own messages. The first field of the message is the MSIP header (version). A header is used to avoid possible conflict with other applications using the same communication port. The second message field contains the message type. Figure 1 shows the general format of MSIP messages. |-------------------------- IP datagram --------------------------| |-------------------- TCP segment --------------------| |------------- MSIP segment -------------| +-----------+------------+-------------+--------------+-----------+ | IP header | TCP header | MSIP header | MSIP message | MSIP data | | | | | type | | +-----------+------------+-------------+--------------+-----------+ 20 bytes 20 bytes 1 byte 1 byte Figure 1 MSIP general message format Abouabdalla, et. al. Expires February 1, 2007 [Page 4] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 There are essentially six phases in a session, each of which has varying message formats or types. The six phases are: 1- Registration – During registration the user notifies the local MSIP server at which terminal he is located. Users can also change their passwords or change their status after registration. 2- Session initiation – In this phase the user (chairman) requests to create a new session. 3- Session establishment – In this phase the MSIP server sends an invitation message to all users chosen by the chairman to be involved in the session. 4- Joining a session – A user can join a session when he receives (through a MSIP client) an invitation message by responding to it. He can also join a session by sending a message to the MSIP server requesting for the list of sessions he has been invited to. 5- Controlling the session and session updates – This phase continually occurs while a session is running. A control criterion is used to control the flow of the session. In this phase a participant can request to be an active site (the MSIP server will then put him in the first empty cell in the session queue), release the active site status, withdraw from the session queue, or logout from the session. In this phase the chairman can invite new users, remove users from active site, change user status (from participant to observer or vice versa) or drop a user completely from the session. 6- Terminating a session – In this phase the chairman client terminates the session by sending a terminate message to the MSIP server. The MSIP server informs all MSIP clients about the termination of the session by sending an update message to all MSIP clients. After that, the MSIP server frees the session resources within the MSIP server. Within the session there are three levels of participation: chairman, participant and observer. Chairman is the person who begins the session. The chairman has the authority to cut short a lengthy active site, that is to "kill" a currently active site or drop him completely from the session. Abouabdalla, et. al. Expires February 1, 2007 [Page 5] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 The chairman is also the only one who has the authority to completely terminate the session. Individual participants may leave or rejoin the session as and when they wish, as long as the chairman still keeps the session going. Participants can be active or passive during the session, but observers are limited to passive mode only. An observer or participant can be upgraded or downgraded by the chairman at any time during the session. 6. Messages flow The control messages are exchanged between all entities, mostly flows between MSIP client and MSIP Server (MSIP client --> MSIP server and MSIP server --> MSIP client). If more than one MSIP server is involved in the session, the basic structure of the messages flow will be as in figure 2. MSIP MSIP MSIP MSIP MSIP Client1 Server1 Reflector Server2 Client2 | | | | | | Req Msg | | | | |------------>| Req Msg | | | | |------------->| Req Msg | | | | |------------->| Update Msg | | | | Rply Msg |------------>| | | Rply Msg |<-------------| | | Rply Msg |<-------------| | | |<------------| | | | Figure 2 Basic structure of message flow. 6.1 Session messages flow The message flow will be between MSIP server and MSIP client and vice Versa. When MSIP server starts up it performs the following tasks: - Initialize Session Data List - Initialize Users Info List - Wait for any incoming message Abouabdalla, et. al. Expires February 1, 2007 [Page 6] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 Once a message is received, the MSIP server will check the message header. If the message header belongs to MSIP it checks the message and acts accordingly. As mentioned before, the first field of the message is the MSIP header (version). A header is used to avoid possible conflict with other applications using the same communication port. The second message field contains the message type. There are essentially six phases in the session, each of which have varying message formats or types. 6.1.1 Registration phase The first message that should be received from the MSIP client is C_USER_LOGIN. This message contains the user information. The MSIP Server will check the user authentication and update users table by adding a new record with the user information (if authentication succeeded). The MSIP server then sends back S_USER_LOGIN message to the MSIP client with login successful or not. It also sends S_USER_UPDATE to other clients (if they login to MSIP server). After a user logs in to the MSIP Server, the user can change his password by sending C_PASS_CHG message to MSIP server. The message format is as shown in figure 3. The VER field is for MSIP version. The Type field is for message type, in this case it is either C_PASS_CHG or S_PASS_CHG. The flag field is used to return the operation’s result to the client. The user ID, user name, user old password and user new password constitute the rest of the fields. 1 Byte 1 Byte 1 Byte 2Bytes 10 Bytes 10 Bytes 10 Bytes +-----+------+------+--------+-----------+----------+----------+ | VER | Type | FLAG |User ID | User Name | Old | New | | | | | | | Password | Password | +-----+------+------+--------+-----------+----------+----------+ Figure 3 Change password message format When MSIP server receives C_PASS_CHG from a client it MUST compare the old password with the one in the user table stored in the server. After that MSIP server will change the password in the table with the new password (if correct) then send back S_PASS_CHG message to the client with a flag. The flag will explain the operation. The flag can be PASS_WRG --> 0x11 if a wrong password is received from the client, or PASS_OK --> 0x10 if a correct password is received and change password is successfully done. If writing the new password in the user’s file could not be done for any reason, the flag will be FILE_ERROR --> 0x12. Figure 4 below shows an unsuccessful attempt to change the password followed by a successful one. The figure shows the communications between MSIP server and MSIP client. Abouabdalla, et. al. Expires February 1, 2007 [Page 7] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 MSIP MSIP Server Client2 | | | C_PASS_CHG | |<-------------------------------| | S_PASS_CHG Flag = PASS_WRG | |------------------------------->| | C_PASS_CHG | |<-------------------------------| | S_PASS_CHG Flag = PASS_OK | |------------------------------->| | | Figure 4 Change password message flow MSIP client can also send C_STS_CHG message to MSIP server if one of his flags changed (i.e. video flag, audio flag). MSIP client can also use C_STS_CHG message to announce the change of his status (in a session, available, busy, …). The message format is as shown in figure 5. The VER field is for MSIP version. The Type field is for message type, in this case it is C_STS_CHG. The flag field is used to determine which device is changed (video, audio, client status ..). Other fields are the user ID and user status. 1 Byte 1 Byte 1 Byte 2 Bytes 1 Byte +-------+-------+-------+--------+-------------+ | VER | Type | FLAG |User ID | User Status | +-------+-------+-------+--------+-------------+ Figure 5 Change status message format When MSIP server receives C_STS_CHG from a client it updates the User table based on the information received, and then it sends S_USER_UPDATE message to current user and all other involved users. Involved users are users communicating with the user who changes his status. Figure 6 shows the message flows between MSIP server and the other MSIP clients involved in the session. The messages showed in figure 6 are from MSIP server start-up and before starting a session. Abouabdalla, et. al. Expires February 1, 2007 [Page 8] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 MSIP MSIP MSIP MSIP Server Client1 Client2 Client3 | | | | Start | | | | ***** | C_USER_LOGIN | | | |<--------------| | | | S_USER_LOGIN | | | |-------------->| | | | | C_USER_LOGIN | | |<--------------+---------------| | | S_USER_LOGIN | PASSOK | | |---------------+-------------->| | | S_USER_UPDATE | | | |-------------->| | | | | | C_USER_LOGIN | |<--------------+---------------+---------------| | S_USER_LOGIN | PASSWRG | | |---------------+---------------+-------------->| | | | C_USER_LOGIN | |<--------------+---------------+---------------| | S_USER_LOGIN | PASSOK | | |---------------+---------------+-------------->| | S_USER_UPDATE | | | |-------------->| | | | S_USER_UPDATE | | | |---------------+-------------->| | | | | C_PASS_CHG | |<--------------+---------------+---------------| | S_PASS_CHG | | Flag = PASS_OK| |---------------+---------------+-------------->| | | C_STS_CHG | | |<--------------+---------------| | | S_USER_UPDATE | | | |-------------->| | | | S_USER_UPDATE | | | |---------------+---------------+-------------->| | | | | Figure 6 message flows from MSIP server start-up and before starting a session 6.1.2 Session initiation phase In this phase the user (chairman) requests to initiate a new session. Before MSIP client starts a session, it sends C_GET_USERLIST to the MSIP server, the MSIP server replies with S_START_USERLIST followed by S_CONT_USERLIST if required. The S_CONT_USERLIST is required if the number of users is very big and their information can not fit in one message (message buffer size = 202 byte). Abouabdalla, et. al. Expires February 1, 2007 [Page 9] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 The MSIP server will also send a S_USER_UPDATE message to the MSIP client (one for each user in the user list). The S_USER_UPDATE message contains the latest updates for the users. The MSIP client will then send a C_GET_GROUPRLIST message to the MSIP server, asking for the list of groups. MSIP server replies with S_START_GROUPLIST followed by S_CONT_GROUPLIST if required. The S_CONT_GROUPLIST is required if the number of groups is very big and their information can not fit in one message. After the MSIP client receives all the information it builds the users list which contains all the information about all users having accounts in the MSIP server. User names will be in the form name@server. MSIP client can also send C_GET_CONFLIST to the MSIP server, to ask for a list of the sessions it is invited to. The MSIP server replies with S_START_CONFLIST followed by S_CONT_CONFLIST if required. The S_CONT_CONFLIST is required if number of sessions is very big and their information can not fit in one message. Figure 7 shows the messages flow for pre-create and pre-join session stages. MSIP MSIP MSIP MSIP Server Client1 Client2 Client3 | | | | Pre | | | | Create | | | | Conf | | | | ****** | C_GET_USERLIST | | | |<------------------| | | | S_START_USERLIST | | | |------------------>| | | If | S_CONT_USERLIST | | | Required |------------------>| | | | S_USER_UPDATE | | | |------------------>| | | | C_GET_GROUPLIST | | | |<------------------| | | | S_START_GROUPLIST | | | |------------------>| | | If | S_CONT_GROUPLIST | | | Required |------------------>| | | | | | | Pre Join | | | | Conf | | | | ******** | | C_GET_CONFLIST | | |<------------------+----------------| | | S_START_CONFLIST | | | |-------------------+--------------->| | If | S_CONT_CONFLIST | | | Required |-------------------+--------------->| | | | | | Figure 7 message flows for pre-create and pre-join session stages Abouabdalla, et. al. Expires February 1, 2007 [Page 10] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 After MSIP client builds users information it can start a session by sending C_CREATE_CONF message to the MSIP server. The C_CREATE_CONF message contains the session name, session priority, session control criteria and chairman info (i.e. chairman name, chairman id, chairman group id and chairman flags). When the MSIP server receives this message it checks for an available session slot. If no slot is available it sends back S_CREATE_CONF message with session priority field = CREATE_CONF_MAX (0x21). If the max number of sessions is not reached, the MSIP server will initiate all session parameters based on the information received in C_CREATE_CONF message, and then add a new session record. After that, the MSIP server sends back S_CREATE_CONF message with session priority field = CREATE_CONF_OK (0x20). 6.1.3 Session establishment phase After MSIP client receives CREATE_CONF_OK, it will send multiple C_CONF_ADDUSER messages (one for each user invited to the session). This message contains the session ID, session operation, user ID, user group ID, user MSIP server ID, operation type and user name. Once MSIP server receives the message, it adds the user to session invited list, then sends S_CONF_UPDATE message to all users involved in the session and to the user invited with Update_Operation field = ADDPAR. Figure 8 shows the message flow for session establishment between 3 clients. Client 2 is considered the session chairman. MSIP MSIP MSIP MSIP Server Client1 Client2 Client3 | | | | | | C_CREATE_CONF | | |<------------------+----------------| | | S_CREATE_CONF | CREATE_CONF_OK | | |-------------------+--------------->| | | (Client 1) | C_CONF_ADDUSER | | |<------------------+----------------| | | S_CONF_UPDATE | | | |------------------>| | | | (Client 3) | C_CONF_ADDUSER | | |<------------------+----------------| | | S_CONF_UPDATE | | | |------------------>| | | | S_CONF_UPDATE | | | |-------------------+----------------+-------------->| | | | | Figure 8 message flows for establishing a session Abouabdalla, et. al. Expires February 1, 2007 [Page 11] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 6.1.4 Joining a session phase A user can join a session when he receives an invitation message by responding to it. A user should know that he is invited to a session when he receives a S_CONF_UPDATE message that contains session operation field = ADDPAR (Add Participant), and the participant ID is equal to his ID. A user can also join a session by sending C_GET_CONFLIST message to MSIP server, requesting for the list of sessions he has been invited to. MSIP sever will send S_START_CONFLIST message back to the client followed by S_CONT_CONFLIST (if required). After MSIP client receives the full list, he chooses the session he wishes to join and sends a C_REQJOIN_CONF message to MSIP server. MSIP server will check session Availability and reply with S_REQJOIN_CONF message. The reply message includes a flag that determines whether the client can join the session or not. The flag value can be: - NO_INVITE - if the client is not invited to the session. - CONF_ENDED - if session was terminated before the client requested to join. - JOIN_PAR - if the client is invited as participant. - JOIN_OBS - if the client is invited as observer. When the flag equals JOIN_PAR or JOIN_OBS, the S_REQJOIN_CONF message also includes information about the session such as chairman name, chairman group and control criteria. Here the client can join a session by sending C_JOIN_CONF message. If an error occurs, the MSIP server will reply to the client with S_ERRORB4JOIN message, otherwise it will send back a series of messages as follows. The first message will be S_START_PARLIST followed by S_CONT_PARLIST (if Required). These two messages MUST contain all users invited to the session and their status (Participant or Observer). After that, MSIP server will send S_ACTIVE_LIST message to the client that contains the current active users. Lastly, the MSIP server sends S_START_QLIST message followed by S_CONT_QLIST message(if required). The last two messages MUST contain information about the users in the session queue (if any) which are waiting for their turn to become active. The joining client SHOULD use all the information to build up its session table. MSIP server MUST send S_CONF_UPDATE message to other clients involved in the session to update them on newly joined clients. Figure 9 shows the message flow for joining a session between 3 clients. Client 1 is considered the session chairman, and he invited Client 1 and Client 3. Client 1 joined immediately, while Client 3 joined later, and found out that the session has ended. Abouabdalla, et. al. Expires February 1, 2007 [Page 12] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 MSIP MSIP MSIP MSIP Server Client1 Client2 Client3 | | | | | S_CONF_UPDATE | | | |------------------>| | | | S_CONF_UPDATE | | | |-------------------+----------------+--------------->| | C_REQJOIN_CONF | | | |<------------------| | | | S_REQJOIN_CONF | | | | Flag = JOIN_PAR | | | |------------------>| | | | C_JOIN_CONF | | | |<------------------| | | | S_START_PARLIST | | | |------------------>| | | if | S_CONT_PARLIST | | | Required|------------------>| | | | S_ACTIVE_LIST | | | |------------------>| | | | S_START_QLIST | | | |------------------>| | | if | S_CONT_QLIST | | | Required|------------------>| | | | S_CONF_UPDATE | | | |-------------------+----------------+--------------->| | S_CONF_UPDATE | | | |-------------------+--------------->| | | | | C_GET_CONFLIST | |<------------------+----------------+----------------| | S_START_CONFLIST | | | |-------------------+----------------+--------------->| if | S_CONT_CONFLIST | | | Required|-------------------+----------------+--------------->| | | | C_REQJOIN_CONF | |<------------------+----------------+----------------| | S_REQJOIN_CONF | Flag=CONF_ENDED| | |-------------------+----------------+--------------->| | | | | Figure 9 message flows for joining a session 6.1.5 Controlling the session and session updates phase This phase continually occurs while a session is running. A control criterion MUST be used to control the flow of the session. In this phase a participant can request to be an active site by sending C_CONF_UPDATE message to MSIP server with Update_Operation field = REQ. Abouabdalla, et. al. Expires February 1, 2007 [Page 13] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 If one of the active site cells is empty, the participant will be active, if not MSIP server will put the participant ID in the first empty cell in the session queue then send a S_CONF_UPDATE message with updated information to all clients involved so that the clients can also update their session table. The number of active cells can be one, two, or three (based on the control criteria). Participants can also release the active site status or withdraw from the session queue by sending C_CONF_UPDATE message to the MSIP server with the Update_Operation field = REL or UNQ. The MSIP server will update the session queue and the session table accordingly, and then send S_CONF_UPDATE message with updated information to all clients involved. The S_CONF_UPDATE message contains the update type (Update_Operation Field), user ID, and session ID, so when the current active participant releases, the participant who is next at the top of the session queue will know that he is now an active site. Participants SHOULD recognize themselves since each user has a unique ID in MSIP server. The S_CONF_UPDATE message is also sent to all clients when a new user joins a session. If a participant wants to logout from a session (hang up), his client SHOULD send C_LEAVE_CONF message to MSIP server. Once the MSIP server receives this message it will update the session table by changing the user’s Join_Status field in the session table to LEFT_CONF. Then it sends S_CONF_UPDATE message to all MSIP clients involved in the session with the Update_Operation field = LEAVE. During this phase the chairman can upgrade observers to participants or conversely using the C_CONF_UPDATE message. Chairman will send the message to MSIP server with the Update_Operation field = CHGSTS. When the MSIP server receives the message it will check and confirm if the message is received from the session chairman or not. If so the MSIP server will update the user information in the session table and send S_CONF_UPDATE message to all MSIP clients involved in the session with The Update_Operation field = CHGSTS. The session chairman can also cut short a lengthy active site, that is to ‘kill’ a currently active site by sending C_CONF_UPDATE message to MSIP server with the Update_Operation field = KILL, with which the MSIP server will then follow the procedure for releasing the active site. During the session, the chairman can invite new participants or drop an existing participant. To invite a new participant, the chairman sends C_CONF_ADDUSER message to MSIP server. Please refer to section 6.1.3 (Session establishment phase) for message contents and MSIP server behavior upon receiving it. The session chairman could also drop any participant any time during the session. Abouabdalla, et. al. Expires February 1, 2007 [Page 14] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 MSIP MSIP MSIP MSIP Server Client1 Client2 Client3 | | | | |C_CONF_UPDATE (REQ)| | | |<------------------+ | | | S_ CONF_UPDATE | OPR = REQ | | |-------------------+--------------->| | | S_CONF_UPDATE | | OPR = REQ | |-------------------+----------------+-------------->| |S_CONF_UPDATE (REQ)| | | |------------------>| | | | S_CONF_UPDATE | | | |------------------>| | | | (Client 1) |C_CONF_DROPUSER | | |<------------------+----------------| | |S_CONF_UPDATE(DROP)| | | |------------------>| | | | S_CONF_UPDATE | OPR = DROP | | |-------------------+----------------+-------------->| | | | C_LEAVE_CONF | |<------------------+----------------+---------------| | S_ CONF_UPDATE | OPR = LEAVE | | |-------------------+--------------->| | | | | | Figure 10 message flows for session updates To drop a participant, the chairman sends C_CONF_DROPUSER message to MSIP server. The server will remove the dropped participant from the session invited users, update the session table and then send S_CONF_UPDATE message to all involved clients with Update_Operation field = DROP. Once a user is removed from the invited participant list, it would not be able to join the session again even if the session is still running. Figure 10 shows the message flow for some of the session update messages between 3 clients. Client 2 is considered the session chairman. 6.1.6 Terminating a session phase In this phase the chairman’s MSIP client terminates the session by sending C_END_CONF message to the MSIP server. The MSIP server first MUST confirm that the message is received from the session chairman by checking the sender ID and comparing it with the chairman ID in the session table. If so, it will inform all the MSIP clients that are involved in the session about the session termination by sending S_END_CONF message to all of them. Abouabdalla, et. al. Expires February 1, 2007 [Page 15] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 After that, the server disconnects all clients from the session and then frees the session resources within the server. Figure 11 shows the message flow for some of the session update messages between 3 clients. Client 2 is considered the session chairman. MSIP MSIP MSIP MSIP Server Client1 Client2 Client3 | | | | | | C_END_CONF | | |<------------------+----------------| | | S_END_CONF | | | |------------------>| | | | S_END_CONF | | | |-------------------+----------------+-------------->| | | | | Figure 11 message flows for session termination Author's Address Dr. Omar Amer Abouabdalla National Advanced IPv6 Center (NAv6) Level 6, School of Computer Sciences Universiti Sains Malaysia 11800 Minden, Penang, Malaysia tel: 604-6533006 Email: omar@nrg.cs.usm.my Assoc Prof Dr. Sureswaran Ramadass School of Computer Sciences Universiti Sains Malaysia 11800 Penang, Malaysia tel: 604-6533004 Email: sures@cs.usm.my Ayman Helweh Multimedia Research Lab Suite 242, Complex EUREKA, USM 11800 Penang, Malaysia tel: 604-6593590 Email: ayman@mlabs.com Comments are solicited and should be addressed to omar@nrg.cs.usm.my Abouabdalla, et. al. Expires February 1, 2007 [Page 16] INTERNET-DRAFT Multipoint Session Initiation Protocol (MSIP) July 2006 Expiration Date This memo expires on February 1, 2007. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Abouabdalla, et. al. Expires February 1, 2007 [Page 17]