idnits 2.17.00 (12 Aug 2021) /tmp/idnits47025/draft-ietf-megaco-reqs-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 44 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 45 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 53 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1570 has weird spacing: '... permit speci...' == Line 1610 has weird spacing: '... French and s...' == Line 1860 has weird spacing: '...Discard in pr...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Nancy Greene 2 INTERNET DRAFT Nortel Networks 3 Michael A. Ramalho 4 Category: Informational Cisco Systems 5 Expires: June 9, 2000 Brian Rosen 6 Fore Systems 8 Media Gateway control protocol architecture and requirements 9 Nancy Greene, Michael A. Ramalho, Brian Rosen 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. Internet-Drafts are working docu- 15 ments of the Internet Engineering Task Force (IETF), its areas, and its 16 working groups. Note that other groups may also distribute working docu- 17 ments as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 This document is a product of the Media Gateway Control (MEGACO) Working 31 Group of the Internet Engineering Task Force (IETF). Comments should be 32 submitted to the mailing list megaco@standards.nortelnetworks.com. 34 Abstract 36 This document describes protocol requirements for the Media Gateway con- 37 trol protocol between a Media Gateway Controller and a Media Gateway. 39 Table of Contents 41 Internet draft MG control protocol requirements 9 December 1999 43 1. Introduction .............................................. 4 44 2. Terminology ............................................... 4 45 3. Definitions ............................................... 4 46 4. Specific functions assumed within the MG .................. 5 47 5. Per-Call Requirements ..................................... 7 48 5.1. Resource Reservation ................................. 7 49 5.2. Connection Requirements .............................. 8 50 5.3. Media Transformations ................................ 9 51 5.4. Signal/Event Processing and Scripting ................ 10 52 5.5. QoS/CoS .............................................. 11 53 5.6. Test Support ......................................... 11 54 5.7. Accounting ........................................... 11 55 5.8. Signalling Control ................................... 12 56 6. Resource Control .......................................... 12 57 6.1. Resource Status Management ........................... 12 58 6.2. Resource Assignment .................................. 14 59 7. Operational/Management Requirements ....................... 14 60 7.1. Assurance of Control/Connectivity .................... 14 61 7.2. Error Control ........................................ 15 62 7.3. MIB Requirements ..................................... 15 63 8. General Protocol Requirements ............................. 16 64 8.1. MG-MGC Association Requirements ...................... 17 65 8.2. Performance Requirements ............................. 17 66 9. Transport ................................................. 18 67 9.1. Assumptions made for underlying network .............. 18 68 9.2. Transport Requirements ............................... 18 69 10. Security Requirements .................................... 19 70 11. Requirements specific to particular bearer types ......... 20 71 11.1. Media-specific Bearer types ......................... 20 72 11.1.1. Requirements for TDM PSTN (Circuit) ............ 21 73 11.1.2. Packet Bearer type ............................. 22 74 11.1.3. Bearer type requirements for ATM ............... 23 75 11.1.3.1. Addressing ................................ 23 76 11.1.3.2. Connection related requirements ........... 24 77 11.1.3.3. Media adaptation .......................... 25 78 11.1.3.4. Reporting requirements .................... 26 79 11.1.3.5. Functional requirements ................... 26 80 11.2. Application-Specific Requirements ................... 26 81 11.2.1. Trunking Gateway ............................... 26 82 11.2.2. Access Gateway ................................. 27 83 11.2.3. Trunking/Access Gateway with fax ports ......... 28 84 11.2.4. Trunking/Access Gateway with text telephone .... 28 85 11.2.5. Trunking/Access Gateway with conference ports .. 29 86 11.2.6. Network Access Server .......................... 29 87 11.2.7. Restricted Capability Gateway .................. 31 88 11.2.8. Multimedia Gateway ............................. 31 89 11.2.9. ARF Unit ....................................... 33 91 Internet draft MG control protocol requirements 9 December 1999 93 11.2.10. Multipoint Control Units ....................... 43 94 12. Full Copyright Statement ................................. 43 95 13. References ............................................... 44 96 14. Acknowledgements ......................................... 45 97 15. Authors' addresses ....................................... 45 99 Internet draft MG control protocol requirements 9 December 1999 101 1. Introduction 103 This document describes requirements to be placed on the Media Gateway 104 control protocol. When the word protocol is used on its own in this 105 document it implicitly means the Media Gateway control protocol. 107 2. Terminology 109 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 110 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 111 "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indi- 112 cate requirement levels for the protocol. 114 3. Definitions 116 * Connection 118 Under the control of a Media Gateway Controller (MGC), the Media Gateway 119 (MG) realizes connections. In this document, connections are associa- 120 tions of resources hosted by the MG. They typically involve two termina- 121 tions, but may involve more. 123 * Line or Loop 125 An analogue or digital access connection from a user terminal which car- 126 ries user media content and telephony access signalling (DP, DTMF, BRI, 127 proprietary business set). 129 * Media Gateway (MG) function 131 A Media Gateway (MG) function provides the media mapping and/or tran- 132 scoding functions between potentially dissimilar networks, one of which 133 is presumed to be a packet, frame or cell network. For example, an MG 134 might terminate switched circuit network (SCN) facilities (trunks, 135 loops), packetize the media stream, if it is not already packetized, and 136 deliver packetized traffic to a packet network. It would perform these 137 functions in the reverse order for media streams flowing from the packet 138 network to the SCN. 140 Media Gateways are not limited to SCN <-> packet/frame/cell functions: A 141 conference bridge with all packet interfaces could be an MG, as well as 142 an (IVR) interactive voice recognition unit, an audio resource function, 143 or a voice recognition system with a cell interface. 145 * Media Gateway unit (MG-unit) 147 An MG-unit is a physical entity that contains an MG function and may 149 Internet draft MG control protocol requirements 9 December 1999 151 also contain other functions, e.g. an SG function. 153 * Media Gateway Controller (MGC) function 155 A Media Gateway Controller (MGC) function controls a MG. 157 * Media Resource 159 Examples of media resources are codecs, announcements, tones, and 160 modems, interactive voice response (IVR) units, bridges, etc. 162 * Signaling Gateway (SG) function 164 An SG function receives/sends SCN native signalling at the edge of a 165 data network. For example the SG function may relay, translate or ter- 166 minate SS7 signaling in an SS7-Internet Gateway. The SG function may 167 also be co-resident with the MG function to process SCN signalling asso- 168 ciated with line or trunk terminations controlled by the MG, such as the 169 "D" channel of an ISDN PRI trunk. 171 * Termination 173 A termination is a point of entry and/or exit of media flows relative to 174 the MG. When an MG is asked to connect two or more terminations, it 175 understands how the flows entering and leaving each termination are 176 related to each other. 178 Terminations are, for instance, DS0's, ATM VCs and RTP ports. Another 179 word for this is bearer point. 181 * Trunk 183 An analog or digital connection from a circuit switch which carries user 184 media content and may carry telephony signalling (MF, R2, etc.). Digi- 185 tal trunks may be transported and may appear at the Media Gateway as 186 channels within a framed bit stream, or as an ATM cell stream. Trunks 187 are typically provisioned in groups, each member of which provides 188 equivalent routing and service. 190 * Type of Bearer 192 A Type of Bearer definition provides the detailed requirements for its 193 particular application/bearer type. A particular class of Media Gateway, 194 for example, would support a particular set of Bearer types. 196 Internet draft MG control protocol requirements 9 December 1999 198 4. Specific functions assumed within the MG 200 This section provides an environment for the definition of the general 201 Media Gateway control protocol requirements. 203 MGs can be architected in many different ways depending where the media 204 conversions and transcoding (if required) are performed, the level of 205 programmability of resources, how conferences are supported, and how 206 associated signalling is treated. The functions assumed to be within the 207 MG must not be biased towards a particular architecture. 209 For instance, announcements in a MG could be provided by media resources 210 or by the bearer point resource or termination itself. Further, this 211 difference must not be visible to MGC: The MGC must be able to issue the 212 identical request to two different implementations and achieve the 213 identical functionality. 215 Depending on the application of the MG (e.g., trunking, residential), 216 some functions listed below will be more prominent than others, and in 217 some cases, functions may even disappear. 219 Although media adaptation is the essence of the MG, it is not necessary 220 for it to be involved every time. An MG may join two 221 terminations/resources of the same type (i.e., the MG behaves as a 222 switch). The required media conversion depends on the media type sup- 223 ported by the resources being joined together. 225 In addition to media adaptation function, resources have a number of 226 unique properties, for instance: 228 * certain types of resources have associated signalling capabilities 229 (e.g., PRI signalling, DTMF), 231 * some resources perform maintenance functions (e.g., continuity 232 tests), 234 * the MGC needs to know the state changes of resources (e.g., a trunk 235 group going out of service), 237 * the MG retains some control over the allocation and control of some 238 resources (e.g., resource name space: RTP port numbers). 240 Therefore, an MG realizes point-to-point connections and conferences, 241 and supports several resource functions. These functions include media 242 conversion, resource allocation and management, and event notifications. 243 Handling termination associated signalling is either done using event 244 notifications, or is handled by the signalling backhaul part of a MG- 245 unit (i.e. NOT directly handled by the MG). 247 Internet draft MG control protocol requirements 9 December 1999 249 MGs must also support some level of system related functions, such as 250 establishing and maintaining some kind of MG-MGC association. This is 251 essential for MGC redundancy, fail-over and resource sharing. 253 Therefore, an MG is assumed to contain these functions: 255 * Reservation and release, of resources 257 * Ability to provide state of resources 259 * Maintenance of resources - It must be possible to make maintenance 260 operations independent of other termination functions, for 261 instance, some maintenance states should not affect the resources 262 associated with that resource . Examples of maintenance functions 263 are loopbacks and continuity tests. 265 * Connection management, including connection state. 267 * Media processing, using media resources: these provide services 268 such as transcoding, conferencing, interactive voice recognition 269 units, audio resource function units. Media resources may or may 270 not be directly part of other resources. 272 * Incoming digit analysis for terminations, interpretation of scripts 273 for terminations 275 * Event detection and signal insertion for per-channel signalling 277 * Ability to configure signalling backhauls (for example, a Sigtran 278 backhaul) 280 * Management of the association between the MGC and MG, or between 281 the MGC and MG resources. 283 5. Per-Call Requirements 285 5.1. Resource Reservation 287 The protocol must: 289 a. Support reservation of bearer terminations and media resources for 290 use by a particular call and support their subsequent release 291 (which may be implicit or explicit). 293 b. Allow release in a single exchange of messages, of all resources 294 associated with a particular set of connectivity and/or associa- 295 tions between a given number terminations . 297 Internet draft MG control protocol requirements 9 December 1999 299 c. The MG is not required (or allowed) by the protocol to maintain a 300 sense of future time: a reservation remains in effect until expli- 301 citly released by the MGC. 303 5.2. Connection Requirements 305 The protocol must: 307 a. Support connections involving packet and circuit bearer termina- 308 tions in any combination, including "hairpin" connections (connec- 309 tions between two circuit connections within the same MG). 311 b. Support connections involving TDM, Analogue, ATM, IP or FR tran- 312 sport in any combination. 314 c. Allow the specification of bearer plane (e.g. Frame Relay, IP, 315 etc.) on a call by call basis. 317 d. Support unidirectional, symmetric bi-directional, and asymmetric 318 bi-directional flows of media. 320 e. Support multiple media types (e.g. audio, text, video, T.120). 322 f. Support point-to-point and point-to-multipoint connections. 324 g. Support creation and modification of more complex flow topologies 325 e.g. conference bridge capabilities. Be able to add or delete 326 media streams during a call or session, and be able to add or sub- 327 tract participants to/from a call or session. 329 h. Support inclusion of media resources into call or session as 330 required. Depending on the protocol and resource type, media 331 resources may be implicitly included, class-assigned, or individu- 332 ally assigned. 334 i. Provide unambiguous specification of which media flows pass through 335 a point and which are blocked at a given point in time, if the pro- 336 tocol permits multiple flows to pass through the same point. 338 j. Allow modifications of an existing termination, for example, use of 339 higher compression to compensate for insufficient bandwidth or 340 changing transport network connections. 342 k. Allow the MGC to specify that a given connection has higher prior- 343 ity than other connections. 345 l. Allow a reference to a port/termination on the MG to be a logical 347 Internet draft MG control protocol requirements 9 December 1999 349 identifier, 351 with a one-to-one mapping between a logical identifier and a physi- 352 cal port. 354 m. Allow the MG to report events such as resource reservation and con- 355 nection completion. 357 5.3. Media Transformations 359 The Protocol must: 361 a. Support mediation/adaptation of flows between different types of 362 transport 364 b. Support invocation of additional processing such as echo cancella- 365 tion. 367 c. Support mediation of flows between different content encoding 368 (codecs, encryption/decryption) 370 d. Allow the MGC to specify whether text telephony/FAX/data modem 371 traffic is to be terminated at the MG, modulated/demodulated, and 372 converted to packets or forwarded by the MG in the media flow as 373 voice band traffic. 375 e. Allow the MGC to specify that Dual-Tone MultiFrequency (DTMF) 376 digits or other line and trunk signals and general Multi-Frequency 377 (MF) tones are to be processed in the MG and how these 378 digits/signals/tones are to be handled. The MGC must be able to 379 specify any of the following handling of such digits/signals/tones: 381 1. The digits/signals/tones are to be encoded normally in the audio 382 RTP stream (e.g., no analysis of the digits/signals/tones). 384 2. Analyzed and sent to the MGC. 386 3. Received from the MGC and inserted in the line-side audio stream. 388 4. Analyzed and sent as part of a separate RTP stream (e.g., DTMF 389 digits sent via a RTP payload separate from the audio RTP stream). 391 5. Taken from a separate RTP stream and inserted in the line-side 392 audio stream. 394 6. Handled according to a script of instructions. 396 Internet draft MG control protocol requirements 9 December 1999 398 For all but the first case, an option to mute the 399 digits/signals/tones with silence, comfort noise, or other means 400 (e.g., notch filtering of some telephony tones) must be provided. 401 As detection of these events may take up to tens of milliseconds, 402 the first few milliseconds of such digit/signal/tone may be encoded 403 and sent in the audio RTP stream before the digit/signal/tone can 404 be verified. Therefore muting of such digits/signals/tones in the 405 audio RTP stream with silence or comfort noise is understood to 406 occur at the earliest opportunity after the digit/signal/tone is 407 verified. 409 f. Allow the MGC to specify signalled flow characteristics on circuit 410 as well as on packet bearer connections, e.g. u-law/a-law. 412 g. Allow for packet/cell transport adaptation only (no media adapta- 413 tion) e.g. mid-stream (packet-to-packet) 414 transpacketization/transcoding, or ATM AAL5 to and from ATM AAL2 415 adaptation. 417 h. Allow the transport of audio normalization levels as a setup param- 418 eter, e.g., for conference bridging. 420 i. Allow conversion to take place between media types e.g., text to 421 speech and speech to text. 423 5.4. Signal/Event Processing and Scripting 425 The Protocol must: 427 a. Allow the MGC to enable/disable monitoring for specific supervision 428 events at specific circuit terminations 430 b. Allow the MGC to enable/disable monitoring for specific events 431 within specified media streams 433 c. Allow reporting of detected events on the MG to the MGC. The proto- 434 col should provide the means to minimize the messaging required to 435 report commonly-occurring event sequences. 437 d. Allow the MGC to specify other actions (besides reporting) that the 438 MG should take upon detection of specified events. 440 e. Allow the MGC to enable and/or mask events. 442 f. Provide a way for MGC to positively acknowledge event notification. 444 Internet draft MG control protocol requirements 9 December 1999 446 g. Allow the MGC to specify signals (e.g., supervision, ringing) to be 447 applied at circuit terminations. 449 h. Allow the MGC to specify content of extended duration (announce- 450 ments, continuous tones) to be inserted into specified media flows. 452 i. Allow the MGC to specify alternative conditions (detection of 453 specific events, timeouts) under which the insertion of extended- 454 duration signals should cease. 456 j. Allow the MGC to download, and specify a script to be invoked on 457 the occurrence of an event. 459 k. Specify common events and signals to maximize MG/MGC interworking. 461 l. Provide an extension mechanism for implementation defined events 462 and signals with, for example, IANA registration procedures. It may 463 be useful to have an Organizational Identifier (i.e. ITU, ETSI, 464 ANSI, ) as part of the registration mechanism. 466 m. The protocol shall allow the MGC to request the arming of a mid- 467 call trigger even after the call has been set up. 469 5.5. QoS/CoS 471 The Protocol must: 473 a. Support the establishment of a bearer channel with a specified 474 QoS/CoS. 476 b. Support the ability to specify QoS for the connection between MGs, 477 and by direction. 479 c. Support a means to change QoS during a connection, as a whole and 480 by direction. 482 d. Allow the MGC to set QOS thresholds and receive notification when 483 such thresholds cannot be maintained. 485 e. Allow the jitter buffer parameters on RTP channels to be specified 486 at connection setup. 488 5.6. Test Support 490 The protocol must: 492 Internet draft MG control protocol requirements 9 December 1999 494 a. Support of the different types of PSTN Continuity Testing (COT) for 495 both the originating and terminating ends of the circuit connection 496 (2-wire and 4- wire). 498 b. Specifically support test line operation (e.g. 103, 105, 108). 500 5.7. Accounting 502 The protocol must: 504 a. Support a common identifier to mark resources related to one con- 505 nection. 507 b. Support collection of specified accounting information from MGs. 509 c. Provide the mechanism for the MGC to specify that the MG report 510 accounting information automatically at end of call, in mid-call 511 upon request, at specific time intervals as specified by the MGC 512 and at unit usage thresholds as specified by the MGC. 514 d. Specifically support collection of: 516 * start and stop time, by media flow, 518 * volume of content carried (e.g. number of packets/cells transmit- 519 ted, number received with and without error, inter-arrival jitter), 520 by media flow, 522 * QOS statistics, by media flow. 524 e. Allow the MGC to have some control over which statistics are 525 reported, to enable it to manage the amount of information 526 transferred. 528 5.8. Signalling Control 530 Establishment and provisioning of signalling backhaul channels (via 531 SIGTRAN for example) is out of scope. However, the MG must be capable 532 of supporting detection of events, and application of signals associated 533 with basic analogue line, and CAS type signalling. The protocol must: 535 a. Support the signalling requirements of analogue lines and Channel 536 Associated Signaling (CAS). 538 b. Support national variations of such signalling. 540 Internet draft MG control protocol requirements 9 December 1999 542 c. Provide mechanisms to support signalling without requiring MG-MGC 543 timing constraints beyond that specified in this document. 545 d. Must not create a situation where the MGC and the MG must be homo- 546 logated together as a mandatory requirement of using the protocol; 547 i.e. it must be possible to optionally conceal signaling type vari- 548 ation from the MGC. 550 6. Resource Control 552 6.1. Resource Status Management 554 The protocol must: 556 a. Allow the MG to report changes in status of physical entities sup- 557 porting bearer terminations, media resources, and facility- 558 associated signalling channels, due to failures, recovery, or 559 administrative action. It must be able to report whether a termina- 560 tion is in service or out of service. 562 b. Support administrative blocking and release of TDM circuit termina- 563 tions. 565 [Editor's Note: as the above point only relates to ISUP-controlled cir- 566 cuits, it may be unnecessary to require this since the MGC controls 567 their use. However, it may be meaningful for MF and R2-signalled 568 trunks, where supervisory states are set to make the trunks unavailable 569 at the far end.] 571 c. Provide a method for the MGC to request that the MG release all 572 resources under the control of a particular MGC currently in use, 573 or reserved, for any or all connections. 575 d. Provide an MG Resource Discovery mechanism which must allow an MGC 576 to discover what resources the MG has. Expressing resources can be 577 an arbitrarily difficult problem and the initial release of the 578 protocol may have a simplistic view of resource discovery. 580 At a minimum, resource discovery must enumerate the names of avail- 581 able circuit terminations and the allowed values for parameters 582 supported by terminations. 584 The protocol should be defined so that simple gateways could 585 respond with a relatively short, pre-stored response to the 586 discovery request mechanism. In general, if the protocol defines a 587 mechanism that allows the MGC to specify a setting or parameter for 588 a resource or connection in the MG, and MGs are not required to 589 support all possible values for that setting or parameter, then the 591 Internet draft MG control protocol requirements 9 December 1999 593 discovery mechanism should provide the MGC with a method to deter- 594 mine what possible values such settings or parameters are supported 595 in a particular MG. 597 e. Provide a mechanism to discover the current available resources in 598 the MG, where resources are dynamically consumed by connections and 599 the MGC cannot reasonably or reliably track the consumption of such 600 resources. It should also be possible to discover resources 601 currently in use, in order to reconcile inconsistencies between the 602 MGC and the MG. 604 f. Not require an MGC to implement an SNMP manager function in order 605 to discover capabilities of an MG that may be specified during con- 606 text establishment. 608 6.2. Resource Assignment 610 The protocol must: 612 a. Provide a way for the MG to indicate that it was unable to perform 613 a requested action because of resource exhaustion, or because of 614 temporary resource unavailability. 616 b. Provide an ability for the MGC to indicate to an MG the resource to 617 use for a call (e.g. DS0) exactly, or indicate a set of resources 618 (e.g. pick a DS0 on a T1 line or a list of codec types) via a "wild 619 card" mechanism from which the MG can select a specific resource 620 for a call (e.g. the 16th timeslot, or G.723). 622 c. Allow the use of DNS names and IP addresses to identify MGs and 623 MGCs. This shall not preclude using other identifiers for MGs or 624 MGCs when other non IP transport technologies for the protocol are 625 used. 627 7. Operational/Management Requirements 629 7.1. Assurance of Control/Connectivity 631 To provide assurance of control and connectivity, the protocol must pro- 632 vide the means to minimize duration of loss of control due to loss of 633 contact, or state mismatches. 635 The protocol must: 637 a. Support detection and recovery from loss of contact due to 638 failure/congestion of communication links or due to MG or MGC 640 Internet draft MG control protocol requirements 9 December 1999 642 failure. 644 Note that failover arrangements are one of the mechanisms which 645 could be used to meet this requirement. 647 b. Support detection and recovery from loss of synchronized view of 648 resource and connection states between MGCs and MGs. (e.g. through 649 the use of audits). 651 c. Provide a means for MGC and MG to provide each other with booting 652 and reboot indications, and what the MG's configuration is. 654 d. Permit more than one backup MGC and provide an orderly way for the 655 MG to contact one of its backups. 657 e. Provide for an orderly switchback to the primary MGC after it 658 recovers. How MGCs coordinate resources between themselves is out- 659 side the scope of the protocol. 661 f. Provide a mechanism so that when an MGC fails, connections already 662 established can be maintained. The protocol does not have to pro- 663 vide a capability to maintain connections in the process of being 664 connected, but not actually connected when the failure occurs. 666 g. The Protocol must allow the recovery or redistribution of traffic 667 without call loss. 669 7.2. Error Control 671 The protocol must: 673 a. Allow for the MG to report reasons for abnormal failure of lower 674 layer connections e.g. TDM circuit failure, ATM VCC failure. 676 b. Allow for the MG to report Usage Parameter Control (UPC) events. 678 c. Provide means to ameliorate potential synchronization or focused 679 overload of supervisory/signaling events that can be detrimental to 680 either MG or MGC operation. Power restoration or signaling tran- 681 sport re-establishment are typical sources of potentially detrimen- 682 tal signaling showers from MG to MGC or vice- versa. 684 d. Allow the MG to notify the MGC that a termination was terminated 685 and communicate a reason when a terminations is taken out-of- 686 service unilaterally by the MG due to abnormal events. 688 e. Allow the MGC to acknowledge that a termination has been taken 690 Internet draft MG control protocol requirements 9 December 1999 692 out-of-service. 694 f. Allow the MG to request the MGC to release a termination and com- 695 municate a reason. 697 g. Allow the MGC to specify, as a result of such a request its deci- 698 sion to take termination down, leave it as is or modify it. 700 7.3. MIB Requirements 702 The Protocol must define a common MG MIB, which must be extensible, but 703 must: 705 a. Provide information on: 707 * mapping between resources and supporting physical entities. 709 * statistics on quality of service on the control and signalling 710 backhaul interfaces. 712 * statistics required for traffic engineering within the MG. 714 b. The protocol must allow the MG to provide to the MGC all informa- 715 tion the MGC needs to provide in its MIB. 717 c. MG MIB must support implementation of H.341 by either the MG, MGC, 718 or both acting together. 720 [Editor's Note: Discussion: MIB requirements should focus solely on the 721 management of the operation of the protocol itself. Other MIBs cover 722 the topics suggested here, except possibly for the traffic engineering 723 statistics. The point was raised that the MGC should not have to imple- 724 ment a manager function, because of the complications this would pose 725 for security administration. This raises a requirement for the MGC to 726 be able to discover the resources and other necessary information per- 727 taining to a given MG by means of the protocol. A suggestion was also 728 made that the MG needs to discover certain information about the MGC. 730 The mailing list is invited to comment, both on the proper Media Control 731 MIB requirements and on the requirements for discovery.] 733 8. General Protocol Requirements 735 The protocol must: 737 a. Support multiple operations to be invoked in one message and 739 Internet draft MG control protocol requirements 9 December 1999 741 treated as a single transaction. 743 b. Be both modular and extensible. Not all implementations may wish to 744 support all of the possible extensions for the protocol. This will 745 permit lightweight implementations for specialized tasks where pro- 746 cessing resources are constrained. This could be accomplished by 747 defining particular profiles for particular uses of the protocol. 749 c. Be flexible in allocation of intelligence between MG and MGC. For 750 example, an MGC may want to allow the MG to assign particular MG 751 resources in some implementations, while in others, the MGC may 752 want to be the one to assign MG resources for use. 754 d. Support scalability from very small to very large MGs: The protocol 755 must support MGs with capacities ranging from one to millions of 756 terminations. 758 e. Support scalability from very small to very large MGC span of con- 759 trol: The protocol should support MGCs that control from one MG to 760 a few tens of thousands of MGs. 762 f. Support the needs of a residential gateway that supports one to a 763 few lines, and the needs of a large PSTN gateway supporting tens of 764 thousands of lines. Protocol mechanisms favoring one extreme or the 765 other should be minimized in favor of more general purpose mechan- 766 ism applicable to a wide range of MGs. Where special purpose 767 mechanisms are proposed to optimize a subset of implementations, 768 such mechanisms should be defined as optional, and should have 769 minimal impact on the rest of the protocol. 771 g. Facilitate MG and MGC version upgrades independently of one 772 another. The protocol must include a version identifier in the ini- 773 tial message exchange. 775 h. Facilitate the discovery of the protocol capabilities of the one 776 entity to the other. 778 i. Specify commands as optional (they can be ignored) or mandatory 779 (the command must be rejected), and within a command, to specify 780 parameters as optional (they can be ignored) or mandatory (the com- 781 mand must be rejected). 783 8.1. MG-MGC Association Requirements 785 The Protocol must: 787 Internet draft MG control protocol requirements 9 December 1999 789 a. Support the establishment of a control relationship between an MGC 790 and an MG. 792 b. Allow multiple MGCs to send control messages to an MG. Thus, the 793 protocol must allow control messages from multiple signalling 794 addresses to a single MG. 796 c. Provide a method for the MG to tell an MGC that the MG received a 797 command for a resource that is under the control of a different 798 MGC. 800 d. Support a method for the MG to control the rate of requests it 801 receives from the MGC (e.g. windowing techniques, exponential back- 802 off). 804 e. Support a method for the MG to tell an MGC that it cannot handle 805 any more requests. 807 8.2. Performance Requirements 809 The protocol must: 811 a. Minimize message exchanges between MG and MGC, for example during 812 boot/reboot, and during continuity tests. 814 b. Support Continuity test constraints which are a maximum of 200ms 815 cross-MGC IAM (IAM is the name given to an SS7 connection setup 816 msg) propagation delay, and a maximum of 200ms from end of dialing 817 to IAM emission). 819 c. Make efficient use of the underlying transport mechanism. For exam- 820 ple, protocol PDU sizes vs. transport MTU sizes needs to be con- 821 sidered in designing the protocol. 823 d. Not contain inherent architectural or signaling constraints that 824 would prohibit peak calling rates on the order of 140 calls/second 825 on a moderately loaded network. 827 e. Allow for default/provisioned settings so that commands need only 828 contain non-default parameters. 830 9. Transport 832 9.1. Assumptions made for underlying network 834 The protocol must assume that the underlying network: 836 Internet draft MG control protocol requirements 9 December 1999 838 a. May be over large shared networks: proximity assumptions are not 839 allowed. 841 b. Does not assure reliable delivery of messages. 843 c. Does not guarantee ordering of messages: Sequenced delivery of mes- 844 sages associated with the same source of events is not assumed. 846 d. Does not prevent duplicate transmissions. 848 9.2. Transport Requirements 850 The protocol must: 852 a. Provide the ability to abort delivery of obsolete messages at the 853 sending end if their transmission has not been successfully com- 854 pleted. For example, aborting a command that has been overtaken by 855 events. 857 b. Support priority messages: The protocol shall allow a command pre- 858 cedence to allow priority messages to supercede non-priority mes- 859 sages. 861 c. Support of large fan-out at the MGC. 863 d. Provide a way for one entity to correlate commands and responses 864 with the other entity. 866 e. Provide a reason for any command failure. 868 f. Provide that loss of a packet not stall messages not related to the 869 message(s) contained in the packet lost. 871 Note that there may be enough protocol reliability requirements here to 872 warrant a separate reliable transport layer be written apart from the 873 Media Gateway control protocol. Also need to compare Megaco reliable 874 transport requirements with similar Sigtran requirements. 876 10. Security Requirements 878 Security mechanisms may be specified as provided in underlying transport 879 mechanisms, such as IPSEC. The protocol, or such mechanisms, must: 881 a. Allow for mutual authentication at the start of an MGC-MG associa- 882 tion 884 Internet draft MG control protocol requirements 9 December 1999 886 b. Allow for preservation of the of control messages once the associa- 887 tion has been established. 889 c. Allow for optional confidentiality protection of control messages. 890 The mechanism should allow a choice in the algorithm to be used. 892 d. Operate across untrusted domains in a secure fashion. 894 e. Support non-repudiation for a customer-located MG talking to a net- 895 work operator's MGC. 897 g. Define mechanisms to mitigate denial of service attacks 899 Note: the protocol document will need to include an extended discussion 900 of security requirements, offering more precision on each threat and 901 giving a complete picture of the defense including non-protocol measures 902 such as configuration. 904 h. It would be desirable for the protocol to be able to pass through 905 commonly-used firewalls. 907 11. Requirements specific to particular bearer types 909 The bearer types listed in Table 1 can be packaged into different types 910 of MGs. Examples are listed in the following sections. How they are 911 packaged is outside the scope of the general Media Gateway control pro- 912 tocol. The protocol must support all types of bearer types listed in 913 Table 1. 915 Internet draft MG control protocol requirements 9 December 1999 917 Table 1: Bearer Types and Applications 919 Bearer Type Applications Transit Network 920 ================================================================ 921 Trunk+ISUP trunking/access IP, ATM, FR 922 Voice,Fax,NAS, 923 Multimedia 925 Trunk+MF trunking/access IP, ATM, FR 926 Voice,Fax,NAS, 927 Multimedia 929 ISDN trunking/access IP, ATM, FR 930 Voice,Fax,NAS, 931 Multimedia 933 Analogue Voice,Fax, IP, ATM, FR 934 Text Telephony 936 Termination in a Restricted Voice,Fax, IP, ATM, FR 937 Capability Gateway Text Telephony 939 Application Termination IVR,ARF, Announcement Server, 940 Voice Recognition Server,... 942 Multimedia H.323 H.323 Multimedia IP, ATM, FR 943 Gateway and MCU 945 Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR 947 11.1. Media-specific Bearer Types 949 This section describes requirements for handling terminations attached 950 to specific types of networks. 952 11.1.1. Requirements for TDM PSTN (Circuit) 954 This bearer type is applicable to a Trunking GW, Access GW, ... 956 The protocol must allow: 958 a. the MGC to specify the encoding to use on the attached circuit. 960 b. In general, if something is set by a global signalling protocol 962 Internet draft MG control protocol requirements 9 December 1999 964 (e.g. ISUP allows mu-Law or A-Law to be signaled using ISUP) then 965 it must be settable by the protocol. 967 c. TDM attributes: 969 * Echo cancellation, 971 * PCM encoding or other voice compression (e.g. mu-law or A-law), 973 * encryption, 975 * rate adaptation (e.g. V.110, or V.120). 977 d. for incoming calls, identification of a specific TDM circuit 978 (timeslot and facility). 980 e. for calls outgoing to the circuit network, identification of a 981 specific circuit or identification of a circuit group with the 982 indication that the MG must select and return the identification of 983 an available member of that group. 985 f. specification of the default encoding of content passing to and 986 from a given circuit, possibly on a logical or physical circuit 987 group basis. 989 g. specification at any point during the life of a connection of vari- 990 able aspects of the content encoding, particularly including chan- 991 nel information capacity. 993 h. specification at any point during the life of a connection of loss 994 padding to be applied to incoming and outgoing media streams at the 995 circuit termination. 997 i. specification at any point during the life of a connection of the 998 applicability of echo cancellation to the outgoing media stream. 1000 j. Multi-rate calls to/from the SCN. 1002 k. H-channel (n x 64K) calls to/from the SCN. 1004 l. B channel aggregation protocols for creating high speed channels 1005 for multimedia over the SCN. 1007 m. Modem terminations and negotiations. 1009 The protocol may also allow: 1011 Internet draft MG control protocol requirements 9 December 1999 1013 l. specification of sub-channel media streams, 1015 m. specification of multi-channel media streams. 1017 11.1.2. Packet Bearer Type 1019 The protocol must be able to specify: 1021 a. ingress and egress coding (i.e. the way packets coming in and out 1022 are encoded) (including encryption). 1024 b. near and far-end ports and other session parameters for RTP and 1025 RTCP. 1027 The protocol must support reporting of: 1029 c. re-negotiation of codec for cause - for further study 1031 d. on Trunking and Access Gateways, resources capable of more than one 1032 active connection at a time must also be capable of mixing and 1033 packet duplication. 1035 The protocol must allow: 1037 e. specification of parameters for outgoing and incoming packet flows 1038 at separate points in the life of the connection (because far-end 1039 port addresses are typically obtained through a separate signalling 1040 exchange before or after the near-end port addresses are assigned). 1042 f. the possibility for each Media Gateway to allocate the ports on 1043 which it will receive packet flows (including RTCP as well as media 1044 streams) and report its allocations to the Media Gateway Controller 1045 for signalling to the far end. Note that support of different IP 1046 backbone providers on a per call basis would require that the ports 1047 on which packets flow be selected by the MGC. (but only if the IP 1048 address of the MG is different for each backbone provider). 1050 g. the specification at any point during the life of a connection of 1051 RTP payload type and RTP session number for each RTP-encapsulated 1052 media flow. 1054 h. the ability to specify whether outgoing flows are to be uni-cast or 1055 multi-cast. Note that on an IP network this information is implicit 1056 in the destination address, but in other networks this is a connec- 1057 tion parameter. 1059 i. invoking of encryption/decryption on media flows and specification 1061 Internet draft MG control protocol requirements 9 December 1999 1063 of the associated algorithm and key. 1065 The protocol should also allow: 1067 j. the MGC to configure non-RTP (proprietary or other) encapsulated 1068 packet flows. 1070 11.1.3. Bearer type requirements for ATM 1072 This bearer type is applicable to Trunking GW, Access GW, .... 1074 11.1.3.1. Addressing 1076 a. The protocol must be able to specify the following termination 1077 attributes: 1079 * VC identifier, 1081 * VC identifier plus AAL2 slot, and variant of these allowing the 1082 gateway to choose (part of) the identifier, 1084 * remote termination network address, remote MG name. 1086 b. Allow specification of an ATM termination which is to be assigned 1087 to an MG connection as a VC identifier, a VC identifier plus AAL2 1088 slot, a wild-carded variant of either of these. A remote termina- 1089 tion network address, or a remote MG name could also be used when 1090 the MG can select the VC and change the VC during the life of the 1091 connection by using ATM signalling. 1093 c. Provide an indication by the MG of the VC identifier and possibly 1094 AAL2 slot of the termination actually assigned to a connection. 1096 d. Provide a means to refer subsequently to that termination. 1098 e. Refer to an existing VCC as the physical interface + Virtual Path 1099 Identifier (VPI) + Virtual Circuit Identifier (VCI). 1101 f. Where the VCC is locally established (SVCs signalled by the Gateway 1102 through UNI or PNNI signalling or similar), the VCC must be 1103 indirectly referred to in terms which are of significance to both 1104 ends of the VCC. For example, a global name or the ATM address of 1105 the ATM devices at each end of the VCC. However, it is possible/ 1106 probable that there may be several VCCs between a given pair of ATM 1107 devices. Therefore the ATM address pair must be further resolved by 1108 a VCC identifier unambiguous within the context of the ATM address 1110 Internet draft MG control protocol requirements 9 December 1999 1112 pair. 1114 g. refer to a VCC as the Remote GW ATM End System Address + VCCI. 1116 h. allow the VCCI to be selected by the MG or imposed on the MG. 1118 i. support all ATM addressing variants (e.g. ATM End System Address 1119 (AESA) and E.164). 1121 11.1.3.2. Connection related requirements 1123 The protocol must: 1125 a. Allow for the de-coupling of creation/deletion of the narrow-band 1126 connection from the creation/deletion of the underlying VCC. 1128 b. Allow for efficient disconnection of all connections associated 1129 with a physical port or VCC. As an example, this could aggregate 1130 disconnections across a broadband circuit which experienced a phy- 1131 sical error. 1133 c. Allow the connection established using this protocol to be carried 1134 over a VCC, which may be a: 1136 * PVC or SPVC, 1138 * an SVC established on demand, either by the MGC itself or by a 1139 broker acting on its behalf or, 1141 * an SVC originated as required by the local MG, or by the remote end 1142 to the local MG through UNI or PNNI signalling. 1144 d. Allow ATM transport parameters and QoS parameters to be passed to 1145 the MG. 1147 e. Allow blocking and unblocking of a physical interface, a VCC or an 1148 AAL1/AAL2 channel. 1150 The protocol should: 1152 f. Where a VCC is required to be established on a per narrow-band call 1153 basis, allow all necessary information to be passed in one message. 1155 11.1.3.3. Media adaptation 1157 The protocol must: 1159 Internet draft MG control protocol requirements 9 December 1999 1161 a. Allow AAL parameters to be passed to the MG. 1163 b. Allow AAL1/AAL2 multiple narrow-band calls to be mapped to a single 1164 VCC. For AAL2, these calls are differentiated within each VCC by a 1165 AAL2 channel identifier. An AAL2 connection may span more than 1 1166 VCC and transit AAL2 switching devices. ITU Q.2630.1 [2] defines 1167 an end-to-end identifier called the Served User Generated Reference 1168 (SUGR). It carries information from the originating user of the 1169 AAL2 signalling protocol to the terminating user transparently and 1170 unmodified. 1172 c. Allow unambiguous binding of a narrow band call to an AAL2 connec- 1173 tion identifier, or AAL1 channel, within the specified VCC. 1175 d. Allow the AAL2 connection identifier, or AAL1 channel, to be 1176 selected by the MG or imposed on the MG. 1178 e. Allow the use of the AAL2 channel identifier (cid) instead of the 1179 AAL2 connection identifier. 1181 f. Allow the AAL2 voice profile to be imposed or negotiated before the 1182 start of the connection. AAL2 allows for variable length packets 1183 and varying packet rates, with multiple codecs possible within a 1184 given profile. Thus a given call may upgrade or downgrade the codec 1185 within the lifetime of the call. Idle channels may generate zero 1186 bandwidth. Thus an AAL2 VCC may vary in bandwidth and possibly 1187 exceed its contract. Congestion controls within a gateway may react 1188 to congestion by modifying codec rates/types. 1190 g. Allow the MGC to instruct the MG on how individual narrow-band 1191 calls behave under congestion. 1193 [Editor's Note: The ATM Forum is concerned that the above requirement 1194 (g.) is not specific enough to handle all ATM traffic management capa- 1195 bilities. They will provide a more specific requirement at a later 1196 date.] 1198 h. Allow for the MGC to specify an AAL5 bearer, with the following 1199 choices: 1201 * Per ATM Forum standard AF-VTOA-0083 [4], 1203 * RTP with IP/UDP, 1205 * RTP without IP/IDP per H.323v2 Annex C [5], 1207 * Compressed RTP per ATM Forum AF-SAA-0124.000 [6]. 1209 Internet draft MG control protocol requirements 9 December 1999 1211 i. Allow unambiguous binding of a narrow band call to an AAL1 channel 1212 within the specified VCC. (In AAL1, multiple narrow-band calls may 1213 be mapped to a single VCC.) 1215 11.1.3.4. Reporting requirements 1217 The protocol should: 1219 a. Allow any end-of-call statistics to show loss/restoration of under- 1220 lying VCC within the calls duration, together with duration of 1221 loss. 1223 b. Allow notification, as requested by MGC, of any congestion 1224 avoidance actions taken by the MG. 1226 The protocol must: 1228 c. Allow for ATM VCCs or AAL2 channels to be audited by the MGC. 1230 d. Allow changes in status of ATM VCCs or AAL2 channels to be notified 1231 as requested by the MGC. 1233 e. Allow the MGC to query the resource and endpoint availability. 1234 Resources may include VCCs, and DSPs. VCCs may be up or down. End- 1235 points may be connection-free, connected or unavailable. 1237 11.1.3.5. Functional requirements 1239 The protocol must: 1241 a. Allow an MGC to reserve a bearer, and specify a route for it 1242 through the network. 1244 11.2. Application-Specific Requirements 1246 11.2.1. Trunking Gateway 1248 A Trunking Gateway is an interface between SCN networks and Voice over 1249 IP or Voice over ATM networks. Such gateways typically interface to SS7 1250 or other NNI signalling on the SCN and manage a large number of digital 1251 circuits. 1253 The protocol must: 1255 a. Provide circuit and packet-side loopback. 1257 Internet draft MG control protocol requirements 9 December 1999 1259 b. Provide circuit-side n x 64kbs connections. 1261 c. Provide subrate and multirate connections -for further study. 1263 d. Provide lawful wiretap capability 1265 e. Provide the capability to support Reporting/generation of per-trunk 1266 CAS signalling (DP, DTMF, MF, R2, J2, and national variants). 1268 f. Provide the capability to support reporting of detected DTMF events 1269 either digit-by-digit, as a sequence of detected digits with a 1270 flexible mechanism For the MG to determine the likely end of dial 1271 string, or in a separate RTP stream. 1273 g. Provide the capability to support ANI and DNIS generation and 1274 reception. 1276 11.2.2. Access Gateway 1278 An Access Gateway connects UNI interfaces like ISDN (PRI and BRI) or 1279 traditional analog voice terminal interfaces, to a Voice over IP or 1280 Voice over ATM network, or Voice over Frame Relay network. 1282 The Protocol must: 1284 a. Support detection and generation of analog line signaling (hook- 1285 state, ring generation). 1287 b. Provide the capability to support reporting of detected DTMF events 1288 either digit-by-digit, as a sequence of detected digits with a 1289 flexible mechanism For the MG to determine the likely end of dial 1290 string, or in a separate RTP stream. 1292 c. Not require scripting mechanisms, event buffering, digit map 1293 storage when implementing restricted function (1-2 line) gateways 1294 with very limited capabilities. 1296 d. Provide the capability to support CallerID generation and recep- 1297 tion. 1299 Proxying of the protocol is for further study. 1301 11.2.3. Trunking/Access Gateway with fax ports 1303 a. the protocol must be able to indicate detection of fax media. 1305 Internet draft MG control protocol requirements 9 December 1999 1307 b. the protocol must be able to specify T.38 for the transport of the 1308 fax. 1310 c the protocol must be able to specify G.711 encoding for transport 1311 of fax tones across a packet network. 1313 11.2.4. Trunking/Access Gateway with text telephone access ports 1315 An access gateway with ports capable of text telephone communication, 1316 must provide communication between text telephones in the SCN and text 1317 conversation channels in the packet network. 1319 Text telephone capability of ports is assumed to be possible to combine 1320 with other options for calls as described in section 11.2.6 (e.) on 1321 "Adaptable NASes". 1323 The port is assumed to adjust for the differences in the supported text 1324 telephone protocols, so that the text media stream can be communicated 1325 T.140 coded in the packet network without further transcoding [7]. 1327 The protocol must be capable of reporting the type of text telephone 1328 that is connected to the SCN port. The foreseen types are the same as 1329 the ones supported by ITU-T V.18: DTMF, EDT, Baudot-45, Baudot-50, 1330 Bell, V.21, Minitel and V.18. It should be possible to control which 1331 protocols are supported. The SCN port is assumed to contain ITU-T V.18 1332 functionality [8]. 1334 The protocol must be able to control the following functionality levels 1335 of text telephone support: 1337 a. Simple text-only support: The call is set into text mode from the 1338 beginning of the call, in order to conduct a text-only conversa- 1339 tion. 1341 b. Alternating text-voice support: The call may begin in voice mode or 1342 text mode and, at any moment during the call, change mode on 1343 request by the SCN user. On the packet side, the two media streams 1344 for voice and text must be opened, and it must be possible to con- 1345 trol the feeding of each stream by the protocol. 1347 c. Simultaneous text and voice support: The call is performed in a 1348 mode when simultaneous text and voice streams are supported. The 1349 call may start in voice mode and during the call change state to a 1350 text-and-voice call. 1352 A port may implement only level a, or any level combination of a, b and 1353 c, always including level a. 1355 Internet draft MG control protocol requirements 9 December 1999 1357 The protocol must support: 1359 d. A text based alternative to the interactive voice response, or 1360 audio resource functionality of the gateway when the port is used 1361 in text telephone mode. 1363 e. Selection of what national translation table to be used between the 1364 Unicode based T.140 and the 5-7 bit based text telephone protocols. 1366 f. Control of the V.18 probe message to be used on incoming calls. 1368 11.2.5. Trunking/Access Gateway with conference ports (Multipoint Pro- 1369 cessing Unit) 1371 11.2.6. Network Access Server 1373 A NAS is an access gateway, or Media Gateway (MG), which terminates 1374 modem signals or synchronous HDLC connections from a network (e.g. SCN 1375 or xDSL network) and provides data access to the packet network. Only 1376 those requirements specific to a NAS are described here. 1378 Figure 1 provides a reference architecture for a Network Access Server 1379 (NAS). Signaling comes into the MGC and the MGC controls the NAS. 1381 +-------+ +-------+ 1382 Signaling | | | | 1383 -----------+ MGC + | AAA | 1384 | | | | 1385 +---+---+ +--+----+ 1386 | | 1387 Megaco|_______________| 1388 | 1389 | 1390 +---+---+ ~~|~~~ 1391 Bearer | | ( ) 1392 -----------+ NAS +-------( IP ) 1393 | | ( ) 1394 +-------+ ~~~~~~ 1396 Figure 1: NAS reference architecture 1398 The Protocol must support: 1400 a. Callback capabilities: 1402 Internet draft MG control protocol requirements 9 December 1999 1404 * Callback 1406 b. Modem calls. The protocol must be able to specify the modem 1407 type(s) to be used for the call. 1409 c. Carriage of bearer information. The protocol must be able to 1410 specify the data rate of the TDM connection (e.g., 64 kbit/s, 56 1411 kbit/s, 384 kbit/s), if this is available from the SCN. 1413 d. Rate Adaptation: The protocol must be able to specify the type of 1414 rate adaptation to be used for the call including indicating the 1415 subrate, if this is available from the SCN (e.g. 56K, or V.110 sig- 1416 naled in Bearer capabilities with subrate connection of 19.2kbit/s. 1418 e. Adaptable NASes: The protocol must be able to support multiple 1419 options for an incoming call to allow the NAS to dynamically select 1420 the proper type of call. For example, an incoming ISDN call coded 1421 for "Speech" Bearer Capability could actually be a voice, modem, 1422 fax, text telephone, or 56 kbit/s synchronous call. The protocol 1423 should allow the NAS to report back to the MGC the actual type of 1424 call once it is detected. 1426 The 4 basic types of bearer for a NAS are: 1428 1. Circuit Mode, 64-kbps, 8-khz structured, Speech 1430 2. Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio 1432 3. Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital 1433 Transmission-Rate Adapted from 56-kbps 1435 4. Circuit Mode, 64-kbps, 8-khz structure, Unrestricted Digital 1436 Transmission 1438 f. Passage of Called and Calling Party Number information to the NAS 1439 from the MGC. Also, passage of Charge Number/Billing Number, 1440 Redirecting Number, and Original Call Number, if known, to the NAS 1441 from the MGC. If there are other Q.931 fields that need to be 1442 passed from the MGC to the MG, then it should be possible to pass 1443 them [9]. 1445 g. Ability for the MGC to direct the NAS to connect to a specific tun- 1446 nel, for example to an LNS, or to an AAA server. 1448 h. When asked by the MGC, be able to report capability information, 1449 for example, connection types (V.34/V90/Synch ISDN..), AAA mechan- 1450 ism (RADIUS/DIAMETER/..), access type (PPP/SLIP/..) after restart 1451 or upgrade. 1453 Internet draft MG control protocol requirements 9 December 1999 1455 11.2.7. Restricted Capability Gateway 1457 The requirements here may also be applied to small analog gateways, and 1458 to cable/xDSL modems. See also the section on access gateways. 1460 The Protocol must support: 1462 a. The ability to provide a scaled down version of the protocol. When 1463 features of the protocol are not supported, an appropriate error 1464 message must be sent. Appropriate default action must be defined. 1465 Where this is defined may be outside the scope of the protocol. 1467 b. The ability to provide device capability information to the MGC 1468 with respect to the use of the protocol. 1470 11.2.8. Multimedia Gateway 1472 The protocol must have sufficient capability to support a multimedia 1473 gateway. H.320 and H.324 are characterized by a single data stream with 1474 multiple media streams multiplexed on it. 1476 If the mapping is from H.320 or H.324 on the circuit side, and H.323 on 1477 the packet side, it is assumed that the MG knows how to map respective 1478 subchannels from H.320/H.324 side to streams on packet side. If extra 1479 information is required when connecting two terminations, then it must 1480 be supplied so that the connections are not ambiguous. 1482 The Multimedia Gateway: 1484 1) should support Bonding Bearer channel aggregation, 1486 2) must support 2xB (and possibly higher rates) aggregation via H.221, 1488 3) must be able to dynamically change the size of audio, video and 1489 data channels within the h.320 multiplex, 1491 4) must react to changes in the H.320 multiplex on 20 msec boundaries, 1493 5) must support TCS4/IIS BAS commands, 1495 6) must support detection and creation of DTMF tones, 1497 7) should support SNMP MIBS as specified in H.341 [3] 1499 a. If some of the above cannot be handled by the MGC to MG protocol 1500 due to timing constraints, then it is likely that the H.245 to 1501 H.242 processing must take place in the MG. Otherwise, support for 1502 this functionality in the multimedia gateway are protocol 1504 Internet draft MG control protocol requirements 9 December 1999 1506 requirements. 1508 b. It must be possible on a call by call basis for the protocol to 1509 specify different applications. Thus, one call might be PSTN to 1510 PSTN under SS7 control, while the next might be ISDN/H.320 under 1511 SS7 control to H.323. This is only one example; the key require- 1512 ment is that the protocol not prevent such applications. 1514 11.2.9. Audio Resource Function 1516 An Audio Resource Function (ARF) consists of one or more functional 1517 modules which can be deployed on an stand alone media gateway server 1518 IVR, Intelligent Peripheral, speech/speaker recognition unit, etc. or a 1519 traditional media gateway. Such a media gateway is known as an Audio 1520 Enabled Gateway (AEG) if it performs tasks defined in one or more of the 1521 following ARF functional modules: 1523 Play Audio, 1524 DTMF Collect, 1525 Record Audio, 1526 Speech Recognition, 1527 Speaker Verification/Identification, 1528 Auditory Feature Extraction/Recognition, or 1529 Audio Conferencing. 1531 Additional ARF function modules that support human to machine communica- 1532 tions through the use of telephony tones (e.g., DTMF) or auditory means 1533 (e.g. speech) may be appended to the AEG definition in future versions 1534 of these requirements. 1536 Generic scripting packages for any module must support all the require- 1537 ments for that module. Any package extension for a given module must 1538 include, by inheritance or explicit reference, the requirements for that 1539 given module. 1541 The protocol requirements for each of the ARF modules are provided in 1542 the following subsections. 1544 11.2.9.1. Play Audio Module 1546 a. Be able to provide the following basic operation: 1548 - request an ARF MG to play an announcement. 1550 b. Be able to specify these play characteristics: 1552 Internet draft MG control protocol requirements 9 December 1999 1554 - Play volume 1556 - Play speed 1558 - Play iterations 1560 - Interval between play iterations 1562 - Play duration 1564 c. Permit the specification of voice variables such as DN, number, 1565 date, time, etc. The protocol must allow specification of both 1566 the value (eg 234-3456), and well as the type (Directory number). 1568 d. Using the terminology that a segment is a unit of playable speech, 1569 or is an abstraction that is resolvable to a unit of playable 1570 speech, permit specification of the following segment types: 1572 - A provisioned recording. 1574 - A block of text to be converted to speech. 1576 - A block of text to be displayed on a device. 1578 - A length of silence qualified by duration. 1580 - An algorithmically generated tone. 1582 - A voice variable, specified by type and value. Given a variable 1583 type and value, the IVR/ARF unit would dynamically assemble the 1584 phrases required for its playback. 1586 - An abstraction that represents a sequence of audio segments. Nest- 1587 ing of these abstractions must also be permitted. 1589 An example of this abstraction is a sequence of audio segments, the 1590 first of which is a recording of the words "The number you have dialed," 1591 followed by a Directory Number variable, followed by a recording of the 1592 words "is no longer in service." 1594 - An abstraction that represents a set of audio segments and which is 1595 resolved to a single segment by a qualifier. Nesting of these 1596 abstractions must be permitted. 1598 For example take a set of audio segments recorded in different languages 1599 all of which express the semantic concept "The number you have dialed is 1600 no longer in service." The set is resolved by a language qualifier. If 1601 the qualifier is "French," the set resolves to the French version of 1603 Internet draft MG control protocol requirements 9 December 1999 1605 this announcement. 1607 In the case of a nested abstraction consisting of a set qualified by 1608 language at one level and and a set qualified by gender at another 1609 level, it would be possible to specify that an announcement be played 1610 in French and spoken by a female voice. 1612 e. Provide two different methods of audio specification: 1614 - Direct specification of the audio components to be played by speci- 1615 fying the sequence of segments in the command itself. 1617 - Indirect specification of the audio components to be played by 1618 reference to a single identifier that resolves to a provisioned 1619 sequence of audio segments. 1621 11.2.9.2. DTMF Collect Module 1623 The DTMF Collect Module must support all of the requirements in the Play 1624 Module in addition to the following requirements: 1626 a. Be able to provide the following basic operation: 1628 - request an AEG to play an announcement, which may optionally ter- 1629 minated by DTMF, and then collect DTMF 1631 b. Be able to specify these event collection characteristics: 1633 - The number of attempts to give the user to enter a valid DTMF pat- 1634 tern. 1636 c. With respect to digit timers, allow the specification of: 1638 - Time allowed to enter the first digit. 1640 - Time allowed for user to enter each digit subsequent to the first 1641 digit. 1643 - Time allowed for user to enter a digit once the maximum expected 1644 number of digits has been entered. 1646 d. To be able to allow multiple prompt operations DTMF digit collec- 1647 tion, voice recording (if supported), and/or speech recognition 1648 analysis (if supported) provide the following types of prompts: 1650 - Initial Prompt 1652 Internet draft MG control protocol requirements 9 December 1999 1654 - Reprompt 1656 - Error prompt 1658 - Failure announcement 1660 - Success announcement. 1662 e. To allow digit pattern matching, allow the specification of: 1664 - maximum number of digits to collect. 1666 - minimum number of digits to collect. 1668 - a digit pattern using a regular expression. 1670 f. To allow digit buffer control, allow the specification of: 1672 - Ability to clear digit buffer prior to playing initial prompt 1673 (default is not to clear buffer). 1675 - Default clearing of buffer following playing of un-interruptible 1676 announcement segment. 1678 - Default clearing of buffer before playing a re-prompt in response 1679 to previous invalid input. 1681 g. Provide a method to specify DTMF interruptibility on a per audio 1682 segment basis. 1684 h. Allow the specification of definable key sequences for DTMF digit 1685 collection to: 1687 - Discard collected digits in progress, replay the prompt, and resume 1688 DTMF digit collection. 1690 - Discard collected digits in progress and resume DTMF digit collec- 1691 tion. 1693 - Terminate the current operation and return the terminating key 1694 sequence to the MGC. 1696 i. Provide a way to ask the ARF MG to support the following definable 1697 keys for digit collection and recording. These keys would then be 1698 able to be acted upon by the ARF MG: 1700 - A key to terminate playing of an announcement in progress. 1702 Internet draft MG control protocol requirements 9 December 1999 1704 - A set of one or more keys that can be accepted as the first digit 1705 to be collected. 1707 - A key that signals the end of user input. The key may or may not 1708 be returned to the MGC along with the input already collected. 1710 - Keys to stop playing the current announcement and resume playing at 1711 the beginning of the first segment of the announcement, last seg- 1712 ment of the announcement, previous segment of the announcement, 1713 next segment of the announcement, or the current announcement seg- 1714 ment. 1716 11.2.9.3. Record Audio Module 1718 The Record Module must support all of the requirements in the Play 1719 Module as in addition to the following requirements: 1721 a. Be able to provide the following basic operation: 1723 - request an AEG to play an announcement and then record voice. 1725 b. Be able to specify these event collection characteristics: 1727 - The number of attempts to give the user to make a recording. 1729 c. With respect to recording timers, allow the specification of: 1731 - Time to wait for the user to initially speak. 1733 - The amount of silence necessary following the last speech segment 1734 for the recording to be considered complete. 1736 - The maximum allowable length of the recording (not including pre- 1737 and post- speech silence). 1739 d. To be able to allow multiple prompt operations for DTMF digit col- 1740 lection (if supported), voice recording (if supported), speech 1741 recognition analysis (if supported) and/or speech 1742 verification/identification (if supported) and then to provide the 1743 following types of prompts: 1745 - Initial Prompt 1747 - Reprompt 1749 - Error prompt 1751 Internet draft MG control protocol requirements 9 December 1999 1753 - Failure announcement 1755 - Success announcement. 1757 e. Allow the specification of definable key sequences for digit 1758 recording or speech recognition analysis (if supported) to: 1760 - Discard recording in progress, replay the prompt, and resume 1761 recording. 1763 - Discard recording in progress and resume recording. 1765 - Terminate the current operation and return the terminating key 1766 sequence to the MGC. 1768 f. Provide a way to ask the ARF MG to support the following definable 1769 keys for recording. These keys would then be able to be acted upon 1770 by the ARF MG: 1772 - A key to terminate playing of an announcement in progress. 1774 - A key that signals the end of user input. The key may or may not 1775 be returned to the MGC along with the input already collected. 1777 - Keys to stop playing the current announcement and resume playing at 1778 the beginning of the first segment of the announcement, last seg- 1779 ment of the announcement, previous segment of the announcement, 1780 next segment of the announcement, or the current announcement seg- 1781 ment. 1783 g. While audio prompts are usually provisioned in IVR/ARF MGs, support 1784 changing the provisioned prompts in a voice session rather than a 1785 data session. In particular, with respect to audio management: 1787 - A method to replace provisioned audio with audio recorded during a 1788 call. The newly recorded audio must be accessible using the iden- 1789 tifier of the audio it replaces. 1791 - A method to revert from replaced audio to the original provisioned 1792 audio. 1794 - A method to take audio recorded during a call and store it such 1795 that it is accessible to the current call only through its own 1796 newly created unique identifier. 1798 - A method to take audio recorded during a call and store it such 1799 that it is accessible to any subsequent call through its own newly 1800 created identifier. 1802 Internet draft MG control protocol requirements 9 December 1999 1804 11.2.9.4. Speech Recognition Module 1806 The speech recognition module can be used for a number of speech recog- 1807 nition applications, such as: 1809 - Limited Vocabulary Isolated Speech Recognition (e.g., "yes", "no", 1810 the number "four"), 1812 - Limited Vocabulary Continuous Speech Feature Recognition (e.g., the 1813 utterace "four hundred twenty-three dollars"),and/or 1815 - Continuous Speech Recognition (e.g., unconstrained speech recogni- 1816 tion tasks). 1818 The Speech Recognition Module must support all of the requirements in 1819 the Play Module as in addition to the following requirements: 1821 a. Be able to provide the following basic operation: request an AEG to 1822 play an announcement and then perform speech recognition analysis. 1824 b. Be able to specify these event collection characteristics: 1826 - The number of attempts to give to perform speech recognition task. 1828 c. With respect to speech recognition analysis timers, allow the 1829 specification of: 1831 - Time to wait for the user to initially speak. 1833 - The amount of silence necessary following the last speech segment 1834 for the speech recognition analysis segment to be considered com- 1835 plete. 1837 - The maximum allowable length of the speech recognition analysis 1838 (not including pre- and post- speech silence). 1840 d. To be able to allow multiple prompt operations for DTMF digit col- 1841 lection (if supported), voice recording (if supported), and/or 1842 speech recognition analysis and then to provide the following types 1843 of prompts: 1845 - Initial Prompt 1847 - Reprompt 1849 - Error prompt 1851 - Failure announcement 1853 Internet draft MG control protocol requirements 9 December 1999 1855 - Success announcement. 1857 e. Allow the specification of definable key sequences for digit 1858 recording (if supported) or speech recognition analysis to: 1860 - Discard in process analysis, replay the prompt, and resume 1861 analysis. 1863 - Discard recording in progress and resume analysis. 1865 - Terminate the current operation and return the terminating key 1866 sequence to the MGC. 1868 f. Provide a way to ask the ARF MG to support the following definable 1869 keys for speech recognition analysis. These keys would then be able 1870 to be acted upon by the ARF MG: 1872 - A key to terminate playing of an announcement in progress. 1874 - A key that signals the end of user input. The key may or may not 1875 be returned to the MGC along with the input already collected. 1877 - Keys to stop playing the current announcement and resume playing at 1878 the beginning of the first segment of the announcement, last seg- 1879 ment of the announcement, previous segment of the announcement, 1880 next segment of the announcement, or the current announcement seg- 1881 ment. 1883 11.2.9.5. Speaker Verification/Identification Module 1885 The speech verification/identification module returns parameters that 1886 indicate either the likelihood of the speaker to be the person that they 1887 claim to be (verification task) or the likelihood of the speaker being 1888 one of the persons contained in a set of previously characterized speak- 1889 ers (identification task). 1891 The Speaker Verification/Identification Module must support all of the 1892 requirements in the Play Module in addition to the following require- 1893 ments: 1895 a. Be able to download parameters, such as speaker templates (verifi- 1896 cation task) or sets of potential speaker templates (identification 1897 task), either prior to the session or in mid-session. 1899 b. Be able to download application specific software to the ARF either 1900 prior to the session or in mid-session. 1902 Internet draft MG control protocol requirements 9 December 1999 1904 c. Be able to return parameters indicating either the likelihood of 1905 the speaker to be the person that they claim to be (verification 1906 task) or the likelihood of the speaker being one of the persons 1907 contained in a set of previously characterized speakers (identifi- 1908 cation task). 1910 d. Be able to provide the following basic operation: request an AEG to 1911 play an announcement and then perform speech 1912 verification/identification analysis. 1914 e. Be able to specify these event collection characteristics: The 1915 number of attempts to give to perform speech 1916 verification/identification task. 1918 f. With respect to speech verification/identification analysis timers, 1919 allow the specification of: 1921 - Time to wait for the user to initially speak. 1923 - The amount of silence necessary following the last speech segment 1924 for the speech verification/identification analysis segment to be 1925 considered complete. 1927 - The maximum allowable length of the speech 1928 verification/identification analysis (not including pre- and 1929 post-speech silence). 1931 g. To be able to allow multiple prompt operations for DTMF digit col- 1932 lection (if supported), voice recording, (if supported), speech 1933 recognition analysis (if supported) and/or speech 1934 verification/identification and provide the following types of 1935 prompts: 1937 - Initial Prompt 1939 - Reprompt 1941 - Error prompt 1943 - Failure announcement 1945 - Success announcement. 1947 h. Allow the specification of definable key sequences for digit 1948 recording (if supported) or speech recognition (if supported) in 1949 the speech verification/identification analysis to: 1951 - Discard speech verification/identification in analysis, replay the 1953 Internet draft MG control protocol requirements 9 December 1999 1955 prompt, and resume analysis. 1957 - Discard speech verification/identification analysis in progress and 1958 resume analysis. 1960 - Terminate the current operation and return the terminating key 1961 sequence to the MGC. 1963 i. Provide a way to ask the ARF MG to support the following definable 1964 keys for speech verification/identification analysis. These keys 1965 would then be able to be acted upon by the ARF MG: 1967 - A key to terminate playing of an announcement in progress. 1969 - A key that signals the end of user input. The key may or may not 1970 be returned to the MGC along with the input already collected. 1972 - Keys to stop playing the current announcement and resume speech 1973 verification/identification at the beginning of the first segment 1974 of the announcement, last segment of the announcement, previous 1975 segment of the announcement, next segment of the announcement, or 1976 the current announcement segment. 1978 11.2.9.6. Auditory Feature Extraction/Recognition Module 1980 The auditory feature extraction/recognition module is engineered to con- 1981 tinuously monitor the auditory stream for the appearance of particular 1982 auditory signals or speech utterances of interest and to report these 1983 events (and optionally a signal feature representation of these events) 1984 to network servers or MGCs. 1986 The Auditory Feature Extraction/Recognition Module must support the fol- 1987 lowing requirements: 1989 a. Be able to download application specific software to the ARF either 1990 prior to the session or in mid-session. 1992 b. Be able to download parameters, such as a representation of the 1993 auditory feature to extract/recognize, for prior to the session or 1994 in mid-session. 1996 c. Be able to return parameters indicating the auditory event found or 1997 a representation of the feature found (i.e., auditory feature). 1999 Internet draft MG control protocol requirements 9 December 1999 2001 11.2.9.7. Audio Conferencing Module 2003 The protocol must support: 2005 a. a mechanism to create multi-point conferences of audio only and 2006 multimedia conferences in the MG. 2008 b. audio mixing; mixing multiple audio streams into a new composite 2009 audio stream 2011 c. audio switching; selection of incoming audio stream to be sent out 2012 to all conference participants. 2014 11.2.10. Multipoint Control Units 2016 The protocol must support: 2018 a. a mechanism to create multi-point conferences of audio only and 2019 multimedia conferences in the MG. 2021 b. audio mixing; mixing multiple audio streams into a new composite 2022 audio stream 2024 c. audio switching; selection of incoming audio stream to be sent out 2025 to all conference participants. 2027 d. video switching; selection of video stream to be sent out to all 2028 conference participants 2030 e. lecture video mode; a video selection option where on video source 2031 is sent out to all conference users 2033 f. multi-point of T.120 data conferencing. 2035 g. The ability for the MG to function as an H.323 MP, and for the MGC 2036 to function as an H.323 MC, connected by this protocol 2037 (MEGACOP/H.248). It should be possible for audio, data, and video 2038 MG/MPs to be physically separate while being under the control of a 2039 single MGC/H.323 MC. 2041 12. Full Copyright Statement 2043 Copyright (C) The Internet Society (1999, 2000). All Rights Reserved. 2045 Internet draft MG control protocol requirements 9 December 1999 2047 This document and translations of it may be copied and furnished to oth- 2048 ers, and derivative works that comment on or otherwise explain it or 2049 assist in its implementation may be prepared, copied, published and dis- 2050 tributed, in whole or in part, without restriction of any kind, provided 2051 that the above copyright notice and this paragraph are included on all 2052 such copies and derivative works. However, this document itself may not 2053 be modified in any way, such as by removing the copyright notice or 2054 references to the Internet Society or other Internet organizations, 2055 except as needed for the purpose of developing Internet standards in 2056 which case the procedures for copyrights defined in the Internet Stan- 2057 dards process must be followed, or as required to translate it into 2058 languages other than English. 2060 The limited permissions granted above are perpetual and will not be 2061 revoked by the Internet Society or its successors or assigns. 2063 This document and the information contained herein is provided on an "AS 2064 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2065 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2066 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2067 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- 2068 NESS FOR A PARTICULAR PURPOSE." 2070 13. References 2072 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- 2073 els", RFC 2119, March 1997. 2075 [2] ITU-T Q.2630.1 2077 [3] ITU-T H.341 2079 [4] AF-VTOA-0083, ATM Forum document 2081 [5] ITU H.323v2 Annex C Recommendation 2083 [6] ATM Forum AF-SAA-0124.000 2085 [7] ITU-T T.140 2087 [8] ITU-T V.18 2089 [9] ITU-T Q.931 2091 Internet draft MG control protocol requirements 9 December 1999 2093 14. Acknowledgements 2095 The authors would like to acknowledge the many contributors who debated 2096 the media gateway control architecture and requirements on the IETF 2097 Megaco and Sigtran mailing lists. Contributions to this document have 2098 also been made through internet-drafts and discussion with members of 2099 ETSI Tiphon, ITU-T SG16, TIA TR41.3.4, the ATM Forum, and the Multiser- 2100 vice Switching Forum. 2102 15. Authors' addresses 2104 Nancy Greene 2105 Nortel Networks 2106 P.O. Box 3511 Stn C 2107 Ottawa, ON, Canada K1Y 4H7 2108 Tel: (514) 271-7221 2109 Email: ngreene@nortelnetworks.com 2111 Michael A. Ramalho 2112 Cisco Systems 2113 Wall Township, NJ 2114 Tel: +1.732.449.5762 2115 Email: mramalho@cisco.com 2117 Brian Rosen 2118 Fore Systems 2119 1000 FORE Drive, Warrendale, PA 15086 2120 Tel: (724) 742-6826 2121 Email: brosen@eng.fore.com