idnits 2.17.1 draft-taylor-ipdc-reqts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 420 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...ment is an I...' == Line 12 has weird spacing: '...cuments of t...' == Line 13 has weird spacing: '...ups may also ...' == Line 17 has weird spacing: '... and may be...' == Line 18 has weird spacing: '...me. It is i...' == (415 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1998) is 9355 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-greene-ss7-arch-frame-00 ** Obsolete normative reference: RFC 1889 (ref. '3') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1548 (ref. '4') (Obsoleted by RFC 1661) Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT P. Tom Taylor 3 Category: Informational Nortel (Northern Telecom) 4 Title: draft-taylor-ipdc-reqts-00.txt Date: September 1998 6 Requirements for A Telephony Gateway Device Control Protocol 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes the requirements for a protocol to control a 30 device which supports telephone lines or trunks on one side and 31 packet network ports on the other. The primary functions of the 32 device are to make, modify, and break media stream connections 33 between these edge-points, to perform operations on the media 34 streams, and to detect and report specific events associated with 35 those streams or the edge-points. This device may also terminate call 36 signalling which it processes itself and/or passes to the device 37 which controls it. Using the terminology provided by Cuervo et al 38 [1], the device just described is a Media Gateway, and is controlled 39 by a Media Gateway Controller. 41 The requirements for the protocol separate into two major parts: 42 operational and functional. The operational requirements are 43 concerned with reliability and security of control messaging, control 44 session startup and takedown, handling of control session failures, 45 and control system performance. The functional requirements cover 46 connection control, media processing, event notification, and 47 resource status tracking. They may also include signalling backhaul 48 from the Media Gateway to the Media Gateway Controller. 50 The protocol should extend to the control of devices which contain 51 telephony edge-points only (such as digital cross-connects) or packet 52 network ports only (such as transcoders or announcement servers). 54 Table Of Contents 56 1.0 Introduction 57 1.1 Terminology 58 1.2 Definitions 59 1.3 Application Examples 60 1.3.1 Network Access Server 61 1.3.2 Internet Telephony Media Gateway 62 1.3.3 Continuity Test 63 1.3.4 Interactive Voice Response Unit 64 1.3.5 Digital Cross-Connect 65 1.4 Network Context 66 1.4.1 Distribution of Signalling and Control Functions 67 1.4.1.1 Device Control and Tone-Based Signalling Schemes 68 1.4.1.2 Transparent Carriage of Signalling Protocol Data 69 1.4.2 Possible Control Arrangements 71 2.0 Operational Requirements 72 2.1 Reliability 73 2.2 Failure Recovery 74 2.3 Startup and Takedown 75 2.4 Control Security 76 2.5 Performance 78 3.0 Functional Requirements 79 3.1 Connection Control 80 3.2 Tones and Announcements 81 3.3 Event Notification and Scripts 82 3.4 Tone Signalling 83 3.5 Signalling Backhaul 84 3.6 Resource Status Tracking 85 3.7 Other 86 3.6.1 Vendor Extensibility 87 3.6.2 Architectural Flexibility 89 4.0 Security Aspects 91 5.0 References 93 6.0 Acknowledgements 94 7.0 Author's Address 96 1.0 Introduction 98 A broadening class of network configurations exists within the 99 internet, such that one device which switches and processes media 100 streams is controlled by another which handles call signalling. 101 Cuervo et al [1] give several examples of such devices sitting on the 102 boundary between the telephone and packet data networks. One is the 103 Network Access Server, which terminates telephony network connections 104 on modems and establishes connections through the packet network to 105 serve them. Another is the media handling part of Voice over IP 106 gateways, where this part is packaged separately from the call 107 processing part. 109 Cuervo et al apply the term "Media Gateway" to the function which 110 processes and switches media streams, and "Media Gateway Controller" 111 to the function which controls the operation of the Media Gateway 112 function. Where these functions are packaged in separate devices, a 113 protocol is needed to carry commands, responses, and notifications 114 between them. 116 The primary intent of this document is to describe the requirements 117 which apply to a media gateway control protocol. However, such a 118 protocol also has application to devices which lie entirely within 119 the packet network rather than on its boundary, and even to devices 120 which serve only telephone network terminations, provided that they 121 can be controlled through the IP network. A first broad requirement 122 is therefore that the scope of application of the protocol should 123 include such devices. 125 1.1 Terminology 127 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 130 indicate requirement levels for the device control protocol. 132 1.2 Definitions 134 Edge-Point 135 A general term for a point on the edge of a given Media Gateway 136 where a media stream enters and/or leaves the device. Physically, 137 edge-points consist of line or trunk appearances on the telephone 138 network side, or one or a pair of RTP/RTCP port pairs on the 139 packet side, depending on whether the media stream is uni- or bi- 140 directional. [On the packet side, should this be broader?] 142 Call Signalling 143 A series of messages between two devices conveying an user's 144 request for service, possibly requesting more information about 145 that request, and coordinating the actions of the devices which 146 provide that service. 148 Device Control 149 Messages between a Media Gateway Controller ("controller", for 150 short) and a Media Gateway causing the latter to perform specific 151 actions required to satisfy an user's request for service. 153 Media Stream 154 A flow of information which appears in the telephony network as an 155 analogue signal, typically digitally encoded, and in the packet 156 network as a stream of packets, typically encapsulated by RTP [3] 157 or PPP [4]. In this document, the term "media stream" implies a 158 two-way flow of information. The terms "incoming media stream" 159 and "outgoing media stream" imply one-way flows relative to a 160 specified edge-point of a device. 162 1.3 Application Examples 164 This section gives a series of examples of potential applications of 165 Media Gateways, in order to motivate the statements of requirements 166 in sections 2 and 3 of this document. In this section only, it is 167 generally assumed that all call signalling and control processing are 168 done on devices other than the Media Gateway device, except for DTMF 169 signalling for specific purposes (authorization code in section 170 1.3.2, Interactive Voice Response Unit controls in section 1.3.4). 171 This assumption is relaxed in section 1.4.1. 173 1.3.1 Network Access Server 175 A Network Access Server (NAS) is a Media Gateway connecting between 176 telephony bearers carrying modem signals on one side and the packet 177 network on the other. All of its services are call-associated, where 178 the call is between an user device within the telephone network and 179 the call processing application associated with the NAS controller. 180 Calls may be incoming or outgoing relative to the telephone network. 182 For an incoming call, the typical exchanges of information between 183 the Media Gateway and the controller would be as follows: 185 a) A control request to the NAS causes it to assign a modem 186 termination to the call and connect it to the designated incoming 187 trunk or line. It may be necessary for the controller to tell the 188 NAS what codec is in use on the telephony side of the call. The NAS 189 must tell the controller if the request fails. 191 b1) If the NAS is responsible for obtaining authorization and 192 routing information (e.g. from a RADIUS server) it must be given the 193 calling and called number information provided by the telephone 194 network. The NAS must tell the controller if the RADIUS request 195 fails. 197 b2) Alternatively, if some other device obtains the authorization 198 and routing information, the NAS must be told what IP address to 199 assign to the caller's device, to what IP address the caller's data 200 should be sent, and any other policy information governing the NAS's 201 transformation of the user's data into packets. 203 c) The NAS must tell the controller when the user completes 204 his/her data session. (It is assumed that the NAS then automatically 205 frees the modem and clears the connection between the line or trunk. 206 Otherwise another message is needed from the controller to trigger 207 this action.) 209 A variant on the incoming call sequence may require termination of 210 the initial call after the first exchange with the RADIUS server, 211 followed by a call back to the caller's modem using a telephone 212 number provided by RADIUS. If this is the case, and the NAS is the 213 device which communicated with the RADIUS server, the NAS must so 214 inform the controller. It may or may not be necessary to clear the 215 existing modem connection, depending on whether the incoming trunk 216 can be reused for the outgoing call. 218 An outgoing call is triggered by the establishment of a packet 219 connection (PPP, L2TP) from the calling host to the NAS. The typical 220 exchanges of information in this case are as follows: 222 a) The NAS notifies the controller that a call to the telephone 223 network is required and provides the called party's telephone number 224 to the controller. 226 b) The controller assigns the outgoing line or trunk, or asks the 227 NAS to select a free trunk from a specified group; whichever end 228 makes the selection must inform the other. 230 c1) The controller establishes the call and notifies the NAS when 231 the connection is complete. 233 c2) Alternatively the controller asks the NAS to notify it when 234 modem tone is detected on the selected line or trunk. 236 d) The session ends in the same way as an incoming call. 238 An important variant on this procedure involves multiple bearers 239 associated with the same call. A procedure such as BONDING is used 240 to establish the association. The NAS must inform the controller 241 that the various connections are correlated [or vice versa -- check 242 details]. 244 1.3.2 Internet Telephony Media Gateway 246 The Internet Telephony Media Gateway could be an access gateway, 247 terminating one or more user lines directly, or a trunking gateway, 248 terminating trunks from a switch on the telephone network side. 249 Requirements for device control will be similar in nature for both 250 applications, except that the access gateway must deal with line- 251 associated signalling and supervision. This is ignored here for 252 simplicity, but illustrated in section 1.4.1. 254 The following exchanges of information are necessary to handle a 255 voice call incoming from the telephone network: 257 a) The controller may tell the Media Gateway to reserve the 258 incoming trunk or line so that no other call can claim it. 260 b) The controller may either allocate ports for a two-way RTP 261 connection through the packet network and tell the Media Gateway to 262 reserve them, or ask the Media Gateway to allocate ports and report 263 back. 265 c) The controller tells the Media Gateway to apply audible ring- 266 back tone back toward the caller. 268 d) In preparation for final cut-through, which must be done within 269 40 milliseconds [check this] of the controller's receipt of a signal 270 indicating that the called party has answered to avoid clipping of 271 the called party's first words, the controller also tells the Media 272 Gateway to set up a connection between the line or trunk appearance 273 and the RTP session, but not to enable the transfer of content in 274 either direction until further notice. 276 The connection has a number of attributes: 277 -- codec in use on the telephone network side of the connection (if 278 not already known from configuration data) 279 -- codec to be used on the packet network side of the connection 280 -- whether echo cancellation is to be applied 281 -- loss padding to be applied in each direction 282 -- method to be used to request transport QOS. 284 The user may also have requested confidentiality service. In that 285 case, further attributes must be passed to the Media Gateway 286 describing the encryption to be performed on the packet stream. 288 e) The controller tells the Media Gateway to stop applying 289 ringback tone and to complete the two-way connection between the line 290 or trunk and the RTP session. 292 f) When the call ends, the controller tells the Media Gateway to 293 break the connection and free the resources assigned to it. 295 g) The Media Gateway may report QOS statistics derived from RTCP 296 [3] reports to the controller, either at the end of the call or 297 periodically during the call. 299 The information exchanges for a call which is outgoing to the 300 telephone network are very similar to those for an incoming call. 301 Ringback tone will not be applied to the outgoing telephone network 302 connection, but if the Media Gateway is an access gateway, the 303 controller will direct it to apply ringing to the called line. 305 If an incoming call fails to complete successfully, the controller 306 may direct the Media Gateway to connect the line or trunk to an 307 announcement or to apply a busy or other tone to it. If the 308 announcement is to come from a separate announcement server device, a 309 one-way incoming RTP connection will be required to carry it. The 310 controller must direct the Media Gateway to release the outgoing RTP 311 session ports reserved for the original call and to make a one-way 312 connection from the incoming RTP port to the line or trunk. When the 313 user ends the call, the controller must tell the Media Gateway to 314 release all connections and resources as before. 316 At times it will be necessary to preserve a connection but 317 temporarily terminate the transfer of information across it (as with 318 call hold service). Typically this will be followed by the making of 319 a second connection involving the same Media Gateway edge-point (as 320 in consultation hold service or operator handling of a call). The 321 edge-point concerned may be either on the telephone network or the 322 packet network side of the Media Gateway. 324 Another possibility is that the Media Gateway contains a conference 325 bridge. The controller may direct that the Media Gateway make 326 connections from different telephone network or packet network edge- 327 points on the Media Gateway to specific ports on this bridge. 329 The final possibility considered in this section is the case where 330 the Media Gateway must prompt an user to enter an authorization code 331 before continuing with an incoming call, must collect the digits 332 entered by the user, and must report the results to the controller. 333 In detail, a variety of sequences of information exchanges may be 334 used to achieve this, but here is a typical example: 336 a) The controller tells the Media Gateway to execute the following 337 sequence of actions (i.e. script): 339 i) listen for DTMF signalling on the incoming line or trunk 341 ii) apply a prompt tone requesting the input of the authorization 342 code 344 iii) collect digits until the earlier of two events occurs: 345 -- all N required digits have been entered, where N is given by 346 the controller, or 347 -- digit collection times out, with timing given by the 348 controller. 350 iv) report either the digits collected or the timeout failure. 352 b) The Media Gateway makes its report. 354 1.3.3 Continuity Test 356 An SS7-signalled call, whether it involves a NAS or an Internet 357 Telephony Media Gateway, will frequently begin with a request to 358 check the continuity of the media connection between the Media 359 Gateway and the upstream bearer path. There are two possibilities: 360 that the Media Gateway runs the test, or that it provides the 361 loopback. 363 In the first case, the following sequence of information exchanges 364 occurs: 366 a) The controller specifies a series of actions as follows: 368 i) It specifies a edge-point, representing the termination of 369 the network connection to be tested on the Media Gateway. 371 ii) It requests that continuity test tone be applied to the 372 indicated edge-point in the outgoing direction for a specified 373 duration. 375 iii) It requests that the Media Gateway listen for continuity test 376 tone incoming on the given edge-point, again for a specified 377 duration. 379 iv) It requests that the Media Gateway report whether it has 380 detected incoming continuity test tone or not within the specified 381 time period, then terminate the test. 383 b) The Media Gateway reports the result of the test as requested. 385 At the other end of the connection, the following information 386 exchanges take place: 388 a) The controller requests that the Media Gateway place a given 389 edge-point into loopback state. 391 b) Subsequently, the controller requests that the Media Gateway 392 disconnect the two sides of the edge-point from each other. 394 1.3.4 Interactive Voice Response Unit 396 A Media Gateway associated with an Interactive Voice Response Unit 397 plays announcements and tones to the user, listens for DTMF 398 signalling, and either reports detected signalling to the controller 399 or takes subsequent actions based on a script provided by the 400 controller. To this point, the operation of the Interactive Voice 401 Response Unit involves no new information exchanges beyond those 402 already suggested in section 1.3.2, except that the scripts may be 403 more elaborate. 405 The new aspect is the recording and playback of messages. This 406 requires the media handling gateway to create uni-directional 407 connections between the edge-point on the user side and the recording 408 or playback unit respectively. 410 It is also possible that the Media Gateway will be told to listen for 411 silence during recording, time out after a certain duration, and take 412 down the connection. 414 A complete script will require more specialized device control 415 actions: for skipping back through a given message or between 416 messages, for example. Because of this, requirements for the media 417 handling part of an Interactive Voice Response Unit will be [unless 418 decided otherwise] specified in a separate document. 420 1.3.5 Digital Cross-Connect 421 A digital cross-connect operates only on digital channels, not on 422 packet streams. The basic information exchange with the controller 423 is the latter's request to connect a specified channel to another 424 specified channel, or to break a connection. Additional information 425 may be specified when a connection is made, governing the processing 426 of the digital stream running through it. Detailed requirements for 427 this application are for further study. 429 1.4 Network Context 431 This section considers aspects of the architecture of the controller 432 and the Media Gateway which lead to the recognition of additional 433 requirements for device control. 435 1.4.1 Distribution of Signalling and Control Functions 437 The basic hypothesis of this document is that at least some of the 438 Media Gateway Control function required to handle a call resides on a 439 physical device which is different from the one housing the Media 440 Gateway function. This leaves room for a number of different 441 possible arrangements for routing and processing of the various call 442 signalling protocols which may be in use in a given network. There 443 are four basic possibilities, where "incoming' means the direction 444 from which the call was initiated and "outgoing" is the direction to 445 which it is propagated: 447 (i) The incoming-side call signalling is processed at the Media 448 Gateway device, while the outgoing-side call signalling is processed 449 at the controller. 451 (ii) The incoming-side call signalling is processed at the 452 controller, while the outgoing-side call signalling is processed at 453 the Media Gateway device. 455 (iii) Call signalling for both sides is processed at the controller. 456 One variant on this case is that call signalling for either side is 457 tunneled through the Media Gateway device to/from the controller, so 458 that the latter is its logical endpoint. 460 (iv) Call signalling for both sides is processed at the Media 461 Gateway device, but the controller must be involved because it 462 contains the service control logic or owns the Media Gateway's 463 resources. 465 The application descriptions in section 1.3 assumed case (iii). 467 Cases (i) and (ii) require the operation of one or more signalling 468 protocols between the controller and the Media Gateway device. The 469 choice of which protocols to use for which combinations of external 470 signalling protocols is in general a matter for call signalling 471 experts, and is beyond the scope of device control. However, device 472 control can reasonably encompass the special case of tone-based 473 signalling. Furthermore, it may be desirable to provide a mechanism 474 for the transparent transfer of signalling information within a 475 device control session. 477 The detailed requirements imposed by case (iv) require further study. 478 They may be implementation-specific and not susceptible to 479 standardization. 481 1.4.1.1 Device Control and Tone-Based Signalling Schemes 483 The operation of tone-based signalling schemes can be viewed as a 484 candidate for inclusion in a device control protocol both because 485 analogue signalling is inseparable from the lines and trunks on which 486 it appears, and because of the relatively limited scope of such 487 schemes. Note that tone-based signalling (such as DTMF for lines, MF 488 or R2 for trunks) relies both on tones themselves and on 489 "supervision" such as off-hook and on-hook for lines, or wink, 490 seizure, and release for trunks, which are signalled by other means. 492 The details of such signalling vary from country to country and over 493 different trunk and line types within a country. Because of this, 494 the detailed processing of signalling and supervision is beyond the 495 scope of the requirements provided in this document. Nevertheless, 496 certain basic concepts, such as off-hook/seizure, on-hook/release, 497 and the individual digits, are sufficiently common to all tone-based 498 signalling schemes that their representation within a device control 499 protocol could be standardized. 501 Looking at the matter another way, it should be possible for 502 individual implementations of the device control protocol to extend 503 this signalling representation scheme to cover the additional events 504 conveyed by specific signalling schemes. 506 Now, assuming that the device control protocol meets these 507 requirements for the representation of signalling events, what uses 508 of these representations should the protocol allow? There are two 509 possibilities, depending on whether the Media Gateway acts merely as 510 a sender and receiver of signals (i.e. a tunnel for them, as a 511 variant of case (iii) in the section 1.4.1), or is also capable of 512 taking actions based upon them. 514 In the first case, the protocol must support three types of 515 signalling related messages: 516 -- requests from the controller to turn monitoring for signalling 517 events on and off, 518 -- requests from the controller for specific signalling events to be 519 generated, and 520 -- messages from the media handling gateway reporting the detection 521 of specific signalling events. 523 Because signalling events tend to happen in batches (particularly 524 when numbers are being passed), the protocol should provide for 525 efficient handling of batched events. For incoming signalling, this 526 implies the use of mechanisms such as expected digit counts and 527 timeouts. 529 If the Media Gateway can act on detected signalling events, the 530 possibility arises that it can be programmed to do so without the 531 need for intervention from the controller. This amounts to 532 processing of the signalling, and thus places us into any one of 533 cases (i), (ii), or (iv) of section 1.4.1, so that we cannot state 534 any specific new requirements on the device control protocol proper. 536 The complexity of telephone network numbering plans introduces an 537 intermediate possibility: that the Media Gateway may be programmed, 538 but the program for a given line or trunk must be updated as the call 539 proceeds to take account of the information the controller has 540 already received. Two basic mechanisms for this purpose come to 541 mind: the device control message may itself contain a program, 542 written in a pre-defined scripting language, or alternatively the 543 device control message may invoke and provide parameters for a named 544 script or applet. The device control protocol should provide support 545 for at least one of these mechanisms. 547 1.4.1.2 Transparent Carriage Of Signalling Protocol Data Units 549 Under certain circumstances it may be desirable to carry unmodified 550 signalling between the controller and the Media Gateway; this could 551 be in either direction. One example of this is where the Media 552 Gateway can process Q.931 (ISDN signalling), but is also presented 553 with QSIG signalling from a PBX which the network operator is willing 554 to transport transparently to the far end. Another more dubious 555 example is where the call signalling is being tunneled through the 556 Media Gateway to/from the controller. 558 As a general mechanism to support such operations, the device control 559 protocol may be required to support the transfer of signalling 560 protocol data units as opaque data, possibly labelled by a protocol 561 discriminator. [This requirement may be more properly assessed by 562 the signalling transport working group.] 564 1.4.2 Possible Control Arrangements 566 This section is concerned with the possible degrees of redundancy at 567 either end of the device control session, and their impact on the 568 requirements for recovery from failures. 570 Control redundancy is commonly characterized in terms of a 571 temperature metaphor, as if controllers were engines. In these 572 terms, one can have: 574 a) No alternate controller. If the controller fails, it may need 575 to retrieve current state from each device under its control upon 576 recovery, or it may have to reset those devices. (It is also 577 possible that at least some state was saved in persistent memory from 578 which it can be retrieved without going to the controlled devices.) 580 b) Cold standby, implying that the alternate controller has no 581 knowledge of current state and may have to retrieve it from the 582 controlled devices or reset them before taking over. 584 c) Warm standby, implying that the alternate controller always has 585 some knowledge of current state. It may either retrieve additional 586 state from the controlled devices or invoke a partial reset in 587 specific cases where recovery is impossible. 589 d) Hot standby, implying that the alternate controller has full 590 knowledge of current state and can take over without loss of service. 592 These different cases suggest a number of requirements on the device 593 control protocol relating to resets and querying of existing states, 594 which are spelled out in detail in section 2.2. The one point to 595 consider here is the impact of such operations on protocol 596 performance. 598 The first potential problem is a fairly obvious one, that recovery 599 may be delayed by the sheer volume of messaging required to achieve 600 it. This can be mitigated by careful design of the recovery process, 601 to ensure that the most critical elements get highest priority. The 602 requirement on the device control protocol will be to support 603 subdivision of the recovery process into the necessary steps. 605 The second potential problem is that of message fragmentation when 606 large volumes of information are passed at once. If UDP is used as 607 the transport protocol, the device control protocol may have to 608 support either end-to-end negotiation of maximum application message 609 length, or recovery from message segmentation. 611 2.0 Operational Requirements 613 This section is concerned with requirements on the design of the 614 protocol independently of the content to be carried. 616 2.1 Reliability 618 R2.1.1 Transport level reliability: device control messages MUST be 619 delivered reliably, in the order in which they were sent. 621 R2.1.2 Presentation level reliability: the device control protocol 622 MUST provide mechanisms to ensure that the originator of a message is 623 made aware when that message is rejected or not understood by the 624 receiving entity. 626 R2.1.3 Application level reliability: the device control protocol 627 MUST provide the means for the originator of a message to determine 628 if the recipient of that message failed to process it. 630 2.2 Failure Recovery 632 R2.2.1 The device control protocol MUST provide the means to detect 633 failure of the control session within a locally-configurable time 634 period (of the order of seconds). 636 R2.2.2 The device control protocol MUST provide the means for an 637 alternative controller instance to take over control of a Media 638 Gateway when a control session failure is detected. 640 R2.2.3 The device control protocol MUST provide the means for a 641 controller to negotiate handoff of control of a given Media Gateway 642 to another controller. 644 R2.2.4 The device control protocol MUST provide the means for a 645 controller to retrieve in controlled fashion the details on all 646 persistent processes (such as connections and running scripts) and 647 all resource reservations currently active in a Media Gateway. 649 R2.2.5 The device control protocol SHOULD provide the means for a 650 controller to request that a Media Gateway release all connections 651 and resources and restore default initial conditions. Comment: this 652 is obviously a mechanism of last resort for recovery of stranded 653 resources. 655 R2.2.6 It is DESIRABLE that the device control protocol allow the 656 controller (i) to associate a session identifier with each command 657 which assigns resources and creates persistent processes in the Media 658 Gateway, and (ii) to release all resources and processes associated 659 with a given session identifier, without having to list these 660 resources explicitly. Justification: if an alternate controller can 661 retrieve from another source a mapping between the call identifiers 662 used in signalling and the session identifiers potentially used in 663 device control, then when a given call is cleared the controller can 664 release the associated resources without knowing what they are. This 665 reduces the urgency for the controller to use the retrieval 666 mechanisms postulated in R2.2.3. 668 R2.2.7 The device control protocol MUST provide the means for a 669 controller to temporarily reduce the rate of message generation at 670 the Media Gateway, to allow the controller to recover from overload. 672 2.3 Startup and Takedown 674 R2.3.1 The device control protocol MUST allow either the controller 675 or the Media Gateway to initiate control session startup. 677 R2.3.2 The device control protocol MUST provide for the negotiation 678 of protocol version as part of control session startup. 680 R2.3.3 The device control protocol SHOULD provide a means for 681 negotiating the support of optional or vendor-specific portions of 682 the protocol. 684 R2.3.4 The device control protocol MUST allow graceful termination of 685 a control session. 687 2.4 Control Security 689 Control sessions are often run over physically separate links. When 690 they are not, the primary threats are impersonation and denial of 691 service attacks. Control sessions will typically run directly 692 between the controller and the Media Gateway, without an intervening 693 proxy. This leads to the following requirements. 695 R2.4.1 The device control protocol MUST provide for authentication of 696 the originator of each message. 698 R2.4.2 The device control protocol MUST contain provisions to prevent 699 denial of service attacks from being effective. 701 2.5 Performance 702 The key dimensions of device control protocol performance are 703 response time and scalability. Response time requirements depend on 704 the application; they are more stringent for a VoIP gateway than for 705 other applications. Response times for VoIP gateways MUST be rapid 706 (of the order of tens of milliseconds) to conform to the requirements 707 of the telephone network. In particular, connection setup for a 708 voice path MUST be rapid following called user answer, so that the 709 initial portion of the called user's greeting is not clipped. 710 "Response time" here refers to the sum of times taken to formulate 711 the command message at the controller, transmit it to the Media 712 Gateway, and process and execute it within the Media Gateway. 714 R2.5.1 The design of the device control protocol MUST be aimed at 715 minimizing response time as defined in the preceding paragraph, for 716 time-critical device control operations. 718 R2.5.2 The design of the device control protocol MUST allow one 719 controller to control tens of thousands of Media Gateways, and one 720 Media Gateway to support thousands of edge-points. 722 3.0 Functional Requirements 724 This section is concerned with requirements on the design of the 725 device control protocol related to its applications and the content 726 they imply. 728 3.1 Connection Control 730 R3.1.1 The device control protocol MUST support requests to create, 731 modify, and delete media stream connections between: 732 * an edge-point and another edge-point on the same device 733 * a line or trunk and a data modem 734 * a line or trunk and a FAX modem 735 * an edge-point and the port of a conference bridge 736 * an edge-point and an internal sink (e.g. recorder) for media 737 content 738 * [what else?]. 740 R3.1.2 Extensibility to arbitrary resource types: The device control 741 protocol SHOULD support requests to create, modify, and delete 742 connections between edge-points and arbitrary named resources where 743 the assumption is that the controller and Media Gateway understand 744 what the names "mean". 746 R3.1.3 The device control protocol MUST support specification of the 747 following attributes of a connection either when creating or when 748 modifying a connection: 749 * directionality: no media flow, one way in a specified direction, 750 or two ways 751 * whether echo cancellation is to be applied 752 * loss padding to be applied on the telephony side of a connection 753 * coding and compression algorithms to be applied in each direction 754 of flow 755 * whether the media stream should be encrypted, and if so, the 756 parameters to be used to accomplish encryption and decryption 757 * the method by which transport QOS is to be requested from the 758 packet network 759 * [what else?]. 761 R3.1.4 Where connection to a data modem is requested, the device 762 control protocol MUST support the carriage of the parameters needed 763 for the NAS to complete the connection through the packet network, 764 specifically including: 765 * called number 766 * calling number. 768 R3.1.5 The device control protocol SHOULD support a request from the 769 Media Gateway to the controller to make a call to a specified 770 telephone number. 772 R3.1.6 The device control protocol MUST support responses from the 773 Media Gateway indicating the fact and cause of failure to execute a 774 request to create, modify, or delete a connection. 776 R3.1.7 The device control protocol SHOULD support the ability to have 777 the Media Gateway choose and report back the identity of a specific 778 edge-point to be used for a connection, within constraints provided 779 by the controller. Examples of this are selection of an idle trunk 780 from a named trunk group, or selection of one or two free RTP/RTCP 781 port pairs depending on the required directionality of the 782 connection. 784 R3.1.8 The device control protocol MUST support the creation and 785 deletion of loopback connections at specified edge-points. To 786 support testing and debugging of device operations, the device 787 control protocol SHOULD also support the creation of loopbacks at one 788 edge-point back through the Media Gateway towards another edge-point 789 to which it is connected. 791 R3.1.9 The device control protocol MUST support the retrieval of 792 statistics indicating the quality of service received on a given 793 packet connection. 795 3.2 Tones and Announcements 797 R3.2.1 The device control protocol MUST support requests for the 798 Media Gateway to play out and to stop playing out to a specified 799 edge-point one or a sequence of named tones and/or announcements. 801 R3.2.2 For each tone or announcement to be played, it MUST be 802 possible to specify the maximum amount of time the tone or 803 announcement is to be played out or, for announcements specifically, 804 how often the announcement should be repeated before discontinuing 805 it. 807 R3.2.3 The device control protocol MUST support a mechanism whereby 808 it is possible to associate the commencement and/or termination of 809 the playout of specific tones or announcements with specific events 810 involving the endpoint. This is a specific case of the general 811 scripting capability called for requirement R3.3.2. 813 R3.2.4 It is DESIRABLE that the device control protocol be capable of 814 configuring tone specifications consisting of the following aspects: 815 * tone name 816 * number of segments 817 * for each segment: whether it consists of silence or tone; if the 818 latter, what frequency or frequencies to use, at what loudness 819 level; the segment duration. 821 3.3 Event Notification and Scripts 823 See the final paragraphs of section 1.4.1.1 for background on the 824 scripting requirements given here. 826 R3.3.1 The device control protocol MUST support requests for the 827 Media Gateway to start and stop monitoring for specific events 828 observed at an edge-point. Many of the events of interest are 829 covered under tone signalling, in the next section. However, there 830 is a specific requirement to detect and report on: 831 * modem tone 832 * FAX tone 833 * various test tones, including continuity test [with national 834 variations] 835 * busy tone [with national variations] 836 * reorder tone [with national variations] 837 * [what else?]. 839 R3.3.2 The device control protocol MUST provide a mechanism whereby 840 the controller can specify mixed sequences of events to be detected 841 and actions to be taken (scripting capability). It MUST be possible 842 to specify the following within these sequences: 843 * conditional subsequences, to be executed only if specified events 844 occur 845 * repeated subsequences (loops), where the loop is terminated by a 846 specified event 847 * conditions under which the entire script is deactivated, 848 regardless of which specific step in the script is currently 849 being executed. For example, a script applied in association 850 with a connection between two edge-points may be required 851 to deactivate when the connection is deleted. 853 R3.3.3 The device control protocol MUST provide the means to 854 simultaneously create or modify a connection and invoke a script on 855 or request a report from either or both edge-points involved in the 856 connection. 858 R3.3.4 The device control protocol must provide a means of tagging 859 script invocations, such that the controller can refer to a specified 860 script running at a specifed endpoint in subsequent messages. 862 R3.3.5 The device control protocol MUST provide the means for the 863 controller to: 864 * determine what scripts are active at a given edge-point 865 * deactivate a specified script or all scripts active at a given 866 edge-point. 868 3.4 Tone Signalling 870 See the discussion in section 1.4.1.1 for background. Detection and 871 generation of tone signalling are events and actions respectively to 872 which the scripting requirements of the previous section may apply. 874 R3.4.1 The device control protocol MUST allow the controller to 875 request the generation of tone signalling to specified edge-points. 876 Such requests will include designation of the symbols to be sent (see 877 requirement R3.4.3), the duration of each symbol, and the time 878 between successive symbols. 880 R3.4.2 The device control protocol MUST allow the controller to 881 enable and disable the reporting of tone signalling received from 882 specified edge-points. To avoid unnecessary messaging, it must be 883 possible for the controller to specify alternative patterns of 884 signals, the completion of which should trigger a report to the 885 controller. The controller should also be able to specify a timeout 886 period beyond which collected events should be reported regardless of 887 whether a pattern has been completed. 889 R3.4.3 It is DESIRABLE that the device control protocol provide a 890 language for the reporting of events likely to be encountered with 891 the the most common tone signalling systems. Examples of such events 892 are: 893 * off- and on-hook, hook-flash, the digits "0" through "D", and the 894 pound "#" and star "*" for tone signalling on lines 895 * wink, seizure, release, the digits "0" through "9", the elements 896 "K0" through "K2", and the elements "S0" through "S3" 897 for signalling on trunks. 899 R3.4.4 As a further elaboration of the basic scripting requirement 900 R3.3.2, the protocol MUST allow invocation of a script combining the 901 detection of specified signalling events with actions to be taken 902 upon detection. Examples of such use might be to program the 903 sequence: "Detect off-hook. Apply dial tone. Listen for digits. 904 Remove dial tone after a digit is detected. Collect digits according 905 to specified parsing and timeout rules. Report the results." 907 3.5 Signalling Backhaul 909 R3.5.1 As suggested in section 1.4.1.2, it MAY BE DESIRABLE that the 910 device control protocol provide a means of passing signalling data 911 units transparently, along with an identification of the signalling 912 protocol involved. 914 3.6 Resource Status Management 916 R3.6.1 The device control protocol MUST provide the means for the 917 controller to track failure conditions affecting call processing. 918 Specifically: 919 * If a failure condition within the Media Gateway device has 920 resulted in its failure to execute a request from the controller, 921 means MUST be provided in the Media Gateway's response to the 922 controller to identify the failure condition for further 923 reference. 925 * It MUST be possible for the controller to determine when 926 the failure condition has cleared, either by way of a direct 927 notification within the device control protocol itself or by 928 other means (e.g. SNMP). 930 R3.6.2 The identification of the failure condition SHOULD be such as 931 to allow the controller to determine the scope of the failure (e.g. 932 specific trunk, entire transmission facility, etc.). 934 R3.6.3 The device control protocol MUST provide the means for the 935 controller to block and unblock the use of specified trunks. 937 3.7 Other 939 3.7.1 Vendor Extensibility 941 R3.7.1.1 Because device control is a fairly basic function, it is 942 highly probable that vendor-specific commands, indications, and 943 attributes or extensions to attributes will be required in any 944 concrete situation. The device control protocol MUST be easy to 945 extend in these ways. 947 3.7.2 Architectural Flexibility 949 R3.7.2.1 The device control protocol MUST be able to operate 950 successfully regardless of the location of individual call signalling 951 functions and related call processing functions. It MUST also be 952 able to operate regardless of the existing arrangements for control 953 redundancy. 955 4.0 Security Aspects 957 Security requirements relating to the secure operation of an IP 958 device control session are discussed in section 2.4 above. Security 959 requirements for the handling of media streams include 960 confidentially, integrity, and possibly authentication. [ITU-T 961 Recommendation H.235 has a good discussion of security requirements, 962 the applicable parts of which could be brought into this document.] 964 5.0 References 966 [1] F. Cuervo, N. Greene, M. Holdredge, L. Ong, and C. Huitema, 967 "SS7-Internet Interworking - Architectural Framework", draft-greene- 968 ss7-arch-frame-00.txt, July 1998. 970 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 971 Levels", RFC 2119, Internet Engineering Task Force, March 1997 973 [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 974 A Transport Protocol for Real-Time Applications," RFC 1889, Internet 975 Engineering Task Force, January 1996. 977 [4] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1548, 978 Internet Engineering Task Force, December 1993. 980 6.0 Acknowledgements 982 The following individuals contributed to the initial definition of 983 requirements for the IP device control protocol, from which this 984 document was derived: 986 Ilya Akramovich, Bob Bell, Andrew Dugan, Ike Elliott, Cary 987 Fitzgerald, Jan M. Gronski, Tom Hess, Geoff Jordan, Tony Lam, Pete 988 O'Connell, Scott Pickett, Shyamal Prasad, Eric Presworsky, Paul 989 Richards, Dale Skran, Louise Spergel, David Sprague, Raj Srinivasan, 990 and Michael Thomas. 992 7.0 Author's Address 994 Questions about this memo can be directed to: 996 P. Tom Taylor 997 Nortel (Northern Telecom) 998 M/S 097, SKY, 999 P.O. Box 3511, Station C, 1000 Ottawa, Ontario, 1001 Canada 1003 Phone: 1-613-765-4167 1004 Fax: 1-613-765-7236 1005 E-mail: taylor@nortel.com