rfc2805.txt

RFC 的详细文档！

        of loss.

   b.   Allow notification, as requested by MGC, of any congestion
        avoidance actions taken by the MG.

   The protocol must:

   c.   Allow for ATM VCCs or AAL2 channels to be audited by the MGC.

   d.   Allow changes in status of ATM VCCs or AAL2 channels to be
        notified as requested by the MGC.

   e.   Allow the MGC to query the resource and endpoint availability.
        Resources may include VCCs, and DSPs. VCCs may be up or down.
        End-points may be connection-free, connected or unavailable.

11.1.3.5.  Functional requirements

   The protocol must:

   a.   Allow an MGC to reserve a bearer, and specify a route for it
        through the network.

11.2.  Application-Specific Requirements

11.2.1.  Trunking Gateway

   A Trunking Gateway is an interface between SCN networks and Voice
   over IP or Voice over ATM networks.  Such gateways typically
   interface to SS7 or other NNI signalling on the SCN and manage a
   large number of digital circuits.

   The protocol must:

   a.   Provide circuit and packet-side loopback.

   b.   Provide circuit-side n x 64kbs connections.

   c.   Provide subrate and multirate connections for further study.






Greene, et al.               Informational                     [Page 26]

RFC 2805            MG Control Protocol Requirements          April 2000


   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 2000


11.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,