INTERNET-DRAFT Carsten Bormann
Expires: December 1996 Universitaet Bremen
Joerg Ott, Christoph Reichert
TU Berlin
June 1996
Simple Conference Control Protocol
draft-ietf-mmusic-sccp-00.txt
Status of this memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
This document defines a simple conference control protocol for
tightly coupled conferences, based on the Internet Multimedia
Conferencing Architecture [1]. The functions provided are based on
the services offered by the ITU-T recommendations of the T.120 (and
H.320) series [2], they are, however, not a simple ``port'' of these
recommendations to the Internet. Instead, the aim is to define a
simple conference control protocol that is rich enough to allow the
construction of gateways to the T.120 world. Also, the protocol is
intended to be scalable and robust to failures. In contrast to the
ITU-T recommendations, it allows the use of IP multicast both for
multimedia information and for other applications and control
streams.
This document is a product of the IETF MMUSIC working group.
Comments are solicited and should be addressed to the working group's
mailing list at confctrl@isi.edu and/or the authors.
1. Introduction
The Internet Multimedia Conferencing Architecture [1] currently
Bormann, Ott, Reichert [Page 1]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
comprises conference control elements only for loosely coupled
conferences, i.e. ``crowds that gather around an attraction''. Many
conferences have more formal policies with respect to the set of
participants that are allowed to listen or with respect to who may
talk at a particular time, or they grant specific permissions to a
conference chair (called conductor in this document). Also, it may
be desirable to change parameters of the conference (e.g., set of
media/applications active, parameters for these applications) in a
coordinated way for all participants simultaneously. Conferences
that have facilities for this purpose shall be termed tightly coupled
conferences in this document.
This document defines a simple conference control protocol (SCCP) for
tightly coupled conferences. The design of this protocol was, in
part, guided by the services offered by the ITU-T recommendations of
the T.120 (and H.320) series [2], in particular:
o management of the set of members participating in the
conference;
o management of the set of applications/media that constitute the
conference;
o floor control;
o assignment of a special ``conductor'' role to one participant.
The protocol is, however, not intended as a simple ``port'' of these
recommendations to the Internet. Instead, the aim is to define a
simple conference control protocol that is rich enough to allow the
construction of gateways between conferences based on this protocol
to conferences that are based on the T.120 series of recommendations.
Also, the protocol is intended to be more scalable and more robust to
failures than an MCS-based protocol can be. In contrast to the ITU-T
recommendations, the protocol allows the use of IP multicast both for
multimedia information and for other applications and control
streams.
Conferences that are controlled by SCCP may be convened using an
invitation protocol such as SIP [3].
2. Definition of terms
[Note that some of these terms are general enough that, if we like
them, they should be defined in [1].]
o Conference
The relationship between a set of human beings that are communicating
together. In this document, the term is used for tightly coupled
(see 1) computer based conferences.
Bormann, Ott, Reichert [Page 2]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
o Participant
A human being that takes part in a conference.
o Member
The system, including software and hardware, that takes part in a
computer conference, representing a single participant.
o End system
A host or a set of locally interconnected hosts[1] that is used as an
interface to a teleconference by a single participant. The end
system runs all the required conferencing software (e.g. media
agents, session directory, and the SCCP entity), together with this
software it constitutes a member.
o SCCP entity
An instantiation of an SCCP implementation running on an end system
for a single member. An SCCP entity (or entity for short) represents
a specific participant in the conference using the SCCP protocol.
o Conference controller
An application that interacts closely with an SCCP entity on one hand
to implement the conference policy and with the participant to
realize her wishes.
o UCI
A universal communication identifier of a person. Used as the E-mail
address of an individual as well as the address that can be used to
invite that individual via the SIP protocol.
o Presence
A representation of the fact that an identified person is using a
particular end system for the purpose of (potentially or actually)
representing this person in one or more conferences. A presence
corresponds to that person ``being logged in'' at an end system and
(potentially or actually) being available for conferencing. There is
a one-to-many relationship between presences and members: one
presence may be member of many conferences. There is a one-to-one
relationship between members and the cross-product of presences and
the set of conferences this presence appears in (which cross-product
contains the set of ``appearances'' of each presence).
_________________________
[1] In this document, we use the term ``end system'' as a syn-
onym for ``host'' in the simplest case. We do not want to ex-
clude, however, that the local system that serves one participant
may be composed of several ``hosts'' in the Internet sense.
Bormann, Ott, Reichert [Page 3]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
o Conference context
All state information kept about a conference at each member of this
conference.
o Ownership (of state information)
To allow for a distributed maintenance of the conference context,
each piece of state information is ``owned'' by exactly one end
system. Each end system is responsible for keeping its owned state
and distributing (and updating) this information to those that need
it. Ownership is -- as far as possible -- defined such that the need
for a copy of the state information is bound to the appearance of its
owner in the conference.
o Statekeeper
At each point in time, one SCCP entity is assigned the function of
statekeeper. This entity is relevant for state synchronization
between the involved end systems[2]. As the conference context is
maintained in a distributed fashion, such an entity is needed to
resolve conflicting concurrent operations on the conference state.
Also, the statekeeper is owner of the state that is global to the
conference.
o Receptionist
At each point in time, one SCCP entity is assigned the function of
receptionist. This entity is responsible for providing new
participants with a copy of the current conference context[3].
o Profile
An initial description of the conference, including assignment of
roles to particular members, time limits for speakers, attributes of
the conference (open/close, conducted/anarchic, etc)[4].
o Application session (AS), Session
The set of media agents/applications that act as peers to each other
within a conference. For real-time data, this generally will be an
RTP session [4]; for other application protocols, other horizontal
protocols may define their own type of session concept. Possible
synonyms are ``application group'' or ``media agent group''.
_________________________
[2] For this version of this document, the statekeeper concept
is not yet actually necessary. See section 3.
[3] Statekeeper and receptionist may (but need not) be co-
located.
[4] Not all of this is defined in this version of the present
document, some of it is intended to be relegated to a companion
document called ``Simple Conference Control Semantics'' (SCCS).
Bormann, Ott, Reichert [Page 4]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
3. Services expected from the underlying transport
For simplicity, this version of SCCP expects to be able to use an
underlying multicast transport service. This service is assumed to
provide reliable, consistent delivery of data units called messages.
Reliability is bounded by the fact that member end systems may find
that they no longer can reliably interact with the other members,
e.g. due to a network partitioning. Messages are globally ordered:
Each message is assigned a message number by the transport service,
and messages are delivered to SCCP entities in monotonic message
number order. In the rest of this document, the term ``distribute''
will be used to indicate that a member end system sends a message
using the transport service.
Appendix B contains information on two transport mappings, including
one with full multicast functionality and one for a very simple
multipoint protocol based on TCP (MTCP). As MTCP is very easy to
implement, it might be appropriate for small conferences that use
simple implementations (e.g., internet telephony).
A version of SCCP that can be based on an unreliable datagram
multicast service and uses the statekeeper mechanism instead can be
derived from the present version, if this is desired.
4. Basic concepts of SCCP
4.1. Context and Objects
SCCP is based on the idea of maintaining a common state for the
entire conference, the conference context, at all participants. This
state is partitioned into objects. SCCP distinguishes four types of
objects:
- variables, which are general repositories for global state that
does not fit elsewhere, such as a conference policy;
- sessions, which are a special kind of variable that represents
global state about an application session;
- tokens, which are a special kind of variable that allows
synchronization operations; and
- members, which represent the information specific to a single
member.
All objects are named by a string (name), support 32 boolean
flags[5], can be assigned opaque data (value), and can carry a list
of strings that may reference other objects (namelist).
_________________________
[5] at most one of which is used in this specification.
Bormann, Ott, Reichert [Page 5]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
There are no special semantics associated with any of these elements
of an object if that object is a variable. By convention, variables
are named with lower-case names, e.g. ``policy''.
Session objects by convention are named with names that have an
initial capital, e.g. ``Audio''. Flag 0 is defined to indicate a
session with inexact membership, i.e. a session for which membership
information is not maintained with SCCP. The name list specifies the
set of members that are to join this session (the special name list
entry ``*'' specifies ``all members'').
Token objects by convention have upper case names, e.g., ``FLOOR''.
Tokens can have zero or more holders (members). Flag 0 is defined to
indicate a sharable state of the token, i.e. if flag 0 is not set,
only one member can hold the token at any time.
Member objects have names that indicate the presence that this member
represents, i.e. the names are composed of a UCI and a host name with
an intervening space, e.g. ``jo@cs.tu-berlin.de presto.cs.tu-
berlin.de''. Flag 0 is defined to indicate that this member is
willing and able to become receptionist. The namelist indicates the
names of the application sessions the member is currently present in.
4.2. Semantics
SCCP itself does not define the semantics of the variables and opaque
data values associated with objects. A simple example for semantics
(``Simple Conference Control Semantics'', SCCS) is attached as Annex
C.
By convention, every conference context contains a variable
``semantics'' which has as value a string defining the type and
version of the semantics being used (e.g., ``SCCS-1.0''). [Issue:
define mechanisms for upward compatibility of semantics versions in
SCCP or in the semantics documents?]
4.3. Application support
SCCP can be used to provide support for horizontal application
protocols, by defining specific objects such as variables and tokens
for this purpose. This may allow application protocols to use a more
lightweight transport protocol for their application data.
4.4. Messages
The context is updated by an ordered sequence of SCCP messages. Each
message is an ordered sequence of one or more SCCP actions, all of
which are applied to the conference context in one atomic step. It
is the task of the conference controller to check the SCCP actions
against the policy of the conference and perform only actions from
messages that respect this policy. In the following text, a clear
Bormann, Ott, Reichert [Page 6]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
separation will generally not be made between messages and the
actions, except where necessary for clarity.
5. Management of the set of members participating in the conference
SCCP is responsible for maintaining a (to a certain degree)
consistent membership list of all current conference participants.
Changes to the membership list are initiated by the following two
operations:
o JOIN
The SCCP entity of an end system that wants to join a conference
distributes a JOIN message to the SCCP transport of the respective
conference. Upon receipt of this message the members of the
conference know about the potential new participant and make a
decision (based on the conference policy) whether or not to accept
the newcomer. The receptionist is responsible for finally answering
the JOIN request. This answer is also distributed to the entire
conference to allow updating the membership list.
o LEAVE
When an end system decides to leave a conference, its SCCP entity
distributes a LEAVE message to the conference so that all
participants are informed about the state change.
[We need a system to ascertain membership regularly in those cases
where this is desired, e.g. DOUBT/CONFIRM and LEAVE on timeout. This
would generally be done by the statekeeper, although members that
have applications with their own membership control mechanisms may
also want to generate DOUBT messages.]
5.1. Invitation
An SCCP entity contacts the participant to be invited (more
correctly: one or more presences of this participant) by sending an
invitation message (e.g. as payload information within SIP [3]). The
invitation contains contact point information: a conference name,
transport contact information, and possibly authentication
information. The end system representing the participant to be
invited can use this information to join the conference or it can use
mechanisms defined outside of SCCP (e.g., an SIP BUSY message) to
deny joining.
5.2. Joining a conference
To join a conference, an SCCP entity needs as contact information:
The name (transport address) of the conference and possibly some
authentication information.
Bormann, Ott, Reichert [Page 7]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
A joining entity distributes a JOIN message. (Conferences may start
out empty. In this case, JOIN messages by the first member will not
receive an answer, see below.) If the conference already has
participants, all SCCP entities mark the new member as JOINING. The
receptionist now either distributes an ACCEPT or a LEAVE message. An
ACCEPT message contains a copy of the current conference context and
the conference profile; upon the receipt of an ACCEPT message all
SCCP entities mark the new member as ACCEPTED in their conference
state. The new participant creates the applications that are defined
in the current conference context.
If the joining member does not receive an ACCEPT or LEAVE message
within some time (TBD), it is the first participant. If the
conference profile for the new conference is available to the joining
member and it allows the joining member to initiate the conference,
the conference context is initialized with the profile and the SCCP
entity assumes the functions of receptionist and statekeeper. If the
joining member does not want to become statekeeper, the SCCP entity
remains passive until it sees activity in SCCP (other than JOIN
messages)[6]; it then repeats the joining procedure.
If a participant just created the conference profile from scratch and
thus knows it is the first member (e.g., for a simple phone call), it
can simply create the conference context, invite other members, and
wait for JOIN messages.
5.3. Obtaining the conference context
Together with one or more ACCEPT actions, a receptionist distributes
a CONTEXT action in the same SCCP message. This copy of the
conference context is used to initialize the conference context in
the newly accepted member.
As other messages may be distributed in the time the receptionist
submits a message containing a CONTEXT action and the time this
message is distributed, the new member must be aware of the position
in the sequence of messages for which the CONTEXT action is current.
We call this position the context synchronization event. For
transport mappings that provide serial numbers, this information
simply is the first transport serial number that was not considered
at the time the CONTEXT action was built. For transport mappings
that do not provide serial numbers, some other method is necessary to
refer to the context synchronization event, which in general will be
a JOIN action (or possibly a special SYNC action). Therefore, both
of these actions carry a synchronization time stamp that, together
with the source of the action, can be referred to in the CONTEXT
action.
_________________________
[6] This option is available only for transport mappings that
allow passive joins. Otherwise, a SIP based invitation mechanism
can be used.
Bormann, Ott, Reichert [Page 8]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
A new member that wants to obtain the conference context simply
records all messages it receives from the transport until a
conference context is received. After applying all messages that are
more recent than the context synchronization event to the context
received, the local copy of the context is current.
5.4. Leaving a conference
If the conference profile allows this, any SCCP entity can distribute
a LEAVE message with the identification of a participant that now no
longer is a member of the conference. Any conference participant can
distribute a LEAVE message for itself. An SCCP entity receiving a
LEAVE message removes the participant listed from the (conference
membership list and application session membership lists of the)
conference context.
If the receptionist wants to leave the conference, it transfers its
receptionist function beforehand (see 6).
A forced leave message might include a new session key to enforce
that the ejected member can no longer take part in the conference.
5.5. Terminating a conference
An SCCP entity that is granted -- from the conference profile -- the
permission to terminate the conference does so by distributing a
special LEAVE message with the name ``*'' to all other participants,
which indicates ``conference terminated'' as the reason for the
exclusion from the conference. Each SCCP entity receiving this
message reacts similar to as if it was excluded from the conference.
6. Transferring the receptionist and statekeeper functions
There are two possibilities that require the SCCP entity performing
the function of the receptionist/statekeeper to change: a) when the
current holder of this function leaves the conference (voluntarily or
not) in an orderly fashion; b) when the holder crashes or is
partitioned away from the other conferees.
6.1. Mechanisms for transferring the receptionist function
[Fix me.] In the first case (orderly release), the receptionist
simply sends out a LEAVE message to the group. Each member of the
conference notices that the leaving entity currently acts as the
receptionist and that consequently a new receptionist has to be
found. As all members of the conference keep a consistent state
information base (including the sequence in which the members
Bormann, Ott, Reichert [Page 9]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
joined[7]), the conference, this is done by simply selecting the
oldest remaining conference member that is receptionist-capable to
become the new receptionist. The new receptionist announces its new
role by sending a RECEPTIONIST-IS message to the group.
In case the designated receptionist has failed recently (and this has
not been detected so far), the REPECTIONIST-IS message will not show
up. Therefore, all receptionist-capable members of the group react
after a timeout (TBD) as described below for case b).
In case of temporarily inconsistent membership information multiple
RECEPTIONIST-IS messages may be sent. This situation is treated as
if multiple receptionist changes occur, and consequently the entity
whose message is delivered last becomes the new receptionist.
In the second case (failure), a recovery mechanism is invoked. If a
JOIN message is not answered by the receptionist within a certain
time (TBD, dithered), each SCCP entity distributes a RECOVERY message
unless it has already seen a RECOVERY message. The RECOVERY message
includes a random number, the beacon. The SCCP entity with the
lowest beacon assumes the receptionist function and distributes a
RECEPTIONIST-IS message. If two beacons are equal, the ``older''
member wins.
6.2. Mechanisms for transferring the statekeeper function
[The statekeeper is not defined in this version of this document.]
7. Setting variables
Actions are defined for setting the various fields of objects such as
variables, tokens, and sessions.
o SETVALUE: sets the value field.
o SETFLAG: sets the flag field under a bitmask.
o ADDNAME: adds a name to the namelist.
o DELNAME: removes a name from the namelist.
o DELETE: deletes an object.
SETVALUE and SETFLAG can also be applied to member objects.
_________________________
[7] This information is propagated to new members through the
ordering of the member objects in the CONTEXT message.
Bormann, Ott, Reichert [Page 10]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
8. Management of the set of applications/media that constitute the
conference
Each application session is described by a session object in the
conference context. The name of the session object identifies the
session within the conference.
Application specific parameters are indicated in the value of the
session object. (for SDP style parameters e.g. media address, port
number and format [5]). As part of its own member state, each SCCP
entity maintains a list of application sessions it is a member of; in
the conference context, this current actual membership is indicated
in the namelists of the member objects unless the session is marked
as inexact by flag 0 (see below).
8.1. Creating application sessions
An SCCP entity (that is permitted to do so via the conference profile
-- in conducted conferences typically the conductor) distributes an
AS-CREATE message with the session parameters. An application
session is identified by a unique identifier. The namelist of the
session object specifies the set of members that are to join the
session, if the special name ``*'', it specifies that all members are
to join the session.
8.2. Terminating application sessions
An SCCP entity (as permitted by the conference profile) distributes
an AS-DELETE message with the name of the session. All other
entities remove the session from the conference context and indicate
termination of the session to the corresponding local application.
8.3. Joining application sessions
An SCCP entity starts the application and distributes an AS-JOIN
message with the identifier of the session. The SCCP entities note
in their conference context that this member now is a peer to the
application session.
8.4. Leaving application sessions
An SCCP entity distributes an AS-LEAVE message with the identifier of
the session and terminates the application. The other SCCP entities
take note in the member object. A LEAVE message implies leaving all
application sessions.
8.5. Inexact application sessions
For large conferences, it may make sense to mark an application
session as inexact, i.e. no AS-JOIN and AS-LEAVE messages are to be
distributed. This may also be useful in case application protocols
are able to maintain membership lists by themselves.
Bormann, Ott, Reichert [Page 11]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
9. Token control
To support synchronization such as floor control (possibly with
multiple floors) and conductorship assignment, SCCP defines a generic
type of object, the token.
An SCCP entity distributes a TOKEN-WANT message to request a token,
TOKEN-GIVE to transfer it and TOKEN-RELEASE to relinquish it. A
token can be assigned exclusively to a single SCCP entity or can be
shared by any number of SCCP entities. In addition, members that are
appropriately privileged by the conference profile may simply re-
assign a token as they wish.
A token can basically be in one of three states: FREE (no holder),
EXCLUSIVE (one holder, flag 0 unset), or SHARED (one or more holders,
flag 0 set).
In each of these states a TOKEN-WANT message indicates the desire to
obtain the token. A flag in the TOKEN-WANT message indicates whether
exclusive or shared control of the token is desired.
o If the token is in the FREE state, the TOKEN-WANT automatically
assigns the token to the requester (provided the conference
policy permits giving the token to the requester).
o If the token is in the EXCLUSIVE state, the token holder has to
decide whether to pass the token on to the requester
(TOKEN_GIVE) for exclusive or shared control (the token holder
should follow the flag in the request) or not.
o If the token is in the SHARED state the behavior depends on the
request. A request for the shared token is implicitly granted
(if the policy, i.e. a limit on the number of concurrent token
holders, permits this). A request for an exclusive token is
only granted if all current shared token holders decide to pass
on the token to the requester by means of a TOKEN-GIVE message
or decide to relinquish the token with a TOKEN-RELEASE message.
(Note, however, that at least one TOKEN-GIVE must be sent within
the request timeout (TBD) for the request to succeed).
TOKEN-GIVE, TOKEN-WANT, and TOKEN-RELEASE messages can be sent by an
appropriately privileged SCCP entity indicating the desired token
control state: assigned to one or more explicitly listed
participants, assigned to the privileged entity itself, or free,
respectively. Such a request overrides the current token state.
Determination of whether or not an entity is privileged is up to the
conference semantics layer on top of SCCP (as is consequently the
decision whether or not modify the conference state accordingly).
10. Security Considerations
The authentication and encryption model for SCCP will be defined in a
Bormann, Ott, Reichert [Page 12]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
future version of this document.
Any interoperation between ITU-based systems and Internet-based
systems must take care to preserve the point-to-point link based
security model underlying the ITU standards. In T.120, much of the
access control relies on being able to reject the attempt to join a
conference via an ISDN connection to an MCU.
11. Authors' Addresses
Carsten Bormann
Universitaet Bremen FB3 MZH 5180
Postfach 330440
D-28334 Bremen
GERMANY
cabo@informatik.uni-bremen.de
phone +49.421.218-7024
Joerg Ott
Christoph Reichert
Technische Universitaet Berlin FR 6-3
Franklinstr. 28/29
D-10587 Berlin
GERMANY
jo@cs.tu-berlin.de
phone +49.30.314-73389
12. Acknowledgements
Scott Shenker, Abel Weinrib, and Eve Schooler have submitted drafts
of a more general conference control protocol, the Agreement
Protocol, in the MMUSIC working group of the IETF. Many concepts of
the Simple Conference Control Protocol are based on discussions of
the agreement protocol and our experience with attempts to implement
it.
13. References
[1] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet
Multimedia Conferencing Architecture,'' Internet Draft draft-
ietf-mmusic-confarch-00.txt, Work in Progress, February 1996.
[2] ITU T.120 series, in particular T.122/125 (MCS) and T.124 (GCC).
[3] Mark Handley, Eve Schooler, ``Session Invitation Protocol,''
Internet Draft draft-ietf-mmusic-sip-00.txt, Work in Progress,
February 1996.
Bormann, Ott, Reichert [Page 13]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
[4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A
Transport Protocol for Real-Time Applications,'' Internet RFC
1889, January 1996.
[5] M. Handley, V. Jacobson, ``SDP: Session Description Protocol,''
Internet Draft draft-ietf-mmusic-sdp-01.txt, .ps, Work in
Progress, November 1995.
Bormann, Ott, Reichert [Page 14]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
A. Message formats
[Issue: Note that this XDR-like specification does not necessarily
imply any particular type of encoding of the SCCP PDUs. The encoding
may be defined independently, or RFC 1832 encoding may be used.]
/*
* $Id: sccp.xdr,v 1.7 1996/06/12 19:55:13 cabo Exp $
*
* Common types for SCCP and the API.
*/
typedef string SCCP_Name<>;
typedef int SCCP_Flags;
typedef opaque SCCP_Value<>;
typedef SCCP_Name SCCP_Namelist<>;
/*
* Presence: UCI space Hostname
* UCI: user@hostname (where hostname is SIP relevant)
*/
struct SCCP_Object {
SCCP_Name name;
SCCP_Flags flags;
SCCP_Value value; /* upper layer semantics */
SCCP_Name namelist<>;
};
/*
* vars: completely user defined
*
* Session: 0 = inexact
*
* mEmBer: 0 = precept; namelist is AS list
* (space in name)
*
* TOKEN: 0 = shared; namelist is holder list
*/
struct SCCP_Context {
SCCP_Object vars<>;
SCCP_Object tokens<>;
SCCP_Object sessions<>;
SCCP_Object members<>;
};
enum SCCP_Sync_Type {
SCCP_S_TRANSPORT,
SCCP_S_COOKIE
};
Bormann, Ott, Reichert [Page 15]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
typedef int SCCP_Sync; /* local timestamp etc. */
struct SCCP_Cookie {
SCCP_Sync sync;
SCCP_Name sender;
};
union SCCP_Sync_Un switch(SCCP_Sync_Type type) {
case SCCP_S_TRANSPORT:
int transport_serial;
case SCCP_S_COOKIE:
SCCP_Cookie cookie;
};
struct SCCP_Context_Msg {
SCCP_Context context;
SCCP_Sync_Un sync;
};
/*
* for SRM adaptation protocol: include
* string name<>; // conference name
* in each message.
* This is not needed for MTP-2 or MTCP, as the context is clear.
*/
struct SCCP_Header {
char proto[4]; /* "sccp" */
char sccp[4]; /* "01.1" */
SCCP_Name sender; /* Presence name of sender of this message */
};
enum SCCP_Type {
SCCP_T_JOIN, /* join conference */
SCCP_T_LEAVE, /* leave conference */
SCCP_T_ACCEPT, /* accept joining member */
SCCP_T_CONTEXT, /* context */
SCCP_T_SYNC, /* context sync */
SCCP_T_ASCREATE, /* create application session */
SCCP_T_ASDELETE, /* delete application session */
SCCP_T_ASJOIN, /* join application session */
SCCP_T_ASLEAVE, /* leave application session */
SCCP_T_TOKCREATE, /* create a token */
SCCP_T_TOKDELETE, /* delete a token */
SCCP_T_TOKWANT, /* want or grab a token */
SCCP_T_TOKGIVE, /* give token */
SCCP_T_TOKRELEASE, /* release token */
SCCP_T_SETVALUE, /* set value of var, token, session, member */
SCCP_T_SETFLAG, /* set flag of var, session, member, (token) */
SCCP_T_DELETE, /* delete var */
Bormann, Ott, Reichert [Page 16]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
SCCP_T_ADDNAME, /* add name to var */
SCCP_T_DELNAME, /* delete name from var */
SCCP_T_RCPTIS, /* announce receptionist */
SCCP_T_RECOVER, /* recovery message */
SCCP_T_INVALID /* last and invalid sccp pdu type */
};
struct SCCP_Join {
SCCP_Name presence; /* joining member */
SCCP_Flags flags; /* precept etc. */
SCCP_Value value; /* user data */
SCCP_Sync sync; /* cookie (timestamp etc.) */
};
struct SCCP_AS {
SCCP_Name name;
SCCP_Value value;
SCCP_Namelist names;
};
struct SCCP_AddDelname {
SCCP_Name objname;
SCCP_Name entry;
};
struct SCCP_Recover {
unsigned int beacon;
};
struct SCCP_TOKwant {
SCCP_Name name; /* name of token */
SCCP_Name presence;/* member the token is to be assigned to*/
SCCP_Flags shared; /* want token shared or exclusive */
bool notify; /* inform holder the token is wanted */
};
struct SCCP_TOKgive {
SCCP_Name name; /* name of token */
SCCP_Name giver; /* member from whom the token is taken away */
SCCP_Name receiver; /* member to whom the token is given */
};
struct SCCP_setvalue {
SCCP_Name var; /* name of var to set */
SCCP_Value val; /* new value */
};
struct SCCP_setflags {
SCCP_Name var; /* name of var to set */
SCCP_Flags mask; /* select the flags to be modified */
Bormann, Ott, Reichert [Page 17]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
SCCP_Flags flags; /* new flags */
};
union SCCP_Union switch (SCCP_Type type) {
case SCCP_T_JOIN:
SCCP_Join join;
case SCCP_T_LEAVE:
SCCP_Name leave;
case SCCP_T_ACCEPT:
SCCP_Name accept;
case SCCP_T_CONTEXT:
SCCP_Context_Msg context_msg;
case SCCP_T_SYNC:
SCCP_Sync sync;
case SCCP_T_ASCREATE:
SCCP_AS ascreate;
case SCCP_T_ASDELETE:
SCCP_Name asdelete;
case SCCP_T_ASJOIN:
SCCP_AddDelname asjoin; /* member, session */
case SCCP_T_ASLEAVE:
SCCP_AddDelname asleave; /* member, session */
case SCCP_T_TOKCREATE:
SCCP_Name tokcreate;
case SCCP_T_TOKDELETE:
SCCP_Name tokdelete;
case SCCP_T_TOKWANT:
SCCP_TOKwant tokwant;
case SCCP_T_TOKGIVE:
SCCP_TOKgive tokgive;
case SCCP_T_TOKRELEASE:
SCCP_AddDelname tokrelease; /* token, member no longer holder */
case SCCP_T_SETVALUE:
SCCP_setvalue setvalue;
case SCCP_T_SETFLAG:
SCCP_setflags setflags;
case SCCP_T_DELETE:
SCCP_Name objname;
case SCCP_T_ADDNAME:
SCCP_AddDelname addname;
case SCCP_T_DELNAME:
SCCP_AddDelname delname;
case SCCP_T_RCPTIS:
SCCP_Name rcptis;
case SCCP_T_RECOVER:
SCCP_Recover recover;
};
Bormann, Ott, Reichert [Page 18]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
struct SCCP_Message {
SCCP_Header hdr;
SCCP_Union sccp_un<>;
};
Bormann, Ott, Reichert [Page 19]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
B. Transport mappings
At this time, transport mappings are defined for SCCP for two
protocols:
1) A simple multipoint protocol based on TCP defined in this annex
(MTCP).
2) The multicast transport protocol MTP-2.
B.1. MTCP
Each SCCP message is mapped to an MTCP message.
The initiator of a conference operates as the MTCP core. All other
participants build connections to the MTCP core.
B.1.1. MTCP protocol definition
MTCP uses TCP connections between a central core and additional
participants (one or more). Data units are exchanged on these
connections, delimited by using a variant of the RMS protocol (RFC
1831 section 10): Instead of a header with one bit of flag and 31
bits of length, MTCP uses two bits of flag and 30 bits of length.
The most significant bit, if set, indicates a control message; the
rest of the header is then interpreted specially. If the control
message bit is unset, the next to most significant bit indicates the
final fragment of a message as in RFC1831:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|F| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the control message bit is set, the next to most significant bit
indicates one of two control messages: If unset, the header indicates
a release event.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If set, the header indicates an initial sequence number data unit:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Initial Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Messages are assigned numbers implicitly by the order in which the
MTCP core distributes them, starting from the initial sequence
number. The core relays every message in order to every participant.
Bormann, Ott, Reichert [Page 20]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
New participants receive an initial sequence number from the core,
this is the sequence number of the next message received.
A message received by the core from a non-core participant is relayed
by the core to every other participant, except to the participant
that sent it: As the sending participant knows what message it sent,
it simply receives a release event in the position in the message
sequence that its message has been determined to occupy by the core.
A MTCP implementation has to provide two modes. In core mode, it
passively listens on a TCP socket. Once a new connection is opened,
it immediately sends an initial sequence number on that connection.
It sends all of the messages locally originated in the same order on
all connections. It also sends a copy of all messages received from
the non-cores, except on the connection where the message was
received, where a release event is sent instead. It delivers
messages to the SCCP entity in the same order it sends them to the
non-core members.
In non-core mode, it creates a TCP connection to a specified core.
It sends all messages it wants send to the core, keeping a copy in a
queue. It delivers all messages received from the core to the SCCP
entity. If it receives a release event, it delivers a copy of the
oldest message in its queue to the SCCP entity.
B.2. MTP-2
[Fix me, although:] The mapping to MTP-2 is trivial.
C. SCCS: Simple Conference Control Semantics
This annex defines a simple set of semantics for conference control.
C.1. Variables
VariableName Field Semantic Contents
------------------------------------------------------
"semantics" .flags - none -
.value "SCCS-1.0"
.namelist - none -
------------------------------------------------------
"permitted" .flags - none -
.value - none -
.namelist - prospective members -
------------------------------------------------------
"policy" .flags 0x0001 - conference locked
0x0002 - closed conference
Bormann, Ott, Reichert [Page 21]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
.value TBD.
.namelist TBD.
C.2. Member objects
The member objects fields have the semantics defined in SCCP (flags:
0x1 - capable/willing of being receptionist, namelist: application
sessions user is active in). The value is defined by the following
BNF (following the notational conventions of RFC822, section 2, with
the exception that whitespaces are allowed to separate the tokens
below):
The following tokens are recognized:
; delimiter
OP = "("
CP = ")"
DOT = "."
; keywords
AFFILIATION = "affiliation"
AUDIO = "audio"
CAPS = "caps"
CONTROL = "control"
DATA = "data"
EMAIL = "e-mail"
EXCLUSIVE = "exclusive"
FAX = "fax"
IP4-TYPE = "IN4"
LOCATION = "location"
MAX-SHARED = "max-shared"
USER-INFO = "user-info"
MESSAGE = "message"
MTCP = "MTCP"
MTP-2 = "MTP-2"
MULTICAST = "multicast"
NAME = "name"
PARAMETERS = "parameters"
PHONE = "phone"
PRIVATE = "private"
PUBLIC = "public"
RTP = "RTP"
SHARED = "shared"
TCP = "TCP"
UDP = "UDP"
UNICAST = "unicast"
UNICAST-CENTRALIZED = "unicast-centralized"
UNICAST-MESH = "unicast-mesh"
VIDEO = "video"
; complex tokens
CARDINAL = POS-DIGIT *DIGIT
Bormann, Ott, Reichert [Page 22]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
DECIMAL-UCHAR = DIGIT
| POS-DIGIT DIGIT
| (1 2*DIGIT)
| (2 (0|1|2|3|4) DIGIT)
| (2 5 (0|1|2|3|4|5))
DECIMAL-USHORT = DIGIT
| POS-DIGIT 1*3DIGIT
| (("1"|"2"|"3"|"4"|"5") 4DIGIT)
| ("6" ("0"|"1"|"2"|"3"|"4") 3DIGIT)
| ("65" ("0"|"1"|"2"|"3"|"4") 2DIGIT)
| ("655" ("0"|"1"|"2") DIGIT)
| ("6553" ("0"|"1"|"2"|"3"|"4"|"5"))
IP4-ADDRESS = <"> DECIMAL-UCHAR DOT DECIMAL-UCHAR DOT
DECIMAL-UCHAR DOT DECIMAL-UCHAR <">
; it is not up to the parser to distinguish between unicast
; and multicast addresses
STRING = <"> *<any CHAR excluding ASCII 0 to 31
ASCII 34, and ASCII 127> <">
MemberSemantics = OP UserInfo AS-CapabilityList [AS-Parameters] /* ... */ CP
UserInfo = OP USER-INFO Name [Phone] [Fax] [E-Mail]
[Affiliation] [Location] [Message] /* ... */ CP
Name = OP NAME DOT STRING CP
Phone = OP VOICE DOT STRING CP
Fax = OP FAX DOT STRING CP
E-Mail = OP E-MAIL DOT STRING CP
Affiliation = OP AFFILIATION DOT STRING CP
Location = OP LOCATION DOT STRING CP
Message = OP MESSAGE DOT STRING CP
AS-CapabilityList = OP CAPS *AS-Capability CP
AS-Capability = OP AS-Medium AS-Protocol AS-Format AS-Distribution CP
AS-Distribution = UNICAST / MULTICAST / UNICAST MULTICAST
AS-Parameters = OP PARAMETERS AS-ParameterList CP
AS-ParameterList = OP *AS-Parameter CP
AS-Parameter = OP AS-Name UniTransportAddress /* ... */ CP
C.3. Session objects
The session objects fields have the semantics defined in SCCP (flags:
0x1 - inexact membership, namelist: prospective member list for this
session). The value is defined by the following BNF:
AS-Semantics = OP [PermissionRequired]
Bormann, Ott, Reichert [Page 23]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
AS-Transport AS-Format CP
PermissionRequired = (OP PRIVATE PermittedMembers CP)
/ (OP PUBLIC CP)
AS-Transport = (UNICAST-CENTRALIZED AS-Medium AS-Protocol UniTransportAddress)
/ (UNICAST-MESH AS-Medium AS-Protocol)
/ (MULTICAST AS-Medium AS-Protocol MultiTransportAddress)
AS-Medium = AUDIO / VIDEO / DATA
AS-Protocol = 1*AS-ProtocolName
AS-ProtocolName = UDP / TCP / MTP-2 / MTCP / RTP
; to be extended
UniTransportAddress = OP Address Port CP
MultiTransportAddress = OP Address Port TTL CP
Address = IP4-TYPE IP4-ADDRESS
; to be extended
Port = DECIMAL-USHORT
AS-Format = OP FormatName [FormatParameter] CP
FormatName = STRING ; choose one of the RTP payload types
FormatParameters = STRING
C.4. Token objects
The token objects fields have the semantics defined in SCCP (flags:
0x1 - inexact membership, namelist: current token holder). In
addition, flag 0x100 signifies that sharing is allowed, and flag
0x200 signifies that special permission is required to obtain the
token. The value is defined by the following BNF:
TokenSemantics : OP [ExclusiveHolders] [SharedHolders] MaxNumShared CP
ExclusiveHolders : OP EXCLUSIVE SCCS_MemberList CP
SharedHolders : OP SHARED SCCS_MemberList CP
MaxNumShared : OP MAX-SHARED CARDINAL CP
C.5. Common Definitions
Bormann, Ott, Reichert [Page 24]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
The following common definitions are used in the BNF:
SCCS_MemberList : OP *SCCS_Member CP
SCCS_Member : SCCP_Name
SCCS_UserList : OP *SCCS_User CP
SCCS_User : STRING ; globally unique
; format: user@domain
C.6. Predefined tokens
To implement floor control, the state for each application session
may define what token defines its floor (if applicable). A
predefined token identifier ``FLOOR'' is used as the ``default''
floor.
A token for managing conductorship is named ``CONDUCTOR'' (generally,
no shared conductorship will be possible). Whenever the conductor
``token'' is FREE, the conference is said to be ``non-conducted''. A
conference profile may restrict who is allowed to assume this role.
D. Examples
D.1. Scenario: Internet Phone Call
In this scenario, a simple phone call is made, then extended to a
three-way phone call, and enhanced by video. Conference policy: no
floor token (open floor), no conference chair, closed conference
(i.e. access restrictions apply), conference locked after
establishment (i.e. no further participant allowed -- until a three-
way call is made).
The initiator creates an initial conference context (in this annex,
contexts are given in a notation that lists the objects, terminated
by a semicolon, giving their type, name, flags, value, and namelist):
member "cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de" 0x1
'((user-info (name . "Carsten Bormann")
(phone . "+49 421 218 70 24"))
(caps (audio RTP ("GSM") unicast)
(audio RTP ("PCMU") unicast)
(audio RTP ("G722" "48k") unicast)
(video RTP ("H261 CIF") unicast multicast)
(video RTP ("H261 QCIF") unicast multicast))',
();
Bormann, Ott, Reichert [Page 25]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
variable "semantics" 0 'sccs-1.0' ();
variable "policy" 0x3 '' ();
variable "permitted" 0x0 ''
("cabo@informatik.uni-bremen.de" "jo@cs.tu-berlin.de");
The initiator then sends a SIP invitation to the target of the phone
call [fix SIP syntax]:
SIP invite
m=control 47121 TCP MTCP SCCP-01.0
c=IN IP4 134.102.200.36
which responds with [fix SIP syntax]
SIP accept
m=control 45789 TCP MTCP SCCP-01.0
c=IN IP4 130.149.25.97
and then sends the following SCCP message:
join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", 0x1,
'((user-info (name . "Joerg Ott")
(phone . "+49 421 314 73389")
(fax . "+49 30 314 25156")
(message . "just getting coffee..."))
(caps (audio RTP ("GSM") unicast)
(audio RTP ("PCMU") unicast)
(video RTP ("H261 CIF") unicast multicast)
(video RTP ("H261 QCIF") unicast multicast))',
0x47245634);
The initiator takes note of the capabilities available and responds
with the message:
accept("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"),
context(vars = ("semantics"(...), "policy"(...), "permitted"(...)),
/* each one including the contents, of course */
tokens = (),
members =
("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"(...),
"jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"(...)),
sessions = (),
sync = (cookie, 0x47245634,
"jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"),
as-create("Audio-session-0", '((unicast audio RTP (IN4 "134.102.200.36"
10020) ("GSM")))', ("*")),
as-join("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de",
"Audio-session-0");
Bormann, Ott, Reichert [Page 26]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
The target responds with its local unicast parameters for the audio
session and joins the session, too:
set-value("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de",
'...old value...
(parameters (("Audio-session-0" (IN4 "130.149.25.97" 12960))))'),
as-join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de",
"Audio-session-0");
This completes the setup of the point-to-point call; the two persons
communicate using the audio session. If this call shall be extended
to a three person conference, either of the participants may invite
the third party to join their discussion. To the other party, this
is indicated by modifying the list of permitted persons; then the
initiator sends a SIP invitation to the target of the phone call [fix
SIP syntax]:
add-name ("permitted", "aquarius@cs.tu-berlin.de");
SIP invite
m=control 47121 TCP MTCP SCCP-01.0
c=IN IP4 134.102.200.36
which responds with [fix SIP syntax]
SIP accept
m=control 45300 TCP MTCP SCCP-01.0
c=IN IP4 130.149.25.94
and then sends the following SCCP message:
join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 0x1,
'((user-info (name . "Christoph Reichert"))
(caps (audio RTP ("PCMA") unicast)
(audio RTP ("PCMU") unicast)
(video RTP ("H261 CIF") unicast multicast)
(video RTP ("H261 QCIF") unicast multicast))',
0x6438123b);
The new member is accepted by the receptionist. However, the
receptionist notices that the currently used audio encoding is not
suitable for the new member. Therefore, the receptionist decides to
modify the parameters of the audio session allowing the new member to
get in.
accept("aquarius@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"),
set-value("Audio-session-0", '((unicast audio RTP (IN4 "134.102.200.36"
10020) ("PCMU")))', ("*")),
Bormann, Ott, Reichert [Page 27]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
The receptionist informs the newcomer about the most recent state
(including the changes) rather than about the state at the time of
entry. To achieve this synchronization the receptionist sends a new
synchronization message.
sync(cookie, 0x78423d35,
"cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de");
context(vars = ("semantics"(...), "policy"(...), "permitted"(...)),
; each one including the contents, of course
tokens = (),
members =
("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"(...),
"jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"(...)),
"aquarius@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"),
sessions = ("Audio-session-0"(...)),
sync = (cookie, 0x78423d35,
"cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de");
Noticing the existence of the audio session and that everybody is
expected to join, the newcomer provides his parameters for audio and
joins the audio session:
set-value("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de",
'(...old value...
(parameters (("Audio-session-0" (IN4 "130.149.25.94" 14578)))))'),
as-join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de",
"Audio-session-0");
Thereby the three way audio conference is established. Besides
audio, the participants want to include video information exchange
(using multicast). One participant creates a video session. As all
support the same video capabilities, the initiator chooses to trade
resolution for framerate at a given bandwidth. By the creation the
other participants are implicitly invited and join it afterwards.
as-create("Video-session-0", '((multicast video RTP (IN4 "224.2.168.199"
11480) ("H261 QCIF")))', ("*")),
as-join("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de",
"Audio-session-0");
as-join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de",
"Video-session-0");
as-join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de",
"Video-session-0");
After some discussion, one participant leaves the conference:
Bormann, Ott, Reichert [Page 28]
INTERNET-DRAFT Simple Conference Control Protocol June 1996
as-leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de",
"Audio-session-0"),
as-leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de",
"Video-session-0"),
leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de");
Finally, the second participant hangs up -- his implementation does
not generate redundant AS-LEAVE actions:
leave("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de");
The initiator, knowing that it is the only remaining member, simply
discards its copy of the conference context.
Bormann, Ott, Reichert [Page 29]
