Absence de son, audio dans un seul sens, écho, « robot »
Un téléphone peut être enregistré, appeler et décrocher — sans transmettre le moindre son. La raison : l’enregistrement et la voix empruntent deux chemins différents : l’enregistrement passe par des messages de service sur le port 5060, tandis que la voix circule dans un flux distinct de paquets sur les ports 10000–20000. Le routeur de l’établissement peut laisser passer le premier et bloquer le second. Ce n’est ni une panne du téléphone, ni une panne du standard : dans neuf cas sur dix, c’est le réseau entre les deux qui pose problème, et on peut le localiser en quelques minutes.
La configuration générale des téléphones se trouve dans l’aperçu « Configuration des téléphones SIP », les autres symptômes dans le diagnostic par symptômes.
Vérifiez d’abord dans l’admin#
Test d’écho
*43depuis l’appareil concerné. Le standard décroche, émet une tonalité au bout d’une seconde, puis renvoie votre voix. La tonalité retentit avant l’écho à dessein — elle vérifie le sens « standard → téléphone » indépendamment du microphone :Ce que vous entendez Ce que cela signifie Tonalité, puis votre voix Le son passe dans les deux sens — le réseau jusqu’au standard est correct Tonalité présente, vous ne vous entendez pas Le son n’arrive pas du téléphone au standard Même la tonalité est absente Le son n’arrive pas du standard au téléphone Vous vous entendez, mais de façon hachée ou avec retard Le chemin existe, mais il est mauvais : pertes, gigue, canal surchargé Parlez dans
*43pendant une dizaine de secondes — le standard aura alors le temps de mesurer les pertes, la gigue et le retard. Analyse détaillée dans « Vérification de la qualité de la liaison ».Journal des appels — ouvrez l’appel problématique. La ligne « Son » d’un appel décroché indique si la voix passait dans les deux sens : « dans les deux sens », « pas de son depuis le téléphone poste 101 » ou « pas de son depuis l’interlocuteur », — avec à côté les pertes, la gigue et le RTT de chaque côté.
Fiche de l’appareil → « Son dans les deux sens » — combien d’appels de ce téléphone étaient unidirectionnels. Pour les modèles qui perdent la voix au moment du décrochage, le standard active lui-même les « tonalités du standard » — c’est également visible ici.
Enregistrement de la conversation, si l’enregistrement est activé : celui que l’on entend sur l’enregistrement est celui dont la voix est parvenue au standard.
Trace SIP sur un standard dédié : dans la description du son (
SDP, lignesc=etm=audio), on voit quelle adresse et quel port chaque partie a annoncés.
Pourquoi l’enregistrement fonctionne mais pas le son#
Notre standard fait toujours passer la voix par lui-même (les téléphones n’échangent pas le son directement) et répond vocalement vers l’endroit d’où provient la voix du téléphone, et non vers l’adresse que le téléphone a annoncée. C’est pourquoi un téléphone derrière un routeur n’a besoin ni de STUN, ni de redirection de ports. Mais il en découle aussi que si rien n’arrive du téléphone au standard, le standard n’a nulle part où répondre — d’où un silence dans les deux sens.
Ce qui casse le plus souvent la voix, alors que l’enregistrement est correct :
- SIP ALG sur le routeur (« SIP Helper », « SIP Passthrough »). Le routeur « aide » le SIP et réécrit les adresses dans les messages de service — souvent à tort. L’enregistrement passe, le son non, ou dans un seul sens. Où le désactiver selon les marques de routeurs — « Réseau, routeur et internet ».
- UDP sortant 10000–20000 fermé. Le pare-feu laisse passer « internet » (ports web) et le 5060, mais pas les ports vocaux.
- Double NAT — routeur du fournisseur plus votre propre routeur derrière : les adresses sont réécrites deux fois, et l’un des réécrivains se trompe.
- Wi-Fi — réseau invité avec isolation des clients, signal faible, téléphone éloigné du point d’accès.
- Canal surchargé — la vidéosurveillance déverse ses enregistrements dans le cloud, les clients regardent des vidéos sur la même connexion : la voix arrive avec des trous.
Pour l’administrateur réseau : ce que le standard fait du son
- La voix passe toujours par le standard (
direct_media=no) : les téléphones n’échangent pas les RTP directement — c’est ce qui permet l’enregistrement, le téléprompteur et les mesures. - RTP symétrique (
rtp_symmetric=yes) : le standard envoie la voix vers l’adresse et le port d’où provient réellement le flux du téléphone. La signalisation également (force_rport,rewrite_contact). - Réception stricte (
strictrtp=yesdansrtp.conf) : après avoir mémorisé la source de la voix au début de la conversation, le standard n’accepte le son que de celle-ci — protection contre l’usurpation. - Ports RTP : serveur mutualisé — UDP 10000–10200, standard dédié — UDP 10000–20000. Il faut ouvrir l’UDP sortant vers l’adresse du standard ; aucune redirection entrante n’est nécessaire.
- Codecs : G.711 µ-law (PCMU), G.711 A-law (PCMA), G.722. G.729, Opus et AMR ne sont pas proposés aux téléphones.
- Chiffrement de la voix (SRTP) désactivé par défaut. Un SRTP activé dans le téléphone produit un silence ou un refus d’appel.
- Coupure sur silence non configurée (
rtp_timeout=0) : le standard ne raccroche pas faute de son — un appel « silencieux » restera en attente jusqu’à ce que quelqu’un raccroche.
Valeurs issues de shared/sip/advanced-options.json et sip-edge/asterisk/rtp.conf.
Aucun son du tout#
Pourquoi cela arrive#
- Les ports vocaux sont fermés dans les deux sens : l'UDP sortant 10000–20000 est bloqué par le pare-feu ou le routeur. Comme rien n'est arrivé du téléphone, le PBX ne sait pas où envoyer la réponse.
- SIP ALG a réécrit l'adresse vocale dans la description de l'appel, et les paquets partent au mauvais endroit.
- Le chiffrement vocal (SRTP) est activé sur le téléphone — notre PBX ne le propose pas par défaut.
- Les trois codecs que nous proposons (G.711 PCMA, PCMU et G.722) sont désactivés sur le téléphone. Dans ce cas, l'appel ne se connecte généralement même pas — réponse
488. - Le téléphone est connecté via un VPN ou un proxy d'entreprise qui ne laisse pas passer l'UDP.
Que faire#
Après chaque étape, composez *43 ; ne continuez que si cela n'a pas aidé.
- Désactivez SIP ALG sur le routeur et redémarrez le routeur et le téléphone.
- Ouvrez l'UDP sortant 10000–20000 vers l'adresse du PBX (pour le serveur partagé, 10000–10200 suffisent).
- Sur le téléphone, désactivez SRTP / le chiffrement vocal et vérifiez qu'au moins G.711 (PCMA ou PCMU) est activé.
- Connectez le téléphone par câble au réseau principal de l'établissement, en dehors du Wi-Fi invité et du VPN.
- Si un autre routeur se trouve derrière celui du fournisseur d'accès — passez le routeur du fournisseur en mode pont (bridge) ou connectez le téléphone directement dessus. Plus de détails — « Réseau, routeur et internet ».
On n'entend que dans un sens#
Pourquoi cela arrive#
Le son unidirectionnel recouvre deux cas différents — *43 les distingue à la tonalité :
- « On ne m'entend pas » (tonalité présente, pas ma voix) : le son n'arrive pas du téléphone au PBX. Causes : SIP ALG, microphone coupé ou bouton Mute, casque défectueux, mode casque activé sans casque, téléphone en Wi-Fi invité. Sur certains modèles, la voix se perd exactement au moment de la réponse — le téléphone change de port audio (c'est par exemple le comportement du D-Link DPH-150S) ; pour les modèles connus, le PBX corrige cela tout seul, en activant les « tonalités du PBX ».
- « Je n'entends pas » (pas de tonalité) : le son n'arrive pas du PBX au téléphone : pare-feu strict, SIP ALG, double NAT. Si le journal de l'appel indique « aucun son ne venait de l'interlocuteur », c'est l'opérateur ou l'appelant qui était muet — votre téléphone n'y est pour rien.
Que faire#
- Composez
*43et déterminez le sens à la tonalité. - « On ne m'entend pas » : vérifiez le Mute et le casque, essayez le combiné au lieu du haut-parleur ; désactivez SIP ALG ; sortez le téléphone du Wi-Fi invité.
- « Je n'entends pas » : désactivez SIP ALG ; vérifiez le pare-feu (UDP sortant 10000–20000 et les réponses correspondantes) ; supprimez le double NAT.
*43est propre dans les deux sens, mais le son unidirectionnel n'apparaît que sur les appels externes — la panne se situe entre le PBX et l'opérateur. Comparez avec un appel interne à un collègue et envoyez l'heure de l'appel au support.- Son unidirectionnel au moment de la réponse et sur un seul modèle — sur un PBX dédié, dans « Réglages du téléphone » du poste, activez « Tonalités sortantes — du PBX, pas de l'opérateur ». Prix : le collaborateur n'entendra pas les messages de l'opérateur avant la réponse (« abonné indisponible »).
Écho#
Pourquoi cela arrive#
La règle principale de l'écho : c'est celui dont la voix se réfléchit à l'autre bout qui l'entend. Si c'est vous qui entendez votre propre écho — la source est chez votre interlocuteur : son haut-parleur, un casque bon marché, un volume poussé à fond, un téléphone en voiture — le microphone capte votre voix depuis son haut-parleur et la renvoie. Si c'est le client qui se plaint — la source est chez vous.
La deuxième source fréquente — la ligne analogique : un téléphone ordinaire via une passerelle-adaptateur (ATA) ou une ligne urbaine via une passerelle. À la jonction entre les « quatre fils » du numérique et les « deux fils » de l'analogique, une partie du signal se réfléchit en arrière ; c'est le suppresseur d'écho de la passerelle qui l'atténue.
Plus le délai sur la ligne est grand, plus l'écho est perceptible : une réflexion arrivée presque immédiatement n'est pas distinguée par l'oreille, mais une réflexion arrivée avec du retard s'entend comme une répétition.
Dans *43, vous devez vous entendre — ce n'est pas de l'écho, mais le test lui-même. Mais si votre voix dans *43 revient avec un retard notable (délai RTT supérieur à 300 ms dans le journal), tout écho sur de vrais appels sera plus irritant : le canal est en cause.
Que faire#
- Déterminez qui entend l'écho. Vous — cherchez chez votre interlocuteur ; le client — chez vous.
- Écho venant de votre appareil : le combiné au lieu du haut-parleur, un volume de haut-parleur plus bas, un autre casque ; le téléphone pas contre un mur ni contre une vitre si vous parlez en haut-parleur. D'après la documentation Yealink, un microphone sensible placé trop près produit aussi de l'écho.
- Écho sur les appels via une passerelle (téléphone analogique ou ligne urbaine) : vérifiez que le suppresseur d'écho de la passerelle est activé — sur le Grandstream HT, c'est le champ Disable Line Echo Canceller (LEC), qui doit être sur No pour la voix (valeur d'usine) ; rétablissez les valeurs d'usine du gain de port (Rx / Tx gain) si elles ont été augmentées.
- Écho sur tous les appels externes via un même opérateur, alors que les appels internes sont propres — envoyez l'heure des appels au support.
Voix « robot », gargouillements, syllabes qui disparaissent#
Pourquoi cela arrive#
La voix est découpée en petits paquets, et chaque paquet perdu est un morceau de syllabe perdu. Les paquets arrivés de façon irrégulière sont temporairement lissés par le téléphone, mais si la dispersion est importante, le son se coupe. D'où trois chiffres que le standard mesure dans *43 et sur chaque appel décroché :
| Chiffre | Bon | Acceptable | Mauvais |
|---|---|---|---|
| Perte de paquets | jusqu'à 1 % | 1–3 % | plus de 3 % — « gargouillements », syllabes perdues |
| Gigue (irrégularité d'arrivée) | jusqu'à 30 ms | 30–50 ms | plus de 50 ms — le son se coupe |
| Délai RTT (aller-retour) | jusqu'à 150 ms | 150–300 ms | plus de 300 ms — les interlocuteurs se coupent la parole |
Ces mêmes seuils donnent les évaluations « qualité bonne / acceptable / mauvaise » dans le journal.
D'où viennent les pertes et la gigue : le Wi-Fi (surtout loin du point d'accès ou sur un canal encombré), un internet surchargé (caméras, exports, mises à jour, Wi-Fi invité sur le même canal), un routeur faible qui ne supporte pas la charge, l'internet mobile et le VPN.
Que faire#
- Faites
*43deux fois : à un moment calme et à l'heure de pointe. Bon au calme et mauvais en pointe — le canal est encombré ; mauvais toujours — le réseau ou le Wi-Fi. - Branchez le téléphone par câble au lieu du Wi-Fi.
- Séparez le Wi-Fi invité du réseau de service et limitez-lui le débit ; déplacez l'export des vidéos de caméras vers la nuit.
- Activez sur le routeur la priorité pour les téléphones (QoS), s'il le permet. Quelle connexion internet faut-il pour un appel — « Réseau, routeur et internet ».
- Sans résultat — montrez au fournisseur d'accès les chiffres du journal (pertes, gigue, heure) : c'est une discussion sur des faits, pas un « on vous entend mal ».
Comment déterminer de quel côté est la panne#
| Vérification | Ce qu'elle permet de séparer |
|---|---|
*43 depuis l'appareil problématique |
Votre réseau jusqu'au standard ↔ tout le reste. *43 propre — le téléphone et le réseau de l'établissement sont en ordre |
| Appel interne à un collègue vs appel externe | Interne propre, externe mauvais — le segment entre le standard et l'opérateur de téléphonie ou le côté de l'appelant |
| Enregistrement de la conversation | Celui qu'on entend sur l'enregistrement, sa voix est bien arrivée au standard. On entend les deux, mais pas dans le combiné — le problème se situe entre le standard et l'un des téléphones |
| Ligne « Son » dans le journal | « Aucun son depuis le téléphone poste 101 » — votre appareil ou son réseau ; « aucun son depuis l'interlocuteur » — le côté distant |
| Un autre téléphone sur la même prise | Même symptôme — le réseau ; symptôme disparu — l'appareil ou ses réglages |
Que nous envoyer pour le support#
- la date et l'heure de l'appel à la minute près, le numéro de l'interlocuteur et le poste ;
- qui n'entendait pas qui ou qui entendait un écho ;
- le résultat de
*43depuis cet appareil : tonalité, votre propre voix, coupures — et les chiffres du journal (pertes, gigue, RTT) ; - une capture d'écran de la fiche d'appel du journal avec la ligne « Son » ;
- le modèle et le firmware du téléphone (la ligne du tag de l'appareil), son mode de connexion (câble / Wi-Fi), le modèle du routeur et si le SIP ALG est désactivé ;
- sur un standard dédié — le texte de la trace SIP de l'appel reproduit.
Comment nous écrire — « Support ».
Questions fréquentes#
Dans *43, je m'entends avec un délai — est-ce un écho ?#
Non. *43 consiste justement à « renvoyer votre voix » : le délai correspond au temps de trajet jusqu'au standard et retour. Jusqu'à 300 ms, il passe presque inaperçu. Si le retard s'entend nettement (une demi-seconde et plus), les appels réels seront inconfortables — c'est le canal qui est en cause, pas le téléphone.
Le son disparaît uniquement lors des appels depuis des mobiles — est-ce chez nous ?#
Probablement non : votre interlocuteur mobile a son propre segment faible — le réseau cellulaire. Vérifiez *43 depuis votre appareil : s'il est propre et que les appels internes le sont aussi, envoyez au support l'heure de plusieurs de ces appels — nous regarderons sur quel segment le son se perd.
D'autres codecs — G.729 ou Opus — aideraient-ils ?#
Non. Notre standard propose aux téléphones les codecs G.711 (PCMA, PCMU) et G.722 — tous les téléphones les prennent en charge, et ils ne compressent pas la voix, donc ils résistent mieux aux erreurs. G.729, Opus et AMR ne sont pas proposés aux téléphones : les activer dans le téléphone ne sert à rien.
Peut-on activer le chiffrement de la voix pour que le routeur « ne touche pas » à l'appel ?#
Pour l'instant non : les téléphones fonctionnent en UDP / TCP sans TLS ni SRTP. Le SRTP activé « au cas où » dans le téléphone produit justement le silence. Contre le routeur, ce n'est pas le chiffrement qui aide, mais le SIP ALG désactivé.
Sections liées#
- Le téléphone ne fonctionne pas : diagnostic par symptômes
- Configuration des téléphones SIP — vérification de la qualité de la liaison
*43, réseau de l'établissement - Réseau, routeur et internet pour la téléphonie — SIP ALG par marques de routeurs, double NAT, canal
- L'appel se coupe — la coupure au bout de 30 secondes commence aussi par le SIP ALG
- Journal des appels et trace SIP
- Passerelles pour téléphones analogiques : Grandstream HT, Yeastar TA et Dinstar DAG
Sources#
- RFC 3550 — RTP et rapports RTCP, à partir desquels sont calculés les pertes, la gigue et la latence — https://www.rfc-editor.org/rfc/rfc3550
- ITU-T G.114 — recommandations sur la latence dans un sens (seuils de 150 / 300 ms de latence aller-retour dans
*43— pratique du secteur) — https://www.itu.int/rec/T-REC-G.114 - Yealink SIP-T2/T3/T4/T5/CP920 Administrator Guide V86.60 — Troubleshooting → Audio Issues : causes de l'écho et de la voix hachée
- Grandstream HT80x Administration Guide — Disable Line Echo Canceller (LEC), Rx / Tx gain — https://documentation.grandstream.com/knowledge-base/ht80x-administration-guide/
- Code du PBX :
shared/sip/advanced-options.json(direct_media=no,rtp_symmetric,force_rport,rewrite_contact, codecs,rtp_timeout=0),sip-edge/asterisk/rtp.conf(strictrtp=yes, ports),sip-edge/sipsync/linecheck.go(test d'écho*43, seuils 1 / 3 %, 30 / 50 ms, 150 / 300 ms) - Écrans d'administration : ligne « Son » du journal (
admin/app/[locale]/calls/i18n/CallsPbxLog.i18n.ts), bloc « Son dans les deux sens » (admin/components/integrations/SipDeviceMediaHealth.tsx), « Sonneries sortantes — depuis le PBX » (admin/components/integrations/SipOptions.i18n.ts)