Skip to main content
Procédez d’abord au sortant, puis à l’entrant. Le sortant isole les identifiants, le transport et les codecs avant que les variables de routage (FQDN, IP source, correspondance du DID) n’entrent en jeu, et la plupart des trunks fonctionnent en sortant en quelques minutes.

​
La plateforme n’envoie jamais de SIP REGISTER

La plateforme authentifie chaque appel directement, requête par requête — elle ne s’enregistre jamais auprès de votre fournisseur, et n’attend jamais que votre fournisseur s’enregistre auprès d’elle. Si le tableau de bord de votre fournisseur affiche le trunk ou l’utilisateur SIP comme Offline / Non enregistré après la configuration, c’est normal, pas un défaut : les appels entrants arrivent via la destination que vous avez configurée (le FQDN SIP de la plateforme), pas via un enregistrement. Plusieurs guides fournisseurs le précisent explicitement car cela semble cassé au premier abord — voir Fonial et Autres fournisseurs et fournisseurs personnalisés pour des exemples.

​
Les appels sortants ne se connectent pas

  1. Vérifiez d’abord l’hôte de terminaison, le transport (UDP/TCP/TLS) et les identifiants au regard de la documentation du fournisseur — un transport incohérent, ou un préfixe sip: ou un port superflu sur l’adresse de terminaison, est la cause la plus fréquente.
  2. Confirmez que le format du numéro d’appel sortant (international avec +, international sans +, ou national) correspond à ce qu’attend le fournisseur pour ce trunk — certains opérateurs rejettent silencieusement un mauvais format, d’autres acceptent l’appel puis le coupent.
  3. Si le fournisseur exige que les appels proviennent d’une IP source unique et whitelistée, activez explicitement Fixed outbound IP. La plateforme n’a sinon aucune IP sortante statique, ce qui fait échouer toute liste blanche d’IP côté fournisseur sans ce réglage activé.
  4. Comparez les codecs : un fournisseur n’acceptant que le G.711 rejettera un appel proposant encore Opus/G.722, ou ne renverra l’audio que dans un sens.
  5. Modifiez un seul réglage à la fois et passez un appel test après chacun — History affiche le code de statut SIP exact, ce qui identifie la cause bien plus vite qu’en devinant.

​
Les appels entrants n’atteignent pas l’assistant

  • Envoyez vers le FQDN SIP de la plateforme, jamais vers une adresse IP brute. Envoyer vers une IP est la cause la plus fréquente d’échec entrant, et échoue silencieusement des deux côtés — aucun appel n’apparaît jamais dans History.
  • Avec Provider source IPs, chaque IP/CIDR de signalisation actuel doit être saisi. Une liste obsolète ou incomplète rejette les appels sans erreur claire, plutôt que de les refuser explicitement.
  • Confirmez que le DID correspond exactement à ce qu’envoie le fournisseur — un trunk SIP Extension a également besoin de son Primary DID renseigné, car ce n’est pas un caractère générique.
  • Si rien n’arrive du tout dans History (pas même un appel en échec), le fournisseur n’atteint pas encore la plateforme — vérifiez d’abord sa propre règle de sortie/renvoi avant de supposer un problème d’authentification côté plateforme.

​
Les transferts d’appel échouent (SIP REFER)

Un transfert à froid ou à chaud qui échoue alors que les appels ordinaires fonctionnent normalement tient presque toujours à l’un de ces points, dans cet ordre :
  1. Le trunk ne prend pas en charge SIP REFER. Ce n’est pas le cas de tous les opérateurs — voir le guide Easybell pour un exemple concret, et le guide PBX et centre de contact pour les notes spécifiques à Aircall/Five9. Quand c’est la cause, aucun changement de format de destination ne résout le problème : passez ce transfert en Warm Transfer, qui déclenche un nouvel appel sortant et le connecte au lieu de faire un REFER sur l’appel existant.
  2. Le format de l’URI SIP. Si REFER est pris en charge mais que le transfert échoue quand même, essayez les variantes dans l’ordre : avec le port (sip:+1234567890@sip-server:5060), sans le port, puis un sip:+1234567890 nu.
  3. La destination elle-même. Confirmez que le numéro cible est joignable et non bloqué avant de conclure que le trunk est en cause.
Chaque tentative de transfert — réussie ou non — laisse call_transfer_failed ou warm_transfer_failed dans le journal d’événements de l’appel ; consultez Appels entrants et sortants pour la structure d’échec commune.

​
Codes de statut SIP courants

Ces codes correspondent aux codes d’échec neutres vis-à-vis du fournisseur (busy, no_answer, authentication_failed, destination_forbidden, trunk_unavailable, …) décrits dans Appels entrants et sortants.

​
Connectivité générale

  • Confirmez que le réseau derrière le trunk dispose d’une connexion internet fonctionnelle.
  • Vérifiez qu’aucun pare-feu ne bloque le trafic SIP sortant — un pare-feu n’ouvrant que les ports standards (5060/5061) rejette silencieusement les fournisseurs utilisant des ports de signalisation non standards (par exemple Genesys Cloud sur 32681/32682).

​
Avant de contacter le support

  • Sortant : identifiants vérifiés, bon type de trunk/téléphone sélectionné, Fixed outbound IP configuré si le fournisseur l’exige, un appel test direct effectué.
  • Entrant : méthode d’authentification configurée (IP source ou nom d’utilisateur/mot de passe), chaque IP fournisseur actuelle saisie en cas d’authentification par IP, fournisseur confirmé comme envoyant vers le FQDN (pas une IP), un appel test effectué depuis un numéro externe.
  • Général : connectivité réseau confirmée, pare-feu écarté.

​
Obtenir de l’aide

À fournir en contactant le support :
  • L’ID d’appel depuis History.
  • La configuration exacte du trunk (type, transport, méthode d’authentification).
  • Les résultats de test pour les deux sens (sortant et entrant).
  • Pour les problèmes de transfert, le format d’URI SIP exact que vous avez essayé.
Testez l’entrant et le sortant indépendamment — le bon fonctionnement de l’un ne confirme jamais celui de l’autre.