Panoramisk

Asterisk et transport de la voix

Dans la téléphonie on sépare fonctionnellement le plan de contrôle, sur lequel transitent les messages de signalisation, du plan de transport de la voix. Chaque plan offre des fonctionnalités et des performances tout à fait différentes, ce qui dans les faits se traduit souvent par la mise en place de machines différentes et dédiées à un usage spécifique. Nous explorons dans cet article comment se comporte Asterisk par rapport à ce principe élémentaire de la téléphonie sur IP.

Dans la téléphonie privée (ou d’entreprise), les fonctions sont séparées mais la machine peut être la même, c’est souvent le cas des constructeurs issus du monde de la téléphonie, à contrario, ceux venant du monde de la donnée utilisent plus volontiers un modèle distribué dans lequel les tâches sont réparties sur des éléments différenciés.

L’approche sur Asterisk est résolument tournée vers la combinaison forte des deux fonctions: la signalisation des appels et le transport de la voix. On peut néanmoins, dans certains cas, extraire de l’Asterisk le transport de la voix et faire en sorte que celle-ci circule directement entre les terminaux.
Le fonctionnement par défaut d’un Asterisk est donc de transporter la voix. Il se place ainsi en intermédiaire entre les terminaux ou les ressources souhaitant échanger la partie voix de la communication téléphonique.

Le protocole IAX est tout à fait adapté à ce mode de fonctionnement, un seul canal de communication étant utilisé pour le transport de la signalisation et de la voix. En revanche, le protocole SIP fait un distinguo très fort entre les deux plans et ne s’attache qu’au premier, celui lié à la signalisation. Lorsque l’on utilise des postes téléphoniques de type SIP, Asterisk reproduit son schéma normal de fonctionnement en forçant le transport de la voix à transiter via son intermédiaire.

Faire passer la voix dans l’Asterisk offre des avantages indéniables:

capacité d’interception de touches de contrôle (cf features.conf)
uniformité des manipulations liées au traitement d’un appel sur tous les téléphones (renvoi, transfert, …)
adaptation de codec (celui-ci peut être différents sur chaque extrémité)

En revanche, la charge occasionnée par la gestion des trames contenant de la voix n’est pas forcément nécessaire, notamment pour les appels passés entre des postes sur le réseau interne. On pourrait donc arriver à des problèmes de qualité de service et de délai, surtout sur un réseau étendu avec un Asterisk en central: un appel entre deux postes sur un site distant transiterait par le point central.

Le schéma protocolaire d’un appel SIP standard sur Asterisk est le suivant:

On constate bien ici que l’ensemble de la signalisation transite par l’Asterisk, ainsi que la voix (en vert). Au niveau SIP cela correspond à peut près au fonctionnement d’un stateful proxy, au niveau de la voix d’un SBC¹.

Lorsque l’on souhaite détacher la voix de l’Asterisk, il faut remplir trois conditions:

ne pas mettre d’argument dans la commande Dial qui nécessite un contrôle de l’Asterisk, par exemple t ou T.
spécifier dans sip.conf l’option canreinvite=yes pour chaque téléphone SIP
disposer de terminaux capables de gérer la réception d’un message SIP INVITE en cours de communication

La première condition est simple à mettre en oeuvre, au niveau du fichier extensions.conf on modifiera les commandes Dial afin qu’elles ne comportent que les deux premiers paramètres.

La problématique du reinvite est plus complexe. En effet, le comportement d’Asterisk pour détacher l’audio path et le faire passer en direct n’est pas conforme à ce que l’on fait de façon standard en SIP. Normalement, au niveau des messages INVITE on spécifie directement les adresses IP des terminaux pour le passage de la voix. Dès que l’appel est accepté, chaque terminal envoi directement les trames voix, dans des capsules RTP, au terminal distant.

Asterisk se comporte comme détaillé sur le diagramme suivant:

La première phase est totalement similaire à celle constatée dans un appel supervisé. Ce qui est ajouté apparaît en phase 2, dans laquelle l’Asterisk envoie à chaque terminal un nouveau message INVITE dans lequel la partie de description des sessions mentionne les adresses IP des terminaux, de façon à modifier le chemin effectif des trames RTP. Mais la communication téléphonique a déjà commencé, via l’Asterisk. Si l’un des téléphone ne supporte pas de recevoir un nouveau message INVITE alors qu’il est en communication, l’appel pourrait alors être perdu. Si tout se passe bien, un nouvel échange RTP s’effectuera en direct, libérant ainsi des ressources sur l’Asterisk. L’objectif est donc ainsi atteint.

Si l’on souhaite favoriser le transit en direct des trames voix entre les terminaux, on veillera donc à choisir des téléphones capables de le gérer correctement. En plus de la partie SIP, il sera nécessaire d’adapter les codecs afin de ne pas se retrouver dans un situation dans laquelle le début de l’appel fonctionne car transitant dans l’Asterisk (qui effectue la conversion) et la suite de l’appel ne fonctionnant pas. Quelques essais et validation s’imposent donc.

Enfin, puisque l’on perd les fonctions centrales de traitement des appels, comme le transfert par exemple, il est nécessaire de former ses utilisateurs à l’utilisation particulière de leur téléphone. Chaque constructeur présente les fonctions de transfert de façon différentes, souvent sur les téléphones d’entrée de gamme on distingue le transfert supervisé (majoritairement utilisé en France), utilisant une touche Flash, du transfert non supervisé, utilisant une touche Transfer.