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]
