One document matched: draft-taylor-ipdc-reqts-00.txt
INTERNET DRAFT P. Tom Taylor
Category: Informational Nortel (Northern Telecom)
Title: draft-taylor-ipdc-reqts-00.txt Date: September 1998
Requirements for A Telephony Gateway Device Control Protocol
<draft-taylor-ipdc-reqts-00.txt>
Status of this Memo
This document is an Internet-Draft. 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 learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes the requirements for a protocol to control a
device which supports telephone lines or trunks on one side and
packet network ports on the other. The primary functions of the
device are to make, modify, and break media stream connections
between these edge-points, to perform operations on the media
streams, and to detect and report specific events associated with
those streams or the edge-points. This device may also terminate call
signalling which it processes itself and/or passes to the device
which controls it. Using the terminology provided by Cuervo et al
[1], the device just described is a Media Gateway, and is controlled
by a Media Gateway Controller.
The requirements for the protocol separate into two major parts:
operational and functional. The operational requirements are
concerned with reliability and security of control messaging, control
session startup and takedown, handling of control session failures,
and control system performance. The functional requirements cover
connection control, media processing, event notification, and
Taylor expires March 1999 [Page 1]
INTERNET DRAFT Device Control Requirements September 1998
resource status tracking. They may also include signalling backhaul
from the Media Gateway to the Media Gateway Controller.
The protocol should extend to the control of devices which contain
telephony edge-points only (such as digital cross-connects) or packet
network ports only (such as transcoders or announcement servers).
Table Of Contents
1.0 Introduction
1.1 Terminology
1.2 Definitions
1.3 Application Examples
1.3.1 Network Access Server
1.3.2 Internet Telephony Media Gateway
1.3.3 Continuity Test
1.3.4 Interactive Voice Response Unit
1.3.5 Digital Cross-Connect
1.4 Network Context
1.4.1 Distribution of Signalling and Control Functions
1.4.1.1 Device Control and Tone-Based Signalling Schemes
1.4.1.2 Transparent Carriage of Signalling Protocol Data
1.4.2 Possible Control Arrangements
2.0 Operational Requirements
2.1 Reliability
2.2 Failure Recovery
2.3 Startup and Takedown
2.4 Control Security
2.5 Performance
3.0 Functional Requirements
3.1 Connection Control
3.2 Tones and Announcements
3.3 Event Notification and Scripts
3.4 Tone Signalling
3.5 Signalling Backhaul
3.6 Resource Status Tracking
3.7 Other
3.6.1 Vendor Extensibility
3.6.2 Architectural Flexibility
4.0 Security Aspects
5.0 References
6.0 Acknowledgements
Taylor expires March 1999 [Page 2]
INTERNET DRAFT Device Control Requirements September 1998
7.0 Author's Address
1.0 Introduction
A broadening class of network configurations exists within the
internet, such that one device which switches and processes media
streams is controlled by another which handles call signalling.
Cuervo et al [1] give several examples of such devices sitting on the
boundary between the telephone and packet data networks. One is the
Network Access Server, which terminates telephony network connections
on modems and establishes connections through the packet network to
serve them. Another is the media handling part of Voice over IP
gateways, where this part is packaged separately from the call
processing part.
Cuervo et al apply the term "Media Gateway" to the function which
processes and switches media streams, and "Media Gateway Controller"
to the function which controls the operation of the Media Gateway
function. Where these functions are packaged in separate devices, a
protocol is needed to carry commands, responses, and notifications
between them.
The primary intent of this document is to describe the requirements
which apply to a media gateway control protocol. However, such a
protocol also has application to devices which lie entirely within
the packet network rather than on its boundary, and even to devices
which serve only telephone network terminations, provided that they
can be controlled through the IP network. A first broad requirement
is therefore that the scope of application of the protocol should
include such devices.
1.1 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for the device control protocol.
1.2 Definitions
Edge-Point
A general term for a point on the edge of a given Media Gateway
where a media stream enters and/or leaves the device. Physically,
edge-points consist of line or trunk appearances on the telephone
Taylor expires March 1999 [Page 3]
INTERNET DRAFT Device Control Requirements September 1998
network side, or one or a pair of RTP/RTCP port pairs on the
packet side, depending on whether the media stream is uni- or bi-
directional. [On the packet side, should this be broader?]
Call Signalling
A series of messages between two devices conveying an user's
request for service, possibly requesting more information about
that request, and coordinating the actions of the devices which
provide that service.
Device Control
Messages between a Media Gateway Controller ("controller", for
short) and a Media Gateway causing the latter to perform specific
actions required to satisfy an user's request for service.
Media Stream
A flow of information which appears in the telephony network as an
analogue signal, typically digitally encoded, and in the packet
network as a stream of packets, typically encapsulated by RTP [3]
or PPP [4]. In this document, the term "media stream" implies a
two-way flow of information. The terms "incoming media stream"
and "outgoing media stream" imply one-way flows relative to a
specified edge-point of a device.
1.3 Application Examples
This section gives a series of examples of potential applications of
Media Gateways, in order to motivate the statements of requirements
in sections 2 and 3 of this document. In this section only, it is
generally assumed that all call signalling and control processing are
done on devices other than the Media Gateway device, except for DTMF
signalling for specific purposes (authorization code in section
1.3.2, Interactive Voice Response Unit controls in section 1.3.4).
This assumption is relaxed in section 1.4.1.
1.3.1 Network Access Server
A Network Access Server (NAS) is a Media Gateway connecting between
telephony bearers carrying modem signals on one side and the packet
network on the other. All of its services are call-associated, where
the call is between an user device within the telephone network and
the call processing application associated with the NAS controller.
Calls may be incoming or outgoing relative to the telephone network.
For an incoming call, the typical exchanges of information between
the Media Gateway and the controller would be as follows:
Taylor expires March 1999 [Page 4]
INTERNET DRAFT Device Control Requirements September 1998
a) A control request to the NAS causes it to assign a modem
termination to the call and connect it to the designated incoming
trunk or line. It may be necessary for the controller to tell the
NAS what codec is in use on the telephony side of the call. The NAS
must tell the controller if the request fails.
b1) If the NAS is responsible for obtaining authorization and
routing information (e.g. from a RADIUS server) it must be given the
calling and called number information provided by the telephone
network. The NAS must tell the controller if the RADIUS request
fails.
b2) Alternatively, if some other device obtains the authorization
and routing information, the NAS must be told what IP address to
assign to the caller's device, to what IP address the caller's data
should be sent, and any other policy information governing the NAS's
transformation of the user's data into packets.
c) The NAS must tell the controller when the user completes
his/her data session. (It is assumed that the NAS then automatically
frees the modem and clears the connection between the line or trunk.
Otherwise another message is needed from the controller to trigger
this action.)
A variant on the incoming call sequence may require termination of
the initial call after the first exchange with the RADIUS server,
followed by a call back to the caller's modem using a telephone
number provided by RADIUS. If this is the case, and the NAS is the
device which communicated with the RADIUS server, the NAS must so
inform the controller. It may or may not be necessary to clear the
existing modem connection, depending on whether the incoming trunk
can be reused for the outgoing call.
An outgoing call is triggered by the establishment of a packet
connection (PPP, L2TP) from the calling host to the NAS. The typical
exchanges of information in this case are as follows:
a) The NAS notifies the controller that a call to the telephone
network is required and provides the called party's telephone number
to the controller.
b) The controller assigns the outgoing line or trunk, or asks the
NAS to select a free trunk from a specified group; whichever end
makes the selection must inform the other.
c1) The controller establishes the call and notifies the NAS when
the connection is complete.
Taylor expires March 1999 [Page 5]
INTERNET DRAFT Device Control Requirements September 1998
c2) Alternatively the controller asks the NAS to notify it when
modem tone is detected on the selected line or trunk.
d) The session ends in the same way as an incoming call.
An important variant on this procedure involves multiple bearers
associated with the same call. A procedure such as BONDING is used
to establish the association. The NAS must inform the controller
that the various connections are correlated [or vice versa -- check
details].
1.3.2 Internet Telephony Media Gateway
The Internet Telephony Media Gateway could be an access gateway,
terminating one or more user lines directly, or a trunking gateway,
terminating trunks from a switch on the telephone network side.
Requirements for device control will be similar in nature for both
applications, except that the access gateway must deal with line-
associated signalling and supervision. This is ignored here for
simplicity, but illustrated in section 1.4.1.
The following exchanges of information are necessary to handle a
voice call incoming from the telephone network:
a) The controller may tell the Media Gateway to reserve the
incoming trunk or line so that no other call can claim it.
b) The controller may either allocate ports for a two-way RTP
connection through the packet network and tell the Media Gateway to
reserve them, or ask the Media Gateway to allocate ports and report
back.
c) The controller tells the Media Gateway to apply audible ring-
back tone back toward the caller.
d) In preparation for final cut-through, which must be done within
40 milliseconds [check this] of the controller's receipt of a signal
indicating that the called party has answered to avoid clipping of
the called party's first words, the controller also tells the Media
Gateway to set up a connection between the line or trunk appearance
and the RTP session, but not to enable the transfer of content in
either direction until further notice.
The connection has a number of attributes:
-- codec in use on the telephone network side of the connection (if
not already known from configuration data)
-- codec to be used on the packet network side of the connection
Taylor expires March 1999 [Page 6]
INTERNET DRAFT Device Control Requirements September 1998
-- whether echo cancellation is to be applied
-- loss padding to be applied in each direction
-- method to be used to request transport QOS.
The user may also have requested confidentiality service. In that
case, further attributes must be passed to the Media Gateway
describing the encryption to be performed on the packet stream.
e) The controller tells the Media Gateway to stop applying
ringback tone and to complete the two-way connection between the line
or trunk and the RTP session.
f) When the call ends, the controller tells the Media Gateway to
break the connection and free the resources assigned to it.
g) The Media Gateway may report QOS statistics derived from RTCP
[3] reports to the controller, either at the end of the call or
periodically during the call.
The information exchanges for a call which is outgoing to the
telephone network are very similar to those for an incoming call.
Ringback tone will not be applied to the outgoing telephone network
connection, but if the Media Gateway is an access gateway, the
controller will direct it to apply ringing to the called line.
If an incoming call fails to complete successfully, the controller
may direct the Media Gateway to connect the line or trunk to an
announcement or to apply a busy or other tone to it. If the
announcement is to come from a separate announcement server device, a
one-way incoming RTP connection will be required to carry it. The
controller must direct the Media Gateway to release the outgoing RTP
session ports reserved for the original call and to make a one-way
connection from the incoming RTP port to the line or trunk. When the
user ends the call, the controller must tell the Media Gateway to
release all connections and resources as before.
At times it will be necessary to preserve a connection but
temporarily terminate the transfer of information across it (as with
call hold service). Typically this will be followed by the making of
a second connection involving the same Media Gateway edge-point (as
in consultation hold service or operator handling of a call). The
edge-point concerned may be either on the telephone network or the
packet network side of the Media Gateway.
Another possibility is that the Media Gateway contains a conference
bridge. The controller may direct that the Media Gateway make
connections from different telephone network or packet network edge-
points on the Media Gateway to specific ports on this bridge.
Taylor expires March 1999 [Page 7]
INTERNET DRAFT Device Control Requirements September 1998
The final possibility considered in this section is the case where
the Media Gateway must prompt an user to enter an authorization code
before continuing with an incoming call, must collect the digits
entered by the user, and must report the results to the controller.
In detail, a variety of sequences of information exchanges may be
used to achieve this, but here is a typical example:
a) The controller tells the Media Gateway to execute the following
sequence of actions (i.e. script):
i) listen for DTMF signalling on the incoming line or trunk
ii) apply a prompt tone requesting the input of the authorization
code
iii) collect digits until the earlier of two events occurs:
-- all N required digits have been entered, where N is given by
the controller, or
-- digit collection times out, with timing given by the
controller.
iv) report either the digits collected or the timeout failure.
b) The Media Gateway makes its report.
1.3.3 Continuity Test
An SS7-signalled call, whether it involves a NAS or an Internet
Telephony Media Gateway, will frequently begin with a request to
check the continuity of the media connection between the Media
Gateway and the upstream bearer path. There are two possibilities:
that the Media Gateway runs the test, or that it provides the
loopback.
In the first case, the following sequence of information exchanges
occurs:
a) The controller specifies a series of actions as follows:
i) It specifies a edge-point, representing the termination of
the network connection to be tested on the Media Gateway.
ii) It requests that continuity test tone be applied to the
indicated edge-point in the outgoing direction for a specified
duration.
iii) It requests that the Media Gateway listen for continuity test
Taylor expires March 1999 [Page 8]
INTERNET DRAFT Device Control Requirements September 1998
tone incoming on the given edge-point, again for a specified
duration.
iv) It requests that the Media Gateway report whether it has
detected incoming continuity test tone or not within the specified
time period, then terminate the test.
b) The Media Gateway reports the result of the test as requested.
At the other end of the connection, the following information
exchanges take place:
a) The controller requests that the Media Gateway place a given
edge-point into loopback state.
b) Subsequently, the controller requests that the Media Gateway
disconnect the two sides of the edge-point from each other.
1.3.4 Interactive Voice Response Unit
A Media Gateway associated with an Interactive Voice Response Unit
plays announcements and tones to the user, listens for DTMF
signalling, and either reports detected signalling to the controller
or takes subsequent actions based on a script provided by the
controller. To this point, the operation of the Interactive Voice
Response Unit involves no new information exchanges beyond those
already suggested in section 1.3.2, except that the scripts may be
more elaborate.
The new aspect is the recording and playback of messages. This
requires the media handling gateway to create uni-directional
connections between the edge-point on the user side and the recording
or playback unit respectively.
It is also possible that the Media Gateway will be told to listen for
silence during recording, time out after a certain duration, and take
down the connection.
A complete script will require more specialized device control
actions: for skipping back through a given message or between
messages, for example. Because of this, requirements for the media
handling part of an Interactive Voice Response Unit will be [unless
decided otherwise] specified in a separate document.
1.3.5 Digital Cross-Connect
Taylor expires March 1999 [Page 9]
INTERNET DRAFT Device Control Requirements September 1998
A digital cross-connect operates only on digital channels, not on
packet streams. The basic information exchange with the controller
is the latter's request to connect a specified channel to another
specified channel, or to break a connection. Additional information
may be specified when a connection is made, governing the processing
of the digital stream running through it. Detailed requirements for
this application are for further study.
1.4 Network Context
This section considers aspects of the architecture of the controller
and the Media Gateway which lead to the recognition of additional
requirements for device control.
1.4.1 Distribution of Signalling and Control Functions
The basic hypothesis of this document is that at least some of the
Media Gateway Control function required to handle a call resides on a
physical device which is different from the one housing the Media
Gateway function. This leaves room for a number of different
possible arrangements for routing and processing of the various call
signalling protocols which may be in use in a given network. There
are four basic possibilities, where "incoming' means the direction
from which the call was initiated and "outgoing" is the direction to
which it is propagated:
(i) The incoming-side call signalling is processed at the Media
Gateway device, while the outgoing-side call signalling is processed
at the controller.
(ii) The incoming-side call signalling is processed at the
controller, while the outgoing-side call signalling is processed at
the Media Gateway device.
(iii) Call signalling for both sides is processed at the controller.
One variant on this case is that call signalling for either side is
tunneled through the Media Gateway device to/from the controller, so
that the latter is its logical endpoint.
(iv) Call signalling for both sides is processed at the Media
Gateway device, but the controller must be involved because it
contains the service control logic or owns the Media Gateway's
resources.
The application descriptions in section 1.3 assumed case (iii).
Taylor expires March 1999 [Page 10]
INTERNET DRAFT Device Control Requirements September 1998
Cases (i) and (ii) require the operation of one or more signalling
protocols between the controller and the Media Gateway device. The
choice of which protocols to use for which combinations of external
signalling protocols is in general a matter for call signalling
experts, and is beyond the scope of device control. However, device
control can reasonably encompass the special case of tone-based
signalling. Furthermore, it may be desirable to provide a mechanism
for the transparent transfer of signalling information within a
device control session.
The detailed requirements imposed by case (iv) require further study.
They may be implementation-specific and not susceptible to
standardization.
1.4.1.1 Device Control and Tone-Based Signalling Schemes
The operation of tone-based signalling schemes can be viewed as a
candidate for inclusion in a device control protocol both because
analogue signalling is inseparable from the lines and trunks on which
it appears, and because of the relatively limited scope of such
schemes. Note that tone-based signalling (such as DTMF for lines, MF
or R2 for trunks) relies both on tones themselves and on
"supervision" such as off-hook and on-hook for lines, or wink,
seizure, and release for trunks, which are signalled by other means.
The details of such signalling vary from country to country and over
different trunk and line types within a country. Because of this,
the detailed processing of signalling and supervision is beyond the
scope of the requirements provided in this document. Nevertheless,
certain basic concepts, such as off-hook/seizure, on-hook/release,
and the individual digits, are sufficiently common to all tone-based
signalling schemes that their representation within a device control
protocol could be standardized.
Looking at the matter another way, it should be possible for
individual implementations of the device control protocol to extend
this signalling representation scheme to cover the additional events
conveyed by specific signalling schemes.
Now, assuming that the device control protocol meets these
requirements for the representation of signalling events, what uses
of these representations should the protocol allow? There are two
possibilities, depending on whether the Media Gateway acts merely as
a sender and receiver of signals (i.e. a tunnel for them, as a
variant of case (iii) in the section 1.4.1), or is also capable of
taking actions based upon them.
In the first case, the protocol must support three types of
Taylor expires March 1999 [Page 11]
INTERNET DRAFT Device Control Requirements September 1998
signalling related messages:
-- requests from the controller to turn monitoring for signalling
events on and off,
-- requests from the controller for specific signalling events to be
generated, and
-- messages from the media handling gateway reporting the detection
of specific signalling events.
Because signalling events tend to happen in batches (particularly
when numbers are being passed), the protocol should provide for
efficient handling of batched events. For incoming signalling, this
implies the use of mechanisms such as expected digit counts and
timeouts.
If the Media Gateway can act on detected signalling events, the
possibility arises that it can be programmed to do so without the
need for intervention from the controller. This amounts to
processing of the signalling, and thus places us into any one of
cases (i), (ii), or (iv) of section 1.4.1, so that we cannot state
any specific new requirements on the device control protocol proper.
The complexity of telephone network numbering plans introduces an
intermediate possibility: that the Media Gateway may be programmed,
but the program for a given line or trunk must be updated as the call
proceeds to take account of the information the controller has
already received. Two basic mechanisms for this purpose come to
mind: the device control message may itself contain a program,
written in a pre-defined scripting language, or alternatively the
device control message may invoke and provide parameters for a named
script or applet. The device control protocol should provide support
for at least one of these mechanisms.
1.4.1.2 Transparent Carriage Of Signalling Protocol Data Units
Under certain circumstances it may be desirable to carry unmodified
signalling between the controller and the Media Gateway; this could
be in either direction. One example of this is where the Media
Gateway can process Q.931 (ISDN signalling), but is also presented
with QSIG signalling from a PBX which the network operator is willing
to transport transparently to the far end. Another more dubious
example is where the call signalling is being tunneled through the
Media Gateway to/from the controller.
As a general mechanism to support such operations, the device control
protocol may be required to support the transfer of signalling
protocol data units as opaque data, possibly labelled by a protocol
discriminator. [This requirement may be more properly assessed by
the signalling transport working group.]
Taylor expires March 1999 [Page 12]
INTERNET DRAFT Device Control Requirements September 1998
1.4.2 Possible Control Arrangements
This section is concerned with the possible degrees of redundancy at
either end of the device control session, and their impact on the
requirements for recovery from failures.
Control redundancy is commonly characterized in terms of a
temperature metaphor, as if controllers were engines. In these
terms, one can have:
a) No alternate controller. If the controller fails, it may need
to retrieve current state from each device under its control upon
recovery, or it may have to reset those devices. (It is also
possible that at least some state was saved in persistent memory from
which it can be retrieved without going to the controlled devices.)
b) Cold standby, implying that the alternate controller has no
knowledge of current state and may have to retrieve it from the
controlled devices or reset them before taking over.
c) Warm standby, implying that the alternate controller always has
some knowledge of current state. It may either retrieve additional
state from the controlled devices or invoke a partial reset in
specific cases where recovery is impossible.
d) Hot standby, implying that the alternate controller has full
knowledge of current state and can take over without loss of service.
These different cases suggest a number of requirements on the device
control protocol relating to resets and querying of existing states,
which are spelled out in detail in section 2.2. The one point to
consider here is the impact of such operations on protocol
performance.
The first potential problem is a fairly obvious one, that recovery
may be delayed by the sheer volume of messaging required to achieve
it. This can be mitigated by careful design of the recovery process,
to ensure that the most critical elements get highest priority. The
requirement on the device control protocol will be to support
subdivision of the recovery process into the necessary steps.
The second potential problem is that of message fragmentation when
large volumes of information are passed at once. If UDP is used as
the transport protocol, the device control protocol may have to
support either end-to-end negotiation of maximum application message
length, or recovery from message segmentation.
Taylor expires March 1999 [Page 13]
INTERNET DRAFT Device Control Requirements September 1998
2.0 Operational Requirements
This section is concerned with requirements on the design of the
protocol independently of the content to be carried.
2.1 Reliability
R2.1.1 Transport level reliability: device control messages MUST be
delivered reliably, in the order in which they were sent.
R2.1.2 Presentation level reliability: the device control protocol
MUST provide mechanisms to ensure that the originator of a message is
made aware when that message is rejected or not understood by the
receiving entity.
R2.1.3 Application level reliability: the device control protocol
MUST provide the means for the originator of a message to determine
if the recipient of that message failed to process it.
2.2 Failure Recovery
R2.2.1 The device control protocol MUST provide the means to detect
failure of the control session within a locally-configurable time
period (of the order of seconds).
R2.2.2 The device control protocol MUST provide the means for an
alternative controller instance to take over control of a Media
Gateway when a control session failure is detected.
R2.2.3 The device control protocol MUST provide the means for a
controller to negotiate handoff of control of a given Media Gateway
to another controller.
R2.2.4 The device control protocol MUST provide the means for a
controller to retrieve in controlled fashion the details on all
persistent processes (such as connections and running scripts) and
all resource reservations currently active in a Media Gateway.
R2.2.5 The device control protocol SHOULD provide the means for a
controller to request that a Media Gateway release all connections
and resources and restore default initial conditions. Comment: this
is obviously a mechanism of last resort for recovery of stranded
resources.
R2.2.6 It is DESIRABLE that the device control protocol allow the
controller (i) to associate a session identifier with each command
which assigns resources and creates persistent processes in the Media
Taylor expires March 1999 [Page 14]
INTERNET DRAFT Device Control Requirements September 1998
Gateway, and (ii) to release all resources and processes associated
with a given session identifier, without having to list these
resources explicitly. Justification: if an alternate controller can
retrieve from another source a mapping between the call identifiers
used in signalling and the session identifiers potentially used in
device control, then when a given call is cleared the controller can
release the associated resources without knowing what they are. This
reduces the urgency for the controller to use the retrieval
mechanisms postulated in R2.2.3.
R2.2.7 The device control protocol MUST provide the means for a
controller to temporarily reduce the rate of message generation at
the Media Gateway, to allow the controller to recover from overload.
2.3 Startup and Takedown
R2.3.1 The device control protocol MUST allow either the controller
or the Media Gateway to initiate control session startup.
R2.3.2 The device control protocol MUST provide for the negotiation
of protocol version as part of control session startup.
R2.3.3 The device control protocol SHOULD provide a means for
negotiating the support of optional or vendor-specific portions of
the protocol.
R2.3.4 The device control protocol MUST allow graceful termination of
a control session.
2.4 Control Security
Control sessions are often run over physically separate links. When
they are not, the primary threats are impersonation and denial of
service attacks. Control sessions will typically run directly
between the controller and the Media Gateway, without an intervening
proxy. This leads to the following requirements.
R2.4.1 The device control protocol MUST provide for authentication of
the originator of each message.
R2.4.2 The device control protocol MUST contain provisions to prevent
denial of service attacks from being effective.
2.5 Performance
Taylor expires March 1999 [Page 15]
INTERNET DRAFT Device Control Requirements September 1998
The key dimensions of device control protocol performance are
response time and scalability. Response time requirements depend on
the application; they are more stringent for a VoIP gateway than for
other applications. Response times for VoIP gateways MUST be rapid
(of the order of tens of milliseconds) to conform to the requirements
of the telephone network. In particular, connection setup for a
voice path MUST be rapid following called user answer, so that the
initial portion of the called user's greeting is not clipped.
"Response time" here refers to the sum of times taken to formulate
the command message at the controller, transmit it to the Media
Gateway, and process and execute it within the Media Gateway.
R2.5.1 The design of the device control protocol MUST be aimed at
minimizing response time as defined in the preceding paragraph, for
time-critical device control operations.
R2.5.2 The design of the device control protocol MUST allow one
controller to control tens of thousands of Media Gateways, and one
Media Gateway to support thousands of edge-points.
3.0 Functional Requirements
This section is concerned with requirements on the design of the
device control protocol related to its applications and the content
they imply.
3.1 Connection Control
R3.1.1 The device control protocol MUST support requests to create,
modify, and delete media stream connections between:
* an edge-point and another edge-point on the same device
* a line or trunk and a data modem
* a line or trunk and a FAX modem
* an edge-point and the port of a conference bridge
* an edge-point and an internal sink (e.g. recorder) for media
content
* [what else?].
R3.1.2 Extensibility to arbitrary resource types: The device control
protocol SHOULD support requests to create, modify, and delete
connections between edge-points and arbitrary named resources where
the assumption is that the controller and Media Gateway understand
what the names "mean".
R3.1.3 The device control protocol MUST support specification of the
following attributes of a connection either when creating or when
Taylor expires March 1999 [Page 16]
INTERNET DRAFT Device Control Requirements September 1998
modifying a connection:
* directionality: no media flow, one way in a specified direction,
or two ways
* whether echo cancellation is to be applied
* loss padding to be applied on the telephony side of a connection
* coding and compression algorithms to be applied in each direction
of flow
* whether the media stream should be encrypted, and if so, the
parameters to be used to accomplish encryption and decryption
* the method by which transport QOS is to be requested from the
packet network
* [what else?].
R3.1.4 Where connection to a data modem is requested, the device
control protocol MUST support the carriage of the parameters needed
for the NAS to complete the connection through the packet network,
specifically including:
* called number
* calling number.
R3.1.5 The device control protocol SHOULD support a request from the
Media Gateway to the controller to make a call to a specified
telephone number.
R3.1.6 The device control protocol MUST support responses from the
Media Gateway indicating the fact and cause of failure to execute a
request to create, modify, or delete a connection.
R3.1.7 The device control protocol SHOULD support the ability to have
the Media Gateway choose and report back the identity of a specific
edge-point to be used for a connection, within constraints provided
by the controller. Examples of this are selection of an idle trunk
from a named trunk group, or selection of one or two free RTP/RTCP
port pairs depending on the required directionality of the
connection.
R3.1.8 The device control protocol MUST support the creation and
deletion of loopback connections at specified edge-points. To
support testing and debugging of device operations, the device
control protocol SHOULD also support the creation of loopbacks at one
edge-point back through the Media Gateway towards another edge-point
to which it is connected.
R3.1.9 The device control protocol MUST support the retrieval of
statistics indicating the quality of service received on a given
packet connection.
Taylor expires March 1999 [Page 17]
INTERNET DRAFT Device Control Requirements September 1998
3.2 Tones and Announcements
R3.2.1 The device control protocol MUST support requests for the
Media Gateway to play out and to stop playing out to a specified
edge-point one or a sequence of named tones and/or announcements.
R3.2.2 For each tone or announcement to be played, it MUST be
possible to specify the maximum amount of time the tone or
announcement is to be played out or, for announcements specifically,
how often the announcement should be repeated before discontinuing
it.
R3.2.3 The device control protocol MUST support a mechanism whereby
it is possible to associate the commencement and/or termination of
the playout of specific tones or announcements with specific events
involving the endpoint. This is a specific case of the general
scripting capability called for requirement R3.3.2.
R3.2.4 It is DESIRABLE that the device control protocol be capable of
configuring tone specifications consisting of the following aspects:
* tone name
* number of segments
* for each segment: whether it consists of silence or tone; if the
latter, what frequency or frequencies to use, at what loudness
level; the segment duration.
3.3 Event Notification and Scripts
See the final paragraphs of section 1.4.1.1 for background on the
scripting requirements given here.
R3.3.1 The device control protocol MUST support requests for the
Media Gateway to start and stop monitoring for specific events
observed at an edge-point. Many of the events of interest are
covered under tone signalling, in the next section. However, there
is a specific requirement to detect and report on:
* modem tone
* FAX tone
* various test tones, including continuity test [with national
variations]
* busy tone [with national variations]
* reorder tone [with national variations]
* [what else?].
R3.3.2 The device control protocol MUST provide a mechanism whereby
the controller can specify mixed sequences of events to be detected
and actions to be taken (scripting capability). It MUST be possible
Taylor expires March 1999 [Page 18]
INTERNET DRAFT Device Control Requirements September 1998
to specify the following within these sequences:
* conditional subsequences, to be executed only if specified events
occur
* repeated subsequences (loops), where the loop is terminated by a
specified event
* conditions under which the entire script is deactivated,
regardless of which specific step in the script is currently
being executed. For example, a script applied in association
with a connection between two edge-points may be required
to deactivate when the connection is deleted.
R3.3.3 The device control protocol MUST provide the means to
simultaneously create or modify a connection and invoke a script on
or request a report from either or both edge-points involved in the
connection.
R3.3.4 The device control protocol must provide a means of tagging
script invocations, such that the controller can refer to a specified
script running at a specifed endpoint in subsequent messages.
R3.3.5 The device control protocol MUST provide the means for the
controller to:
* determine what scripts are active at a given edge-point
* deactivate a specified script or all scripts active at a given
edge-point.
3.4 Tone Signalling
See the discussion in section 1.4.1.1 for background. Detection and
generation of tone signalling are events and actions respectively to
which the scripting requirements of the previous section may apply.
R3.4.1 The device control protocol MUST allow the controller to
request the generation of tone signalling to specified edge-points.
Such requests will include designation of the symbols to be sent (see
requirement R3.4.3), the duration of each symbol, and the time
between successive symbols.
R3.4.2 The device control protocol MUST allow the controller to
enable and disable the reporting of tone signalling received from
specified edge-points. To avoid unnecessary messaging, it must be
possible for the controller to specify alternative patterns of
signals, the completion of which should trigger a report to the
controller. The controller should also be able to specify a timeout
period beyond which collected events should be reported regardless of
whether a pattern has been completed.
Taylor expires March 1999 [Page 19]
INTERNET DRAFT Device Control Requirements September 1998
R3.4.3 It is DESIRABLE that the device control protocol provide a
language for the reporting of events likely to be encountered with
the the most common tone signalling systems. Examples of such events
are:
* off- and on-hook, hook-flash, the digits "0" through "D", and the
pound "#" and star "*" for tone signalling on lines
* wink, seizure, release, the digits "0" through "9", the elements
"K0" through "K2", and the elements "S0" through "S3"
for signalling on trunks.
R3.4.4 As a further elaboration of the basic scripting requirement
R3.3.2, the protocol MUST allow invocation of a script combining the
detection of specified signalling events with actions to be taken
upon detection. Examples of such use might be to program the
sequence: "Detect off-hook. Apply dial tone. Listen for digits.
Remove dial tone after a digit is detected. Collect digits according
to specified parsing and timeout rules. Report the results."
3.5 Signalling Backhaul
R3.5.1 As suggested in section 1.4.1.2, it MAY BE DESIRABLE that the
device control protocol provide a means of passing signalling data
units transparently, along with an identification of the signalling
protocol involved.
3.6 Resource Status Management
R3.6.1 The device control protocol MUST provide the means for the
controller to track failure conditions affecting call processing.
Specifically:
* If a failure condition within the Media Gateway device has
resulted in its failure to execute a request from the controller,
means MUST be provided in the Media Gateway's response to the
controller to identify the failure condition for further
reference.
* It MUST be possible for the controller to determine when
the failure condition has cleared, either by way of a direct
notification within the device control protocol itself or by
other means (e.g. SNMP).
R3.6.2 The identification of the failure condition SHOULD be such as
to allow the controller to determine the scope of the failure (e.g.
specific trunk, entire transmission facility, etc.).
R3.6.3 The device control protocol MUST provide the means for the
Taylor expires March 1999 [Page 20]
INTERNET DRAFT Device Control Requirements September 1998
controller to block and unblock the use of specified trunks.
3.7 Other
3.7.1 Vendor Extensibility
R3.7.1.1 Because device control is a fairly basic function, it is
highly probable that vendor-specific commands, indications, and
attributes or extensions to attributes will be required in any
concrete situation. The device control protocol MUST be easy to
extend in these ways.
3.7.2 Architectural Flexibility
R3.7.2.1 The device control protocol MUST be able to operate
successfully regardless of the location of individual call signalling
functions and related call processing functions. It MUST also be
able to operate regardless of the existing arrangements for control
redundancy.
4.0 Security Aspects
Security requirements relating to the secure operation of an IP
device control session are discussed in section 2.4 above. Security
requirements for the handling of media streams include
confidentially, integrity, and possibly authentication. [ITU-T
Recommendation H.235 has a good discussion of security requirements,
the applicable parts of which could be brought into this document.]
5.0 References
[1] F. Cuervo, N. Greene, M. Holdredge, L. Ong, and C. Huitema,
"SS7-Internet Interworking - Architectural Framework", draft-greene-
ss7-arch-frame-00.txt, July 1998.
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Internet Engineering Task Force, March 1997
[3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications," RFC 1889, Internet
Engineering Task Force, January 1996.
Taylor expires March 1999 [Page 21]
INTERNET DRAFT Device Control Requirements September 1998
[4] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1548,
Internet Engineering Task Force, December 1993.
6.0 Acknowledgements
The following individuals contributed to the initial definition of
requirements for the IP device control protocol, from which this
document was derived:
Ilya Akramovich, Bob Bell, Andrew Dugan, Ike Elliott, Cary
Fitzgerald, Jan M. Gronski, Tom Hess, Geoff Jordan, Tony Lam, Pete
O'Connell, Scott Pickett, Shyamal Prasad, Eric Presworsky, Paul
Richards, Dale Skran, Louise Spergel, David Sprague, Raj Srinivasan,
and Michael Thomas.
7.0 Author's Address
Questions about this memo can be directed to:
P. Tom Taylor
Nortel (Northern Telecom)
M/S 097, SKY,
P.O. Box 3511, Station C,
Ottawa, Ontario,
Canada
Phone: 1-613-765-4167
Fax: 1-613-765-7236
E-mail: taylor@nortel.com
Taylor expires March 1999 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-24 10:28:28 |