📄 rfc2805.txt
字号:
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.11.2.2. Access Gateway An Access Gateway connects UNI interfaces like ISDN (PRI and BRI) or traditional analog voice terminal interfaces, to a Voice over IP or Voice over ATM network, or Voice over Frame Relay network. The Protocol must: a. Support detection and generation of analog line signaling (hook-state, ring generation). b. 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. c. Not require scripting mechanisms, event buffering, digit map storage when implementing restricted function (1-2 line) gateways with very limited capabilities. d. Provide the capability to support CallerID generation and reception. Proxying of the protocol is for further study.11.2.3. Trunking/Access Gateway with fax ports a. the protocol must be able to indicate detection of fax media. b. the protocol must be able to specify T.38 for the transport of the fax. c. the protocol must be able to specify G.711 encoding for transport of fax tones across a packet network.Greene, et al. Informational [Page 27]RFC 2805 MG Control Protocol Requirements April 200011.2.4. Trunking/Access Gateway with text telephone access ports An access gateway with ports capable of text telephone communication, must provide communication between text telephones in the SCN and text conversation channels in the packet network. Text telephone capability of ports is assumed to be possible to combine with other options for calls as described in 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 [7]. 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 [8]. 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.Greene, et al. Informational [Page 28]RFC 2805 MG Control Protocol Requirements April 2000 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.11.2.5. Network Access Server A NAS is an access gateway, or Media Gateway (MG), which terminates modem signals or synchronous HDLC connections from a network (e.g. SCN or xDSL network) and provides data access to the packet network. Only those requirements specific to a NAS are described here. Figure 1 provides a reference architecture for a Network Access Server (NAS). Signaling comes into the MGC and the MGC controls the NAS. +-------+ +-------+ Signaling | | | | -----------+ MGC + | AAA | | | | | +---+---+ +--+----+ | | Megaco|_______________| | | +---+---+ ~~|~~~ Bearer | | ( ) -----------+ NAS +-------( IP ) | | ( ) +-------+ ~~~~~~ Figure 1: NAS reference architecture The Protocol must support: a. Callback capabilities: * Callback b. Modem calls. The protocol must be able to specify the modem type(s) to be used for the call. c. Carriage of bearer information. The protocol must be able to specify the data rate of the TDM connection (e.g., 64 kbit/s, 56 kbit/s, 384 kbit/s), if this is available from the SCN.Greene, et al. Informational [Page 29]RFC 2805 MG Control Protocol Requirements April 2000 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 [9]. 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.11.2.6. Restricted Capability Gateway The requirements here may also be applied to small analog gateways, and to cable/xDSL modems. See also the section on access gateways.Greene, et al. Informational [Page 30]RFC 2805 MG Control Protocol Requirements April 2000 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.11.2.7. Multimedia Gateway The protocol must have sufficient capability to support a multimedia gateway. H.320 and H.324 are characterized by a single data stream with multiple media streams multiplexed on it. If the mapping is from H.320 or H.324 on the circuit side, and H.323 on the packet side, it is assumed that the MG knows how to map respective subchannels from H.320/H.324 side to streams on packet side. If extra information is required when connecting two terminations, then it must be supplied so that the connections are not ambiguous. The Multimedia Gateway: 1) should support Bonding Bearer channel aggregation, 2) must support 2xB (and possibly higher rates) aggregation via H.221, 3) must be able to dynamically change the size of audio, video and data channels within the h.320 multiplex, 4) must react to changes in the H.320 multiplex on 20 msec boundaries, 5) must support TCS4/IIS BAS commands, 6) must support detection and creation of DTMF tones, 7) should support SNMP MIBS as specified in H.341 [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.Greene, et al. Informational [Page 31]RFC 2805 MG Control Protocol Requirements April 2000 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.11.2.8. Audio Resource Function An Audio Resource Function (ARF) consists of one or more functional modules which can be deployed on an stand alone media gateway server IVR, Intelligent Peripheral, speech/speaker recognition unit, etc. or a traditional media gateway. Such a media gateway is known as an Audio Enabled Gateway (AEG) if it performs tasks defined in one or more of the following ARF functional modules: Play Audio, DTMF Collect, Record Audio, Speech Recognition, Speaker Verification/Identification, Auditory Feature Extraction/Recognition, or Audio Conferencing. Additional ARF function modules that support human to machine communications through the use of telephony tones (e.g., DTMF) or auditory means (e.g. speech) may be appended to the AEG definition in future versions of these requirements. Generic scripting packages for any module must support all the requirements for that module. Any package extension for a given module must include, by inheritance or explicit reference, the requirements for that given module. The protocol requirements for each of the ARF modules are provided in the following subsections.11.2.8.1. Play Audio Module a. Be able to provide the following basic operation: - request an ARF MG to play an announcement. b. Be able to specify these play characteristics: - Play volume - Play speedGreene, et al. Informational [Page 32]RFC 2805 MG Control Protocol Requirements April 2000 - 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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -