Un trunk est la frontière où l'opérateur décide quels appels votre équipement peut émettre et recevoir. Si vous avez un PBX, le système téléphonique d'entreprise qui achemine vos appels, un session border controller, une plateforme de centre de contacts ou tout autre client SIP, le trunk est le moyen par lequel ses appels atteignent le monde extérieur et par lequel les appels extérieurs lui parviennent. Un session border controller est l'équipement qui protège la périphérie d'un réseau voix.
La première question est généralement de savoir si vous en avez besoin, et la réponse est oui. Ce qui varie, c'est ce que vous placez derrière.
Ai-je vraiment besoin d'un trunk ?
Oui. Ce qui diffère entre les configurations, c'est le client de votre côté, pas la présence d'un trunk.
Chaque appel vers ou depuis le réseau téléphonique en traverse un, parce que le trunk est l'endroit où la plateforme décide si elle accepte l'appel. Deux cas de figure sont courants :
- Vous avez un système téléphonique. Un PBX, un softswitch ou une plateforme de centre de contacts qui gère déjà les appels et a besoin d'une route vers le réseau public. Il se connecte en tant que pair, généralement depuis une adresse fixe, et son propre dial plan, les règles qui acheminent ses appels, assure le contrôle d'appel.
- Vous avez du code applicatif. Vous voulez que votre logiciel passe ou reçoive des appels sans exploiter d'infrastructure téléphonique. Vous avez quand même besoin d'un trunk, et ce qui s'y connecte peut être léger : un softphone, un navigateur, le CLI ou un runtime d'agent vocal. Il s'authentifie avec un identifiant de session éphémère, un nom d'utilisateur et un mot de passe temporaires pour un client SIP, plutôt que depuis un équipement à adresse connue.
La distinction porte sur l'endroit où vit le contrôle d'appel, pas sur l'échelle, et aucun des deux cas ne contourne le trunk. Ce qu'un client léger vous épargne, c'est l'exploitation d'un système téléphonique, pas la connexion elle-même. L'outillage propre de Bird l'illustre doublement : le téléphone du tableau de bord et l'appel de test du CLI sont tous deux des clients SIP qui passent de vrais appels à travers l'un de vos trunks.
Le trunk n'est pas non plus une alternative au API, car aucun endpoint ne passe un appel vers une destination de votre choix. Qu'est-ce qu'un API voix explique comment la partie configuration et la partie signalisation se répartissent le travail.
Que fait concrètement un trunk ?
Il donne à votre équipement une adresse vers laquelle envoyer les appels, et décide lesquels il accepte.
Bird attribue à chaque trunk un domaine SIP fixe, que vous saisissez dans votre système téléphonique pour que les appels puissent être associés au trunk. Votre équipement envoie vers ce domaine sur l'un des trois transports : UDP ou TCP sur 5060, ou TLS sur 5061 lorsque vous voulez que la signalisation soit chiffrée en transit.
Un nouveau trunk rejette chaque appel. Les deux directions sont désactivées, et aucun expéditeur n'est autorisé. C'est un choix délibéré, pas une configuration incomplète. Un trunk qui accepterait les appels dès sa création serait une invitation permanente, et la fraude au péage rend cela coûteux très vite.
Pourquoi le sortant et l'entrant sont-ils configurés séparément ?
Parce que ce sont des problèmes différents avec des modes de défaillance différents, et qu'un trunk porte chaque direction indépendamment.
Le sortant, c'est votre système téléphonique qui passe des appels via Bird. Tant que vous ne l'activez pas, le trunk refuse chaque tentative sortante quels que soient les identifiants, de sorte qu'un appel correctement authentifié échoue quand même si la direction est désactivée.
L'entrant, c'est Bird qui livre les appels à votre système téléphonique pour les numéros pointant vers le trunk. L'activer ne suffit pas en soi : un trunk avec l'entrant activé et sans passerelle de livraison refuse chaque appel entrant vers ses numéros. Le rattachement d'un numéro au trunk se fait sur le numéro et non sur le trunk, ce qui est l'autre moitié que l'on oublie souvent.
Désactiver les appels entrants remet chaque numéro pointant vers ce trunk en rejet, et le réactiver ne les restaure pas. Supprimer le trunk produit le même effet. L'annulation n'est donc pas symétrique : si vous désactivez l'entrant pour tester quelque chose, prévoyez de rediriger chaque numéro ensuite, et vérifiez les numéros au lieu de supposer que le basculement les a restaurés.
Comment un trunk décide-t-il qui peut lui envoyer des appels ?
Une liste d'autorisation IP, l'authentification par clé API et les identifiants de session en décident. Ils peuvent être combinés, et chacun devient actif dès qu'il contient une entrée.
Une liste d'autorisation IP. Ajoutez les adresses publiques depuis lesquelles votre équipement envoie vers SIP. Le filtrage démarre dès que la liste contient une entrée, et à partir de là, seules les plages listées peuvent envoyer des appels. Pour un équipement derrière du NAT, il s'agit de l'adresse publique du routeur, pas de l'adresse privée du système téléphonique. Les appels depuis des adresses non listées sont refusés à la couche SIP et n'apparaissent généralement jamais dans le journal d'appels. Un journal vide est donc un symptôme de cela, pas la preuve que rien n'a été tenté.
Authentification par clé API. Bird conteste l'appel, et votre système répond avec un hash du mot de passe plutôt que le mot de passe lui-même. Le hash est vérifié par rapport à une clé Bird API disposant d'un accès voix en écriture. Dans votre PBX, le nom d'utilisateur est toujours bird et le mot de passe est le secret de la clé. Comme la liste IP, elle devient exclusive dès qu'une clé est autorisée.
Deux détails opérationnels en découlent. Retirer la permission voix d'une clé interrompt son authentification immédiatement. La clé reste dans la liste autorisée du trunk, marquée, afin que la liste ne paraisse jamais fonctionnelle quand elle ne l'est pas. Remettre la permission la restaure sans rien modifier. Révoquer ou supprimer la clé prend effet immédiatement sur chaque trunk qui l'autorisait, et c'est définitif. Pour faire une rotation, ajoutez d'abord la nouvelle clé au trunk, migrez votre équipement, puis révoquez l'ancienne en dernier.
Identifiants de session. Un nom d'utilisateur et un mot de passe SIP éphémères répondant au même challenge sans exposer un secret de longue durée. Ils sont désactivés sur un nouveau trunk et appartiennent à l'espace de travail plutôt qu'à un seul trunk. Le mot de passe n'est renvoyé qu'au moment de sa création.
Activer les identifiants de session ne change pas la façon dont l'équipement en liste d'autorisation se connecte. Un appel depuis une adresse listée sur un trunk sans clé API autorisée est toujours admis sans aucun challenge de mot de passe. Si vous vouliez que l'identifiant serve de contrôle d'accès, c'est la liste IP qui continue silencieusement de remplir ce rôle.
Pourquoi mon navigateur ou mon softphone échoue-t-il à s'authentifier ?
Presque toujours à cause de l'algorithme de digest. C'est le seul paramètre qui échoue d'une manière qui ressemble à un problème d'identifiants.
Par défaut, Bird propose SHA-256 en premier et MD5 en second, et votre équipement répond avec le premier qu'il supporte. Un trunk n'accepte que les algorithmes qu'il propose, donc restreindre l'offre restreint ce qui peut se connecter.
Le piège, ce sont les navigateurs : un navigateur répond avec MD5 et rien d'autre. Un trunk n'offrant que SHA-256 rejette chaque appel depuis un navigateur, y compris le téléphone du tableau de bord. Gardez donc MD5 dans l'offre sur tout trunk depuis lequel vous comptez appeler via un navigateur, et réservez le MD5 seul au cas où un PBX traite mal un challenge commençant par SHA-256. Les clés API fonctionnent avec l'un ou l'autre algorithme et n'ont jamais besoin d'être réémises lorsque vous modifiez l'offre.
Que dois-je configurer ?
- Un trunk, quel que soit votre cas de figure. Chaque appel en traverse un, cette étape n'est donc pas optionnelle.
- Un pair, si vous exploitez un système téléphonique. Connectez le PBX ou la plateforme de centre de contacts depuis une adresse fixe, et laissez son dial plan contrôler les appels.
- Un client léger, si vous avez du code applicatif. Un softphone, un navigateur, le CLI ou un runtime d'agent, s'authentifiant avec un identifiant de session éphémère au lieu d'une adresse connue.
- Une règle d'expéditeur, quel que soit votre choix. Une liste d'autorisation IP, une clé API autorisée ou un identifiant de session, en gardant à l'esprit que chacun devient exclusif dès qu'il contient une entrée.
- MD5 conservé dans l'offre de digest sur tout trunk depuis lequel vous comptez appeler via un navigateur.
Trunks SIP couvre chaque paramètre et où le trouver. Clients SIP couvre la connexion d'un client unique plutôt que d'un système téléphonique, et dépannage voix traite les appels qui n'arrivent pas.
En bref
Tout chemin vers le réseau téléphonique traverse un trunk.
Ce qui change, c'est le client de votre côté : un système téléphonique connecté en tant que pair, ou un client SIP plus léger tel qu'un navigateur ou le CLI sur un identifiant éphémère.
Un nouveau trunk refuse tout.
Les deux directions sont désactivées, et aucun expéditeur n'est autorisé tant que vous n'en ajoutez pas un. C'est délibéré, pas une étape de configuration que vous pouvez ignorer.
Chaque direction est activée séparément, et l'entrant nécessite une passerelle.
Un trunk avec l'entrant activé mais sans passerelle de livraison refuse chaque appel entrant vers ses numéros.
Désactiver l'entrant ne s'annule pas proprement.
Chaque numéro pointant vers le trunk repasse en rejet, et réactiver l'entrant ne les restaure pas. Redirigez chaque numéro vous-même.