Petit récap sur la VoIP

Un cours s'impose

Avant de raccorder notre infrastructure à un transitaire voix, on a vu différences façons d'aborder la téléphonie chez un opérateur. En effet, on peut proposer pas moins de 4 offres :

• Centrex
• Trunk SIP
• Softphonie
• WebRTC

On pourrait aussi retrouver dans cette liste du Teams, du mobile, etc. Malheureusement, je ne peux pas labber tout ça, donc, dans ce blog, je me limite aux 4 offres ci-dessus !

On a enchainé 3 épisodes en se consacrant sur la configuration plutôt que la compréhension. Donc un récap s'impose dans ce épisode. On va voir les différents protocoles et les échanges utilisés dans le cadre de la téléphonie (et c'est pas aussi compliqué que je ne le pensais !).

Un peu de définition avant :

• URI : Equivalent à l'adresse mail d'un téléphone : sip:utilisateur@domaine.com. L'URI est utilisé pour router un appel.
• Codec : Compresseur / Décompresseur. Le flux voix doit être compressé pour être le plus léger possible ! Les deux plus récents et utilisés :
  • G711 : Meilleure qualité mais plus lourde (64 kbps)
  • G729 : Qualité moyenne mais léger (8 kbps)

Protocoles

Comme pour un backbone data, un certain nombre de protocoles sont utilisés. On commence par le plus évident : le SIP !

SIP

Session Initiation Protocol, définit dans la rfc3261, est le protocole utilisé pour la VoIP. C'est un protocole applicative sur le modèle TCP/IP, il est donc transporté par UDP généralement (pour l'absence de contrôle, il faut que ca aille vite !). Son port est en TCP/UDP 5060. Il existe aussi le SIPS qui lui est sécurisé via TLS et le port est TCP 5061.

SIP a été conçu pour établir, modifier ou terminer des sessions téléphoniques. En aucun cas, les données sont dans les échanges SIP.

Comme dans tout échange informatique, il y a un client (User Agent Client) et un serveur (User Agent Server). Les client sont bien évidemment des postes téléphoniques mais aussi des softphone, IPBX client, etc.

Quand au serveur, on l'appelle IPBX. Il a plusieurs fonctions :

• Registrar : Gère l'authentification des clients (login SIP)
• Proxy : Route les différents appels aux bonnes destinations
• Media server : Gère l'audio
• Gateway : Arrivée des trunk sip clients

Lors d'un échange, le client envoie donc des requêtes au serveur IPBX :

• Invite : Permet à un client d'initier une nouvelle session
• ACK : Confirme le message précédent envoyé par le serveur
• Cancel : Annule un invite en cours
• Bye : Termine une session
• Options : Permet de récupérer ou vérifier les capacités et la disponibilité d’un utilisateur ou d’un serveur
• Register : Permet de s'enregistrer auprès d'un serveur

SIP est fortement inspiré de HTTP. En effet, on retrouve des codes de retour, j'en liste quelqu'uns :

• 100 : Trying (Serveur reçoit la requête et la traite)
• 180 : Ringing (Téléphone sonne)
• 200 : OK
• 401 : Unauthorized (Téléphone pas authentifié)
• 403 : Forbidden (Interdiction d'appeler)
• 404 : Not found (Utilisateur n'existe pas par exemple)
• 486 : Busy Here (Utilisateur distant occupé)

J'en ai sûrement oublié mais c'est grosso modo les codes les plus retrouvés dans mes échanges que j'ai fait.

Regardons en détail le tout premier échange SIP d'un téléphone vers son IPBX :

Ici, le téléphone 192.168.1.155 envoie un register à l'IPBX 192.168.1.210. On remarque l'URI : sip:lba52j5v@192.168.1.22. On voit aussi que c'est un polycom qui s'enregistre et que l'utilisateur est Naruto Uzumaki ! Par contre, il se mange un 401 Unauthorized dans la foulée.

Mais pourquoi ?

Parce qu'en aucun cas le téléphone s'est enregistré avec ses logins SIP ! Bah oui, il les a jamais fourni dans le premier Register. L'IPBX lui répond donc : vas te faire foutre, je te connais pas, envoie tes logins 😄. C'est le champ WWW-Authenticate qui faut regarder ! C'est l'authentification digest SIP.

Dans le second register, le téléphone envoie ses logins dans authorization. Le serveur renvoie donc un 200 OK :

Avant de regarder les autres échange SIP en détail, il nous faut comprendre un autre protocole ..... le SDP !

SDP

Et oui, un autre protocole : le Session Description Protocole, définit dans la rfc4566. Si on dit que le SIP est le livreur d'un meuble IKEA, le SDP est la notice de montage (ma comparaison est un peu flinguée mais dans l'idée c'est ça lol).

En gros, le SDP va servir à décrire techniquement comment on fait. Il est transporté dans le message SIP !

Prenons un exemple pour voir les informations qu'il y a à l'intérieur (de cet échange SIP) :

Le SDP est décrit dans les informations en dessous :

xv=0
xo=- 1771967261 1771967261 IN IP4 192.168.1.22
xs=Polycom IP Phone
xc=IN IP4 192.168.1.22
xt=0 0
xa=sendrecv
xm=audio 2228 RTP/AVP 9 102 0 8 18 127
xa=rtpmap:9 G722/8000
xa=rtpmap:102 G7221/16000
xa=fmtp:102 bitrate=32000
xa=rtpmap:0 PCMU/8000
xa=rtpmap:8 PCMA/8000
xa=rtpmap:18 G729/8000
xa=fmtp:18 annexb=no
xa=rtpmap:127 telephone-event/8000

Et il nous indique quoi ?

• v : la version (toujours à 0)
• o : origine de la session (id de la session, version d'ip et l'ip)
• s : la marque du téléphone
• c : l'IP du téléphone source
• a : mode de communication
• m : média (type, format, protocole de transport)

Je pense que c'est assez clair sauf pour le m. A quoi correspond les nombres 9 102 0 8 18 127 ?
Juste en dessous de cette ligne, on les retrouve. Ce sont les codecs que le téléphone peut utiliser et va privilégier ! Ici, il préfère le codec G722 (codec privilégié des téléphones IP).

Bien sûr, en fonction de la techno (centrex, trunksip ou webrtc), le contenu du SDP va être différent et c'est normal ! Je ne vais pas détailler toutes les possibilités (la rfc existe 😄), le but étant de comprendre comment ça marche de faire un ding dong !

Il nous reste plus qu'un dernier protocole à voir avant de s'attaquer à une analyse entière d'un appel téléphonique !

RTP

On a vu le SIP et le SDP mais ce ne sont pas ces deux protocoles qui transportent la donnée, ils ne servent juste qu'à établir la session entre le poste et l'IPBX et les paramètres de négociation (codec, etc). Il nous faut donc trouver un protocole qui permet cela.

Et c'est le RTP qui l'emporte ! Il est transporté par UDP encore une fois. Il ne possède pas de ports fixe, en effet, c'est un range de port qui varie en fonction des constructeurs. J'aime bien set de 10 000 à 20 000. Ce sont aussi les ports par défaut de Wazo :

Ce protocole est assez simple à comprendre, chaque message passe par l'IPBX (à cause du NAT par exemple). Quoique, dans certains cas, on peut faire du P2P mais j'ai jamais vu donc bon 😅

Un exemple de trame :

Pas grand chose à expliquer hormis qu'en cas de débug, c'est pas parce que le SIP est OK que la communication passe ! On peut appeler cela des com blanches (par exemple le range de port RTP bloqué par un firewall ?), du one way audio (communication unidirectionnelle), etc.

Il existe aussi le SRTP qui permet de chiffrer le RTP. Je ferai un épisode sur le chiffrement des échanges téléphoniques, ca peut être marrant à tester 😄

Analyse d'un échange SIP

Maintenant qu'on a vu les trois grands protocoles, on peut enfin aller regarder sous le capot ! Prenons une trame SIP où 192.168.1.22 est un téléphone physique, 192.168.1.210 est un IPBX et 192.168.1.155 le softphone distant :

Qu'est ce qu'on observe ?

Déjà on a deux screens : le premier est entre téléphone source et IPBX et le second IPBX et le téléphone distant.

Intéressons nous d'abord au premier screen !

On voit un invite SDP, qui dedans, possède les informations qu'on a pu voir au dessus. L'IPBX répond un 401 unauthorized (voir échanges register, le client n'envoie pas de digest). Donc c'est tout à fait normal ! Une fois le digest envoyé par le client (premier screen), l'IPBX répond un 100 trying.

Puis l'IPBX envoie un invite vers le téléphonie distant :

Il est intérresant de regarder le contenu du SDP ! En effet, on voit que la source est un asterisk (wazo), l'IP est 192.168.1.210 et le codec utilisé va être le code 0 qui est le PCMU (variante de G711 si j'ai bien compris).

Le téléphone distant répond à l'IPBX en lui disant qu'il sonne avec un 180 ringing :

Puis l'IPBX dit au poste source 180 ringing :

Quand le client final répond, le téléphone envoie un 200 OK à l'IPBX :

L'IPBX renvoie un 200 OK au poste destination :

L'IPBX renvoie donc un ACK aux deux téléphones pour leur dire que c'est cool vous avez votre session en cours. A la fin de l'appel, le téléphone source raccroche. Un BYE est envoyé :

Puis les postes envoient un 200 OK à l'IPBX

C'est un échange SIP et ca sera toujours comme ca ! Les seules informations qui vont changer sont dans le SDP (et bien sûr les IP/utilisateurs) !

Le NAT : l'ennemi de la téléphonie

Le NAT a été conçu pour éviter que des gens incompétents passent sur IPv6 (petite pique azy excusez moi mais IPv6 >>>>> IPv4 mdrrr tellement plus simple).

Bon plus sérieusement, le NAT a été inventé pour pallier à des problèmes de ressources d'IPv4. Ainsi, des IP dites privées sont nattées sur des IP dites publiques. Or dans un message SIP (dans le SDP), l'IP du poste est envoyée donc son IP privée !

Le flux SIP va donc être ouvert car le flux TCP/IP va être natté mais pas les informations du SDP ... De ce fait, l'IPBX va voir une IP privée dans le SDP, comment peut-il répondre ?

Plusieurs contournements en vue le jour :

RPORT & RECEIVED & COMEDIA: Une donnée dans le SIP qui permet que le client puisse envoyer cette info : "salut bg l'ipbx, je t'envoie mon IP privée dans le SIP mais répond sur l'IP pub et le port que tu reçois ce message". De plus, avec le message comedia, le flux RTP va être envoyé au port d'où il a reçu le retour 200 OK (SDA) de l'IPBX.
Le plus couramment utilisé quand on maitrise le NAT des deux côtés.

STUN : Le client va demander à un serveur quelle est son IP publique et son port. Le STUN fonctionnait très bien sauf quand le NAT change le port quand la destination change ... Etant donné que le serveur STUN est généralement un autre serveur donc une autre destination que l'IPBX ... voili voilou

TURN : Amélioration du STUN. Le TURN est vu comme un serveur relai. Se reposant sur STUN, TURN réserve un couple adresse/port au niveau du serveur STUN qui sera utilisé à la fois pour contacter l’hôte distant, mais aussi pour que ce dernier puisse contacter le client.
Très utilisée quand les deux postes sont derrières un NAT qu'on ne maitrise pas par contre impossibilité de faire du P2P ;(

ICE : Comparé au STUN/TURN, ICE mise que l'intelligence doit être dans les postes et non un autre serveur ! De ce que j'ai compris (protocole très poussé), il permet de savoir si un serveur STUN suffit ou un TURN. Je ne détaillerai pas plus, je pense que ca sera plus simple de labber

SIP ALG : Une option dans les équipements faisant le NAT de casser le message SIP et d'y remplacer l'IP et le port utilisé dans le NAT.
Malheureusement ça pue sa grand mère, ça peut casser les message SIP donc le premier réflexe c'est de désactiver cette merde

SBC : Session Border Controller, c'est un équipement qui est vu comme un firewall pour la VoIP. Il permet de réécrire les headers SIP/SDP à la volée. Il force aussi le flux audio à passer par lui. Généralement, c'est là où sont montés les trunks opérateurs.

Etant donné que je vais dédier une VRF téléphonique pour chaque subnet voix pour mes clients, mon IPBX aura une patte dedans donc pas besoin de natter pour le contacter, c'est déjà ça ! Mon SBC portera mes transit voix, c'est donc là où les entêtes vont être modifiées. Le STUN/TURN sera utilisé pour mon webRTC 😄

Conclusion

Un gros épisode aujourd'hui, non pas par sa taille mais par son contenu.

Honnêtement, je n'avais jamais fait de téléphonie de ma carrière pro (2 ans et demi dans les télécoms en CDI). J'ai toujours pensé que c'était compliqué, j'en avais limite peur lol mais au final sah ...

Loin d'être un tutoriel qui explique de a à z le SIP mais je trouve que cela fait une bonne base. Je ne compte pas devenir expert VoIP, mon opérateur proposera que les solutions basiques mais il est toujours primordiale d'assurer un bon support à sec clients (OVH t'es visé).

Quelque soit la manière de collecter de la téléphonie (centrex, trunk, webrtc), le seul truc qui change c'est la manière de transporter le SIP et les informations dans le SDP !

Le SIP a été crée avant le NAT donc personne n'aurait pu anticiper les problèmes que ca allait impliquer ... Je vous conseille le blog https://www.nexcom.fr/blog/page/2/ qui explique plus en détail les solutions.

Prochain épisode : direction le SBC ! Bah oui, c'est bien beau de faire de la téléphonie mais si les clients ne peuvent même pas appeler des SDA ou se faire appeler, à quoi bon ? On simulera donc un transit voix (en attendant qu'OVH réponde à un ptn de ticket). On verra du kamailio, du rtpengine, du redis :p

Je termine sur un mot de fin : Xebec est tellement le roi des pirates fuck roger