Pour ceux d'entre vous qui utilisent du matériel standard avec leur abonnement SFR, et qui voudraient utiliser un Cisco SPA112 pour utiliser l'abonnement téléphonique VoIP/SIP inclus dans votre offre.
Voici les paramètres à renseigner dans l'interface. Tout y est, avec les explications.
Tutoriel mis à jour le 05 octobre 2023
-------------------------------------------
IMPORTANT ! Avant de commencer, à propos des IPv4 dites "CGNAT" : connexion directe devenue impossible en IPv4
Si vous ne possédez plus d'adresse IPv4 dédiée, en date d'octobre 2023, vous ne pouvez plus établir de connexion IPv4 aux serveurs SIP de SFR.
En effet, les connexions UDP en IPv4 vers les serveurs SIP de SFR semblent se perdre en chemin (ou alors c'est leur réponse qui se perd, ou alors c'est le serveur SIP qui refuse de répondre), mais dans les 3 cas, ça ne fonctionne plus.
Les connexions TCP/IP vers ces mêmes serveurs peuvent quant à elles s'établir, mais malgré ça, le serveur tente ensuite de signaler les appels entrants en envoyant des messages en UDP (qui ne seront pas acheminés non plus en cas d'IPv4 CGNAT). Même quand ces messages UDP sont acheminés jusqu'au SPA112, si la connexion a été faite en TCP/IP, le SPA112 ignore alors ces messages UDP.
A cette date (Octobre 2023), en cas d'IPv4 CGNAT vous êtes donc forcés d'utiliser IPv6 pour joindre les serveurs SIP.
J'imagine que cette désactivation de prise en charge en IPv4 partagée est justifiée, du fait que les ports d'émission choisis et annoncés par client SIP (à la fois pour la connexion SIP et les flux audio RTP) ne sont plus garantis d'être libres (car potentiellement déjà utilisés par d'autres utilisateurs de l'adresse IPv4 partagée, le CGNAT ayant alors tendance à en mapper un autre de façon imprévisible), ce qui risquait de faire échouer des appels (en signalant envoyer le flux RTP depuis un port finalement déjà utilisé pour quelqu'un d'autre par le CGNAT).
Malheureusement le SPA112 n'étant pas compatible IPv6 et son support ayant été arrêté par Cisco, c'est la fin de l'aventure pour lui si vous êtes dans ce cas (ou alors il vous faudrait utiliser un système de proxy relai intermédiaire, semblerait que ce soit possible).
Etant passé en IPv4 CGNAT sur l'une de mes connexions SFR RED, je me suis procuré un ATA191 (le remplaçant du SPA112) pour refaire tous ces essais et créer une variante IPv6 à jour de ce tutoriel.
-------------------------------------------
Network Setup > Advanced Settings > CDP & LLDP- Enable CDP: Disabled
- Enable LLDP-MED: Disabled
- Layer 2 Logging: Disabled
Optionnel mais si vous n'utilisez pas ces fonctionnalités, en cas d'analyse Wireshark c'est du bazar en moins.
Administration > Management > Bonjour > DisabledOptionnel, idem.
Administration > Management > User List- Optionnel. Remplacez le mot de passe "admin" (admin par défaut) avec attention (soyez sur de pouvoir le retrouver dans 3 ans !) sinon c'est Reset Button.
- Il est également possible de remplacer le mot de passe "cisco" (cisco par défaut)
Voice -> SIP -> NAT Support Parameters- Handle VIA received : YES
- Handle VIA rport : YES
On en a besoin pour l'étape suivante.
Ce réglage permet au SPA112 de lire votre adresse IP+Port externe d’émission vu du serveur SIP (en lisant les entêtes "via" dans ses réponses).
Ainsi, pas la peine d'utiliser un serveur STUN à côté (un serveur STUN c'est un "what is my ip", en gros, mais grâce au entêtes VIA le travail est déjà fait).
Voice -> Line 1 -> NAT Settings- NAT Mapping Enable : YES
- NAT Keep Alive Enable : YES
- 2 Possibilités : version 2020
- NAT Keep Alive Msg : $REGISTER (le serveur SIP de SFR n'aime pas le message $NOTIFY, ça renvoie des erreurs et ça fait buguer les appels)
- NAT Keep Alive Dest: $PROXY
- Ou alors version 2023
- NAT Keep Alive Msg : $NOTIFY (le serveur SIP de SFR accepte finalement les messages "NOTIFY / Event: keep-alive", mais à condition de bien régler le paramètre suivant !)
- NAT Keep Alive Dest: ims.mnc010.mcc208.3gppnetwork.org (c'est la valeur de la case "Proxy" plus bas - on la recopie ici car quand il y avait la valeur $PROXY, c'était le "Outbound Proxy" qui était utilisé dans le message, et ce n'était pas bon).
NAT Mapping Enable permet au SPA112 de demander à être contacté sur l'adresse IP:Port externe avec lequel le serveur nous voit (ça le place dans l'entête "Contact" lors de l'enregistrement)
En effet certains serveurs SIP vont prendre l'entête SIP "Contact" au pied de la lettre quand il faudra annoncer un appel entrant par exemple.
Si on est derrière un NAT il est donc judicieux d'activer ces options afin de demander au serveur SIP de continuer d'utiliser l'adresse/port qu'il utilise déjà pour communiquer avec nous.
NAT Keep Alive Enable permet, en l'absence de redirection de port exposant le SPA112 depuis l'extérieur en continu, de garder la connexion active entre lui et le serveur SIP.
Sans cette option, et en l'absence d'appels, votre routeur pourrait rapidement penser que la connexion est terminée, et cesser de rediriger les messages en provenance du serveur SIP vers votre SPA112 (vous perdriez des appels entrants)
Voice -> Line 1 -> SIP Settings- SIP Transport : UDP
- SIP Port : 5060 (c'est le port d'émission UDP des messages depuis le Cisco SPA112
Mise à jour en date d'Octobre 2023 : utiliser un autre port ne pose plus problème; il y a quelques années, utiliser un autre port faisait basculer les messages du serveur SIP en TCP/IP
En cas de réglage de "SIP Transport" sur TCP, ce sont les champs SIP TCP Port Min et Max qui seront utilisés pour définir le port d'émission. Mais pour rappel en date d'Octobre 2023 les connexions TCP/IP au serveur SIP de SFR fonctionnent mais les appels restent signalés en UDP donc pas le choix, il faut être en UDP).
Voice > SIP > SIP Timer Values (sec)- Reg Retry Intvl: 30 (OPTIONNEL - en l'absence de réponse du serveur, le SPA112 attend 30 secondes avant de ré-essayer)
- Reg Retry Long Intvl: 75 (OPTIONNEL - en cas de refus du serveur, ou de serveur injoignable - erreur réseau ou coupure Internet temporaire par exemple, ça permet de ré-essayer avant les 20 minutes par défaut)
Voice > SIP > RTP Parameters > RTP- RTP Packet Size: 0.020 (valeur utilisée pour les appels par le serveur SFR, et valeur par défaut sur les NB6VAC en 2023 - 10)
Voice -> Line 1 -> Proxy and Registration- Proxy : ims.mnc010.mcc208.3gppnetwork.org (souvent appelé hostname ou domaine)
- Première variante (réglage analogue à celui utilisé par la Box SFR) :
- Outbound Proxy : residential.p-cscf.sfr.net (souvent appelé proxy)
- Use Outbound Proxy : YES (sinon il ignore la ligne précédente)
- Use DNS SRV : YES (obligatoire pour la résolution DNS de residential.p-cscf.sfr.net, qui est un enregistrement de type "SRV")
- DNS SRV Auto Prefix : YES (car residential.p-cscf.sfr.net n'existe pas, il faut ajouter un préfixe "_sip._udp" devant)
- Deuxième variante (si vous voulez choisir vous même le serveur le plus proche de chez vous parmi ceux disponibles en Octobre 2023) :
- Outbound Proxy : mitry.p-cscf.sfr.net:5062 / trappes.p-cscf.sfr.net:5062 / corbas.p-cscf.sfr.net:5062
- Use Outbound Proxy : YES (sinon il ignore la ligne précédente)
- Use DNS SRV : NO
- DNS SRV Auto Prefix : NO
Dans la 2ème variante précisez bien le ":5062" à la fin de l'adresse du Outbound Proxy, car sur le port 5060 les enregistrement échouent.
Voice -> Line 1 -> Subscriber Information- Display Name : +33XXXXXXXXX (nom d'usage présenté lors des appels sortants, ne semble pas obligatoire car Zoiper ne l'utilise pas, par exemple)
- User ID : +33XXXXXXXXX (utilisé dans à peu près toutes les entêtes SIP)
- Password : XXXXXXXXXXXXXXXX (sera utilisé lors de l'authentification après du serveur SIP, à l'enregistrement)
- Auth ID : NDI0XXXXXXXXX.CTR.THD@sfr.fr (sera utilisé lors de l'authentification après du serveur SIP, à l'enregistrement)
- Use Auth ID : YES (sinon il ignore la ligne précédente)
Voice > Line 1 > Audio ConfigurationRécupération des identifiants :SFR met à disposition un serveur pour que nos BOX viennent récupérer toutes seules et automatiquement leurs identifiants (celles-ci interrogent le serveur, prennent leurs identifiants, puis se connectent en SIP avec).
Malheureusement en parallèle de ça, les identifiants ne sont pas envoyés par mail (ni même disponibles sur l'espace abonné) comme à la vieille époque où tout le monde avait besoin de ces informations, mais un logiciel créé par l'utilisateur "nextgens" (qu'on remercie chaleureusement) existe pour compenser ce manque :
https://florent.daigniere.com/posts/2019/04/extracting-voip-credentials-from-my-broadband-router/Attention, "extract-voip-parameters_v1.exe" ne fonctionne que lorsqu'on a déjà remplacé le routeur SFR par du matériel standard (probablement du fait que le serveur ne donne accès aux identifiants que quand ils ne sont pas déjà en cours d'utilisation, par la box par exemple).
Attention 2, Romain nous signale qu'en IPv6, la récupération des identifiant peut échouer - auquel cas, vous pouvez désactiver l'IPv6 temporairement (sur le WAN dans votre routeur, ou dans les propriétés réseau de votre OS).
Troubleshooting :La VoIP SIP est une technologie complexe (mais au moins, c'est une science, qu'on peut comprendre et paramétrer).
C'est une technologie que les ingénieurs spécialisés en téléphonie IP ont passé du temps à apprendre - après tous ces efforts, certains n'ont pas spécialement envie de la voir être remplacée par autre chose (et de devoir tout réapprendre).
Mais c'est un tort : en contre partie de sa flexibilité, cette technologie est infâme de complexité et de caprices. Il faudrait vraiment la remplacer par quelque chose de plus simple. D'ici là, faisons avec.
Émission/Réception d'appels impossibles :TCP/UDP :En date d'Octobre 2023, en cas d'utilisation du protocole TCP/IP au lieu de UDP, le SPA112 parvient à établir la connexion SIP, et ajoute bien "transport=tcp" dans le champs "Contact" des messages qu'il envoie au serveur SIP, pourtant quel que soit le port d'émission utilisé, le serveur SIP continue de chercher à signaler les appels entrants via UDP. On est donc contraint d'utiliser UDP.
Keep-alives :La valeur de 150 secondes que j'ai conseillée en 2020 ne passe finalement pas partout ! (Erreur du tutoriel de 2020 donc, toutes mes excuses)
NAT Keep Alive Intvl : Sur OpenWrt 23.05.0-rc3, la durée de fermeture d'une connexion UDP sans activité est de 180 secondes pour les flux UDP à paquets nombreux, voire 60 en cas de très petits nombres de paquets échangés - ce qui est parfois le cas pour SIP.
Le SPA112 est par défaut configuré pour envoyer un paquet de "Keepalive" toutes les 15 secondes, finalement cette valeur est correcte (Wireguard conseille 25 secondes, OpenVPN 10 secondes...).
RTP Port Min et Max, et règle NAT pour la plage RTP vers le SPA112 La valeur par défaut du SPA112 (16384 à 16482) permet au SPA112, à chaque appel (entrant ou sortant), de sélectionner un port d'émission RTP ayant assez peu de chances d'être déjà utilisé par votre routeur IPv4 / NAT. Le port que le SPA112 va choisir sera également communiqué au serveur SIP pour que ce dernier y envoie les données voix. Si le port RTP choisi par le SPA112 est déjà en cours d'utilisation par votre NAT, les données voix échoueront à être transmises.
Si vous êtes embêtés avec ça, vous pouvez toujours essayer de réserver cette plage de port en règle NAT / Port Forwarding UDP depuis votre routeur.
Pour info / pour les curieux, en Octobre 2023, la box SFR utilise quant à elle la plage 35500 - 35599 pour ses flux RTP audio.
Règle NAT pour SIP UDP vers le SPA112 ? Mon conseil : non, utilisez le mécanisme de keep alive. Toutes les connexions sont initiées par le SPA112 (oui, même les appels entrants).
Autant que le SPA112 reste à l'abri des attaques, floods, etc.
Lorsqu'un appel arrive, la communication précédemment établie par le SPA112 avec le serveur SIP, est utilisée pour prévenir le SPA112, qui établit alors la communication RTP avec le serveur de voix.
Le SPA112 n'a donc pas vraiment besoin d'être joignable à distance : c'est lui qui établit toutes les communications vers les serveurs, qui peuvent alors lui répondre et le solliciter en cas d'appel.
Codec : Le SPA112 a tendance à préférer G711u (PCMU) alors que SFR a tendance à préférer G711a (PCMA). Du coup les appels se font en G711a (PCMA).
Lors des signalements d'appels sortants/entrants, les préférences et compatibilités de codec sont échangées avec le serveur, et les deux se mettent d'accord de façon automatique.
Voilà, j'espère que le paquet d'heure qu'on a passé avec un ami à faire le tour de ce sujet assez costaud saura aider d'autres personnes !