Les téléphones IP sont largement utilisés dans les communications d’entreprise, les systèmes de répartition, les centres d’appels, les campus, les sites industriels, les hôtels et les réseaux de services publics. La plupart des téléphones IP modernes utilisent le protocole SIP, ce qui facilite leur enregistrement auprès des serveurs SIP, des plates-formes IP PBX, des systèmes softswitch et des plates-formes de communication unifiée. Cependant, lors du déploiement, un problème courant peut apparaître : l’audio unidirectionnel.

L’audio unidirectionnel signifie qu’un appel est établi, mais qu’un seul côté peut entendre l’autre côté. La signalisation SIP peut sembler normale, le téléphone peut sonner et l’appel peut être décroché avec succès, mais le flux vocal ne circule pas correctement dans les deux sens. Ce problème est généralement lié à la NAT, à la transmission RTP, aux politiques de pare-feu, à SIP ALG, à la négociation des codecs, à la configuration du terminal ou aux paramètres média du serveur.

Commencez par la différence entre signalisation et médias

Un appel téléphonique SIP contient deux parties importantes : la signalisation et les médias. La signalisation SIP est utilisée pour l’enregistrement, la numérotation, la sonnerie, l’établissement et la libération de l’appel. RTP est utilisé pour transmettre le flux vocal réel après l’établissement de l’appel. Cette différence est la clé pour comprendre pourquoi un audio unidirectionnel peut se produire.

Dans de nombreux cas, la partie SIP réussit car le port SIP par défaut, souvent UDP ou TCP 5060, est autorisé par le réseau. Le téléphone peut s’enregistrer, composer et répondre normalement. Mais les ports RTP utilisés pour la voix sont différents du port de signalisation SIP. Si le chemin RTP est bloqué, mal routé, mal traduit ou envoyé à la mauvaise adresse IP, l’appel peut aboutir sans voix bidirectionnelle normale.

Par conséquent, le dépannage ne doit pas s’arrêter à l’état d’enregistrement SIP. Un téléphone correctement enregistré peut encore avoir des problèmes de médias. Les ingénieurs doivent vérifier si les deux côtés peuvent envoyer et recevoir des paquets RTP pendant l’appel.

La NAT est une source courante de problèmes de direction audio

La NAT permet aux périphériques d’un réseau local d’accéder à des réseaux externes via une adresse IP publique. C’est courant dans les bureaux d’entreprise, les sites distants, les hôtels, les usines et les endroits éloignés. Lorsqu’un téléphone IP ou un serveur SIP se trouve derrière une NAT, le périphérique peut annoncer une adresse IP privée dans les informations SIP ou SDP. Le côté distant peut alors essayer d’envoyer des paquets RTP vers une adresse privée injoignable.

C’est l’une des causes les plus courantes d’audio unidirectionnel, en particulier lorsque le serveur SIP est déployé sur le réseau public et que les téléphones IP se trouvent dans différents environnements LAN. L’appel peut être établi, mais le flux média ne peut pas revenir vers le périphérique interne correct.

Pour résoudre ce problème, le déploiement doit utiliser une conception appropriée de traversée NAT. Les méthodes courantes incluent STUN, TURN, RTP symétrique, mappage d’adresses publiques, redirection de ports, déploiement SBC ou relais média via le serveur SIP. Le meilleur choix dépend de la topologie du réseau et du fait que le système soit déployé dans un réseau privé, à travers des réseaux publics ou entre plusieurs sites distants.

Les règles de pare-feu doivent inclure le trafic RTP

La politique de pare-feu est une autre raison fréquente de l’audio unidirectionnel. De nombreux administrateurs n’ouvrent que le port de signalisation SIP et oublient la plage de ports RTP. En conséquence, les téléphones peuvent s’enregistrer et les appels peuvent être créés, mais les paquets vocaux ne peuvent pas traverser le pare-feu.

RTP utilise généralement des ports UDP. La plage de ports dépend du téléphone, du PBX, du serveur SIP, du SBC ou de la configuration de la plateforme média. Dans de nombreux environnements SIP, RTP peut utiliser des plages telles que UDP 16384-32768 ou une autre plage personnalisée définie par l’administrateur système. La plage exacte doit être vérifiée à la fois dans la configuration du téléphone et dans celle du serveur.

Pour un audio bidirectionnel fiable, les règles de pare-feu doivent autoriser les ports UDP média requis dans les deux sens. Si le déploiement implique plusieurs VLAN, tunnels VPN, routeurs distants, serveurs cloud ou mappage d’IP publiques, chaque segment réseau doit être vérifié. Un seul segment bloqué peut créer des symptômes d’audio unidirectionnel ou d’absence d’audio.

Le routage RTP a besoin d’un chemin média clair

La voix du téléphone IP est transportée par des flux RTP. Si l’adresse de destination RTP, l’adresse source, le port ou le chemin de routage est incorrect, l’audio peut ne fonctionner que dans un seul sens. Cela peut se produire non seulement dans les scénarios de réseau public mais aussi à l’intérieur d’un LAN privé.

Par exemple, le téléphone et le serveur peuvent utiliser des plages de ports RTP différentes, ou le serveur peut s’attendre à ce que les médias passent par un proxy média tandis que le terminal essaie d’envoyer les médias directement à un autre téléphone. Certains systèmes prennent en charge les médias directs entre terminaux, tandis que d’autres exigent que tout le trafic RTP passe par le serveur ou le SBC. Si ce mode est mal configuré, un audio unidirectionnel peut apparaître.

Lors du déploiement, l’équipe du projet doit confirmer si le chemin vocal est de terminal à terminal, de terminal à serveur ou de terminal à SBC. Tous les périphériques dans le flux d’appel doivent utiliser des adresses IP joignables et des paramètres de port RTP compatibles.

SIP ALG peut aider ou casser l’appel

De nombreux routeurs et pare-feux incluent une fonction SIP ALG. Elle est conçue pour inspecter et modifier les paquets SIP afin que le trafic SIP puisse traverser NAT plus facilement. En théorie, cela semble utile. En pratique, SIP ALG peut parfois modifier incorrectement les informations SIP ou SDP et provoquer un audio unidirectionnel, des appels échoués ou un enregistrement instable.

Si un réseau utilise déjà un SBC approprié, un mappage d’adresses publiques, STUN ou un mécanisme de relais média, SIP ALG peut devenir inutile, voire nuisible. Dans de nombreux cas de dépannage, la désactivation de SIP ALG sur les routeurs ou les pare-feux peut résoudre les problèmes d’audio unidirectionnel.

Le bon choix dépend de la conception du réseau. Si SIP ALG est utilisé, il doit être testé soigneusement. Si le système dispose déjà d’une méthode contrôlée de traversée NAT, la désactivation de SIP ALG est souvent une meilleure option.

La négociation des codecs doit être cohérente

Les téléphones IP prennent généralement en charge plusieurs codecs vocaux, tels que G.711, G.729, G.722 et d’autres formats audio. Ces codecs sont sélectionnés lors de la négociation SIP. Si les deux parties ne partagent pas un codec compatible, l’appel peut avoir une absence d’audio, un audio déformé ou un comportement média instable.

Le décalage de codec n’est pas toujours la première cause de l’audio unidirectionnel, mais il doit tout de même être vérifié. Ceci est particulièrement important lorsque des téléphones de différents fournisseurs, des softphones, des passerelles, des plates-formes PBX et des systèmes d’enregistrement sont utilisés ensemble.

Une solution pratique consiste à prioriser les codecs communs sur tous les périphériques. Par exemple, G.711 est souvent utilisé dans les environnements LAN en raison de sa simplicité et de sa qualité vocale, tandis que des codecs compressés peuvent être utilisés lorsque la bande passante est limitée. La stratégie de codec doit correspondre à l’état réel du réseau.

La configuration côté téléphone ne doit pas être ignorée

Certains problèmes d’audio unidirectionnel sont causés par les paramètres du terminal. Le téléphone IP peut avoir une configuration incorrecte des ports RTP, un mode NAT, des paramètres de compte SIP, des options de relais média, des paramètres d’interface réseau locale ou une priorité de codec incorrecte. Dans certains cas, le téléphone peut également être en mode muet, le câble du combiné peut être desserré, ou les paramètres du haut-parleur et du microphone peuvent être incorrects.

Lorsqu’un seul ou quelques téléphones ont le problème, la comparaison des terminaux est utile. Les ingénieurs peuvent comparer un téléphone fonctionnel avec un téléphone problématique et vérifier les paramètres du compte SIP, l’adresse réseau, la plage de ports RTP, la liste des codecs, le mode de traversée NAT, la version du firmware et l’état du périphérique audio.

Cette méthode est souvent plus rapide que de modifier immédiatement les paramètres globaux du serveur. Si le problème est limité à un seul terminal, la cause profonde est généralement plus proche de ce terminal ou de son réseau local.

Les paramètres du serveur et du proxy média affectent tous les appels

La configuration du serveur SIP peut également provoquer un audio unidirectionnel. L’adresse du serveur média, le mode proxy RTP, l’adresse IP externe, l’adresse IP interne, la plage de ports, la politique de médias directs, le traitement NAT et les paramètres de relais peuvent tous affecter le chemin RTP.

Ces paramètres doivent être ajustés avec soin car les modifications globales du serveur peuvent affecter de nombreux utilisateurs à la fois. Si seulement quelques téléphones ont un audio unidirectionnel, il est préférable d’analyser la topologie du réseau et la configuration du terminal avant de modifier les paramètres centraux du serveur.

Lorsque le problème est complexe, la capture de paquets et les journaux du serveur sont utiles. En vérifiant les informations SIP/SDP et le flux de paquets RTP, les ingénieurs peuvent voir quelle adresse IP et quel port sont annoncés, où le flux RTP est envoyé et si l’autre côté le reçoit.

Les interfaces réseau multiples peuvent envoyer les médias dans la mauvaise direction

Certains téléphones IP, serveurs SIP, passerelles ou plates-formes de communication disposent de plusieurs interfaces réseau. Par exemple, un serveur peut avoir une interface pour le LAN, une autre pour un réseau public et une autre pour un réseau de gestion. Si le service média sélectionne la mauvaise interface, les paquets RTP peuvent être envoyés sur le mauvais chemin.

Cela peut créer une situation où la signalisation semble normale mais l’audio ne peut pas revenir correctement. Le périphérique peut annoncer la mauvaise adresse IP dans SDP, ou il peut envoyer des paquets RTP à partir d’une interface réseau inattendue.

Pour éviter cela, l’équipe du projet doit confirmer l’adresse de liaison correcte, la table de routage, la passerelle par défaut, l’interface média et le mappage NAT. Les environnements multi-NIC doivent être clairement documentés lors du déploiement.

Un flux de travail pratique pour le dépannage

Un processus de dépannage structuré est préférable à des modifications aléatoires de paramètres. Tout d’abord, confirmez si le problème se produit sur tous les appels ou seulement sur certains téléphones. Deuxièmement, vérifiez si les appels concernés sont internes, externes, intersites, basés sur VPN ou sur réseau public. Troisièmement, vérifiez si l’enregistrement SIP et l’établissement de l’appel sont normaux.

Après cela, concentrez-vous sur RTP. Vérifiez les politiques de pare-feu, les plages de ports RTP, les paramètres de traversée NAT, l’état de SIP ALG, la négociation des codecs, le mode de relais média et les paramètres d’IP externe du serveur. Si le problème reste flou, utilisez une capture de paquets pour confirmer si les paquets RTP sont envoyés et reçus dans les deux sens.

Un bon dépannage repose sur le chemin de l’appel. Une fois le chemin complet clair, le problème d’audio unidirectionnel devient beaucoup plus facile à localiser.

Planifier pour un audio bidirectionnel stable

La meilleure solution est de réduire les risques d’audio unidirectionnel dès la phase de conception. Pour les petits déploiements LAN, gardez le réseau simple et assurez-vous que les téléphones, le PBX et les passerelles utilisent des paramètres RTP cohérents. Pour les déploiements multisites, planifiez la traversée NAT, les règles de pare-feu, le routage VPN et l’emplacement du SBC avant d’installer les téléphones.

Pour les déploiements sur réseau public ou PBX cloud, il est généralement préférable d’utiliser un relais média ou un SBC pour contrôler le chemin RTP. Cela évite de nombreux problèmes liés à NAT et améliore la compatibilité entre différents environnements réseau.

La documentation est également importante. Le port SIP, la plage de ports RTP, la politique de codec, la méthode NAT, l’adresse IP du serveur, le paramètre de proxy média et les règles de pare-feu doivent être enregistrés pour la maintenance future.

Conclusion

L’audio unidirectionnel dans les systèmes de téléphonie IP n’est généralement pas causé par un seul problème fixe. Il peut provenir de la traduction NAT, de ports RTP bloqués, d’une politique de pare-feu incorrecte, d’une interférence SIP ALG, d’un décalage de codec, d’une configuration de terminal, de paramètres média du serveur ou d’un routage multi-interfaces réseau.

Une bonne solution commence par la compréhension de la différence entre la signalisation SIP et les médias RTP. L’enregistrement et la numérotation peuvent fonctionner normalement alors que la transmission vocale échoue. En vérifiant le chemin média étape par étape, les équipes de projet peuvent localiser le problème plus rapidement et construire un système de communication vocale IP plus stable.