MEGACO mode

1) Presentation

Megaco is a NGN protocol used to control media gateways (TDM/IP interworking, analog/IP) by a MGC (media gateway controller). This protocol is described in RFC 3015.

The diagram below describes the different uses of this protocol.

Tulip allows simulating each of these four network elements:

-         MGC: termination seizure simulation on a media gateway and keep alive.

-         Trunking gateway: replies to termination seizures initiated by the MGC, sends notifications, registers the gateway. Interconnects PCM links with IP backbone.

-         Centralized access gateway: replies to termination seizures initiated by the MGC, sends notifications, registers the gateway. Interconnects several subscriber connection units (e.g. PBX) with IP backbone.

-         Access gateway: replies to termination seizures initiated by the MGC, sends notifications, registers the gateway. IP subscriber connection unit.

The scenarii only describe the applicative payload, lower layer are handled by Tulip and the operating system.

2) Transport specifics

- Transport protocol:

Tulip only offers MEGACO transport over UDP. There is no repetition mechanism implemented right now.

The mono socket mode is the only one supported (a single source UDP socket from which transit all packets, towards a single destination socket.

- Packet routing:

In the configuration file, it is possible to list three routing criteria by order of priority. Below, the default list:

        <INTERNAL_ROUTER>

                   <CRITERIA>CONTEXT</CRITERIA>

                   <CRITERIA>TERMINATION</CRITERIA>

                   <CRITERIA>TRANSACTION</CRITERIA>

         </INTERNAL_ROUTER>

CONTEXT: MEGACO context established at the beginning of each communication.

TERMINATION: MEGACO termination linked to the physical TDM timeslot (64 kbits). This data is normally used to route the first message received in a dialog.

TRANSACTION: MEGACO relies on a request/reply/notification mechanism, each couple request/reply is identified by a transaction number (necessary in addition to the context number if UDP is used, because datagrams can arrive in dispersed order.

It is not advised to diverge from default list, unless there is a specific interest to do so.

3) Protocol specific commands

The MEGACO library implements the following commands:

EXPECTED: message reception command, specified in text or hexa mode according to the chosen format in the configuration file. The TAM attribute contains the number of seconds in receiving state before a traffic error is raised.

The text enclosed between beginning and ending anchors may contain on or more jokers, variables, constants, traffic parameters. If a variable is in format ~(variable)~, then Tulip considers the variable as a joker, and tries to position the matched string into the variable.

Example:

         <EXPECTED TAM="20">

!/1 [~IP_MGC~] T=~(tranId)~{C=~(context)~{MF=~TERM~{E=~ValEvent~{al/of{strict=failWrong},al/on{strict=exact},al/fl},SG{alert/ri{SY=TO,DR=60000,pattern=1}}}}}

        </EXPECTED>

TEST_RECEIVE: message reception from test pipeline command (see related section), specified in text or hexa mode according to the chosen format in the configuration file. The TAM attribute contains the number of seconds in receiving state before a traffic error is raised.

The text enclosed between beginning and ending anchors may contain on or more jokers, variables, constants, traffic parameters. If a variable is in format ~(variable)~, then Tulip considers the variable as a joker, and tries to position the matched string into the variable.

Example:

         <TEST_RECEIVE TAM="5">

MEGACO/1 [~IP_TULIP~]:~adrPORT~ T=~tranId~{C=~CALLER_NUM_AGENT~{N=~CALLER_TERM~{OE=~ValEventTerminaisonTdm~{19700103T05180106:dd/std{tl=d~(digit)~}}}}}

         </TEST_RECEIVE>

MESSAGE: command used in responder scenario in order to match an incoming packet. The enclosed content is in text or hexa depending of the format chosen in configuration file, and can contain one or more jokers/constants/variables/traffic parameters. If a variable is in format ~(variable)~, then Tulip considers the variable as a joker, and tries to position the matched string into the variable.

Example:

         <MESSAGE>

!/1 [~IP_MGC~] T=~(tranId)~{C=${A=~(TerminaisonTdm)~{M{O{MO=SR,tdmc/ec=OFF}},E=~(ValEvent)~{al/on{strict=exact},al/of{strict=exact},al/fl}},A=${M{O{MO=IN},L{v=0

c=IN IP4 $

m=audio $ RTP/AVP 8}}}}}

         </MESSAGE>

SEND: sends a MEGACO packet described between the beginning and ending anchors. The text may contain variables, traffic parameters, constants.

Example:

         <SEND>

MEGACO/1 [~IP_TULIP~]:~adrPORT~ P=~tranId~{C=~context~{MF=~TERM~}}

         </SEND>

TEST_SEND: sends a SIP packet described between the beginning and ending anchors into the test pipeline (see corresponding section for more details). The text may contain variables, traffic parameters, constants.

Example:

         <TEST_SEND PIPELINE="INPUT">

!/1 [~IP_MGC~] T=~tranId~{C=${A=~CALLER_TERM~{M{O{MO=SR,tdmc/ec=OFF}},E=~ValEventTerminaisonTdm~{dd/etd{tl=*},al/on{strict=exact},al/of{strict=exact},al/fl}}}}

         </TEST_SEND>

CHANGE_PORT: command which changes the distant UDP port used to send MEGACO packets. Indeed, the protocol allows using different ports during registration phase (used to perform load balancing).

The PORT attribute contains in numeric format the UDP distant port.

3) Example scenarii

Below, some MEGACO example scenarii:

1)     Simple test mode responder /samples/REP MEGACO

This test package provides an illustration of the use of responder scenario in order to simulate a trunking gateway. Indeed, it is not necessary to have a traffic agent to do so, a stateless behaviour may be sufficient to perform basic functions.

Included scenario files:

tulip.xml : configuration file.

mainRepTest.xml : launcher file, starts the responder and test traffic agent. Responder.xml : responder scenario, which matches the incoming packet and replies with another message.

The topology has the type “OTHER only + responder (test mode)”.

2)     Access gateway (CALLER + CALLED) in test mode /samples/MEGACO_2

This test package simulates some traffic coming from an access gateway, and is linked to a MGC which forwards calls towards the same access gateway (caller/called parties are on the same simulated access gateway).

Included scenario files:

tulip.xml : configuration file.

GO_MEGACO.xml : launcher file, starts the responder scenario and traffic agents (CALLER+CALLED). Finishes afterwards.

RESPONDER_MEGACO.xml : responder file, coupled with each traffic agent.

TEST_MGC.xml : scenario which describes the MGC behaviour in test mode.

ABODR.xml : scenario describing the access gateway behaviour on calling party side.

ABODE.xml : scenario describing the access gateway behaviour on called party side.

The topology has the type “CALLER+CALLED+MGC + responder (test mode)”.

3)     Access gateway (CALLER + CALLED + MGC) in UDP mode /samples/MEGACO_UDP

This package provides the simulation of test subscribers connected to an access gateway (CALLER+CALLED). The access gateway communicates with a distant MGC in MEGACO/UDP.

Scenario files included:

tulip_client.xml : client configuration file (access gateway).

tulip_server.xml : server configuration file (MGC).

GO_MEGACO.xml : access gateway launcher file, starts the responder scenario and traffic agents (CALLER+CALLED). Finishes afterwards.

GO_MGC.xml : MGC launcher file, starts all traffic agents (MGC), finishes afterwards.

RESPONDER_MEGACO.xml : responder file, coupled with each traffic agent.

SERVER_MEGACO.xml : scenario describing the behaviour of MGC in UDP mode.

ABODR.xml : scenario describing the access gateway behaviour on calling party side.

ABODE.xml : scenario describing the access gateway behaviour on called party side.