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]