Sommaire
- Qu'est-ce qu'un trunk SIP, concrètement
- Register ou IP-to-IP : lequel choisir
- Dimensionner : combien de canaux simultanés ?
- Codecs : G.711, G.729, Opus
- NAT : la cause n°1 des appels sans son
- Sécurité : la fraude à la terminaison
- Ce qu'il faut exiger d'un opérateur
- Checklist de mise en production
- Ce qu'il faut retenir
Un trunk SIP, c'est le lien entre votre standard téléphonique et le réseau téléphonique mondial. Le concept tient en une phrase, mais trois questions décident du résultat : combien de canaux, quel codec, et comment éviter de payer les appels de quelqu'un d'autre. Ce guide traite les trois.
Qu'est-ce qu'un trunk SIP, concrètement
Historiquement, une entreprise louait des lignes physiques : un T0 (2 communications simultanées), un T2 (30 communications). Le nombre de conversations possibles était figé dans le cuivre.
Un trunk SIP remplace ces lignes par une connexion logicielle sur IP entre votre IPBX (Asterisk, FreePBX, 3CX, un centre d'appels VICIdial…) et l'opérateur. Le protocole SIP gère la signalisation — qui appelle qui, ça sonne, ça décroche, ça raccroche — pendant que la voix elle-même circule séparément en RTP.
Cette séparation explique la moitié des incidents VoIP : la signalisation passe, l'appel s'établit, et pourtant personne n'entend rien. Dans ce cas, le problème est presque toujours le RTP, pas le SIP.
Signalisation SIP : port 5060 (UDP/TCP) ou 5061 en TLS. Média RTP : une plage de ports UDP, typiquement 10000–20000. Authentification : soit par identifiants (register), soit par autorisation d'adresse IP (IP-to-IP).
Register ou IP-to-IP : lequel choisir
Deux façons de prouver à l'opérateur que vous êtes bien vous.
L'enregistrement (register)
Votre IPBX s'annonce périodiquement auprès de l'opérateur avec un identifiant et un mot de passe. Avantage décisif : cela fonctionne derrière une IP dynamique et derrière du NAT. C'est le mode adapté aux PME, aux sites multiples et à tout ce qui n'a pas d'adresse fixe.
L'autorisation par IP (IP-to-IP)
L'opérateur autorise votre adresse IP publique ; aucun mot de passe ne circule. Plus robuste, plus simple à déboguer, et sans le bruit permanent des ré-enregistrements. C'est le mode standard pour un serveur en datacenter avec IP fixe — donc pour la quasi-totalité des centres d'appels.
IP fixe et serveur hébergé → IP-to-IP. IP dynamique, box, NAT ou mobilité → register. Et si vous êtes en IP-to-IP, pensez à prévenir votre opérateur avant de changer d'hébergeur : le trunk tombe à la seconde où l'IP change.
Dimensionner : combien de canaux simultanés ?
C'est la question qui coûte le plus cher quand on se trompe, dans les deux sens : trop peu et vos appels sont rejetés en pointe, trop et vous payez du vide.
Le calcul par les Erlangs
Le trafic en Erlang se calcule ainsi :
Trafic (E) = (nombre d'appels à l'heure de pointe × durée moyenne en secondes) / 3600Exemple : 240 appels dans l'heure la plus chargée, durée moyenne 180 secondes.
(240 × 180) / 3600 = 12 Erlangs12 Erlangs, c'est 12 conversations en moyenne à un instant donné. Mais la moyenne n'est pas le pic : il faut appliquer une marge pour absorber les rafales. Avec la formule Erlang B et un taux de blocage cible de 1 %, il faut environ 20 canaux pour 12 Erlangs. Une règle de terrain suffisante hors contexte critique : trafic × 1,6, arrondi au-dessus.
Le cas particulier du composeur prédictif
Un centre d'appels sortant en mode prédictif ne se dimensionne pas comme un standard. Le dialer compose plusieurs numéros par agent disponible, et la grande majorité de ces tentatives n'aboutit pas — mais chacune consomme un canal pendant la sonnerie.
| Configuration | Canaux par agent | Commentaire |
|---|---|---|
| Appels manuels / entrants | 1 à 1,2 | Un canal par conversation, plus une marge. |
| Progressif (1:1) | 1,5 | Sonnerie + conversation se recouvrent. |
| Prédictif ratio 2,5 | 3 à 3,5 | Le standard en B2C sur fichier chaud. |
| Prédictif ratio 4+ | 5 à 6 | Fichier froid, taux de décroché faible. |
Pour 20 agents en prédictif à ratio 3, prévoyez donc de l'ordre de 70 canaux, pas 20. C'est le premier poste de sous-dimensionnement que l'on rencontre.
Codecs : G.711, G.729, Opus
Le codec décide de deux choses : la bande passante consommée et la qualité perçue.
| Codec | Débit utile | Avec en-têtes IP | Usage |
|---|---|---|---|
| G.711 (a-law / µ-law) | 64 kbit/s | ~87 kbit/s par sens | Référence qualité. Le standard en Europe (a-law). |
| G.729 | 8 kbit/s | ~31 kbit/s par sens | Liens contraints. Qualité en retrait, mauvais rendu de la musique et des DTMF. |
| Opus | 6–510 kbit/s | variable | Excellent, adaptatif, résistant à la perte. Idéal en WebRTC. |
Le calcul de bande passante à retenir, en G.711 : ~87 kbit/s par appel et par sens, soit environ 174 kbit/s en bidirectionnel. Pour 30 appels simultanés, comptez donc à peu près 5,2 Mbit/s dans chaque sens, garantis — pas en débit théorique de la ligne.
Si vos postes parlent G.711 et votre opérateur G.729, votre serveur transcode chaque appel — et le transcodage est coûteux en CPU. Sur une machine modeste, quelques dizaines d'appels suffisent à saturer le processeur et à dégrader tous les appels d'un coup. Alignez les codecs de bout en bout quand vous le pouvez.
NAT : la cause n°1 des appels sans son
Si votre IPBX est derrière un routeur, il annonce dans les paquets SIP son adresse privée (192.168.x.x). L'opérateur, lui, ne sait pas router vers cette adresse : il envoie donc le flux RTP dans le vide. Résultat classique : la sonnerie fonctionne, l'appel est « établi », et le silence est total — souvent dans un seul sens.
Sur Asterisk, la configuration minimale côté sip.conf ressemble à ceci :
[general]
externaddr = 203.0.113.10 ; votre IP publique
localnet = 192.168.0.0/255.255.0.0
nat = force_rport,comedia
directmedia = noEt côté réseau, la plage RTP doit être ouverte en UDP :
; rtp.conf
rtpstart = 10000
rtpend = 20000Un pare-feu en politique « tout refuser » qui autorise 5060 mais oublie la plage 10000–20000/UDP produit exactement le même symptôme : appels établis, aucun son. C'est particulièrement fréquent sur les VM (Proxmox, ESXi) où le filtrage est appliqué au niveau de l'hyperviseur, en plus de celui de la machine.
Sécurité : la fraude à la terminaison
Un trunk SIP mal protégé est une carte bancaire ouverte. Le scénario type se déroule en trois temps : un robot scanne le port 5060, teste des extensions courantes (1000, 1001, 2000…) avec des mots de passe faibles, puis lance des milliers d'appels vers des numéros surtaxés à l'étranger, généralement la nuit du vendredi au samedi. La facture se compte en milliers d'euros en quelques heures.
Les mesures qui comptent vraiment
- Plafond de dépense chez l'opérateur. C'est la seule protection qui fonctionne même quand tout le reste a échoué. Exigez un crédit prépayé ou un plafond journalier.
- Restreindre les destinations. N'ouvrez que les préfixes dont vous avez réellement besoin. La plupart des fraudes ciblent des destinations que vous n'appelez jamais.
- Filtrer par IP. Autorisez le port 5060 uniquement depuis les adresses de votre opérateur et de vos sites. Interdisez le reste.
- Mots de passe d'extensions robustes. Aléatoires, 16 caractères, jamais égaux au numéro d'extension.
- Fail2ban actif sur les journaux SIP, avec bannissement long.
- Interdire les appels sortants aux extensions qui n'en ont pas besoin — postes d'accueil, interphones, salles de réunion.
- Une alerte de volume. Un simple contrôle du nombre d'appels par heure, avec notification au-delà d'un seuil, détecte la fraude bien avant la facture.
Regardez vos CDR sur les 30 derniers jours et listez les préfixes réellement composés. Tout ce qui n'y figure pas peut être bloqué sans risque. C'est dix minutes de travail et cela supprime l'essentiel de la surface d'attaque.
Ce qu'il faut exiger d'un opérateur
Au-delà du prix à la minute, quatre points distinguent un trunk exploitable d'un trunk qui vous fera perdre des clients :
- La présentation du numéro (CLI). L'opérateur doit transmettre le numéro que vous affichez, de bout en bout, sans le remplacer. Sujet détaillé dans notre article sur le choix du numéro appelant.
- L'ASR et l'ACD par destination. Un taux de réponse anormalement bas trahit des routes de mauvaise qualité, indépendamment de vos fichiers.
- La facturation à la seconde, sans palier initial de 60 secondes — l'écart atteint 15 à 25 % sur un trafic sortant à durée courte.
- Un support joignable en heures ouvrées de votre fuseau, capable de lire une trace SIP. C'est ce qui fait la différence un mardi matin à 9h05 quand plus rien ne passe.
Checklist de mise en production
- Mode d'authentification décidé (IP-to-IP si IP fixe) et IP communiquée à l'opérateur.
- Nombre de canaux calculé sur le trafic de pointe, avec la marge liée au mode de numérotation.
- Bande passante garantie vérifiée : 174 kbit/s bidirectionnels par appel en G.711.
- Codec aligné de bout en bout, transcodage évité.
externaddretlocalnetrenseignés si NAT ; plage RTP ouverte en UDP sur tous les pare-feux, hyperviseur compris.- Format des numéros validé dans les deux sens (E.164 avec
+33ou format national selon l'opérateur). - Plafond de dépense, restriction de préfixes, fail2ban et alerte de volume en place.
- Test réel : appel entrant, appel sortant, transfert, DTMF, mise en attente, et un appel de 20 minutes pour valider la stabilité.
Ce qu'il faut retenir
Un trunk SIP se juge sur trois axes : correctement dimensionné, il absorbe vos pointes sans rejet ; correctement configuré côté réseau, il ne produit pas d'appels muets ; correctement verrouillé, il ne finance pas la fraude d'un tiers. Le prix à la minute ne vient qu'après — et il se traite séparément, comme nous le détaillons dans les leviers de réduction du coût de terminaison.