rfc2705.txt

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

   Large gateways include a large number of endpoints which are often of
   different types.  In some networks, we may often have to set-up
   connections between endpoints that are located within the same
   gateway.  Examples of such connections may be:

   *  Connecting a trunk line to a wiretap device,

   *  Connecting a call to an Interactive Voice-Response unit,

   *  Connecting a call to a Conferencing unit,

   *  Routing a call from on endpoint to another, something often
      described as a "hairpin" connection.

   Local connections are much simpler to establish than network
   connections. In most cases, the connection will be established
   through some local interconnecting device, such as for example a TDM
   bus.

   When two endpoints are managed by the same gateway, it is possible to
   specify the connection in a single command that conveys the name of
   the two endpoints that will be connected.  The command is essentially
   a "Create Connection" command which includes the name of the second
   endpoint in lieu of the "remote session description."

2.1.4.  Names of Call Agents and other entities

   The media gateway control protocol has been designed to allow the
   implementation of redundant Call Agents, for enhanced network
   reliability.  This means that there is no fixed binding between
   entities and hardware platforms or network interfaces.

   Reliability can be improved by the following precautions:

   *  Entities such as endpoints or Call Agents are identified by their
      domain name, not their network addresses. Several addresses can be
      associated with a domain name. If a command or a response cannot
      be forwarded to one of the network addresses, implementations
      should retry the transmission using another address.

   *  Entities may move to another platform. The association between a
      logical name (domain name) and the actual platform are kept in the
      domain name service. Call Agents and Gateways should keep track of
      the time-to-live of the record they read from the DNS. They should
      query the DNS to refresh the information if the time to live has
      expired.



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


   In addition to the indirection provided by the use of domain names
   and the DNS, the concept of "notified entity" is central to
   reliability and fail-over in MGCP. The "notified entity" for an
   endpoint is the Call Agent currently controlling that endpoint. At
   any point in time, an endpoint has one, and only one, "notified
   entity" associated with it, and when the endpoint needs to send a
   command to the Call Agent, it MUST send the command to the current
   "notified entity" for which endpoint(s) the command pertains. Upon
   startup, the "notified entity" MUST be set to a provisioned value.
   Most commands sent by the Call Agent include the ability to
   explicitly name the "notified entity" through the use of a
   "NotifiedEntity" parameter. The "notified entity" will stay the same
   until either a new "NotifiedEntity" parameter is received or the
   endpoint reboots. If the "notified entity" for an endpoint is empty
   or has not been set explicitly, the "notified entity" will then
   default to the source address of the last connection handling command
   or notification request received for the endpoint. Auditing will thus
   not change the "notified entity."

2.1.5.  Digit maps

   The Call Agent can ask the gateway to collect digits dialed by the
   user.  This facility is intended to be used with residential gateways
   to collect the numbers that a user dials; it may also be used with
   trunking gateways and access gateways alike, to collect the access
   codes, credit card numbers and other numbers requested by call
   control services.

   An alternative procedure is for the gateway to notify the Call Agent
   of the dialed digits, as soon as they are dialed. However, such a
   procedure generates a large number of interactions. It is preferable
   to accumulate the dialed numbers in a buffer, and to transmit them in
   a single message.

   The problem with this accumulation approach, however, is that it is
   hard for the gateway to predict how many numbers it needs to
   accumulate before transmission. For example, using the phone on our
   desk, we can dial the following numbers:













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


        _______________________________________________________
       |  0                     |  Local operator             |
       |  00                    |  Long distance operator     |
       |  xxxx                  |  Local extension number     |
       |  8xxxxxxx              |  Local number               |
       |  #xxxxxxx              |  Shortcut to local number at|
       |                        |  other corporate sites      |
       |  *xx                   |  Star services              |
       |  91xxxxxxxxxx          |  Long distance number       |
       |  9011 + up to 15 digits|  International number       |
       |________________________|_____________________________|

   The solution to this problem is to load the gateway with a digit map
   that correspond to the dial plan. This digit map is expressed using a
   syntax derived from the Unix system command, egrep. For example, the
   dial plan described above results in the following digit map:

      (0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)

   The formal syntax of the digit map is described by the DigitMap rule
   in the formal syntax description of the protocol (section 3.4).  A
   Digit-Map, according to this syntax, is defined either by a "string"
   or by a list of strings. Each string in the list is an alternative
   numbering scheme, specified either as a set of digits or timers, or
   as regular expression. A gateway that detects digits, letters or
   timers will:

   1) Add the event parameter code as a token to the end of an internal
      state variable called the "current dial string"

   2) Apply the current dial string to the digit map table, attempting a
      match to each regular expression in the Digit Map in lexical order

   3) If the result is under-qualified (partially matches at least one
      entry in the digit map), do nothing further.

   If the result matches, or is over-qualified (i.e. no further digits
   could possibly produce a match), send the current digit string to the
   Call Agent. A match, in this specification, can be either a "perfect
   match," exactly matching one of the specified alternatives, or an
   impossible match, which occur when the dial string does not match any
   of the alternative. Unexpected timers, for example, can cause
   "impossible matches."  Both perfect matches and impossible matches
   trigger notification of the accumulated digits.

   Digit maps are provided to the gateway by the Call Agent, whenever
   the Call Agent instructs the gateway to listen for digits.




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


2.1.6.  Names of events

   The concept of events and signals is central to MGCP. A Call Agent
   may ask to be notified about certain events occurring in an endpoint,
   e.g.  off-hook events, and a call agent may request certain signals
   to be applied to an endpoint, e.g. dial-tone.

   Events and signals are grouped in packages within which they share
   the same namespace which we will refer to as event names in the
   following.  Packages are groupings of the events and signals
   supported by a particular type of endpoint. For instance, one package
   may support a certain group of events and signals for analog access
   lines, and another package may support another group of events and
   signals for video lines. One or more packages may exist for a given
   endpoint-type.

   Event names are case insensitive and are composed of two logical
   parts, a package name and an event name. Both names are strings of
   letters, hyphens and digits, with the restriction that hyphens shall
   never be the first or last characters in a name. Package or event
   names are not case sensitive - values such as "hu", "Hu", "HU" or
   "hU" should be considered equal.

   Examples of package names are "D" (DTMF), "M" (MF), "T" (Trunk) or
   "L" (Line). Examples of event names can be "hu" (off hook or "hang-
   up" transition), "hf" (flash hook) or "0" (the digit zero).

   In textual representations, the package name, when present, is
   separated from the event name by a slash ("/").  The package name is
   in fact optional. Each endpoint-type has a default package associated
   with it, and if the package name is excluded from the event name, the
   default package name for that endpoint-type is assumed. For example,
   for an analog access line, the following two event names are equal:

   l/dl dial-tone in the line package for an analog access line.

   dl   dial-tone in the line package (default) for an analog access
        line.

   This document defines a basic set of package names and event names.
   Additional package names and event names can be registered with the
   IANA. A package definition shall define the name of the package, and
   the definition of each event belonging to the package. The event
   definition shall include the precise name of the event (i.e., the
   code used in MGCP), a plain text definition of the event, and, when
   appropriate, the precise definition of the corresponding signals, for
   example the exact frequencies of audio signal such as dial tones or
   DTMF tones.



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


   In addition, implementers can gain experience by using experimental
   packages. The names of experimental packages must start with the two
   characters "x-"; the IANA shall not register package names that start
   with these characters.

   Digits, or letters, are supported in many packages, notably "DTMF"
   and "MF". Digits and letters are defined by the rules "Digit" and
   "Letter" in the definition of digit maps. This definition refers to
   the digits (0 to 9), to the asterisk or star ("*") and orthotrope,
   number or pound sign ("#"), and to the letters "A", "B", "C" and "D",
   as well as the timer indication "T". These letters can be combined in
   "digit string" that represent the keys that a user punched on a dial.
   In addition, the letter "X" can be used to represent all digits, and
   the sign "$" can be used in wildcard notations. The need to easily
   express the digit strings has a consequence on the form of event
   names:

     An event name that does not denote a digit should always contain at
     least one character that is neither a digit, nor one of the letters
     A, B, C, D, T or X. (Such names should not contain the special
     signs "*", "#", "/" or "$".)

   A Call Agent may often have to ask a gateway to detect a group of
   events. Two conventions can be used to denote such groups:

   *  The wildcard convention can be used to detect any event belonging
      to a package, or a given event in many packages, or event any
      event in any package supported by the gateway.

   *  The regular expression Range notation can be used to detect a
      range of digits.

   The star sign (*) can be used as a wildcard instead of a package
   name, and the keyword "all" can be used as a wildcard instead of an
   event name:

     A name such as "foo/all" denotes all events in package "foo"
     A name such as "*/bar" denotes the event "bar" in any package
     supported by the gateway
     The names "*" or "*/all" denote all events supported by the
     gate way.

   The call agent can ask a gateway to detect a set of digits or letters
   either by individually describing those letters, or by using the
   "range" notation defined in the syntax of digit strings. For example,
   the call agent can:





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


     Use the letter "x" to denote "any letter or digit."
     Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound
     sign.

   In some cases, Call Agents will request the gateway to generate or
   detect events on connections rather than on the end point itself.
   For example, gateways may be asked to provide a ringback tone on a
   connection.  When an event shall be applied on a connection, the name
   of the connection is added to the name of the event, using an "at"
   sign (@) as a delimiter, as in:

     G/rt@0A3F58

   The wildcard character "*" (star) can be used to denote "all
   connections". When this convention is used, the gateway will generate
   or detect the event on all the connections that are connected to the
   endpoint. An example of this convention could be:

     R/qa@*

   The wildcard character "$" can be used to denote "the current
   connection." It should only be used by the call agent, when the event
   notification request is "encapsulated" within a command creation or
   modification command. When this convention is used, the gateway will
   generate or detect the event on the connection that is currently
   being created or modified. An example of this convention is:

     G/rt@$

   The connection id, or a wildcard replacement, can be used in
   conjunction