INTERNET-DRAFT Carsten Bormann Expires: December 1996 Universitaet Bremen Joerg Ott, Christoph Reichert TU Berlin June 1996 Simple Conference Control Protocol draft-ietf-mmusic-sccp-00.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document defines a simple conference control protocol for tightly coupled conferences, based on the Internet Multimedia Conferencing Architecture [1]. The functions provided are based on the services offered by the ITU-T recommendations of the T.120 (and H.320) series [2], they are, however, not a simple ``port'' of these recommendations to the Internet. Instead, the aim is to define a simple conference control protocol that is rich enough to allow the construction of gateways to the T.120 world. Also, the protocol is intended to be scalable and robust to failures. In contrast to the ITU-T recommendations, it allows the use of IP multicast both for multimedia information and for other applications and control streams. This document is a product of the IETF MMUSIC working group. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. 1. Introduction The Internet Multimedia Conferencing Architecture [1] currently Bormann, Ott, Reichert [Page 1] INTERNET-DRAFT Simple Conference Control Protocol June 1996 comprises conference control elements only for loosely coupled conferences, i.e. ``crowds that gather around an attraction''. Many conferences have more formal policies with respect to the set of participants that are allowed to listen or with respect to who may talk at a particular time, or they grant specific permissions to a conference chair (called conductor in this document). Also, it may be desirable to change parameters of the conference (e.g., set of media/applications active, parameters for these applications) in a coordinated way for all participants simultaneously. Conferences that have facilities for this purpose shall be termed tightly coupled conferences in this document. This document defines a simple conference control protocol (SCCP) for tightly coupled conferences. The design of this protocol was, in part, guided by the services offered by the ITU-T recommendations of the T.120 (and H.320) series [2], in particular: o management of the set of members participating in the conference; o management of the set of applications/media that constitute the conference; o floor control; o assignment of a special ``conductor'' role to one participant. The protocol is, however, not intended as a simple ``port'' of these recommendations to the Internet. Instead, the aim is to define a simple conference control protocol that is rich enough to allow the construction of gateways between conferences based on this protocol to conferences that are based on the T.120 series of recommendations. Also, the protocol is intended to be more scalable and more robust to failures than an MCS-based protocol can be. In contrast to the ITU-T recommendations, the protocol allows the use of IP multicast both for multimedia information and for other applications and control streams. Conferences that are controlled by SCCP may be convened using an invitation protocol such as SIP [3]. 2. Definition of terms [Note that some of these terms are general enough that, if we like them, they should be defined in [1].] o Conference The relationship between a set of human beings that are communicating together. In this document, the term is used for tightly coupled (see 1) computer based conferences. Bormann, Ott, Reichert [Page 2] INTERNET-DRAFT Simple Conference Control Protocol June 1996 o Participant A human being that takes part in a conference. o Member The system, including software and hardware, that takes part in a computer conference, representing a single participant. o End system A host or a set of locally interconnected hosts[1] that is used as an interface to a teleconference by a single participant. The end system runs all the required conferencing software (e.g. media agents, session directory, and the SCCP entity), together with this software it constitutes a member. o SCCP entity An instantiation of an SCCP implementation running on an end system for a single member. An SCCP entity (or entity for short) represents a specific participant in the conference using the SCCP protocol. o Conference controller An application that interacts closely with an SCCP entity on one hand to implement the conference policy and with the participant to realize her wishes. o UCI A universal communication identifier of a person. Used as the E-mail address of an individual as well as the address that can be used to invite that individual via the SIP protocol. o Presence A representation of the fact that an identified person is using a particular end system for the purpose of (potentially or actually) representing this person in one or more conferences. A presence corresponds to that person ``being logged in'' at an end system and (potentially or actually) being available for conferencing. There is a one-to-many relationship between presences and members: one presence may be member of many conferences. There is a one-to-one relationship between members and the cross-product of presences and the set of conferences this presence appears in (which cross-product contains the set of ``appearances'' of each presence). _________________________ [1] In this document, we use the term ``end system'' as a syn- onym for ``host'' in the simplest case. We do not want to ex- clude, however, that the local system that serves one participant may be composed of several ``hosts'' in the Internet sense. Bormann, Ott, Reichert [Page 3] INTERNET-DRAFT Simple Conference Control Protocol June 1996 o Conference context All state information kept about a conference at each member of this conference. o Ownership (of state information) To allow for a distributed maintenance of the conference context, each piece of state information is ``owned'' by exactly one end system. Each end system is responsible for keeping its owned state and distributing (and updating) this information to those that need it. Ownership is -- as far as possible -- defined such that the need for a copy of the state information is bound to the appearance of its owner in the conference. o Statekeeper At each point in time, one SCCP entity is assigned the function of statekeeper. This entity is relevant for state synchronization between the involved end systems[2]. As the conference context is maintained in a distributed fashion, such an entity is needed to resolve conflicting concurrent operations on the conference state. Also, the statekeeper is owner of the state that is global to the conference. o Receptionist At each point in time, one SCCP entity is assigned the function of receptionist. This entity is responsible for providing new participants with a copy of the current conference context[3]. o Profile An initial description of the conference, including assignment of roles to particular members, time limits for speakers, attributes of the conference (open/close, conducted/anarchic, etc)[4]. o Application session (AS), Session The set of media agents/applications that act as peers to each other within a conference. For real-time data, this generally will be an RTP session [4]; for other application protocols, other horizontal protocols may define their own type of session concept. Possible synonyms are ``application group'' or ``media agent group''. _________________________ [2] For this version of this document, the statekeeper concept is not yet actually necessary. See section 3. [3] Statekeeper and receptionist may (but need not) be co- located. [4] Not all of this is defined in this version of the present document, some of it is intended to be relegated to a companion document called ``Simple Conference Control Semantics'' (SCCS). Bormann, Ott, Reichert [Page 4] INTERNET-DRAFT Simple Conference Control Protocol June 1996 3. Services expected from the underlying transport For simplicity, this version of SCCP expects to be able to use an underlying multicast transport service. This service is assumed to provide reliable, consistent delivery of data units called messages. Reliability is bounded by the fact that member end systems may find that they no longer can reliably interact with the other members, e.g. due to a network partitioning. Messages are globally ordered: Each message is assigned a message number by the transport service, and messages are delivered to SCCP entities in monotonic message number order. In the rest of this document, the term ``distribute'' will be used to indicate that a member end system sends a message using the transport service. Appendix B contains information on two transport mappings, including one with full multicast functionality and one for a very simple multipoint protocol based on TCP (MTCP). As MTCP is very easy to implement, it might be appropriate for small conferences that use simple implementations (e.g., internet telephony). A version of SCCP that can be based on an unreliable datagram multicast service and uses the statekeeper mechanism instead can be derived from the present version, if this is desired. 4. Basic concepts of SCCP 4.1. Context and Objects SCCP is based on the idea of maintaining a common state for the entire conference, the conference context, at all participants. This state is partitioned into objects. SCCP distinguishes four types of objects: - variables, which are general repositories for global state that does not fit elsewhere, such as a conference policy; - sessions, which are a special kind of variable that represents global state about an application session; - tokens, which are a special kind of variable that allows synchronization operations; and - members, which represent the information specific to a single member. All objects are named by a string (name), support 32 boolean flags[5], can be assigned opaque data (value), and can carry a list of strings that may reference other objects (namelist). _________________________ [5] at most one of which is used in this specification. Bormann, Ott, Reichert [Page 5] INTERNET-DRAFT Simple Conference Control Protocol June 1996 There are no special semantics associated with any of these elements of an object if that object is a variable. By convention, variables are named with lower-case names, e.g. ``policy''. Session objects by convention are named with names that have an initial capital, e.g. ``Audio''. Flag 0 is defined to indicate a session with inexact membership, i.e. a session for which membership information is not maintained with SCCP. The name list specifies the set of members that are to join this session (the special name list entry ``*'' specifies ``all members''). Token objects by convention have upper case names, e.g., ``FLOOR''. Tokens can have zero or more holders (members). Flag 0 is defined to indicate a sharable state of the token, i.e. if flag 0 is not set, only one member can hold the token at any time. Member objects have names that indicate the presence that this member represents, i.e. the names are composed of a UCI and a host name with an intervening space, e.g. ``jo@cs.tu-berlin.de presto.cs.tu- berlin.de''. Flag 0 is defined to indicate that this member is willing and able to become receptionist. The namelist indicates the names of the application sessions the member is currently present in. 4.2. Semantics SCCP itself does not define the semantics of the variables and opaque data values associated with objects. A simple example for semantics (``Simple Conference Control Semantics'', SCCS) is attached as Annex C. By convention, every conference context contains a variable ``semantics'' which has as value a string defining the type and version of the semantics being used (e.g., ``SCCS-1.0''). [Issue: define mechanisms for upward compatibility of semantics versions in SCCP or in the semantics documents?] 4.3. Application support SCCP can be used to provide support for horizontal application protocols, by defining specific objects such as variables and tokens for this purpose. This may allow application protocols to use a more lightweight transport protocol for their application data. 4.4. Messages The context is updated by an ordered sequence of SCCP messages. Each message is an ordered sequence of one or more SCCP actions, all of which are applied to the conference context in one atomic step. It is the task of the conference controller to check the SCCP actions against the policy of the conference and perform only actions from messages that respect this policy. In the following text, a clear Bormann, Ott, Reichert [Page 6] INTERNET-DRAFT Simple Conference Control Protocol June 1996 separation will generally not be made between messages and the actions, except where necessary for clarity. 5. Management of the set of members participating in the conference SCCP is responsible for maintaining a (to a certain degree) consistent membership list of all current conference participants. Changes to the membership list are initiated by the following two operations: o JOIN The SCCP entity of an end system that wants to join a conference distributes a JOIN message to the SCCP transport of the respective conference. Upon receipt of this message the members of the conference know about the potential new participant and make a decision (based on the conference policy) whether or not to accept the newcomer. The receptionist is responsible for finally answering the JOIN request. This answer is also distributed to the entire conference to allow updating the membership list. o LEAVE When an end system decides to leave a conference, its SCCP entity distributes a LEAVE message to the conference so that all participants are informed about the state change. [We need a system to ascertain membership regularly in those cases where this is desired, e.g. DOUBT/CONFIRM and LEAVE on timeout. This would generally be done by the statekeeper, although members that have applications with their own membership control mechanisms may also want to generate DOUBT messages.] 5.1. Invitation An SCCP entity contacts the participant to be invited (more correctly: one or more presences of this participant) by sending an invitation message (e.g. as payload information within SIP [3]). The invitation contains contact point information: a conference name, transport contact information, and possibly authentication information. The end system representing the participant to be invited can use this information to join the conference or it can use mechanisms defined outside of SCCP (e.g., an SIP BUSY message) to deny joining. 5.2. Joining a conference To join a conference, an SCCP entity needs as contact information: The name (transport address) of the conference and possibly some authentication information. Bormann, Ott, Reichert [Page 7] INTERNET-DRAFT Simple Conference Control Protocol June 1996 A joining entity distributes a JOIN message. (Conferences may start out empty. In this case, JOIN messages by the first member will not receive an answer, see below.) If the conference already has participants, all SCCP entities mark the new member as JOINING. The receptionist now either distributes an ACCEPT or a LEAVE message. An ACCEPT message contains a copy of the current conference context and the conference profile; upon the receipt of an ACCEPT message all SCCP entities mark the new member as ACCEPTED in their conference state. The new participant creates the applications that are defined in the current conference context. If the joining member does not receive an ACCEPT or LEAVE message within some time (TBD), it is the first participant. If the conference profile for the new conference is available to the joining member and it allows the joining member to initiate the conference, the conference context is initialized with the profile and the SCCP entity assumes the functions of receptionist and statekeeper. If the joining member does not want to become statekeeper, the SCCP entity remains passive until it sees activity in SCCP (other than JOIN messages)[6]; it then repeats the joining procedure. If a participant just created the conference profile from scratch and thus knows it is the first member (e.g., for a simple phone call), it can simply create the conference context, invite other members, and wait for JOIN messages. 5.3. Obtaining the conference context Together with one or more ACCEPT actions, a receptionist distributes a CONTEXT action in the same SCCP message. This copy of the conference context is used to initialize the conference context in the newly accepted member. As other messages may be distributed in the time the receptionist submits a message containing a CONTEXT action and the time this message is distributed, the new member must be aware of the position in the sequence of messages for which the CONTEXT action is current. We call this position the context synchronization event. For transport mappings that provide serial numbers, this information simply is the first transport serial number that was not considered at the time the CONTEXT action was built. For transport mappings that do not provide serial numbers, some other method is necessary to refer to the context synchronization event, which in general will be a JOIN action (or possibly a special SYNC action). Therefore, both of these actions carry a synchronization time stamp that, together with the source of the action, can be referred to in the CONTEXT action. _________________________ [6] This option is available only for transport mappings that allow passive joins. Otherwise, a SIP based invitation mechanism can be used. Bormann, Ott, Reichert [Page 8] INTERNET-DRAFT Simple Conference Control Protocol June 1996 A new member that wants to obtain the conference context simply records all messages it receives from the transport until a conference context is received. After applying all messages that are more recent than the context synchronization event to the context received, the local copy of the context is current. 5.4. Leaving a conference If the conference profile allows this, any SCCP entity can distribute a LEAVE message with the identification of a participant that now no longer is a member of the conference. Any conference participant can distribute a LEAVE message for itself. An SCCP entity receiving a LEAVE message removes the participant listed from the (conference membership list and application session membership lists of the) conference context. If the receptionist wants to leave the conference, it transfers its receptionist function beforehand (see 6). A forced leave message might include a new session key to enforce that the ejected member can no longer take part in the conference. 5.5. Terminating a conference An SCCP entity that is granted -- from the conference profile -- the permission to terminate the conference does so by distributing a special LEAVE message with the name ``*'' to all other participants, which indicates ``conference terminated'' as the reason for the exclusion from the conference. Each SCCP entity receiving this message reacts similar to as if it was excluded from the conference. 6. Transferring the receptionist and statekeeper functions There are two possibilities that require the SCCP entity performing the function of the receptionist/statekeeper to change: a) when the current holder of this function leaves the conference (voluntarily or not) in an orderly fashion; b) when the holder crashes or is partitioned away from the other conferees. 6.1. Mechanisms for transferring the receptionist function [Fix me.] In the first case (orderly release), the receptionist simply sends out a LEAVE message to the group. Each member of the conference notices that the leaving entity currently acts as the receptionist and that consequently a new receptionist has to be found. As all members of the conference keep a consistent state information base (including the sequence in which the members Bormann, Ott, Reichert [Page 9] INTERNET-DRAFT Simple Conference Control Protocol June 1996 joined[7]), the conference, this is done by simply selecting the oldest remaining conference member that is receptionist-capable to become the new receptionist. The new receptionist announces its new role by sending a RECEPTIONIST-IS message to the group. In case the designated receptionist has failed recently (and this has not been detected so far), the REPECTIONIST-IS message will not show up. Therefore, all receptionist-capable members of the group react after a timeout (TBD) as described below for case b). In case of temporarily inconsistent membership information multiple RECEPTIONIST-IS messages may be sent. This situation is treated as if multiple receptionist changes occur, and consequently the entity whose message is delivered last becomes the new receptionist. In the second case (failure), a recovery mechanism is invoked. If a JOIN message is not answered by the receptionist within a certain time (TBD, dithered), each SCCP entity distributes a RECOVERY message unless it has already seen a RECOVERY message. The RECOVERY message includes a random number, the beacon. The SCCP entity with the lowest beacon assumes the receptionist function and distributes a RECEPTIONIST-IS message. If two beacons are equal, the ``older'' member wins. 6.2. Mechanisms for transferring the statekeeper function [The statekeeper is not defined in this version of this document.] 7. Setting variables Actions are defined for setting the various fields of objects such as variables, tokens, and sessions. o SETVALUE: sets the value field. o SETFLAG: sets the flag field under a bitmask. o ADDNAME: adds a name to the namelist. o DELNAME: removes a name from the namelist. o DELETE: deletes an object. SETVALUE and SETFLAG can also be applied to member objects. _________________________ [7] This information is propagated to new members through the ordering of the member objects in the CONTEXT message. Bormann, Ott, Reichert [Page 10] INTERNET-DRAFT Simple Conference Control Protocol June 1996 8. Management of the set of applications/media that constitute the conference Each application session is described by a session object in the conference context. The name of the session object identifies the session within the conference. Application specific parameters are indicated in the value of the session object. (for SDP style parameters e.g. media address, port number and format [5]). As part of its own member state, each SCCP entity maintains a list of application sessions it is a member of; in the conference context, this current actual membership is indicated in the namelists of the member objects unless the session is marked as inexact by flag 0 (see below). 8.1. Creating application sessions An SCCP entity (that is permitted to do so via the conference profile -- in conducted conferences typically the conductor) distributes an AS-CREATE message with the session parameters. An application session is identified by a unique identifier. The namelist of the session object specifies the set of members that are to join the session, if the special name ``*'', it specifies that all members are to join the session. 8.2. Terminating application sessions An SCCP entity (as permitted by the conference profile) distributes an AS-DELETE message with the name of the session. All other entities remove the session from the conference context and indicate termination of the session to the corresponding local application. 8.3. Joining application sessions An SCCP entity starts the application and distributes an AS-JOIN message with the identifier of the session. The SCCP entities note in their conference context that this member now is a peer to the application session. 8.4. Leaving application sessions An SCCP entity distributes an AS-LEAVE message with the identifier of the session and terminates the application. The other SCCP entities take note in the member object. A LEAVE message implies leaving all application sessions. 8.5. Inexact application sessions For large conferences, it may make sense to mark an application session as inexact, i.e. no AS-JOIN and AS-LEAVE messages are to be distributed. This may also be useful in case application protocols are able to maintain membership lists by themselves. Bormann, Ott, Reichert [Page 11] INTERNET-DRAFT Simple Conference Control Protocol June 1996 9. Token control To support synchronization such as floor control (possibly with multiple floors) and conductorship assignment, SCCP defines a generic type of object, the token. An SCCP entity distributes a TOKEN-WANT message to request a token, TOKEN-GIVE to transfer it and TOKEN-RELEASE to relinquish it. A token can be assigned exclusively to a single SCCP entity or can be shared by any number of SCCP entities. In addition, members that are appropriately privileged by the conference profile may simply re- assign a token as they wish. A token can basically be in one of three states: FREE (no holder), EXCLUSIVE (one holder, flag 0 unset), or SHARED (one or more holders, flag 0 set). In each of these states a TOKEN-WANT message indicates the desire to obtain the token. A flag in the TOKEN-WANT message indicates whether exclusive or shared control of the token is desired. o If the token is in the FREE state, the TOKEN-WANT automatically assigns the token to the requester (provided the conference policy permits giving the token to the requester). o If the token is in the EXCLUSIVE state, the token holder has to decide whether to pass the token on to the requester (TOKEN_GIVE) for exclusive or shared control (the token holder should follow the flag in the request) or not. o If the token is in the SHARED state the behavior depends on the request. A request for the shared token is implicitly granted (if the policy, i.e. a limit on the number of concurrent token holders, permits this). A request for an exclusive token is only granted if all current shared token holders decide to pass on the token to the requester by means of a TOKEN-GIVE message or decide to relinquish the token with a TOKEN-RELEASE message. (Note, however, that at least one TOKEN-GIVE must be sent within the request timeout (TBD) for the request to succeed). TOKEN-GIVE, TOKEN-WANT, and TOKEN-RELEASE messages can be sent by an appropriately privileged SCCP entity indicating the desired token control state: assigned to one or more explicitly listed participants, assigned to the privileged entity itself, or free, respectively. Such a request overrides the current token state. Determination of whether or not an entity is privileged is up to the conference semantics layer on top of SCCP (as is consequently the decision whether or not modify the conference state accordingly). 10. Security Considerations The authentication and encryption model for SCCP will be defined in a Bormann, Ott, Reichert [Page 12] INTERNET-DRAFT Simple Conference Control Protocol June 1996 future version of this document. Any interoperation between ITU-based systems and Internet-based systems must take care to preserve the point-to-point link based security model underlying the ITU standards. In T.120, much of the access control relies on being able to reject the attempt to join a conference via an ISDN connection to an MCU. 11. Authors' Addresses Carsten Bormann Universitaet Bremen FB3 MZH 5180 Postfach 330440 D-28334 Bremen GERMANY cabo@informatik.uni-bremen.de phone +49.421.218-7024 Joerg Ott Christoph Reichert Technische Universitaet Berlin FR 6-3 Franklinstr. 28/29 D-10587 Berlin GERMANY jo@cs.tu-berlin.de phone +49.30.314-73389 12. Acknowledgements Scott Shenker, Abel Weinrib, and Eve Schooler have submitted drafts of a more general conference control protocol, the Agreement Protocol, in the MMUSIC working group of the IETF. Many concepts of the Simple Conference Control Protocol are based on discussions of the agreement protocol and our experience with attempts to implement it. 13. References [1] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet Multimedia Conferencing Architecture,'' Internet Draft draft- ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. [2] ITU T.120 series, in particular T.122/125 (MCS) and T.124 (GCC). [3] Mark Handley, Eve Schooler, ``Session Invitation Protocol,'' Internet Draft draft-ietf-mmusic-sip-00.txt, Work in Progress, February 1996. Bormann, Ott, Reichert [Page 13] INTERNET-DRAFT Simple Conference Control Protocol June 1996 [4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A Transport Protocol for Real-Time Applications,'' Internet RFC 1889, January 1996. [5] M. Handley, V. Jacobson, ``SDP: Session Description Protocol,'' Internet Draft draft-ietf-mmusic-sdp-01.txt, .ps, Work in Progress, November 1995. Bormann, Ott, Reichert [Page 14] INTERNET-DRAFT Simple Conference Control Protocol June 1996 A. Message formats [Issue: Note that this XDR-like specification does not necessarily imply any particular type of encoding of the SCCP PDUs. The encoding may be defined independently, or RFC 1832 encoding may be used.] /* * $Id: sccp.xdr,v 1.7 1996/06/12 19:55:13 cabo Exp $ * * Common types for SCCP and the API. */ typedef string SCCP_Name<>; typedef int SCCP_Flags; typedef opaque SCCP_Value<>; typedef SCCP_Name SCCP_Namelist<>; /* * Presence: UCI space Hostname * UCI: user@hostname (where hostname is SIP relevant) */ struct SCCP_Object { SCCP_Name name; SCCP_Flags flags; SCCP_Value value; /* upper layer semantics */ SCCP_Name namelist<>; }; /* * vars: completely user defined * * Session: 0 = inexact * * mEmBer: 0 = precept; namelist is AS list * (space in name) * * TOKEN: 0 = shared; namelist is holder list */ struct SCCP_Context { SCCP_Object vars<>; SCCP_Object tokens<>; SCCP_Object sessions<>; SCCP_Object members<>; }; enum SCCP_Sync_Type { SCCP_S_TRANSPORT, SCCP_S_COOKIE }; Bormann, Ott, Reichert [Page 15] INTERNET-DRAFT Simple Conference Control Protocol June 1996 typedef int SCCP_Sync; /* local timestamp etc. */ struct SCCP_Cookie { SCCP_Sync sync; SCCP_Name sender; }; union SCCP_Sync_Un switch(SCCP_Sync_Type type) { case SCCP_S_TRANSPORT: int transport_serial; case SCCP_S_COOKIE: SCCP_Cookie cookie; }; struct SCCP_Context_Msg { SCCP_Context context; SCCP_Sync_Un sync; }; /* * for SRM adaptation protocol: include * string name<>; // conference name * in each message. * This is not needed for MTP-2 or MTCP, as the context is clear. */ struct SCCP_Header { char proto[4]; /* "sccp" */ char sccp[4]; /* "01.1" */ SCCP_Name sender; /* Presence name of sender of this message */ }; enum SCCP_Type { SCCP_T_JOIN, /* join conference */ SCCP_T_LEAVE, /* leave conference */ SCCP_T_ACCEPT, /* accept joining member */ SCCP_T_CONTEXT, /* context */ SCCP_T_SYNC, /* context sync */ SCCP_T_ASCREATE, /* create application session */ SCCP_T_ASDELETE, /* delete application session */ SCCP_T_ASJOIN, /* join application session */ SCCP_T_ASLEAVE, /* leave application session */ SCCP_T_TOKCREATE, /* create a token */ SCCP_T_TOKDELETE, /* delete a token */ SCCP_T_TOKWANT, /* want or grab a token */ SCCP_T_TOKGIVE, /* give token */ SCCP_T_TOKRELEASE, /* release token */ SCCP_T_SETVALUE, /* set value of var, token, session, member */ SCCP_T_SETFLAG, /* set flag of var, session, member, (token) */ SCCP_T_DELETE, /* delete var */ Bormann, Ott, Reichert [Page 16] INTERNET-DRAFT Simple Conference Control Protocol June 1996 SCCP_T_ADDNAME, /* add name to var */ SCCP_T_DELNAME, /* delete name from var */ SCCP_T_RCPTIS, /* announce receptionist */ SCCP_T_RECOVER, /* recovery message */ SCCP_T_INVALID /* last and invalid sccp pdu type */ }; struct SCCP_Join { SCCP_Name presence; /* joining member */ SCCP_Flags flags; /* precept etc. */ SCCP_Value value; /* user data */ SCCP_Sync sync; /* cookie (timestamp etc.) */ }; struct SCCP_AS { SCCP_Name name; SCCP_Value value; SCCP_Namelist names; }; struct SCCP_AddDelname { SCCP_Name objname; SCCP_Name entry; }; struct SCCP_Recover { unsigned int beacon; }; struct SCCP_TOKwant { SCCP_Name name; /* name of token */ SCCP_Name presence;/* member the token is to be assigned to*/ SCCP_Flags shared; /* want token shared or exclusive */ bool notify; /* inform holder the token is wanted */ }; struct SCCP_TOKgive { SCCP_Name name; /* name of token */ SCCP_Name giver; /* member from whom the token is taken away */ SCCP_Name receiver; /* member to whom the token is given */ }; struct SCCP_setvalue { SCCP_Name var; /* name of var to set */ SCCP_Value val; /* new value */ }; struct SCCP_setflags { SCCP_Name var; /* name of var to set */ SCCP_Flags mask; /* select the flags to be modified */ Bormann, Ott, Reichert [Page 17] INTERNET-DRAFT Simple Conference Control Protocol June 1996 SCCP_Flags flags; /* new flags */ }; union SCCP_Union switch (SCCP_Type type) { case SCCP_T_JOIN: SCCP_Join join; case SCCP_T_LEAVE: SCCP_Name leave; case SCCP_T_ACCEPT: SCCP_Name accept; case SCCP_T_CONTEXT: SCCP_Context_Msg context_msg; case SCCP_T_SYNC: SCCP_Sync sync; case SCCP_T_ASCREATE: SCCP_AS ascreate; case SCCP_T_ASDELETE: SCCP_Name asdelete; case SCCP_T_ASJOIN: SCCP_AddDelname asjoin; /* member, session */ case SCCP_T_ASLEAVE: SCCP_AddDelname asleave; /* member, session */ case SCCP_T_TOKCREATE: SCCP_Name tokcreate; case SCCP_T_TOKDELETE: SCCP_Name tokdelete; case SCCP_T_TOKWANT: SCCP_TOKwant tokwant; case SCCP_T_TOKGIVE: SCCP_TOKgive tokgive; case SCCP_T_TOKRELEASE: SCCP_AddDelname tokrelease; /* token, member no longer holder */ case SCCP_T_SETVALUE: SCCP_setvalue setvalue; case SCCP_T_SETFLAG: SCCP_setflags setflags; case SCCP_T_DELETE: SCCP_Name objname; case SCCP_T_ADDNAME: SCCP_AddDelname addname; case SCCP_T_DELNAME: SCCP_AddDelname delname; case SCCP_T_RCPTIS: SCCP_Name rcptis; case SCCP_T_RECOVER: SCCP_Recover recover; }; Bormann, Ott, Reichert [Page 18] INTERNET-DRAFT Simple Conference Control Protocol June 1996 struct SCCP_Message { SCCP_Header hdr; SCCP_Union sccp_un<>; }; Bormann, Ott, Reichert [Page 19] INTERNET-DRAFT Simple Conference Control Protocol June 1996 B. Transport mappings At this time, transport mappings are defined for SCCP for two protocols: 1) A simple multipoint protocol based on TCP defined in this annex (MTCP). 2) The multicast transport protocol MTP-2. B.1. MTCP Each SCCP message is mapped to an MTCP message. The initiator of a conference operates as the MTCP core. All other participants build connections to the MTCP core. B.1.1. MTCP protocol definition MTCP uses TCP connections between a central core and additional participants (one or more). Data units are exchanged on these connections, delimited by using a variant of the RMS protocol (RFC 1831 section 10): Instead of a header with one bit of flag and 31 bits of length, MTCP uses two bits of flag and 30 bits of length. The most significant bit, if set, indicates a control message; the rest of the header is then interpreted specially. If the control message bit is unset, the next to most significant bit indicates the final fragment of a message as in RFC1831: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|F| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the control message bit is set, the next to most significant bit indicates one of two control messages: If unset, the header indicates a release event. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Must be zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If set, the header indicates an initial sequence number data unit: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Initial Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Messages are assigned numbers implicitly by the order in which the MTCP core distributes them, starting from the initial sequence number. The core relays every message in order to every participant. Bormann, Ott, Reichert [Page 20] INTERNET-DRAFT Simple Conference Control Protocol June 1996 New participants receive an initial sequence number from the core, this is the sequence number of the next message received. A message received by the core from a non-core participant is relayed by the core to every other participant, except to the participant that sent it: As the sending participant knows what message it sent, it simply receives a release event in the position in the message sequence that its message has been determined to occupy by the core. A MTCP implementation has to provide two modes. In core mode, it passively listens on a TCP socket. Once a new connection is opened, it immediately sends an initial sequence number on that connection. It sends all of the messages locally originated in the same order on all connections. It also sends a copy of all messages received from the non-cores, except on the connection where the message was received, where a release event is sent instead. It delivers messages to the SCCP entity in the same order it sends them to the non-core members. In non-core mode, it creates a TCP connection to a specified core. It sends all messages it wants send to the core, keeping a copy in a queue. It delivers all messages received from the core to the SCCP entity. If it receives a release event, it delivers a copy of the oldest message in its queue to the SCCP entity. B.2. MTP-2 [Fix me, although:] The mapping to MTP-2 is trivial. C. SCCS: Simple Conference Control Semantics This annex defines a simple set of semantics for conference control. C.1. Variables VariableName Field Semantic Contents ------------------------------------------------------ "semantics" .flags - none - .value "SCCS-1.0" .namelist - none - ------------------------------------------------------ "permitted" .flags - none - .value - none - .namelist - prospective members - ------------------------------------------------------ "policy" .flags 0x0001 - conference locked 0x0002 - closed conference Bormann, Ott, Reichert [Page 21] INTERNET-DRAFT Simple Conference Control Protocol June 1996 .value TBD. .namelist TBD. C.2. Member objects The member objects fields have the semantics defined in SCCP (flags: 0x1 - capable/willing of being receptionist, namelist: application sessions user is active in). The value is defined by the following BNF (following the notational conventions of RFC822, section 2, with the exception that whitespaces are allowed to separate the tokens below): The following tokens are recognized: ; delimiter OP = "(" CP = ")" DOT = "." ; keywords AFFILIATION = "affiliation" AUDIO = "audio" CAPS = "caps" CONTROL = "control" DATA = "data" EMAIL = "e-mail" EXCLUSIVE = "exclusive" FAX = "fax" IP4-TYPE = "IN4" LOCATION = "location" MAX-SHARED = "max-shared" USER-INFO = "user-info" MESSAGE = "message" MTCP = "MTCP" MTP-2 = "MTP-2" MULTICAST = "multicast" NAME = "name" PARAMETERS = "parameters" PHONE = "phone" PRIVATE = "private" PUBLIC = "public" RTP = "RTP" SHARED = "shared" TCP = "TCP" UDP = "UDP" UNICAST = "unicast" UNICAST-CENTRALIZED = "unicast-centralized" UNICAST-MESH = "unicast-mesh" VIDEO = "video" ; complex tokens CARDINAL = POS-DIGIT *DIGIT Bormann, Ott, Reichert [Page 22] INTERNET-DRAFT Simple Conference Control Protocol June 1996 DECIMAL-UCHAR = DIGIT | POS-DIGIT DIGIT | (1 2*DIGIT) | (2 (0|1|2|3|4) DIGIT) | (2 5 (0|1|2|3|4|5)) DECIMAL-USHORT = DIGIT | POS-DIGIT 1*3DIGIT | (("1"|"2"|"3"|"4"|"5") 4DIGIT) | ("6" ("0"|"1"|"2"|"3"|"4") 3DIGIT) | ("65" ("0"|"1"|"2"|"3"|"4") 2DIGIT) | ("655" ("0"|"1"|"2") DIGIT) | ("6553" ("0"|"1"|"2"|"3"|"4"|"5")) IP4-ADDRESS = <"> DECIMAL-UCHAR DOT DECIMAL-UCHAR DOT DECIMAL-UCHAR DOT DECIMAL-UCHAR <"> ; it is not up to the parser to distinguish between unicast ; and multicast addresses STRING = <"> * <"> MemberSemantics = OP UserInfo AS-CapabilityList [AS-Parameters] /* ... */ CP UserInfo = OP USER-INFO Name [Phone] [Fax] [E-Mail] [Affiliation] [Location] [Message] /* ... */ CP Name = OP NAME DOT STRING CP Phone = OP VOICE DOT STRING CP Fax = OP FAX DOT STRING CP E-Mail = OP E-MAIL DOT STRING CP Affiliation = OP AFFILIATION DOT STRING CP Location = OP LOCATION DOT STRING CP Message = OP MESSAGE DOT STRING CP AS-CapabilityList = OP CAPS *AS-Capability CP AS-Capability = OP AS-Medium AS-Protocol AS-Format AS-Distribution CP AS-Distribution = UNICAST / MULTICAST / UNICAST MULTICAST AS-Parameters = OP PARAMETERS AS-ParameterList CP AS-ParameterList = OP *AS-Parameter CP AS-Parameter = OP AS-Name UniTransportAddress /* ... */ CP C.3. Session objects The session objects fields have the semantics defined in SCCP (flags: 0x1 - inexact membership, namelist: prospective member list for this session). The value is defined by the following BNF: AS-Semantics = OP [PermissionRequired] Bormann, Ott, Reichert [Page 23] INTERNET-DRAFT Simple Conference Control Protocol June 1996 AS-Transport AS-Format CP PermissionRequired = (OP PRIVATE PermittedMembers CP) / (OP PUBLIC CP) AS-Transport = (UNICAST-CENTRALIZED AS-Medium AS-Protocol UniTransportAddress) / (UNICAST-MESH AS-Medium AS-Protocol) / (MULTICAST AS-Medium AS-Protocol MultiTransportAddress) AS-Medium = AUDIO / VIDEO / DATA AS-Protocol = 1*AS-ProtocolName AS-ProtocolName = UDP / TCP / MTP-2 / MTCP / RTP ; to be extended UniTransportAddress = OP Address Port CP MultiTransportAddress = OP Address Port TTL CP Address = IP4-TYPE IP4-ADDRESS ; to be extended Port = DECIMAL-USHORT AS-Format = OP FormatName [FormatParameter] CP FormatName = STRING ; choose one of the RTP payload types FormatParameters = STRING C.4. Token objects The token objects fields have the semantics defined in SCCP (flags: 0x1 - inexact membership, namelist: current token holder). In addition, flag 0x100 signifies that sharing is allowed, and flag 0x200 signifies that special permission is required to obtain the token. The value is defined by the following BNF: TokenSemantics : OP [ExclusiveHolders] [SharedHolders] MaxNumShared CP ExclusiveHolders : OP EXCLUSIVE SCCS_MemberList CP SharedHolders : OP SHARED SCCS_MemberList CP MaxNumShared : OP MAX-SHARED CARDINAL CP C.5. Common Definitions Bormann, Ott, Reichert [Page 24] INTERNET-DRAFT Simple Conference Control Protocol June 1996 The following common definitions are used in the BNF: SCCS_MemberList : OP *SCCS_Member CP SCCS_Member : SCCP_Name SCCS_UserList : OP *SCCS_User CP SCCS_User : STRING ; globally unique ; format: user@domain C.6. Predefined tokens To implement floor control, the state for each application session may define what token defines its floor (if applicable). A predefined token identifier ``FLOOR'' is used as the ``default'' floor. A token for managing conductorship is named ``CONDUCTOR'' (generally, no shared conductorship will be possible). Whenever the conductor ``token'' is FREE, the conference is said to be ``non-conducted''. A conference profile may restrict who is allowed to assume this role. D. Examples D.1. Scenario: Internet Phone Call In this scenario, a simple phone call is made, then extended to a three-way phone call, and enhanced by video. Conference policy: no floor token (open floor), no conference chair, closed conference (i.e. access restrictions apply), conference locked after establishment (i.e. no further participant allowed -- until a three- way call is made). The initiator creates an initial conference context (in this annex, contexts are given in a notation that lists the objects, terminated by a semicolon, giving their type, name, flags, value, and namelist): member "cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de" 0x1 '((user-info (name . "Carsten Bormann") (phone . "+49 421 218 70 24")) (caps (audio RTP ("GSM") unicast) (audio RTP ("PCMU") unicast) (audio RTP ("G722" "48k") unicast) (video RTP ("H261 CIF") unicast multicast) (video RTP ("H261 QCIF") unicast multicast))', (); Bormann, Ott, Reichert [Page 25] INTERNET-DRAFT Simple Conference Control Protocol June 1996 variable "semantics" 0 'sccs-1.0' (); variable "policy" 0x3 '' (); variable "permitted" 0x0 '' ("cabo@informatik.uni-bremen.de" "jo@cs.tu-berlin.de"); The initiator then sends a SIP invitation to the target of the phone call [fix SIP syntax]: SIP invite m=control 47121 TCP MTCP SCCP-01.0 c=IN IP4 134.102.200.36 which responds with [fix SIP syntax] SIP accept m=control 45789 TCP MTCP SCCP-01.0 c=IN IP4 130.149.25.97 and then sends the following SCCP message: join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", 0x1, '((user-info (name . "Joerg Ott") (phone . "+49 421 314 73389") (fax . "+49 30 314 25156") (message . "just getting coffee...")) (caps (audio RTP ("GSM") unicast) (audio RTP ("PCMU") unicast) (video RTP ("H261 CIF") unicast multicast) (video RTP ("H261 QCIF") unicast multicast))', 0x47245634); The initiator takes note of the capabilities available and responds with the message: accept("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), context(vars = ("semantics"(...), "policy"(...), "permitted"(...)), /* each one including the contents, of course */ tokens = (), members = ("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"(...), "jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"(...)), sessions = (), sync = (cookie, 0x47245634, "jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), as-create("Audio-session-0", '((unicast audio RTP (IN4 "134.102.200.36" 10020) ("GSM")))', ("*")), as-join("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de", "Audio-session-0"); Bormann, Ott, Reichert [Page 26] INTERNET-DRAFT Simple Conference Control Protocol June 1996 The target responds with its local unicast parameters for the audio session and joins the session, too: set-value("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", '...old value... (parameters (("Audio-session-0" (IN4 "130.149.25.97" 12960))))'), as-join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", "Audio-session-0"); This completes the setup of the point-to-point call; the two persons communicate using the audio session. If this call shall be extended to a three person conference, either of the participants may invite the third party to join their discussion. To the other party, this is indicated by modifying the list of permitted persons; then the initiator sends a SIP invitation to the target of the phone call [fix SIP syntax]: add-name ("permitted", "aquarius@cs.tu-berlin.de"); SIP invite m=control 47121 TCP MTCP SCCP-01.0 c=IN IP4 134.102.200.36 which responds with [fix SIP syntax] SIP accept m=control 45300 TCP MTCP SCCP-01.0 c=IN IP4 130.149.25.94 and then sends the following SCCP message: join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 0x1, '((user-info (name . "Christoph Reichert")) (caps (audio RTP ("PCMA") unicast) (audio RTP ("PCMU") unicast) (video RTP ("H261 CIF") unicast multicast) (video RTP ("H261 QCIF") unicast multicast))', 0x6438123b); The new member is accepted by the receptionist. However, the receptionist notices that the currently used audio encoding is not suitable for the new member. Therefore, the receptionist decides to modify the parameters of the audio session allowing the new member to get in. accept("aquarius@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), set-value("Audio-session-0", '((unicast audio RTP (IN4 "134.102.200.36" 10020) ("PCMU")))', ("*")), Bormann, Ott, Reichert [Page 27] INTERNET-DRAFT Simple Conference Control Protocol June 1996 The receptionist informs the newcomer about the most recent state (including the changes) rather than about the state at the time of entry. To achieve this synchronization the receptionist sends a new synchronization message. sync(cookie, 0x78423d35, "cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"); context(vars = ("semantics"(...), "policy"(...), "permitted"(...)), ; each one including the contents, of course tokens = (), members = ("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"(...), "jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"(...)), "aquarius@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), sessions = ("Audio-session-0"(...)), sync = (cookie, 0x78423d35, "cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"); Noticing the existence of the audio session and that everybody is expected to join, the newcomer provides his parameters for audio and joins the audio session: set-value("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", '(...old value... (parameters (("Audio-session-0" (IN4 "130.149.25.94" 14578)))))'), as-join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", "Audio-session-0"); Thereby the three way audio conference is established. Besides audio, the participants want to include video information exchange (using multicast). One participant creates a video session. As all support the same video capabilities, the initiator chooses to trade resolution for framerate at a given bandwidth. By the creation the other participants are implicitly invited and join it afterwards. as-create("Video-session-0", '((multicast video RTP (IN4 "224.2.168.199" 11480) ("H261 QCIF")))', ("*")), as-join("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de", "Audio-session-0"); as-join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", "Video-session-0"); as-join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", "Video-session-0"); After some discussion, one participant leaves the conference: Bormann, Ott, Reichert [Page 28] INTERNET-DRAFT Simple Conference Control Protocol June 1996 as-leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", "Audio-session-0"), as-leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", "Video-session-0"), leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de"); Finally, the second participant hangs up -- his implementation does not generate redundant AS-LEAVE actions: leave("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"); The initiator, knowing that it is the only remaining member, simply discards its copy of the conference context. Bormann, Ott, Reichert [Page 29]