doc: Add RFC documents

1 files changed, 2523 insertions, 0 deletions

diff --git a/doc/rfc/rfc2805.txt b/doc/rfc/rfc2805.txt
new file mode 100644
index 0000000..1bc1b71
--- /dev/null
+++ b/doc/rfc/rfc2805.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Network Working Group                                          N. Greene
+Request for Comments: 2805                               Nortel Networks
+Category: Informational                                       M. Ramalho
+                                                           Cisco Systems
+                                                                B. Rosen
+                                                                 Marconi
+                                                              April 2000
+
+
+      Media Gateway Control Protocol Architecture and Requirements
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes protocol requirements for the Media Gateway
+   Control Protocol between a Media Gateway Controller and a Media
+   Gateway.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Greene, et al.               Informational                      [Page 1]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+Table of Contents
+
+   1.  Introduction ..............................................  3
+   2.  Terminology ...............................................  3
+   3.  Definitions ...............................................  3
+   4.  Specific functions assumed within the MG ..................  5
+   5.  Per-Call Requirements .....................................  6
+      5.1.  Resource Reservation .................................  6
+      5.2.  Connection Requirements ..............................  7
+      5.3.  Media Transformations ................................  8
+      5.4.  Signal/Event Processing and Scripting ................  9
+      5.5.  QoS/CoS .............................................. 10
+      5.6.  Test Support ......................................... 11
+      5.7.  Accounting ........................................... 11
+      5.8.  Signalling Control ................................... 11
+   6.  Resource Control .......................................... 12
+      6.1.  Resource Status Management ........................... 12
+      6.2.  Resource Assignment .................................. 13
+   7.  Operational/Management Requirements ....................... 13
+      7.1.  Assurance of Control/Connectivity .................... 13
+      7.2.  Error Control ........................................ 14
+      7.3.  MIB Requirements ..................................... 15
+   8.  General Protocol Requirements ............................. 15
+      8.1.  MG-MGC Association Requirements ...................... 16
+      8.2.  Performance Requirements ............................. 17
+   9.  Transport ................................................. 17
+      9.1.  Assumptions made for underlying network .............. 17
+      9.2.  Transport Requirements ............................... 18
+   10.  Security Requirements .................................... 18
+   11.  Requirements specific to particular bearer types ......... 19
+      11.1.  Media-specific Bearer types ......................... 20
+         11.1.1.  Requirements for TDM PSTN (Circuit) ............ 20
+         11.1.2.  Packet Bearer type ............................. 22
+         11.1.3.  Bearer type requirements for ATM ............... 23
+      11.2.  Application-Specific Requirements ................... 26
+         11.2.1.  Trunking Gateway ............................... 26
+         11.2.2.  Access Gateway ................................. 27
+         11.2.3.  Trunking/Access Gateway with fax ports ......... 27
+         11.2.4.  Trunking/Access Gateway with text telephone .... 28
+         11.2.5.  Network Access Server .......................... 29
+         11.2.6.  Restricted Capability Gateway .................. 30
+         11.2.7.  Multimedia Gateway ............................. 31
+         11.2.8.  Audio Resource Function ........................ 32
+         11.2.9. Multipoint Control Units ........................ 42
+   12.  References ............................................... 43
+   13.  Acknowledgements ......................................... 43
+   14.  Authors' Addresses ....................................... 44
+   15.  Full Copyright Statement ................................. 45
+
+
+
+Greene, et al.               Informational                      [Page 2]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+1.  Introduction
+
+   This document describes requirements to be placed on the Media
+   Gateway Control Protocol. When the word protocol is used on its own
+   in this document it implicitly means the Media Gateway Control
+   Protocol.
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
+   indicate requirement levels for the protocol.
+
+3.  Definitions
+
+   *    Connection
+
+   Under the control of a Media Gateway Controller (MGC), the Media
+   Gateway (MG) realizes connections. In this document, connections are
+   associations of resources hosted by the MG. They typically involve
+   two terminations, but may involve more.
+
+   *    Line or Loop
+
+   An analogue or digital access connection from a user terminal which
+   carries user media content and telephony access signalling (DP, DTMF,
+   BRI, proprietary business set).
+
+   *    Media Gateway (MG) function
+
+   A Media Gateway (MG) function provides the media mapping and/or
+   transcoding functions between potentially dissimilar networks, one of
+   which is presumed to be a packet, frame or cell network.  For
+   example, an MG might terminate switched circuit network (SCN)
+   facilities (trunks, loops), packetize the media stream, if it is not
+   already packetized, and deliver packetized traffic to a packet
+   network.  It would perform these functions in the reverse order for
+   media streams flowing from the packet network to the SCN.
+
+   Media Gateways are not limited to SCN <-> packet/frame/cell
+   functions: A conference bridge with all packet interfaces could be an
+   MG, as well as an (IVR) interactive voice recognition unit, an audio
+   resource function, or a voice recognition system with a cell
+   interface.
+
+
+
+
+
+
+Greene, et al.               Informational                      [Page 3]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   *    Media Gateway unit (MG-unit)
+
+   An MG-unit is a physical entity that contains an MG function and may
+   also contain other functions, e.g. an SG function.
+
+   *    Media Gateway Controller (MGC) function
+
+   A Media Gateway Controller (MGC) function controls a MG.
+
+   *    Media Resource
+
+   Examples of media resources are codecs, announcements, tones, and
+   modems, interactive voice response (IVR) units, bridges, etc.
+
+   *    Signaling Gateway (SG) function
+
+   An SG function receives/sends SCN native signalling at the edge of a
+   data network. For example the SG function may relay, translate or
+   terminate SS7 signaling in an SS7-Internet Gateway. The SG function
+   may also be co-resident with the MG function to process SCN
+   signalling associated with line or trunk terminations controlled by
+   the MG, such as the "D" channel of an ISDN PRI trunk.
+
+   *    Termination
+
+   A termination is a point of entry and/or exit of media flows relative
+   to the MG. When an MG is asked to connect two or more terminations,
+   it understands how the flows entering and leaving each termination
+   are related to each other.
+
+   Terminations are, for instance, DS0's, ATM VCs and RTP ports. Another
+   word for this is bearer point.
+
+   *    Trunk
+
+   An analog or digital connection from a circuit switch which carries
+   user media content and may carry telephony signalling (MF, R2, etc.).
+   Digital trunks may be transported and may appear at the Media Gateway
+   as channels within a framed bit stream, or as an ATM cell stream.
+   Trunks are typically provisioned in groups, each member of which
+   provides equivalent routing and service.
+
+   *    Type of Bearer
+
+   A Type of Bearer definition provides the detailed requirements for
+   its particular application/bearer type. A particular class of Media
+   Gateway, for example, would support a particular set of Bearer types.
+
+
+
+
+Greene, et al.               Informational                      [Page 4]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+4.  Specific functions assumed within the MG
+
+   This section provides an environment for the definition of the
+   general Media Gateway Control Protocol requirements.
+
+   MGs can be architected in many different ways depending where the
+   media conversions and transcoding (if required) are performed, the
+   level of programmability of resources, how conferences are supported,
+   and how associated signalling is treated. The functions assumed to be
+   within the MG must not be biased towards a particular architecture.
+
+   For instance, announcements in a MG could be provided by media
+   resources or by the bearer point resource or termination itself.
+   Further, this difference must not be visible to MGC: The MGC must be
+   able to issue the identical request to two different implementations
+   and achieve the identical functionality.
+
+   Depending on the application of the MG (e.g., trunking, residential),
+   some functions listed below will be more prominent than others, and
+   in some cases, functions may even disappear.
+
+   Although media adaptation is the essence of the MG, it is not
+   necessary for it to be involved every time. An MG may join two
+   terminations/resources of the same type (i.e., the MG behaves as a
+   switch). The required media conversion depends on the media type
+   supported by the resources being joined together.
+
+   In addition to media adaptation function, resources have a number of
+   unique properties, for instance:
+
+   *    certain types of resources have associated signalling
+        capabilities (e.g., PRI signalling, DTMF),
+
+   *    some resources perform maintenance functions (e.g., continuity
+        tests),
+
+   *    the MGC needs to know the state changes of resources (e.g., a
+        trunk group going out of service),
+
+   *    the MG retains some control over the allocation and control of
+        some resources (e.g., resource name space: RTP port numbers).
+
+   Therefore, an MG realizes point-to-point connections and conferences,
+   and supports several resource functions. These functions include
+   media conversion, resource allocation and management, and event
+   notifications.  Handling termination associated signalling is either
+   done using event notifications, or is handled by the signalling
+   backhaul part of a MG-unit (i.e. NOT directly handled by the MG).
+
+
+
+Greene, et al.               Informational                      [Page 5]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   MGs must also support some level of system related functions, such as
+   establishing and maintaining some kind of MG-MGC association. This is
+   essential for MGC redundancy, fail-over and resource sharing.
+
+   Therefore, an MG is assumed to contain these functions:
+
+   *    Reservation and release, of resources
+
+   *    Ability to provide state of resources
+
+   *    Maintenance of resources - It must be possible to make
+        maintenance operations independent of other termination
+        functions, for instance, some maintenance states should not
+        affect the resources associated with that resource . Examples of
+        maintenance functions are loopbacks and continuity tests.
+
+   *    Connection management, including connection state.
+
+   *    Media processing, using media resources: these provide services
+        such as transcoding, conferencing, interactive voice recognition
+        units, audio resource function units. Media resources may or may
+        not be directly part of other resources.
+
+   *    Incoming digit analysis for terminations, interpretation of
+        scripts for terminations
+
+   *    Event detection and signal insertion for per-channel signalling
+
+   *    Ability to configure signalling backhauls (for example, a
+        Sigtran backhaul)
+
+   *    Management of the association between the MGC and MG, or between
+        the MGC and MG resources.
+
+5.  Per-Call Requirements
+
+5.1.  Resource Reservation
+
+   The protocol must:
+
+   a.   Support reservation of bearer terminations and media resources
+        for use by a particular call and support their subsequent
+        release (which may be implicit or explicit).
+
+   b.   Allow release in a single exchange of messages, of all resources
+        associated with a particular set of connectivity and/or
+        associations between a given number terminations.
+
+
+
+
+Greene, et al.               Informational                      [Page 6]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   c.   The MG is not required (or allowed) by the protocol to maintain
+        a sense of future time: a reservation remains in effect until
+        explicitly released by the MGC.
+
+5.2.  Connection Requirements
+
+   The protocol must:
+
+   a.   Support connections involving packet and circuit bearer
+        terminations in any combination, including "hairpin" connections
+        (connections between two circuit connections within the same
+        MG).
+
+   b.   Support connections involving TDM, Analogue, ATM, IP or FR
+        transport in any combination.
+
+   c.   Allow the specification of bearer plane (e.g. Frame Relay, IP,
+        etc.) on a call by call basis.
+
+   d.   Support unidirectional, symmetric bi-directional, and asymmetric
+        bi-directional flows of media.
+
+   e.   Support multiple media types (e.g. audio, text, video, T.120).
+
+   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]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   The protocol must:
+
+   a.   Support detection and recovery from loss of contact due to
+        failure/congestion of communication links or due to MG or MGC
+        failure.
+
+        Note that failover arrangements are one of the mechanisms which
+        could be used to meet this requirement.
+
+   b.   Support detection and recovery from loss of synchronized view of
+        resource and connection states between MGCs and MGs. (e.g.
+        through the use of audits).
+
+   c.   Provide a means for MGC and MG to provide each other with
+        booting and reboot indications, and what the MG's configuration
+        is.
+
+   d.   Permit more than one backup MGC and provide an orderly way for
+        the MG to contact one of its backups.
+
+   e.   Provide for an orderly switchback to the primary MGC after it
+        recovers. How MGCs coordinate resources between themselves is
+        outside the scope of the protocol.
+
+   f.   Provide a mechanism so that when an MGC fails, connections
+        already established can be maintained. The protocol does not
+        have to provide a capability to maintain connections in the
+        process of being connected, but not actually connected when the
+        failure occurs.
+
+   g.   The Protocol must allow the recovery or redistribution of
+        traffic without call loss.
+
+7.2.  Error Control
+
+   The protocol must:
+
+   a.   Allow for the MG to report reasons for abnormal failure of lower
+        layer connections e.g. TDM circuit failure, ATM VCC failure.
+
+   b.   Allow for the MG to report Usage Parameter Control (UPC) events.
+
+   c.   Provide means to ameliorate potential synchronization or focused
+        overload of supervisory/signaling events that can be detrimental
+        to either MG or MGC operation. Power restoration or signaling
+        transport re-establishment are typical sources of potentially
+        detrimental signaling showers from MG to MGC or vice-versa.
+
+
+
+
+Greene, et al.               Informational                     [Page 14]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   d.   Allow the MG to notify the MGC that a termination was terminated
+        and communicate a reason when a terminations is taken out-of-
+        service unilaterally by the MG due to abnormal events.
+
+   e.   Allow the MGC to acknowledge that a termination has been taken
+        out-of-service.
+
+   f.   Allow the MG to request the MGC to release a termination and
+        communicate a reason.
+
+   g.   Allow the MGC to specify, as a result of such a request its
+        decision to take termination down, leave it as is or modify it.
+
+7.3.  MIB Requirements
+
+   The Protocol must define a common MG MIB, which must be extensible,
+   but must:
+
+   a.   Provide information on:
+
+   *    mapping between resources and supporting physical entities.
+
+   *    statistics on quality of service on the control and signalling
+        backhaul interfaces.
+
+   *    statistics required for traffic engineering within the MG.
+
+   b.   The protocol must allow the MG to provide to the MGC all
+        information the MGC needs to provide in its MIB.
+
+   c.   MG MIB must support implementation of H.341 by either the MG,
+        MGC, or both acting together.
+
+8.  General Protocol Requirements
+
+   The protocol must:
+
+   a.   Support multiple operations to be invoked in one message and
+        treated as a single transaction.
+
+   b.   Be both modular and extensible. Not all implementations may wish
+        to support all of the possible extensions for the protocol. This
+        will permit lightweight implementations for specialized tasks
+        where processing resources are constrained. This could be
+        accomplished by defining particular profiles for particular uses
+        of the protocol.
+
+
+
+
+
+Greene, et al.               Informational                     [Page 15]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   c.   Be flexible in allocation of intelligence between MG and MGC.
+        For example, an MGC may want to allow the MG to assign
+        particular MG resources in some implementations, while in
+        others, the MGC may want to be the one to assign MG resources
+        for use.
+
+   d.   Support scalability from very small to very large MGs: The
+        protocol must support MGs with capacities ranging from one to
+        millions of terminations.
+
+   e.   Support scalability from very small to very large MGC span of
+        control: The protocol should support MGCs that control from one
+        MG to a few tens of thousands of MGs.
+
+   f.   Support the needs of a residential gateway that supports one to
+        a few lines, and the needs of a large PSTN gateway supporting
+        tens of thousands of lines. Protocol mechanisms favoring one
+        extreme or the other should be minimized in favor of more
+        general purpose mechanism applicable to a wide range of MGs.
+        Where special purpose mechanisms are proposed to optimize a
+        subset of implementations, such mechanisms should be defined as
+        optional, and should have minimal impact on the rest of the
+        protocol.
+
+   g.   Facilitate MG and MGC version upgrades independently of one
+        another. The protocol must include a version identifier in the
+        initial message exchange.
+
+   h.   Facilitate the discovery of the protocol capabilities of the one
+        entity to the other.
+
+   i.   Specify commands as optional (they can be ignored) or mandatory
+        (the command must be rejected), and within a command, to specify
+        parameters as optional (they can be ignored) or mandatory (the
+        command must be rejected).
+
+8.1.  MG-MGC Association Requirements
+
+   The Protocol must:
+
+   a.   Support the establishment of a control relationship between an
+        MGC and an MG.
+
+   b.   Allow multiple MGCs to send control messages to an MG. Thus, the
+        protocol must allow control messages from multiple signalling
+        addresses to a single MG.
+
+
+
+
+
+Greene, et al.               Informational                     [Page 16]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   c.   Provide a method for the MG to tell an MGC that the MG received
+        a command for a resource that is under the control of a
+        different MGC.
+
+   d.   Support a method for the MG to control the rate of requests it
+        receives from the MGC (e.g. windowing techniques, exponential
+        back-off).
+
+   e.   Support a method for the MG to tell an MGC that it cannot handle
+        any more requests.
+
+8.2.  Performance Requirements
+
+   The protocol must:
+
+   a.   Minimize message exchanges between MG and MGC, for example
+        during boot/reboot, and during continuity tests.
+
+   b.   Support Continuity test constraints which are a maximum of 200ms
+        cross-MGC IAM (IAM is the name given to an SS7 connection setup
+        msg) propagation delay, and a maximum of 200ms from end of
+        dialing to IAM emission.
+
+   c.   Make efficient use of the underlying transport mechanism. For
+        example, protocol PDU sizes vs. transport MTU sizes needs to be
+        considered in designing the protocol.
+
+   d.   Not contain inherent architectural or signaling constraints that
+        would prohibit peak calling rates on the order of 140
+        calls/second on a moderately loaded network.
+
+   e.   Allow for default/provisioned settings so that commands need
+        only contain non-default parameters.
+
+9.  Transport
+
+9.1.  Assumptions made for underlying network
+
+        The protocol must assume that the underlying network:
+
+   a.   May be over large shared networks: proximity assumptions are not
+        allowed.
+
+   b.   Does not assure reliable delivery of messages.
+
+   c.   Does not guarantee ordering of messages: Sequenced delivery of
+        messages associated with the same source of events is not
+        assumed.
+
+
+
+Greene, et al.               Informational                     [Page 17]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   d.   Does not prevent duplicate transmissions.
+
+9.2.  Transport Requirements
+
+   The protocol must:
+
+   a.   Provide the ability to abort delivery of obsolete messages at
+        the sending end if their transmission has not been successfully
+        completed. For example, aborting a command that has been
+        overtaken by events.
+
+   b.   Support priority messages: The protocol shall allow a command
+        precedence to allow priority messages to supercede non-priority
+        messages.
+
+   c.   Support of large fan-out at the MGC.
+
+   d.   Provide a way for one entity to correlate commands and responses
+        with the other entity.
+
+   e.   Provide a reason for any command failure.
+
+   f.   Provide that loss of a packet not stall messages not related to
+        the message(s) contained in the packet lost.
+
+   Note that there may be enough protocol reliability requirements here
+   to warrant a separate reliable transport layer be written apart from
+   the Media Gateway Control Protocol. Also need to compare Megaco
+   reliable transport requirements with similar Sigtran requirements.
+
+10.  Security Requirements
+
+   Security mechanisms may be specified as provided in underlying
+   transport mechanisms, such as IPSEC.  The protocol, or such
+   mechanisms, must:
+
+   a.   Allow for mutual authentication at the start of an MGC-MG
+        association
+
+   b.   Allow for preservation of the of control messages once the
+        association has been established.
+
+   c.   Allow for optional confidentiality protection of control
+        messages.  The mechanism should allow a choice in the algorithm
+        to be used.
+
+   d.   Operate across untrusted domains in a secure fashion.
+
+
+
+
+Greene, et al.               Informational                     [Page 18]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   e.   Support non-repudiation for a customer-located MG talking to a
+        network operator's MGC.
+
+   f.   Define mechanisms to mitigate denial of service attacks
+
+   Note: the protocol document will need to include an extended
+   discussion of security requirements, offering more precision on each
+   threat and giving a complete picture of the defense including non-
+   protocol measures such as configuration.
+
+   g.   It would be desirable for the protocol to be able to pass
+        through commonly-used firewalls.
+
+11.  Requirements specific to particular bearer types
+
+   The bearer types listed in Table 1 can be packaged into different
+   types of MGs. Examples are listed in the following sections.  How
+   they are packaged is outside the scope of the general Media Gateway
+   control protocol. The protocol must support all types of bearer types
+   listed in Table 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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
+        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,
+                   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 speed
+
+
+
+
+Greene, 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.
+
+   -    A length of silence qualified by duration.
+
+   -    An algorithmically generated tone.
+
+   -    A voice variable, specified by type and value.  Given a variable
+        type and value, the IVR/ARF unit would dynamically assemble the
+        phrases required for its playback.
+
+   -    An abstraction that represents a sequence of audio segments.
+        Nesting of these abstractions must also be permitted.
+
+   An example of this abstraction is a sequence of audio segments, the
+   first of which is a recording of the words "The number you have
+   dialed", followed by a Directory Number variable, followed by a
+   recording of the words "is no longer in service".
+
+   -    An abstraction that represents a set of audio segments and which
+        is resolved to a single segment by a qualifier.  Nesting of
+        these abstractions must be permitted.
+
+   For example take a set of audio segments recorded in different
+   languages all of which express the semantic concept "The number you
+   have dialed is no longer in service".  The set is resolved by a
+   language qualifier. If the qualifier is "French", the set resolves to
+   the French version of this announcement.
+
+
+
+
+Greene, et al.               Informational                     [Page 33]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   In the case of a nested abstraction consisting of a set qualified by
+   language at one level and and a set qualified by gender at another
+   level,  it would be possible to specify that an announcement be
+   played in French  and spoken by a female voice.
+
+   e.   Provide two different methods of audio specification:
+
+   -    Direct specification of the audio components to be played by
+        specifying the sequence of segments in the command itself.
+
+   -    Indirect specification of the audio components to be played by
+        reference to a single identifier that resolves to a provisioned
+        sequence of audio segments.
+
+11.2.8.2.  DTMF Collect Module
+
+   The DTMF Collect Module must support all of the requirements in the
+   Play Module in addition to the following requirements:
+
+   a.   Be able to provide the following basic operation:
+
+   -    request an AEG to play an announcement, which may optionally
+        terminated by DTMF, and then collect DTMF
+
+   b.   Be able to specify these event collection characteristics:
+
+   -    The number of attempts to give the user to enter a valid DTMF
+        pattern.
+
+   c.   With respect to digit timers, allow the specification of:
+
+   -    Time allowed to enter the first digit.
+
+   -    Time allowed for user to enter each digit subsequent to the
+        first digit.
+
+   -    Time allowed for user to enter a digit once the maximum expected
+        number of digits has been entered.
+
+   d.   To be able to allow multiple prompt operations DTMF digit
+        collection, voice recording (if supported), and/or speech
+        recognition analysis (if supported) provide the following types
+        of prompts:
+
+   -    Initial Prompt
+
+   -    Reprompt
+
+
+
+
+Greene, et al.               Informational                     [Page 34]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   -    Error prompt
+
+   -    Failure announcement
+
+   -    Success announcement.
+
+   e.   To allow digit pattern matching, allow the specification of:
+
+   -    maximum number of digits to collect.
+
+   -    minimum number of digits to collect.
+
+   -    a digit pattern using a regular expression.
+
+   f.   To allow digit buffer control, allow the specification of:
+
+   -    Ability to clear digit buffer prior to playing initial prompt
+        (default is not to clear buffer).
+
+   -    Default clearing of buffer following playing of un-interruptible
+        announcement segment.
+
+   -    Default clearing of buffer before playing a re-prompt in
+        response to previous invalid input.
+
+   g.   Provide a method to specify DTMF interruptibility on a per audio
+        segment basis.
+
+   h.   Allow the specification of definable key sequences for DTMF
+        digit collection to:
+
+   -    Discard collected digits in progress, replay the prompt, and
+        resume DTMF digit collection.
+
+   -    Discard collected digits in progress and resume DTMF digit
+        collection.
+
+   -    Terminate the current operation and return the terminating key
+        sequence to the MGC.
+
+   i.   Provide a way to ask the ARF MG to support the following
+        definable keys for digit collection and recording. These keys
+        would then be able to be acted upon by the ARF MG:
+
+   -    A key to terminate playing of an announcement in progress.
+
+   -    A set of one or more keys that can be accepted as the first
+        digit to be collected.
+
+
+
+Greene, et al.               Informational                     [Page 35]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   -    A key that signals the end of user input.  The key may or may
+        not be returned to the MGC along with the input already
+        collected.
+
+   -    Keys to stop playing the current announcement and resume playing
+        at the beginning of the first segment of the announcement, last
+        segment of the announcement, previous segment of the
+        announcement, next segment of the announcement, or the current
+        announcement segment.
+
+11.2.8.3.  Record Audio Module
+
+   The Record Module must support all of the requirements in the Play
+   Module as in addition to the following requirements:
+
+   a.   Be able to provide the following basic operation:
+
+   -    request an AEG to play an announcement and then record voice.
+
+   b.   Be able to specify these event collection characteristics:
+
+   -    The number of attempts to give the user to make a recording.
+
+   c.   With respect to recording timers, allow the specification of:
+
+   -    Time to wait for the user to initially speak.
+
+   -    The amount of silence necessary following the last speech
+        segment for the recording to be considered complete.
+
+   -    The maximum allowable length of the recording  (not including
+        pre- and post- speech silence).
+
+   d.   To be able to allow multiple prompt operations for DTMF digit
+        collection (if supported), voice recording (if supported),
+        speech recognition analysis (if supported) and/or speech
+        verification/identification (if supported) and then to provide
+        the following types of prompts:
+
+   -    Initial Prompt
+
+   -    Reprompt
+
+   -    Error prompt
+
+   -    Failure announcement
+
+   -    Success announcement.
+
+
+
+Greene, et al.               Informational                     [Page 36]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   e.   Allow the specification of definable key sequences for digit
+        recording or speech recognition analysis (if supported) to:
+
+   -    Discard recording in progress, replay the prompt, and resume
+        recording.
+
+   -    Discard recording in progress and resume recording.
+
+   -    Terminate the current operation and return the terminating key
+        sequence to the MGC.
+
+   f.   Provide a way to ask the ARF MG to support the following
+        definable keys for recording. These keys would then be able to
+        be acted upon by the ARF MG:
+
+   -    A key to terminate playing of an announcement in progress.
+
+   -    A key that signals the end of user input.  The key may or may
+        not be returned to the MGC along with the input already
+        collected.
+
+   -    Keys to stop playing the current announcement and resume playing
+        at the beginning of the first segment of the announcement, last
+        segment of the announcement, previous segment of the
+        announcement, next segment of the announcement, or the current
+        announcement segment.
+
+   g.   While audio prompts are usually provisioned in IVR/ARF MGs,
+        support changing the provisioned prompts in a voice session
+        rather than a data session.  In particular, with respect to
+        audio management:
+
+   -    A method to replace provisioned audio with audio recorded during
+        a call. The newly recorded audio must be accessible using the
+        identifier of the audio it replaces.
+
+   -    A method to revert from replaced audio to the original
+        provisioned audio.
+
+   -    A method to take audio recorded during a call and store it such
+        that it is accessible to the current call only through its own
+        newly created unique identifier.
+
+   -    A method to take audio recorded during a call and store it such
+        that it is accessible to any subsequent call through its own
+        newly created identifier.
+
+
+
+
+
+Greene, et al.               Informational                     [Page 37]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+11.2.8.4.  Speech Recognition Module
+
+   The speech recognition module can be used for a number of speech
+   recognition applications, such as:
+
+   -    Limited Vocabulary Isolated Speech Recognition (e.g., "yes",
+        "no", the number "four"),
+
+   -    Limited Vocabulary Continuous Speech Feature Recognition (e.g.,
+        the utterance "four hundred twenty-three dollars"),and/or
+
+   -    Continuous Speech Recognition (e.g., unconstrained speech
+        recognition tasks).
+
+   The Speech Recognition Module must support all of the requirements in
+   the Play Module as in addition to the following requirements:
+
+   a.   Be able to provide the following basic operation: request an AEG
+        to play an announcement and then perform speech recognition
+        analysis.
+
+   b.   Be able to specify these event collection characteristics:
+
+   -    The number of attempts to give to perform speech recognition
+        task.
+
+   c.   With respect to speech recognition analysis timers, allow the
+        specification of:
+
+   -    Time to wait for the user to initially speak.
+
+   -    The amount of silence necessary following the last speech
+        segment for the speech recognition analysis segment to be
+        considered complete.
+
+   -    The maximum allowable length of the speech recognition analysis
+        (not including pre- and post- speech silence).
+
+   d.   To be able to allow multiple prompt operations for DTMF digit
+        collection  (if supported), voice recording (if supported),
+        and/or speech recognition analysis and then to provide the
+        following types of prompts:
+
+   -    Initial Prompt
+
+   -    Reprompt
+
+   -    Error prompt
+
+
+
+Greene, et al.               Informational                     [Page 38]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   -    Failure announcement
+
+   -    Success announcement.
+
+   e.   Allow the specification of definable key sequences for digit
+        recording (if supported) or speech recognition analysis to:
+
+   -    Discard in process analysis, replay the prompt, and resume
+        analysis.
+
+   -    Discard recording in progress and resume analysis.
+
+   -    Terminate the current operation and return the terminating key
+        sequence to the MGC.
+
+   f.   Provide a way to ask the ARF MG to support the following
+        definable keys for speech recognition analysis. These keys would
+        then be able to be acted upon by the ARF MG:
+
+   -    A key to terminate playing of an announcement in progress.
+
+   -    A key that signals the end of user input.  The key may or may
+        not be returned to the MGC along with the input already
+        collected.
+
+   -    Keys to stop playing the current announcement and resume playing
+        at the beginning of the first segment of the announcement, last
+        segment of the announcement, previous segment of the
+        announcement, next segment of the announcement, or the current
+        announcement segment.
+
+11.2.8.5.  Speaker Verification/Identification Module
+
+   The speech verification/identification module returns parameters that
+   indicate either the likelihood of the speaker to be the person that
+   they claim to be (verification task) or the likelihood of the speaker
+   being one of the persons contained in a set of previously
+   characterized speakers (identification task).
+
+   The Speaker Verification/Identification Module must support all of
+   the requirements in the Play Module in addition to the following
+   requirements:
+
+   a.   Be able to download parameters, such as speaker templates
+        (verification task) or sets of potential speaker templates
+        (identification task), either prior to the session or in mid-
+        session.
+
+
+
+
+Greene, et al.               Informational                     [Page 39]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   b.   Be able to download application specific software to the ARF
+        either prior to the session or in mid-session.
+
+   c.   Be able to return parameters indicating either the likelihood of
+        the speaker to be the person that they claim to be (verification
+        task) or the likelihood of the speaker being one of the persons
+        contained in a set of previously characterized speakers
+        (identification task).
+
+   d.   Be able to provide the following basic operation: request an AEG
+        to play an announcement and then perform speech
+        verification/identification analysis.
+
+   e.   Be able to specify these event collection characteristics: The
+        number of attempts to give to perform speech
+        verification/identification task.
+
+   f.   With respect to speech verification/identification analysis
+        timers, allow the specification of:
+
+   -    Time to wait for the user to initially speak.
+
+   -    The amount of silence necessary following the last speech
+        segment for the speech verification/identification analysis
+        segment to be considered complete.
+
+   -    The maximum allowable length of the speech
+        verification/identification analysis  (not including pre- and
+        post- speech silence).
+
+   g.   To be able to allow multiple prompt operations for DTMF digit
+        collection (if supported), voice recording, (if supported),
+        speech recognition analysis (if supported) and/or speech
+        verification/identification and provide the following types of
+        prompts:
+
+   -    Initial Prompt
+
+   -    Reprompt
+
+   -    Error prompt
+
+   -    Failure announcement
+
+   -    Success announcement.
+
+
+
+
+
+
+Greene, et al.               Informational                     [Page 40]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   h.   Allow the specification of definable key sequences for digit
+        recording (if supported) or speech recognition (if supported) in
+        the speech verification/identification analysis to:
+
+   -    Discard speech verification/identification in analysis, replay
+        the prompt, and resume analysis.
+
+   -    Discard speech verification/identification analysis in progress
+        and resume analysis.
+
+   -    Terminate the current operation and return the terminating key
+        sequence to the MGC.
+
+   i.   Provide a way to ask the ARF MG to support the following
+        definable keys for speech verification/identification analysis.
+        These keys would then be able to be acted upon by the ARF MG:
+
+   -    A key to terminate playing of an announcement in progress.
+
+   -    A key that signals the end of user input.  The key may or may
+        not be returned to the MGC along with the input already
+        collected.
+
+   -    Keys to stop playing the current announcement and resume speech
+        verification/identification at the beginning of the first
+        segment of the announcement, last segment of the announcement,
+        previous segment of the announcement, next segment of the
+        announcement, or the current announcement segment.
+
+11.2.8.6.  Auditory Feature Extraction/Recognition Module
+
+   The auditory feature extraction/recognition module is engineered to
+   continuously monitor the auditory stream for the appearance of
+   particular auditory signals or speech utterances of interest and to
+   report these events (and optionally a signal feature representation
+   of these events) to network servers or MGCs.
+
+   The Auditory Feature Extraction/Recognition Module must support the
+   following requirements:
+
+   a.   Be able to download application specific software to the ARF
+        either prior to the session or in mid-session.
+
+   b.   Be able to download parameters, such as a representation of the
+        auditory feature to extract/recognize, for prior to the session
+        or in mid-session.
+
+
+
+
+
+Greene, et al.               Informational                     [Page 41]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+   c.   Be able to return parameters indicating the auditory event found
+        or a representation of the feature found (i.e., auditory
+        feature).
+
+11.2.8.7.  Audio Conferencing Module
+
+   The protocol must support:
+
+   a.   a mechanism to create multi-point conferences of audio only and
+        multimedia conferences in the MG.
+
+   b.   audio mixing; mixing multiple audio streams into a new composite
+        audio stream
+
+   c.   audio switching; selection of incoming audio stream to be sent
+        out to all conference participants.
+
+11.2.9.  Multipoint Control Units
+
+   The protocol must support:
+
+   a.   a mechanism to create multi-point conferences of audio only and
+        multimedia conferences in the MG.
+
+   b.   audio mixing; mixing multiple audio streams into a new composite
+        audio stream
+
+   c.   audio switching; selection of incoming audio stream to be sent
+        out to all conference participants.
+
+   d.   video switching; selection of video stream to be sent out to all
+        conference participants
+
+   e.   lecture video mode; a video selection option where on video
+        source is sent out to all conference users
+
+   f.   multi-point of T.120 data conferencing.
+
+   g.   The ability for the MG to function as an H.323 MP, and for the
+        MGC to function as an H.323 MC, connected by this protocol
+        (MEGACOP/H.248).  It should be possible for audio, data, and
+        video MG/MPs to be physically separate while being under the
+        control of a single MGC/H.323 MC.
+
+
+
+
+
+
+
+
+Greene, et al.               Informational                     [Page 42]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+12.  References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  ITU-T Recommendation Q.2630.1, AAL type 2 Signalling Protocol
+        (Capability Set 1), December 1999.
+
+   [3]  ITU-T Recommendation H.341, Line Transmission of Non-Telephone
+        Signals, May 1999.
+
+   [4]  ATM Forum Technical Committee, af-vtoa-0083.001, Voice and
+        Telephony Over ATM to the Desktop Specification, March 1999.
+
+   [5]  ITU-T Recommendation H.323v3, Packet-based Multimedia
+        Communications Systems (includes Annex C - H.323 on ATM),
+        September 1999.
+
+   [6]  ATM Forum Technical Committee, af-saa-0124.000, Gateway for
+        H.323 Media Transport Over ATM, May 1999.
+
+   [7]  ITU-T Recommendation T.140, Protocol for Multimedia Application
+        Text Conversation, February 1998.
+
+   [8]  ITU-T Recommendation V.18, Operational and Interworking
+        Requirements for DCEs Operating in Text Telephone Mode, February
+        1998.
+
+   [9]  ITU-T Recommendation Q.931, Digital Subscriber Signalling System
+        No. 1 (DSS 1) - ISDN User - Network Interface Layer 3
+        Specification for Basic Call Control, May 1998.
+
+14.  Acknowledgements
+
+   The authors would like to acknowledge the many contributors who
+   debated the Media Gateway Control Architecture and Requirements on
+   the IETF Megaco and Sigtran mailing lists. Contributions to this
+   document have also been made through internet-drafts and discussion
+   with members of ETSI Tiphon, ITU-T SG16, TIA TR41.3.4, the ATM Forum,
+   and the Multiservice Switching Forum.
+
+
+
+
+
+
+
+
+
+
+
+Greene, et al.               Informational                     [Page 43]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+15.  Authors' Addresses
+
+   Nancy Greene
+   Nortel Networks
+   P.O. Box 3511 Stn C
+   Ottawa, ON, Canada K1Y 4H7
+
+   Phone: (514) 271-7221
+   EMail: ngreene@nortelnetworks.com
+
+
+   Michael A. Ramalho
+   Cisco Systems
+   1802 Rue de la Port
+   Wall Township, NJ
+
+   Phone: +1.732.449.5762
+   EMail: mramalho@cisco.com
+
+
+   Brian Rosen
+   Marconi
+   1000 FORE Drive, Warrendale, PA 15086
+
+   Phone: (724) 742-6826
+   EMail: brosen@eng.fore.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Greene, et al.               Informational                     [Page 44]
+
+RFC 2805            MG Control Protocol Requirements          April 2000
+
+
+16.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Greene, et al.               Informational                     [Page 45]
+