An application-level protocol over the N1 interface can be used by the media gateway controller to run the media gateway (as far as call control, connection control, and resource allocation are concerned). Industry approaches vary in the way that resources are represented and calls and connections are modeled. Huitema et al. (1999) describe an early approach. Supplanting it is the approach that has been pursued jointly by ITU-T and the IETF media gateway control (MEGACO) named after the IETF working group [see www.ietf .org/ html.charters/megaco-charter.html]. While bearing resemblance to Huitema’s approach, MEGACO differs in a considerable way as well.
At the heart of the MEGACO approach is its connection model, which consists of two types of objects: a termination and a context. A termination is a source or sink of one or more flows on a media gateway. It has properties (for example, media characteristics, a set of events that can be detected, and a set of signals that can be acted on) describing the nature of the termination. Bearer circuit channels and RTP streams are examples of terminations. In particular, bearer circuits, like other physical resources, are terminations that are persistent as long as they are provisioned on a gateway. In contrast, RTP streams, which are created on demand, are ephemeral terminations. Terminations may come in a wide number of types. The MEGACO approach includes a mechanism to define them in separate packages.
A context is an association of a collection of terminations that defines the directions of flows, if any, between the terminations. Terminations can be added to or removed from a context. A context is created when the first termination is added and is destroyed when the last termination is removed. (Similarly, an ephemeral termination is created when it is added to a context and destroyed when it is removed from the context.) Terminations can also be moved from one context to another. In addition, their properties can be modified within a context. Terminations without any association belong to a special type of context called the null context. Such terminations usually represent physical resources. Adding these terminations to a normal context removes them from the null context; removing them from a normal context returns them to the null context. Figure 1 shows examples of contexts and terminations.
Based on the connection model, the MEGACO approach defines a set of commands for the overall purpose of call and connection control. Among them are the commands for direct manipulation of terminations and contexts, including addition of a termination to a context, removal of a termination from a context, modifying the properties of a termination, and moving a termination from one context to another. Other commands are for auditing of the current state of a termination and the range of the termination properties supported on the media gateway, event notification, and management of the association between the media gateway and the controller. Most of these commands are initiated by the media gateway controller and are sent to the media gateway under its control. The exceptions are the ones for event notification and association management. For notifying the controller of certain events (for example, off-hook and end-of-tone) received by the media gate way, the command for event notification is naturally initiated by the media gateway. In contrast, the command for association management can be initiated by either the media gateway or the controller. When initiated by the media gateway, it is used to notify the controller of the change of the availability status of terminations on the media gateway or the availability status of the gateway itself. When initiated by the controller, it is used to instruct the media gateway to establish an association with a new controller or to take certain terminations out of service.
Another important aspect of the MEGACO approach is its operational model, which recognizes transactions and actions. A transaction consists of one or more actions; an action is composed of a series of commands and is applicable only to a specific context. Invocation of transactions is done by way of messages. To reduce the load of the communications exchange between the media gateway and the controller, a message can hold multiple transac- tions. The transactions in a message are treated independently and can be processed in any order or concurrently. In contrast, commands within a transaction must be processed sequentially. When a command fails, the processing of the rest of the commands stops, unless the failed command is optional. Commands must be responded to upon completion. When a transaction takes a long time to complete, a provisional response should be sent periodically to its originator indicating that the transaction is being processed. Responses are sent also by way of messages. As expected, a message can hold multiple transaction responses, each of which consists of a series of action responses. An action response comprises the responses to the commands pertaining to the action.
An assumption of the MEGACO operational model is that messages are exchanged reliably over the network. For this reason, implementations must ensure that the media gateway and the controller use a reliable transport mechanism [such as Transmission Control Protocol (TCP)] for the relevant exchange. When an unreliable transport [such as User Datagram Protocol (UDP)] is used, the mechanisms that eliminate message duplication and ensure in-sequence transmission of transactions must be used. In addition, it is important to have mechanisms that detect network congestion and respond to it by reducing the traffic. On the other hand, when a reliable transport is used, simple application-level timers may be all that is needed to guard against component failure and undesirable use of the network.
As you have probably noticed the MEGACO technology is somewhat closer to supporting the old-type telephones than true IP telephones, which can establish an end-to-end call without the network even being aware that the call is established. Doing so requires signaling protocols such as SIP and H.323.
No comments:
Post a Comment