idnits 2.17.1 draft-ietf-mmusic-mbus-call-control-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: ---------------------------------------------------------------------------- ** 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. == 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 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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There is 44 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 454: '...very newly created call reference MUST...' RFC 2119 keyword, line 464: '... general URI syntax) MUST be used:...' RFC 2119 keyword, line 472: '...art of an address URI MUST contain the...' RFC 2119 keyword, line 514: '... list for media settings for the call. SDP[9] or SDP-ng[10] SHOULD...' RFC 2119 keyword, line 519: '... description types SHOULD be used:...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 23, 2001) is 8463 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) == Unused Reference: '5' is defined on line 1410, but no explicit reference was found in the text -- No information found for draft-ietf-mmusic-mbus - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-09) exists of draft-ietf-sip-rfc2543bis-02 -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2327 (ref. '9') (Obsoleted by RFC 4566) == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sdpng-req-00 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ott 3 Internet-Draft Kutscher 4 Expires: August 24, 2001 Meyer 5 TZI, Universitaet Bremen 6 February 23, 2001 8 An Mbus Profile for Call Control 9 draft-ietf-mmusic-mbus-call-control-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To view the entire list of Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 24, 2001. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 This document defines an Mbus application profile for call control 38 services. This application profiles is designed to provide the most 39 common basic services of call signaling protocols like SIP[3], 40 H.323/Q.931[4] related to call setup and tear down but also defines 41 a set of optional Mbus commands for supplementary services. The 42 targeted applications include gateway and endpoint decomposition and 43 remote controlling of call signaling engines. 45 The underlying message passing and addressing mechanisms for the 46 Mbus is defined in the Mbus transport specification[1]. 48 This document is a contribution to the Multiparty Multimedia Session 49 Control (MMUSIC) working group of the Internet Engineering Task 50 Force. Comments are solicited and should be addressed to the 51 working group's mailing list at confctrl@isi.edu and/or the authors. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2 Scope of this Document . . . . . . . . . . . . . . . . . . . 4 58 2. The Call-Control Model . . . . . . . . . . . . . . . . . . . 5 59 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3 Basic Services . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3.1 Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.3.2 Call Redirection . . . . . . . . . . . . . . . . . . . . . . 10 64 2.3.3 Call Forwarding/Proxying . . . . . . . . . . . . . . . . . . 10 65 2.3.4 Call Rejection . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.4 Supplementary Services . . . . . . . . . . . . . . . . . . . 11 67 3. The Mbus Call-Control Profile . . . . . . . . . . . . . . . 12 68 3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.1.1 Mbus Parameter Type Definitions . . . . . . . . . . . . . . 12 70 3.1.2 Mbus Addressing Scheme . . . . . . . . . . . . . . . . . . . 14 71 3.1.3 Mbus Control Relation Class . . . . . . . . . . . . . . . . 14 72 3.2 Mbus Commands . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.3 conf.call-control.accept . . . . . . . . . . . . . . . . . . 15 74 3.4 conf.call-control.accepted . . . . . . . . . . . . . . . . . 16 75 3.5 conf.call-control.call . . . . . . . . . . . . . . . . . . . 16 76 3.6 conf.call-control.cancel . . . . . . . . . . . . . . . . . . 19 77 3.7 conf.call-control.cancelled . . . . . . . . . . . . . . . . 19 78 3.8 conf.call-control.connect . . . . . . . . . . . . . . . . . 20 79 3.9 conf.call-control.connected . . . . . . . . . . . . . . . . 20 80 3.10 conf.call-control.incoming-call . . . . . . . . . . . . . . 21 81 3.11 conf.call-control.proceed . . . . . . . . . . . . . . . . . 22 82 3.12 conf.call-control.proceeding . . . . . . . . . . . . . . . . 23 83 3.13 conf.call-control.redirect . . . . . . . . . . . . . . . . . 23 84 3.14 conf.call-control.redirected . . . . . . . . . . . . . . . . 24 85 3.15 conf.call-control.reject . . . . . . . . . . . . . . . . . . 25 86 3.16 conf.call-control.rejected . . . . . . . . . . . . . . . . . 26 87 3.17 conf.call-control.ring . . . . . . . . . . . . . . . . . . . 26 88 3.18 conf.call-control.ringing . . . . . . . . . . . . . . . . . 27 89 4. Asynchronous Status Signaling . . . . . . . . . . . . . . . 28 90 5. Supplementary Services . . . . . . . . . . . . . . . . . . . 29 91 5.1 conf.call-control.hold . . . . . . . . . . . . . . . . . . . 29 92 5.2 conf.call-control.on-hold . . . . . . . . . . . . . . . . . 29 93 5.3 conf.call-control.retrieve . . . . . . . . . . . . . . . . . 30 94 5.4 conf.call-control.retrieved . . . . . . . . . . . . . . . . 30 95 5.5 conf.call-control.transfer . . . . . . . . . . . . . . . . . 31 96 5.6 conf.call-control.transfered . . . . . . . . . . . . . . . . 31 97 References . . . . . . . . . . . . . . . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 99 A. SIP Call Flow Example . . . . . . . . . . . . . . . . . . . 35 100 B. H.323 Call Flow Example . . . . . . . . . . . . . . . . . . 36 101 Full Copyright Statement . . . . . . . . . . . . . . . . . . 37 103 1. Introduction 105 1.1 Background 107 The Mbus transport specification[1] defines the transport mechanisms 108 of the Message Bus (Mbus), a local coordination infrastructure that 109 allows message passing between a group of application components. 111 The Mbus guidelines[2] define a list of conventions for terminology, 112 algorithms and procedures for higher level interaction models that 113 are useful for applications using the Mbus. These conventions are 114 intended as guidelines for designers of Mbus application profiles 115 and Mbus implementations/applications. 117 This document builds on these two specifications and provides an 118 Mbus application profile for call control services that uses the 119 conventions codified in the Mbus guidelines[2] to specify an Mbus 120 application profile, i.e., a list of Mbus commands and procedures 121 that allow to implement call-control applications. 123 1.2 Scope of this Document 125 This document defines a command set and corresponding interactions 126 between application components for basic call control services, such 127 as call setup, call termination. The set of basic call control 128 commands also includes commands for redirecting or forwarding 129 (proxying) call setup requests. 131 The set of basic call control commands is supplemented by a set of 132 additional commands for supplementary services, such as call hold 133 and call transfer. 135 In a future version, this document will also specify commands that 136 allow to implement multiparty conferencing. 138 2. The Call-Control Model 140 2.1 Overview 142 The model that this specification is based on is that of a 143 decomposed conferencing system, such as a terminal or gateway. In 144 such a system, there exists a call control engine, for example, a 145 SIP engine, that implements a call signaling protocol, in this case 146 SIP. This call control engine provides the functionality to 147 initiate, manage and terminate call control relations to other 148 endpoints (or gateways). 150 The call control engine can be viewed as an application component, 151 i.e., it offers certain services to other components that can make 152 use of the call control component and control the call signaling 153 processes. As an application component it is probably designed to be 154 reusable in different application scenarios. 156 A separate controlling component, termed "controller" in the 157 following sections, implements the application logic and controls 158 one (or more) call control engines using the Mbus commands specified 159 in this document. 161 The figure below (Figure 1) shows an example of the relation between 162 a controller and a call control engine in an Mbus enables 163 conferencing system. 165 +---------- Mbus ----------+ 166 | | 167 | +---------------+ | 168 | | | | 169 | | controller | | 170 | | | | 171 | +---------------+ | 172 | | | 173 | | | 174 | +---------------+ | +---------------+ 175 | | call | | SIP | call | 176 | | control |==================| control | 177 | | engine | | | engine | 178 | +---------------+ | +---------------+ 179 | | 180 +--------------------------+ 182 The scope of this document is the specification of the communication 183 mechanisms between a controller and a call control engine within an 184 Mbus domain, based on the transport mechanisms specified in the Mbus 185 transport specification[1] and based on the interaction schemes 186 defined in the Mbus guidelines[2]. 188 In order to accommodate other call signaling protocols besides SIP, 189 the interactions that are defined here provide a sufficient level of 190 abstraction from concrete call control protocols. This abstraction 191 implies that not every feature of every call control can be 192 provided. The trade-off between generality and 193 functionality/specificity results in a call-control model that 195 o supports basic, common call control services; 197 o uses universal addressing schemes for callee addresses and other 198 parameters; 200 o provides hooks for call control protocol specific extensions, 201 such as optional parameters; and 203 o separates advanced functionality, such as supplementary services, 204 out into an optional module. 206 The generality provided should allow for building generic 207 controllers relying on this call-control model that can control call 208 control engine from different protocol domains without having to 209 care about the call control specific details. For an architecture 210 like the one depicted in the figure above (Figure 1) this would 211 allow to replace the SIP call control engine by a H.323 engine 212 without having to change the the implementation of the controller. 214 2.2 Concepts 216 This section describes a set of concepts, abstractions and 217 identifiers that are used by the presented call control model. This 218 includes: 220 identification of calls; 222 addressing concept for participants and endpoints; and 224 call state manipulation. 226 Controlling a call control engine by a controller uses the notion of 227 "a call", which is an abstraction that represents the state of a 228 call control relation that is setup, modified and terminated by 229 means of message exchange between a controller and a call control 230 engine. In order to disambiguate multiple calls that are managed by 231 a system, call identifiers are employed. 233 Different types of identifiers are used: 235 Call Identifier: A call identifier is used to identify calls 236 uniquely. In this model, "a call" represents a call control 237 relation between two endpoints. If an endpoint has call control 238 relation to two other endpoints at the same time, two different 239 call identifiers will be used to disambiguate the call states. 240 The concept of a globally unique call identifier is prevalent in 241 most call signaling protocols as well. For the Mbus call control 242 commands, the call identifiers are generated by the call control 243 engine and are considered opaque values by other components, 244 e.g., a controller. The appearance of the call identifier depends 245 on the call signaling protocoll. See H.225.0[6] and SIP for 246 details. 248 Call Leg Identifier: Call leg identifiers allow for a more fine 249 grained control of call control relations. A call control engine 250 may try to setup more than one outgoing call at a time in order 251 to establish a call control relation to a participant, e.g., when 252 the call control engine is a component in a forking proxy system. 253 In order to disambiguate the different call legs that are created 254 for a single call, the notion of call leg identifiers is 255 introduced. 257 Conference Identifier: While a call identifier is used to identify 258 individual call control relations there are also more persistent 259 states, e.g., multi-party conferences. In some models, 260 multi-party conferences can be implemented by creating a full 261 mesh of calls between all participants. The individual calls 262 would then disambiguated with call identifiers while the 263 conference itself is identified by a "conference identifier". In 264 this specification, this identifier is also used to implement 265 call transfer. The transfer of a call is implemented by having 266 the transferor initiate a new call to the transferred-to party, 267 which result in a new call with a new call identifier. In order 268 to be able to identify and track the call it is assigned a 269 persistent conference identifier. 271 2.3 Basic Services 273 The provided basic services are: 275 Call setup: A controller can make a call control engine initiate a 276 new call using its native call signaling protocol. The call 277 control engine will notify the controller of progress events, 278 e.g., when the called party accepts the call. For a called 279 endpoint, the call control engine will signal incoming call 280 events it received via its native call signaling protocol, 281 enabling the controller to react and eventually control the 282 completion of the call setup by accepting the call. See Section 283 2.3.1 for a detailed discussion of call setup procedures. 285 Call redirection: After an incoming call has been signaled by the 286 call control engine, the controller can request the call control 287 engine to redirect the call to another endpoint. See Section 288 2.3.2 for a detailed discussion of call redirection procedures. 290 Call forwarding/proxying: After an incoming call has been signaled 291 by the call control engine, the controller can request the call 292 control engine to proxy the call to another endpoint. See Section 293 2.3.3 for a detailed discussion of call forwarding procedures. 295 Call canceling/rejection: Outgoing and incoming calls can be 296 rejected and cancelled by the controller at any time. See Section 297 2.3.4 for a detailed discussion of call rejection procedures. 299 2.3.1 Call Setup 301 The figure below (Figure 2) provides a schematic visualization of 302 the Mbus communication for setting up and terminating a call. "CS" 303 represents the call signaling protocol. Please refer to Appendix A 304 and to Appendix B for examples that show the mapping of call control 305 specific PDUs to the Mbus commands. 307 Caller (A) Callee (B) 309 Controller Call Control Call Control Controller 310 Engine Engine 312 | call | | | 313 | ----------------> | | incoming-call | 314 | | | ----------------> | 315 | | | proceed | 316 | proceeding | CS | <---------------- | 317 | <---------------- | | | 318 | | <--> | ring | 319 | ringing | | <---------------- | 320 | <---------------- | | | 321 | | | accept | 322 | accepted | | <---------------- | 323 | <---------------- | | | 324 | connect | | | 325 | ----------------> | | | 326 | connected | | connected | 327 | <---------------- | | ----------------> | 328 | | | | 330 | cancel | | | 331 | ----------------> | | | 332 | cancelled | | cancelled | 333 | <---------------- | | ----------------> | 334 | | | | 336 The figure above (Figure 2) shows the message flow for a calling 337 party A as well as for a called party B . A's controller initiates 338 the call setup with a "call" message sent to the call control 339 engine. The call control engine would subsequently setup a call 340 using its native call signaling protocol (not shown here in detail). 341 The most important parameters of the "call" message are the address 342 of the callee and a media/capability description to be used for the 343 call. 345 In case a call control relation with the callee can be established, 346 A's call control engine will notify the controller of call progress 347 indications it received via its call signaling protocol. When B has 348 accepted the call, A's call control engine will notify the 349 controller with a "accepted" message, which must be acknowledged by 350 sending a connect message back to the call control engine. In 351 essence, this mimics a three-way-handshake model, that allows some 352 basic form of call parameters negotiation, as employed by, e.g., 353 SIP[3]. For this purpose, both the "call" and the "accepted" message 354 can be parameterized with media/capability descriptions. 356 In this example, the call is terminated by A's controller's sending 357 of a "cancel" message to its call control engine, which subsequently 358 terminates the call control relation to B. Both A's and B's call 359 control engine notify their controllers with a "cancelled" message. 360 A "cancel" message can be sent at any stage of a call setup phase in 361 order to terminate the call and cancel the call control relation. 363 2.3.2 Call Redirection 365 The figure below (Figure 3) provides a schematic visualization of 366 the Mbus communication for redirecting an incoming call. "CS" 367 represents the call signaling protocol. 369 Caller (A) Callee (B) 371 Controller Call Control Call Control Controller 372 Engine Engine 374 | call | | | 375 | ----------------> | | incoming-call | 376 | | | ----------------> | 377 | | | redirect | 378 | redirected | CS | <---------------- | 379 | <---------------- | | | 380 | | <--> | | 382 In this example, B's controller decides to redirect the incoming 383 call instead of accepting it. The "redirect" message is 384 parameterized with the address of an alternative contact for the 385 originally called party. This information is transported via the 386 native signaling protocol and reported by A's call control engine to 387 its controller using the "redirected" message. 389 In order to contact the party that A has been redirected to A's 390 controller would have to setup a new call using the "call" message. 392 2.3.3 Call Forwarding/Proxying 394 Call forwarding/proxying is a functionality used for implementing 395 application layer gateways, e.g., proxy servers. 397 Details TBD 399 2.3.4 Call Rejection 401 The figure below (Figure 4) provides a schematic visualization of 402 the Mbus communication for rejecting an incoming call. "CS" 403 represents the call signaling protocol. 405 Caller (A) Callee (B) 407 Controller Call Control Call Control Controller 408 Engine Engine 410 | call | | | 411 | ----------------> | | incoming-call | 412 | | | ----------------> | 413 | | | reject | 414 | rejected | CS | <---------------- | 415 | <---------------- | | | 416 | | <--> | | 418 In this example, B's controller decides to reject the incoming call 419 instead of accepting it. The "reject" message is parameterized with 420 a reason code. This information is transported via the native 421 signaling protocol and reported by A's call control engine to its 422 controller using the "rejected" message. 424 2.4 Supplementary Services 426 The provided supplementary services are: 428 Call hold: 430 Call transfer: 432 Call waiting: 434 3. The Mbus Call-Control Profile 436 3.1 General 438 This section defines how the call control model described in Section 439 2 is implemented as an Mbus application profile using the mechanisms 440 defined in the Mbus guidelines[2]. We define Mbus commands that 441 provide the call control services and define the structure and 442 semantics of parameters. 444 3.1.1 Mbus Parameter Type Definitions 446 Some commonly used parameter types: 448 Call reference: In most of the Mbus commands specified below a call 449 reference is used to identify calls. Call control engines can map 450 the call reference to call identifies of their call signaling 451 protocol. The Mbus parameter data type for call references is 452 String and abbreviated as "call-ref" in the specification below. 453 References are created by call (Section 3.5) or incoming-call 454 (Section 3.10) commands. Every newly created call reference MUST 455 be composed of the Mbus address of the creating entity and a 456 second entity specific part in order to ensure uniqueness. 458 Address: Some commands require the specification of an address (or 459 address list) for users. These addresses are self-contained URIs, 460 that allow to identify the call control protocol domain and the 461 call control domain specific information that is required to 462 setup a call control relation to the specified user. One of 463 following scheme identifiers (see [7] for the definition of the 464 general URI syntax) MUST be used: 466 sip: for SIP URIs 468 h323: for H.323 URIs 470 tel: for telephone call URIs as specified in [8] 472 The scheme specific part of an address URI MUST contain the 473 protocol specific information that is needed to establish a 474 call control relation. 476 The Mbus parameter type for an address is called "address" in the 477 specification below. The Mbus type for "address" is String. 478 Address parameters are used in requests to call control engines, 479 that should be able to translate them into native addresses of 480 their corresponding call signaling protocol. 482 Address list: For some commands, more than one address needs to 483 passed as a parameter. The type "address-list" is defined as a 484 "list of address" and is used as a parameter type for requests 485 where more than address can be specified. 487 Logical address: A logical address is an informational address that 488 denominates the user that a caller is trying to call. The logical 489 address is not necessarily identical to the address URI described 490 above. For example, in a SIP-INVITE request the Request-URI may 491 be "sip:123434565@big-company.foo" (which may have been obtained 492 from a location server), whereas the logical address is 493 "sip:support@big-company.foo" (in SIP, this could be the content 494 of a To header field). As the To header field in SIP, the logical 495 address can be augmented by a "display name", that can be 496 presented to a user by a user agent. As an Mbus parameter, the 497 logical address is therefore represented as a list of two 498 elements (both of type string), where the first element is the 499 display name and the second element is the address URI. In the 500 command specification below the type for logical address 501 parameters is called "logical-address". 503 Status codes: Some of the commands defined below can be 504 parameterized with status codes and reason descriptions that 505 represent error conditions (or other status information). On the 506 Mbus, this information is represented as a list of two strings, 507 where the first element is a numerical status code code and the 508 second element is a textual description. In the command 509 specification below the type for status information parameters is 510 called "status". The details of the status codes are to be 511 defined; they are to be derived from H.323 and SIP. 513 Media: Some commands have a media parameter list and/or a capability 514 list for media settings for the call. SDP[9] or SDP-ng[10] SHOULD 515 be used for describing session parameters and capabilities. The 516 Mbus parameter type "media" is a pair of (Symbol, Data) where the 517 first element identifies the type of the description language and 518 the second element is the actual description. The following 519 description types SHOULD be used: 521 * SDP 523 * SDP-ng 525 In order to allow for expressing preferences with SDP, some 526 commands use a list of media for media description parameters. In 527 these lists, the order of the media elements (each of which 528 represents a stand alone SDP description) define their relative 529 preference. 531 Overview of the parameter data types: 533 +----------------+-----------------------+--------------------+ 534 |Type name | Mbus type definition | Description | 535 +----------------+-----------------------+--------------------+ 536 |call-ref | string | Call Reference | 537 |address | string | Address URI | 538 |address-list | list of address | List of URIs | 539 |logical-address | pair of string | Logical Address | 540 |status | pair of string | Status Information | 541 |media | pair of (symbol,data) | Media Information | 542 +----------------+-----------------------+--------------------+ 544 In the command specification below the type names are used to 545 specify parameter lists. 547 3.1.2 Mbus Addressing Scheme 549 The following Mbus address fields SHOULD be used by implementations 550 of the call control commands: 552 function: Describes the general function of the component. 553 The value SHOULD be fixed to "call-control" for both, controller 554 and call control engine. 556 cc-module: Describes the type of the component. 557 Possible values: 559 controller: The component is a controller. 561 engine: The component is a call control engine. 563 A sample Mbus address for a controller could look like this: 565 (function:call-control cc-module:controller id:123-4@192.168.1.1) 567 A sample Mbus address for a call control engine could look like 568 this: 570 (function:call-control cc-module:engine id:124-4@192.168.1.1) 572 3.1.3 Mbus Control Relation Class 574 The Mbus guidelines[2] specify different control classes for 575 applications consisting of modules with controller/controllee 576 relations. 578 Implementations of the call control profile SHOULD implement the 579 control class "tight control", which means, that a controllee (a 580 control engine) can only be controlled by one controller at a time. 582 A controller MUST therefore take over the control of a call control 583 engine -- using the mbus.register command [2] -- before it can send 584 commands to a call control engine. The command prefix for the call 585 control commands is "conf.call-control". This means, a controller 586 MUST register itself for the "conf.call-control" hierarchy. See 587 Section 3.2 for the default target address that SHOULD be used for 588 event notifications by call control engines that are not yet 589 controlled. 591 3.2 Mbus Commands 593 The following Mbus commands can be divided into two classes: 595 RPCs 597 Event notifications 599 RPCs are sent from a controller to a call control engine. All RPCs 600 MUST be supported by call control engines, i.e., they MUST be able 601 to receive and understand them. Where possible, the imperative form 602 has been chosen for RPC command names, e.g., "call" and "cancel". 604 Event notifications are sent from a call control engine to a 605 controller. All event notifications MUST be supported by 606 controllers, i.e., they MUST be able to receive and understand them. 607 Where possible, the past (or present) participle form has been 608 chosen for names of event notification commands, e.g., "connected" 609 and "proceeding". 611 The default target address (see the Mbus guidelines[2] for a 612 definition of default target address) is 614 (function:call-control) 616 3.3 conf.call-control.accept 618 conf.call-control.accept 619 RPC 621 Parameters: 623 REF: call-ref 624 Identifies the call the command refers to. 626 MEDIA-LIST: list of media 627 A list of media types along with the preferred capability 628 descriptions selected by the local controller. This SHOULD be 629 a strict subset of the media descriptions the calling endpoint 630 has proposed for this particular call. 632 Optional Parameters: none 634 Return parameters: none 636 The following application specific result states are defined: 638 OK: The parameters are valid and the accept has been sent. 640 INVALID_REF: The reference is invalid 642 INVALID_PARAMETER: One or more parameters are invalid. The error 643 description SHOULD provide more detailed information. 645 An ACCEPT message is sent by the local controller to the call 646 control engine that has indicated an INCOMING CALL (Section 3.10) to 647 indicate acceptance of the call. 649 3.4 conf.call-control.accepted 651 conf.call-control.accepted 652 EVENT NOTIFICATION 653 default target address: (function:call-control) 655 Parameters: 657 REF: call-ref 658 Identifies the call the command refers to. 660 Optional Parameters: 662 LEG: integer 663 Identifies the leg the command refers to. 665 The ACCEPTED message is sent by the callers call control engine to 666 the local controller to indicate that the party has accepted the 667 call. 669 3.5 conf.call-control.call 671 conf.call-control.call 672 RPC 674 Parameters: 676 REF: call-ref 677 A unique identifier for the call. This reference MUST be used 678 for all further interactions relating to this between the call 679 control engine and the initiating entity. Call references 680 SHOULD be constructed considering the rules specified in 681 Section 3.1.1. 683 CALLER-INFO-LIST: list of string 684 A list containing caller information that the call control 685 engine should use for this call. The first parameter is the 686 caller's logical address, the second parameter a protocol 687 specific source address (if applicable) and the third the 688 display information (e.g. the real name). The caller-info-list 689 can be empty for scenarios where the call control engine can 690 provide this information itself. 692 CALLEE: logical-address 693 The callee's logical address. 695 DESTINATION-ADDRESS: address-list 696 An ordered list of URIs -- where the protocol domain is 697 indicated by the scheme prefix of each URI. It is assumed that 698 all these addresses refer to the same user, and only a single 699 call will be established. The order in which the addresses are 700 specified indicates a preference and contacting the target 701 SHOULD be tried in that order. 703 CALL-TYPE: symbol 704 Indicates the intention of the call: join a conference (or an 705 n-way call), invite another user into a conference or an n-way 706 call, or create a new call or conference. Possible values are 708 INVITE-2-PARTY: for an invitation to a 2-party call 710 Other types are to be defined in future versions of this 711 document. 713 MEDIA-LIST: list of media 714 A list of media types along with the preferred capability 715 descriptions to be used for this particular call. 717 Optional Parameters: 719 GW-PROXY-LIST: list of string 720 An ordered list of (ordered) lists identifying proxies or 721 gateways to be used for call setup if they are known. The 722 n-th element in the list is a list of alternative 723 gateways/proxies to be used in the n-th step in the call setup 724 process. 726 CALL-ID: data 727 The call-id is a unique call identifier for this call. The 728 type is protocol-dependent, see H.225.0 or SIP for details. If 729 the call-id is not given, the call-control engine MUST 730 generate one. 732 CONF-ID: data 733 The conf-id is a unique conference identifier for this call. 734 The type is protocol-dependent, see H.225.0 or SIP for 735 details. If the conf-id is not given, the call-control engine 736 MUST generate one. 738 ACTIVE-MC: integer 739 If different from zero the caller is an active-mc in this 740 call. 742 TRANFER-REF: call-ref 743 Indicates that this call setup belongs to a transfer 744 indication with the given reference. 746 REDIRECT-REF: call-ref 747 Indicates that this call setup belongs to a forward indication 748 with the given reference. 750 Return parameters: 752 CALL-ID: data 753 The call-id is a unique conference identifier for this call. 755 CONF-ID: data 756 The conf-id is a unique conference identifier for this call. 758 The following application specific result states are defined: 760 OK: The parameters are valid and a call-setup process has been 761 initiated. 763 BAD_URI: The given URI for the callee is not supported by this 764 call-control engine. 766 INCOMPLETE: The given telephone number is incomplete. 768 NOT_FOUND: The call-control engine cannot reach an endpoint with 769 the given URI. 771 DUPLICATE_REF: The reference already exists and cannot be used 772 for this call. 774 INVALID_PARAMETER: One or more parameters are invalid. The error 775 description SHOULD provide more detailed information. 777 The CALL command is used to setup a new call and is sent by the 778 local controller to the call signaling engine. 780 3.6 conf.call-control.cancel 782 conf.call-control.cancel 783 RPC 785 Parameters: 787 REF: call-ref 788 Identifies the call the command refers to. 790 REASON: status 791 A list containing the reason of the cancel. 793 Optional Parameters: none 795 Return parameters: none 797 The following application specific result states are defined: 799 OK: The parameters are valid and the accept has been sent. 801 INVALID_REF: The reference is invalid 803 INVALID_PARAMETER: One or more parameters are invalid. The error 804 description SHOULD provide more detailed information. 806 The CANCEL command is sent by the local controller to the call 807 control engine to indicate that the specified call is to be 808 cancelled. It can also be used by the local controller to inform the 809 call control engine that a call has already been terminated by 810 out-of-band communication, e.g. a horizontal conference control 811 protocol. 813 3.7 conf.call-control.cancelled 815 conf.call-control.connected 816 EVENT NOTIFICATION 817 default target address: (function:call-control) 819 Parameters: 821 REF: call-ref 822 Identifies the call the command refers to. 824 REASON: status 825 A list containing the reason of the cancel, e.g. normal 826 hangup. 828 Optional Parameters: none 830 The CANCELLED message is sent by the call control engine to the 831 local controller to indicate that the call was cancelled. 833 3.8 conf.call-control.connect 835 conf.call-control.connect 836 RPC 838 Parameters: 840 REF: call-ref 841 Identifies the call the command refers to. 843 Optional Parameters: 845 LEG: integer 846 Identifies the specific call leg the command refers to. 848 Return parameters: none 850 The following application specific result states are defined: 852 OK: The parameters are valid and the accept has been sent. 854 INVALID_REF: The reference is invalid 856 INVALID_PARAMETER: One or more parameters are invalid. The error 857 description SHOULD provide more detailed information. 859 The CONNECT message is sent by a the local controller to the call 860 control engine to establish the call. 862 3.9 conf.call-control.connected 864 conf.call-control.connected 865 EVENT NOTIFICATION 866 default target address: (function:call-control) 868 Parameters: 870 REF: call-ref 871 Identifies the call the command refers to. 873 PEER-ADDRESS: address-list 874 Specifies the address of the peer endpoint (or a 875 proxy/gateway/gatekeeper hiding its actual identity) that the 876 call was finally established with. 878 MEDIA-LIST: list of media 879 A list of media types along with the capability descriptions 880 that were initially negotiated for this particular call. 882 Optional Parameters: none 884 The CONNECTED message is sent by a call control engine to the local 885 controller to indicate that the call was successfully established. 887 3.10 conf.call-control.incoming-call 889 conf.call-control.incoming-call 890 EVENT NOTIFICATION 891 default target address: (function:call-control) 893 Parameters: 895 REF: call-ref 896 A unique identifier for the call, that is created by the call 897 control engine signaling in accordance with the rules 898 specified in Section 3.1.1. 900 CALLER-ADDRESS: pair of (logical address string) 901 The address of the caller. The first list element is the 902 logical address, that may contain a display name. The second 903 list element can be an alternative "real" address (if 904 available) or be an empty string. 906 CALLEE: logical-address 907 Callee address as specified by the caller. For example, this 908 may be the content of a SIP To Header. 910 CALLEE-ADDRESS-LIST: address-list 911 An ordered list of URIs, that are addresses of the callee as 912 specified by the caller. For SIP call control engines, this 913 will be a list with one element, with the first element as the 914 SIP Request-URI. 916 CALL-TYPE: symbol 917 Indicates the intention of the call; similar to the CALL-TYPE 918 of the CALL message. 920 MEDIA-LIST: list of media 921 A list of media types along with the preferred capability 922 descriptions proposed by the calling endpoint to be used for 923 this particular call. 925 CALL-ID: data 926 A unique identifier for this call. 928 CONF-ID: data 929 A unique identifier for this conference. 931 Optional Parameters: 933 GW-PROXY-LIST: 934 An ordered list of (ordered) lists identifying proxies or 935 gateways to be used for call setup if they are known. Similar 936 to the CALL message. 938 TRANSFER-REF: call-ref 939 Indicates that this incoming call belongs to a call transfer. 940 If a valid reference is given, this call was used for the 941 transfer and will be terminated. 943 REDIRECT-ADDRESS: media-list 944 Indicates that this incoming call was redirected to this 945 address from the address list. This parameter is optional, 946 because not all call signaling protocols can provide the 947 required information. 949 The INCOMING CALL messages is sent by the call control engine to the 950 local controller to indicate a call request from another endpoint. 952 3.11 conf.call-control.proceed 954 conf.call-control.proceed 955 RPC 957 Parameters: 959 REF: call-ref 960 Identifies the call the command refers to. 962 Optional Parameters: none 964 Return parameters: none 966 The following application specific result states are defined: 968 OK: The parameters are valid and the accept has been sent. 970 INVALID_REF: The reference is invalid 972 INVALID_PARAMETER: One or more parameters are invalid. The error 973 description SHOULD provide more detailed information. 975 The PROCEED command is sent by a local controller to a call control 976 engine in order to indicate that the call setup, that has been 977 signaled with an INCOMING-CALL (Section 3.10) command, is still 978 proceeding. A call control engine should restart its timers for call 979 setup timeouts (if applicable) and translate this command to a 980 protocol specific message, e.g. a SIP-TRYING or Q931-CALL-PROCEEDING 981 message, that is to be sent to the originating party. 983 3.12 conf.call-control.proceeding 985 conf.call-control.proceeding 986 EVENT NOTIFICATION 987 default target address: (function:call-control) 989 Parameters: 991 REF: call-ref 992 Identifies the call the command refers to. 994 PEER-ADDRESS: address-list 995 Specifies the address of the peer endpoint (or a 996 proxy/gateway/gatekeeper hiding its actual identity) that 997 sends the proceeding information. 999 Optional Parameters: 1001 CALL-LEG: integer 1002 Identifies the leg the command refers to. 1004 The PROCEEDING command is sent by a call control engine to a local 1005 controller in order to indicate that the call, that has been 1006 initiated with a CALL (Section 3.5) command, is still proceeding. 1007 The call control engine will usually send this command after it has 1008 received an according message in its call control protocol, e.g. a 1009 SIP-TRYING or Q931-CALL-PROCEEDING message. The reception of a 1010 PROCEEDING command does not imply that a user has already been 1011 contacted. It merely expresses that the call setup is still in 1012 progress. 1014 3.13 conf.call-control.redirect 1016 conf.call-control.redirect 1017 RPC 1019 Parameters: 1021 REF: call-ref 1022 Identifies the call the command refers to. 1024 CALLEE: logical-address 1025 An identifier for the new callee. 1027 ADDRESS-LIST: address-list 1028 List of addresses where the call should be redirected to. 1030 ATTR: symbol 1031 A symbol with the value "TEMPORARILY" or "PERMANENTLY", 1032 signaling whether the redirection is temporarily or not. 1034 REASON: status 1035 A list containing the reason of the redirection. 1037 Optional Parameters: none 1039 Return parameters: none 1041 The following application specific result states are defined: 1043 OK: The parameters are valid and the redirected has been send. 1044 The call is terminated by the call signaling engine. 1046 INVALID_REF: The reference is invalid 1048 INVALID_PARAMETER: One or more parameters are invalid. The error 1049 description SHOULD provide more detailed information. 1051 The REDIRECT command is sent by the local controller to the call 1052 control engine to indicate that the specified call is to be 1053 redirected to another specified address. If the command returns with 1054 OK, the call is terminated. 1056 3.14 conf.call-control.redirected 1058 conf.call-control.redirected 1059 EVENT NOTIFICATION 1060 default target address: (function:call-control) 1062 Parameters: 1064 REF: call-ref 1065 Identifies the call the command refers to. 1067 CALLEE logical-address 1068 A universal personal identifier for the callee as specified by 1069 the caller. For example, this may be the content of a SIP To 1070 Header. 1072 ADDRESS-LIST address-list 1073 List of addresses where the call has been redirected to. 1075 ATTR: symbol 1076 A symbol with the value "TEMPORARILY" or "PERMANENTLY", 1077 signaling whether the redirection is temporarily or not. 1079 REASON: status 1080 A list containing the reason of the redirect. 1082 Optional Parameters: 1084 CALL-LEG: integer 1085 Identifies the leg the command refers to. 1087 The REDIRECTED command is sent by a call control engine to the local 1088 controller to indicate that the specified call has been redirected 1089 to the specified address. The local controller has to setup the 1090 redirected call with a new CALL command (Section 3.5). The old call 1091 will be terminated. If the user does not want the call to be 1092 redirected a CANCEL (Section 3) message must be send to the 1093 signaling engine to terminate the call. 1095 3.15 conf.call-control.reject 1097 conf.call-control.reject 1098 RPC 1100 Parameters: 1102 REF: call-ref 1103 Identifies the call the command refers to. 1105 REASON: status 1106 A list containing the reason of the rejection. 1108 Optional Parameters: none 1110 Return parameters: none 1112 The following application specific result states are defined: 1114 OK: The parameters are valid and the accept has been sent. 1116 INVALID_REF: The reference is invalid 1118 INVALID_PARAMETER: One or more parameters are invalid. The error 1119 description SHOULD provide more detailed information. 1121 A REJECT message is sent by the local controller to the call control 1122 engine that has indicated an INCOMING CALL (Section 3.10) to 1123 indicate rejection of the call. 1125 3.16 conf.call-control.rejected 1127 conf.call-control.rejected 1128 EVENT NOTIFICATION 1129 default target address: (function:call-control) 1131 Parameters: 1133 REF: call-ref 1134 Identifies the call the command refers to. 1136 REASONS: list of pair of (address-list, status) 1137 The pair specifies which target address has rejected the call 1138 for which reason. As several different address lists may have 1139 been tried explicitly, a list of pairs is returned. 1141 Optional Parameters: none 1143 The REJECTED message is sent by a call control engine to the local 1144 controller to indicate that the call was rejected. 1146 3.17 conf.call-control.ring 1148 conf.call-control.ring 1149 RPC 1151 Parameters: 1153 REF: call-ref 1154 Identifies the call the command refers to. 1156 ADDRESS-LIST: address-list 1157 An ordered list of URIs -- where the protocol domain is 1158 indicated by the scheme prefix of each URI. It is assumed that 1159 all these addresses refer to the same user, and only a single 1160 call will be established. 1162 Optional Parameters: 1164 WAITING: integer 1165 If given, the callee is in a conference and it may take a 1166 while before he is finally able to accept the call. A value 1167 greater than zero represents the position of the caller in the 1168 waiting queue. 1170 Return parameters: 1172 The following application specific result states are defined: 1174 OK: The parameters are valid and the accept has been sent. 1176 INVALID_REF: The reference is invalid 1178 INVALID_PARAMETER: One or more parameters are invalid. The error 1179 description SHOULD provide more detailed information. 1181 The RING message is sent by the local controller to the call control 1182 engine. RING indicates that the controller is willing to accept the 1183 incoming call and is now alerting the user. A gateway or proxy 1184 system should translate incoming RINGING (Section 3.18) commands 1185 into RING commands that are to be sent to the call control engine 1186 the incoming call was received from. 1188 3.18 conf.call-control.ringing 1190 conf.call-control.ringing 1191 EVENT NOTIFICATION 1192 default target address: (function:call-control) 1194 Parameters: 1196 REF: call-ref 1197 A unique identifier for the call. 1199 CALLEE: address-list 1200 An ordered list of addresses of endpoints that have been 1201 alerted. It is assumed that all these addresses refer to the 1202 same user, and only a single call will be established. 1204 Optional Parameters: 1206 CALL-LEG: integer 1207 Identifies the leg 1209 WAITING: integer 1210 If given, the callee is in a conference it may take a while 1211 before he is finally able to accept the call. A value greater 1212 than zero represents the position of the caller in the waiting 1213 queue. 1215 The RINGING message is sent by the call control engine to the entity 1216 it received the corresponding CALL (Section 3.5) message from. 1217 RINGING indicates that one or more endpoints have been contacted and 1218 are now alerting the user. 1220 4. Asynchronous Status Signaling 1222 The use of mbus.status commands as specified in the Mbus 1223 guidelines[2] and a list of status code with descriptions will be 1224 provided in a future version of this document. 1226 5. Supplementary Services 1228 5.1 conf.call-control.hold 1230 conf.call-control.hold 1231 RPC 1233 Parameters: 1235 REF: call-ref 1236 Identifies the call the command refers to. 1238 Optional Parameters: 1240 MEDIA-AVAILABLE: integer 1241 If given, media information will be send during the hold. This 1242 may be information or music. 1244 Return parameters: none 1246 The following application specific result states are defined: 1248 OK: The parameters are valid and the redirected has been send. 1249 The call is terminated by the call signaling engine. 1251 INVALID_REF: The reference is invalid 1253 INVALID_PARAMETER: One or more parameters are invalid. The error 1254 description SHOULD provide more detailed information. 1256 The HOLD command is sent by the local controller to the call control 1257 engine to indicate that the specified call is to be hold. The call 1258 can be retrieved with the RETRIEVE command. 1260 5.2 conf.call-control.on-hold 1262 conf.call-control.on-hold 1263 EVENT NOTIFICATION 1264 default target address: (function:call-control) 1266 Parameters: 1268 REF: call-ref 1269 Identifies the call the command refers to. 1271 Optional Parameters: 1273 MEDIA-AVAILABLE: integer 1274 If given, media information will be send during the hold. This 1275 may be information or music. 1277 The ON-HOLD command is sent by a call control engine to the local 1278 controller to indicate that the specified call has been set on hold. 1280 5.3 conf.call-control.retrieve 1282 conf.call-control.retrieve 1283 RPC 1285 Parameters: 1287 REF: call-ref 1288 Identifies the call the command refers to. 1290 Optional Parameters: none 1292 Return parameters: none 1294 The following application specific result states are defined: 1296 OK: The parameters are valid and the redirected has been send. 1297 The call is terminated by the call signaling engine. 1299 INVALID_REF: The reference is invalid 1301 INVALID_PARAMETER: One or more parameters are invalid. The error 1302 description SHOULD provide more detailed information. 1304 NOT_ON_HOLD: The call is not on hold and cannot be retrieved. 1306 The RETRIEVE command is sent by the local controller to the call 1307 control engine to indicate that the specified call is no longer on 1308 hold. 1310 5.4 conf.call-control.retrieved 1312 conf.call-control.retrieved 1313 EVENT NOTIFICATION 1314 default target address: (function:call-control) 1316 Parameters: 1318 REF: call-ref 1319 Identifies the call the command refers to. 1321 Optional Parameters: none 1323 The RETRIEVED command is sent by a call control engine to the local 1324 controller to indicate that the specified call, that has been put on 1325 hold before, has been retrieved. 1327 5.5 conf.call-control.transfer 1329 conf.call-control.transfer 1330 RPC 1332 Parameters: 1334 REF: call-ref 1335 Identifies the call the command refers to. 1337 CALLEE: logical-address 1338 An identifier for the new callee. 1340 ADDRESS-LIST: pair of (symbol, address-list) 1341 The symbol describes the type of the address. Possible types 1342 are "REFERENCE" if the list contains one mbus reference for 1343 the transfer, or "URI" if the list contains URIs for blind 1344 transfer. 1346 Optional Parameters: none 1348 Return parameters: none 1350 The following application specific result states are defined: 1352 OK: The parameters are valid and the redirected has been send. 1353 The call is terminated by the call signaling engine. 1355 INVALID_REF: The reference is invalid 1357 INVALID_PARAMETER: One or more parameters are invalid. The error 1358 description SHOULD provide more detailed information. 1360 The TRANSFER command is sent by the local controller to the call 1361 control engine to indicate that the specified call is to be 1362 transfered to another specified address or another existing call. If 1363 the command returns with OK, the call is terminated. 1365 5.6 conf.call-control.transfered 1367 conf.call-control.transfered 1368 EVENT NOTIFICATION 1369 default target address: (function:call-control) 1371 Parameters: 1373 REF: call-ref 1374 Identifies the call the command refers to. 1376 CALLEE logical-address 1377 An identifier for the callee. 1379 ADDRESS-LIST address-list 1380 List of addresses where the call has been transfered to. 1382 Optional Parameters: none 1384 The TRANSFERED command is sent by a call control engine to the local 1385 controller to indicate that the specified call has been transfered 1386 to the specified address. The local controller has to setup the new 1387 call with a new CALL command (Section 3.5). The old call will be 1388 terminated. If the user does not want the call to be redirected a 1389 REDIRECT message must be send to the signaling engine to terminate 1390 the call. 1392 References 1394 [1] Ott, J., Perkins, C. and D. Kutscher, "A Message Bus for Local 1395 Coordination", Internet Draft draft-ietf-mmusic-mbus-03.txt, 1396 December 2000. 1398 [2] Kutscher, D., "The Message Bus: Guidelines for Application 1399 Profile Writers", Internet Draft 1400 draft-ietf-mmusic-mbus-guidelines-00.txt, February 2001. 1402 [3] Handley, , Schulzrinne, H., Schooler, and Rosenberg, "SIP: 1403 Session Initiation Protocol", Internet Draft 1404 draft-ietf-sip-rfc2543bis-02.txt, November 2000. 1406 [4] ITU-T, "Visual Telephone Systems and Equipment for Local Area 1407 Networks with Non-Guaranteed Quality of Service", ITU-T 1408 Recommendation H.323, 2000. 1410 [5] ITU-T, "ISDN User-Network Interface Layer 3 Specification For 1411 Basic Call Control", ITU-T Recommendation Q.931, 1993. 1413 [6] ITU-T, "Call Signaling Protocols and Media Stream Packetization 1414 for Packet Based Multimedia Communications Systems", ITU-T 1415 Recommendation H.225.0, 2000. 1417 [7] Berners-Lee, , Fielding, and Masinter, "Uniform Resource 1418 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1420 [8] Vaha-Sipila, , "URLs for Telephone Calls", April 2000. 1422 [9] Handley, M. and V. Jacobsen, "SDP: Session Description 1423 Protocol", RFC 2327, April 1998. 1425 [10] Kutscher, D., Ott, J. and C. Bormann, "Requirements for 1426 Session Description and Capability Negotiation", Internet 1427 Draft draft-ietf-mmusic-sdpng-req-00.txt, February 2001. 1429 Authors' Addresses 1431 Joerg Ott 1432 TZI, Universitaet Bremen 1433 Bibliothekstr. 1 1434 Bremen 28359 1435 Germany 1437 Phone: +49.421.201-7028 1438 Fax: +49.421.218-7000 1439 EMail: jo@tzi.org 1440 Dirk Kutscher 1441 TZI, Universitaet Bremen 1442 Bibliothekstr. 1 1443 Bremen 28359 1444 Germany 1446 Phone: +49.421.218-7595 1447 Fax: +49.421.218-7000 1448 EMail: dku@tzi.org 1450 Dirk Meyer 1451 TZI, Universitaet Bremen 1452 Bibliothekstr. 1 1453 Bremen 28359 1454 Germany 1456 Fax: +49.421.218-7000 1457 EMail: dmeyer@tzi.org 1459 Appendix A. SIP Call Flow Example 1461 Caller (A) Callee (B) 1463 Controller Call Control Call Control Controller 1464 Engine Engine 1466 | call | | | 1467 | ----------------> | invite | | 1468 | | ----------------> | incoming-call | 1469 | | | ----------------> | 1470 | | | proceed | 1471 | | 100 proceed | <---------------- | 1472 | proceeding | <---------------- | | 1473 | <---------------- | | | 1474 | | | ring | 1475 | | 180 ringing | <---------------- | 1476 | ringing | <---------------- | | 1477 | <---------------- | | | 1478 | | | accept | 1479 | | 200 OK | <---------------- | 1480 | accepted | <---------------- | | 1481 | <---------------- | | | 1482 | connect | | | 1483 | ----------------> | ACK | | 1484 | connected | ----------------> | connected | 1485 | <---------------- | | ----------------> | 1486 | | | | 1488 | cancel | | | 1489 | ----------------> | BYE | | 1490 | cancelled | ----------------> | cancelled | 1491 | <--------------- | | ----------------> | 1493 Appendix B. H.323 Call Flow Example 1495 Caller (A) Callee (B) 1497 Controller Call Control Call Control Controller 1498 Engine Engine 1500 | call | | | 1501 | ----------------> | setup | | 1502 | | ----------------> | incoming-call | 1503 | | | ----------------> | 1504 | | | proceed | 1505 | | call-proceeding | <---------------- | 1506 | proceeding | <---------------- | | 1507 | <---------------- | | | 1508 | | | ring | 1509 | | alerting | <---------------- | 1510 | ringing | <---------------- | | 1511 | <---------------- | | | 1512 | | | accept | 1513 | | connect | <---------------- | 1514 | accepted | <---------------- | | 1515 | <---------------- | | | 1516 | connect | | | 1517 | ----------------> | | | 1518 | | H.245 open | | 1519 | | logical channels | | 1520 | connected | | connected | 1521 | <---------------- | | ----------------> | 1522 | | | | 1524 | cancel | | | 1525 | ----------------> | release-complete | | 1526 | cancelled | ----------------> | cancelled | 1527 | <--------------- | | ----------------> | 1529 Full Copyright Statement 1531 Copyright (C) The Internet Society (2001). All Rights Reserved. 1533 This document and translations of it may be copied and furnished to 1534 others, and derivative works that comment on or otherwise explain it 1535 or assist in its implmentation may be prepared, copied, published 1536 and distributed, in whole or in part, without restriction of any 1537 kind, provided that the above copyright notice and this paragraph 1538 are included on all such copies and derivative works. However, this 1539 document itself may not be modified in any way, such as by removing 1540 the copyright notice or references to the Internet Society or other 1541 Internet organizations, except as needed for the purpose of 1542 developing Internet standards in which case the procedures for 1543 copyrights defined in the Internet Standards process must be 1544 followed, or as required to translate it into languages other than 1545 English. 1547 The limited permissions granted above are perpetual and will not be 1548 revoked by the Internet Society or its successors or assigns. 1550 This document and the information contained herein is provided on an 1551 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1552 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1553 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1554 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1555 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1557 Acknowledgement 1559 Funding for the RFC editor function is currently provided by the 1560 Internet Society.