Internet DRAFT - draft-abouabdalla-multisip

draft-abouabdalla-multisip




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]