Pourquoi un appel SIP s’enregistre sur un VPN mais n’envoie aucun son
L’enregistrement et l’audio suivent des chemins différents. Suivez un appel à travers le tunnel pour voir quelles adresses le PBX peut utiliser et où le RTP s’arrête réellement.
Une inscription réussie ne vous dit presque rien sur l’audio. Un softphone peut maintenir une liaison valide avec le PBX du bureau pendant des heures et livrer malgré tout du silence. Le tunnel ne transporte que les paquets que quelqu’un y envoie délibérément, et un appel emprunte trois chemins distincts : la liaison, l’établissement du dialogue et le flux RTP. Dès que vous les séparez, la panne tombe sur un chemin plutôt que sur le mot VPN.
Imaginez un ordinateur portable sur un Wi-Fi domestique qui compose un poste du bureau à travers un tunnel approuvé. Le PBX authentifie l’utilisateur, accepte le REGISTER, et le poste apparaît comme disponible, mais l’appel se connecte avec un silence total dans une direction.
L’enregistrement lie un contact, pas un chemin média
Une requête REGISTER demande au registraire de stocker une correspondance entre une adresse d’enregistrement et un ou plusieurs URI de contact. Cette correspondance répond à une question étroite : où envoyer un nouveau dialogue maintenant. Elle ne dit rien sur l’endroit où appartiennent les médias, et un enregistrement accepté ne prouve pas qu’un INVITE ultérieur porte une adresse média joignable. Les enregistrements expirent aussi selon un minuteur, si bien qu’un téléphone qui cesse de rafraîchir perd les appels entrants alors que son tunnel semble toujours sain. Surveillez l’expiration du contact plutôt que l’état du tunnel.
Quand le softphone se trouve derrière le tunnel, l’en-tête de contact peut porter une adresse privée. Un PBX qui le transmet à un autre point de terminaison crée un dialogue visant un réseau que le correspondant ne peut pas atteindre. Régler rewrite_contact=yes sur le point de terminaison PJSIP pousse le PBX à substituer l’adresse source qu’il a observée, et c’est souvent la différence entre une sonnerie et un délai expiré.
Ce que propose l’INVITE et qui peut l’utiliser
Un INVITE avec un corps SDP propose où l’appelant veut recevoir les médias : une adresse, un port et une liste de codecs. Le correspondant répond avec sa propre adresse et son propre port, puis chaque côté envoie du RTP vers ce que l’autre a proposé. Si l’appelant a proposé une adresse 192.168.x.x qui n’existe que dans son réseau domestique, le correspondant n’a nulle part où envoyer l’audio, aussi propre fût la signalisation. Le masquage réécrit les en-têtes IP lorsque les paquets quittent un routeur, mais il ne réécrit jamais le texte à l’intérieur d’un corps SDP.
Cet écart explique l’appel unidirectionnel classique : la signalisation fonctionne parce que les deux extrémités atteignent le PBX, et l’audio échoue parce qu’on a dit à une extrémité d’envoyer vers une adresse qui n’existe que derrière un autre NAT.
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
Qui transporte l’audio est un choix de configuration
La signalisation et les médias sont des rôles distincts. Un proxy peut rester sur le chemin de signalisation pendant tout un appel sans jamais toucher un seul paquet RTP. Que le PBX devienne un relais média dépend de la configuration, pas de la présence d’un tunnel.
Avec les médias directs, les extrémités échangent elles-mêmes le RTP, ce qui fonctionne bien sur un LAN et mal quand un côté se trouve derrière une plage de ports étroite.
Régler direct_media=no force le PBX dans le chemin média pour que les deux jambes se terminent sur une adresse qu’il contrôle, échangeant bande passante et processeur contre un adressage prévisible. Quand il relaie, le PBX doit encore annoncer une adresse joignable. Sur un hôte multi-réseaux, external_media_address et external_signaling_address dans pjsip.conf décident de ce qui apparaît dans le SDP et dans les en-têtes Via. Laissez-les non définis et le PBX peut proposer son adresse LAN à un appelant dont le seul chemin est l’autre côté du tunnel.
Suivez chaque direction avant de toucher aux réglages
Commencez par la table des sockets du PBX pendant qu’un appel est actif : ss -uanp | grep -E '5060|10000' montre si les ports RTP sont liés et quelle adresse locale ils utilisent. Si rien n’est lié dans la plage média, le relais n’est pas engagé et les extrémités dialoguent directement. Capturez ensuite côté softphone avec tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Des paquets sortants sans paquets entrants réduisent le problème au chemin de retour ou à l’adresse qu’on a dit à l’autre extrémité d’utiliser, et une capture vide signifie que les médias n’ont jamais atteint l’interface du tunnel. Une capture de signalisation avec sngrep répond à l’autre moitié en montrant la ligne de connexion SDP telle qu’elle a été envoyée.
Comparez l’adresse de cette ligne de connexion à l’adresse vers laquelle l’autre extrémité peut réellement router. Cette seule comparaison résout la plupart des rapports d’audio unidirectionnel plus vite que n’importe quelle revue de configuration.
Le chiffrement s’arrête au bord du tunnel
SIP sur TLS protège le saut de signalisation pour lequel il a été configuré, SRTP protège les médias quand les deux extrémités le négocient, et le tunnel protège le trafic entre ses propres extrémités. Aucun d’eux n’accorde les autres. Un appel chiffré à l’intérieur du tunnel peut sortir de la passerelle en clair vers le PBX, et c’est une décision de conception, pas un défaut.
Avant de fermer le ticket, confirmez trois choses dans l’ordre : l’enregistrement est récent, le SDP porte une adresse que l’autre extrémité peut atteindre, et les paquets circulent dans les deux sens sur les ports média. Si l’une de ces conditions est fausse, le tunnel n’est pas là où réside le problème. Corrigez le chemin qui a échoué, puis relancez la même capture pour confirmer le changement. Conserver les captures avant et après fait du prochain rapport unidirectionnel une vérification de cinq minutes au lieu d’un après-midi entier.