idnits 2.17.1 draft-ott-mmusic-mbus-semantics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 33 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 22 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 194 has weird spacing: '...tarting appli...' == Line 195 has weird spacing: '...options and...' == Line 197 has weird spacing: '...cess is able ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 1999) is 9053 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1889 (ref. '4') (Obsoleted by RFC 3550) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Ott/C. Perkins/D. Kutscher 2 Expires: December 1999 Universitaet Bremen/UCL/Universitaet Bremen 3 June 1999 5 The Message Bus: Messages and Procedures 6 draft-ott-mmusic-mbus-semantics-00.txt 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 In a variety of conferencing scenarios, a local communication channel 32 is desirable for conference-related information exchange between co- 33 located but otherwise independent application entities, for example 34 those taking part in application sessions that belong to the same 35 conference. In loosely coupled conferences such a mechanism allows 36 for coordination of applications entities to e.g. implement 37 synchronization between media streams or to configure entities 38 without user interaction. It can also be used to implement tightly 39 coupled conferences enabling a conference controller to enforce 40 conference wide control within a end system. 42 The local conference Message Bus (Mbus) provides a means to achieve 43 the necessary amount of coordination between co-located conferencing 44 applications for virtually any type of conference. The Message Bus 45 comprises two logically distinct parts: a message transport and 46 addressing infrastructure and a set of common as well as media tool 47 specific messages. This document defines protocol procedures for the 48 Message Bus operation and the syntax and semantics of several sets of 49 Mbus messages: common messages understood by all application entities 50 as well as messages specific to particular classes of applications. 52 The underlying message passing and addressing mechanisms for the Mbus 53 is defined in a companion Internet draft [3]. 55 This document is a contribution to the Multiparty Multimedia Session 56 Control (MMUSIC) working group of the Internet Engineering Task 57 Force. Comments are solicited and should be addressed to the working 58 group's mailing list at confctrl@isi.edu and/or the authors. 60 1. Introduction 62 1.1. Background 64 The requirement specification as defined in the companion 65 requirements specification [2] provides a set of scenario 66 descriptions for the usage of a local coordination infrastructure. 67 The Message Bus defined in this and a companion document provides a 68 suitable means for local communication that serves all of the 69 purposes mentioned in the requirement draft. 71 1.2. Scope of this Document 73 Two components constitute the Message Bus: the (lower level) message 74 passing mechanisms and the (higher level) messages and their 75 semantics. While the basic transport mechanisms for the Mbus are 76 defined in a companion Internet Draft [3], the purpose of this 77 document is to define common as well as application-specific Mbus 78 messages and their semantics. This includes 80 o definition of a simple naming scheme to allow for unambiguous 81 command names as well as easy and conflict-free extensibility of 82 the Mbus command set. 84 o definition of a set of mandatory Mbus management messages and 85 associated procedures that enable the Mbus to function in 86 virtually all kinds of conference settings; 88 o definition of a set of conditionally mandatory messages for 89 conference control; and 91 o definition of several sets of optional messages for specific 92 media types and/or functions. 94 The main body of this document addresses the first three bullet items 95 thereby providing the foundation for the operation of the Mbus. The 96 Mbus messages specific to particular protocols, media, and functions 97 are contained in independent appendices to this document. 99 2. Command Naming Scheme 101 The general command syntax is described in the companion Mbus 102 protocol Internet draft[3]. Command names SHALL be constructed using 103 hierarchical names to group conceptually related commands under a 104 common hierarchy. The delimiter between names in the hierarchy is 105 ``.'' (dot). 107 The Mbus addressing scheme defined in [3] provides for specifying 108 incomplete addresses by omitting certain elements of an address 109 element list, enabling entities to send commands to a group of Mbus 110 entities. Therefore all command names must be unambiguous in a way 111 that it is possible to interpret or neglect them without considering 112 the message's address. 114 A set of commands within a certain hierarchy that MUST be understood 115 by every entity is defined in section 4 ("Entity Control"). Table 1 116 lists the pre-defined command prefixes: 118 +---------------+------------------------------------------+ 119 |Command prefix | Description of command class | 120 +---------------+------------------------------------------+ 121 |mbus. | General Basic Mbus commands | 122 |conf. | Commands related to conference control | 123 |rtp. | RTP-related commands | 124 |audio. | Commands specific to audio tools/engines | 125 |video. | Commands specific to video tools/engines | 126 |security. | Security-related commands | 127 |status. | Commands to communicate status | 128 | | information, error conditions etc. | 129 +---------------+------------------------------------------+ 130 Table 1: Naming conventions for Mbus commands 132 In addition, tool specific commands have to be defined as well thus 133 allowing each Mbus entity to define and use a number of private 134 commands. All such commands must begin with the sequence 136 tool., 138 for example tool.rat. 140 The following sections define the mentioned command classes. 142 3. Basic Mbus Operation and Management 144 3.1. Requirements 146 Before components of a conferencing system can communicate with one 147 another using the Mbus, they need to mutually find out about their 148 existence. After this bootstrap procedure that each Mbus entity goes 149 through all other entities listening to the same Mbus know about the 150 newcomer and the newcomer has learned about all the other entities. 152 In order to minimize the dependencies of applications on one another 153 and on the environment they are operating in, a bootstrap procedure 154 must take into account that 156 o Mbus entities may be started in an arbitrary order 158 - manually by the user from a command line interpreter 159 (possibly with provision a set of command line parameters), 161 - manually by the user from a window manager menu (i.e. in 162 contrast to the former without explicit parameterization), 164 - automatically from a conference-aware tool (such as SDR), 165 or 167 - initially at system startup (and thus may be listening in 168 the background).[1] 170 o some Mbus entities may depend on continued existence of other 171 Mbus entities or need to synchronize with them before being able 172 to perform their functions properly; and 174 o a local coordination entity -- if present -- may take over 175 control of the tools, but cooperation via the Mbus works as well 176 if no such controller is present. 178 3.2. Basic Mechanisms 180 From the aforementioned requirements, the following mechanisms are 181 devised as being necessary: 183 1. Self-announcement messages 185 Any Mbus entity is supposed to announce its presence (on the 186 Mbus) after starting up. This is to be done repeatedly 187 throughout its lifetime to address the issues of startup 188 sequence. 190 2. Alive messages 192 _________________________ 193 [1] Note that the main distinction between these various ways of 194 starting application entities are a) the amount of configuration 195 information passed to the application as command line options and 196 b) whether applications are single-session or multi-session capa- 197 ble (i.e. whether or not a single application process is able to 198 act as multiple instances on the Mbus or not). 200 Any Mbus entity should frequently indicate that it is still 201 alive. This mechanism may be combined with the aforementioned 202 self-announcement. 204 3. Synchronization messages 206 An Mbus entity should be able to indicate that it is waiting for 207 a certain event to happen (similar to a P() operation on a 208 semaphore but without creating external state somewhere). In 209 conjunction with this, an Mbus entity should be capable of 210 indicating to another entity that this condition is now 211 satisfied (similar to a semaphore's V() operation). 213 An appropriate set of commands that implements this conceptual 214 specification is presented in the following section. 216 3.3. Mbus Management Protocol 218 3.3.1. Mbus Message Syntax and Procedures 220 The following Mbus messages are defined to implement the mechanisms 221 described above: 223 HELLO 225 Syntax: mbus.hello () 227 Parameters: - none - 229 Each Mbus entity MUST send HELLO messages after startup to the global 230 Mbus channel. After transmission of the HELLO message, it shall 231 start a timer after the expiration of which the next HELLO message 232 shall be transmitted. The timer shall be set to a random value 233 t_hello <= t <= t_hello + t_dither to avoid synchronization of HELLO 234 messages. Transmission of HELLO messages MUST NOT be stopped unless 235 the entity detaches from the Mbus. 237 HELLO messages are sent unreliably to all Mbus entities. 239 Each Mbus entity learns about other Mbus entities by observing their 240 HELLO messages and tracking the sender address of each message. 242 The HELLO message is also used to track the liveness of any Mbus 243 entity. Whenever an Mbus entity has not heard for a time span of 244 n_dead*(t_hello+t_dither) from another Mbus entity it may consider 245 this entity to have failed (or have quit silently). Note that no 246 need for any action is necessarily implied from this observation. 248 BYE 250 Syntax: mbus.bye () 252 Parameters: - none - 254 An Mbus entity that is about to terminate (or ``detach'' from the 255 Mbus) announces this by transmitting a BYE message. 257 The BYE message is sent unreliably to all receivers. 259 WAITING 261 Syntax: mbus.waiting (condition) 263 Parameters: symbol condition 264 The condition parameter is used to indicate that the 265 entity transmitting this message is waiting for a 266 particular event to occur. 268 The WAITING messages may be broadcast to all Mbus entities, multicast 269 an arbitrary subgroup, or unicast to a particular peer. Transmission 270 of the WAITING message MUST be unreliable and hence has to be 271 repeated at an application-defined interval (until the condition is 272 satisfied). 274 If an application wants to indicate that it is waiting for several 275 conditions to be met, several WAITING messages are sent (possibly 276 included in the same Mbus payload). Note that HELLO and WAITING 277 messages may also be transmitted in a single Mbus payload. 279 Appendix D presents a tool configuration scheme that allow tools to 280 be parameterized on the command line in order to start them in 281 ``waiting mode''. 283 GO 285 Syntax: mbus.go (condition) 287 Parameters: symbol condition 288 This parameter specifies which condition is met. 290 The GO message is sent by an Mbus entity to ``unblock'' another Mbus 291 entity -- the latter of which has indicated that it is waiting for a 292 certain condition to be met. Only a single condition can be 293 specified per GO message. If several conditions are satisfied 294 simultaneously multiple GO messages MAY be combined in a single Mbus 295 payload. 297 The GO message MUST be sent reliably via unicast to the Mbus entity 298 to unblock. 300 QUERY 302 Syntax: mbus.query (variable) 304 Parameters: symbol variable 305 This parameter specifies the variable name. 307 The QUERY message is a general mechanism for obtaining arbitrary 308 information from Mbus entities. The semantics and the variable names 309 are application specific. QUERY messages are answered with INFO 310 messages (see below). 312 The QUERY message can be multicast or sent reliably via unicast to a 313 single Mbus entity or a group of entities. 315 INFO 317 Syntax: mbus.info (variable value) 319 Parameters: symbol variable 320 This parameter specifies the variable name. 322 string value 323 The variable parameter specifies the variable name 324 requested in a QUERY messages and the value parameter, 325 that can be of an arbitrary type, provides the requested 326 information. 328 The INFO message is a general mechanism for delivering arbitrary 329 information to Mbus entities. The semantics and the variable names 330 are application specific. 332 The INFO message can be multicast or sent reliably via unicast to a 333 single Mbus entity or a group of entities. 335 POLL 337 Syntax: mbus.poll (question alt_c choice_c (alternatives) 338 context) 340 Parameters: symbol question 341 This parameter question specifies the question topic a 342 vote is requested for. 344 Integer alt_c 346 Integer choice_c 347 List (alternatives) 348 A sequence of parameters specifying how to process and 349 answer the question in the following format: (n k (c1 ... 350 cn)) 352 +------------+--------------------------------------+ 353 |n | Number of alternatives | 354 |k | Number of allowed choices | 355 |(c1 ... cn) | A List of alternatives (type string) | 356 +------------+--------------------------------------+ 357 Table 2: Specification parameters of a POLL message 359 list context 360 The context parameter contains application specific 361 context information required for deciding on the 362 question. 364 The POLL message is a general mechanism for requesting decisions on 365 arbitrary questions from Mbus entities. The semantics, the question 366 names and the alternatives are application specific. 368 The POLL message can be multicast or sent reliably via unicast to a 369 single Mbus entity or a group of entities. 371 It is up to the inquiring application to ensure that 373 a) all desired entities are inquired (and reached) and 375 b) all responses are collected 377 VOTE 379 Syntax: mbus.vote (question (choice-list)) 381 Parameters: symbol question 382 This parameter question specifies the question topic this 383 vote refers to. 385 List choice-list 386 A list of selected choices that must conform to the 387 specification that was received in a POLL message before. 388 The list elements are of type Integer and represent 389 indices to the alternatives-list of the POLL message 390 starting from 0. 392 The VOTE message is a general mechanism for answering POLL messages. 393 A entity can have a group of other entities decide on a question, 394 collect the results as VOTE messages and evaluate these to infer 395 further actions. See appendix H for a sample POLL/VOTE conversation 396 scenario. 398 The VOTE message can be multicast or sent reliably via unicast to a 399 single Mbus entity or a group of entities. 401 3.3.2. Timers and Counters 403 The following values for timers and counters used in this document 404 shall apply. 406 +----------------+------------------+ 407 |Timer / Counter | Value | 408 +----------------+------------------+ 409 |t_hello | 1 second | 410 |t_dither | 100 milliseconds | 411 |n_dead | 5 | 412 +----------------+------------------+ 413 Table 2: Timer and counter values 415 As the Mbus is designed for a local system architecture it is not 416 considered necessary to provide dynamic adaptation of these timers 417 and counters to the number of Mbus entities. 419 4. Conference Control 421 The conference control part of the Mbus messages is intended to 423 a) provide a means for obtaining information about capabilities 424 from other local application entities -- for both using this 425 information for capability negotiation with other end systems 426 and determining which commands are understood by another 427 application entity --; 429 b) allow dynamic (re-)configuration of application entities with 430 respect to various session parameters; 432 c) forward conference state changes (potentially negotiated by a 433 local conference controller through a horizontal control 434 protocol) to all other application entities; and 436 d) provide means for controlling call control entities, such as SIP 437 or H.323 engines; and 439 e) allow application entities (in tightly controlled conferences) 440 to request invocation of conference control services from a 441 conference controller (within whatever system and conference 442 policy constraints apply). 444 Commands of the ``Conference Control'' class SHALL be prefixed with 445 ``conf.''. Table 3 lists the currently defined prefixes under the 446 conf hierarchy. 448 +-------------------+----------------------------------------+ 449 |Command prefix | Description of command class | 450 +-------------------+----------------------------------------+ 451 |conf.cap. | Capability commands | 452 |conf.transport. | Media transport configuration commands | 453 |conf.call-control. | Call control commands | 454 +-------------------+----------------------------------------+ 455 Table 3: Naming conventions for Mbus conference control commands 457 4.1. Capabilities 459 In order to enable tightly controlled conferences a conference 460 controller -- potentially the local coordination entity -- needs to 461 determine not only which application entities are present but also 462 which capabilities they have, in which application sessions they 463 participate, and so forth. This leads to the following: 465 Each Mbus entity should support a capability query and respond by 466 providing the requested information to the querier. The query may be 467 asking for all capabilities of the queried entity or for a particular 468 subset specified in the query. Upon receipt of such a query the 469 inquired Mbus entity provides successively all the desired capability 470 information, possibly after recursive queries from the querier. 472 Capability commands are to be defined at a later time. 474 4.2. Media transport configuration 476 The hierarchy conf.transport. contains commands for configuring 477 media transport parameters of entities such as IP addresses, port 478 numbers, ttl. These commands SHOULD generally not be sent to entity 479 groups because each entity will require a unique parameter set. 481 4.2.1. address 483 Syntax: conf.transport.address (ipaddr port [cport]) 485 Parameters: string ipaddr 487 list of integer port-list 489 integer ttl 491 The IP unicast or multicast address and associated port 492 number(s) to be used for information transmission (and, 493 in case of multicast) reception. For application 494 entities using RTP, the port for RTCP addresses may be 495 specified as the second element of the port list. TTL 496 values can be specified with the ttl parameter. 498 4.3. Miscellaneous Conference Control 500 A conference controller that cannot map or translate every conference 501 control related state transition in a tightly coupled conference to a 502 entity specific remote control Mbus message will want to ``forward'' 503 this information to the group of all Mbus entities in order to allow 504 each entity to interpret this information independently. The 505 objective is to define a set of generic Mbus commands that allows to 506 represent the change of conference global variables without 507 necessarily using these commands to remote-control entities 508 explicitly. 510 Conference control related commands are prefixed with ``conf.''. 511 Table 4 lists the prefixes under the conf hierarchy. 513 +------------------+-----------------------------------------+ 514 |Command prefix | Description of command class | 515 +------------------+-----------------------------------------+ 516 |conf.name | Set conference/session name | 517 |conf.call-control | Commands for signaling invitations etc. | 518 |conf.floor | Floor control commands/indications | 519 | | | 520 |conf.member | Membership lists | 521 |conf.chair | Conference chair indications | 522 +------------------+-----------------------------------------+ 523 Table 5: Naming conventions for Mbus control.conf commands 525 4.3.1. Conference parameters 527 A set of commands is defined to communicate conference parameters 528 like conference/session names etc. 530 4.3.1.1. Name 532 Syntax: conf.name (conference-name [session-name]) 534 Parameters: conference-name 535 session-name 536 Sets the conference (and session) name for a conference. 538 4.4. Call Control Messages 540 Call control messages are intended for interaction with call control 541 and invitation protocols such as H.323 and SIP. They are designed to 542 constitute the union of the call control messaging needed by 543 endpoints, gateways, proxies, multipoint controllers, and 544 gatekeepers. This allows the use of the Message Bus as a gluing 545 mechanisms to create any type of system from roughly the same 546 building blocks. 548 Mbus call control messages are based on a common basic message set 549 defined in the following that shall be supported by any kind of call 550 control protocol entity. The basic message set may be augmented by 551 protocol-specific extensions required for protocol specific 552 interactions between a local controller and/or local applications on 553 one side and the respective protocol engine on the other. 555 The following prefixing conventions apply for call control messages: 557 +---------------------------------------------------------------------+ 558 |Command prefix Description of command class 559 +---------------------------------------------------------------------+ 560 |conf.call-control. basic call control | 561 | message set | 562 |conf.call-control.h323. extensions for | 563 | H.323-specific call | 564 | control messages | 565 |conf.call-control.sip. extensions for SIP- | 566 | specific call control | 567 | messages | 568 +---------------------------------------------------------------------+ 569 Table 6: Call control message prefixes 571 4.4.1. The Basic Call Control Message Set 573 The basic set of messages is defined to provide the core 574 functionality of initiating a call on one side, accepting or refusing 575 it on the other, and providing progress information as well as 576 allowing termination of the call on either side. The basic call 577 control message set MUST be supported by any call control engine. 579 These messages are exchanged using unicast addressing between some 580 local controlling entity and a call control engine implementing a 581 call control or initiation protocol such as H.323 or SIP: 583 o Outgoing calls may be initiated by any local entity; the call 584 control engine has to keep track of the initiator of a 585 particular call and return all responses or events relating to 586 this call to this entity -- which may be different on a per call 587 basis. If the call control engine notices that the controlling 588 entity for a particular call has gone (e.g. because the Mbus 589 reliability mechanism indicates non-delivery of a call control 590 message or a BYE message was seen from this entity), these 591 messages are forwarded to the local controller. If no local 592 controller is available, the call SHOULD be terminated. 594 o Indications about incoming calls are always forwarded to the 595 local controller. If no local controller is present incoming 596 calls SHOULD automatically be rejected by the call control 597 engine. 599 All messages of the basic call control message set are sent reliably 600 via unicast to the call control engine. 602 In this first draft, the definition of the basic call control message 603 set is deliberately kept very much restricted: 605 o In this revision of the document, only the messages for 606 establishing a simple (point-to-point) call are specified, along 607 with very few messages dealing with supplementary services. 608 Further Mbus messages supporting supplementary services are TBD. 610 o No explicit consideration is given so far for devices other than 611 end systems -- although a simple gateway could probably be built 612 based upon the present subset. 614 The following messages are specified so far: 616 CALL 618 The CALL message is sent to the call control engine to make the 619 engine initiate a call to another endpoint using the parameters 620 specified as part of the CALL message. 622 Syntax: conf.call-control.call (ref upi address-list call-type gw- 623 proxy-list media-list status) 625 Parameters: string ref 626 A unique identifier for the call. This reference MUST be 627 used for all further interactions relating to this 628 between the call control engine and the initiating 629 entity. Every newly created call identifier MUST be 630 composed of the Mbus address of the creating entity and a 631 second entity specific part in order to ensure 632 uniqueness. 634 string upi 635 A universal personal identifier for the callee. 637 list of string address-list 638 An ordered list of transport addresses, alias names, 639 UCIs, or phone numbers -- as indicated by the prefix 640 preceding each address to be called. It is assumed that 641 all these addresses refer to the same user, and only a 642 single call will be established. The order in which the 643 addresses are specified indicates a preference and 644 contacting the target SHOULD be tried in that order. 646 symbol call-type 647 Indicates the intention of the call: join a conference 648 (or an n-way call), invite another user into a conference 649 or an n-way call, or create a new call or conference. 651 list of string gw-proxy-list 652 An ordered list of (ordered) lists identifying proxies or 653 gateways to be used for call setup if they are known. 654 The n-th element in the list is a list of alternative 655 gateways/proxies to be used in the n-th step in the call 656 setup process. The gw-proxy-list may be empty. 658 list of string media-list 659 A list of media along with the preferred capability 660 descriptions to be used for this particular call. If the 661 same media type (e.g. audio) occurs repeatedly in the 662 list (e.g. with different codecs) the relative order of 663 the media descriptions indicates a preference (e.g. of 664 one codec over the other). 666 Currently, media-list are SDP specifiations, but a new 667 general format will be specified in the next revision of 668 this draft. 670 symbol status 671 A parameter used to indicate certain attributes of a call 672 process. This list is a subset of the following list of 673 symbols: 675 +-------------------+------------------------------------+ 676 | Symbol | Description | 677 +-------------------+------------------------------------+ 678 | complete | Means that this call | 679 | | command contains all | 680 | | required information and | 681 | | that it can be processed | 682 | | immediately by a | 683 | | receiving entity. | 684 +-------------------+------------------------------------+ 685 | partial | This call command is | 686 | | part of a series of call | 687 | | commands related to a | 688 | | single call. | 689 +-------------------+------------------------------------+ 690 | final | This is the last call | 691 | | command in a series of | 692 | | call commands related to | 693 | | a single call. | 694 +-------------------+------------------------------------+ 695 Table 7: Status symbols in a conf.call-control.call command 697 The symbols complete, partial, and final SHALL be used 698 exclusively. 700 DISCONNECT 702 The DISCONNECT command is sent by the local controller to the call 703 control engine to indicate that the specified call is to be 704 disconnected. It can also be used by the local controller to inform 705 the call control engine that a call has already been terminated by 706 out-of-band communication, e.g. a horizontal conference control 707 protocol. In this case a special (yet to be defined) reason code has 708 to be passed with the command. 710 Syntax: conf.call-control.disconnect (ref reason) 712 Parameters: string ref 713 Identifies the call the DISCONNECT command refers to. 715 string reason 716 Indicates why the call was terminated. The reason will 717 be set to user-initiated if the user simply ''hung up`` 718 the phone. Other reason codes will be imported from 719 H.323 and SIP. They are to be defined. 721 RINGING 723 The RINGING message is sent by the call control engine to the entity 724 it received the corresponding CALL message from. RINGING indicates 725 that one or more addresses at the far end were contacted and are now 726 alerting the user. 728 Syntax: conf.call-control.ringing (ref (address-list)) 730 Parameters: string ref 731 Identifies the call the RINGING message refers to. 733 list of string address-list 734 An ordered list of transport addresses, alias names, 735 UCIs, or phone numbers -- as indicated by the prefix 736 preceding each address to be called. It is assumed that 737 all these addresses refer to the same user, and only a 738 single call will be established. The order in which the 739 addresses are specified indicates a preference and 740 contacting the target SHOULD be tried in that order. 742 CONNECTED 744 The CONNECTED message is sent by the call control engine to the 745 entity that initiated the call (on the calling side) and to the local 746 controller (on the called side) to indicate that the call was 747 successfully established. 749 Syntax: conf.call-control.connected (ref peer-address (media-list)) 751 Parameters: string ref 752 Identifies the call the CONNECTED message refers to. 754 string peer-address 755 Indicates the (transport/alias/UCI/etc.) address of the 756 peer endpoint (or a proxy/gateway/gatekeeper hiding its 757 actual identity) that the call was finally established 758 with. 760 list of string media-list 761 A list of media along with the capability descriptions 762 that were initially negotiated for this particular call. 764 REJECTED 766 The REJECTED message is sent by the call control engine to the entity 767 that initiated the call (on the calling side) and to the local 768 controller (on the called side) to indicate that the call was 769 rejected. 771 Syntax: conf.call-control.rejected (ref ((address reason)-list)) 773 Parameters: string ref 774 Identifies the call the REJECTED message refers to. 776 list of list of string ((address reason)-list) 777 The (address reason) pair specifies which target address 778 has rejected the call for which reason. As several 779 addresses may have been tried explicitly, a list of 780 addresses is returned, each paired with its particular 781 rejection reason and possibly associated parameters. 782 The details of the reason codes are to be defined; they 783 are to be derived from H.323 and SIP and will include 784 e.g. busy no-answer user-reject no-resources and 785 authentication-failure among many others. 787 DISCONNECTED 789 The DISCONNECTED message is sent by the call control engine to the 790 entity that initiated the call (on the calling side) and to the local 791 controller (on the called side) to indicate that the call was 792 disconnected. 794 Syntax: conf.call-control.disconnected (ref reason) 796 Parameters: string ref 797 Identifies the call the DISCONNECTED message refers to. 799 symbol reason 800 Indicates why the call was terminated. The reason will 801 be set to user-initiated if the user simply ''hung up`` 802 the phone. Other reason codes will be imported from 803 H.323 and SIP. They are to be defined. 805 INCOMING CALL 807 The INCOMING CALL messages is sent by the call control engine to the 808 local controller to indicate a call request from another endpoint. 810 Syntax: 811 conf.call-control.incoming-call (ref src-address (address-list) 812 call-type (gw-proxy-list) (media-list)) 814 Parameters: string ref 815 A unique identifier for the call. (See the notes 816 concerning unique addresses at the description of the 817 CALL command.) This reference MUST be used for all 818 further interactions relating to this between the call 819 control engine and the local controller entity. 821 string src-address 822 The address (transport address, alias name, UCI, phone 823 number, etc.) of the endpoint initiating the call. 825 list of string address-list 826 An ordered list of transport addresses, alias names, 827 UCIs, or phone numbers as sent by the calling endpoint 828 with semantics similar to the address-list in the CALL 829 message. 831 symbol call-type 832 Indicates the intention of the call; again, similar to 833 the CALL message. 835 list of string gw-proxy-list 836 An ordered list of (ordered) lists identifying proxies or 837 gateways to be used for call setup if they are known. 838 Similar to the CALL message. 840 list of string media-list 841 A list of media along with the preferred capability 842 descriptions proposed by the calling endpoint to be used 843 for this particular call. If the same media type (e.g. 844 audio) occurs repeatedly in the list (e.g. with different 845 codecs) the relative order of the media descriptions 846 indicates a preference (e.g. of one codec over the 847 other). 849 ACCEPT 851 An ACCEPT message is sent by the local controller to the call control 852 engine that has indicated an INCOMING CALL to indicate acceptance of 853 the call. 855 Syntax: conf.call-control.accept (ref (media-list)) 857 Parameters: string ref 858 Identifies the call the ACCEPT message refers to. 860 list of string media-list 861 A list of media along with the preferred capability 862 descriptions selected by the local controller. This 863 SHOULD be a strict subset of the media descriptions the 864 calling endpoint has proposed for this particular call. 866 REJECT 868 A REJECT message is sent by the local controller to the call control 869 engine that has indicated an INCOMING CALL to indicate rejection of 870 the call. 872 Syntax: conf.call-control.reject (ref reason [params]) 874 Parameters: string ref 875 Identifies the call the RINGING message refers to. 877 symbol reason 878 The reason code indicates why the call attempt was 879 refused by the callee. 880 The details of the reason codes are to be defined; they 881 are to be derived from H.323 and SIP and will include 882 e.g. busy no-answer user-reject no-resources and 883 authentication-failure among many others. 885 params Additional parameters may be provided along with the 886 reason code. TBD. 888 REDIRECT 890 The REDIRECT command is sent by the local controller to the call 891 control engine to indicate that the specified call is to be 892 redirected to another specified address. 894 Syntax: conf.call-control.redirect (ref upi address-list attr) 895 Parameters: string ref 896 Identifies the call the REDIRECT command refers to. 898 string upi 899 A universal personal identifier for the callee. 901 list of string address-list 902 List of addresses where the call should be redirected to. 904 symbol attr 905 A symbol with the value ``temporarily'' or 906 ``permanently'', signaling whether the redirection is 907 temporarily or not. 909 REDIRECTED 911 The REDIRECTED command is sent by a call control engine to the local 912 controller to indicate that the specified call has been redirected to 913 the specified address. The default semantics in this case are that 914 the call control engine can purge any state related to that call and 915 the local controller has to decide on further actions. In case the 916 redirection should be obeyed the local controller can initiate a new 917 call by sending the CALL command with the address parameter obtained 918 from the REDIRECTED command. 920 Call control engines that can decide themselves what to do after the 921 reception of a protocol specific redirection can signal this by 922 setting the status parameter to ``ACTIVE''. The semantics in this 923 case are that the call control engine performs any required protocol 924 specific action autonomously and that it will send the usual call 925 setup related commands (CONNECTED, REJECTED etc.) during the course 926 of the call setup. The local controller can terminate the call at any 927 time with a DISCONNECT command. This behaviour would have to be 928 configured by out of band means; the default behaviour is that the 929 local controller is responsible for any reaction on REDIRECTED 930 commands (signalled by setting status to PASSIVE). 932 Syntax: conf.call-control.redirected (ref upi addr-list attr 933 status) 935 Parameters: string ref 936 Identifies the call the REDIRECT command refers to. 938 string upi 939 A universal personal identifier for the callee. 941 list of string addr-list 942 Address where the call should be redirected to. 944 symbol attr 945 A symbol with the value ``temporarily'' or 946 ``permanently'', signaling whether the redirection is 947 temporarily or not. 949 symbol status 950 One of ACTIVE and PASSIVE. Used to signal whether a call 951 control engine performs the redirection iself or not. 953 FORWARD 955 The FORWARD command is sent by the local controller to the call 956 control engine to indicate that the specified incoming call is to be 957 forwarded to another (optionally specified) address. The second 958 parameter is a list of strings that are to be interpreted as 959 addresses. This list can be empty. The presence of elements in the 960 address list denotes that the call control engine should use the 961 specified address instead of determining it independently. If no 962 addresses are provided the call control engine is requested to 963 determine an address independently. 965 The FORWARD command can be used instead of REDIRECT when the end 966 system acts as a application layer proxy that decides which calls are 967 allowed to be forwarded. The forwarding can either happen with the 968 call control protocol's implicit semantics (e.g. SIP forwarding) or 969 the controller can explicitely specify the forwarding address. 971 The call control engine will send CONNECTED or REJECTED responses to 972 inform the local controller of the result of the forwarding process. 974 Syntax: conf.call-control.forward (ref addr-list) 976 Parameters: string ref 977 Identifies the call the FORWARD command refers to. 979 list of string addr-list 980 List of (optional) address specifying where the call 981 should be forwarded to. 983 FORWARDED 985 The FORWARDED command is sent by the call control engine to the local 986 controller to indicate that the specified call has been forwarded to 987 the specified address. The local controller can decide whether the 988 call setup should continue or be interrupted (by sending a DISCONNECT 989 command). 991 Syntax: conf.call-control.forwarded (ref addr-list) 993 Parameters: string ref 994 Identifies the call the FORWARD command refers to. 996 list of string addr-list 997 List of (optional) address specifying where the call has 998 been forwarded to. 1000 RELAYED 1002 The RELAYED command is sent by the local controller to the call 1003 control engine to indicate that the specified incoming call is being 1004 forwarded to the specified address via another call control engine 1005 (e.g. from another protocol of administrative domain). 1007 One scenario would be a incoming call that has been signalled by a 1008 SIP call control engine with a INCOMING-CALL command and that is then 1009 relayed to the H.323 call control engine. The local controller would 1010 inform the SIP engine by sending the RELAYED command. 1012 A notation for address specifications (h323:bla) needs to be defined. 1014 Syntax: conf.call-control.relayed (ref addr) 1016 Parameters: string ref 1017 Identifies the call this command refers to. 1019 string addr-list 1020 The address specifying where the call has been relayed 1021 to. 1023 Further messages deemed necessary for the basic call control message 1024 set include the following 1026 o PROGRESS 1028 The details of these as well as further messages are to be defined. 1030 4.4.2. Running a conference 1032 Floor control, chairperson, policy, membership lists, etc. 1034 4.4.2.1. Floor control 1036 owner 1038 Syntax: conf.floor.owner (cname) 1040 Parameters: cname 1041 The cname parameter designates the participant who the 1042 floor is currently assigned to. 1044 need 1046 Syntax: conf.floor.need () 1048 Parameters: -- 1049 Used to indicate that an application entity is requesting 1050 the floor for its media session. 1052 release 1054 Syntax: conf.floor.release () 1056 Parameters: -- 1057 Used to indicate that an application entity is releasing 1058 the floor it formerly requested for its media session. 1060 4.4.2.2. Membership Lists 1062 Commands starting with conf.member are intented for general messages 1063 on membership information that are not bound to specific transport 1064 protocols such as RTP[4]. 1066 Syntax: conf.member.list ([cname]*) 1068 Parameters: cname 1069 The cname parameter designates the current list of 1070 members. 1072 Syntax: conf.member.add (cname) 1074 Parameters: cname 1075 The cname parameter designates a member that has joined 1076 the session. 1078 Syntax: conf.member.remove (cname) 1080 Parameters: cname 1081 The cname parameter designates a member that has left the 1082 session. 1084 4.4.2.3. Conference Chairs 1086 Syntax: conf.chair (cname) 1087 Parameters: cname 1088 The cname parameter designates the current conference 1089 chair. 1091 4.5. Status commands 1093 The following table lists a few commands for generic status and error 1094 reports: 1096 +-------------+------------------------------+ 1097 |Command | Description of command class | 1098 +-------------+------------------------------+ 1099 |status.error | Error messages | 1100 |status.warn | Warnings | 1101 |status.info | Informational messages | 1102 +-------------+------------------------------+ 1103 Table 8: Mbus Status commands 1105 All status commands MUST be used with at least one string parameter 1106 that contains information on the status reported. Status commands MAY 1107 be used with arbitrary command prefixes. This allows classification 1108 of status commands where appropriate. E.G. status commands that are 1109 related to call-control MAY be prefixed with conf.call-control 1110 allowing an receiving entity to treat the command as a call-control 1111 specific status command. By convention status commands may have 1112 additional application specific parameters that are only useful if 1113 the concrete application context is known from the command prefix. 1115 All status messages SHOULD be sent unreliably to all entities. 1117 5. Authors' Addresses 1119 Joerg Ott 1120 Universitaet Bremen, TZI, MZH 5180 1121 Bibliothekstr. 1 1122 D-28359 Bremen 1123 Germany 1124 voice +49 421 201-7028 1125 fax +49 421 218-7000 1127 Colin Perkins 1128 Department of Computer Science 1129 University College London 1130 Gower Street 1131 London WC1E 6BT 1132 United Kingdom 1133 Dirk Kutscher 1134 Universitaet Bremen, TZI, MZH 5160 1135 Bibliothekstr. 1 1136 D-28359 Bremen 1137 Germany 1138 voice +49 421 218-7595 1139 fax +49 421 218-7000 1141 6. References 1143 [1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 1144 Levels'' RFC 2119, March 1997 1146 [2] J. Ott, C. Perkins, and D. Kutscher, ``Requirements for Local 1147 Conference Control'', Internet Draft draft-ott-mmusic-mbus- 1148 req-00.txt, Work in Progress, June 1999. 1150 [3] J. Ott, C. Perkins, and D. Kutscher, ``A Message Bus for 1151 Conferencing Systems'', Internet Draft draf-ott-mmusic-mbus- 1152 transport-00.txt, Work in Progress, June 1999. 1154 [4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A 1155 Transport Protocol for Real-Time Applications,'' RFC 1889, 1156 January 1996. 1158 Appendix A: RTP specific commands 1160 The following commands are used to provide information about an 1161 RTP[4] media source. Each source in media sessions is identified by 1162 its SSRC (not by the CNAME, since this would not be unique). 1163 Correlation to CNAMEs for cross-media references (eg: for lip- 1164 synchronization) has to be done by receiving entities. 1166 rtp.ssrc (ssrc) 1167 Sent to inform an entity of the SSRC it is to use for the 1168 remainder of the session. 1170 rtp.source.exists (ssrc validityTime) 1171 The rtp.source.exists command is sent by a media engine to 1172 assert that a particular source is present in a session. The 1173 validityTime parameter is the time for which that source should 1174 be considered valid, in seconds. If another rtp.source.exists 1175 command has not been received for that source within this time 1176 period, the source is implicitly timed out. The validityTime 1177 SHOULD be three times the RTCP reporting interval for that 1178 session. 1180 rtp.source.remove (ssrc) 1181 The rtp.source.remove command is used to indicate that a source 1182 has left the session. 1184 rtp.source.name (ssrc name) 1185 rtp.source.email (ssrc email) 1186 rtp.source.phone (ssrc phone) 1187 rtp.source.loc (ssrc loc) 1188 rtp.source.tool (ssrc tool) 1189 rtp.source.note (ssrc note) 1190 rtp.source.cname (ssrc cname) 1192 These commands are used to pass RTCP SDES information from a 1193 media engine to a user interface. If sent to a media engine, 1194 they have no effect unless the ssrc field is the SSRC of that 1195 engine, in which case the are used to change the SDES 1196 information being transmitted by that media engine. 1198 rtp.source.reception (ssrc packetsRecv packetsLost packetsMisordered 1199 jitter validityTime) 1200 This command is used to pass RTCP RR information from a media 1201 engine to a user interface. The total number of packets 1202 received, lost and misordered are sent, together with the 1203 network timing jitter in milliseconds and a validity time for 1204 this report in seconds. 1206 rtp.source.packet.loss (dest_ssrc src_ssrc loss% validityTime) 1207 Sent by a media engine to indicate the instantaneous packet loss 1208 observed between two sources. The validityTime for this report 1209 is in milliseconds. 1211 rtp.source.active (ssrc validityTime) 1212 rtp.source.inactive (ssrc) 1214 The rtp.source.active command indicates that a source is 1215 transmitting data into the session. The validityTime field 1216 indicates the period for which this source should be considered 1217 active, in milliseconds. The source.inactive command indicates 1218 that the source has stopped transmitting. 1220 rtp.source.mute (ssrc muteState) 1221 The rtp.source.mute command indicates that a source is to be 1222 muted/ unmuted. The value of the muteState parameter is 0 to 1223 indicate unmuted, and 1 to indicate muted. 1225 rtp.source.packet.duration (ssrc packetDuration) 1226 Sent by a media engine to indicate the duration, in 1227 milliseconds, of packets received from a source. This may be 1228 used to control the duration of packets sent by a media engine, 1229 if sent to that engine with the cname of the engine. 1231 rtp.source.codec (ssrc codec) 1232 Sent by a media engine to indicate the codec in use by a source. 1234 rtp.source.playout (ssrc playoutDelay) 1235 Sent by a media engine to indicate the playout delay, in 1236 milliseconds, for a source (that is, end-to-end time from 1237 capture to playout). This allows for lip-synchronization 1238 between audio and video streams. 1240 Appendix B: Media Engine Control Commands -- Audio 1242 The following commands are used to control the playout of data by the 1243 media engine. If sent to a media engine they change output settings, 1244 if sent by a media engine they inform other entities of the state of 1245 the output. 1247 It is expected that a similar set of commands will be defined to 1248 control the operation of other media engines (eg: video, shared- 1249 workspace). 1251 audio.output.gain (gain) 1252 Select gain (volume) of the output device. 1254 audio.output.port (port) 1255 Select port to be used. The allowable values for the port are 1256 ``speaker'', ``line'' and ``headset''. 1258 audio.output.mute (muteState) 1259 Mute (if muteState is 1) or unute (if muteState is 0) the 1260 output. 1262 audio.output.powermeter (level%) 1263 Sent from media engine to user interface to control display of 1264 audio power meters. Level is specified as a percentage. 1266 audio.output.agc (state) 1267 Enable/disable automatic gain control for output. state is 1 to 1268 enable, 0 to disable. 1270 audio.output.synchronize (state entity) 1271 Enable synchronization with the Mbus entity specified. This uses 1272 the rtp.source.playout messages to achieve synchronization (eg: 1273 lip-sync between audio and video). The value of state is 0 to 1274 disable synchronization, 1 to enable. Note that this option may 1275 conflict with the audio.output.playout.delay.* commands. 1277 audio.input.gain (gain) 1278 audio.input.port (port) 1279 audio.input.mute (muteState) 1280 audio.input.powermeter (level) 1281 audio.input.agc (agcState) 1283 These commands function in a manner analogous to the 1284 audio.output.* commands, but affect input of data by the media 1285 engine. 1287 audio.codec.describe (codec name clock-rate channels) 1288 Describe a codec. The codec parameter is an opaque codec 1289 identifier. The name parameter provides a human readable 1290 description of the codec, clock-rate and channels are self 1291 explanatory. 1293 For an RTP-based media tool, the codec parameter will be an RTP 1294 payload type number. 1296 audio.codec.supported.tx (codec ...) 1297 audio.codec.supported.rx (codec ...) 1299 Indicates that the specified codec(s) are supported by this 1300 media engine. This list includes basic codecs only, repair 1301 schemes such as redundancy, FEC and interleaving are not 1302 included in the response. 1304 The audio.codec.supported.tx indicates codecs which this media 1305 engine can transmit. The audio.codec.supported.rx indicates 1306 codecs which are supported for reception. 1308 audio.codec.supported.tx.request 1309 audio.codec.supported.rx.request 1311 Request that the recipient responds with a codec.supported 1312 message. 1314 audio.codec (codec) 1315 If sent to a media engine, select the codec to be used when 1316 transmitting. If sent by a media engine, indicates the codec 1317 being used when transmitting. 1319 audio.suppress.silence (state) 1320 Enable/disable silence suppression on the input signal. State is 1321 1 to enable, 0 to disable. 1323 audio.channel.coding (coding parameters ...) 1324 Indicate the channel coding scheme to be used. The following 1325 values are currently defined for coding 1327 none - No special channel coding. 1329 redundant - RFC2198 redundancy 1331 interleaved - Interleaving. 1333 Others may be defined in future. 1335 The parameters section is specific to a particular encoding. For 1336 redundant coding, parameters are a series of codec, offset 1337 pairs. For interleaved coding, the number of blocks and block 1338 separation are parameters. 1340 audio.channel.repair (repair-scheme) 1341 Indicate the loss-repair scheme to be used at the receiver. The 1342 following repair schemes are currently defined: 1344 - repetition 1346 - pattern-match 1348 Others may be defined in future. 1350 Appendix C: Security commands 1352 security.encryption.algorithm (algorithm) 1353 security.encryption.key (key) 1355 Specify the encryption algorithm and key to be used. The 1356 algorithm defaults to ``DES'' if not specified. 1358 security.encryption (state) 1359 Enable/disable encryption. Enable if state is 1, disable if 1360 state is 0. A security.encryption.key command MUST be sent 1361 before this command. 1363 Appendix D: Tool configuration 1365 IETF conferencing tools so far make use of a variety of to some 1366 degree standardized command line options, including (but not limited 1367 to) the following: 1369 tool -C conference -N name ... mc-addr/port/ttl 1371 In order to accommodate the aforementioned boot phase procedures, the 1372 following parameters with the associated behavior are needed: 1374 -wait [condition]Wait for a particular event to happen; if no 1375 condition is specified on the command line, an 1376 internally pre-defined condition is used. The 1377 application entity is supposed to start emitting 1378 self-announcements to the Mbus but should defer any 1379 further action (with respect to self-configuration 1380 and media exchange) until the condition is met. 1382 Besides waiting for the indicated condition to occur, 1383 an application entity is required to react to Mbus 1384 configuration requests directed to it, since their 1385 execution may be a prerequisite for it eventually 1386 receiving the ``GO'' message. 1388 -nowait Start immediately. 1390 Examples 1392 rat Start and go ahead with whatever you want to do. 1394 rat -wait ... Takes default condition: Wait for the own user 1395 interface to show up and configure the engine. 1397 rat -wait controllerWait for a local conference controller to show up 1398 and make the application continue.