Network Working Group Bormann
Internet-Draft Kutscher
Expires: August 14, 2001 Ott
TZI, Universitaet Bremen
Trossen
Nokia Research Center
February 13, 2001
Simple Conference Control Protocol -- Service Specification
draft-ietf-mmusic-sccp-01.txt
Status of this Memo
This document is an 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 as reference
material or to cite them other than as "work in progress."
To view the entire list of Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on 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. It is
part of the Internet Multimedia Conferencing Architecture, proposed
in [1].
The SCCP services provide functionality for management of the set of
members, management of the set of application/media sessions, and
for floor control to implement access control rules for distributed
application resources.
Note that this document does not specify how to implement the
proposed services. For that, different mappings are specified based
Bormann, et. al. Expires August 14, 2001 [Page 1]
Internet-Draft sccp-services February 2001
on different transport layer techniques.
This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the
working group's mailing list at confctrl@isi.edu and/or the authors.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 SCCP and Conference Setup . . . . . . . . . . . . . . . . . . 3
1.3 SCCP and Capability Negotiation . . . . . . . . . . . . . . . 4
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
3. Services of SCCP . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Conference Management . . . . . . . . . . . . . . . . . . . . 7
3.2 Application Session Management . . . . . . . . . . . . . . . . 7
3.3 Floor Control . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements for Mappings onto underlying Transports . . . . . 10
5. A Model for Configuration and Capability Negotiation . . . . . 11
6. SDP considerations . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24
Bormann, et. al. Expires August 14, 2001 [Page 2]
Internet-Draft sccp-services February 2001
1. Introduction
1.1 Overview
The Internet Multimedia Conferencing Architecture [1] currently
comprises conference control elements only for loosely coupled
conferences, i.e., "crowds that gather around an attraction".
However, many conferences have more formal policies with respect to
the underlying "social protocol" of the specific scenario. Also, it
may be desirable to change parameters of the conference, e.g., set
of media/applications and their parameters, in a coordinated way for
all participants. Conferences that have facilities for this purpose
shall be termed "tightly coupled conferences" in this document.
This document defines services for simple conference control of
tightly coupled conferences. The services provided by this protocol
were guided by the services offered by the ITU-T recommendations of
the H.323 series [7], namely:
o management of the set of members participating in the conference;
o management of the set of media/application sessions that
constitute the conference; and
o floor control, which especially enables "conducted" conferences
or implementation of arbitrary access control on distributed
resources.
Note that this document specifies only the services to be provided
but not the protocol mechanisms to be used for implementation. The
latter are to be specified by different "mapping drafts" for
specific transport layer techniques.
1.2 SCCP and Conference Setup
The Internet Multimedia Conferencing Architecture described in [1]
provides a categorization of conference management concepts and
corresponding technologies. The 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
distribute a proper initial state to the involved end systems, the
purpose of a conference course control protocol like SCCP is to
manage a state during the lifetime of a conference.
However, in cases where conferences are set up with SIP, the state
managed by SCCP would incorporate the initial conference state. This
initial state usually includes configuration of media sessions, that
Bormann, et. al. Expires August 14, 2001 [Page 3]
Internet-Draft sccp-services February 2001
might result from negotiation processes. One element of the initial
configuration of SCCP-enabled conference will be the configuration
of the SCCP channel and transport mapping-specific information.
While we clearly distinguish between the roles of conference setup
and conference course control there is a strong relation between
these two forms of conference control and it is therefore desirable
to define a way how to emerge an initial conference state (setup and
distributed with SIP, SAP, or by other means) into an SCCP-state.
1.3 SCCP and Capability Negotiation
The configuration information of application sessions in the setup
protocols SIP and SAP [3] is specified in a session description, in
the moment this is often an SDP [4] description.
Because SDP addresses the description of conferences only, a new
conference description framework is currently being defined ([6]).
This work does not only address the issue of describing sessions but
also the issue of capability negotiation.
In Section 3.2 capability (re-)negotiation is listed as one of the
functionalities provided by SCCP for application session management.
Section 5 presents a model for configuration and capability
negotiation that is currently pursued by [6]. The refinement of the
SCCP services in future versions of this document will consider this
model.
Bormann, et. al. Expires August 14, 2001 [Page 4]
Internet-Draft sccp-services February 2001
2. Definition of Terms
Participant: A human being that takes part in a conference.
Member: The system, including software and 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 a teleconference by a single
participant. The end system runs all the required conferencing
software. Together with this software it constitutes a member.
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.
Conference controller: An application that interacts closely with an
SCCP entity on one hand to implement the conference policy and
with the participant on the other hand to realize her wishes.
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 SIP [2].
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).
Conference context: All session and membership information kept at
each member of a conference which can be accessed by each SCCP
entity through appropriate service requests.
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).
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
Bormann, et. al. Expires August 14, 2001 [Page 5]
Internet-Draft sccp-services February 2001
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 accessed
by each SCCP entity through appropriate service requests.
Bormann, et. al. Expires August 14, 2001 [Page 6]
Internet-Draft sccp-services February 2001
3. Services of SCCP
This section describes the services provided by SCCP and realized by
appropriate protocol mechanisms. Note that the latter is not within
the scope of this document.
3.1 Conference Management
SCCP is responsible for managing a conference context containing
membership information of all current conference participants. The
following operations are possible in the context of SCCP conference
management:
invite other users: SCCP users may invite other users to participate
in the current SCCP conference.
join the conference: SCCP provides to dynamically join a running
conference. The conference context is updated appropriately.
leave the conference: SCCP also provides to dynamically leave a
conference without disturbance. The conference context is updated
appropriately.
terminate the conference: in the case of a "conducted" conference, a
running conference may be terminated by the conductor resulting
in a destruction of the entire conference.
obtain conference context: maintain the information stored in the
conference context.
For sake of simplicity, SCCP does not provide more sophisticated
features like merging, appending, or splitting entire conferences.
3.2 Application Session Management
SCCP provides functionality to manage a set of media/application
sessions that constitute the conference, e.g., for real-time data
this 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 is also possible to create
application sessions without registering them in the conference
context due to scalability reasons.
Hence, SCCP offers the following application session management
functions:
negotiating and changing the configuration of application sessions:
Bormann, et. al. Expires August 14, 2001 [Page 7]
Internet-Draft sccp-services February 2001
allows to find an appropriate configuration of one or more
application sessions. Different policies for different types of
conferences and different requirements for different media types
have to be considered (symmetric vs. asymmetric configurations,
equal rights for participants or not etc.) The negotiation and
changing of the configuration can be applied on existing
application sessions (re-negotiation) or on newly created
application sessions. See Section 5 for the description of a
model for configuration and capability negotiation.
creating application sessions: defines a media/application set being
identified by a unique identifier within the conference. The
allowance to create application sessions depends on the
conference policy, e.g., in a conducted conference only the
conductor is allowed to create application sessions. The members
of the application session are stored in the appropriate
application session context entry.
terminating application sessions: an SCCP entity (as permitted in
the conference profile) deletes an application session. The
conference context is updated and the termination is signaled to
the appropriate local application(s).
joining application sessions: an SCCP entity starts the application
which then joins the SCCP application session. The conference
context is updated appropriately by adding the application as a
peer in the media/application set.
leaving application sessions: an SCCP entity terminates the local
application and leave the SCCP application session. The
conference context is updated appropriately.
inexact application sessions: For large conferences, it may make
sense to mark an application session as "inexact", i.e., no join
or leave messages are to be distributed. This may also be useful
in case that application protocols are able to maintain
membership information by themselves.
3.3 Floor Control
SCCP provides floor control facilities to support application state
synchronization. Additionally, conductorship of conferences is also
realized using the floor control functionality.
Hence, SCCP supports to map "social protocols", i.e., the rules to
access application objects like audiovisual streams, onto
distributed systems. However, the mapping of floors onto application
semantics is not within the scope of SCCP.
Bormann, et. al. Expires August 14, 2001 [Page 8]
Internet-Draft sccp-services February 2001
Each floor within SCCP is identified using a conference-unique name.
The naming pattern is not within the scope of SCCP.
Hence, SCCP provides the following floor control services:
grab floor: allocates a floor for exclusive use by the requesting
participant
inhibit floor: allocates a floor for non-exclusive use by several
participants
release floor: releases a previously allocated floor; the state of
the floor is changed accordingly
test floor: ask for the current state (F_FREE, F_GRABBED,
F_INHIBITTED) of the floor
ask floor: ask the current floor holder to grant an exclusive floor
to the requesting SCCP entity
give floor: grant an exclusive floor to another participant
holders of floor: ask for a list of current floor holders
It can be seen that the provided floor control service is very
similar to the T.122 services [8] of the H.323 standard. However,
requesting the current floor holder list is not supported by the
T.122 standard.
Bormann, et. al. Expires August 14, 2001 [Page 9]
Internet-Draft sccp-services February 2001
4. Requirements for Mappings onto underlying Transports
As previously mentioned in the introduction, this draft does not
specify the mappings onto different transport layer mechanisms.
However, some basic functionality is assumed by the underlying
transport to provide.
The requirements for transport mappings are:
Reliable message transport: Transport layer services are assumed
to provide reliable, consistent delivery of data units called
"messages". Reliability is bounded by the fact that member end
systems may find that they no longer can reliably interact
with the other members, e.g., due to a network partitioning.
When considering unicast transfer of messages, a "connection
failure indication" is mandatory to be delivered to the SCCP
layer.
Globally ordered message delivery: Messages are globally ordered.
Each message is assigned a message number by the appropriate
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.
Bormann, et. al. Expires August 14, 2001 [Page 10]
Internet-Draft sccp-services February 2001
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 features enabled and restricted by fixed
hardware and software resources of end systems are termed "system
capabilities". For example, the capability to process (or generate)
audio data of a given codec format is one of the system capabilities
of an audio conferencing system.
In multiparty multimedia conferences, participants employ different
"components" in conducting the conference.
Example: In lecture multicast conferences one component might be
the voice transmission for the lecturer, another the transmission
of video pictures showing the lecturer and the third the
transmission of presentation material.
Depending on system capabilities, user preferences and other
technical and political constraints, different configurations can be
chosen to accomplish the "deployment" of these components.
Each component can be characterized at least by (a) its intended use
(i.e., the function it shall provide) and (b) a one or more possible
ways to realize this function. Each way of realizing a particular
function is referred to as a "configuration".
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 image and transmitting a video stream via some video tool or
by loading a copy of the slides into a distributed electronic
whiteboard. For each of these cases, additional parameters may
exist, variations of which lead to additional configurations (see
below).
Two configurations are considered different regardless of whether
they employ entirely different mechanisms and protocols (as in the
previous example) or they choose the same and differ only in a
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 system model, we distinguish two types of configurations:
Bormann, et. al. Expires August 14, 2001 [Page 11]
Internet-Draft sccp-services February 2001
o potential configurations
(a set of any number of configurations per component) indicating
a system's functional capabilities as constrained by the intended
use of the various components;
o actual configurations
(exactly one per instance of a component) reflecting the mode of
operation of this component's particular instantiation.
Example: The potential configuration of the aforementioned video
component may indicate support for JPEG, H.261/CIF, and
H.261/QCIF. A particular instantiation for a video conference
may use the actual configuration of H.261/CIF for exchanging
video streams.
In summary, the key terms of 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 supported by an end system.
* An actual configuration is an "instantiation" of one of the
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 actual configurations describe
how a system is configured to operate at a certain point in time
(media stream spec).
To decide on a certain actual configuration, a negotiation process
needs to take place between the involved peers:
1. to determine which potential configuration(s) they have in
common, and
2. to select one of this shared set of common potential
configurations to be used for information exchange (e.g., based
upon preferences, external constraints, etc.).
Bormann, et. al. Expires August 14, 2001 [Page 12]
Internet-Draft sccp-services February 2001
In SAP [3]-based session announcements on the Mbone, for which SDP
was originally developed, the negotiation procedure is non-existent.
Instead, the 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 typically
carried out implicitly: each party informs the other about what it
can receive and the respective sender chooses from this set a
configuration that it can transmit.
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 determining the
subset of allowable potential configurations is deterministic to
reduce the number of required round trips before a session can be
established.
Bormann, et. al. Expires August 14, 2001 [Page 13]
Internet-Draft sccp-services February 2001
6. SDP considerations
This section defines how to describe conferences that make use of
SCCP with SDP. Note the transport mappings for SCCP will require
additional parameters to be configured and thus provide extensions
to the SDP conventions presented here.
Usage of SCCP MUST be described in separate media description, where
the media type of an SCCP media description is "control", i.e. the
first sub-field of the m= line of the SCCP description has the value
"control".
As specified in [4] the second sub-field is the transport port to
which the media stream will be sent. In this case it is RECOMMENDED
that for transport mappings where the concept of a transport port
number is applicable the value of this field is interpreted as a
port number. Even if this is not the case the second sub-field MUST
contain a decimal number in the range 1024 to 65535 inclusive. If
the transport mapping requires a range of port numbers to be
specified the first port number MUST be followed by a "/" and the
number of ports as a decimal number (as specified in [4]).
The third sub-field specifies the transport protocol. The first
portion of the value MUST be set to "SCCP" followed by "/" and an
identifier for the SCCP transport mechanism (to be defined in
corresponding transport mapping specifications).
In SDP, the fourth sub-field is used to specify media formats as RTP
payload types. For SCCP, the value "0" MUST be used.
Additional attributes that might be defined in "a=" lines are yet to
be defined (or specified by transport mapping specifications.)
Example of an SCCP description in SDP:
m=control 30000 SCCP/XY 0
Bormann, et. al. Expires August 14, 2001 [Page 14]
Internet-Draft sccp-services February 2001
7. Security Considerations
The authentication and encryption model for SCCP will be defined in
a future version of this document.
Bormann, et. al. Expires August 14, 2001 [Page 15]
Internet-Draft sccp-services February 2001
References
[1] Handley, M., Crowcroft, J., Bormann, C. and 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 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 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
Bormann, et. al. Expires August 14, 2001 [Page 16]
Internet-Draft sccp-services February 2001
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
Bormann, et. al. Expires August 14, 2001 [Page 17]
Internet-Draft sccp-services February 2001
Appendix A. Message Formats
Note that this XDR-like specification does not imply any particular
type of encoding of the 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 floor to be given back with most requests */
enum SCCP_Status {
F_FREE,
F_GRABBED,
F_INHIBITED,
F_GIVING
};
/* Flag of an application session (see also section 3.2) */
enum SCCP_AS_Flag {
AS_EXACT,
AS_INEXACT
};
/* Error for requests, currently only for floor control */
enum SCCP_Error {
SCCP_E_GRABBED, /* floor grabbed */
SCCP_E_INHIBITED, /* floor inhibited */
SCCP_E_FREE /* floor free */
};
/* SCCP_AS is the application session in the conference context
* Name: identifies the application session
* flag: exact or inexact session description
* value: reflects upper layer semantic
* namelist: list of media/application sets
*/
struct SCCP_AS {
SCCP_Name name;
SCCP_AS_Flag flag;
SCCP_Value value; /* upper layer semantics */
SCCP_NameList namelist;
};
/* SCCP_Member is the member entry in the conference context
* presence: presence information of the member
*/
struct SCCP_Member {
SCCP_Name presence;
Bormann, et. al. Expires August 14, 2001 [Page 18]
Internet-Draft sccp-services February 2001
};
/* SCCP_Floor is the core entry in the floor context
* Name: identifies the floor
* status: status of floor
* Holders: list of floor holders for 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
* - members
* - sessions
*/
struct SCCP_Conference_Context {
SCCP_Member members<>;
SCCP_AS sessions<>;
};
/* SCCP_Floor_Context contains list of floors to be maintained
depending on the 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 other user */
Bormann, et. al. Expires August 14, 2001 [Page 19]
Internet-Draft sccp-services February 2001
SCCP_T_FLOOR_GIVEN, /* indication to originator */
SCCP_T_FLOOR_HOLDER, /* ask for 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;
};
Bormann, et. al. Expires August 14, 2001 [Page 20]
Internet-Draft sccp-services February 2001
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 {
Bormann, et. al. Expires August 14, 2001 [Page 21]
Internet-Draft sccp-services February 2001
SCCP_Name presence;
SCCP_Name floor;
SCCP_NameList floor_holders;
};
struct SCCP_Floor_Status {
SCCP_Object floor;
};
struct SCCP_Floor_Error {
SCCP_Name presence;
SCCP_Name floor;
SCCP_Error error;
};
union SCCP_Union switch (SCCP_Type type) {
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 */
case SCCP_T_ASLEAVE:
SCCP_AS_Leave AS_LEAVE; /* member, session */
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;
Bormann, et. al. Expires August 14, 2001 [Page 22]
Internet-Draft sccp-services February 2001
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<>;
};
Bormann, et. al. Expires August 14, 2001 [Page 23]
Internet-Draft sccp-services February 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the 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 RFC editor function is currently provided by the
Internet Society.
Bormann, et. al. Expires August 14, 2001 [Page 24]
