⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc3015.txt

📁 最新的RFC
💻 TXT
📖 第 1 页 / 共 5 页
字号:
5. CONVENTIONS   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in RFC2119.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.Cuervo, et al.              Standards Track                    [Page 11]RFC 3015              Megaco Protocol Version 1.0          November 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 ModelCuervo, et al.              Standards Track                    [Page 12]RFC 3015              Megaco Protocol Version 1.0          November 2000   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.   Figure 1 above 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 T1Cuervo, et al.              Standards Track                    [Page 13]RFC 3015              Megaco Protocol Version 1.0          November 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 T16.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 3015              Megaco Protocol Version 1.0          November 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.Cuervo, et al.              Standards Track                    [Page 15]RFC 3015              Megaco Protocol Version 1.0          November 2000   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.   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   example, Recommendation H.221 describes a frame structure for   multiple media streams multiplexed on a number of digital 64 kbit/s   channels.  Such a case is handled in the connection model in the   following way.  For every bearer channel that carries part of the   multiplexed streams, there is a Termination.  The Terminations that   source/sink the digital channels are connected to a separate   Termination called the multiplexing Termination. This Termination   describes the multiplex used (e.g. how the H.221 frames are carried   over the digital channels used).  The MuxDescriptor is used to this   end.  If multiple media are carried, this Termination contains   multiple StreamDescriptors. The media streams can be associated with   streams sourced/sunk by other Terminations in the Context.   Terminations may be created which represent multiplexed bearers, such   as an ATM AAL Type 2 bearer.  When a new multiplexed bearer is to be   created, an ephemeral termination is created in a context established   for this purpose.  When the termination is subtracted, the   multiplexed bearer is destroyed.

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -