rfc2705.txt

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

                                         +-------
                        +---------------+|
              (line) ===|analog endpoint| -------- Connections
                        +---------------+|
                                         +-------

   Media gateways should be able to establish several connections
   between the endpoint and the packet networks, or between the endpoint
   and other endpoints in the same gateway.  The audio signals
   originating from these connections shall be mixed according to the
   connection "mode", as specified later in this document.  The precise
   number of connections that an endpoint support is a characteristic of
   the gateway, and may in fact vary according with the allocation of
   resource within the gateway.  A typical gateway should however be
   able to support two or three connections per endpoint, in order to
   provide services such as "call waiting" or "three ways calling".

2.1.1.3.  Annoucement server access point

   An announcement server endpoint provides acces to an announcement
   service. Under requests from the call agent, the announcement server
   will "play" a specified announcement.  The requests from the call
   agent will follow the event signalling and reporting procedures
   defined in MGCP.

             +----------------------+
             | Announcement endpoint| -------- Connection
             +----------------------+

   A given announcement endpoint is not supposed to support more than
   one connection at a time. If several connections were established to
   the same endpoint, then the same announcements would be played
   simultaneously over all the connections.

   Connections to an announcement server are typically oneway, or "half
   duplex" -- the announcement server is not expected to listen the
   audio signals from the connection.

2.1.1.4.  Interactive Voice Response access point

   An Interactive Voice Response (IVR) endpoint provides acces to an IVR
   service. Under requests from the call agent, the IVR server will
   "play" announcements and tones, and will "listen" to responses from
   the user.  The requests from the call agent will follow the event
   signalling and reporting procedures defined in MGCP.






Arango, et al.               Informational                     [Page 12]

RFC 2705         Media Gateway Control Protocol (MGCP)      October 1999


                      +-------------+
                      | IVR endpoint| -------- Connection
                      +-------------+

   A given IVR endpoint is not supposed to support more than one
   connection at a time. If several connections were established to the
   same endpoint, then the same tones and announcements would be played
   simultaneously over all the connections.

2.1.1.5.  Conference bridge access point

   A conference bridge endpoint is used to provide access to a specific
   conference.

                                         +-------
             +--------------------------+|
             |Conference bridge endpoint| -------- Connections
             +--------------------------+|
                                         +-------

   Media gateways should be able to establish several connections
   between the endpoint and the packet networks, or between the endpoint
   and other endpoints in the same gateway.  The signals originating
   from these connections shall be mixed according to the connection
   "mode", as specified later in this document. The precise number of
   connections that an endpoint support is a characteristic of the
   gateway, and may in fact vary according with the allocation of
   resource within the gateway.

2.1.1.6.  Packet relay

   A packet relay endpoint is a specific form of conference bridge, that
   typically only supports two connections.  Packets relays can be found
   in firewalls between a protected and an open network, or in
   transcoding servers used to provide interoperation between
   incompatible gateways, for example gateways that do not support
   compatible compression algorithms, or gateways that operate over
   different transmission networks such as IP and ATM.

                                          +-------
                  +---------------------+ |
                  |Packet relay endpoint|  2 connections
                  +---------------------+ |
                                          +-------







Arango, et al.               Informational                     [Page 13]

RFC 2705         Media Gateway Control Protocol (MGCP)      October 1999


2.1.1.7.  Wiretap access point

   A wiretap access point provides access to a wiretap service,
   providing either a recording or a life playback of a connection.

                  +-----------------+
                  | Wiretap endpoint| -------- Connection
                  +-----------------+

   A given wiretap endpoint is not supposed to support more than one
   connection at a time. If several connections were established to the
   same endpoint, then the recording or playback would mix the audio
   signals received on this connections.

   Connections to an wiretap endpoint are typically oneway, or "half
   duplex" -- the wiretap server is not expected to signal its presence
   in a call.

2.1.1.8.  ATM "trunk side" interface.

   ATM "trunk side" endpoints are typically found when one or several
   ATM permanent virtual circuits are used as a replacement for the
   classic "TDM" trunks linking switches.  When ATM/AAL2 is used,
   several trunks or channels are multiplexed on a single virtual
   circuit; each of these trunks correspond to a single endpoint.

                                         +-------
                     +------------------+|
         (channel) = |ATM trunk endpoint| -------- Connections
                     +------------------+|
                                         +-------

   Media gateways should be able to establish several connections
   between the endpoint and the packet networks, or between the endpoint
   and other endpoints in the same gateway.  The signals originating
   from these connections shall be mixed according to the connection
   "mode", as specified later in this document.  The precise number of
   connections that an endpoint support is a characteristic of the
   gateway, and may in fact vary according with the allocation of
   resource within the gateway.











Arango, et al.               Informational                     [Page 14]

RFC 2705         Media Gateway Control Protocol (MGCP)      October 1999


2.1.2.  Endpoint identifiers

   Endpoints identifiers have two components that both are case
   insensitive:

   *  the domain name of the gateway that is managing the endpoint,

   *  a local name within that gateway,

   The syntax of the local name depends on the type of endpoint being
   named. However, the local name for each of these types is naturally
   hierarchical, beginning with a term which identifies the physical
   gateway containing the given endpoint and ending in a term which
   specifies the individual endpoint concerned. With this in mind,  the
   following rules for construction and interpretation of the Entity
   Name field for these entity types MUST be supported:

   1) The individual terms of the naming path MUST be separated by a
      single slash ("/", ASCII 2F hex).

   2) The individual terms are character strings composed of letters,
      digits or other printable characters, with the exception of
      characters used as delimitors ("/", "@"), characters used for
      wildcarding ("*", "$") and white spaces.

   3) Wild-carding is represented either by an asterisk ("*") or a
      dollar sign ("$") for the terms of the naming path which are to be
      wild-carded. Thus, if the full naming path looks like

             term1/term2/term3

      then the Entity Name field looks like this depending on which
      terms are wild-carded:

             */term2/term3 if term1 is wild-carded
             term1/*/term3 if term2 is wild-carded
             term1/term2/* if term3 is wild-carded
             term1/*/* if term2 and term3 are wild-carded,
              etc.

      In each of these examples a dollar sign could have appeared
      instead of an asterisk.









Arango, et al.               Informational                     [Page 15]

RFC 2705         Media Gateway Control Protocol (MGCP)      October 1999


   4) A term represented by an asterisk is to be interpreted as: "use
      ALL values of this term known within the scope of the Media
      Gateway".  A term represented by a dollar sign is to be
      interpreted as: "use ANY ONE value of this term known within the
      scope of the Media Gateway".  The description of a specific
      command may add further criteria for selection within the general
      rules given here.

   If the Media Gateway controls multiple physical gateways, the first
   term of the naming MUST identify the physical gateway containing the
   desired entity.  If the Media Gateway controls only a single physical
   gateway, the first term of the naming string MAY identify that
   physical gateway, depending on local practice.  A local name that is
   composed of only a wildcard character refers to either all (*) or any
   ($) endpoints within the media gateway.

   In the case of trunking gateways, endpoints are trunk circuits
   linking a gateway to a telephone switch. These circuits are typically
   grouped into a digital multiplex, that is connected to the gateway by
   a physical interface. Such circuits are named in three contexts:

   *  In the ISUP protocol, trunks are grouped into trunk groups,
      identified by the SS7 point codes of the switches that the group
      connects. Circuits within a trunk group are identified by a
      circuit number (CIC in ISUP).

   *  In the gateway configuration files, physical interfaces are
      typically identified by the name of the interface, an arbitrary
      text string. When the interface multiplexes several circuits,
      individual circuits are typically identified by a circuit number.

   *  In MGCP, the endpoints are identified by an endpoint identifier.

   The Call Agents use configuration databases to map ranges of circuit
   numbers within an ISUP trunk group to corresponding ranges of
   circuits in a multiplex connected to a gateway through a physical
   interface. The gateway will be identified, in MGCP, by a domain name.
   The local name will be structured to encode both the name of the
   physical interface, for example X35V3+A4, and the circuit number
   within the multiplex connected to the interface, for example 13. The
   circuit number will be separated from the name of the interface by a
   fraction bar, as in:

        X35V3+A4/13







Arango, et al.               Informational                     [Page 16]

RFC 2705         Media Gateway Control Protocol (MGCP)      October 1999


   Other types of endpoints will use different conventions. For example,
   in gateways were physical interfaces by construction only control one
   circuit, the circuit number will be omitted. The exact syntax of such
   names should be specified in the corresponding server specification.

2.1.3.  Calls and connections

   Connections are created on the call agent on each endpoint that will
   be involved in the "call."  In the classic example of a connection
   between two "DS0" endpoints (EP1 and EP2), the call agents
   controlling the end points will establish two connections (C1 and
   C2):

                 +---+                            +---+
   (channel1) ===|EP1|--(C1)--...        ...(C2)--|EP2|===(channel2)
                 +---+                            +---+

   Each connection will be designated locally by a connection
   identifier, and will be characterized by connection attributes.

   When the two endpoints are located on gateways that are managed by
   the same call agent, the creation is done via the three following
   steps:

   1) The call agent asks the first gateway to "create a connection" on
      the first endpoint.  The gateway allocates resources to that
      connection, and respond to the command by providing a "session
      description."  The session description contains the information