 |
|
MEGACO
1) Présentation
Le schéma ci-dessous décrit les différentes utilisations du protocole.
Tulip permet de simuler chacun de ces quatre éléments réseaux : - MGC : Simulation de prise de terminaisons sur une media gateway, et keepalive. - Trunking gateway : réponse aux prises de terminaisons initiées par le MGC, et enregistrement de la media gateway. - Centralized access gateway : réponse aux prises de terminaisons initiées par le MGC, et enregistrement de la media gateway. - Access gateway : prise de terminaison et envoi de la numérotation vers le MGC.
Les séquentiels décrivent uniquement la payload applicative, les couches inférieures sont prises en charge par TULIP et le système d’exploitation.
2) Spécificités transport
Tulip ne gère actuellement que le transport du MEGACO sur l’UDP. Il n’y a actuellement pas de mécanisme de répétition des datagrammes non acquittés. Le mode mono socket est le seul supporté (une socket UDP source par laquelle transitent tous les paquets UDP, vers une seule socket destination.
3) Routage des paquets
Dans le fichier de configuration, il est possible d’ordonner trois critères de routage par ordre de précédence. Ci-dessous, l’ordonnancement par défaut.
<INTERNAL_ROUTER> <CRITERIA>CONTEXT</CRITERIA> <CRITERIA>TERMINATION</CRITERIA> <CRITERIA>TRANSACTION</CRITERIA> </INTERNAL_ROUTER>
CONTEXT : contexte MEGACO établi au début de chaque communication. TERMINATION : terminaison MEGACO liée à l’adresse physique de la voie de parole TDM (intervalle de temps 64 kbits). Cette donnée permet de router le message en tout début de dialogue. TRANSACTION : MEGACO repose sur un mécanisme requête/réponses/notifications, chaque couple requête/réponse est identifié par un numéro de transaction (nécessaire en plus du numéro de contexte si UDP est utilisé, car les datagrammes peuvent arriver en ordre dispersé.
Il est plutôt déconseillé de diverger de l’ordre par défaut, sauf pour une utilisation très particulière du simulateur.
4) Commandes spécifiques protocole
La libraire MEGACO implémente les commandes suivantes :
EXPECTED: commande d’attente de message, spécifié en mode texte ou hexa selon le format choisi dans le fichier de configuration. L’attribut TAM (tempo d’attente message) contient le nombre de secondes d’attente avant qu’une erreur soit émise. Le texte contenu entre les balises de début et fin peut contenir un ou plusieurs joker, variables, constantes, paramètres de trafic. Si une variable est présentée sous le format ~(variable)~, alors tulip considère la variable comme un joker, et en cas de correspondance, la variable prend pour valeur le bloc qu’elle a remplacé.
Exemple : <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: commande d’attente de message venant du pipeline de test (voir section portant sur le mode test), spécifié en mode texte ou hexa selon le format choisi dans le fichier de configuration. L’attribut TAM (tempo d’attente message) contient le nombre de secondes d’attente avant qu’une erreur soit émise. Le texte contenu entre les balises de début et fin peut contenir un ou plusieurs joker, variables, constantes, paramètres de trafic. Si une variable est présentée sous le format ~(variable)~, alors tulip considère la variable comme un joker, et en cas de correspondance, la variable prend pour valeur le bloc qu’elle a remplacé.
Exemple : <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: commande utilisée dans le sequentiel répondeur pour matcher un paquet arrivant depuis le pipeline standard. Le texte spécifié en mode texte ou hexa selon le format choisi dans le fichier de configuration. Le texte contenu entre les balises de début et fin peut contenir un ou plusieurs joker, variables, constantes, paramètres de trafic. Si une variable est présentée sous le format ~(variable)~, alors tulip considère la variable comme un joker, et en cas de correspondance, la variable prend pour valeur le bloc qu’elle a remplacé.
Exemple : <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: envoi du paquet MEGACO décrit entre la balise de début et celle de fin. Le texte peut contenir des variables, paramètres de trafic, constantes.
Exemple : <SEND> MEGACO/1 [~IP_TULIP~]:~adrPORT~ P=~tranId~{C=~context~{MF=~TERM~}} </SEND>
TEST_SEND: envoi du paquet MEGACO décrit entre la balise de début et celle de fin vers le pipeline de test (voir section dédiée au test). Le texte peut contenir des variables, paramètres de trafic, constantes.
Exemple : <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 : commande permettant de changer le port UDP distant utilisé pour l’envoi de paquets MEGACO. En effet, le protocole autorise le changement de ce port en phase d’enregistrement (pour le partage de charge). L’attribut PORT contient au format numérique le port distant UDP choisi.
5) Scénarii exemples
Ci-dessous, quelques scénarii exemples MEGACO :
1) Répondeur simple en mode test /samples/REP MEGACO
Ce package de test fournit une illustration de l’utilisation d’un répondeur pour simuler une trunking gateway. En effet, il n’est pas nécessaire d’avoir un trafic agent pour ce faire, le fonctionnement en mode « stateless » suffit à assurer les fonctions de base.
Fichiers scenario inclus : tulip.xml : fichier de configuration. mainRepTest.xml : fichier lanceur, lance le répondeur et le traffic agent de test. responder.xml : séquentiel répondeur, qui matche le paquet et en envoie un autre en réponse.
La topologie est de type « OTHER only + responder (mode test)».
2) Access gateway (CALLER + CALLED) en mode test /samples/MEGACO_2
Ce package de test simule un trafic venant d’une access gateway, et relié par un MGC vers cette même access gateway (abonnés demandeurs et demandés sur le même équipement simulé).
Fichiers scenarios inclus : tulip.xml : fichier de configuration GO_MEGACO.xml : fichier lanceur du répondeur, des traffic agents (CALLER+CALLED). Se termine ensuite. RESPONDER_MEGACO.xml : fichier répondeur, utilisé en mode couplé avec chaque traffic agent. TEST_MGC.xml : séquentiel décrivant le comportement du MGC en mode test. ABODR.xml : séquentiel décrivant le comportement de l’access gateway de l’abonné demandeur. ABODE.xml : séquentiel décrivant le comportement de l’access gateway de l’abonné demandé.
La topologie est de type « CALLER+CALLED+MGC + responder (mode test)».
3) Access gateway (CALLER + CALLED + MGC) en mode UDP /samples/MEGACO_UDP
Ce package permet la simulation d’abonnés de test raccordés à une access gateway (CALLER + CALLED). L’access gateway dialogue avec un MGC local/distant en MEGACO/UDP.
Fichiers scenarios inclus : tulip_client.xml : fichier de configuration du client. tulip_server.xml : fichier de configuration du serveur. GO_MEGACO.xml : fichier lanceur du répondeur, des traffic agents (CALLER+CALLED). Se termine ensuite. GO_MGC.xml : fichier lanceur du répondeur, des traffic agents (MGC). Se termine ensuite. RESPONDER_MEGACO.xml : fichier répondeur, utilisé en mode couplé avec chaque traffic agent. SERVER_MEGACO.xml : séquentiel décrivant le comportement du MGC en mode UDP. ABODR.xml : séquentiel décrivant le comportement de l’access gateway de l’abonné demandeur. ABODE.xml : séquentiel décrivant le comportement de l’access gateway de l’abonné demandé.
|
| MEGACO |
|
 |
