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]