Laquelle ?
Dans un monde numérique, le physique tend à disparaitre et les postes téléphoniques ne font pas exception. Cependant, on veut toujours être joignable par téléphone donc il faudrait une solution (ou plusieurs ?) qui permettent de répondre aux problématiques les plus basiques qui soit !
On va donc en voir deux : la softphonie et le WebRTC !
Softphonie
Cette solution est assez simple à comprendre. En effet, au lieu d'avoir un poste physique sur sa paillasse, on a un téléphone directement dans notre PC.
Pour tester, je suis parti sur l'application MicroSIP.
Donc pour configurer un utilisateur, c'est à peu près la même façon que dans le premier épisode, juste on ne crée pas de device 😄
Allez on s'y lance en créant l'utilisateur Kakashi (la team 7 est au complet, je compte pas la fraude sai) :
Et dans la ligne associé à l'utilisateur :
On ne renseigne pas de device (logique, y'en a pas !). Et c'est tout !
Dans la configuration de notre application de softphonie :
On renseigne l'IP de l'IPBX, le nom d'utilisateur et le mot de passe de la ligne. Plutôt simple nan ?
Allez on essaye d'appeler une extension dans le tenant :
Ca a l'air pas trop mal nan ?
On voit bien l'origine de l'appel qui est Kakashi avec en IP source 192.168.1.155 en destination de notre PBX. Ensuite, il y a les échanges SIP (prochain épisode en détail).
Et notre PBX contacte bien l'autre téléphone :
Et dans les CDR, on voit bien l'appel :
Enfaite, il faut voir cette solution comme une simple ligne SIP (OVH propose ça à 1€/mois par exemple). Elle pourrait très bien convenir à des TPE/PME <50 salariés. Par contre, on reste assez limité sur la configuration du softphone en lui même (cela dépend peut-être des solutions, à tester). Toute l'intelligence devra être faite sur l'IPBX. Par exemple, sur un Yealink T46G, on peut mettre en NDP, redirections, etc.
Il faut aussi que le poste puisse contacter l'IPBX en SIP (5060 UDP). Ainsi, ce port devra être autorisé depuis des IP publiques (et pas un pool IP privée car le softphone est sur le LAN DATA donc pas routé dans le backbone) ou que le client monte un VPN pour joindre l'IPBX en privée.
WebRTC
Comparé à la softphonie, il faut voir le webRTC comme une solution qui permet des communications en temps réel sans plugin via une API Javascript. De ce fait, il va se baser sur des websockets pour circuler (en gros via HTTPS donc via TCP / TLS). Le serveur fait juste office de relay. En effet, il transmet le demande d'appel à l'autre client. Si le client accepte alors les échanges sont entre les deux clients (donc en PeerToPeer).
Enormément de solutions sont basées dessus : Rainbow d'Alcatel et Teams de Micro$$$$ pour les plus populaires. C'est carrément la téléphonie de demain quand les postes vont être délaissés (ce qui arrivera sauf les standard I guess).
C'est aussi très intéressant car tout le monde peut l'utiliser donc faire des applications ! On peut citer Jitsi, Nextcloud Talk ou bien Mattermost.
Wazo ont développé une solution de démo basé sur du WebRTC. De ce fait, on va l'utiliser dans le cadre de ce blog (plus simple pour du lab, pas besoin d'installer un autre serveur mais ca aurait pu être un bel exercice).
Pour l'installer, il faut télécharger le plugin https://github.com/wazo-platform/wazo-webrtc-demo :
Ensuite, on se peut se connecter en web sur https://IP_SRV/wazo-webrtc-demo
Par contre, cela ne va pas être un utilisateur spécifique. En effet, au lieu d'utiliser la template global (qui correspond aux user SIP), on va utiliser celle dédié au webrtc donc on change ça :
On se connecte avec les logins du compte kakashi :
Appelons Naruto sur l'extension 1002 :
L'appel aboutit bien :
Une trace SIP :
On voit dans le via (2ème ligne) que l'échange se fait en WSS qui est du websocket donc bien du webrtc.
Ca c'est les échanges SIP à l'intérieur donc de la websocket. Si on regarde en wireshark :
On peut voir que les flux SIP sont dans du TLS donc chiffré via le certificat du site.
Ensuite vient le STUN qui est un service qui aide à établir une connexion avec une autre personne tout en contournant les différents problèmes de NAT. En l'occurrence, on a pas de NAT mais ça sera intéressant de voir comment le NAT peut impacter la téléphonie et voir comment installer un serveur STUN.
Pour finir, vient le DTLS qui permet de chiffrer l'UDP utilisé par les flux RTP. Ainsi, au lieu d'avoir du RTP en clair, le DTLS permet d'échanger des certificats pour chiffrer ce RTP et donc devenir du SRTP.
Conclusion
Je ne voulais pas rentrer trop dans les détails des échanges SIP ces 3 derniers épisodes car je vais en consacrer qui portera sur tous ces sujets de flux SIP / RTP / WSS / Codec / etc, ca sera plus simple et plus structuré qu'à chaque fin d'épisode 😄
Donc dans celui ci, si on récapitule, on a vu deux nouvelles façons de collecter de la VoIP : la softphonie et le webrtc.
Encore une fois, elles ne visent pas à remplacer les postes physiques (quoique) mais plutôt à avoir de nouveaux produits à proposer aux clients.
Aujourd'hui, énormément de solutions sont basées sur du webRTC en vrai (Rainbow d'Alcatel, Teams, Discord, etc). En plus, avec les nouvelles politiques et modes de supprimer le physique (tout dans le cloud = explosion des coûts mais bon cElA pErMeT dE sE dEdOuAnEr aka des gens qui comprennent rien au métier des réseaux / systèmes).
Cette épisode clôture les offres qu'un petit opérateur BtoB peut proposer en matière de téléphonie et c'est aussi le dernier de ce genre sur ce blog ... La fin se rapproche ! On pourrait aussi proposer des solutions de téléphonie mobile en devenant MVNO mais malheureusement c'est qu'un lab 😄
Je termine sur un mot de fin : Le vrai top four : Naruto, Kingdom, Gintama et Fairy Tail