Figure 6-10 MEGACO contexts and terminations, showing possible Move command in Visual Studio .NET

Creating Data Matrix in Visual Studio .NET Figure 6-10 MEGACO contexts and terminations, showing possible Move command

Downloaded from Digital Engineering Library @ McGraw-Hill (wwwdigitalengineeringlibrarycom) Copyright 2004 The McGraw-Hill Companies All rights reserved Any use is subject to the Terms of Use as given at the website

6

indicates the flow of media between terminations (which terminations may send media to others or receive media from others) Also, the priority attribute indicates the precedence applied to a context when an MGC must handle many contexts simultaneously, and an emergency attribute is used to give preferential handling to emergency calls A context is identified by a ContextID, which is assigned by the MG and is unique within a single MG As is the case for terminations, MECAGO enables wildcarding when referring to contexts, such that the all (*) and choose ($) wildcards may be used The all wildcard may be used by an MGC to refer to every context on a gateway The choose wildcard ($) is used when an MGC requires the MG to create a new context A special context is also available, known as the null context This context contains all terminations that do not exist in any other context Idle terminations normally exist in the null context The ContextID for the null context is simply - Transactions MEGACO transactions involve the passing of commands and the responses to those commands Commands are directed towards terminations within contexts In other words, every command specifies a ContextID and one or more TerminationIDs to which the command applies This is the case even for a command that requires some action by an idle termination that does not exist in any specific context In such a case, the null context is applicable Commands between an MGC and an MG are grouped together in a transaction structure where a set of commands related to one context may be followed by a set of commands related to another context The grouped commands are sent together in a single TransactionRequest This can be represented as

TransactionRequest (TransactionID { ContextID1 {Command, Command, Command}, ContextID2 {Command, Command, Command}, ContextID3 {Command, Command, Command} } )

A TransactionRequest does not need to contain commands for more than one context or even contain more than one command A TransactionRequest containing just a single command for a single context is perfectly valid Upon receipt of a TransactionRequest, the recipient executes the enclosed commands The commands are executed sequentially in the order specified in the TransactionRequest Upon completed execution of the commands, a TransactionReply is issued This has a similar structure to the

Downloaded from Digital Engineering Library @ McGraw-Hill (wwwdigitalengineeringlibrarycom) Copyright 2004 The McGraw-Hill Companies All rights reserved Any use is subject to the Terms of Use as given at the website

TransactionRequest in that it contains a number of responses for a number of contexts A TransactionReply may be represented as

TransactionReply (TransactionID ContextID1 {Response, ContextID2 {Response, ContextID3 {Response, { Response, Response}, Response, Response}, Response, Response} } )

As mentioned, commands within a transaction are executed in sequence If a given command in the transaction happens to fail, then the subsequent commands in the transaction are not processed One exception is when a transaction contains one or more optional commands If an optional command fails, then the processing of the remaining commands will continue Optional commands in a transaction are indicated by inserting the string O- immediately prior to the command name If the recipient of a TransactionRequest might take some time to execute the request, the recipient can return an interim reply so that the sender of the request does not assume that it has been lost This interim reply is simply an indication that the TransactionRequest has been received and is being handled The term applied to this response is TransactionPending It simply returns the TransactionID received and no parameters The TransactionID is a 32-bit integer

TransactionPending (TransactionID { })

Messages Not only is it possible to combine multiple commands within a single transaction, but it is also possible to concatenate multiple transactions within a message In ABNF syntax, a message begins with the word MEGACO followed by a slash, the protocol version number (1), a message ID (mId), and finally the message body The mId can be the domain name or IP address (and optionally the port) of the entity transmitting the message As an alternative, it can be the MTP point code and network indicator of the entity issuing the message The following example combines the concept of a message, transactions, and commands and it shows the text format of a message:

MEGACO/1 [111111222222]:34567 Transaction = 12345 { Context = 1111 { Add = A5555, Add = A6666 } Context = $ { Add = A7777 } } Downloaded from Digital Engineering Library @ McGraw-Hill (wwwdigitalengineeringlibrarycom) Copyright 2004 The McGraw-Hill Companies All rights reserved Any use is subject to the Terms of Use as given at the website