Network Working Group Ott Internet-Draft Kutscher Expires: August 24, 2001 Meyer TZI, Universitaet Bremen February 23, 2001 An Mbus Profile for Call Control draft-ietf-mmusic-mbus-call-control-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 24, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document defines an Mbus application profile for call control services. This application profiles is designed to provide the most common basic services of call signaling protocols like SIP[3], H.323/Q.931[4] related to call setup and tear down but also defines a set of optional Mbus commands for supplementary services. The targeted applications include gateway and endpoint decomposition and remote controlling of call signaling engines. The underlying message passing and addressing mechanisms for the Mbus is defined in the Mbus transport specification[1]. This document is a contribution to the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the Ott, et. al. Expires August 24, 2001 [Page 1] Internet-Draft An Mbus Profile for Call Control February 2001 working group's mailing list at confctrl@isi.edu and/or the authors. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Scope of this Document . . . . . . . . . . . . . . . . . . . 4 2. The Call-Control Model . . . . . . . . . . . . . . . . . . . 5 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Basic Services . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 Call Redirection . . . . . . . . . . . . . . . . . . . . . . 10 2.3.3 Call Forwarding/Proxying . . . . . . . . . . . . . . . . . . 10 2.3.4 Call Rejection . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 Supplementary Services . . . . . . . . . . . . . . . . . . . 11 3. The Mbus Call-Control Profile . . . . . . . . . . . . . . . 12 3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1 Mbus Parameter Type Definitions . . . . . . . . . . . . . . 12 3.1.2 Mbus Addressing Scheme . . . . . . . . . . . . . . . . . . . 14 3.1.3 Mbus Control Relation Class . . . . . . . . . . . . . . . . 14 3.2 Mbus Commands . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 conf.call-control.accept . . . . . . . . . . . . . . . . . . 15 3.4 conf.call-control.accepted . . . . . . . . . . . . . . . . . 16 3.5 conf.call-control.call . . . . . . . . . . . . . . . . . . . 16 3.6 conf.call-control.cancel . . . . . . . . . . . . . . . . . . 19 3.7 conf.call-control.cancelled . . . . . . . . . . . . . . . . 19 3.8 conf.call-control.connect . . . . . . . . . . . . . . . . . 20 3.9 conf.call-control.connected . . . . . . . . . . . . . . . . 20 3.10 conf.call-control.incoming-call . . . . . . . . . . . . . . 21 3.11 conf.call-control.proceed . . . . . . . . . . . . . . . . . 22 3.12 conf.call-control.proceeding . . . . . . . . . . . . . . . . 23 3.13 conf.call-control.redirect . . . . . . . . . . . . . . . . . 23 3.14 conf.call-control.redirected . . . . . . . . . . . . . . . . 24 3.15 conf.call-control.reject . . . . . . . . . . . . . . . . . . 25 3.16 conf.call-control.rejected . . . . . . . . . . . . . . . . . 26 3.17 conf.call-control.ring . . . . . . . . . . . . . . . . . . . 26 3.18 conf.call-control.ringing . . . . . . . . . . . . . . . . . 27 4. Asynchronous Status Signaling . . . . . . . . . . . . . . . 28 5. Supplementary Services . . . . . . . . . . . . . . . . . . . 29 5.1 conf.call-control.hold . . . . . . . . . . . . . . . . . . . 29 5.2 conf.call-control.on-hold . . . . . . . . . . . . . . . . . 29 5.3 conf.call-control.retrieve . . . . . . . . . . . . . . . . . 30 5.4 conf.call-control.retrieved . . . . . . . . . . . . . . . . 30 5.5 conf.call-control.transfer . . . . . . . . . . . . . . . . . 31 5.6 conf.call-control.transfered . . . . . . . . . . . . . . . . 31 References . . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 A. SIP Call Flow Example . . . . . . . . . . . . . . . . . . . 35 Ott, et. al. Expires August 24, 2001 [Page 2] Internet-Draft An Mbus Profile for Call Control February 2001 B. H.323 Call Flow Example . . . . . . . . . . . . . . . . . . 36 Full Copyright Statement . . . . . . . . . . . . . . . . . . 37 Ott, et. al. Expires August 24, 2001 [Page 3] Internet-Draft An Mbus Profile for Call Control February 2001 1. Introduction 1.1 Background The Mbus transport specification[1] defines the transport mechanisms of the Message Bus (Mbus), a local coordination infrastructure that allows message passing between a group of application components. The Mbus guidelines[2] define a list of conventions for terminology, algorithms and procedures for higher level interaction models that are useful for applications using the Mbus. These conventions are intended as guidelines for designers of Mbus application profiles and Mbus implementations/applications. This document builds on these two specifications and provides an Mbus application profile for call control services that uses the conventions codified in the Mbus guidelines[2] to specify an Mbus application profile, i.e., a list of Mbus commands and procedures that allow to implement call-control applications. 1.2 Scope of this Document This document defines a command set and corresponding interactions between application components for basic call control services, such as call setup, call termination. The set of basic call control commands also includes commands for redirecting or forwarding (proxying) call setup requests. The set of basic call control commands is supplemented by a set of additional commands for supplementary services, such as call hold and call transfer. In a future version, this document will also specify commands that allow to implement multiparty conferencing. Ott, et. al. Expires August 24, 2001 [Page 4] Internet-Draft An Mbus Profile for Call Control February 2001 2. The Call-Control Model 2.1 Overview The model that this specification is based on is that of a decomposed conferencing system, such as a terminal or gateway. In such a system, there exists a call control engine, for example, a SIP engine, that implements a call signaling protocol, in this case SIP. This call control engine provides the functionality to initiate, manage and terminate call control relations to other endpoints (or gateways). The call control engine can be viewed as an application component, i.e., it offers certain services to other components that can make use of the call control component and control the call signaling processes. As an application component it is probably designed to be reusable in different application scenarios. A separate controlling component, termed "controller" in the following sections, implements the application logic and controls one (or more) call control engines using the Mbus commands specified in this document. The figure below (Figure 1) shows an example of the relation between a controller and a call control engine in an Mbus enables conferencing system. +---------- Mbus ----------+ | | | +---------------+ | | | | | | | controller | | | | | | | +---------------+ | | | | | | | | +---------------+ | +---------------+ | | call | | SIP | call | | | control |==================| control | | | engine | | | engine | | +---------------+ | +---------------+ | | +--------------------------+ The scope of this document is the specification of the communication mechanisms between a controller and a call control engine within an Mbus domain, based on the transport mechanisms specified in the Mbus transport specification[1] and based on the interaction schemes defined in the Mbus guidelines[2]. Ott, et. al. Expires August 24, 2001 [Page 5] Internet-Draft An Mbus Profile for Call Control February 2001 In order to accommodate other call signaling protocols besides SIP, the interactions that are defined here provide a sufficient level of abstraction from concrete call control protocols. This abstraction implies that not every feature of every call control can be provided. The trade-off between generality and functionality/specificity results in a call-control model that o supports basic, common call control services; o uses universal addressing schemes for callee addresses and other parameters; o provides hooks for call control protocol specific extensions, such as optional parameters; and o separates advanced functionality, such as supplementary services, out into an optional module. The generality provided should allow for building generic controllers relying on this call-control model that can control call control engine from different protocol domains without having to care about the call control specific details. For an architecture like the one depicted in the figure above (Figure 1) this would allow to replace the SIP call control engine by a H.323 engine without having to change the the implementation of the controller. 2.2 Concepts This section describes a set of concepts, abstractions and identifiers that are used by the presented call control model. This includes: identification of calls; addressing concept for participants and endpoints; and call state manipulation. Controlling a call control engine by a controller uses the notion of "a call", which is an abstraction that represents the state of a call control relation that is setup, modified and terminated by means of message exchange between a controller and a call control engine. In order to disambiguate multiple calls that are managed by a system, call identifiers are employed. Different types of identifiers are used: Call Identifier: A call identifier is used to identify calls uniquely. In this model, "a call" represents a call control Ott, et. al. Expires August 24, 2001 [Page 6] Internet-Draft An Mbus Profile for Call Control February 2001 relation between two endpoints. If an endpoint has call control relation to two other endpoints at the same time, two different call identifiers will be used to disambiguate the call states. The concept of a globally unique call identifier is prevalent in most call signaling protocols as well. For the Mbus call control commands, the call identifiers are generated by the call control engine and are considered opaque values by other components, e.g., a controller. The appearance of the call identifier depends on the call signaling protocoll. See H.225.0[6] and SIP for details. Call Leg Identifier: Call leg identifiers allow for a more fine grained control of call control relations. A call control engine may try to setup more than one outgoing call at a time in order to establish a call control relation to a participant, e.g., when the call control engine is a component in a forking proxy system. In order to disambiguate the different call legs that are created for a single call, the notion of call leg identifiers is introduced. Conference Identifier: While a call identifier is used to identify individual call control relations there are also more persistent states, e.g., multi-party conferences. In some models, multi-party conferences can be implemented by creating a full mesh of calls between all participants. The individual calls would then disambiguated with call identifiers while the conference itself is identified by a "conference identifier". In this specification, this identifier is also used to implement call transfer. The transfer of a call is implemented by having the transferor initiate a new call to the transferred-to party, which result in a new call with a new call identifier. In order to be able to identify and track the call it is assigned a persistent conference identifier. 2.3 Basic Services The provided basic services are: Call setup: A controller can make a call control engine initiate a new call using its native call signaling protocol. The call control engine will notify the controller of progress events, e.g., when the called party accepts the call. For a called endpoint, the call control engine will signal incoming call events it received via its native call signaling protocol, enabling the controller to react and eventually control the completion of the call setup by accepting the call. See Section 2.3.1 for a detailed discussion of call setup procedures. Call redirection: After an incoming call has been signaled by the Ott, et. al. Expires August 24, 2001 [Page 7] Internet-Draft An Mbus Profile for Call Control February 2001 call control engine, the controller can request the call control engine to redirect the call to another endpoint. See Section 2.3.2 for a detailed discussion of call redirection procedures. Call forwarding/proxying: After an incoming call has been signaled by the call control engine, the controller can request the call control engine to proxy the call to another endpoint. See Section 2.3.3 for a detailed discussion of call forwarding procedures. Call canceling/rejection: Outgoing and incoming calls can be rejected and cancelled by the controller at any time. See Section 2.3.4 for a detailed discussion of call rejection procedures. 2.3.1 Call Setup The figure below (Figure 2) provides a schematic visualization of the Mbus communication for setting up and terminating a call. "CS" represents the call signaling protocol. Please refer to Appendix A and to Appendix B for examples that show the mapping of call control specific PDUs to the Mbus commands. Ott, et. al. Expires August 24, 2001 [Page 8] Internet-Draft An Mbus Profile for Call Control February 2001 Caller (A) Callee (B) Controller Call Control Call Control Controller Engine Engine | call | | | | ----------------> | | incoming-call | | | | ----------------> | | | | proceed | | proceeding | CS | <---------------- | | <---------------- | | | | | <--> | ring | | ringing | | <---------------- | | <---------------- | | | | | | accept | | accepted | | <---------------- | | <---------------- | | | | connect | | | | ----------------> | | | | connected | | connected | | <---------------- | | ----------------> | | | | | | cancel | | | | ----------------> | | | | cancelled | | cancelled | | <---------------- | | ----------------> | | | | | The figure above (Figure 2) shows the message flow for a calling party A as well as for a called party B . A's controller initiates the call setup with a "call" message sent to the call control engine. The call control engine would subsequently setup a call using its native call signaling protocol (not shown here in detail). The most important parameters of the "call" message are the address of the callee and a media/capability description to be used for the call. In case a call control relation with the callee can be established, A's call control engine will notify the controller of call progress indications it received via its call signaling protocol. When B has accepted the call, A's call control engine will notify the controller with a "accepted" message, which must be acknowledged by sending a connect message back to the call control engine. In essence, this mimics a three-way-handshake model, that allows some basic form of call parameters negotiation, as employed by, e.g., SIP[3]. For this purpose, both the "call" and the "accepted" message can be parameterized with media/capability descriptions. Ott, et. al. Expires August 24, 2001 [Page 9] Internet-Draft An Mbus Profile for Call Control February 2001 In this example, the call is terminated by A's controller's sending of a "cancel" message to its call control engine, which subsequently terminates the call control relation to B. Both A's and B's call control engine notify their controllers with a "cancelled" message. A "cancel" message can be sent at any stage of a call setup phase in order to terminate the call and cancel the call control relation. 2.3.2 Call Redirection The figure below (Figure 3) provides a schematic visualization of the Mbus communication for redirecting an incoming call. "CS" represents the call signaling protocol. Caller (A) Callee (B) Controller Call Control Call Control Controller Engine Engine | call | | | | ----------------> | | incoming-call | | | | ----------------> | | | | redirect | | redirected | CS | <---------------- | | <---------------- | | | | | <--> | | In this example, B's controller decides to redirect the incoming call instead of accepting it. The "redirect" message is parameterized with the address of an alternative contact for the originally called party. This information is transported via the native signaling protocol and reported by A's call control engine to its controller using the "redirected" message. In order to contact the party that A has been redirected to A's controller would have to setup a new call using the "call" message. 2.3.3 Call Forwarding/Proxying Call forwarding/proxying is a functionality used for implementing application layer gateways, e.g., proxy servers. Details TBD 2.3.4 Call Rejection The figure below (Figure 4) provides a schematic visualization of the Mbus communication for rejecting an incoming call. "CS" Ott, et. al. Expires August 24, 2001 [Page 10] Internet-Draft An Mbus Profile for Call Control February 2001 represents the call signaling protocol. Caller (A) Callee (B) Controller Call Control Call Control Controller Engine Engine | call | | | | ----------------> | | incoming-call | | | | ----------------> | | | | reject | | rejected | CS | <---------------- | | <---------------- | | | | | <--> | | In this example, B's controller decides to reject the incoming call instead of accepting it. The "reject" message is parameterized with a reason code. This information is transported via the native signaling protocol and reported by A's call control engine to its controller using the "rejected" message. 2.4 Supplementary Services The provided supplementary services are: Call hold: Call transfer: Call waiting: Ott, et. al. Expires August 24, 2001 [Page 11] Internet-Draft An Mbus Profile for Call Control February 2001 3. The Mbus Call-Control Profile 3.1 General This section defines how the call control model described in Section 2 is implemented as an Mbus application profile using the mechanisms defined in the Mbus guidelines[2]. We define Mbus commands that provide the call control services and define the structure and semantics of parameters. 3.1.1 Mbus Parameter Type Definitions Some commonly used parameter types: Call reference: In most of the Mbus commands specified below a call reference is used to identify calls. Call control engines can map the call reference to call identifies of their call signaling protocol. The Mbus parameter data type for call references is String and abbreviated as "call-ref" in the specification below. References are created by call (Section 3.5) or incoming-call (Section 3.10) commands. Every newly created call reference MUST be composed of the Mbus address of the creating entity and a second entity specific part in order to ensure uniqueness. Address: Some commands require the specification of an address (or address list) for users. These addresses are self-contained URIs, that allow to identify the call control protocol domain and the call control domain specific information that is required to setup a call control relation to the specified user. One of following scheme identifiers (see [7] for the definition of the general URI syntax) MUST be used: sip: for SIP URIs h323: for H.323 URIs tel: for telephone call URIs as specified in [8] The scheme specific part of an address URI MUST contain the protocol specific information that is needed to establish a call control relation. The Mbus parameter type for an address is called "address" in the specification below. The Mbus type for "address" is String. Address parameters are used in requests to call control engines, that should be able to translate them into native addresses of their corresponding call signaling protocol. Address list: For some commands, more than one address needs to Ott, et. al. Expires August 24, 2001 [Page 12] Internet-Draft An Mbus Profile for Call Control February 2001 passed as a parameter. The type "address-list" is defined as a "list of address" and is used as a parameter type for requests where more than address can be specified. Logical address: A logical address is an informational address that denominates the user that a caller is trying to call. The logical address is not necessarily identical to the address URI described above. For example, in a SIP-INVITE request the Request-URI may be "sip:123434565@big-company.foo" (which may have been obtained from a location server), whereas the logical address is "sip:support@big-company.foo" (in SIP, this could be the content of a To header field). As the To header field in SIP, the logical address can be augmented by a "display name", that can be presented to a user by a user agent. As an Mbus parameter, the logical address is therefore represented as a list of two elements (both of type string), where the first element is the display name and the second element is the address URI. In the command specification below the type for logical address parameters is called "logical-address". Status codes: Some of the commands defined below can be parameterized with status codes and reason descriptions that represent error conditions (or other status information). On the Mbus, this information is represented as a list of two strings, where the first element is a numerical status code code and the second element is a textual description. In the command specification below the type for status information parameters is called "status". The details of the status codes are to be defined; they are to be derived from H.323 and SIP. Media: Some commands have a media parameter list and/or a capability list for media settings for the call. SDP[9] or SDP-ng[10] SHOULD be used for describing session parameters and capabilities. The Mbus parameter type "media" is a pair of (Symbol, Data) where the first element identifies the type of the description language and the second element is the actual description. The following description types SHOULD be used: * SDP * SDP-ng In order to allow for expressing preferences with SDP, some commands use a list of media for media description parameters. In these lists, the order of the media elements (each of which represents a stand alone SDP description) define their relative preference. Overview of the parameter data types: Ott, et. al. Expires August 24, 2001 [Page 13] Internet-Draft An Mbus Profile for Call Control February 2001 +----------------+-----------------------+--------------------+ |Type name | Mbus type definition | Description | +----------------+-----------------------+--------------------+ |call-ref | string | Call Reference | |address | string | Address URI | |address-list | list of address | List of URIs | |logical-address | pair of string | Logical Address | |status | pair of string | Status Information | |media | pair of (symbol,data) | Media Information | +----------------+-----------------------+--------------------+ In the command specification below the type names are used to specify parameter lists. 3.1.2 Mbus Addressing Scheme The following Mbus address fields SHOULD be used by implementations of the call control commands: function: Describes the general function of the component. The value SHOULD be fixed to "call-control" for both, controller and call control engine. cc-module: Describes the type of the component. Possible values: controller: The component is a controller. engine: The component is a call control engine. A sample Mbus address for a controller could look like this: (function:call-control cc-module:controller id:123-4@192.168.1.1) A sample Mbus address for a call control engine could look like this: (function:call-control cc-module:engine id:124-4@192.168.1.1) 3.1.3 Mbus Control Relation Class The Mbus guidelines[2] specify different control classes for applications consisting of modules with controller/controllee relations. Implementations of the call control profile SHOULD implement the control class "tight control", which means, that a controllee (a control engine) can only be controlled by one controller at a time. Ott, et. al. Expires August 24, 2001 [Page 14] Internet-Draft An Mbus Profile for Call Control February 2001 A controller MUST therefore take over the control of a call control engine -- using the mbus.register command [2] -- before it can send commands to a call control engine. The command prefix for the call control commands is "conf.call-control". This means, a controller MUST register itself for the "conf.call-control" hierarchy. See Section 3.2 for the default target address that SHOULD be used for event notifications by call control engines that are not yet controlled. 3.2 Mbus Commands The following Mbus commands can be divided into two classes: RPCs Event notifications RPCs are sent from a controller to a call control engine. All RPCs MUST be supported by call control engines, i.e., they MUST be able to receive and understand them. Where possible, the imperative form has been chosen for RPC command names, e.g., "call" and "cancel". Event notifications are sent from a call control engine to a controller. All event notifications MUST be supported by controllers, i.e., they MUST be able to receive and understand them. Where possible, the past (or present) participle form has been chosen for names of event notification commands, e.g., "connected" and "proceeding". The default target address (see the Mbus guidelines[2] for a definition of default target address) is (function:call-control) 3.3 conf.call-control.accept conf.call-control.accept RPC Parameters: REF: call-ref Identifies the call the command refers to. MEDIA-LIST: list of media A list of media types along with the preferred capability descriptions selected by the local controller. This SHOULD be a strict subset of the media descriptions the calling endpoint has proposed for this particular call. Ott, et. al. Expires August 24, 2001 [Page 15] Internet-Draft An Mbus Profile for Call Control February 2001 Optional Parameters: none Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the accept has been sent. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. An ACCEPT message is sent by the local controller to the call control engine that has indicated an INCOMING CALL (Section 3.10) to indicate acceptance of the call. 3.4 conf.call-control.accepted conf.call-control.accepted EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. Optional Parameters: LEG: integer Identifies the leg the command refers to. The ACCEPTED message is sent by the callers call control engine to the local controller to indicate that the party has accepted the call. 3.5 conf.call-control.call conf.call-control.call RPC Parameters: REF: call-ref A unique identifier for the call. This reference MUST be used for all further interactions relating to this between the call control engine and the initiating entity. Call references SHOULD be constructed considering the rules specified in Ott, et. al. Expires August 24, 2001 [Page 16] Internet-Draft An Mbus Profile for Call Control February 2001 Section 3.1.1. CALLER-INFO-LIST: list of string A list containing caller information that the call control engine should use for this call. The first parameter is the caller's logical address, the second parameter a protocol specific source address (if applicable) and the third the display information (e.g. the real name). The caller-info-list can be empty for scenarios where the call control engine can provide this information itself. CALLEE: logical-address The callee's logical address. DESTINATION-ADDRESS: address-list An ordered list of URIs -- where the protocol domain is indicated by the scheme prefix of each URI. It is assumed that all these addresses refer to the same user, and only a single call will be established. The order in which the addresses are specified indicates a preference and contacting the target SHOULD be tried in that order. CALL-TYPE: symbol Indicates the intention of the call: join a conference (or an n-way call), invite another user into a conference or an n-way call, or create a new call or conference. Possible values are INVITE-2-PARTY: for an invitation to a 2-party call Other types are to be defined in future versions of this document. MEDIA-LIST: list of media A list of media types along with the preferred capability descriptions to be used for this particular call. Optional Parameters: GW-PROXY-LIST: list of string An ordered list of (ordered) lists identifying proxies or gateways to be used for call setup if they are known. The n-th element in the list is a list of alternative gateways/proxies to be used in the n-th step in the call setup process. CALL-ID: data The call-id is a unique call identifier for this call. The type is protocol-dependent, see H.225.0 or SIP for details. If the call-id is not given, the call-control engine MUST Ott, et. al. Expires August 24, 2001 [Page 17] Internet-Draft An Mbus Profile for Call Control February 2001 generate one. CONF-ID: data The conf-id is a unique conference identifier for this call. The type is protocol-dependent, see H.225.0 or SIP for details. If the conf-id is not given, the call-control engine MUST generate one. ACTIVE-MC: integer If different from zero the caller is an active-mc in this call. TRANFER-REF: call-ref Indicates that this call setup belongs to a transfer indication with the given reference. REDIRECT-REF: call-ref Indicates that this call setup belongs to a forward indication with the given reference. Return parameters: CALL-ID: data The call-id is a unique conference identifier for this call. CONF-ID: data The conf-id is a unique conference identifier for this call. The following application specific result states are defined: OK: The parameters are valid and a call-setup process has been initiated. BAD_URI: The given URI for the callee is not supported by this call-control engine. INCOMPLETE: The given telephone number is incomplete. NOT_FOUND: The call-control engine cannot reach an endpoint with the given URI. DUPLICATE_REF: The reference already exists and cannot be used for this call. INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The CALL command is used to setup a new call and is sent by the local controller to the call signaling engine. Ott, et. al. Expires August 24, 2001 [Page 18] Internet-Draft An Mbus Profile for Call Control February 2001 3.6 conf.call-control.cancel conf.call-control.cancel RPC Parameters: REF: call-ref Identifies the call the command refers to. REASON: status A list containing the reason of the cancel. Optional Parameters: none Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the accept has been sent. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The CANCEL command is sent by the local controller to the call control engine to indicate that the specified call is to be cancelled. It can also be used by the local controller to inform the call control engine that a call has already been terminated by out-of-band communication, e.g. a horizontal conference control protocol. 3.7 conf.call-control.cancelled conf.call-control.connected EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. REASON: status A list containing the reason of the cancel, e.g. normal hangup. Optional Parameters: none Ott, et. al. Expires August 24, 2001 [Page 19] Internet-Draft An Mbus Profile for Call Control February 2001 The CANCELLED message is sent by the call control engine to the local controller to indicate that the call was cancelled. 3.8 conf.call-control.connect conf.call-control.connect RPC Parameters: REF: call-ref Identifies the call the command refers to. Optional Parameters: LEG: integer Identifies the specific call leg the command refers to. Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the accept has been sent. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The CONNECT message is sent by a the local controller to the call control engine to establish the call. 3.9 conf.call-control.connected conf.call-control.connected EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. PEER-ADDRESS: address-list Specifies the address of the peer endpoint (or a proxy/gateway/gatekeeper hiding its actual identity) that the call was finally established with. MEDIA-LIST: list of media Ott, et. al. Expires August 24, 2001 [Page 20] Internet-Draft An Mbus Profile for Call Control February 2001 A list of media types along with the capability descriptions that were initially negotiated for this particular call. Optional Parameters: none The CONNECTED message is sent by a call control engine to the local controller to indicate that the call was successfully established. 3.10 conf.call-control.incoming-call conf.call-control.incoming-call EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref A unique identifier for the call, that is created by the call control engine signaling in accordance with the rules specified in Section 3.1.1. CALLER-ADDRESS: pair of (logical address string) The address of the caller. The first list element is the logical address, that may contain a display name. The second list element can be an alternative "real" address (if available) or be an empty string. CALLEE: logical-address Callee address as specified by the caller. For example, this may be the content of a SIP To Header. CALLEE-ADDRESS-LIST: address-list An ordered list of URIs, that are addresses of the callee as specified by the caller. For SIP call control engines, this will be a list with one element, with the first element as the SIP Request-URI. CALL-TYPE: symbol Indicates the intention of the call; similar to the CALL-TYPE of the CALL message. MEDIA-LIST: list of media A list of media types along with the preferred capability descriptions proposed by the calling endpoint to be used for this particular call. CALL-ID: data A unique identifier for this call. Ott, et. al. Expires August 24, 2001 [Page 21] Internet-Draft An Mbus Profile for Call Control February 2001 CONF-ID: data A unique identifier for this conference. Optional Parameters: GW-PROXY-LIST: An ordered list of (ordered) lists identifying proxies or gateways to be used for call setup if they are known. Similar to the CALL message. TRANSFER-REF: call-ref Indicates that this incoming call belongs to a call transfer. If a valid reference is given, this call was used for the transfer and will be terminated. REDIRECT-ADDRESS: media-list Indicates that this incoming call was redirected to this address from the address list. This parameter is optional, because not all call signaling protocols can provide the required information. The INCOMING CALL messages is sent by the call control engine to the local controller to indicate a call request from another endpoint. 3.11 conf.call-control.proceed conf.call-control.proceed RPC Parameters: REF: call-ref Identifies the call the command refers to. Optional Parameters: none Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the accept has been sent. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The PROCEED command is sent by a local controller to a call control engine in order to indicate that the call setup, that has been Ott, et. al. Expires August 24, 2001 [Page 22] Internet-Draft An Mbus Profile for Call Control February 2001 signaled with an INCOMING-CALL (Section 3.10) command, is still proceeding. A call control engine should restart its timers for call setup timeouts (if applicable) and translate this command to a protocol specific message, e.g. a SIP-TRYING or Q931-CALL-PROCEEDING message, that is to be sent to the originating party. 3.12 conf.call-control.proceeding conf.call-control.proceeding EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. PEER-ADDRESS: address-list Specifies the address of the peer endpoint (or a proxy/gateway/gatekeeper hiding its actual identity) that sends the proceeding information. Optional Parameters: CALL-LEG: integer Identifies the leg the command refers to. The PROCEEDING command is sent by a call control engine to a local controller in order to indicate that the call, that has been initiated with a CALL (Section 3.5) command, is still proceeding. The call control engine will usually send this command after it has received an according message in its call control protocol, e.g. a SIP-TRYING or Q931-CALL-PROCEEDING message. The reception of a PROCEEDING command does not imply that a user has already been contacted. It merely expresses that the call setup is still in progress. 3.13 conf.call-control.redirect conf.call-control.redirect RPC Parameters: REF: call-ref Identifies the call the command refers to. CALLEE: logical-address An identifier for the new callee. Ott, et. al. Expires August 24, 2001 [Page 23] Internet-Draft An Mbus Profile for Call Control February 2001 ADDRESS-LIST: address-list List of addresses where the call should be redirected to. ATTR: symbol A symbol with the value "TEMPORARILY" or "PERMANENTLY", signaling whether the redirection is temporarily or not. REASON: status A list containing the reason of the redirection. Optional Parameters: none Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the redirected has been send. The call is terminated by the call signaling engine. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The REDIRECT command is sent by the local controller to the call control engine to indicate that the specified call is to be redirected to another specified address. If the command returns with OK, the call is terminated. 3.14 conf.call-control.redirected conf.call-control.redirected EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. CALLEE logical-address A universal personal identifier for the callee as specified by the caller. For example, this may be the content of a SIP To Header. ADDRESS-LIST address-list List of addresses where the call has been redirected to. ATTR: symbol Ott, et. al. Expires August 24, 2001 [Page 24] Internet-Draft An Mbus Profile for Call Control February 2001 A symbol with the value "TEMPORARILY" or "PERMANENTLY", signaling whether the redirection is temporarily or not. REASON: status A list containing the reason of the redirect. Optional Parameters: CALL-LEG: integer Identifies the leg the command refers to. The REDIRECTED command is sent by a call control engine to the local controller to indicate that the specified call has been redirected to the specified address. The local controller has to setup the redirected call with a new CALL command (Section 3.5). The old call will be terminated. If the user does not want the call to be redirected a CANCEL (Section 3) message must be send to the signaling engine to terminate the call. 3.15 conf.call-control.reject conf.call-control.reject RPC Parameters: REF: call-ref Identifies the call the command refers to. REASON: status A list containing the reason of the rejection. Optional Parameters: none Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the accept has been sent. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. A REJECT message is sent by the local controller to the call control engine that has indicated an INCOMING CALL (Section 3.10) to indicate rejection of the call. Ott, et. al. Expires August 24, 2001 [Page 25] Internet-Draft An Mbus Profile for Call Control February 2001 3.16 conf.call-control.rejected conf.call-control.rejected EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. REASONS: list of pair of (address-list, status) The pair specifies which target address has rejected the call for which reason. As several different address lists may have been tried explicitly, a list of pairs is returned. Optional Parameters: none The REJECTED message is sent by a call control engine to the local controller to indicate that the call was rejected. 3.17 conf.call-control.ring conf.call-control.ring RPC Parameters: REF: call-ref Identifies the call the command refers to. ADDRESS-LIST: address-list An ordered list of URIs -- where the protocol domain is indicated by the scheme prefix of each URI. It is assumed that all these addresses refer to the same user, and only a single call will be established. Optional Parameters: WAITING: integer If given, the callee is in a conference and it may take a while before he is finally able to accept the call. A value greater than zero represents the position of the caller in the waiting queue. Return parameters: The following application specific result states are defined: Ott, et. al. Expires August 24, 2001 [Page 26] Internet-Draft An Mbus Profile for Call Control February 2001 OK: The parameters are valid and the accept has been sent. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The RING message is sent by the local controller to the call control engine. RING indicates that the controller is willing to accept the incoming call and is now alerting the user. A gateway or proxy system should translate incoming RINGING (Section 3.18) commands into RING commands that are to be sent to the call control engine the incoming call was received from. 3.18 conf.call-control.ringing conf.call-control.ringing EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref A unique identifier for the call. CALLEE: address-list An ordered list of addresses of endpoints that have been alerted. It is assumed that all these addresses refer to the same user, and only a single call will be established. Optional Parameters: CALL-LEG: integer Identifies the leg WAITING: integer If given, the callee is in a conference it may take a while before he is finally able to accept the call. A value greater than zero represents the position of the caller in the waiting queue. The RINGING message is sent by the call control engine to the entity it received the corresponding CALL (Section 3.5) message from. RINGING indicates that one or more endpoints have been contacted and are now alerting the user. Ott, et. al. Expires August 24, 2001 [Page 27] Internet-Draft An Mbus Profile for Call Control February 2001 4. Asynchronous Status Signaling The use of mbus.status commands as specified in the Mbus guidelines[2] and a list of status code with descriptions will be provided in a future version of this document. Ott, et. al. Expires August 24, 2001 [Page 28] Internet-Draft An Mbus Profile for Call Control February 2001 5. Supplementary Services 5.1 conf.call-control.hold conf.call-control.hold RPC Parameters: REF: call-ref Identifies the call the command refers to. Optional Parameters: MEDIA-AVAILABLE: integer If given, media information will be send during the hold. This may be information or music. Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the redirected has been send. The call is terminated by the call signaling engine. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The HOLD command is sent by the local controller to the call control engine to indicate that the specified call is to be hold. The call can be retrieved with the RETRIEVE command. 5.2 conf.call-control.on-hold conf.call-control.on-hold EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. Optional Parameters: MEDIA-AVAILABLE: integer If given, media information will be send during the hold. This Ott, et. al. Expires August 24, 2001 [Page 29] Internet-Draft An Mbus Profile for Call Control February 2001 may be information or music. The ON-HOLD command is sent by a call control engine to the local controller to indicate that the specified call has been set on hold. 5.3 conf.call-control.retrieve conf.call-control.retrieve RPC Parameters: REF: call-ref Identifies the call the command refers to. Optional Parameters: none Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the redirected has been send. The call is terminated by the call signaling engine. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. NOT_ON_HOLD: The call is not on hold and cannot be retrieved. The RETRIEVE command is sent by the local controller to the call control engine to indicate that the specified call is no longer on hold. 5.4 conf.call-control.retrieved conf.call-control.retrieved EVENT NOTIFICATION default target address: (function:call-control) Parameters: REF: call-ref Identifies the call the command refers to. Optional Parameters: none The RETRIEVED command is sent by a call control engine to the local Ott, et. al. Expires August 24, 2001 [Page 30] Internet-Draft An Mbus Profile for Call Control February 2001 controller to indicate that the specified call, that has been put on hold before, has been retrieved. 5.5 conf.call-control.transfer conf.call-control.transfer RPC Parameters: REF: call-ref Identifies the call the command refers to. CALLEE: logical-address An identifier for the new callee. ADDRESS-LIST: pair of (symbol, address-list) The symbol describes the type of the address. Possible types are "REFERENCE" if the list contains one mbus reference for the transfer, or "URI" if the list contains URIs for blind transfer. Optional Parameters: none Return parameters: none The following application specific result states are defined: OK: The parameters are valid and the redirected has been send. The call is terminated by the call signaling engine. INVALID_REF: The reference is invalid INVALID_PARAMETER: One or more parameters are invalid. The error description SHOULD provide more detailed information. The TRANSFER command is sent by the local controller to the call control engine to indicate that the specified call is to be transfered to another specified address or another existing call. If the command returns with OK, the call is terminated. 5.6 conf.call-control.transfered conf.call-control.transfered EVENT NOTIFICATION default target address: (function:call-control) Parameters: Ott, et. al. Expires August 24, 2001 [Page 31] Internet-Draft An Mbus Profile for Call Control February 2001 REF: call-ref Identifies the call the command refers to. CALLEE logical-address An identifier for the callee. ADDRESS-LIST address-list List of addresses where the call has been transfered to. Optional Parameters: none The TRANSFERED command is sent by a call control engine to the local controller to indicate that the specified call has been transfered to the specified address. The local controller has to setup the new call with a new CALL command (Section 3.5). The old call will be terminated. If the user does not want the call to be redirected a REDIRECT message must be send to the signaling engine to terminate the call. Ott, et. al. Expires August 24, 2001 [Page 32] Internet-Draft An Mbus Profile for Call Control February 2001 References [1] Ott, J., Perkins, C. and D. Kutscher, "A Message Bus for Local Coordination", Internet Draft draft-ietf-mmusic-mbus-03.txt, December 2000. [2] Kutscher, D., "The Message Bus: Guidelines for Application Profile Writers", Internet Draft draft-ietf-mmusic-mbus-guidelines-00.txt, February 2001. [3] Handley, , Schulzrinne, H., Schooler, and Rosenberg, "SIP: Session Initiation Protocol", Internet Draft draft-ietf-sip-rfc2543bis-02.txt, November 2000. [4] ITU-T, "Visual Telephone Systems and Equipment for Local Area Networks with Non-Guaranteed Quality of Service", ITU-T Recommendation H.323, 2000. [5] ITU-T, "ISDN User-Network Interface Layer 3 Specification For Basic Call Control", ITU-T Recommendation Q.931, 1993. [6] ITU-T, "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems", ITU-T Recommendation H.225.0, 2000. [7] Berners-Lee, , Fielding, and Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [8] Vaha-Sipila, , "URLs for Telephone Calls", April 2000. [9] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998. [10] Kutscher, D., Ott, J. and C. Bormann, "Requirements for Session Description and Capability Negotiation", Internet Draft draft-ietf-mmusic-sdpng-req-00.txt, February 2001. Authors' Addresses Joerg Ott TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany Phone: +49.421.201-7028 Fax: +49.421.218-7000 EMail: jo@tzi.org Ott, et. al. Expires August 24, 2001 [Page 33] Internet-Draft An Mbus Profile for Call Control February 2001 Dirk Kutscher TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany Phone: +49.421.218-7595 Fax: +49.421.218-7000 EMail: dku@tzi.org Dirk Meyer TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany Fax: +49.421.218-7000 EMail: dmeyer@tzi.org Ott, et. al. Expires August 24, 2001 [Page 34] Internet-Draft An Mbus Profile for Call Control February 2001 Appendix A. SIP Call Flow Example Caller (A) Callee (B) Controller Call Control Call Control Controller Engine Engine | call | | | | ----------------> | invite | | | | ----------------> | incoming-call | | | | ----------------> | | | | proceed | | | 100 proceed | <---------------- | | proceeding | <---------------- | | | <---------------- | | | | | | ring | | | 180 ringing | <---------------- | | ringing | <---------------- | | | <---------------- | | | | | | accept | | | 200 OK | <---------------- | | accepted | <---------------- | | | <---------------- | | | | connect | | | | ----------------> | ACK | | | connected | ----------------> | connected | | <---------------- | | ----------------> | | | | | | cancel | | | | ----------------> | BYE | | | cancelled | ----------------> | cancelled | | <--------------- | | ----------------> | Ott, et. al. Expires August 24, 2001 [Page 35] Internet-Draft An Mbus Profile for Call Control February 2001 Appendix B. H.323 Call Flow Example Caller (A) Callee (B) Controller Call Control Call Control Controller Engine Engine | call | | | | ----------------> | setup | | | | ----------------> | incoming-call | | | | ----------------> | | | | proceed | | | call-proceeding | <---------------- | | proceeding | <---------------- | | | <---------------- | | | | | | ring | | | alerting | <---------------- | | ringing | <---------------- | | | <---------------- | | | | | | accept | | | connect | <---------------- | | accepted | <---------------- | | | <---------------- | | | | connect | | | | ----------------> | | | | | H.245 open | | | | logical channels | | | connected | | connected | | <---------------- | | ----------------> | | | | | | cancel | | | | ----------------> | release-complete | | | cancelled | ----------------> | cancelled | | <--------------- | | ----------------> | Ott, et. al. Expires August 24, 2001 [Page 36] Internet-Draft An Mbus Profile for Call Control February 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Ott, et. al. Expires August 24, 2001 [Page 37]