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]