[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/