draft-ietf-mmusic-sccp-00.txt   draft-ietf-mmusic-sccp-01.txt 
INTERNET-DRAFT Carsten Bormann Network Working Group Bormann
Expires: December 1996 Universitaet Bremen Internet-Draft Kutscher
Joerg Ott, Christoph Reichert Expires: August 14, 2001 Ott
TU Berlin TZI, Universitaet Bremen
June 1996 Trossen
Nokia Research Center
Simple Conference Control Protocol February 13, 2001
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 Simple Conference Control Protocol -- Service Specification
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow draft-ietf-mmusic-sccp-01.txt
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. Status of this Memo
Abstract This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document defines a simple conference control protocol for Internet-Drafts are working documents of the Internet Engineering
tightly coupled conferences, based on the Internet Multimedia Task Force (IETF), its areas, and its working groups. Note that
Conferencing Architecture [1]. The functions provided are based on other groups may also distribute working documents as
the services offered by the ITU-T recommendations of the T.120 (and Internet-Drafts.
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. Internet-Drafts are draft documents valid for a maximum of six
Comments are solicited and should be addressed to the working group's months and may be updated, replaced, or obsoleted by other documents
mailing list at confctrl@isi.edu and/or the authors. at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
1. Introduction To view the entire list of Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
The Internet Multimedia Conferencing Architecture [1] currently This Internet-Draft will expire on August 14, 2001.
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 Copyright Notice
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 Copyright (C) The Internet Society (2001). All Rights Reserved.
conference;
o management of the set of applications/media that constitute the Abstract
conference;
o floor control; This document defines the services for a simple conference control
protocol (SCCP) to be used for tightly coupled conferences. It is
part of the Internet Multimedia Conferencing Architecture, proposed
in [1].
o assignment of a special ``conductor'' role to one participant. The SCCP services provide functionality for management of the set of
members, management of the set of application/media sessions, and
for floor control to implement access control rules for distributed
application resources.
The protocol is, however, not intended as a simple ``port'' of these Note that this document does not specify how to implement the
recommendations to the Internet. Instead, the aim is to define a proposed services. For that, different mappings are specified based
simple conference control protocol that is rich enough to allow the on different transport layer techniques.
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 This document is a product of the Multiparty Multimedia Session
invitation protocol such as SIP [3]. Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the
working group's mailing list at confctrl@isi.edu and/or the authors.
2. Definition of terms Table of Contents
[Note that some of these terms are general enough that, if we like 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
them, they should be defined in [1].] 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 SCCP and Conference Setup . . . . . . . . . . . . . . . . . . 3
1.3 SCCP and Capability Negotiation . . . . . . . . . . . . . . . 4
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
3. Services of SCCP . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Conference Management . . . . . . . . . . . . . . . . . . . . 7
3.2 Application Session Management . . . . . . . . . . . . . . . . 7
3.3 Floor Control . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements for Mappings onto underlying Transports . . . . . 10
5. A Model for Configuration and Capability Negotiation . . . . . 11
6. SDP considerations . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24
o Conference 1. Introduction
The relationship between a set of human beings that are communicating 1.1 Overview
together. In this document, the term is used for tightly coupled
(see 1) computer based conferences.
o Participant The Internet Multimedia Conferencing Architecture [1] currently
comprises conference control elements only for loosely coupled
conferences, i.e., "crowds that gather around an attraction".
However, many conferences have more formal policies with respect to
the underlying "social protocol" of the specific scenario. Also, it
may be desirable to change parameters of the conference, e.g., set
of media/applications and their parameters, in a coordinated way for
all participants. Conferences that have facilities for this purpose
shall be termed "tightly coupled conferences" in this document.
A human being that takes part in a conference. This document defines services for simple conference control of
tightly coupled conferences. The services provided by this protocol
were guided by the services offered by the ITU-T recommendations of
the H.323 series [7], namely:
o Member o management of the set of members participating in the conference;
The system, including software and hardware, that takes part in a o management of the set of media/application sessions that
computer conference, representing a single participant. constitute the conference; and
o End system o floor control, which especially enables "conducted" conferences
or implementation of arbitrary access control on distributed
resources.
A host or a set of locally interconnected hosts[1] that is used as an Note that this document specifies only the services to be provided
interface to a teleconference by a single participant. The end but not the protocol mechanisms to be used for implementation. The
system runs all the required conferencing software (e.g. media latter are to be specified by different "mapping drafts" for
agents, session directory, and the SCCP entity), together with this specific transport layer techniques.
software it constitutes a member.
o SCCP entity 1.2 SCCP and Conference Setup
An instantiation of an SCCP implementation running on an end system The Internet Multimedia Conferencing Architecture described in [1]
for a single member. An SCCP entity (or entity for short) represents provides a categorization of conference management concepts and
a specific participant in the conference using the SCCP protocol. corresponding technologies. The domain of conference management is
divided into conference setup (including conference discovery) and
conference course control.
o Conference controller While conference setup mechanisms, such as SIP [2], provide means to
distribute a proper initial state to the involved end systems, the
purpose of a conference course control protocol like SCCP is to
manage a state during the lifetime of a conference.
An application that interacts closely with an SCCP entity on one hand However, in cases where conferences are set up with SIP, the state
to implement the conference policy and with the participant to managed by SCCP would incorporate the initial conference state. This
realize her wishes. initial state usually includes configuration of media sessions, that
might result from negotiation processes. One element of the initial
configuration of SCCP-enabled conference will be the configuration
of the SCCP channel and transport mapping-specific information.
o UCI While we clearly distinguish between the roles of conference setup
and conference course control there is a strong relation between
these two forms of conference control and it is therefore desirable
to define a way how to emerge an initial conference state (setup and
distributed with SIP, SAP, or by other means) into an SCCP-state.
A universal communication identifier of a person. Used as the E-mail 1.3 SCCP and Capability Negotiation
address of an individual as well as the address that can be used to
invite that individual via the SIP protocol.
o Presence The configuration information of application sessions in the setup
protocols SIP and SAP [3] is specified in a session description, in
the moment this is often an SDP [4] description.
A representation of the fact that an identified person is using a Because SDP addresses the description of conferences only, a new
particular end system for the purpose of (potentially or actually) conference description framework is currently being defined ([6]).
representing this person in one or more conferences. A presence This work does not only address the issue of describing sessions but
corresponds to that person ``being logged in'' at an end system and also the issue of capability negotiation.
(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.
o Conference context In Section 3.2 capability (re-)negotiation is listed as one of the
functionalities provided by SCCP for application session management.
Section 5 presents a model for configuration and capability
negotiation that is currently pursued by [6]. The refinement of the
SCCP services in future versions of this document will consider this
model.
All state information kept about a conference at each member of this 2. Definition of Terms
conference.
o Ownership (of state information) Participant: A human being that takes part in a conference.
To allow for a distributed maintenance of the conference context, Member: The system, including software and hardware, that takes part
each piece of state information is ``owned'' by exactly one end in a computer conference, representing a single participant.
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 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. Together with this software it constitutes a member.
At each point in time, one SCCP entity is assigned the function of SCCP entity: An instantiation of an SCCP implementation running on
statekeeper. This entity is relevant for state synchronization an end system for a single member. An SCCP entity (or entity for
between the involved end systems[2]. As the conference context is short) represents a specific participant in the conference using
maintained in a distributed fashion, such an entity is needed to the SCCP protocol.
resolve conflicting concurrent operations on the conference state.
Also, the statekeeper is owner of the state that is global to the
conference.
o Receptionist Conference controller: An application that interacts closely with an
SCCP entity on one hand to implement the conference policy and
with the participant on the other hand to realize her wishes.
At each point in time, one SCCP entity is assigned the function of UCI: A universal communication identifier of a person. Used as the
receptionist. This entity is responsible for providing new E-mail address of an individual as well as the address that can
participants with a copy of the current conference context[3]. be used to invite that individual via SIP [2].
o Profile 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).
An initial description of the conference, including assignment of Conference context: All session and membership information kept at
roles to particular members, time limits for speakers, attributes of each member of a conference which can be accessed by each SCCP
the conference (open/close, conducted/anarchic, etc)[4]. entity through appropriate service requests.
o Application session (AS), Session 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).
The set of media agents/applications that act as peers to each other Application session (AS), Session: The set of media
within a conference. For real-time data, this generally will be an agents/applications that act as peers to each other within a
RTP session [4]; for other application protocols, other horizontal conference. For real-time data, this generally will be an RTP
session; for other application protocols, other horizontal
protocols may define their own type of session concept. Possible protocols may define their own type of session concept. Possible
synonyms are ``application group'' or ``media agent group''. 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).
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 Floor context: State information about floors which can be accessed
multicast service and uses the statekeeper mechanism instead can be by each SCCP entity through appropriate service requests.
derived from the present version, if this is desired.
4. Basic concepts of SCCP 3. Services of SCCP
4.1. Context and Objects This section describes the services provided by SCCP and realized by
appropriate protocol mechanisms. Note that the latter is not within
the scope of this document.
SCCP is based on the idea of maintaining a common state for the 3.1 Conference Management
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 SCCP is responsible for managing a conference context containing
does not fit elsewhere, such as a conference policy; membership information of all current conference participants. The
following operations are possible in the context of SCCP conference
management:
- sessions, which are a special kind of variable that represents invite other users: SCCP users may invite other users to participate
global state about an application session; in the current SCCP conference.
- tokens, which are a special kind of variable that allows join the conference: SCCP provides to dynamically join a running
synchronization operations; and conference. The conference context is updated appropriately.
- members, which represent the information specific to a single leave the conference: SCCP also provides to dynamically leave a
member. conference without disturbance. The conference context is updated
appropriately.
All objects are named by a string (name), support 32 boolean terminate the conference: in the case of a "conducted" conference, a
flags[5], can be assigned opaque data (value), and can carry a list running conference may be terminated by the conductor resulting
of strings that may reference other objects (namelist). in a destruction of the entire conference.
_________________________
[5] at most one of which is used in this specification.
There are no special semantics associated with any of these elements obtain conference context: maintain the information stored in the
of an object if that object is a variable. By convention, variables conference context.
are named with lower-case names, e.g. ``policy''.
Session objects by convention are named with names that have an For sake of simplicity, SCCP does not provide more sophisticated
initial capital, e.g. ``Audio''. Flag 0 is defined to indicate a features like merging, appending, or splitting entire conferences.
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''. 3.2 Application Session Management
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 SCCP provides functionality to manage a set of media/application
represents, i.e. the names are composed of a UCI and a host name with sessions that constitute the conference, e.g., for real-time data
an intervening space, e.g. ``jo@cs.tu-berlin.de presto.cs.tu- this will be an RTP session [5].
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 Each media/application set is maintained in the conference context.
Hence, its parameters can be obtained using appropriate conference
context functions. However, it is also possible to create
application sessions without registering them in the conference
context due to scalability reasons.
SCCP itself does not define the semantics of the variables and opaque Hence, SCCP offers the following application session management
data values associated with objects. A simple example for semantics functions:
(``Simple Conference Control Semantics'', SCCS) is attached as Annex
C.
By convention, every conference context contains a variable negotiating and changing the configuration of application sessions:
``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 allows to find an appropriate configuration of one or more
application sessions. Different policies for different types of
conferences and different requirements for different media types
have to be considered (symmetric vs. asymmetric configurations,
equal rights for participants or not etc.) The negotiation and
changing of the configuration can be applied on existing
application sessions (re-negotiation) or on newly created
application sessions. See Section 5 for the description of a
model for configuration and capability negotiation.
SCCP can be used to provide support for horizontal application creating application sessions: defines a media/application set being
protocols, by defining specific objects such as variables and tokens identified by a unique identifier within the conference. The
for this purpose. This may allow application protocols to use a more allowance to create application sessions depends on the
lightweight transport protocol for their application data. conference policy, e.g., in a conducted conference only the
conductor is allowed to create application sessions. The members
of the application session are stored in the appropriate
application session context entry.
4.4. Messages terminating application sessions: an SCCP entity (as permitted in
the conference profile) deletes an application session. The
conference context is updated and the termination is signaled to
the appropriate local application(s).
The context is updated by an ordered sequence of SCCP messages. Each joining application sessions: an SCCP entity starts the application
message is an ordered sequence of one or more SCCP actions, all of which then joins the SCCP application session. The conference
which are applied to the conference context in one atomic step. It context is updated appropriately by adding the application as a
is the task of the conference controller to check the SCCP actions peer in the media/application set.
against the policy of the conference and perform only actions from
messages that respect this policy. In the following text, a clear
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 leaving application sessions: an SCCP entity terminates the local
application and leave the SCCP application session. The
conference context is updated appropriately.
SCCP is responsible for maintaining a (to a certain degree) inexact application sessions: For large conferences, it may make
consistent membership list of all current conference participants. sense to mark an application session as "inexact", i.e., no join
Changes to the membership list are initiated by the following two or leave messages are to be distributed. This may also be useful
operations: in case that application protocols are able to maintain
membership information by themselves.
o JOIN 3.3 Floor Control
The SCCP entity of an end system that wants to join a conference SCCP provides floor control facilities to support application state
distributes a JOIN message to the SCCP transport of the respective synchronization. Additionally, conductorship of conferences is also
conference. Upon receipt of this message the members of the realized using the floor control functionality.
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 Hence, SCCP supports to map "social protocols", i.e., the rules to
access application objects like audiovisual streams, onto
distributed systems. However, the mapping of floors onto application
semantics is not within the scope of SCCP.
When an end system decides to leave a conference, its SCCP entity Each floor within SCCP is identified using a conference-unique name.
distributes a LEAVE message to the conference so that all The naming pattern is not within the scope of SCCP.
participants are informed about the state change.
[We need a system to ascertain membership regularly in those cases Hence, SCCP provides the following floor control services:
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 grab floor: allocates a floor for exclusive use by the requesting
participant
An SCCP entity contacts the participant to be invited (more inhibit floor: allocates a floor for non-exclusive use by several
correctly: one or more presences of this participant) by sending an participants
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 release floor: releases a previously allocated floor; the state of
the floor is changed accordingly
To join a conference, an SCCP entity needs as contact information: test floor: ask for the current state (F_FREE, F_GRABBED,
The name (transport address) of the conference and possibly some F_INHIBITTED) of the floor
authentication information.
A joining entity distributes a JOIN message. (Conferences may start ask floor: ask the current floor holder to grant an exclusive floor
out empty. In this case, JOIN messages by the first member will not to the requesting SCCP entity
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 give floor: grant an exclusive floor to another participant
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 holders of floor: ask for a list of current floor holders
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 It can be seen that the provided floor control service is very
similar to the T.122 services [8] of the H.323 standard. However,
requesting the current floor holder list is not supported by the
T.122 standard.
Together with one or more ACCEPT actions, a receptionist distributes 4. Requirements for Mappings onto underlying Transports
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 As previously mentioned in the introduction, this draft does not
submits a message containing a CONTEXT action and the time this specify the mappings onto different transport layer mechanisms.
message is distributed, the new member must be aware of the position However, some basic functionality is assumed by the underlying
in the sequence of messages for which the CONTEXT action is current. transport to provide.
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.
A new member that wants to obtain the conference context simply The requirements for transport mappings are:
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 Reliable message transport: Transport layer services are 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.
When considering unicast transfer of messages, a "connection
failure indication" is mandatory to be delivered to the SCCP
layer.
If the conference profile allows this, any SCCP entity can distribute Globally ordered message delivery: Messages are globally ordered.
a LEAVE message with the identification of a participant that now no Each message is assigned a message number by the appropriate
longer is a member of the conference. Any conference participant can transport service, and messages are delivered to SCCP entities
distribute a LEAVE message for itself. An SCCP entity receiving a in monotonic message number order. In the rest of this
LEAVE message removes the participant listed from the (conference document, the term "distribute" will be used to indicate that
membership list and application session membership lists of the) a member end system sends a message using the transport
conference context. service.
If the receptionist wants to leave the conference, it transfers its 5. A Model for Configuration and Capability Negotiation
receptionist function beforehand (see 6).
A forced leave message might include a new session key to enforce This section provides a model for configuration and capability
that the ejected member can no longer take part in the conference. negotiation adopted from [6].
5.5. Terminating a conference In this document, the features enabled and restricted by fixed
hardware and software resources of end systems are termed "system
capabilities". For example, the capability to process (or generate)
audio data of a given codec format is one of the system capabilities
of an audio conferencing system.
An SCCP entity that is granted -- from the conference profile -- the In multiparty multimedia conferences, participants employ different
permission to terminate the conference does so by distributing a "components" in conducting the conference.
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 Example: In lecture multicast conferences one component might be
the voice transmission for the lecturer, another the transmission
of video pictures showing the lecturer and the third the
transmission of presentation material.
There are two possibilities that require the SCCP entity performing Depending on system capabilities, user preferences and other
the function of the receptionist/statekeeper to change: a) when the technical and political constraints, different configurations can be
current holder of this function leaves the conference (voluntarily or chosen to accomplish the "deployment" of these components.
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 Each component can be characterized at least by (a) its intended use
(i.e., the function it shall provide) and (b) a one or more possible
ways to realize this function. Each way of realizing a particular
function is referred to as a "configuration".
[Fix me.] In the first case (orderly release), the receptionist Example: A conference component's intended use may be to make
simply sends out a LEAVE message to the group. Each member of the transparencies of a presentation visible to the audience on the
conference notices that the leaving entity currently acts as the Mbone. This can be achieved either by a video camera capturing
receptionist and that consequently a new receptionist has to be the image and transmitting a video stream via some video tool or
found. As all members of the conference keep a consistent state by loading a copy of the slides into a distributed electronic
information base (including the sequence in which the members whiteboard. For each of these cases, additional parameters may
joined[7]), the conference, this is done by simply selecting the exist, variations of which lead to additional configurations (see
oldest remaining conference member that is receptionist-capable to below).
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 Two configurations are considered different regardless of whether
not been detected so far), the REPECTIONIST-IS message will not show they employ entirely different mechanisms and protocols (as in the
up. Therefore, all receptionist-capable members of the group react previous example) or they choose the same and differ only in a
after a timeout (TBD) as described below for case b). single parameter.
In case of temporarily inconsistent membership information multiple Example: In case of video transmission, a JPEG-based still image
RECEPTIONIST-IS messages may be sent. This situation is treated as protocol may be used, H.261 encoded CIF images could be sent as
if multiple receptionist changes occur, and consequently the entity could H.261 encoded QCIF images. All three cases constitute
whose message is delivered last becomes the new receptionist. different configurations. Of course there are many more detailed
protocol parameters.
In the second case (failure), a recovery mechanism is invoked. If a In this system model, we distinguish two types of configurations:
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 o potential configurations
(a set of any number of configurations per component) indicating
a system's functional capabilities as constrained by the intended
use of the various components;
[The statekeeper is not defined in this version of this document.] o actual configurations
(exactly one per instance of a component) reflecting the mode of
operation of this component's particular instantiation.
7. Setting variables Example: The potential configuration of the aforementioned video
component may indicate support for JPEG, H.261/CIF, and
H.261/QCIF. A particular instantiation for a video conference
may use the actual configuration of H.261/CIF for exchanging
video streams.
Actions are defined for setting the various fields of objects such as In summary, the key terms of this model are:
variables, tokens, and sessions.
o SETVALUE: sets the value field. o A multimedia session (streaming or conference) consists of one or
more conference components for multimedia "interaction".
o SETFLAG: sets the flag field under a bitmask. o A component describes a particular type of interaction (e.g.,
audio conversation, slide presentation) that can be realized by
means of different applications (possibly using different
protocols).
o ADDNAME: adds a name to the namelist. o A configuration is a set of parameters that are required to
implement a certain variation (realization) of a certain
component. There are actual and potential configurations.
o DELNAME: removes a name from the namelist. * Potential configurations describe possible configurations that
are supported by an end system.
o DELETE: deletes an object. * An actual configuration is an "instantiation" of one of the
potential configurations, i.e. a decision how to realize a
certain component.
SETVALUE and SETFLAG can also be applied to member objects. In less abstract words, potential configurations describe what a
system can do ("capabilities") and actual configurations describe
how a system is configured to operate at a certain point in time
(media stream spec).
_________________________ To decide on a certain actual configuration, a negotiation process
[7] This information is propagated to new members through the needs to take place between the involved peers:
ordering of the member objects in the CONTEXT message.
8. Management of the set of applications/media that constitute the 1. to determine which potential configuration(s) they have in
conference common, and
Each application session is described by a session object in the 2. to select one of this shared set of common potential
conference context. The name of the session object identifies the configurations to be used for information exchange (e.g., based
session within the conference. upon preferences, external constraints, etc.).
Application specific parameters are indicated in the value of the In SAP [3]-based session announcements on the Mbone, for which SDP
session object. (for SDP style parameters e.g. media address, port was originally developed, the negotiation procedure is non-existent.
number and format [5]). As part of its own member state, each SCCP Instead, the announcement contains the media stream description sent
entity maintains a list of application sessions it is a member of; in out (i.e., the actual configurations) which implicitly describe what
the conference context, this current actual membership is indicated a receiver must understand to participate.
in the namelists of the member objects unless the session is marked
as inexact by flag 0 (see below).
8.1. Creating application sessions In point-to-point scenarios, the negotiation procedure is typically
carried out implicitly: each party informs the other about what it
can receive and the respective sender chooses from this set a
configuration that it can transmit.
An SCCP entity (that is permitted to do so via the conference profile Capability negotiation must not only work for 2-party conferences
-- in conducted conferences typically the conductor) distributes an but is also required for multi-party conferences. Especially for the
AS-CREATE message with the session parameters. An application latter case it is required that the process of determining the
session is identified by a unique identifier. The namelist of the subset of allowable potential configurations is deterministic to
session object specifies the set of members that are to join the reduce the number of required round trips before a session can be
session, if the special name ``*'', it specifies that all members are established.
to join the session.
8.2. Terminating application sessions 6. SDP considerations
An SCCP entity (as permitted by the conference profile) distributes This section defines how to describe conferences that make use of
an AS-DELETE message with the name of the session. All other SCCP with SDP. Note the transport mappings for SCCP will require
entities remove the session from the conference context and indicate additional parameters to be configured and thus provide extensions
termination of the session to the corresponding local application. to the SDP conventions presented here.
8.3. Joining application sessions Usage of SCCP MUST be described in separate media description, where
the media type of an SCCP media description is "control", i.e. the
first sub-field of the m= line of the SCCP description has the value
"control".
An SCCP entity starts the application and distributes an AS-JOIN As specified in [4] the second sub-field is the transport port to
message with the identifier of the session. The SCCP entities note which the media stream will be sent. In this case it is RECOMMENDED
in their conference context that this member now is a peer to the that for transport mappings where the concept of a transport port
application session. number is applicable the value of this field is interpreted as a
port number. Even if this is not the case the second sub-field MUST
contain a decimal number in the range 1024 to 65535 inclusive. If
the transport mapping requires a range of port numbers to be
specified the first port number MUST be followed by a "/" and the
number of ports as a decimal number (as specified in [4]).
8.4. Leaving application sessions The third sub-field specifies the transport protocol. The first
portion of the value MUST be set to "SCCP" followed by "/" and an
identifier for the SCCP transport mechanism (to be defined in
corresponding transport mapping specifications).
An SCCP entity distributes an AS-LEAVE message with the identifier of In SDP, the fourth sub-field is used to specify media formats as RTP
the session and terminates the application. The other SCCP entities payload types. For SCCP, the value "0" MUST be used.
take note in the member object. A LEAVE message implies leaving all
application sessions.
8.5. Inexact application sessions Additional attributes that might be defined in "a=" lines are yet to
be defined (or specified by transport mapping specifications.)
For large conferences, it may make sense to mark an application Example of an SCCP description in SDP:
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.
9. Token control m=control 30000 SCCP/XY 0
To support synchronization such as floor control (possibly with 7. Security Considerations
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, The authentication and encryption model for SCCP will be defined in
TOKEN-GIVE to transfer it and TOKEN-RELEASE to relinquish it. A a future version of this document.
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), References
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 [1] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The
obtain the token. A flag in the TOKEN-WANT message indicates whether Internet Multimedia Conferencing Architecture", Internet Draft
exclusive or shared control of the token is desired. draft-ietf-mmusic-confarch-03.txt, July 2000.
o If the token is in the FREE state, the TOKEN-WANT automatically [2] Handley, , Schulzrinne, H., Schooler, and Rosenberg, "SIP:
assigns the token to the requester (provided the conference Session Initiation Protocol", Internet Draft
policy permits giving the token to the requester). draft-ietf-sip-rfc2543bis-02.txt, November 2000.
o If the token is in the EXCLUSIVE state, the token holder has to [3] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
decide whether to pass the token on to the requester Protocol", RFC 2974, October 2000.
(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 [4] Handley, M. and V. Jacobsen, "SDP: Session Description
request. A request for the shared token is implicitly granted Protocol", RFC 2327, April 1998.
(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 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
appropriately privileged SCCP entity indicating the desired token "RTP: A Transport Protocol for Real-Time Applications", RFC
control state: assigned to one or more explicitly listed 1889, January 1996.
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 [6] Kutscher, , Ott, and Bormann, "Requirements for Session
Description and Capability Negotiation", Internet Draft
draft-kutscher-mmusic-sdpng-req-01.txt, November 2000.
The authentication and encryption model for SCCP will be defined in a [7] ITU-T, "Visual Telephone Systems and Equipment for Local Area
future version of this document. Networks with Non-Guaranteed Quality of Service", ITU-T
Recommendation H.323, 2000.
Any interoperation between ITU-based systems and Internet-based [8] ITU-T, "Multipoint communication service - Service definition",
systems must take care to preserve the point-to-point link based ITU-T Recommendation T.122, February 1998.
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 Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen FB3 MZH 5180 TZI, Universitaet Bremen
Postfach 330440 Bibliothekstr. 1
D-28334 Bremen Bremen 28359
GERMANY 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 Phone: +49.421.218-7024
Multimedia Conferencing Architecture,'' Internet Draft draft- Fax: +49.421.218-7000
ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. EMail: cabo@tzi.org
Dirk Kutscher
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
[2] ITU T.120 series, in particular T.122/125 (MCS) and T.124 (GCC). Phone: +49.421.218-7595
Fax: +49.421.218-7000
EMail: dku@tzi.org
[3] Mark Handley, Eve Schooler, ``Session Invitation Protocol,'' Joerg Ott
Internet Draft draft-ietf-mmusic-sip-00.txt, Work in Progress, TZI, Universitaet Bremen
February 1996. Bibliothekstr. 1
Bremen 28359
Germany
[4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A Phone: +49.421.201-7028
Transport Protocol for Real-Time Applications,'' Internet RFC Fax: +49.421.218-7000
1889, January 1996. EMail: jo@tzi.org
[5] M. Handley, V. Jacobson, ``SDP: Session Description Protocol,'' Dirk Trossen
Internet Draft draft-ietf-mmusic-sdp-01.txt, .ps, Work in Nokia Research Center
Progress, November 1995. 5 Wayside Road
Burlington, MA 01803
USA
A. Message formats Phone: +1.781.993-3605
Fax: +1.781.993-1907
EMail: dirk.trossen@nokia.com
[Issue: Note that this XDR-like specification does not necessarily Appendix A. Message Formats
imply any particular type of encoding of the SCCP PDUs. The encoding
may be defined independently, or RFC 1832 encoding may be used.]
/* Note that this XDR-like specification does not imply any particular
* $Id: sccp.xdr,v 1.7 1996/06/12 19:55:13 cabo Exp $ type of encoding of the PDUs. The encoding may be defined
* independently, or RFC 1832 encoding may be used.
* Common types for SCCP and the API.
*/
/* basic type definitions */
typedef string SCCP_Name<>; typedef string SCCP_Name<>;
typedef int SCCP_Flags;
typedef opaque SCCP_Value<>; typedef opaque SCCP_Value<>;
typedef SCCP_Name SCCP_Namelist<>; typedef SCCP_Name SCCP_Namelist<>;
typedef integer SCCP_Sync;
/* /* Status of a floor to be given back with most requests */
* Presence: UCI space Hostname enum SCCP_Status {
* UCI: user@hostname (where hostname is SIP relevant) F_FREE,
*/ F_GRABBED,
F_INHIBITED,
F_GIVING
};
/* Flag of an application session (see also section 3.2) */
enum SCCP_AS_Flag {
AS_EXACT,
AS_INEXACT
};
/* Error for requests, currently only for floor control */
enum SCCP_Error {
SCCP_E_GRABBED, /* floor grabbed */
SCCP_E_INHIBITED, /* floor inhibited */
SCCP_E_FREE /* floor free */
};
struct SCCP_Object { /* SCCP_AS is the application session in the conference context
* Name: identifies the application session
* flag: exact or inexact session description
* value: reflects upper layer semantic
* namelist: list of media/application sets
*/
struct SCCP_AS {
SCCP_Name name; SCCP_Name name;
SCCP_Flags flags; SCCP_AS_Flag flag;
SCCP_Value value; /* upper layer semantics */ SCCP_Value value; /* upper layer semantics */
SCCP_Name namelist<>; SCCP_NameList namelist;
}; };
/* /* SCCP_Member is the member entry in the conference context
* vars: completely user defined * presence: presence information of the member
*
* Session: 0 = inexact
*
* mEmBer: 0 = precept; namelist is AS list
* (space in name)
*
* TOKEN: 0 = shared; namelist is holder list
*/ */
struct SCCP_Member {
struct SCCP_Context { SCCP_Name presence;
SCCP_Object vars<>;
SCCP_Object tokens<>;
SCCP_Object sessions<>;
SCCP_Object members<>;
};
enum SCCP_Sync_Type {
SCCP_S_TRANSPORT,
SCCP_S_COOKIE
};
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) { /* SCCP_Floor is the core entry in the floor context
case SCCP_S_TRANSPORT: * Name: identifies the floor
int transport_serial; * status: status of floor
case SCCP_S_COOKIE: * Holders: list of floor holders for inhibited floor
SCCP_Cookie cookie; * mapping_data: implementation-dependent data to be stored for
administration purpose
*/
struct SCCP_Floor {
SCCP_Name name;
SCCP_Status status;
SCCP_NameList Holders;
SCCP_Value mapping_data;
}; };
struct SCCP_Context_Msg { /* SCCP_Conference_Context contains list of
SCCP_Context context; * - members
SCCP_Sync_Un sync; * - sessions
*/
struct SCCP_Conference_Context {
SCCP_Member members<>;
SCCP_AS sessions<>;
}; };
/* /* SCCP_Floor_Context contains list of floors to be maintained
* for SRM adaptation protocol: include depending on the chosen mapping for realization
* string name<>; // conference name
* in each message.
* This is not needed for MTP-2 or MTCP, as the context is clear.
*/ */
struct SCCP_Floor_Context {
struct SCCP_Header { SCCP_Floor floors<>;
char proto[4]; /* "sccp" */
char sccp[4]; /* "01.1" */
SCCP_Name sender; /* Presence name of sender of this message */
}; };
enum SCCP_Type { enum SCCP_Type {
SCCP_T_JOIN, /* join conference */ SCCP_T_JOIN, /* join conference */
SCCP_T_LEAVE, /* leave conference */ SCCP_T_LEAVE, /* leave conference */
SCCP_T_ACCEPT, /* accept joining member */ SCCP_T_ACCEPT, /* accept joining member */
SCCP_T_CONTEXT, /* context */ SCCP_T_CONTEXT, /* context */
SCCP_T_SYNC, /* context sync */
SCCP_T_ASCREATE, /* create application session */ SCCP_T_ASCREATE, /* create application session */
SCCP_T_ASDELETE, /* delete application session */ SCCP_T_ASDELETE, /* delete application session */
SCCP_T_ASJOIN, /* join application session */ SCCP_T_ASJOIN, /* join application session */
SCCP_T_ASLEAVE, /* leave application session */ SCCP_T_ASLEAVE, /* leave application session */
SCCP_T_TOKCREATE, /* create a token */ SCCP_T_FLOOR_GRAB, /* grab floor */
SCCP_T_TOKDELETE, /* delete a token */ SCCP_T_FLOOR_INHIBIT, /* inhibit floor */
SCCP_T_TOKWANT, /* want or grab a token */ SCCP_T_FLOOR_RELEASE, /* release floor */
SCCP_T_TOKGIVE, /* give token */ SCCP_T_FLOOR_TEST, /* test floor */
SCCP_T_TOKRELEASE, /* release token */ SCCP_T_FLOOR_ASK, /* ask for floor */
SCCP_T_FLOOR_GIVE, /* give floor to other user */
SCCP_T_SETVALUE, /* set value of var, token, session, member */ SCCP_T_FLOOR_GIVEN, /* indication to originator */
SCCP_T_SETFLAG, /* set flag of var, session, member, (token) */ SCCP_T_FLOOR_HOLDER, /* ask for floor holder list */
SCCP_T_DELETE, /* delete var */ SCCP_T_FLOOR_HOLDER_ASK, /* collect floor holder list */
SCCP_T_ADDNAME, /* add name to var */ SCCP_T_FLOOR_HOLDER_LIST, /* indicate floor holder list */
SCCP_T_DELNAME, /* delete name from var */ SCCP_T_FLOOR_STATUS, /* indicate floor status */
SCCP_T_FLOOR_ERROR, /* floor control error */
SCCP_T_RCPTIS, /* announce receptionist */
SCCP_T_RECOVER, /* recovery message */
SCCP_T_INVALID /* last and invalid sccp pdu type */ SCCP_T_INVALID /* last sccp pdu type */
}; };
struct SCCP_Join { struct SCCP_Join {
SCCP_Name presence; /* joining member */ SCCP_Name presence; /* joining member */
SCCP_Flags flags; /* precept etc. */ SCCP_Flags flags; /* precept etc. */
SCCP_Value value; /* user data */ SCCP_Value value; /* user data */
SCCP_Sync sync; /* cookie (timestamp etc.) */
}; };
struct SCCP_AS { struct SCCP_Accept {
SCCP_Name presence; /* joining member */
};
struct SCCP_Leave {
SCCP_Name presence; /* joining member */
};
struct SCCP_Context_Msg {
SCCP_Conference_Context context;
SCCP_Sync sync;
};
struct SCCP_AS_Create {
SCCP_Name name; SCCP_Name name;
SCCP_Value value; SCCP_Value value;
SCCP_Namelist names; SCCP_Namelist names;
}; };
struct SCCP_AddDelname { struct SCCP_AS_Delete {
SCCP_Name objname; SCCP_Name name;
};
struct SCCP_AS_Join {
SCCP_Name name;
SCCP_Name entry; SCCP_Name entry;
}; };
struct SCCP_Recover { struct SCCP_AS_Leave {
unsigned int beacon; SCCP_Name name;
SCCP_Name entry;
};
struct SCCP_Floor_Grab {
SCCP_Name presence;
SCCP_Name floor;
}; };
struct SCCP_TOKwant { struct SCCP_Floor_Inhibit {
SCCP_Name name; /* name of token */ SCCP_Name presence;
SCCP_Name presence;/* member the token is to be assigned to*/ SCCP_Name floor;
SCCP_Flags shared; /* want token shared or exclusive */
bool notify; /* inform holder the token is wanted */
}; };
struct SCCP_TOKgive { struct SCCP_Floor_Release {
SCCP_Name name; /* name of token */ SCCP_Name presence;
SCCP_Name giver; /* member from whom the token is taken away */ SCCP_Name floor;
SCCP_Name receiver; /* member to whom the token is given */
}; };
struct SCCP_setvalue { struct SCCP_Floor_Test {
SCCP_Name var; /* name of var to set */ SCCP_Name presence;
SCCP_Value val; /* new value */ SCCP_Name floor;
}; };
struct SCCP_setflags { struct SCCP_Floor_Ask {
SCCP_Name var; /* name of var to set */ SCCP_Name presence;
SCCP_Flags mask; /* select the flags to be modified */ SCCP_Name floor;
SCCP_Flags flags; /* new flags */ };
struct SCCP_Floor_Give {
SCCP_Name presence_given;
SCCP_Name presence_giving;
SCCP_Name floor;
};
struct SCCP_Floor_Given {
SCCP_Name presence_given;
SCCP_Name presence_giving;
SCCP_Name floor;
};
struct SCCP_Floor_Holder {
SCCP_Name presence;
SCCP_Name floor;
};
struct SCCP_Floor_Holder_Ask {
SCCP_Name presence;
SCCP_Name floor;
SCCP_NameList floor_holders;
};
struct SCCP_Floor_Holder_List {
SCCP_Name presence;
SCCP_Name floor;
SCCP_NameList floor_holders;
};
struct SCCP_Floor_Status {
SCCP_Object floor;
};
struct SCCP_Floor_Error {
SCCP_Name presence;
SCCP_Name floor;
SCCP_Error error;
}; };
union SCCP_Union switch (SCCP_Type type) { union SCCP_Union switch (SCCP_Type type) {
case SCCP_T_JOIN: case SCCP_T_JOIN:
SCCP_Join join; SCCP_Join JOIN;
case SCCP_T_LEAVE:
SCCP_Name leave;
case SCCP_T_ACCEPT: case SCCP_T_ACCEPT:
SCCP_Name accept; SCCP_Accept ACCEPT;
case SCCP_T_LEAVE:
SCCP_Leave LEAVE;
case SCCP_T_CONTEXT: case SCCP_T_CONTEXT:
SCCP_Context_Msg context_msg; SCCP_Context_Msg CONTEXT;
case SCCP_T_SYNC:
SCCP_Sync sync;
case SCCP_T_ASCREATE: case SCCP_T_ASCREATE:
SCCP_AS ascreate; SCCP_AS_Create AS_CREATE;
case SCCP_T_ASDELETE: case SCCP_T_ASDELETE:
SCCP_Name asdelete; SCCP_AS_Delete AS_DELETE;
case SCCP_T_ASJOIN: case SCCP_T_ASJOIN:
SCCP_AddDelname asjoin; /* member, session */ SCCP_AS_Join AS_JOIN; /* member, session */
case SCCP_T_ASLEAVE: case SCCP_T_ASLEAVE:
SCCP_AddDelname asleave; /* member, session */ SCCP_AS_Leave AS_LEAVE; /* 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: case SCCP_T_FLOOR_GRAB:
SCCP_Name rcptis; SCCP_Floor_Grab FLOOR_GRAB;
case SCCP_T_RECOVER: case SCCP_T_FLOOR_INHIBIT:
SCCP_Recover recover; SCCP_Floor_Inhibit FLOOR_INHIBIT;
case SCCP_T_FLOOR_RELEASE:
SCCP_Floor_Release FLOOR_RELEASE;
case SCCP_T_FLOOR_TEST:
SCCP_Floor_Test FLOOR_TEST;
case SCCP_T_FLOOR_ASK:
SCCP_Floor_Ask FLOOR_ASK;
case SCCP_T_FLOOR_GIVE:
SCCP_Floor_Give FLOOR_GIVE;
case SCCP_T_FLOOR_GIVEN:
SCCP_Floor_Given FLOOR_GIVEN;
case SCCP_T_FLOOR_HOLDER:
SCCP_Floor_Holder FLOOR_HOLDER;
case SCCP_T_FLOOR_HOLDER_ASK:
SCCP_Floor_Holder_Ask FLOOR_HOLDER_ASK;
case SCCP_T_FLOOR_HOLDER_LIST:
SCCP_Floor_Holder_List FLOOR_HOLDER_LIST;
case SCCP_T_FLOOR_STATUS:
SCCP_Floor_Status FLOOR_STATUS;
case SCCP_T_FLOOR_ERROR:
SCCP_Floor_Error FLOOR_ERROR;
}; };
struct SCCP_Message { struct SCCP_Message {
SCCP_Header hdr; SCCP_Header hdr;
SCCP_Union sccp_un<>; SCCP_Union sccp_un<>;
}; };
B. Transport mappings Full Copyright Statement
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.
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
.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
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]
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
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))',
();
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");
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")))', ("*")),
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", Copyright (C) The Internet Society (2001). All Rights Reserved.
"Video-session-0");
After some discussion, one participant leaves the conference: This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
as-leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", The limited permissions granted above are perpetual and will not be
"Audio-session-0"), revoked by the Internet Society or its successors or assigns.
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 This document and the information contained herein is provided on an
not generate redundant AS-LEAVE actions: "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
leave("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"); Acknowledgement
The initiator, knowing that it is the only remaining member, simply Funding for the RFC editor function is currently provided by the
discards its copy of the conference context. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/