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
- 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éfixesip:ou un port superflu sur l’adresse de terminaison, est la cause la plus fréquente. - 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. - Ne comptez pas sur une liste blanche d’IP côté fournisseur pour les appels sortants. La plateforme n’a aucune adresse IP sortante fixe : un fournisseur qui n’accepte que les appels provenant d’une seule IP source autorisée rejette donc les appels sortants. Réglez Authentification sortante sur Nom d’utilisateur / mot de passe (recommandé) et saisissez les identifiants SIP que votre fournisseur a émis pour le trunk. Si le fournisseur ne peut authentifier les appels sortants que par IP source, contactez le support avant la mise en service.
- 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.
- 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 :- 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.
- 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 unsip:+1234567890nu. - 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.
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é, authentification sortante réglée sur nom d’utilisateur/mot de passe (sans dépendre d’une liste blanche d’IP côté fournisseur), 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é.