J'ai passé une bonne partie de mon mois de juin à implémenter galene-sip, une passerelle entre le serveur de vidéoconférence Galène et le protocole SIP.
SIP
SIP (RFC 3261 est un protocole standardisé de téléphonie (et de vidéophonie). Un téléphone SIP peut se présenter comme un logiciel tournant sur un ordinateur ou un smartphone (un « softphone ») ou comme un téléphone matériel.
L'intérêt principal de SIP, c'est qu'il peut être connecté au réseau téléphonique. De nombreux fournisseurs de service fournissent un service SIP qui permet d'avoir un « vrai » numéro de téléphone, et de recevoir des appels sur son softphone. C'est pratique quand on a besoin d'un numéro à l'étranger, et c'est pratique quand on a besoin de recevoir des coups de fil quand on ne veut pas donner son numéro de portable.
Le problème, c'est que SIP n'est pas très bien conçu, et les défauts de SIP ont été réparés à l'aide d'extensions (SIP-outbound, PRACK, GRUU, il y en a qui ont du talent pour les acronymes sexy.). Il en résulte un protocole inutilement complexe, et qui n'est pas forcément sécurisé : le chiffrement du protocole est dans une extension (SIP/TLS), le chiffrement des média dans une autre (SRTP), et la plupart des fournisseurs n'implémentent ni l'une ni l'autre de ces extensions.
Galene-sip
Galene-sip est une passerelle entre SIP et Galène, ce qui permet de participer à une conférence sur Galène en appelant un numéro de téléphone.
Ce qui évite d'exclure ceux qui n'ont ni ordinateur ni smartphone, ceux qui n'ont pas de connectivité Internet, et ceux dont l'employeur interdit tout trafic autre que vers les GAFAM.
Vous commencez par créer un compte SIP, par exemple chez OVH. Vous compilez galene-sip :
git clone https://github.com/jech/galene-sip
cd galene-sip
go build
Vous lancez galene-sip, en lui indiquant votre adresse SIP et l'URL de votre groupe Galène:
./galene-sip -sip sip:user@sip.example.com -sip-password 1234 \
https://galene.org:8443/group/public/linuxfr-sip/
Galene-sip s'est enregistré auprès du fournisseur SIP. Lorsque quelqu'un appelle votre numéro, galene-sip se connecte au groupe Galène, et traduit l'audio entre SIP et Galène.
Il reste du travail
La version actuelle de galene-sip fonctionne surprenamment bien, mais il reste encore du travail. Ce qui me gêne le plus, c'est que ni le protocole SIP ni le trafic audio ne sont chiffrés : il faudrait implémenter SIP/TLS et SRTP, mais malheureusement la plupart des fournisseurs de service n'implémentent pas ces extensions. (Si vous connaissez des gens qui travaillent chez OVH, demandez leur d'aller râler auprès de la direction.)
# Désolé pour le formatage
Posté par jch . Évalué à 4 (+3/-0).
Mes excuses pour le formatage — j'ai rédige ce journal dans Emacs, et j'ai apparemment utilisé le mauvais dialecte de Markdown.
[^] # Re: Désolé pour le formatage
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0).
Corrigé, merci (ainsi que chiffrement plutôt que chiffrage).
# précision
Posté par tkr . Évalué à 2 (+1/-1).
traffic is in english
le trafic est un mot français ;)
un peu comme licence vs license ;)
Oui, mais les ptits geeks estiment que "c'est la fin du monde" sans support du srtp/zrtp chez OVH :
https://lafibre.info/sip/ovh-depuis-toutes-ces-annees-aucun-chiffrement-des-communications/
je trouve plus le lien, mais bref..
[^] # Re: précision
Posté par jch . Évalué à 2 (+1/-0).
Moi qui étais si fier d'avoir pensé à mettre une minuscule à « juin »… merci pour l'éducation.
# experience perso avec SIP sans TLS/ZRTP
Posté par Benjamin Henrion (site web personnel) . Évalué à 5 (+3/-0).
Experience perso avec SIP sans TLS/ZRTP, pour avoir bossé 5 ans dans une boîte de VoIP, je peux dire que certains opérateurs manipulent les messages SIP, à tel point que l'encryption était devenue presque nécessaire.
Et pareil pour le signaling en UDP, c'etait filtré par certains, à tel point qu'on avait du passer en TCP+TLS pour étre sûr que les appels passent.
PS: une petite pensée douce pour l'ami Dave That qui a bossé pour que la voix sur IP fonctionne mieux en diminuant la latence…
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par tkr . Évalué à 2 (+0/-0).
chez OVH, ça fait un moment que des clients demandent le SRTP/ZRTP, et tout le monde sait qu'il ne sera jamais installé. Ou en tout cas pas avant 2040.
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par jch . Évalué à 1 (+0/-0).
Pourquoi ?
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par Sylvain Berfini (site web personnel) . Évalué à 2 (+1/-0).
Attention à ne pas confondre !
On peut très bien faire du SRTP/ZRTP avec un compte OVH qui est connecté en UDP, mais effectivement on ne peut pas se connecter à leur proxy SIP en TCP ni en TLS ce qui est bien dommage.
Voici un article de notre wiki qui explique pourquoi UDP pour le SIP c'est pas bien : https://wiki.linphone.org/xwiki/wiki/public/view/Linphone/Good%20practices%20for%20using%20SIP/#HUseSIP2FTLS
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par jch . Évalué à 3 (+2/-0).
Tu aurais des détails ?
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par Benjamin Henrion (site web personnel) . Évalué à 3 (+1/-0).
C'était le cas en 2015 en Belgique avec un opérateur, les messages SIP de signaling en UDP étaient modifiés à la volée. L'UDP était aussi problématique pour le signaling.
Après le passage a TCP+TLS pour le signaling, plus de problèmes. En fin si, l'audio qui ne passe pas parfois :-)
[^] # Re: experience perso avec SIP sans TLS/ZRTP
Posté par tkr . Évalué à 3 (+1/-0).
Autre cas, un ingé français m'a démontré par capture tcpdump que gigaset ne respecte pas complètement le protocole SIP, sur les appels venants des autres opérateurs, à destination de son "gigaset.net" des tels fixes SIP.
# initiative
Posté par tkr . Évalué à 3 (+1/-0).
Un début d'idée pour "encourager" OVH à bouger sur le srtp/zrtp/tls ?
https://pytition.ethibox.fr/petition/user/tkr9/pour-obliger-les-fournisseurs-doffres-voiptoipsip-francaiseu-a-proposer-du-chiffrement-srtpzrtp
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.