Network Working Group N. Greene Request for Comments: 2805 Nortel Networks Category: Informational M. Ramalho Cisco Systems B. Rosen Marconi April 2000 Media Gateway Control Protocol Architecture and Requirements Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway.
1. Introduction .............................................. 3 2. Terminology ............................................... 3 3. Definitions ............................................... 3 4. Specific functions assumed within the MG .................. 5 5. Per-Call Requirements ..................................... 6 5.1. Resource Reservation ................................. 6 5.2. Connection Requirements .............................. 7 5.3. Media Transformations ................................ 8 5.4. Signal/Event Processing and Scripting ................ 9 5.5. QoS/CoS .............................................. 10 5.6. Test Support ......................................... 11 5.7. Accounting ........................................... 11 5.8. Signalling Control ................................... 11 6. Resource Control .......................................... 12 6.1. Resource Status Management ........................... 12 6.2. Resource Assignment .................................. 13 7. Operational/Management Requirements ....................... 13 7.1. Assurance of Control/Connectivity .................... 13 7.2. Error Control ........................................ 14 7.3. MIB Requirements ..................................... 15 8. General Protocol Requirements ............................. 15 8.1. MG-MGC Association Requirements ...................... 16 8.2. Performance Requirements ............................. 17 9. Transport ................................................. 17 9.1. Assumptions made for underlying network .............. 17 9.2. Transport Requirements ............................... 18 10. Security Requirements .................................... 18 11. Requirements specific to particular bearer types ......... 19 11.1. Media-specific Bearer types ......................... 20 11.1.1. Requirements for TDM PSTN (Circuit) ............ 20 11.1.2. Packet Bearer type ............................. 22 11.1.3. Bearer type requirements for ATM ............... 23 11.2. Application-Specific Requirements ................... 26 11.2.1. Trunking Gateway ............................... 26 11.2.2. Access Gateway ................................. 27 11.2.3. Trunking/Access Gateway with fax ports ......... 27 11.2.4. Trunking/Access Gateway with text telephone .... 28 11.2.5. Network Access Server .......................... 29 11.2.6. Restricted Capability Gateway .................. 30 11.2.7. Multimedia Gateway ............................. 31 11.2.8. Audio Resource Function ........................ 32 11.2.9. Multipoint Control Units ........................ 42 12. References ............................................... 43 13. Acknowledgements ......................................... 43 14. Authors' Addresses ....................................... 44 15. Full Copyright Statement ................................. 45
* Media Gateway unit (MG-unit) An MG-unit is a physical entity that contains an MG function and may also contain other functions, e.g. an SG function. * Media Gateway Controller (MGC) function A Media Gateway Controller (MGC) function controls a MG. * Media Resource Examples of media resources are codecs, announcements, tones, and modems, interactive voice response (IVR) units, bridges, etc. * Signaling Gateway (SG) function An SG function receives/sends SCN native signalling at the edge of a data network. For example the SG function may relay, translate or terminate SS7 signaling in an SS7-Internet Gateway. The SG function may also be co-resident with the MG function to process SCN signalling associated with line or trunk terminations controlled by the MG, such as the "D" channel of an ISDN PRI trunk. * Termination A termination is a point of entry and/or exit of media flows relative to the MG. When an MG is asked to connect two or more terminations, it understands how the flows entering and leaving each termination are related to each other. Terminations are, for instance, DS0's, ATM VCs and RTP ports. Another word for this is bearer point. * Trunk An analog or digital connection from a circuit switch which carries user media content and may carry telephony signalling (MF, R2, etc.). Digital trunks may be transported and may appear at the Media Gateway as channels within a framed bit stream, or as an ATM cell stream. Trunks are typically provisioned in groups, each member of which provides equivalent routing and service. * Type of Bearer A Type of Bearer definition provides the detailed requirements for its particular application/bearer type. A particular class of Media Gateway, for example, would support a particular set of Bearer types.
MGs must also support some level of system related functions, such as establishing and maintaining some kind of MG-MGC association. This is essential for MGC redundancy, fail-over and resource sharing. Therefore, an MG is assumed to contain these functions: * Reservation and release, of resources * Ability to provide state of resources * Maintenance of resources - It must be possible to make maintenance operations independent of other termination functions, for instance, some maintenance states should not affect the resources associated with that resource . Examples of maintenance functions are loopbacks and continuity tests. * Connection management, including connection state. * Media processing, using media resources: these provide services such as transcoding, conferencing, interactive voice recognition units, audio resource function units. Media resources may or may not be directly part of other resources. * Incoming digit analysis for terminations, interpretation of scripts for terminations * Event detection and signal insertion for per-channel signalling * Ability to configure signalling backhauls (for example, a Sigtran backhaul) * Management of the association between the MGC and MG, or between the MGC and MG resources.
c. The MG is not required (or allowed) by the protocol to maintain a sense of future time: a reservation remains in effect until explicitly released by the MGC.
l. Allow a reference to a port/termination on the MG to be a logical identifier, with a one-to-one mapping between a logical identifier and a physical port. m. Allow the MG to report events such as resource reservation and connection completion.
6. Handled according to a script of instructions. For all but the first case, an option to mute the digits/signals/tones with silence, comfort noise, or other means (e.g., notch filtering of some telephony tones) must be provided. As detection of these events may take up to tens of milliseconds, the first few milliseconds of such digit/signal/tone may be encoded and sent in the audio RTP stream before the digit/signal/tone can be verified. Therefore muting of such digits/signals/tones in the audio RTP stream with silence or comfort noise is understood to occur at the earliest opportunity after the digit/signal/tone is verified. f. Allow the MGC to specify signalled flow characteristics on circuit as well as on packet bearer connections, e.g. u-law/a- law. g. Allow for packet/cell transport adaptation only (no media adaptation) e.g. mid-stream (packet-to-packet) transpacketization/transcoding, or ATM AAL5 to and from ATM AAL2 adaptation. h. Allow the transport of audio normalization levels as a setup parameter, e.g., for conference bridging. i. Allow conversion to take place between media types e.g., text to speech and speech to text.
g. Allow the MGC to specify signals (e.g., supervision, ringing) to be applied at circuit terminations. h. Allow the MGC to specify content of extended duration (announcements, continuous tones) to be inserted into specified media flows. i. Allow the MGC to specify alternative conditions (detection of specific events, timeouts) under which the insertion of extended-duration signals should cease. j. Allow the MGC to download, and specify a script to be invoked on the occurrence of an event. k. Specify common events and signals to maximize MG/MGC interworking. l. Provide an extension mechanism for implementation defined events and signals with, for example, IANA registration procedures. It may be useful to have an Organizational Identifier (i.e. ITU, ETSI, ANSI, ) as part of the registration mechanism. m. The protocol shall allow the MGC to request the arming of a mid-call trigger even after the call has been set up.
b. Support national variations of such signalling. c. Provide mechanisms to support signalling without requiring MG- MGC timing constraints beyond that specified in this document. d. Must not create a situation where the MGC and the MG must be homologated together as a mandatory requirement of using the protocol; i.e. it must be possible to optionally conceal signaling type variation from the MGC.
The protocol should be defined so that simple gateways could respond with a relatively short, pre-stored response to the discovery request mechanism. In general, if the protocol defines a mechanism that allows the MGC to specify a setting or parameter for a resource or connection in the MG, and MGs are not required to support all possible values for that setting or parameter, then the discovery mechanism should provide the MGC with a method to determine what possible values such settings or parameters are supported in a particular MG. e. Provide a mechanism to discover the current available resources in the MG, where resources are dynamically consumed by connections and the MGC cannot reasonably or reliably track the consumption of such resources. It should also be possible to discover resources currently in use, in order to reconcile inconsistencies between the MGC and the MG. f. Not require an MGC to implement an SNMP manager function in order to discover capabilities of an MG that may be specified during context establishment.
The protocol must: a. Support detection and recovery from loss of contact due to failure/congestion of communication links or due to MG or MGC failure. Note that failover arrangements are one of the mechanisms which could be used to meet this requirement. b. Support detection and recovery from loss of synchronized view of resource and connection states between MGCs and MGs. (e.g. through the use of audits). c. Provide a means for MGC and MG to provide each other with booting and reboot indications, and what the MG's configuration is. d. Permit more than one backup MGC and provide an orderly way for the MG to contact one of its backups. e. Provide for an orderly switchback to the primary MGC after it recovers. How MGCs coordinate resources between themselves is outside the scope of the protocol. f. Provide a mechanism so that when an MGC fails, connections already established can be maintained. The protocol does not have to provide a capability to maintain connections in the process of being connected, but not actually connected when the failure occurs. g. The Protocol must allow the recovery or redistribution of traffic without call loss.
d. Allow the MG to notify the MGC that a termination was terminated and communicate a reason when a terminations is taken out-of- service unilaterally by the MG due to abnormal events. e. Allow the MGC to acknowledge that a termination has been taken out-of-service. f. Allow the MG to request the MGC to release a termination and communicate a reason. g. Allow the MGC to specify, as a result of such a request its decision to take termination down, leave it as is or modify it.
c. Be flexible in allocation of intelligence between MG and MGC. For example, an MGC may want to allow the MG to assign particular MG resources in some implementations, while in others, the MGC may want to be the one to assign MG resources for use. d. Support scalability from very small to very large MGs: The protocol must support MGs with capacities ranging from one to millions of terminations. e. Support scalability from very small to very large MGC span of control: The protocol should support MGCs that control from one MG to a few tens of thousands of MGs. f. Support the needs of a residential gateway that supports one to a few lines, and the needs of a large PSTN gateway supporting tens of thousands of lines. Protocol mechanisms favoring one extreme or the other should be minimized in favor of more general purpose mechanism applicable to a wide range of MGs. Where special purpose mechanisms are proposed to optimize a subset of implementations, such mechanisms should be defined as optional, and should have minimal impact on the rest of the protocol. g. Facilitate MG and MGC version upgrades independently of one another. The protocol must include a version identifier in the initial message exchange. h. Facilitate the discovery of the protocol capabilities of the one entity to the other. i. Specify commands as optional (they can be ignored) or mandatory (the command must be rejected), and within a command, to specify parameters as optional (they can be ignored) or mandatory (the command must be rejected).
c. Provide a method for the MG to tell an MGC that the MG received a command for a resource that is under the control of a different MGC. d. Support a method for the MG to control the rate of requests it receives from the MGC (e.g. windowing techniques, exponential back-off). e. Support a method for the MG to tell an MGC that it cannot handle any more requests.
d. Does not prevent duplicate transmissions.
e. Support non-repudiation for a customer-located MG talking to a network operator's MGC. f. Define mechanisms to mitigate denial of service attacks Note: the protocol document will need to include an extended discussion of security requirements, offering more precision on each threat and giving a complete picture of the defense including non- protocol measures such as configuration. g. It would be desirable for the protocol to be able to pass through commonly-used firewalls.
Table 1: Bearer Types and Applications Bearer Type Applications Transit Network ================================================================ Trunk+ISUP trunking/access IP, ATM, FR Voice,Fax,NAS, Multimedia Trunk+MF trunking/access IP, ATM, FR Voice,Fax,NAS, Multimedia ISDN trunking/access IP, ATM, FR Voice,Fax,NAS, Multimedia Analogue Voice,Fax, IP, ATM, FR Text Telephony Termination in a Restricted Voice,Fax, IP, ATM, FR Capability Gateway Text Telephony Application Termination IVR,ARF, Announcement Server, Voice Recognition Server,... Multimedia H.323 H.323 Multimedia IP, ATM, FR Gateway and MCU Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR
c. TDM attributes: * Echo cancellation, * PCM encoding or other voice compression (e.g. mu-law or A-law), * encryption, * rate adaptation (e.g. V.110, or V.120). d. for incoming calls, identification of a specific TDM circuit (timeslot and facility). e. for calls outgoing to the circuit network, identification of a specific circuit or identification of a circuit group with the indication that the MG must select and return the identification of an available member of that group. f. specification of the default encoding of content passing to and from a given circuit, possibly on a logical or physical circuit group basis. g. specification at any point during the life of a connection of variable aspects of the content encoding, particularly including channel information capacity. h. specification at any point during the life of a connection of loss padding to be applied to incoming and outgoing media streams at the circuit termination. i. specification at any point during the life of a connection of the applicability of echo cancellation to the outgoing media stream. j. Multi-rate calls to/from the SCN. k. H-channel (n x 64K) calls to/from the SCN. l. B channel aggregation protocols for creating high speed channels for multimedia over the SCN. m. Modem terminations and negotiations. The protocol may also allow: n. specification of sub-channel media streams, o. specification of multi-channel media streams.
The protocol should also allow: j. the MGC to configure non-RTP (proprietary or other) encapsulated packet flows.
h. allow the VCCI to be selected by the MG or imposed on the MG. i. support all ATM addressing variants (e.g. ATM End System Address (AESA) and E.164).
b. Allow AAL1/AAL2 multiple narrow-band calls to be mapped to a single VCC. For AAL2, these calls are differentiated within each VCC by a AAL2 channel identifier. An AAL2 connection may span more than 1 VCC and transit AAL2 switching devices. ITU Q.2630.1  defines an end-to-end identifier called the Served User Generated Reference (SUGR). It carries information from the originating user of the AAL2 signalling protocol to the terminating user transparently and unmodified. c. Allow unambiguous binding of a narrow band call to an AAL2 connection identifier, or AAL1 channel, within the specified VCC. d. Allow the AAL2 connection identifier, or AAL1 channel, to be selected by the MG or imposed on the MG. e. Allow the use of the AAL2 channel identifier (cid) instead of the AAL2 connection identifier. f. Allow the AAL2 voice profile to be imposed or negotiated before the start of the connection. AAL2 allows for variable length packets and varying packet rates, with multiple codecs possible within a given profile. Thus a given call may upgrade or downgrade the codec within the lifetime of the call. Idle channels may generate zero bandwidth. Thus an AAL2 VCC may vary in bandwidth and possibly exceed its contract. Congestion controls within a gateway may react to congestion by modifying codec rates/types. g. Allow the MGC to instruct the MG on how individual narrow-band calls behave under congestion. h. Allow for the MGC to specify an AAL5 bearer, with the following choices: * Per ATM Forum standard AF-VTOA-0083 , * RTP with IP/UDP, * RTP without IP/IDP per H.323v2 Annex C , * Compressed RTP per ATM Forum AF-SAA-0124.000 . i. Allow unambiguous binding of a narrow band call to an AAL1 channel within the specified VCC. (In AAL1, multiple narrow-band calls may be mapped to a single VCC.)
d. Provide the capability to support Reporting/generation of per-trunk CAS signalling (DP, DTMF, MF, R2, J2, and national variants). e. Provide the capability to support reporting of detected DTMF events either digit-by-digit, as a sequence of detected digits with a flexible mechanism For the MG to determine the likely end of dial string, or in a separate RTP stream. f. Provide the capability to support ANI and DNIS generation and reception.
section 11.2.6 (e.) on "Adaptable NASes". The port is assumed to adjust for the differences in the supported text telephone protocols, so that the text media stream can be communicated T.140 coded in the packet network without further transcoding . The protocol must be capable of reporting the type of text telephone that is connected to the SCN port. The foreseen types are the same as the ones supported by ITU-T V.18: DTMF, EDT, Baudot-45, Baudot-50, Bell, V.21, Minitel and V.18. It should be possible to control which protocols are supported. The SCN port is assumed to contain ITU-T V.18 functionality . The protocol must be able to control the following functionality levels of text telephone support: a. Simple text-only support: The call is set into text mode from the beginning of the call, in order to conduct a text-only conversation. b. Alternating text-voice support: The call may begin in voice mode or text mode and, at any moment during the call, change mode on request by the SCN user. On the packet side, the two media streams for voice and text must be opened, and it must be possible to control the feeding of each stream by the protocol. c. Simultaneous text and voice support: The call is performed in a mode when simultaneous text and voice streams are supported. The call may start in voice mode and during the call change state to a text-and-voice call. A port may implement only level a, or any level combination of a, b and c, always including level a. The protocol must support: d. A text based alternative to the interactive voice response, or audio resource functionality of the gateway when the port is used in text telephone mode.
e. Selection of what national translation table to be used between the Unicode based T.140 and the 5-7 bit based text telephone protocols. f. Control of the V.18 probe message to be used on incoming calls.
d. Rate Adaptation: The protocol must be able to specify the type of rate adaptation to be used for the call including indicating the subrate, if this is available from the SCN (e.g. 56K, or V.110 signaled in Bearer capabilities with subrate connection of 19.2kbit/s). e. Adaptable NASes: The protocol must be able to support multiple options for an incoming call to allow the NAS to dynamically select the proper type of call. For example, an incoming ISDN call coded for "Speech" Bearer Capability could actually be a voice, modem, fax, text telephone, or 56 kbit/s synchronous call. The protocol should allow the NAS to report back to the MGC the actual type of call once it is detected. The 4 basic types of bearer for a NAS are: 1. Circuit Mode, 64-kbps, 8-khz structured, Speech 2. Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio 3. Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital Transmission-Rate Adapted from 56-kbps 4. Circuit Mode, 64-kbps, 8-khz structure, Unrestricted Digital Transmission f. Passage of Called and Calling Party Number information to the NAS from the MGC. Also, passage of Charge Number/Billing Number, Redirecting Number, and Original Call Number, if known, to the NAS from the MGC. If there are other Q.931 fields that need to be passed from the MGC to the MG, then it should be possible to pass them . g. Ability for the MGC to direct the NAS to connect to a specific tunnel, for example to an LNS, or to an AAA server. h. When asked by the MGC, be able to report capability information, for example, connection types (V.34/V90/Synch ISDN..), AAA mechanism (RADIUS/DIAMETER/..), access type (PPP/SLIP/..) after restart or upgrade.
The Protocol must support: a. The ability to provide a scaled down version of the protocol. When features of the protocol are not supported, an appropriate error message must be sent. Appropriate default action must be defined. Where this is defined may be outside the scope of the protocol. b. The ability to provide device capability information to the MGC with respect to the use of the protocol. 3] a. If some of the above cannot be handled by the MGC to MG protocol due to timing constraints, then it is likely that the H.245 to H.242 processing must take place in the MG. Otherwise, support for this functionality in the multimedia gateway are protocol requirements.
b. It must be possible on a call by call basis for the protocol to specify different applications. Thus, one call might be PSTN to PSTN under SS7 control, while the next might be ISDN/H.320 under SS7 control to H.323. This is only one example; the key requirement is that the protocol not prevent such applications.
- Play iterations - Interval between play iterations - Play duration c. Permit the specification of voice variables such as DN, number, date, time, etc. The protocol must allow specification of both the value (eg 234-3456), and well as the type (Directory number). d. Using the terminology that a segment is a unit of playable speech, or is an abstraction that is resolvable to a unit of playable speech, permit specification of the following segment types: - A provisioned recording. - A block of text to be converted to speech. - A block of text to be displayed on a device. - A length of silence qualified by duration. - An algorithmically generated tone. - A voice variable, specified by type and value. Given a variable type and value, the IVR/ARF unit would dynamically assemble the phrases required for its playback. - An abstraction that represents a sequence of audio segments. Nesting of these abstractions must also be permitted. An example of this abstraction is a sequence of audio segments, the first of which is a recording of the words "The number you have dialed", followed by a Directory Number variable, followed by a recording of the words "is no longer in service". - An abstraction that represents a set of audio segments and which is resolved to a single segment by a qualifier. Nesting of these abstractions must be permitted. For example take a set of audio segments recorded in different languages all of which express the semantic concept "The number you have dialed is no longer in service". The set is resolved by a language qualifier. If the qualifier is "French", the set resolves to the French version of this announcement.
In the case of a nested abstraction consisting of a set qualified by language at one level and and a set qualified by gender at another level, it would be possible to specify that an announcement be played in French and spoken by a female voice. e. Provide two different methods of audio specification: - Direct specification of the audio components to be played by specifying the sequence of segments in the command itself. - Indirect specification of the audio components to be played by reference to a single identifier that resolves to a provisioned sequence of audio segments.
- Error prompt - Failure announcement - Success announcement. e. To allow digit pattern matching, allow the specification of: - maximum number of digits to collect. - minimum number of digits to collect. - a digit pattern using a regular expression. f. To allow digit buffer control, allow the specification of: - Ability to clear digit buffer prior to playing initial prompt (default is not to clear buffer). - Default clearing of buffer following playing of un-interruptible announcement segment. - Default clearing of buffer before playing a re-prompt in response to previous invalid input. g. Provide a method to specify DTMF interruptibility on a per audio segment basis. h. Allow the specification of definable key sequences for DTMF digit collection to: - Discard collected digits in progress, replay the prompt, and resume DTMF digit collection. - Discard collected digits in progress and resume DTMF digit collection. - Terminate the current operation and return the terminating key sequence to the MGC. i. Provide a way to ask the ARF MG to support the following definable keys for digit collection and recording. These keys would then be able to be acted upon by the ARF MG: - A key to terminate playing of an announcement in progress. - A set of one or more keys that can be accepted as the first digit to be collected.
- A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected. - Keys to stop playing the current announcement and resume playing at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment.
e. Allow the specification of definable key sequences for digit recording or speech recognition analysis (if supported) to: - Discard recording in progress, replay the prompt, and resume recording. - Discard recording in progress and resume recording. - Terminate the current operation and return the terminating key sequence to the MGC. f. Provide a way to ask the ARF MG to support the following definable keys for recording. These keys would then be able to be acted upon by the ARF MG: - A key to terminate playing of an announcement in progress. - A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected. - Keys to stop playing the current announcement and resume playing at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment. g. While audio prompts are usually provisioned in IVR/ARF MGs, support changing the provisioned prompts in a voice session rather than a data session. In particular, with respect to audio management: - A method to replace provisioned audio with audio recorded during a call. The newly recorded audio must be accessible using the identifier of the audio it replaces. - A method to revert from replaced audio to the original provisioned audio. - A method to take audio recorded during a call and store it such that it is accessible to the current call only through its own newly created unique identifier. - A method to take audio recorded during a call and store it such that it is accessible to any subsequent call through its own newly created identifier.
- Failure announcement - Success announcement. e. Allow the specification of definable key sequences for digit recording (if supported) or speech recognition analysis to: - Discard in process analysis, replay the prompt, and resume analysis. - Discard recording in progress and resume analysis. - Terminate the current operation and return the terminating key sequence to the MGC. f. Provide a way to ask the ARF MG to support the following definable keys for speech recognition analysis. These keys would then be able to be acted upon by the ARF MG: - A key to terminate playing of an announcement in progress. - A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected. - Keys to stop playing the current announcement and resume playing at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment.
b. Be able to download application specific software to the ARF either prior to the session or in mid-session. c. Be able to return parameters indicating either the likelihood of the speaker to be the person that they claim to be (verification task) or the likelihood of the speaker being one of the persons contained in a set of previously characterized speakers (identification task). d. Be able to provide the following basic operation: request an AEG to play an announcement and then perform speech verification/identification analysis. e. Be able to specify these event collection characteristics: The number of attempts to give to perform speech verification/identification task. f. With respect to speech verification/identification analysis timers, allow the specification of: - Time to wait for the user to initially speak. - The amount of silence necessary following the last speech segment for the speech verification/identification analysis segment to be considered complete. - The maximum allowable length of the speech verification/identification analysis (not including pre- and post- speech silence). g. To be able to allow multiple prompt operations for DTMF digit collection (if supported), voice recording, (if supported), speech recognition analysis (if supported) and/or speech verification/identification and provide the following types of prompts: - Initial Prompt - Reprompt - Error prompt - Failure announcement - Success announcement.
h. Allow the specification of definable key sequences for digit recording (if supported) or speech recognition (if supported) in the speech verification/identification analysis to: - Discard speech verification/identification in analysis, replay the prompt, and resume analysis. - Discard speech verification/identification analysis in progress and resume analysis. - Terminate the current operation and return the terminating key sequence to the MGC. i. Provide a way to ask the ARF MG to support the following definable keys for speech verification/identification analysis. These keys would then be able to be acted upon by the ARF MG: - A key to terminate playing of an announcement in progress. - A key that signals the end of user input. The key may or may not be returned to the MGC along with the input already collected. - Keys to stop playing the current announcement and resume speech verification/identification at the beginning of the first segment of the announcement, last segment of the announcement, previous segment of the announcement, next segment of the announcement, or the current announcement segment.
c. Be able to return parameters indicating the auditory event found or a representation of the feature found (i.e., auditory feature).
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  ITU-T Recommendation Q.2630.1, AAL type 2 Signalling Protocol (Capability Set 1), December 1999.  ITU-T Recommendation H.341, Line Transmission of Non-Telephone Signals, May 1999.  ATM Forum Technical Committee, af-vtoa-0083.001, Voice and Telephony Over ATM to the Desktop Specification, March 1999.  ITU-T Recommendation H.323v3, Packet-based Multimedia Communications Systems (includes Annex C - H.323 on ATM), September 1999.  ATM Forum Technical Committee, af-saa-0124.000, Gateway for H.323 Media Transport Over ATM, May 1999.  ITU-T Recommendation T.140, Protocol for Multimedia Application Text Conversation, February 1998.  ITU-T Recommendation V.18, Operational and Interworking Requirements for DCEs Operating in Text Telephone Mode, February 1998.  ITU-T Recommendation Q.931, Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN User - Network Interface Layer 3 Specification for Basic Call Control, May 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.