Mon blog

Le protocole de téléphonie sur IP SIP est séparé en deux parties, la signalisation (appeler, raccrocher, etc) qui se fait avec SIP lui-même, et les données qui sont envoyées par un autre mécanisme, mais contrôlé par SIP. Pour la signalisation, SIP avait déjà une fonction de genre traceroute, permettant de visualiser le chemin suivi par les messages SIP. Mais il n'y avait pas l'équivalent pour les données, ce qui est fait désormais.

SIP est normalisé dans le RFC 3261, dont la section 20.22 décrit l'utilisation de l'en-tête Max-Forwards: pour tracer la route entre l'appelant et l'appelé. C'est que les appels SIP ne voyagent que très rarement directement d'un appelant (par exemple un softphone) vers un appelé (entre autres parce que l'appelé n'est pas forcément joignable directement, coincé qu'il est derrière le NAT). Il est courant que l'appel passe par au moins deux intermédiaires (le relais du fournisseur SIP de l'appelant et celui de l'appelé), d'où l'importance de pouvoir faire des « traceroute ». Un traceroute SIP fonctionne donc en envoyant des requêtes avec un Max-Forwards: à 0, puis à 1, et ainsi de suite (comme le traceroute IP utilise le champ TTL), en recevant les messages de code 483 (Too many hops), on identifie les intermédiaires.

Même problème pour les données, elles ne vont pas forcément directement d'un client SIP à un autre, elles peuvent passer par des intermédiaires qui ajoutent des fonctions comme la musique d'attente (RFC 7088), la traversée des NAT, le réencodage du flux audio dans un autre format, etc. Bref, pour les données aussi, on a besoin d'un équivalent de traceroute, afin de pouvoir déboguer tout problème qui surgirait.

Justement, le RFC 6849 fournit un mécanisme, dit media loopback, sur lequel bâtir ce traceroute. Le service de « bouclage » du RFC 6849 permet de renvoyer le flux de données vers l'émetteur, afin que celui-ci puisse contrôler en quel état est ce flux à une étape donnée. Mettons que notre sympathique Alice veuille appeler Bob. Bob n'entend rien à ce que raconte Alice. Il va falloir déboguer. Alice va donc devoir demander à chaque intermédiaire (les B2BUA, back-to-back user agent) de lui envoyer une copie du flux de données, suivant le RFC 6849. Mais Alice ne les connait pas, ces intermédiaires, et n'a pas de moyen de leur parler directement. D'où notre nouveau RFC.

Le principe est d'envoyer une requête SIP INVITE vers Bob, avec des Max-Forwards: partant de zéro et croissant, et d'y joindre un SDP qui demande le bouclage des données (suivant la syntaxe du RFC 6849). Un intermédiaire SIP classique va rejeter l'appel avec le code 483 mais, s'il suit ce nouveau RFC (et le RFC 7332, qui le complète), il va accepter l'appel et renvoyer les données à Alice. Sa réponse sera une réponse positive au INVITE, donc avec le code 200, et, pour indiquer que ce n'est pas la « vraie » réponse de Bob, il indiquera une raison (RFC 3326) Traceroute response.

Attention à la sécurité, ce mécanisme peut finir par envoyer pas mal de données à Alice et imposer du travail aux intermédiaires. Ceux-ci doivent donc avoir un mécanisme pour activer/désactiver ce service, ainsi qu'une limitation automatique du nombre de réponses envoyées (comme les routeurs IP ont une telle limitation pour le traceroute classique).