rfc2805.txt

RFC 的详细文档！

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


                 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

11.1.  Media-specific Bearer Types

   This section describes requirements for handling terminations
   attached to specific types of networks.

11.1.1.  Requirements for TDM PSTN (Circuit)

   This bearer type is applicable to a Trunking GW, Access GW, ...

   The protocol must allow:

   a.   the MGC to specify the encoding to use on the attached circuit.

   b.   In general, if something is set by a global signalling protocol
        (e.g. ISUP allows mu-Law or A-Law to be signaled using ISUP)
        then it must be settable by the protocol.





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


   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.



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


11.1.2.  Packet Bearer Type

   The protocol must be able to specify:

   a.   ingress and egress coding (i.e. the way packets coming in and
        out are encoded) (including encryption).

   b.   near and far-end ports and other session parameters for RTP and
        RTCP.

   The protocol must support reporting of:

   c.   re-negotiation of codec for cause - for further study

   d.   on Trunking and Access Gateways, resources capable of more than
        one active connection at a time must also be capable of mixing
        and packet duplication.

   The protocol must allow:

   e.   specification of parameters for outgoing and incoming packet
        flows at separate points in the life of the connection (because
        far-end port addresses are typically obtained through a separate
        signalling exchange before or after the near-end port addresses
        are assigned).

   f.   the possibility for each Media Gateway to allocate the ports on
        which it will receive packet flows (including RTCP as well as
        media streams) and report its allocations to the Media Gateway
        Controller for signalling to the far end.  Note that support of
        different IP backbone providers on a per call basis would
        require that the ports on which packets flow be selected by the
        MGC. (but only if the IP address of the MG is different for each
        backbone provider).

   g.   the specification at any point during the life of a connection
        of RTP payload type and RTP session number for each RTP-
        encapsulated media flow.

   h.   the ability to specify whether outgoing flows are to be uni-cast
        or multi-cast. Note that on an IP network this information is
        implicit in the destination address, but in other networks this
        is a connection parameter.

   i.   invoking of encryption/decryption on media flows and
        specification of the associated algorithm and key.





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


   The protocol should also allow:

   j.   the MGC to configure non-RTP (proprietary or other) encapsulated
        packet flows.

11.1.3.  Bearer type requirements for ATM

   This bearer type is applicable to Trunking GW, Access GW, ....

11.1.3.1.  Addressing

   a.   The protocol must be able to specify the following termination
        attributes:

   *    VC identifier,

   *    VC identifier plus AAL2 slot, and variant of these allowing the
        gateway to choose (part of) the identifier,

   *    remote termination network address, remote MG name.

   b.   Allow specification of an ATM termination which is to be
        assigned to an MG connection as a VC identifier, a VC identifier
        plus AAL2 slot, a wild-carded variant of either of these. A
        remote termination network address, or a remote MG name could
        also be used when the MG can select the VC and change the VC
        during the life of the connection by using ATM signalling.

   c.   Provide an indication by the MG of the VC identifier and
        possibly AAL2 slot of the termination actually assigned to a
        connection.

   d.   Provide a means to refer subsequently to that termination.

   e.   Refer to an existing VCC as the physical interface + Virtual
        Path Identifier (VPI) + Virtual Circuit Identifier (VCI).

   f.   Where the VCC is locally established (SVCs signalled by the
        Gateway through UNI or PNNI signalling or similar), the VCC must
        be indirectly referred to in terms which are of significance to
        both ends of the VCC. For example, a global name or the ATM
        address of the ATM devices at each end of the VCC. However, it
        is possible/probable that there may be several VCCs between a
        given pair of ATM devices. Therefore the ATM address pair must
        be further resolved by a VCC identifier unambiguous within the
        context of the ATM address pair.

   g.   refer to a VCC as the Remote GW ATM End System Address + VCCI.



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


   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).

11.1.3.2.  Connection related requirements

   The protocol must:

   a.   Allow for the de-coupling of creation/deletion of the narrow-
        band connection from the creation/deletion of the underlying
        VCC.

   b.   Allow for efficient disconnection of all connections associated
        with a physical port or VCC. As an example, this could aggregate
        disconnections across a broadband circuit which experienced a
        physical error.

   c.   Allow the connection established using this protocol to be
        carried over a VCC, which may be a:

   *    PVC or SPVC,

   *    an SVC established on demand, either by the MGC itself or by a
        broker acting on its behalf or,

   *    an SVC originated as required by the local MG, or by the remote
        end to the local MG through UNI or PNNI signalling.

   d.   Allow ATM transport parameters and QoS parameters to be passed
        to the MG.

   e.   Allow blocking and unblocking of a physical interface, a VCC or
        an AAL1/AAL2 channel.

   The protocol should:

   f.   Where a VCC is required to be established on a per narrow-band
        call basis, allow all necessary information to be passed in one
        message.

11.1.3.3.  Media adaptation

   The protocol must:

   a.   Allow AAL parameters to be passed to the MG.





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


   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 [2] 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 [4],

   *    RTP with IP/UDP,

   *    RTP without IP/IDP per H.323v2 Annex C [5],

   *    Compressed RTP per ATM Forum AF-SAA-0124.000 [6].

   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.)





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


11.1.3.4.  Reporting requirements

   The protocol should:

   a.   Allow any end-of-call statistics to show loss/restoration of
        underlying VCC within the calls duration, together with duration