INTERNET-DRAFT                                           Carsten
Network Working Group                                            Bormann
Internet-Draft                                                  Kutscher
Expires: December 1996 August 14, 2001                                             Ott
                                                TZI, Universitaet Bremen
                                           Joerg Ott, Christoph Reichert
                                                               TU Berlin
                                                               June 1996
                                                                 Trossen
                                                   Nokia Research Center
                                                       February 13, 2001

      Simple Conference Control Protocol
                     draft-ietf-mmusic-sccp-00.txt -- Service Specification
                     draft-ietf-mmusic-sccp-01.txt

Status of this memo Memo

   This document is an Internet-Draft. Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 Internet-Drafts as reference
   material or to cite them other than as ``work "work in progress.'' progress."

   To learn view the current status entire list of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Internet-Draft Shadow
   Directories Directories, see
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire 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. August 14, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   This document defines the services for a simple conference control
   protocol (SCCP) to be used for tightly coupled conferences, based on conferences. It is
   part of the Internet Multimedia Conferencing Architecture Architecture, proposed
   in [1].

   The functions provided are based on
   the SCCP services offered by the ITU-T recommendations provide functionality for management of the T.120 (and
   H.320) series [2], they are, however, not a simple ``port'' set 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
   members, management 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 set of IP multicast both for
   multimedia information application/media sessions, and
   for other applications and floor control
   streams. to implement access control rules for distributed
   application resources.

   Note that this document does not specify how to implement the
   proposed services. For that, different mappings are specified based
   on different transport layer techniques.

   This document is a product of the IETF MMUSIC Multiparty Multimedia Session
   Control (MMUSIC) working group. 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.

Table of Contents

   1.  Introduction

   The Internet Multimedia Conferencing Architecture [1] currently
   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 SCCP and control
   streams.

   Conferences that are controlled by Conference Setup  . . . . . . . . . . . . . . . . . .  3
   1.3 SCCP may be convened using an
   invitation protocol such as SIP [3]. and Capability Negotiation  . . . . . . . . . . . . . . .  4
   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.

   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.

   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).

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.

   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 Terms  . . . . . . . . . . . . . . . . . . . . .  5
   3.  Services 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 . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1 Conference Management  . . . . . . . . . . . . . . . . . . . .  7
   3.2 Application Session Management . . . . . . . . . . . . . . . .  7
   3.3 Floor 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  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Requirements for upward compatibility of semantics versions in
   SCCP or in the semantics documents?]

4.3.  Application support

   SCCP can be used to provide support Mappings onto underlying Transports . . . . . 10
   5.  A Model for horizontal application
   protocols, by defining specific objects such as variables Configuration and tokens
   for this purpose.  This may allow application protocols to use a more
   lightweight transport protocol for their application data.

4.4.  Messages Capability Negotiation . . . . . 11
   6.  SDP considerations . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
   A.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 18
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24

1. Introduction

1.1 Overview

   The context is updated by an ordered sequence of SCCP messages.  Each
   message is Internet Multimedia Conferencing Architecture [1] currently
   comprises conference control elements only for loosely coupled
   conferences, i.e., "crowds that gather around an ordered sequence of one or attraction".
   However, many conferences have more SCCP actions, all of
   which are applied formal policies with respect to
   the conference context in one atomic step.  It
   is the task underlying "social protocol" of the conference controller specific scenario. Also, it
   may be desirable to check the SCCP actions
   against the policy change parameters of the conference conference, e.g., set
   of media/applications and perform only actions from
   messages their parameters, in a coordinated way for
   all participants. Conferences that respect have facilities for this policy.  In the following text, a clear
   separation will generally not purpose
   shall be made between messages and the
   actions, except where necessary for clarity.

5.  Management of the set of members participating termed "tightly coupled conferences" in the conference

   SCCP is responsible this document.

   This document defines services for maintaining a (to a certain degree)
   consistent membership list of all current simple conference participants.
   Changes to control of
   tightly coupled conferences. The services provided by this protocol
   were guided by the membership list are initiated services offered by the following two
   operations:

   o    JOIN

   The SCCP entity ITU-T recommendations of an end system that wants to join a conference
   distributes a JOIN message to
   the SCCP transport H.323 series [7], namely:

   o  management of the respective
   conference.  Upon receipt set 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 participating in the membership list. conference;

   o    LEAVE

   When an end system decides to leave a conference, its SCCP entity
   distributes a LEAVE message to  management of the conference so that all
   participants are informed about set of media/application sessions that
      constitute the state change.

   [We need a system to ascertain membership regularly in those cases
   where this is desired, e.g. DOUBT/CONFIRM conference; and LEAVE

   o  floor control, which especially enables "conducted" conferences
      or implementation of arbitrary access control on timeout.  This
   would generally distributed
      resources.

   Note that this document specifies only the services to be done by provided
   but not the statekeeper, although members that
   have applications with their own membership control protocol mechanisms may
   also want to generate DOUBT messages.]

5.1.  Invitation

   An SCCP entity contacts the participant be used for implementation. The
   latter are to be invited (more
   correctly: one or more presences of this participant) specified by sending an
   invitation message (e.g. as payload information within SIP [3]). different "mapping drafts" for
   specific transport layer techniques.

1.2 SCCP and Conference Setup

   The
   invitation contains contact point information: Internet Multimedia Conferencing Architecture described in [1]
   provides a categorization of conference name,
   transport contact information, management concepts and possibly authentication
   information.
   corresponding technologies. The end system representing the participant domain of conference management is
   divided into conference setup (including conference discovery) and
   conference course control.

   While conference setup mechanisms, such as SIP [2], provide means to be
   invited can use this information
   distribute a proper initial state to join the conference or it can use
   mechanisms defined outside involved end systems, the
   purpose of a conference course control protocol like SCCP (e.g., an SIP BUSY message) is to
   deny joining.

5.2.  Joining
   manage a conference

   To join state during the lifetime of a conference, an conference.

   However, in cases where conferences are set up with SIP, the state
   managed by SCCP entity needs as contact information:
   The name (transport address) of would incorporate the initial conference and possibly some
   authentication information.

   A joining entity distributes a JOIN message.  (Conferences may start
   out empty.  In this case, JOIN messages by state. This
   initial state usually includes configuration of media sessions, that
   might result from negotiation processes. One element of the first member initial
   configuration of SCCP-enabled conference will not
   receive an answer, see below.)  If be the configuration
   of the conference already has
   participants, all SCCP entities mark channel and transport mapping-specific information.

   While we clearly distinguish between the new member as JOINING.  The
   receptionist now either distributes an ACCEPT or a LEAVE message.  An
   ACCEPT message contains roles of conference setup
   and conference course control there is a copy strong relation between
   these two forms of the current conference context control and
   the it is therefore desirable
   to define a way how to emerge an initial conference profile; upon the receipt of state (setup and
   distributed with SIP, SAP, or by other means) into an ACCEPT message all SCCP-state.

1.3 SCCP entities mark the new member as ACCEPTED in their conference
   state. and Capability Negotiation

   The new participant creates the applications that are defined configuration information of application sessions in the current conference context.

   If the joining member does not receive an ACCEPT or LEAVE message
   within some time (TBD), it setup
   protocols SIP and SAP [3] is specified in a session description, in
   the first participant.  If the
   conference profile for moment this is often an SDP [4] description.

   Because SDP addresses the description of conferences only, a new
   conference description framework is available to the joining
   member and it allows the joining member to initiate currently being defined ([6]).
   This work does not only address the conference, issue of describing sessions but
   also the conference context issue of capability negotiation.

   In Section 3.2 capability (re-)negotiation is initialized with listed as one of the profile
   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
   entity assumes the functions services in future versions of this document will consider this
   model.

2. Definition of receptionist Terms

   Participant: A human being that takes part in a conference.

   Member: The system, including software and statekeeper.  If the
   joining member does not want hardware, that takes part
      in a computer conference, representing a single participant.

   End system: A host or a set of locally interconnected hosts [1] that
      is used as an interface to become statekeeper, a teleconference by a single
      participant. The end system runs all the SCCP entity
   remains passive until required conferencing
      software. Together with this software it sees activity in constitutes a member.

   SCCP (other than JOIN
   messages)[6]; it then repeats the joining procedure.

   If 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 just created in the conference profile from scratch and
   thus knows it is using
      the first member (e.g., for a simple phone call), it
   can simply create SCCP protocol.

   Conference controller: An application that interacts closely with an
      SCCP entity on one hand to implement the conference context, invite other members, policy 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 participant on the
   conference context is used other hand to initialize realize her wishes.

   UCI: A universal communication identifier of a person.  Used as the conference context in
      E-mail address of an individual as well as the newly accepted member.

   As other messages may address that can
      be distributed in the time used to invite that individual via SIP [2].

   Presence: A representation of the receptionist
   submits a message containing fact that an identified person is
      using a CONTEXT action and particular end system for the time purpose of (potentially or
      actually) representing this
   message 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 distributed, the new member must a one-to-many relationship between
      presences and members: one presence may be aware member of many
      conferences.  There is a one-to-one relationship between members
      and the position
   in the sequence cross-product of messages for which presences and the CONTEXT action is current.
   We call set of conferences
      this position presence appears in (which cross-product contains the context synchronization event.  For
   transport mappings that provide serial numbers, this set of
      "appearances" of each presence).

   Conference context: All session and membership information
   simply is the first transport serial number that was not considered kept 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,
      each member of a conference which in general will can be
   a JOIN action (or possibly a special SYNC action).  Therefore, both accessed by each SCCP
      entity through appropriate service requests.

   Profile: An initial description of these actions carry a synchronization time stamp that, together
   with the source conference, including
      assignment of the action, can be referred roles to in the CONTEXT
   action.
_________________________
  [6] This  option  is  available only particular members, time limits for transport mappings
      speakers, attributes of the conference (open/close,
      conducted/anarchic, etc).

   Application session (AS), Session: The set of media
      agents/applications that
allow passive joins.  Otherwise, act as peers to each other within a SIP based invitation  mechanism
      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
      synonyms are "application group" or "media agent group".

   Floor context: State information about floors which can be used.

   A new member accessed
      by each SCCP entity through appropriate service requests.

3. Services of SCCP

   This section describes the services provided by SCCP and realized by
   appropriate protocol mechanisms. Note that wants to obtain the conference context simply
   records all messages it receives from latter is not within
   the transport until scope of this document.

3.1 Conference Management

   SCCP is responsible for managing a conference context is received.  After applying containing
   membership information of all messages that current conference participants. The
   following operations are
   more recent than the context synchronization event to possible in the context
   received, the local copy of the context is current.

5.4.  Leaving a conference

   If the SCCP conference profile allows this, any
   management:

   invite other users: SCCP entity can distribute
   a LEAVE message with the identification of a participant that now no
   longer is a member of users may invite other users to participate
      in the current SCCP conference.  Any conference participant can
   distribute a LEAVE message for itself.  An

   join the conference: SCCP entity receiving provides to dynamically join a
   LEAVE message removes the participant listed from the (conference
   membership list and application session membership lists of the) running
      conference. The conference context.

   If the receptionist wants to context is updated appropriately.

   leave the conference, it transfers its
   receptionist function beforehand (see 6).

   A forced the conference: SCCP also provides to dynamically leave message might include a new session key to enforce
   that
      conference without disturbance. The conference context is updated
      appropriately.

   terminate the ejected member can no longer take part conference: in the conference.

5.5.  Terminating case of a "conducted" conference, a
      running conference

   An SCCP entity that is granted -- from may be terminated by the conductor resulting
      in a destruction of the entire conference.

   obtain conference profile -- context: maintain the
   permission to terminate information stored in the
      conference context.

   For sake of simplicity, SCCP does so by distributing a
   special LEAVE message with the name ``*'' not provide more sophisticated
   features like merging, appending, or splitting entire conferences.

3.2 Application Session Management

   SCCP provides functionality to all other participants,
   which indicates ``conference terminated'' as manage a set of media/application
   sessions that constitute the reason conference, e.g., for the
   exclusion from the conference.  Each SCCP entity receiving real-time data
   this
   message reacts similar to as if will be an RTP session [5].

   Each media/application set is maintained in the conference context.
   Hence, its parameters can be obtained using appropriate conference
   context functions. However, it was excluded from is also possible to create
   application sessions without registering them in the conference.

6.  Transferring conference
   context due to scalability reasons.

   Hence, SCCP offers the receptionist following application session management
   functions:

   negotiating and statekeeper functions

   There are two possibilities that require the SCCP entity performing changing the function configuration of the receptionist/statekeeper application sessions:

      allows to change: a) when the
   current holder find an appropriate configuration of this function leaves the conference (voluntarily one or
   not) in an orderly fashion; b) when the holder crashes 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 is
   partitioned away from not etc.) The negotiation and
      changing of the other conferees.

6.1.  Mechanisms configuration can be applied on existing
      application sessions (re-negotiation) or on newly created
      application sessions. See Section 5 for transferring the receptionist function

   [Fix me.]  In the first case (orderly release), the receptionist
   simply sends out description of a LEAVE message to
      model for configuration and capability negotiation.

   creating application sessions: defines a media/application set being
      identified by a unique identifier within the group.  Each member of conference.  The
      allowance to create application sessions depends on the
      conference notices that the leaving entity currently acts as the
   receptionist and that consequently policy, e.g., in a new receptionist has conducted conference only the
      conductor is allowed to be
   found.  As all create application sessions. The members
      of the conference keep a consistent state
   information base (including the sequence application session are stored in which the members
   joined[7]), the conference, this is done by simply selecting appropriate
      application session context entry.

   terminating application sessions: an SCCP entity (as permitted in
      the
   oldest remaining conference member that is receptionist-capable to
   become the new receptionist. profile) deletes an application session. 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
      conference context is treated as
   if multiple receptionist changes occur, updated and consequently the entity
   whose message termination is delivered last becomes signaled to
      the new receptionist.

   In appropriate local application(s).

   joining application sessions: an SCCP entity starts the second case (failure), a recovery mechanism is invoked.  If a
   JOIN message is not answered by application
      which then joins the receptionist within a certain
   time (TBD, dithered), each SCCP entity distributes a RECOVERY message
   unless it has already seen a RECOVERY message. application session. The RECOVERY message
   includes conference
      context is updated appropriately by adding the application as a random number,
      peer in the beacon.  The media/application set.

   leaving application sessions: an SCCP entity with the
   lowest beacon assumes terminates the receptionist function local
      application and distributes a
   RECEPTIONIST-IS message.  If two beacons are equal, the ``older''
   member wins.

6.2.  Mechanisms for transferring leave the statekeeper function

   [The statekeeper SCCP application session. The
      conference context 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 updated appropriately.

   inexact application sessions: For large conferences, it may make
      sense to the namelist.

   o    DELNAME: removes a name from the namelist.

   o    DELETE: deletes mark an object.

   SETVALUE and SETFLAG can application session as "inexact", i.e., no join
      or leave messages are to be distributed. This may also be applied useful
      in case that application protocols are able to member objects.

_________________________
  [7] This maintain
      membership information is propagated by themselves.

3.3 Floor Control

   SCCP provides floor control facilities to new  members  through  the
ordering support application state
   synchronization. Additionally, conductorship of conferences is also
   realized using the member objects in floor control functionality.

   Hence, SCCP supports to map "social protocols", i.e., the CONTEXT message.

8.  Management of rules to
   access application objects like audiovisual streams, onto
   distributed systems. However, the set mapping of applications/media that constitute the
conference

   Each floors onto application session
   semantics is described by a session object in the
   conference context.  The name of the session object identifies the
   session not 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 scope of its own member state, each SCCP.

   Each floor within SCCP
   entity maintains a list of application sessions it is identified using a member of; in
   the conference context, this current actual membership conference-unique name.
   The naming pattern is indicated
   in not within the namelists scope of the member objects unless the session is marked
   as inexact by flag 0 (see below).

8.1.  Creating application sessions

   An SCCP.

   Hence, SCCP entity (that is permitted to do so via the conference profile
   -- in conducted conferences typically provides the conductor) distributes an
   AS-CREATE message with following floor control services:

   grab floor: allocates a floor for exclusive use by the session parameters.  An application
   session is identified requesting
      participant

   inhibit floor: allocates a floor for non-exclusive use by several
      participants

   release floor: releases a unique identifier.  The namelist previously allocated floor; the state of
      the
   session object specifies floor is changed accordingly

   test floor: ask for the set current state (F_FREE, F_GRABBED,
      F_INHIBITTED) of members that are to join the
   session, if floor

   ask floor: ask the special name ``*'', it specifies that all members are current floor holder to grant an exclusive floor
      to join the session.

8.2.  Terminating application sessions

   An requesting SCCP entity (as permitted by the conference profile) distributes

   give floor: grant an AS-DELETE message with the name exclusive floor to another participant

   holders of the session.  All other
   entities remove the session from the conference context and indicate
   termination floor: ask for a list of current floor holders

   It can be seen that the session provided floor control service is very
   similar to the corresponding local application.

8.3.  Joining application sessions

   An SCCP entity starts T.122 services [8] of the application and distributes an AS-JOIN
   message with H.323 standard. However,
   requesting the identifier of current floor holder list is not supported by the session.  The SCCP entities note
   T.122 standard.

4. Requirements for Mappings onto underlying Transports

      As previously mentioned in their conference context that the introduction, this member now draft does not
      specify the mappings onto different transport layer mechanisms.
      However, some basic functionality is a peer to assumed by the
   application session.

8.4.  Leaving application sessions

   An SCCP entity distributes an AS-LEAVE underlying
      transport to provide.

      The requirements for transport mappings are:

      Reliable message with the identifier transport: Transport layer services are assumed
         to provide reliable, consistent delivery of data units called
         "messages". Reliability is bounded by the session and terminates the application.  The other SCCP entities
   take note in the fact that member object.  A LEAVE message implies leaving all
   application sessions.

8.5.  Inexact application sessions

   For large conferences, it end
         systems may make sense to mark an application
   session as inexact, i.e. find that they 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

   To support synchronization such as floor control (possibly longer can reliably interact
         with
   multiple floors) and conductorship assignment, SCCP defines a generic
   type of object, the token.

   An SCCP entity distributes a TOKEN-WANT message other members, e.g., due to request a token,
   TOKEN-GIVE to network partitioning.
         When considering unicast transfer it and TOKEN-RELEASE of messages, a "connection
         failure indication" is mandatory to relinquish it.  A
   token can be assigned exclusively delivered to a single SCCP entity or can be
   shared by any number of the SCCP entities.  In addition, members that
         layer.

      Globally ordered message delivery: Messages 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 globally ordered.
         Each message is assigned a TOKEN-WANT message indicates number by the desire appropriate
         transport service, and messages are delivered to
   obtain the token.  A flag SCCP entities
         in the TOKEN-WANT monotonic message indicates whether
   exclusive or shared control of the token is desired.

   o    If the token is in the FREE state, number order. In the TOKEN-WANT automatically
        assigns rest of this
         document, the token term "distribute" will be used to indicate that
         a member end system sends a message using the requester (provided transport
         service.

5. A Model for Configuration and Capability Negotiation

   This section provides a model for configuration and capability
   negotiation adopted from [6].

   In this document, the conference
        policy permits giving features enabled and restricted by fixed
   hardware and software resources of end systems are termed "system
   capabilities". For example, the token capability to the requester).

   o    If the token process (or generate)
   audio data of a given codec format 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 one of the flag system capabilities
   of an audio conferencing system.

   In multiparty multimedia conferences, participants employ different
   "components" in conducting the request) or not.

   o    If the token is in conference.

      Example: In lecture multicast conferences one component might be
      the SHARED state voice transmission for the behavior depends on lecturer, another the
        request.  A request for transmission
      of video pictures showing the shared token is implicitly granted
        (if lecturer and the policy, i.e. a limit on third the number
      transmission of concurrent token
        holders, permits this).  A request for an exclusive token is
        only granted if all current shared token holders decide to pass presentation material.

   Depending on the token system capabilities, user preferences and other
   technical and political constraints, different configurations can be
   chosen to accomplish the requester by means "deployment" 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 these components.

   Each component can be sent characterized at least by an
   appropriately privileged SCCP entity indicating (a) its intended use
   (i.e., the desired token
   control state: assigned to function it shall provide) and (b) a one or more explicitly listed
   participants, assigned possible
   ways to realize this function.  Each way of realizing a particular
   function is referred to as a "configuration".

      Example: A conference component's intended use may be to make
      transparencies of a presentation visible to the audience on the
      Mbone.  This can be achieved either by a video camera capturing
      the privileged entity itself, image and transmitting a video stream via some video tool or free,
   respectively.  Such
      by loading a request overrides copy of the current token state.
   Determination slides into a distributed electronic
      whiteboard.  For each of whether or not an entity is privileged is up these cases, additional parameters may
      exist, variations of which lead to the
   conference semantics layer on top additional configurations (see
      below).

   Two configurations are considered different regardless of SCCP whether
   they employ entirely different mechanisms and protocols (as is consequently in the
   decision whether
   previous example) or not modify they choose the conference state accordingly).

10.  Security Considerations

   The authentication same and encryption model for SCCP will be defined differ only in a
   future version
   single parameter.

      Example: In case of video transmission, a JPEG-based still image
      protocol may be used, H.261 encoded CIF images could be sent as
      could H.261 encoded QCIF images. All three cases constitute
      different configurations. Of course there are many more detailed
      protocol parameters.

   In this document.

   Any interoperation between ITU-based systems and Internet-based
   systems must take care to preserve system model, we distinguish two types of configurations:

   o  potential configurations
      (a set of any number of configurations per component) indicating
      a system's functional capabilities as constrained by the point-to-point link based
   security model underlying intended
      use of the ITU standards.  In T.120, much various components;

   o  actual configurations
      (exactly one per instance of a component) reflecting the
   access control relies on being able to reject mode of
      operation of this component's particular instantiation.

      Example: The potential configuration of 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, aforementioned video
      component may indicate support for JPEG, H.261/CIF, and Eve Schooler have submitted drafts
   of
      H.261/QCIF.  A particular instantiation for a more general video conference control protocol, the Agreement
   Protocol, in
      may use the MMUSIC working group actual configuration of H.261/CIF for exchanging
      video streams.

   In summary, the IETF.  Many concepts key terms of
   the Simple Conference Control Protocol this model are:

   o  A multimedia session (streaming or conference) consists of one or
      more conference components for multimedia "interaction".

   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  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.

      *  Potential configurations describe possible configurations that
         are based on discussions supported by an end system.

      *  An actual configuration is an "instantiation" of one of the agreement protocol
         potential configurations, i.e. a decision how to realize a
         certain component.

      In less abstract words, potential configurations describe what a
      system can do ("capabilities") and our experience with attempts actual configurations describe
      how a system is configured 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 operate at a certain point in Progress, February 1996.

   [2]  ITU T.120 series, time
      (media stream spec).

   To decide on a certain actual configuration, a negotiation process
   needs to take place between the involved peers:

   1.  to determine which potential configuration(s) they have in particular T.122/125 (MCS)
       common, 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.

   [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.

A.  Message formats

   [Issue: Note that this XDR-like specification does not necessarily
   imply any particular type

   2.  to select one of encoding this shared set of the SCCP PDUs.  The encoding
   may be defined independently, or RFC 1832 encoding may common potential
       configurations to be used.]

   /*
    * $Id: sccp.xdr,v 1.7 1996/06/12 19:55:13 cabo Exp $
    *
    * Common types used 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
   };
   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;
   };

   /*
    * information exchange (e.g., based
       upon preferences, external constraints, etc.).

   In SAP [3]-based session announcements on the Mbone, for SRM adaptation protocol: include
    *    string            name<>;                 // conference name
    * in each message.
    * This which SDP
   was originally developed, the negotiation procedure is not needed for MTP-2 or MTCP, as non-existent.
   Instead, the context announcement contains the media stream description sent
   out (i.e., the actual configurations) which implicitly describe what
   a receiver must understand to participate.

   In point-to-point scenarios, the negotiation procedure is clear.
    */

   struct SCCP_Header {
       char        proto[4];       /* "sccp" */
       char        sccp[4];        /* "01.1" */
       SCCP_Name   sender;         /* Presence name of typically
   carried out implicitly: each party informs the other about what it
   can receive and the respective sender of chooses from 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 a
   configuration that it can transmit.

   Capability negotiation must not only work for 2-party conferences
   but is also required for multi-party conferences. Especially for the
   latter case it is required that the process of var, token, session, member */
       SCCP_T_SETFLAG,             /* set flag determining the
   subset of var, session, member, (token) */
       SCCP_T_DELETE,              /* delete var */
       SCCP_T_ADDNAME,             /* add name allowable potential configurations is deterministic 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
   reduce the number of required round trips before a session can be
   established.

6. SDP considerations

   This section defines how to describe conferences that make use of token */
       SCCP_Name           presence;/* member
   SCCP with SDP. Note the token is transport mappings for SCCP will require
   additional parameters to be assigned to*/
       SCCP_Flags          shared;         /* want token shared or exclusive */
       bool                notify;         /* inform holder configured and thus provide extensions
   to the SDP conventions presented here.

   Usage of SCCP MUST be described in separate media description, where
   the token media type of an SCCP media description is wanted */
   };

   struct SCCP_TOKgive {
       SCCP_Name   name;           /* name "control", i.e. the
   first sub-field of token */
       SCCP_Name   giver;          /* member from whom the token m= line of the SCCP description has the value
   "control".

   As specified in [4] the second sub-field is taken away */
       SCCP_Name   receiver;       /* member the transport port to whom
   which the token media stream will be sent. In this case it is given */
   };

   struct SCCP_setvalue {
       SCCP_Name   var;            /* name RECOMMENDED
   that for transport mappings where the concept of var to set */
       SCCP_Value  val;            /* new a transport port
   number is applicable the value */
   };

   struct SCCP_setflags {
       SCCP_Name   var;            /* name of var 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 set */
       SCCP_Flags  mask;           /* select 65535 inclusive. If
   the flags transport mapping requires a range of port numbers to be modified */
       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;
   };
   struct SCCP_Message {
       SCCP_Header         hdr;
       SCCP_Union          sccp_un<>;
   };

B.  Transport mappings

   At this time,
   specified the first port number MUST be followed by a "/" and the
   number of ports as a decimal number (as specified in [4]).

   The third sub-field specifies the transport mappings are defined protocol. The first
   portion of the value MUST be set to "SCCP" followed by "/" and an
   identifier for the SCCP for two
   protocols:

   1)   A simple multipoint protocol based on TCP transport mechanism (to be defined in this annex
        (MTCP).

   2)   The multicast
   corresponding transport protocol MTP-2.

B.1.  MTCP

   Each SCCP message mapping specifications).

   In SDP, the fourth sub-field is mapped used to an MTCP message.

   The initiator of a conference operates specify media formats as RTP
   payload types. For SCCP, 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 value "0" MUST be used.

   Additional attributes that might be defined in "a=" lines are exchanged on these
   connections, delimited yet to
   be defined (or specified by using a variant of the RMS protocol (RFC
   1831 section 10): Instead transport mapping specifications.)

   Example of an SCCP description in SDP:

   	    m=control 30000 SCCP/XY 0

7. Security Considerations

   The authentication and encryption model for SCCP will be defined in
   a header with one bit future version of flag this document.

References

   [1]  Handley, M., Crowcroft, J., Bormann, C. and 31
   bits of length, MTCP uses two bits of flag J. Ott, "The
        Internet Multimedia Conferencing Architecture", Internet Draft
        draft-ietf-mmusic-confarch-03.txt, July 2000.

   [2]  Handley, , Schulzrinne, H., Schooler,  and  Rosenberg, "SIP:
        Session Initiation Protocol", Internet Draft
        draft-ietf-sip-rfc2543bis-02.txt, November 2000.

   [3]  Handley, M., Perkins, C. and E. Whelan, "Session Announcement
        Protocol", RFC 2974, October 2000.

   [4]  Handley, M. and V. Jacobsen, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [5]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
        "RTP: A Transport Protocol for Real-Time Applications", RFC
        1889, January 1996.

   [6]  Kutscher, , Ott,  and  Bormann, "Requirements for Session
        Description and 30 bits Capability Negotiation", Internet Draft
        draft-kutscher-mmusic-sdpng-req-01.txt, November 2000.

   [7]  ITU-T, "Visual Telephone Systems and Equipment for Local Area
        Networks with Non-Guaranteed Quality of length.
   The most significant bit, if set, indicates a control message; the
   rest Service", ITU-T
        Recommendation H.323, 2000.

   [8]  ITU-T, "Multipoint communication service - Service definition",
        ITU-T Recommendation T.122, February 1998.

Authors' Addresses

   Carsten Bormann
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.218-7024
   Fax:   +49.421.218-7000
   EMail: cabo@tzi.org
   Dirk Kutscher
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.218-7595
   Fax:   +49.421.218-7000
   EMail: dku@tzi.org

   Joerg Ott
   TZI, Universitaet Bremen
   Bibliothekstr. 1
   Bremen  28359
   Germany

   Phone: +49.421.201-7028
   Fax:   +49.421.218-7000
   EMail: jo@tzi.org

   Dirk Trossen
   Nokia Research Center
   5 Wayside Road
   Burlington, MA  01803
   USA

   Phone: +1.781.993-3605
   Fax:   +1.781.993-1907
   EMail: dirk.trossen@nokia.com

Appendix A. Message Formats

   Note that this XDR-like specification does not imply any particular
   type of encoding of the header is then interpreted specially.  If the control
   message bit is unset, the next to most significant bit indicates the
   final fragment PDUs. The encoding may be defined
   independently, or RFC 1832 encoding may be used.

   /* basic type definitions */
   typedef string    SCCP_Name<>;
   typedef opaque    SCCP_Value<>;
   typedef SCCP_Name SCCP_Namelist<>;
   typedef integer	 SCCP_Sync;

   /* Status of a message as in RFC1831:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|F|             length                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If the control message bit is set, the next floor to be given back with most significant bit
   indicates one requests */
   enum SCCP_Status {
   	F_FREE,
   	F_GRABBED,
   	F_INHIBITED,
   	F_GIVING
   };
   /* Flag 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 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 */
   };

   /* SCCP_AS 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 application session 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 conference context
   * Name:     identifies the same order on
   all connections.  It also sends a copy application session
   * flag:     exact or inexact session description
   * value:    reflects upper layer semantic
   * namelist: list of all messages received from
   the non-cores, except on the connection where the message was
   received, where a release event media/application sets
   */
   struct SCCP_AS {
          SCCP_Name     name;
          SCCP_AS_Flag  flag;
          SCCP_Value    value;          /* upper layer semantics */
          SCCP_NameList namelist;
   };

   /* SCCP_Member is sent instead.  It delivers
   messages to the SCCP entity member entry in the same order it sends them to conference context
   * presence: presence information of 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 member
   */
   struct SCCP_Member {
   		SCCP_Name   presence;
   };

   /* SCCP_Floor is the core, keeping a copy core entry in a
   queue.  It delivers all messages received from the core to floor context
   * Name:    identifies the SCCP
   entity.  If it receives a release event, it delivers a copy floor
   * status:  status 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 floor
   * Holders: list of semantics floor holders 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 inhibited floor
   * 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;
   };

   /* SCCP_Conference_Context contains list of
       * - 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
   */
   struct SCCP_Conference_Context {
          SCCP_Member members<>;
          SCCP_AS     sessions<>;
   };

   /* SCCP_Floor_Context contains list 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 floors to be maintained
    depending on the parser to distinguish between unicast
                         ; and multicast addresses

   STRING                = <"> *<any CHAR excluding ASCII 0 chosen mapping for realization
   */
   struct SCCP_Floor_Context {
   		SCCP_Floor floors<>;
   };

   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_ASCREATE,            /* create application session */
          SCCP_T_ASDELETE,            /* delete application session */
          SCCP_T_ASJOIN,              /* join application session */
          SCCP_T_ASLEAVE,             /* leave application session */

   SCCP_T_FLOOR_GRAB,          /* grab floor */
   SCCP_T_FLOOR_INHIBIT,       /* inhibit floor */
   SCCP_T_FLOOR_RELEASE,       /* release floor */
   SCCP_T_FLOOR_TEST,          /* test floor */
   SCCP_T_FLOOR_ASK,           /* ask for floor */
   SCCP_T_FLOOR_GIVE,          /* give floor 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 other user */
   SCCP_T_FLOOR_GIVEN,         /* ... indication to originator */ CP

C.3.  Session objects

   The session objects fields have the semantics defined in SCCP (flags:
   0x1 - inexact membership, namelist: prospective member list
   SCCP_T_FLOOR_HOLDER,        /* ask 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       : floor holder list */
   SCCP_T_FLOOR_HOLDER_ASK,    /* collect floor holder list */
   SCCP_T_FLOOR_HOLDER_LIST,   /* indicate floor holder list */
   SCCP_T_FLOOR_STATUS,        /* indicate floor status */
   SCCP_T_FLOOR_ERROR,		   /* floor control error */

          SCCP_T_INVALID              /* last sccp pdu type */
   };

   struct SCCP_Join {
          SCCP_Name     presence;       /* joining member */
          SCCP_Flags    flags;          /* precept etc. */
          SCCP_Value    value;          /* user data */
   };

   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_Value    value;
   		SCCP_Namelist names;
   };

   struct SCCP_AS_Delete {
   		SCCP_Name     name;
   };

   struct SCCP_AS_Join {
   		SCCP_Name     name;
   		SCCP_Name     entry;
   };

   struct SCCP_AS_Leave {
   		SCCP_Name     name;
   		SCCP_Name     entry;
   };
   struct SCCP_Floor_Grab {
   		SCCP_Name presence;
   		SCCP_Name floor;
   };

   struct SCCP_Floor_Inhibit {
   		SCCP_Name presence;
   		SCCP_Name floor;
   };

   struct SCCP_Floor_Release {
   		SCCP_Name presence;
   		SCCP_Name floor;
   };

   struct SCCP_Floor_Test {
   		SCCP_Name presence;
   		SCCP_Name floor;
   };

   struct SCCP_Floor_Ask {
   		SCCP_Name presence;
   		SCCP_Name floor;
   };

   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

   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 floor;
   		SCCP_Error error;
   };

   union SCCP_Union switch (SCCP_Type type) {

      case SCCP_T_JOIN:
          SCCP_Join           JOIN;
      case SCCP_T_ACCEPT:
          SCCP_Accept         ACCEPT;
      case SCCP_T_LEAVE:
          SCCP_Leave          LEAVE;
      case SCCP_T_CONTEXT:
          SCCP_Context_Msg    CONTEXT;

      case SCCP_T_ASCREATE:
          SCCP_AS_Create      AS_CREATE;
      case SCCP_T_ASDELETE:
          SCCP_AS_Delete      AS_DELETE;
      case SCCP_T_ASJOIN:
          SCCP_AS_Join        AS_JOIN; /* member, 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"(...)), */
      case SCCP_T_ASLEAVE:
          SCCP_AS_Leave       AS_LEAVE; /* each one including the contents, of course member, session */
           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");

      case SCCP_T_FLOOR_GRAB:
          SCCP_Floor_Grab     FLOOR_GRAB;
      case SCCP_T_FLOOR_INHIBIT:
          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 {
          SCCP_Header         hdr;
          SCCP_Union          sccp_un<>;
   };

Full Copyright Statement

   Copyright (C) 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"); Internet Society (2001). All Rights Reserved.

   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 document and translations of permitted persons; then the
   initiator sends a SIP invitation it may be copied and furnished to the target
   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 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 above copyright notice 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. this paragraph
   are included on all such copies and derivative works. However, the
   receptionist notices that the currently used audio encoding is this
   document itself may not
   suitable for the new member.  Therefore, the receptionist decides to
   modify the parameters of the audio session allowing be modified in any way, such as by removing
   the new member copyright notice or references 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 Internet Society or other
   Internet organizations, except as needed for the existence purpose of
   developing Internet standards in which case the audio session and that everybody is
   expected to join, the newcomer provides his parameters procedures 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,
   copyrights defined in the initiator chooses Internet Standards process must be
   followed, or as required to trade
   resolution for framerate at a given bandwidth.  By the creation the translate it into languages other participants than
   English.

   The limited permissions granted above are implicitly invited perpetual 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 will not be
   revoked by the conference:

   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, Internet Society or its successors or assigns.

   This document and 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 information contained herein is provided on an
   "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.

Acknowledgement

   Funding for the only remaining member, simply
   discards its copy of RFC editor function is currently provided by the conference context.
   Internet Society.