Aller au contenu

Cas typiques — recettes par symptôme

Bibliothèque de cas concrets. Chaque entrée : symptôme, hypothèses à tester en ordre, fix typique. À enrichir au fil des incidents.

1. Pas d'audio bidirectionnel

Symptôme : appel établi (sonne, décroche), mais aucun audio dans aucun sens.

Hypothèses (ordre):

  1. Codec mismatch — les 2 côtés n'ont aucun codec en commun. SDP answer côté serveur indique m=audio 0 (port 0 = rejet).
  2. pjsip show endpoint <ext> → check les Codec(s) autorisés.
  3. Solution : aligner avec ce que parle le trunk SIP / le téléphone.

  4. Quirk Wazo (à vérifier sur FreePBX) : allow=!all,ulaw,alaw en une seule ligne (cf reference_wazo_confd_codecs_quirk).

  5. Port RTP bloqué par firewall — le 5060 passe (signal OK), mais pas le range 10000-20000.

  6. Côté serveur : ufw status et iptables -L -n.

  7. Côté trunk : whitelist IP côté SBC opérateur.

  8. external_media_address mauvais sur Asterisk dans le cloud.

  9. Le serveur annonce une IP non routable dans le SDP.
  10. cat /etc/asterisk/pjsip.transports_custom_post.conf (FreePBX) ou la conf transport : vérifier external_media_address = l'IP publique de l'instance.

2. Audio dans un seul sens (envoyé OK, reçu KO ou inverse)

Symptôme : "j'entends mon correspondant mais lui ne m'entend pas" (ou vice-versa).

Hypothèses :

  1. NAT du côté qui ne reçoit pas son audio — son SDP annonce une IP RFC1918 (192.168.x), l'autre lui envoie le RTP dans le vide.

  2. Solution endpoint : enabler rtp_symmetric=yes, force_rport=yes, rewrite_contact=yes.

  3. Coturn loopback peer (cas WebRTC) — coturn refuse de relayer vers une IP hôte. Bug suspecté de wazo-prod-01.

  4. Solution : external-ip=<IP publique> dans turnserver.conf, ou séparer coturn et Asterisk sur 2 instances.

  5. MTU bridge — paquets RTP fragmentés perdus en route.

  6. Solution : tester avec ping -M do -s 1472 <peer> pour trouver la PMTU. Si KO < 1472 : ajuster le MTU côté tunnel/VPN.

3. Le téléphone ne s'enregistre pas

Symptôme : le Yealink (ou softphone) reste avec une LED rouge "non enregistré". pjsip show contacts ne le voit pas.

Hypothèses :

  1. Mauvais creds — voir les logs auth : grep -i auth /var/log/asterisk/full | tail.
  2. Port 5060 bloqué — tester tcpdump port 5060 côté serveur, voit-on un REGISTER arriver ? Non = bloqué en amont (firewall site ou NAT côté téléphone).
  3. Adresse serveur mauvaise dans le téléphone — vérifier la conf provisioning Yealink (FQDN exact + port + transport).
  4. DNS — le FQDN résout-il vraiment vers l'IP du serveur depuis le LAN du téléphone ?
  5. Certificat TLS expiré (si transport TLS) — le téléphone refuse silencieusement. openssl s_client -connect pbx.fqdn:5061.
  6. fail2ban ban temporaire — fail2ban-client status sshd et fail2ban-client status asterisk.

4. Appel sortant 503 Service Unavailable

Symptôme : on compose un numéro externe, on entend "service indisponible" ou la ligne raccroche immédiatement.

Hypothèses :

  1. Trunk pas registered — pjsip show registrations. Si Rejected ou absent : creds, IP whitelist côté opérateur, ou opérateur en panne.
  2. Outbound route non matchée — le pattern de la route ne couvre pas le numéro composé. FreePBX → Outbound Routes → Dial Patterns.
  3. No Service à l'opérateur — heure de maintenance Sewan, contrat dépassé en MOU/min.

5. Appel entrant ne sonne nulle part

Symptôme : appeler le DID, ça sonne 1-2 secondes puis raccroche côté appelant. Aucun téléphone ne décroche.

Hypothèses :

  1. DID pas mappé dans Inbound Routes (FreePBX) — créer la route avec exact match du DID + destination.
  2. Trunk identifie pas l'INVITE entrant — config identify côté PJSIP : Asterisk doit reconnaître l'IP source du SBC opérateur.
  3. Context de routage incorrect — l'INVITE arrive dans un context où l'extension cible n'existe pas.

6. La voix est métallique / robotisée

Symptôme : on s'entend mais ça grésille, robotique.

Hypothèses :

  1. Jitter — variations de latence réseau qui ne tiennent pas dans le buffer.
  2. tail -F /var/log/asterisk/full | grep -i jitter ou Wireshark RTP Stream Analysis.
  3. Solution court terme : augmenter jbmaxsize dans rtp.conf.

  4. Solution propre : QoS WAN + Cat 6A + WiFi 6 / DECT solide.

  5. CPU surchargé sur le serveur — transcodage qui sature.

  6. top pendant un appel → si asterisk à 100% CPU.

  7. Solution : aligner les codecs pour éviter le transcodage.

  8. Codec compress trop — Opus 6kbps à du low quality.

  9. Forcer un codec PCMA/PCMU (au prix de plus de BP).

7. Échos / larsen

Symptôme : l'appelant entend sa propre voix avec un délai.

Hypothèses :

  1. Echo cancellation Asterisk désactivée — option echo_cancel dans chan_dahdi.conf (analogique) ou echocan PJSIP.
  2. Microphone trop proche du speaker côté téléphone — vérifier le hardware.
  3. Trunk SIP qui boucle son propre RTP — bug rare côté opérateur, à signaler.

8. Le BYE n'est pas propagé (raccroche d'un côté ne ferme pas l'autre)

Symptôme : "je raccroche, l'autre entend toujours sonner" (cas réel observé sur l'app technotrement-phone Wazo build 41).

Hypothèses :

  1. WebSocket fermée trop tôt — l'app coupe la WSS avant que le BYE soit envoyé. Solution : retenir la WSS jusqu'à confirmation ACK du BYE.
  2. Asterisk n'a pas reçu le BYE côté app, mais l'autre côté est resté en l'air.
  3. pjsip show channels peut révéler des canaux fantômes.
  4. core hangup all en dernier recours pour clean.
  5. CallKit qui release sans dire à JS (iOS) — bien chaîner endCall() natif → SIP BYE.

Template pour ajouter un cas

Quand vous résolvez un nouveau cas, ajoutez-le ici en suivant ce template :

## N. Court titre du symptôme

**Symptôme** : description précise et observable.

**Hypothèses** (ordre du plus probable au moins probable) :

1. **Cause A** — comment vérifier — comment fixer
2. **Cause B** — ...

Pour aller plus loin