Panoramisk

Délai de transit et qualification des partenaires

Le délai de transit sur un réseau IP est un vrai problème pour le passage de communications téléphoniques de qualité. On considère souvent qu’au delà de 150 ms de délai unidirectionnel, celui-ci devient perceptible pour notre oreille; au delà de 400 ms l’appel ne sera pas bon et la conversation devra s’adapter afin d’éviter les débuts de phrases coupées¹. Il est possible avec Asterisk de n’acheminer des appels qu’aux postes ou partenaires lorsque le délai de transit n’excède pas une valeur définie: c’est la qualification.

Pour chaque partenaire SIP (ou IAX), on peut positionner un contrôle actif du délai de transit via le paramètre qualify=, positionné dans [general] ou au niveau de chaque partenaire. Les valeurs possibles sont off ou on qui respectivement désactive ou active le contrôle actif du délai. Lorsqu’il est activé, la valeur crête est positionnée par défaut à 2 secondes.

Cette valeur de 2s est, à mon sens, absurde dans le cadre du passage d’une communication téléphonique et il est donc important de la réduire afin de l’adapter à la qualité de service que l’on souhaite atteindre sur son réseau. On peut, pour ce faire, remplacer la valeur on du qualify= par une valeur en ms plus faible, sachant que cette valeur correspond à un aller-retour entre l’Asterisk et le partenaire².

Le fonctionnement est assez simple: une fois enregistré chaque partenaire sur lequel une qualification est nécessaire se voit envoyer une méthode SIP INFO (ou son équivalent en IAX) à laquelle il est censé répondre avec la liste des méthodes qu’il supporte. Ce message n’est pas conçu pour cet usage à l’origine, mais il n’existe pas de méthode de type HELLO en SIP, aussi l’objectif est atteint. Asterisk détermine le temps de réponse à ce message spécifique et se base sur celui-ci pour extraire temporairement le partenaire si le délai est trop important, supérieur au qualify donc.

La périodicité de cet envoi dépend du statut du partenaire. Si celui-ci peut recevoir des appels la vérification se fera toutes les minutes, sinon toutes les 10 secondes. Ces valeurs ne sont pas modifiables (en version 1.4) par configuration pour SIP, mais le sont pour IAX2.

On peut connaître la dernière valeur collectée et le statut avec un :

sip show peers

ou

iax2 show peers

en vérifiant la dernière colonne nommée Status. Si la valeur est OK on peut acheminer des appels sur ce partenaire, si au contraire la valeur est LAGGED, le délai est trop important et aucun appel ne sera acheminé. Entre parenthèses est fournie la valeur collectée du délai de transit, c’est donc un bon indicateur de la qualité instantanée d’un réseau avec un partenaire. Par exemple, sur notre Asterisk externe:

asterisk-dmz*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status
wengo/achauvinhameau       213.91.9.206         N      5060     OK (72 ms)
kiwak_outbound/achauvin    213.246.39.74        N      5060     OK (76 ms)
callcentric/17772435589    204.11.192.23        N      5060     OK (156 ms)
proxy01.sipphone.com/acha  198.65.166.131       N      5060     OK (231 ms)
4 sip peers [Monitored: 4 online, 0 offline Unmonitored: 0 online, 0 offline]

Clairement les Centrex basés en France sont pour nous plus proches que ceux en Amérique du Nord.

Ainsi, on peut utiliser plusieurs routes pour acheminer des appels et utiliser celle qui semble fournir le meilleur temps de transit afin de garantir, au moins à l’instant du passage de l’appel, que la qualité sera au rendez-vous sur le point du délai. Pour des utilisateurs nomades ou télé-travailleurs, ce principe prend tout son sens, mieux vaut proposer la boîte vocale qu’un appel sur une ligne fortement utilisée au moment de l’appel. Pensez-y.