⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2805.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 5 页
字号:
   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 + -