Il y a deux modes de fonctionnement pour le routage des paquets:

- Routage applicatif : l’application utilise la payload applicative pour router le paquet vers le bon agent.

Si le fichier de configuration contient la directive <INTERNAL_ROUTER>, il est possible alors de lister les critères de routage par ordre de priorité.

Par exemple, en mode SIP :

         <INTERNAL_ROUTER>

            <CRITERIA>CALLID</CRITERIA>

            <CRITERIA>REQUESTURI</CRITERIA>

         </INTERNAL_ROUTER>

Cette déclaration signifie que l’application essaie d’abord de router en fonction du Call-Id SIP, puis en cas d’échec, utilise la Request-URI.

- Routage transport : cette fonction suppose que l’attribut MODE de la balise <TRANSPORT> soit positionné à MULTI. Dans ce cas, le paquet est routé à l’agent en fonction de la socket d’entrée sur laquelle il a été reçu (discrimination par port source/destination). Par exemple, la simulation http Client utilise un tel routage.

Lorsqu’un paquet est reçu, le processus suivant est déroulé :

1) S’il n’y a pas de traffic agent et que le launcher est en réception, envoyer le paquet vers le launcher.

          --> Si la réception échoue et le répondeur existe, router vers le répondeur

2) Si le routage applicatif renvoie un numéro d’agent existant et en réception, router le paquet vers cet agent.

          --> Si la réception échoue et le répondeur existe, router vers le répondeur associé à l’agent.

3) Si le routage applicatif échoue et que le répondeur existe, router le paquet vers le répondeur.

4) Si le routage n’est pas possible et que le répondeur ne peut accepter le paquet, afficher un warning non bloquant (UNEXPECTED message).

5) Si le routage est possible, mais que le paquet ne correspond pas à ce qui est attendu, arrêter l’appel (erreur bloquante).