rfc2805.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   f.   Support point-to-point and point-to-multipoint connections.

   g.   Support creation and modification of more complex flow
        topologies e.g. conference bridge capabilities.  Be able to add
        or delete media streams during a call or session, and be able to
        add or subtract participants to/from a call or session.

   h.   Support inclusion of media resources into call or session as
        required.  Depending on the protocol and resource type, media
        resources may be implicitly included, class-assigned, or
        individually assigned.

   i.   Provide unambiguous specification of which media flows pass
        through a point and which are blocked at a given point in time,
        if the protocol permits multiple flows to pass through the same
        point.

   j.   Allow modifications of an existing termination, for example, use
        of higher compression to compensate for insufficient bandwidth
        or changing transport network connections.

   k.   Allow the MGC to specify that a given connection has higher
        priority than other connections.




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


   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.

5.3.  Media Transformations

   The Protocol must:

   a.   Support mediation/adaptation of flows between different types of
        transport

   b.   Support invocation of additional processing such as echo
        cancellation.

   c.   Support mediation of flows between different content encoding
        (codecs, encryption/decryption)

   d.   Allow the MGC to specify whether text telephony/FAX/data modem
        traffic is to be terminated at the MG, modulated/demodulated,
        and converted to packets or forwarded by the MG in the media
        flow as voice band traffic.

   e.   Allow the MGC to specify that Dual-Tone MultiFrequency (DTMF)
        digits or other line and trunk signals and general Multi-
        Frequency (MF) tones are to be processed in the MG and how these
        digits/signals/tones are to be handled. The MGC must be able to
        specify any of the following handling of such
        digits/signals/tones:

   1.   The digits/signals/tones are to be encoded normally in the audio
        RTP stream (e.g., no analysis of the digits/signals/tones).

   2.   Analyzed and sent to the MGC.

   3.   Received from the MGC and inserted in the line-side audio
        stream.

   4.   Analyzed and sent as part of a separate RTP stream (e.g., DTMF
        digits sent via a RTP payload separate from the audio RTP
        stream).

   5.   Taken from a separate RTP stream and inserted in the line-side
        audio stream.



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


   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.

5.4.  Signal/Event Processing and Scripting

   The Protocol must:

   a.   Allow the MGC to enable/disable monitoring for specific
        supervision events at specific circuit terminations

   b.   Allow the MGC to enable/disable monitoring for specific events
        within specified media streams

   c.   Allow reporting of detected events on the MG to the MGC. The
        protocol should provide the means to minimize the messaging
        required to report commonly-occurring event sequences.

   d.   Allow the MGC to specify other actions (besides reporting) that
        the MG should take upon detection of specified events.

   e.   Allow the MGC to enable and/or mask events.

   f.   Provide a way for MGC to positively acknowledge event
        notification.



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


   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.

5.5.  QoS/CoS

   The Protocol must:

   a.   Support the establishment of a bearer channel with a specified
        QoS/CoS.

   b.   Support the ability to specify QoS for the connection between
        MGs, and by direction.

   c.   Support a means to change QoS during a connection, as a whole
        and by direction.

   d.   Allow the MGC to set QOS thresholds and receive notification
        when such thresholds cannot be maintained.

   e.   Allow the jitter buffer parameters on RTP channels to be
        specified at connection setup.








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


5.6.  Test Support

   The protocol must:

   a.   Support of the different types of PSTN Continuity Testing (COT)
        for both the originating and terminating ends of the circuit
        connection (2-wire and 4- wire).

   b.   Specifically support test line operation (e.g. 103, 105, 108).

5.7.  Accounting

   The protocol must:

   a.   Support a common identifier to mark resources related to one
        connection.

   b.   Support collection of specified accounting information from MGs.

   c.   Provide the mechanism for the MGC to specify that the MG report
        accounting information automatically at end of call, in mid-call
        upon request, at specific time intervals as specified by the MGC
        and at unit usage thresholds as specified by the MGC.

   d.   Specifically support collection of:

   *    start and stop time, by media flow,

   *    volume of content carried (e.g. number of packets/cells
        transmitted, number received with and without error, inter-
        arrival jitter), by media flow,

   *    QOS statistics, by media flow.

   e.   Allow the MGC to have some control over which statistics are
        reported, to enable it to manage the amount of information
        transferred.

5.8.  Signalling Control

   Establishment and provisioning of signalling backhaul channels (via
   SIGTRAN for example) is out of scope.  However, the MG must be
   capable of supporting detection of events, and application of signals
   associated with basic analogue line, and CAS type signalling.  The
   protocol must:

   a.   Support the signalling requirements of analogue lines and
        Channel Associated Signaling (CAS).



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


   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.

6.  Resource Control

6.1.  Resource Status Management

   The protocol must:

   a.   Allow the MG to report changes in status of physical entities
        supporting bearer terminations, media resources, and facility-
        associated signalling channels, due to failures, recovery, or
        administrative action. It must be able to report whether a
        termination is in service or out of service.

   b.   Support administrative blocking and release of TDM circuit
        terminations.

   Note: as the above point only relates to ISUP-controlled circuits, it
   may be unnecessary to require this since the MGC controls their use.
   However, it may be meaningful for MF and R2-signalled trunks, where
   supervisory states are set to make the trunks unavailable at the far
   end.

   c.   Provide a method for the MGC to request that the MG release all
        resources under the control of a particular MGC currently in
        use, or reserved, for any or all connections.

   d.   Provide an MG Resource Discovery mechanism which must allow an
        MGC to discover what resources the MG has. Expressing resources
        can be an arbitrarily difficult problem and the initial release
        of the protocol may have a simplistic view of resource
        discovery.

        At a minimum, resource discovery must enumerate the names of
        available circuit terminations and the allowed values for
        parameters supported by terminations.





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


        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.

6.2.  Resource Assignment

   The protocol must:

   a.   Provide a way for the MG to indicate that it was unable to
        perform a requested action because of resource exhaustion, or
        because of temporary resource unavailability.

   b.   Provide an ability for the MGC to indicate to an MG the resource
        to use for a call (e.g. DS0) exactly, or indicate a set of
        resources (e.g. pick a DS0 on a T1 line or a list of codec
        types) via a "wild card" mechanism from which the MG can select
        a specific resource for a call (e.g. the 16th timeslot, or
        G.723).

   c.   Allow the use of DNS names and IP addresses to identify MGs and
        MGCs. This shall not preclude using other identifiers for MGs or
        MGCs when other non IP transport technologies for the protocol
        are used.

7.  Operational/Management Requirements

7.1.  Assurance of Control/Connectivity

   To provide assurance of control and connectivity, the protocol must
   provide the means to minimize duration of loss of control due to loss
   of contact, or state mismatches.



Greene, et al.               Informational                     [Page 13]