Pourquoi une deuxième offre ? Le centrex ne suffit pas à lui seul ?
Le centrex est une technologie pour toutes entreprises ne voulant pas gérer leur téléphonies. En effet, la gestion se fait par l'opérateur. Il suffit juste de créer des tickets (ou avoir la main sur son tenant) pour administrer sa voix.
Or certaines entreprises compétentes, ou historiques, possèdent un PBX sur site. Il est donc intéressant, au lieu de migrer la solution, de continuer sur cette architecture. Ainsi le client est autonome sur sa gestion. L'opérateur a juste a lui fournir des SDA et l'affaire est dans le sac. Ce qui est plutôt pas mal pour moi car je n'aime pas la téléphonie. Je préfère 1000x que le client soit autonome lol.
Configuration sur notre Wazo
Trunk SIP
Pour beaucoup d'opérateur, les trunks sont montés entre le PBX du client et le SBC opérateur (on verra ce que c'est dans 3 épisodes normalement). Or, moi, j'ai pris la décision de consacrer notre Wazo sur toutes les solutions de téléphonies.
C'est à dire que je n'ai pas envie de changer d'équipement si nouvelle offre alors que Wazo sait très bien le faire. Donc je prends la même décision que mes clients en centrex : un client = un tenant que ce soit centrex ou trunk sip.
Ainsi, je configurerai tout le temps mon PBX Multitenant !
Pour configurer ce fameux trunk, il faut aller dans Gestion des appels -> Trunks :
Oui j'ai choisi le contexte internal et je m'explique ! Comme vu dans l'épisode précédent, ce contexte permet de passer seulement des appels internes (sur des extensions en somme). Vu que je n'ai pas encore mis tout en place pour ma sortie sur des SDA publiques, je préfère faire cet épisode sur des numéros internes. On adaptera la configuration une fois qu'OVH aura répondu à mon ticket ...
Mais ce n'est pas la seule chose à renseigner, dans l'onglet AOR, on va désigner l'IP du serveur d'en face :
Le max_contacts set à 1 signifie que seule une machine peut monter le trunk.
Dans l'onglet Point de terminaison :
Le force_rport et le rewrite_contact c'est pour éviter les problèmes liés au NAT.
Le language, cela me parait évident.
Le allow sert à autoriser uniquement certains codecs. D'abord on interdit tout (!all), on autorise le codec G.711 (ulaw,alaw) qui est le codec le plus récent. En fonction de l'ancienneté du PBX client, on devra surement autoriser d'autres codecs 😄
Pour finir, dans l'onglet Identifier, on renseigne encore une fois l'IP du WAZO client :
On peut aussi configurer le trunk en registrar c'est à dire qu'un des deux PBX va s'enregistrer avec un couple de login/password. J'ai fait le choix de pas le faire car il s'agit d'un PBX client donc pas trop de risque.
root@wazo:~# asterisk -rx "pjsip show endpoints ?"
Endpoint:
I/OAuth:
Aor:
Contact:
Transport:
Identify:
Match:
Channel:
Exten: CLCID:
==========================================================================================
Endpoint: a6jtsyx9 Not in use 0 of inf
Aor: a6jtsyx9 1
Contact: a6jtsyx9/sip:192.168.1.220:5060 da3d6fec5e NonQual nan
Transport: transport-udp udp 0 0 0.0.0.0:5060
Identify: a6jtsyx9/a6jtsyx9
Match: 192.168.1.220/32
On peut voir que notre trunk est bien monté mais pas encore utilisé (bien sûr, il faut faire la configuration sur l'autre PBX, j'ai reconfiguré un wazo rapidement pour faire ce test !).
Appels sortants
La dernière étape pour notre études de cas d'aujourd'hui. Il faut voir un trunk SIP comme un tunnel entre deux PBX. Dans le monde de l'IP, une fois le tunnel monté, on a plus qu'a router les flux dedans ... et bah c'est la même chose avec un trunk !
Pour l'exemple de cet épisode :
| PBX | Extensions |
|---|---|
| Wazo MT | 1XXX |
| PBX client | 2XXX |
J'ai simulé les appels avec des numéros internes. Encore une fois le principe reste sensiblement le même avec des SDA.
Pour ce faire, on va dans Gestion des appels -> Appels sortants :
Ici, on dit qu'on route les numéros 2XXX (donc de 2000 à 2099) sur le trunk. Par exemple, si on avait voulu avoir une 'route par défaut', on aurait mis _X. (quoique mauvaise pratiques apparemment il faudrait être quand même plus restrictif, on verra ca prochainement). Le _ permet à asterisk de comprendre que c'est une regex et le X permet de dire [0-9].
Je sais pas si vous captez mais grosso modo c'est du routage statique avec des regex !
Pas besoin d'appels entrants vu que c'est des extensions encore une fois (ils servent à rediriger les appels sur une SDA vers une extension).
Tests d'appel
Allez, un petit test d'appel comme avec notre centrex !
Notre téléphone avec l'extension 1002 (PBX MT) appelle l'utilisateur avec la 2002 (PBX Client) :
root@wazo:~# asterisk -rx "core show channels"
Channel Location State Application(Data)
PJSIP/lba52j5v-00000034 dial@outcall:11 Up Dial(PJSIP/2002@a6jtsyx9,,o(20
PJSIP/a6jtsyx9-00000035 (None) Up AppDial((Outgoing Line))
2 active channels
1 active call
29 calls processed
Le call est bien active. On peut voir l'ID du trunk (a6jtsyx9) et celui du téléphone (lba52j5v).
Je ne vais pas remettre tous les logs mais il y a une chose primordiale qui change par rapport au centrex :
[2026-02-18 21:57:50.0839] VERBOSE[52194][C-0000001c] pbx.c: Executing [dial@outcall:2] Set("PJSIP/lba52j5v-00000032", "TRUNKEXTEN=2002@a6jtsyx9") in new stack
[2026-02-18 21:57:50.0991] VERBOSE[52194][C-0000001c] pbx.c: Executing [dial@outcall:11] Dial("PJSIP/lba52j5v-00000032", "PJSIP/2002@a6jtsyx9,,o(2002)") in new stack
On peut voir que le trunk a6jtsyx9 est bien choisi pour router le numéro.
Ensuite, le numéro de téléphone est bien appelé, le téléphone sonne et l'utilisateur répond bien :
[2026-02-18 21:58:28.7711] VERBOSE[52250][C-0000001d] app_dial.c: Called PJSIP/2002@a6jtsyx9
[2026-02-18 21:58:28.9911] VERBOSE[52250][C-0000001d] app_dial.c: PJSIP/a6jtsyx9-00000035 is ringing
[2026-02-18 21:58:29.5622] VERBOSE[52250][C-0000001d] app_dial.c: PJSIP/a6jtsyx9-00000035 answered PJSIP/lba52j5v-00000034
Puis, un bridge se forme entre les deux jusqu'à la fermeture du canal (un user a mis à l'appel) :
[2026-02-18 21:58:29.5627] VERBOSE[52263][C-0000001d] bridge_channel.c: Channel PJSIP/a6jtsyx9-00000035 joined 'simple_bridge' basic-bridge
[2026-02-18 21:58:51.1540] VERBOSE[52263][C-0000001d] bridge_channel.c: Channel PJSIP/a6jtsyx9-00000035 left 'simple_bridge' basic-bridge
Et un ptit wireshark ?
Conclusion
Honnêtement, j'ai longtemps redouté de faire cet épisode et plus globalement sur la téléphonie. Je n'ai jamais mis les pieds dedans et je suis plus à l'aise sur de l'automatisation / système en deuxième compétence (ce qui n'a rien à voir avec la voix).
Au final, je trouve que je m'en sors plutôt pas mal lol ! Certes, je pourrai aller plus loin dans la customisation pour le client (scénario d'appel, etc) mais ce genre d'exercice ne me fait peur comparé à monter l'infra. Ca reste assez simple de faire ce genre de demandes clientes une fois que tout est monté (c'est mon avis).
En me relisant, je trouve que y'a pas beaucoup de configuration même sur un Wazo qui, est, comparé à d'autres solutions, assez marrant à prendre en main car il ne mâche pas tout le travail. On arrive vraiment à comprendre ce qu'on fait et je trouve ça cool !
Prochain épisode : on continue de voir d'autres façons de collecter de la VoIP pour nos clients !
Je termine sur un mot de fin : Ca faisait longtemps donc Naruto > All > One Piece