rfc2885.txt

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

5. CONVENTIONS

   In this recommendation, "shall" refers to a mandatory requirement,
   while "should" refers to a suggested but optional feature or
   procedure. The term "may" refers to an optional course of action
   without expressing a preference.

6. CONNECTION MODEL

   The connection model for the protocol describes the logical entities,
   or objects, within the Media Gateway that can be controlled by the
   Media Gateway Controller.  The main abstractions used in the
   connection model are Terminations and Contexts.

   A Termination sources and/or sinks one or more streams.  In a
   multimedia conference, a Termination can be multimedia and sources or
   sinks multiple media streams.  The media stream parameters, as well
   as modem, and bearer parameters are encapsulated within the
   Termination.

   A Context is an association between a collection of Terminations.
   There is a special type of Context, the null Context, which contains
   all Terminations that are not associated to any other Termination.

   For instance, in a decomposed access gateway, all idle lines are
   represented by Terminations in the null Context.














Cuervo, et al.              Standards Track                    [Page 11]

RFC 2885                    Megaco Protocol                  August 2000


          +------------------------------------------------------+
          |Media Gateway                                         |
          | +-------------------------------------------------+  |
          | |Context                          +-------------+ |  |
          | |                                 | Termination | |  |
          | |                                 |-------------| |  |
          | |  +-------------+             +->| SCN Bearer  |<---+->
          | |  | Termination |   +-----+   |  |   Channel   | |  |
          | |  |-------------|   |     |---+  +-------------+ |  |
        <-+--->| RTP Stream  |---|  *  |                      |  |
          | |  |             |   |     |---+  +-------------+ |  |
          | |  +-------------+   +-----+   |  | Termination | |  |
          | |                              |  |-------------| |  |
          | |                              +->| SCN Bearer  |<---+->
          | |                                 |   Channel   | |  |
          | |                                 +-------------+ |  |
          | +-------------------------------------------------+  |
          |                                                      |
          |                                                      |
          |                    +------------------------------+  |
          |                    |Context                       |  |
          |  +-------------+   |              +-------------+ |  |
          |  | Termination |   | +-----+      | Termination | |  |
          |  |-------------|   | |     |      |-------------| |  |
        <-+->| SCN Bearer  |   | |  *  |------| SCN Bearer  |<---+->
          |  |   Channel   |   | |     |      |   Channel   | |  |
          |  +-------------+   | +-----+      +-------------+ |  |
          |                    +------------------------------+  |
          |                                                      |
          |                                                      |
          | +-------------------------------------------------+  |
          | |Context                                          |  |
          | |  +-------------+                +-------------+ |  |
          | |  | Termination |   +-----+      | Termination | |  |
          | |  |-------------|   |     |      |-------------| |  |
        <-+--->| SCN Bearer  |---|  *  |------| SCN Bearer  |<---+->
          | |  |   Channel   |   |     |      |   Channel   | |  |
          | |  +-------------+   +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          | ___________________________________________________  |
          +------------------------------------------------------+

                Figure 1: Example of H.248 Connection Model








Cuervo, et al.              Standards Track                    [Page 12]

RFC 2885                    Megaco Protocol                  August 2000


   Figure 1 is a graphical depiction of these concepts.  The diagram of
   Figure 1 gives several examples and is not meant to be an all-
   inclusive illustration.  The asterisk box in each of the Contexts
   represents the logical association of Terminations implied by the
   Context.

   The example below shows an example of one way to accomplish a call-
   waiting scenario in a decomposed access gateway, illustrating the
   relocation of a Termination between Contexts.   Terminations T1 and
   T2 belong to Context C1 in a two-way audio call.  A second audio call
   is waiting for T1 from Termination T3.  T3 is alone in Context C2.
   T1 accepts the call from T3, placing T2 on hold.  This action results
   in T1 moving into Context C2, as shown below.

          +------------------------------------------------------+
          |Media Gateway                                         |
          | +-------------------------------------------------+  |
          | |Context C1                                       |  |
          | |  +-------------+                +-------------+ |  |
          | |  | Term. T2    |   +-----+      | Term. T1    | |  |
          | |  |-------------|   |     |      |-------------| |  |
        <-+--->| RTP Stream  |---|  *  |------| SCN Bearer  |<---+->
          | |  |             |   |     |      |   Channel   | |  |
          | |  +-------------+   +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          |                                                      |
          | +-------------------------------------------------+  |
          | |Context C2                                       |  |
          | |                                 +-------------+ |  |
          | |                    +-----+      | Term. T3    | |  |
          | |                    |     |      |-------------| |  |
          | |                    |  *  |------| SCN Bearer  |<---+->
          | |                    |     |      |   Channel   | |  |
          | |                    +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          +------------------------------------------------------+

      Figure 2: Example Call Waiting Scenario / Alerting Applied to T1













Cuervo, et al.              Standards Track                    [Page 13]

RFC 2885                    Megaco Protocol                  August 2000


          +------------------------------------------------------+
          |Media Gateway                                         |
          | +-------------------------------------------------+  |
          | |Context C1                                       |  |
          | |  +-------------+                                |  |
          | |  | Term. T2    |   +-----+                      |  |
          | |  |-------------|   |     |                      |  |
        <-+--->| RTP Stream  |---|  *  |                      |  |
          | |  |             |   |     |                      |  |
          | |  +-------------+   +-----+                      |  |
          | +-------------------------------------------------+  |
          |                                                      |
          | +-------------------------------------------------+  |
          | |Context C2                                       |  |
          | |  +-------------+                +-------------+ |  |
          | |  | Term. T1    |   +-----+      | Term. T3    | |  |
          | |  |-------------|   |     |      |-------------| |  |
        <-+--->| SCN Bearer  |---|  *  |------| SCN Bearer  |<---+->
          | |  |   Channel   |   |     |      |   Channel   | |  |
          | |  +-------------+   +-----+      +-------------+ |  |
          | +-------------------------------------------------+  |
          +------------------------------------------------------+

           Figure 3. Example Call Waiting Scenario / Answer by T1

6.1 Contexts

   A Context is an association between a number of Terminations.  The
   Context describes the topology (who hears/sees whom) and the media
   mixing and/or switching parameters if more than two Terminations are
   involved in the association.

   There is a special Context called the null Context. It contains
   Terminations that are not associated to any other Termination.
   Terminations in the null Context can have their parameters examined
   or modified, and may have events detected on them.

   In general, an Add command is used to add Terminations to Contexts.
   If the MGC does not specify an existing Context to which the
   Termination is to be added, the MG creates a new Context.  A
   Termination may be removed from a Context with a Subtract command,
   and a Termination may be moved from one Context to another with a
   Move command. A Termination SHALL exist in only one Context at a
   time.







Cuervo, et al.              Standards Track                    [Page 14]

RFC 2885                    Megaco Protocol                  August 2000


   The maximum number of Terminations in a Context is a MG property.
   Media gateways that offer only point-to-point connectivity might
   allow at most two Terminations per Context. Media gateways that
   support multipoint conferences might allow three or more terminations
   per Context.

6.1.1 Context Attributes and Descriptors

   The attributes of Contexts are:

    .  ContextID.

    .  The topology (who hears/sees whom).  The topology of a Context
       describes the flow of media between the Terminations within a
       Context.  In contrast, the mode of a Termination (send/receive/_)
       describes the flow of the media at the ingress/egress of the
       media gateway.

    .  The priority is used for a context in order to provide the MG
       with information about a certain precedence handling for a
       context. The MGC can also use the priority to control
       autonomously the traffic precedence in the MG in a smooth way in
       certain situations (e.g.  restart), when a lot of contexts must
       be handled simultaneously.

    .  An indicator for an emergency call is also provided to allow a
       preference handling in the MG.

6.1.2 Creating, Deleting and Modifying Contexts

   The protocol can be used to (implicitly) create Contexts and modify
   the parameter values of existing Contexts.  The protocol has commands
   to add Terminations to Contexts, subtract them from Contexts, and to
   move Terminations between Contexts.  Contexts are deleted implicitly
   when the last remaining Termination is subtracted or moved out.

6.2 Terminations

   A Termination is a logical entity on a MG that sources and/or sinks
   media and/or control streams.  A Termination is described by a number
   of characterizing Properties, which are grouped in a set of
   Descriptors that are included in commands. Terminations have unique
   identities (TerminationIDs), assigned by the MG at the time of their
   creation.

   Terminations representing physical entities have a semi-permanent
   existence.  For example, a Termination representing a TDM channel
   might exist for as long as it is provisioned in the gateway.



Cuervo, et al.              Standards Track                    [Page 15]

RFC 2885                    Megaco Protocol                  August 2000


   Terminations representing ephemeral information flows, such as RTP
   flows, would usually exist only for the duration of their use.

   Ephemeral Terminations are created by means of an Add command.  They
   are destroyed by means of a Subtract command.  In contrast, when a
   physical Termination is Added to or Subtracted from a Context, it is
   taken from or to the null Context, respectively.

   Terminations may have signals applied to them.  Signals are MG
   generated media streams such as tones and announcements as well as
   line signals such as hookswitch.  Terminations may be programmed to
   detect Events, the occurrence of which can trigger notification
   messages to the MGC, or action by the MG.  Statistics may be
   accumulated on a Termination.  Statistics are reported to the MGC
   upon request (by means of the AuditValue command, see section 7.2.5)
   and when the Termination is taken out of the call it is in.

   Multimedia gateways may process multiplexed media streams.  For