idnits 2.17.1 draft-ietf-mmusic-sccp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 29 instances of too long lines in the document, the longest one being 20 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '... [1] In this ...' == Line 153 has weird spacing: '... We do not ...' == Line 202 has weird spacing: '...nt, the state...' == Line 204 has weird spacing: '...ekeeper and ...' == Line 206 has weird spacing: '...version of t...' == (26 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1996) is 10175 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '6' is mentioned on line 411, but not defined == Missing Reference: '7' is mentioned on line 508, but not defined == Missing Reference: 'AS-Parameters' is mentioned on line 1056, but not defined == Missing Reference: 'Phone' is mentioned on line 1058, but not defined == Missing Reference: 'Fax' is mentioned on line 1058, but not defined == Missing Reference: 'E-Mail' is mentioned on line 1058, but not defined == Missing Reference: 'PermissionRequired' is mentioned on line 1081, but not defined == Missing Reference: 'FormatParameter' is mentioned on line 1107, but not defined == Missing Reference: 'ExclusiveHolders' is mentioned on line 1121, but not defined == Missing Reference: 'SharedHolders' is mentioned on line 1121, but not defined == Unused Reference: 'Affiliation' is defined on line 1059, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-confarch-00 -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sip-00 ** Obsolete normative reference: RFC 1889 (ref. '4') (Obsoleted by RFC 3550) == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-sdp-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'Affiliation' Summary: 12 errors (**), 0 flaws (~~), 22 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carsten Bormann 2 Expires: December 1996 Universitaet Bremen 3 Joerg Ott, Christoph Reichert 4 TU Berlin 5 June 1996 7 Simple Conference Control Protocol 8 draft-ietf-mmusic-sccp-00.txt 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 This document defines a simple conference control protocol for 33 tightly coupled conferences, based on the Internet Multimedia 34 Conferencing Architecture [1]. The functions provided are based on 35 the services offered by the ITU-T recommendations of the T.120 (and 36 H.320) series [2], they are, however, not a simple ``port'' of these 37 recommendations to the Internet. Instead, the aim is to define a 38 simple conference control protocol that is rich enough to allow the 39 construction of gateways to the T.120 world. Also, the protocol is 40 intended to be scalable and robust to failures. In contrast to the 41 ITU-T recommendations, it allows the use of IP multicast both for 42 multimedia information and for other applications and control 43 streams. 45 This document is a product of the IETF MMUSIC working group. 46 Comments are solicited and should be addressed to the working group's 47 mailing list at confctrl@isi.edu and/or the authors. 49 1. Introduction 51 The Internet Multimedia Conferencing Architecture [1] currently 52 comprises conference control elements only for loosely coupled 53 conferences, i.e. ``crowds that gather around an attraction''. Many 54 conferences have more formal policies with respect to the set of 55 participants that are allowed to listen or with respect to who may 56 talk at a particular time, or they grant specific permissions to a 57 conference chair (called conductor in this document). Also, it may 58 be desirable to change parameters of the conference (e.g., set of 59 media/applications active, parameters for these applications) in a 60 coordinated way for all participants simultaneously. Conferences 61 that have facilities for this purpose shall be termed tightly coupled 62 conferences in this document. 64 This document defines a simple conference control protocol (SCCP) for 65 tightly coupled conferences. The design of this protocol was, in 66 part, guided by the services offered by the ITU-T recommendations of 67 the T.120 (and H.320) series [2], in particular: 69 o management of the set of members participating in the 70 conference; 72 o management of the set of applications/media that constitute the 73 conference; 75 o floor control; 77 o assignment of a special ``conductor'' role to one participant. 79 The protocol is, however, not intended as a simple ``port'' of these 80 recommendations to the Internet. Instead, the aim is to define a 81 simple conference control protocol that is rich enough to allow the 82 construction of gateways between conferences based on this protocol 83 to conferences that are based on the T.120 series of recommendations. 84 Also, the protocol is intended to be more scalable and more robust to 85 failures than an MCS-based protocol can be. In contrast to the ITU-T 86 recommendations, the protocol allows the use of IP multicast both for 87 multimedia information and for other applications and control 88 streams. 90 Conferences that are controlled by SCCP may be convened using an 91 invitation protocol such as SIP [3]. 93 2. Definition of terms 95 [Note that some of these terms are general enough that, if we like 96 them, they should be defined in [1].] 98 o Conference 100 The relationship between a set of human beings that are communicating 101 together. In this document, the term is used for tightly coupled 102 (see 1) computer based conferences. 104 o Participant 106 A human being that takes part in a conference. 108 o Member 110 The system, including software and hardware, that takes part in a 111 computer conference, representing a single participant. 113 o End system 115 A host or a set of locally interconnected hosts[1] that is used as an 116 interface to a teleconference by a single participant. The end 117 system runs all the required conferencing software (e.g. media 118 agents, session directory, and the SCCP entity), together with this 119 software it constitutes a member. 121 o SCCP entity 123 An instantiation of an SCCP implementation running on an end system 124 for a single member. An SCCP entity (or entity for short) represents 125 a specific participant in the conference using the SCCP protocol. 127 o Conference controller 129 An application that interacts closely with an SCCP entity on one hand 130 to implement the conference policy and with the participant to 131 realize her wishes. 133 o UCI 135 A universal communication identifier of a person. Used as the E-mail 136 address of an individual as well as the address that can be used to 137 invite that individual via the SIP protocol. 139 o Presence 141 A representation of the fact that an identified person is using a 142 particular end system for the purpose of (potentially or actually) 143 representing this person in one or more conferences. A presence 144 corresponds to that person ``being logged in'' at an end system and 145 (potentially or actually) being available for conferencing. There is 146 a one-to-many relationship between presences and members: one 147 presence may be member of many conferences. There is a one-to-one 148 relationship between members and the cross-product of presences and 149 the set of conferences this presence appears in (which cross-product 150 contains the set of ``appearances'' of each presence). 151 _________________________ 152 [1] In this document, we use the term ``end system'' as a syn- 153 onym for ``host'' in the simplest case. We do not want to ex- 154 clude, however, that the local system that serves one participant 155 may be composed of several ``hosts'' in the Internet sense. 157 o Conference context 159 All state information kept about a conference at each member of this 160 conference. 162 o Ownership (of state information) 164 To allow for a distributed maintenance of the conference context, 165 each piece of state information is ``owned'' by exactly one end 166 system. Each end system is responsible for keeping its owned state 167 and distributing (and updating) this information to those that need 168 it. Ownership is -- as far as possible -- defined such that the need 169 for a copy of the state information is bound to the appearance of its 170 owner in the conference. 172 o Statekeeper 174 At each point in time, one SCCP entity is assigned the function of 175 statekeeper. This entity is relevant for state synchronization 176 between the involved end systems[2]. As the conference context is 177 maintained in a distributed fashion, such an entity is needed to 178 resolve conflicting concurrent operations on the conference state. 179 Also, the statekeeper is owner of the state that is global to the 180 conference. 182 o Receptionist 184 At each point in time, one SCCP entity is assigned the function of 185 receptionist. This entity is responsible for providing new 186 participants with a copy of the current conference context[3]. 188 o Profile 190 An initial description of the conference, including assignment of 191 roles to particular members, time limits for speakers, attributes of 192 the conference (open/close, conducted/anarchic, etc)[4]. 194 o Application session (AS), Session 196 The set of media agents/applications that act as peers to each other 197 within a conference. For real-time data, this generally will be an 198 RTP session [4]; for other application protocols, other horizontal 199 protocols may define their own type of session concept. Possible 200 synonyms are ``application group'' or ``media agent group''. 201 _________________________ 202 [2] For this version of this document, the statekeeper concept 203 is not yet actually necessary. See section 3. 204 [3] Statekeeper and receptionist may (but need not) be co- 205 located. 206 [4] Not all of this is defined in this version of the present 207 document, some of it is intended to be relegated to a companion 208 document called ``Simple Conference Control Semantics'' (SCCS). 210 3. Services expected from the underlying transport 212 For simplicity, this version of SCCP expects to be able to use an 213 underlying multicast transport service. This service is assumed to 214 provide reliable, consistent delivery of data units called messages. 215 Reliability is bounded by the fact that member end systems may find 216 that they no longer can reliably interact with the other members, 217 e.g. due to a network partitioning. Messages are globally ordered: 218 Each message is assigned a message number by the transport service, 219 and messages are delivered to SCCP entities in monotonic message 220 number order. In the rest of this document, the term ``distribute'' 221 will be used to indicate that a member end system sends a message 222 using the transport service. 224 Appendix B contains information on two transport mappings, including 225 one with full multicast functionality and one for a very simple 226 multipoint protocol based on TCP (MTCP). As MTCP is very easy to 227 implement, it might be appropriate for small conferences that use 228 simple implementations (e.g., internet telephony). 230 A version of SCCP that can be based on an unreliable datagram 231 multicast service and uses the statekeeper mechanism instead can be 232 derived from the present version, if this is desired. 234 4. Basic concepts of SCCP 236 4.1. Context and Objects 238 SCCP is based on the idea of maintaining a common state for the 239 entire conference, the conference context, at all participants. This 240 state is partitioned into objects. SCCP distinguishes four types of 241 objects: 243 - variables, which are general repositories for global state that 244 does not fit elsewhere, such as a conference policy; 246 - sessions, which are a special kind of variable that represents 247 global state about an application session; 249 - tokens, which are a special kind of variable that allows 250 synchronization operations; and 252 - members, which represent the information specific to a single 253 member. 255 All objects are named by a string (name), support 32 boolean 256 flags[5], can be assigned opaque data (value), and can carry a list 257 of strings that may reference other objects (namelist). 258 _________________________ 259 [5] at most one of which is used in this specification. 261 There are no special semantics associated with any of these elements 262 of an object if that object is a variable. By convention, variables 263 are named with lower-case names, e.g. ``policy''. 265 Session objects by convention are named with names that have an 266 initial capital, e.g. ``Audio''. Flag 0 is defined to indicate a 267 session with inexact membership, i.e. a session for which membership 268 information is not maintained with SCCP. The name list specifies the 269 set of members that are to join this session (the special name list 270 entry ``*'' specifies ``all members''). 272 Token objects by convention have upper case names, e.g., ``FLOOR''. 273 Tokens can have zero or more holders (members). Flag 0 is defined to 274 indicate a sharable state of the token, i.e. if flag 0 is not set, 275 only one member can hold the token at any time. 277 Member objects have names that indicate the presence that this member 278 represents, i.e. the names are composed of a UCI and a host name with 279 an intervening space, e.g. ``jo@cs.tu-berlin.de presto.cs.tu- 280 berlin.de''. Flag 0 is defined to indicate that this member is 281 willing and able to become receptionist. The namelist indicates the 282 names of the application sessions the member is currently present in. 284 4.2. Semantics 286 SCCP itself does not define the semantics of the variables and opaque 287 data values associated with objects. A simple example for semantics 288 (``Simple Conference Control Semantics'', SCCS) is attached as Annex 289 C. 291 By convention, every conference context contains a variable 292 ``semantics'' which has as value a string defining the type and 293 version of the semantics being used (e.g., ``SCCS-1.0''). [Issue: 294 define mechanisms for upward compatibility of semantics versions in 295 SCCP or in the semantics documents?] 297 4.3. Application support 299 SCCP can be used to provide support for horizontal application 300 protocols, by defining specific objects such as variables and tokens 301 for this purpose. This may allow application protocols to use a more 302 lightweight transport protocol for their application data. 304 4.4. Messages 306 The context is updated by an ordered sequence of SCCP messages. Each 307 message is an ordered sequence of one or more SCCP actions, all of 308 which are applied to the conference context in one atomic step. It 309 is the task of the conference controller to check the SCCP actions 310 against the policy of the conference and perform only actions from 311 messages that respect this policy. In the following text, a clear 312 separation will generally not be made between messages and the 313 actions, except where necessary for clarity. 315 5. Management of the set of members participating in the conference 317 SCCP is responsible for maintaining a (to a certain degree) 318 consistent membership list of all current conference participants. 319 Changes to the membership list are initiated by the following two 320 operations: 322 o JOIN 324 The SCCP entity of an end system that wants to join a conference 325 distributes a JOIN message to the SCCP transport of the respective 326 conference. Upon receipt of this message the members of the 327 conference know about the potential new participant and make a 328 decision (based on the conference policy) whether or not to accept 329 the newcomer. The receptionist is responsible for finally answering 330 the JOIN request. This answer is also distributed to the entire 331 conference to allow updating the membership list. 333 o LEAVE 335 When an end system decides to leave a conference, its SCCP entity 336 distributes a LEAVE message to the conference so that all 337 participants are informed about the state change. 339 [We need a system to ascertain membership regularly in those cases 340 where this is desired, e.g. DOUBT/CONFIRM and LEAVE on timeout. This 341 would generally be done by the statekeeper, although members that 342 have applications with their own membership control mechanisms may 343 also want to generate DOUBT messages.] 345 5.1. Invitation 347 An SCCP entity contacts the participant to be invited (more 348 correctly: one or more presences of this participant) by sending an 349 invitation message (e.g. as payload information within SIP [3]). The 350 invitation contains contact point information: a conference name, 351 transport contact information, and possibly authentication 352 information. The end system representing the participant to be 353 invited can use this information to join the conference or it can use 354 mechanisms defined outside of SCCP (e.g., an SIP BUSY message) to 355 deny joining. 357 5.2. Joining a conference 359 To join a conference, an SCCP entity needs as contact information: 360 The name (transport address) of the conference and possibly some 361 authentication information. 363 A joining entity distributes a JOIN message. (Conferences may start 364 out empty. In this case, JOIN messages by the first member will not 365 receive an answer, see below.) If the conference already has 366 participants, all SCCP entities mark the new member as JOINING. The 367 receptionist now either distributes an ACCEPT or a LEAVE message. An 368 ACCEPT message contains a copy of the current conference context and 369 the conference profile; upon the receipt of an ACCEPT message all 370 SCCP entities mark the new member as ACCEPTED in their conference 371 state. The new participant creates the applications that are defined 372 in the current conference context. 374 If the joining member does not receive an ACCEPT or LEAVE message 375 within some time (TBD), it is the first participant. If the 376 conference profile for the new conference is available to the joining 377 member and it allows the joining member to initiate the conference, 378 the conference context is initialized with the profile and the SCCP 379 entity assumes the functions of receptionist and statekeeper. If the 380 joining member does not want to become statekeeper, the SCCP entity 381 remains passive until it sees activity in SCCP (other than JOIN 382 messages)[6]; it then repeats the joining procedure. 384 If a participant just created the conference profile from scratch and 385 thus knows it is the first member (e.g., for a simple phone call), it 386 can simply create the conference context, invite other members, and 387 wait for JOIN messages. 389 5.3. Obtaining the conference context 391 Together with one or more ACCEPT actions, a receptionist distributes 392 a CONTEXT action in the same SCCP message. This copy of the 393 conference context is used to initialize the conference context in 394 the newly accepted member. 396 As other messages may be distributed in the time the receptionist 397 submits a message containing a CONTEXT action and the time this 398 message is distributed, the new member must be aware of the position 399 in the sequence of messages for which the CONTEXT action is current. 400 We call this position the context synchronization event. For 401 transport mappings that provide serial numbers, this information 402 simply is the first transport serial number that was not considered 403 at the time the CONTEXT action was built. For transport mappings 404 that do not provide serial numbers, some other method is necessary to 405 refer to the context synchronization event, which in general will be 406 a JOIN action (or possibly a special SYNC action). Therefore, both 407 of these actions carry a synchronization time stamp that, together 408 with the source of the action, can be referred to in the CONTEXT 409 action. 410 _________________________ 411 [6] This option is available only for transport mappings that 412 allow passive joins. Otherwise, a SIP based invitation mechanism 413 can be used. 415 A new member that wants to obtain the conference context simply 416 records all messages it receives from the transport until a 417 conference context is received. After applying all messages that are 418 more recent than the context synchronization event to the context 419 received, the local copy of the context is current. 421 5.4. Leaving a conference 423 If the conference profile allows this, any SCCP entity can distribute 424 a LEAVE message with the identification of a participant that now no 425 longer is a member of the conference. Any conference participant can 426 distribute a LEAVE message for itself. An SCCP entity receiving a 427 LEAVE message removes the participant listed from the (conference 428 membership list and application session membership lists of the) 429 conference context. 431 If the receptionist wants to leave the conference, it transfers its 432 receptionist function beforehand (see 6). 434 A forced leave message might include a new session key to enforce 435 that the ejected member can no longer take part in the conference. 437 5.5. Terminating a conference 439 An SCCP entity that is granted -- from the conference profile -- the 440 permission to terminate the conference does so by distributing a 441 special LEAVE message with the name ``*'' to all other participants, 442 which indicates ``conference terminated'' as the reason for the 443 exclusion from the conference. Each SCCP entity receiving this 444 message reacts similar to as if it was excluded from the conference. 446 6. Transferring the receptionist and statekeeper functions 448 There are two possibilities that require the SCCP entity performing 449 the function of the receptionist/statekeeper to change: a) when the 450 current holder of this function leaves the conference (voluntarily or 451 not) in an orderly fashion; b) when the holder crashes or is 452 partitioned away from the other conferees. 454 6.1. Mechanisms for transferring the receptionist function 456 [Fix me.] In the first case (orderly release), the receptionist 457 simply sends out a LEAVE message to the group. Each member of the 458 conference notices that the leaving entity currently acts as the 459 receptionist and that consequently a new receptionist has to be 460 found. As all members of the conference keep a consistent state 461 information base (including the sequence in which the members 462 joined[7]), the conference, this is done by simply selecting the 463 oldest remaining conference member that is receptionist-capable to 464 become the new receptionist. The new receptionist announces its new 465 role by sending a RECEPTIONIST-IS message to the group. 467 In case the designated receptionist has failed recently (and this has 468 not been detected so far), the REPECTIONIST-IS message will not show 469 up. Therefore, all receptionist-capable members of the group react 470 after a timeout (TBD) as described below for case b). 472 In case of temporarily inconsistent membership information multiple 473 RECEPTIONIST-IS messages may be sent. This situation is treated as 474 if multiple receptionist changes occur, and consequently the entity 475 whose message is delivered last becomes the new receptionist. 477 In the second case (failure), a recovery mechanism is invoked. If a 478 JOIN message is not answered by the receptionist within a certain 479 time (TBD, dithered), each SCCP entity distributes a RECOVERY message 480 unless it has already seen a RECOVERY message. The RECOVERY message 481 includes a random number, the beacon. The SCCP entity with the 482 lowest beacon assumes the receptionist function and distributes a 483 RECEPTIONIST-IS message. If two beacons are equal, the ``older'' 484 member wins. 486 6.2. Mechanisms for transferring the statekeeper function 488 [The statekeeper is not defined in this version of this document.] 490 7. Setting variables 492 Actions are defined for setting the various fields of objects such as 493 variables, tokens, and sessions. 495 o SETVALUE: sets the value field. 497 o SETFLAG: sets the flag field under a bitmask. 499 o ADDNAME: adds a name to the namelist. 501 o DELNAME: removes a name from the namelist. 503 o DELETE: deletes an object. 505 SETVALUE and SETFLAG can also be applied to member objects. 507 _________________________ 508 [7] This information is propagated to new members through the 509 ordering of the member objects in the CONTEXT message. 511 8. Management of the set of applications/media that constitute the 512 conference 514 Each application session is described by a session object in the 515 conference context. The name of the session object identifies the 516 session within the conference. 518 Application specific parameters are indicated in the value of the 519 session object. (for SDP style parameters e.g. media address, port 520 number and format [5]). As part of its own member state, each SCCP 521 entity maintains a list of application sessions it is a member of; in 522 the conference context, this current actual membership is indicated 523 in the namelists of the member objects unless the session is marked 524 as inexact by flag 0 (see below). 526 8.1. Creating application sessions 528 An SCCP entity (that is permitted to do so via the conference profile 529 -- in conducted conferences typically the conductor) distributes an 530 AS-CREATE message with the session parameters. An application 531 session is identified by a unique identifier. The namelist of the 532 session object specifies the set of members that are to join the 533 session, if the special name ``*'', it specifies that all members are 534 to join the session. 536 8.2. Terminating application sessions 538 An SCCP entity (as permitted by the conference profile) distributes 539 an AS-DELETE message with the name of the session. All other 540 entities remove the session from the conference context and indicate 541 termination of the session to the corresponding local application. 543 8.3. Joining application sessions 545 An SCCP entity starts the application and distributes an AS-JOIN 546 message with the identifier of the session. The SCCP entities note 547 in their conference context that this member now is a peer to the 548 application session. 550 8.4. Leaving application sessions 552 An SCCP entity distributes an AS-LEAVE message with the identifier of 553 the session and terminates the application. The other SCCP entities 554 take note in the member object. A LEAVE message implies leaving all 555 application sessions. 557 8.5. Inexact application sessions 559 For large conferences, it may make sense to mark an application 560 session as inexact, i.e. no AS-JOIN and AS-LEAVE messages are to be 561 distributed. This may also be useful in case application protocols 562 are able to maintain membership lists by themselves. 564 9. Token control 566 To support synchronization such as floor control (possibly with 567 multiple floors) and conductorship assignment, SCCP defines a generic 568 type of object, the token. 570 An SCCP entity distributes a TOKEN-WANT message to request a token, 571 TOKEN-GIVE to transfer it and TOKEN-RELEASE to relinquish it. A 572 token can be assigned exclusively to a single SCCP entity or can be 573 shared by any number of SCCP entities. In addition, members that are 574 appropriately privileged by the conference profile may simply re- 575 assign a token as they wish. 577 A token can basically be in one of three states: FREE (no holder), 578 EXCLUSIVE (one holder, flag 0 unset), or SHARED (one or more holders, 579 flag 0 set). 581 In each of these states a TOKEN-WANT message indicates the desire to 582 obtain the token. A flag in the TOKEN-WANT message indicates whether 583 exclusive or shared control of the token is desired. 585 o If the token is in the FREE state, the TOKEN-WANT automatically 586 assigns the token to the requester (provided the conference 587 policy permits giving the token to the requester). 589 o If the token is in the EXCLUSIVE state, the token holder has to 590 decide whether to pass the token on to the requester 591 (TOKEN_GIVE) for exclusive or shared control (the token holder 592 should follow the flag in the request) or not. 594 o If the token is in the SHARED state the behavior depends on the 595 request. A request for the shared token is implicitly granted 596 (if the policy, i.e. a limit on the number of concurrent token 597 holders, permits this). A request for an exclusive token is 598 only granted if all current shared token holders decide to pass 599 on the token to the requester by means of a TOKEN-GIVE message 600 or decide to relinquish the token with a TOKEN-RELEASE message. 601 (Note, however, that at least one TOKEN-GIVE must be sent within 602 the request timeout (TBD) for the request to succeed). 604 TOKEN-GIVE, TOKEN-WANT, and TOKEN-RELEASE messages can be sent by an 605 appropriately privileged SCCP entity indicating the desired token 606 control state: assigned to one or more explicitly listed 607 participants, assigned to the privileged entity itself, or free, 608 respectively. Such a request overrides the current token state. 609 Determination of whether or not an entity is privileged is up to the 610 conference semantics layer on top of SCCP (as is consequently the 611 decision whether or not modify the conference state accordingly). 613 10. Security Considerations 615 The authentication and encryption model for SCCP will be defined in a 616 future version of this document. 618 Any interoperation between ITU-based systems and Internet-based 619 systems must take care to preserve the point-to-point link based 620 security model underlying the ITU standards. In T.120, much of the 621 access control relies on being able to reject the attempt to join a 622 conference via an ISDN connection to an MCU. 624 11. Authors' Addresses 626 Carsten Bormann 627 Universitaet Bremen FB3 MZH 5180 628 Postfach 330440 629 D-28334 Bremen 630 GERMANY 631 cabo@informatik.uni-bremen.de 632 phone +49.421.218-7024 634 Joerg Ott 635 Christoph Reichert 636 Technische Universitaet Berlin FR 6-3 637 Franklinstr. 28/29 638 D-10587 Berlin 639 GERMANY 640 jo@cs.tu-berlin.de 641 phone +49.30.314-73389 643 12. Acknowledgements 645 Scott Shenker, Abel Weinrib, and Eve Schooler have submitted drafts 646 of a more general conference control protocol, the Agreement 647 Protocol, in the MMUSIC working group of the IETF. Many concepts of 648 the Simple Conference Control Protocol are based on discussions of 649 the agreement protocol and our experience with attempts to implement 650 it. 652 13. References 654 [1] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet 655 Multimedia Conferencing Architecture,'' Internet Draft draft- 656 ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. 658 [2] ITU T.120 series, in particular T.122/125 (MCS) and T.124 (GCC). 660 [3] Mark Handley, Eve Schooler, ``Session Invitation Protocol,'' 661 Internet Draft draft-ietf-mmusic-sip-00.txt, Work in Progress, 662 February 1996. 664 [4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A 665 Transport Protocol for Real-Time Applications,'' Internet RFC 666 1889, January 1996. 668 [5] M. Handley, V. Jacobson, ``SDP: Session Description Protocol,'' 669 Internet Draft draft-ietf-mmusic-sdp-01.txt, .ps, Work in 670 Progress, November 1995. 672 A. Message formats 674 [Issue: Note that this XDR-like specification does not necessarily 675 imply any particular type of encoding of the SCCP PDUs. The encoding 676 may be defined independently, or RFC 1832 encoding may be used.] 678 /* 679 * $Id: sccp.xdr,v 1.7 1996/06/12 19:55:13 cabo Exp $ 680 * 681 * Common types for SCCP and the API. 682 */ 684 typedef string SCCP_Name<>; 685 typedef int SCCP_Flags; 686 typedef opaque SCCP_Value<>; 687 typedef SCCP_Name SCCP_Namelist<>; 689 /* 690 * Presence: UCI space Hostname 691 * UCI: user@hostname (where hostname is SIP relevant) 692 */ 694 struct SCCP_Object { 695 SCCP_Name name; 696 SCCP_Flags flags; 697 SCCP_Value value; /* upper layer semantics */ 698 SCCP_Name namelist<>; 699 }; 701 /* 702 * vars: completely user defined 703 * 704 * Session: 0 = inexact 705 * 706 * mEmBer: 0 = precept; namelist is AS list 707 * (space in name) 708 * 709 * TOKEN: 0 = shared; namelist is holder list 710 */ 712 struct SCCP_Context { 713 SCCP_Object vars<>; 714 SCCP_Object tokens<>; 715 SCCP_Object sessions<>; 716 SCCP_Object members<>; 717 }; 719 enum SCCP_Sync_Type { 720 SCCP_S_TRANSPORT, 721 SCCP_S_COOKIE 722 }; 723 typedef int SCCP_Sync; /* local timestamp etc. */ 725 struct SCCP_Cookie { 726 SCCP_Sync sync; 727 SCCP_Name sender; 728 }; 730 union SCCP_Sync_Un switch(SCCP_Sync_Type type) { 731 case SCCP_S_TRANSPORT: 732 int transport_serial; 733 case SCCP_S_COOKIE: 734 SCCP_Cookie cookie; 735 }; 737 struct SCCP_Context_Msg { 738 SCCP_Context context; 739 SCCP_Sync_Un sync; 740 }; 742 /* 743 * for SRM adaptation protocol: include 744 * string name<>; // conference name 745 * in each message. 746 * This is not needed for MTP-2 or MTCP, as the context is clear. 747 */ 749 struct SCCP_Header { 750 char proto[4]; /* "sccp" */ 751 char sccp[4]; /* "01.1" */ 752 SCCP_Name sender; /* Presence name of sender of this message */ 753 }; 755 enum SCCP_Type { 756 SCCP_T_JOIN, /* join conference */ 757 SCCP_T_LEAVE, /* leave conference */ 758 SCCP_T_ACCEPT, /* accept joining member */ 759 SCCP_T_CONTEXT, /* context */ 760 SCCP_T_SYNC, /* context sync */ 762 SCCP_T_ASCREATE, /* create application session */ 763 SCCP_T_ASDELETE, /* delete application session */ 764 SCCP_T_ASJOIN, /* join application session */ 765 SCCP_T_ASLEAVE, /* leave application session */ 767 SCCP_T_TOKCREATE, /* create a token */ 768 SCCP_T_TOKDELETE, /* delete a token */ 769 SCCP_T_TOKWANT, /* want or grab a token */ 770 SCCP_T_TOKGIVE, /* give token */ 771 SCCP_T_TOKRELEASE, /* release token */ 773 SCCP_T_SETVALUE, /* set value of var, token, session, member */ 774 SCCP_T_SETFLAG, /* set flag of var, session, member, (token) */ 775 SCCP_T_DELETE, /* delete var */ 776 SCCP_T_ADDNAME, /* add name to var */ 777 SCCP_T_DELNAME, /* delete name from var */ 779 SCCP_T_RCPTIS, /* announce receptionist */ 780 SCCP_T_RECOVER, /* recovery message */ 782 SCCP_T_INVALID /* last and invalid sccp pdu type */ 783 }; 785 struct SCCP_Join { 786 SCCP_Name presence; /* joining member */ 787 SCCP_Flags flags; /* precept etc. */ 788 SCCP_Value value; /* user data */ 789 SCCP_Sync sync; /* cookie (timestamp etc.) */ 790 }; 792 struct SCCP_AS { 793 SCCP_Name name; 794 SCCP_Value value; 795 SCCP_Namelist names; 796 }; 798 struct SCCP_AddDelname { 799 SCCP_Name objname; 800 SCCP_Name entry; 801 }; 803 struct SCCP_Recover { 804 unsigned int beacon; 805 }; 807 struct SCCP_TOKwant { 808 SCCP_Name name; /* name of token */ 809 SCCP_Name presence;/* member the token is to be assigned to*/ 810 SCCP_Flags shared; /* want token shared or exclusive */ 811 bool notify; /* inform holder the token is wanted */ 812 }; 814 struct SCCP_TOKgive { 815 SCCP_Name name; /* name of token */ 816 SCCP_Name giver; /* member from whom the token is taken away */ 817 SCCP_Name receiver; /* member to whom the token is given */ 818 }; 820 struct SCCP_setvalue { 821 SCCP_Name var; /* name of var to set */ 822 SCCP_Value val; /* new value */ 823 }; 825 struct SCCP_setflags { 826 SCCP_Name var; /* name of var to set */ 827 SCCP_Flags mask; /* select the flags to be modified */ 828 SCCP_Flags flags; /* new flags */ 829 }; 831 union SCCP_Union switch (SCCP_Type type) { 833 case SCCP_T_JOIN: 834 SCCP_Join join; 835 case SCCP_T_LEAVE: 836 SCCP_Name leave; 837 case SCCP_T_ACCEPT: 838 SCCP_Name accept; 839 case SCCP_T_CONTEXT: 840 SCCP_Context_Msg context_msg; 841 case SCCP_T_SYNC: 842 SCCP_Sync sync; 844 case SCCP_T_ASCREATE: 845 SCCP_AS ascreate; 846 case SCCP_T_ASDELETE: 847 SCCP_Name asdelete; 848 case SCCP_T_ASJOIN: 849 SCCP_AddDelname asjoin; /* member, session */ 850 case SCCP_T_ASLEAVE: 851 SCCP_AddDelname asleave; /* member, session */ 853 case SCCP_T_TOKCREATE: 854 SCCP_Name tokcreate; 855 case SCCP_T_TOKDELETE: 856 SCCP_Name tokdelete; 857 case SCCP_T_TOKWANT: 858 SCCP_TOKwant tokwant; 859 case SCCP_T_TOKGIVE: 860 SCCP_TOKgive tokgive; 861 case SCCP_T_TOKRELEASE: 862 SCCP_AddDelname tokrelease; /* token, member no longer holder */ 864 case SCCP_T_SETVALUE: 865 SCCP_setvalue setvalue; 866 case SCCP_T_SETFLAG: 867 SCCP_setflags setflags; 868 case SCCP_T_DELETE: 869 SCCP_Name objname; 870 case SCCP_T_ADDNAME: 871 SCCP_AddDelname addname; 872 case SCCP_T_DELNAME: 873 SCCP_AddDelname delname; 875 case SCCP_T_RCPTIS: 876 SCCP_Name rcptis; 877 case SCCP_T_RECOVER: 878 SCCP_Recover recover; 879 }; 880 struct SCCP_Message { 881 SCCP_Header hdr; 882 SCCP_Union sccp_un<>; 883 }; 885 B. Transport mappings 887 At this time, transport mappings are defined for SCCP for two 888 protocols: 890 1) A simple multipoint protocol based on TCP defined in this annex 891 (MTCP). 893 2) The multicast transport protocol MTP-2. 895 B.1. MTCP 897 Each SCCP message is mapped to an MTCP message. 899 The initiator of a conference operates as the MTCP core. All other 900 participants build connections to the MTCP core. 902 B.1.1. MTCP protocol definition 904 MTCP uses TCP connections between a central core and additional 905 participants (one or more). Data units are exchanged on these 906 connections, delimited by using a variant of the RMS protocol (RFC 907 1831 section 10): Instead of a header with one bit of flag and 31 908 bits of length, MTCP uses two bits of flag and 30 bits of length. 909 The most significant bit, if set, indicates a control message; the 910 rest of the header is then interpreted specially. If the control 911 message bit is unset, the next to most significant bit indicates the 912 final fragment of a message as in RFC1831: 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 |0|F| length | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 If the control message bit is set, the next to most significant bit 919 indicates one of two control messages: If unset, the header indicates 920 a release event. 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 |1|0| Must be zero | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 If set, the header indicates an initial sequence number data unit: 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 |1|1| Initial Sequence Number | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Messages are assigned numbers implicitly by the order in which the 933 MTCP core distributes them, starting from the initial sequence 934 number. The core relays every message in order to every participant. 936 New participants receive an initial sequence number from the core, 937 this is the sequence number of the next message received. 939 A message received by the core from a non-core participant is relayed 940 by the core to every other participant, except to the participant 941 that sent it: As the sending participant knows what message it sent, 942 it simply receives a release event in the position in the message 943 sequence that its message has been determined to occupy by the core. 945 A MTCP implementation has to provide two modes. In core mode, it 946 passively listens on a TCP socket. Once a new connection is opened, 947 it immediately sends an initial sequence number on that connection. 948 It sends all of the messages locally originated in the same order on 949 all connections. It also sends a copy of all messages received from 950 the non-cores, except on the connection where the message was 951 received, where a release event is sent instead. It delivers 952 messages to the SCCP entity in the same order it sends them to the 953 non-core members. 955 In non-core mode, it creates a TCP connection to a specified core. 956 It sends all messages it wants send to the core, keeping a copy in a 957 queue. It delivers all messages received from the core to the SCCP 958 entity. If it receives a release event, it delivers a copy of the 959 oldest message in its queue to the SCCP entity. 961 B.2. MTP-2 963 [Fix me, although:] The mapping to MTP-2 is trivial. 965 C. SCCS: Simple Conference Control Semantics 967 This annex defines a simple set of semantics for conference control. 969 C.1. Variables 971 VariableName Field Semantic Contents 972 ------------------------------------------------------ 973 "semantics" .flags - none - 974 .value "SCCS-1.0" 975 .namelist - none - 976 ------------------------------------------------------ 977 "permitted" .flags - none - 978 .value - none - 979 .namelist - prospective members - 980 ------------------------------------------------------ 981 "policy" .flags 0x0001 - conference locked 982 0x0002 - closed conference 984 .value TBD. 985 .namelist TBD. 987 C.2. Member objects 989 The member objects fields have the semantics defined in SCCP (flags: 990 0x1 - capable/willing of being receptionist, namelist: application 991 sessions user is active in). The value is defined by the following 992 BNF (following the notational conventions of RFC822, section 2, with 993 the exception that whitespaces are allowed to separate the tokens 994 below): 996 The following tokens are recognized: 998 ; delimiter 999 OP = "(" 1000 CP = ")" 1001 DOT = "." 1002 ; keywords 1003 AFFILIATION = "affiliation" 1004 AUDIO = "audio" 1005 CAPS = "caps" 1006 CONTROL = "control" 1007 DATA = "data" 1008 EMAIL = "e-mail" 1009 EXCLUSIVE = "exclusive" 1010 FAX = "fax" 1011 IP4-TYPE = "IN4" 1012 LOCATION = "location" 1013 MAX-SHARED = "max-shared" 1014 USER-INFO = "user-info" 1015 MESSAGE = "message" 1016 MTCP = "MTCP" 1017 MTP-2 = "MTP-2" 1018 MULTICAST = "multicast" 1019 NAME = "name" 1020 PARAMETERS = "parameters" 1021 PHONE = "phone" 1022 PRIVATE = "private" 1023 PUBLIC = "public" 1024 RTP = "RTP" 1025 SHARED = "shared" 1026 TCP = "TCP" 1027 UDP = "UDP" 1028 UNICAST = "unicast" 1029 UNICAST-CENTRALIZED = "unicast-centralized" 1030 UNICAST-MESH = "unicast-mesh" 1031 VIDEO = "video" 1032 ; complex tokens 1033 CARDINAL = POS-DIGIT *DIGIT 1034 DECIMAL-UCHAR = DIGIT 1035 | POS-DIGIT DIGIT 1036 | (1 2*DIGIT) 1037 | (2 (0|1|2|3|4) DIGIT) 1038 | (2 5 (0|1|2|3|4|5)) 1040 DECIMAL-USHORT = DIGIT 1041 | POS-DIGIT 1*3DIGIT 1042 | (("1"|"2"|"3"|"4"|"5") 4DIGIT) 1043 | ("6" ("0"|"1"|"2"|"3"|"4") 3DIGIT) 1044 | ("65" ("0"|"1"|"2"|"3"|"4") 2DIGIT) 1045 | ("655" ("0"|"1"|"2") DIGIT) 1046 | ("6553" ("0"|"1"|"2"|"3"|"4"|"5")) 1048 IP4-ADDRESS = <"> DECIMAL-UCHAR DOT DECIMAL-UCHAR DOT 1049 DECIMAL-UCHAR DOT DECIMAL-UCHAR <"> 1050 ; it is not up to the parser to distinguish between unicast 1051 ; and multicast addresses 1053 STRING = <"> * <"> 1056 MemberSemantics = OP UserInfo AS-CapabilityList [AS-Parameters] /* ... */ CP 1058 UserInfo = OP USER-INFO Name [Phone] [Fax] [E-Mail] 1059 [Affiliation] [Location] [Message] /* ... */ CP 1060 Name = OP NAME DOT STRING CP 1061 Phone = OP VOICE DOT STRING CP 1062 Fax = OP FAX DOT STRING CP 1063 E-Mail = OP E-MAIL DOT STRING CP 1064 Affiliation = OP AFFILIATION DOT STRING CP 1065 Location = OP LOCATION DOT STRING CP 1066 Message = OP MESSAGE DOT STRING CP 1068 AS-CapabilityList = OP CAPS *AS-Capability CP 1069 AS-Capability = OP AS-Medium AS-Protocol AS-Format AS-Distribution CP 1070 AS-Distribution = UNICAST / MULTICAST / UNICAST MULTICAST 1071 AS-Parameters = OP PARAMETERS AS-ParameterList CP 1072 AS-ParameterList = OP *AS-Parameter CP 1073 AS-Parameter = OP AS-Name UniTransportAddress /* ... */ CP 1075 C.3. Session objects 1077 The session objects fields have the semantics defined in SCCP (flags: 1078 0x1 - inexact membership, namelist: prospective member list for this 1079 session). The value is defined by the following BNF: 1081 AS-Semantics = OP [PermissionRequired] 1082 AS-Transport AS-Format CP 1084 PermissionRequired = (OP PRIVATE PermittedMembers CP) 1085 / (OP PUBLIC CP) 1087 AS-Transport = (UNICAST-CENTRALIZED AS-Medium AS-Protocol UniTransportAddress) 1088 / (UNICAST-MESH AS-Medium AS-Protocol) 1089 / (MULTICAST AS-Medium AS-Protocol MultiTransportAddress) 1091 AS-Medium = AUDIO / VIDEO / DATA 1093 AS-Protocol = 1*AS-ProtocolName 1095 AS-ProtocolName = UDP / TCP / MTP-2 / MTCP / RTP 1096 ; to be extended 1098 UniTransportAddress = OP Address Port CP 1100 MultiTransportAddress = OP Address Port TTL CP 1102 Address = IP4-TYPE IP4-ADDRESS 1103 ; to be extended 1105 Port = DECIMAL-USHORT 1107 AS-Format = OP FormatName [FormatParameter] CP 1109 FormatName = STRING ; choose one of the RTP payload types 1111 FormatParameters = STRING 1113 C.4. Token objects 1115 The token objects fields have the semantics defined in SCCP (flags: 1116 0x1 - inexact membership, namelist: current token holder). In 1117 addition, flag 0x100 signifies that sharing is allowed, and flag 1118 0x200 signifies that special permission is required to obtain the 1119 token. The value is defined by the following BNF: 1121 TokenSemantics : OP [ExclusiveHolders] [SharedHolders] MaxNumShared CP 1123 ExclusiveHolders : OP EXCLUSIVE SCCS_MemberList CP 1125 SharedHolders : OP SHARED SCCS_MemberList CP 1127 MaxNumShared : OP MAX-SHARED CARDINAL CP 1129 C.5. Common Definitions 1130 The following common definitions are used in the BNF: 1132 SCCS_MemberList : OP *SCCS_Member CP 1134 SCCS_Member : SCCP_Name 1136 SCCS_UserList : OP *SCCS_User CP 1138 SCCS_User : STRING ; globally unique 1139 ; format: user@domain 1141 C.6. Predefined tokens 1143 To implement floor control, the state for each application session 1144 may define what token defines its floor (if applicable). A 1145 predefined token identifier ``FLOOR'' is used as the ``default'' 1146 floor. 1148 A token for managing conductorship is named ``CONDUCTOR'' (generally, 1149 no shared conductorship will be possible). Whenever the conductor 1150 ``token'' is FREE, the conference is said to be ``non-conducted''. A 1151 conference profile may restrict who is allowed to assume this role. 1153 D. Examples 1155 D.1. Scenario: Internet Phone Call 1157 In this scenario, a simple phone call is made, then extended to a 1158 three-way phone call, and enhanced by video. Conference policy: no 1159 floor token (open floor), no conference chair, closed conference 1160 (i.e. access restrictions apply), conference locked after 1161 establishment (i.e. no further participant allowed -- until a three- 1162 way call is made). 1164 The initiator creates an initial conference context (in this annex, 1165 contexts are given in a notation that lists the objects, terminated 1166 by a semicolon, giving their type, name, flags, value, and namelist): 1168 member "cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de" 0x1 1169 '((user-info (name . "Carsten Bormann") 1170 (phone . "+49 421 218 70 24")) 1171 (caps (audio RTP ("GSM") unicast) 1172 (audio RTP ("PCMU") unicast) 1173 (audio RTP ("G722" "48k") unicast) 1174 (video RTP ("H261 CIF") unicast multicast) 1175 (video RTP ("H261 QCIF") unicast multicast))', 1176 (); 1178 variable "semantics" 0 'sccs-1.0' (); 1180 variable "policy" 0x3 '' (); 1182 variable "permitted" 0x0 '' 1183 ("cabo@informatik.uni-bremen.de" "jo@cs.tu-berlin.de"); 1185 The initiator then sends a SIP invitation to the target of the phone 1186 call [fix SIP syntax]: 1188 SIP invite 1189 m=control 47121 TCP MTCP SCCP-01.0 1190 c=IN IP4 134.102.200.36 1192 which responds with [fix SIP syntax] 1194 SIP accept 1195 m=control 45789 TCP MTCP SCCP-01.0 1196 c=IN IP4 130.149.25.97 1198 and then sends the following SCCP message: 1200 join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", 0x1, 1201 '((user-info (name . "Joerg Ott") 1202 (phone . "+49 421 314 73389") 1203 (fax . "+49 30 314 25156") 1204 (message . "just getting coffee...")) 1205 (caps (audio RTP ("GSM") unicast) 1206 (audio RTP ("PCMU") unicast) 1207 (video RTP ("H261 CIF") unicast multicast) 1208 (video RTP ("H261 QCIF") unicast multicast))', 1209 0x47245634); 1211 The initiator takes note of the capabilities available and responds 1212 with the message: 1214 accept("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), 1215 context(vars = ("semantics"(...), "policy"(...), "permitted"(...)), 1216 /* each one including the contents, of course */ 1217 tokens = (), 1218 members = 1219 ("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"(...), 1220 "jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"(...)), 1221 sessions = (), 1222 sync = (cookie, 0x47245634, 1223 "jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), 1225 as-create("Audio-session-0", '((unicast audio RTP (IN4 "134.102.200.36" 1226 10020) ("GSM")))', ("*")), 1228 as-join("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de", 1229 "Audio-session-0"); 1231 The target responds with its local unicast parameters for the audio 1232 session and joins the session, too: 1234 set-value("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", 1235 '...old value... 1236 (parameters (("Audio-session-0" (IN4 "130.149.25.97" 12960))))'), 1238 as-join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", 1239 "Audio-session-0"); 1241 This completes the setup of the point-to-point call; the two persons 1242 communicate using the audio session. If this call shall be extended 1243 to a three person conference, either of the participants may invite 1244 the third party to join their discussion. To the other party, this 1245 is indicated by modifying the list of permitted persons; then the 1246 initiator sends a SIP invitation to the target of the phone call [fix 1247 SIP syntax]: 1249 add-name ("permitted", "aquarius@cs.tu-berlin.de"); 1251 SIP invite 1252 m=control 47121 TCP MTCP SCCP-01.0 1253 c=IN IP4 134.102.200.36 1255 which responds with [fix SIP syntax] 1257 SIP accept 1258 m=control 45300 TCP MTCP SCCP-01.0 1259 c=IN IP4 130.149.25.94 1261 and then sends the following SCCP message: 1263 join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 0x1, 1264 '((user-info (name . "Christoph Reichert")) 1265 (caps (audio RTP ("PCMA") unicast) 1266 (audio RTP ("PCMU") unicast) 1267 (video RTP ("H261 CIF") unicast multicast) 1268 (video RTP ("H261 QCIF") unicast multicast))', 1269 0x6438123b); 1271 The new member is accepted by the receptionist. However, the 1272 receptionist notices that the currently used audio encoding is not 1273 suitable for the new member. Therefore, the receptionist decides to 1274 modify the parameters of the audio session allowing the new member to 1275 get in. 1277 accept("aquarius@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), 1279 set-value("Audio-session-0", '((unicast audio RTP (IN4 "134.102.200.36" 1280 10020) ("PCMU")))', ("*")), 1282 The receptionist informs the newcomer about the most recent state 1283 (including the changes) rather than about the state at the time of 1284 entry. To achieve this synchronization the receptionist sends a new 1285 synchronization message. 1287 sync(cookie, 0x78423d35, 1288 "cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"); 1290 context(vars = ("semantics"(...), "policy"(...), "permitted"(...)), 1291 ; each one including the contents, of course 1292 tokens = (), 1293 members = 1294 ("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"(...), 1295 "jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"(...)), 1296 "aquarius@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"), 1297 sessions = ("Audio-session-0"(...)), 1298 sync = (cookie, 0x78423d35, 1299 "cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de"); 1301 Noticing the existence of the audio session and that everybody is 1302 expected to join, the newcomer provides his parameters for audio and 1303 joins the audio session: 1305 set-value("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 1306 '(...old value... 1307 (parameters (("Audio-session-0" (IN4 "130.149.25.94" 14578)))))'), 1309 as-join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 1310 "Audio-session-0"); 1312 Thereby the three way audio conference is established. Besides 1313 audio, the participants want to include video information exchange 1314 (using multicast). One participant creates a video session. As all 1315 support the same video capabilities, the initiator chooses to trade 1316 resolution for framerate at a given bandwidth. By the creation the 1317 other participants are implicitly invited and join it afterwards. 1319 as-create("Video-session-0", '((multicast video RTP (IN4 "224.2.168.199" 1320 11480) ("H261 QCIF")))', ("*")), 1322 as-join("cabo@informatik.uni-bremen.de ruin.informatik.uni-bremen.de", 1323 "Audio-session-0"); 1325 as-join("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de", 1326 "Video-session-0"); 1328 as-join("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 1329 "Video-session-0"); 1331 After some discussion, one participant leaves the conference: 1333 as-leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 1334 "Audio-session-0"), 1335 as-leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de", 1336 "Video-session-0"), 1337 leave("aquarius@cs.tu-berlin.de kubismus.cs.tu-berlin.de"); 1339 Finally, the second participant hangs up -- his implementation does 1340 not generate redundant AS-LEAVE actions: 1342 leave("jo@cs.tu-berlin.de kolbmais.cs.tu-berlin.de"); 1344 The initiator, knowing that it is the only remaining member, simply 1345 discards its copy of the conference context.