Auteur Sujet: Utilisation d'un CISCO SPA112 pour la téléphonie VoIP de votre abonnement SFR (Lu 17674 fois)

jrobin28260 · « **le:** 15 février 2020 à 17:01:19 »

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 > Disabled
Optionnel, 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

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 Configuration

Preferred codec G711A

Ré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 !

jrobin28260 · « **Réponse #1 le:** 16 février 2020 à 01:42:54 »

Vos retours et améliorations sont les bienvenues, de même que si à l'avenir quelque chose mérite d'être ajouté/modifié dans mon message initial, j'autorise bien sûr les modérateurs à éditer.
Idem si SFR veut se distinguer et être parmi les premiers opérateurs à documenter ces choses officiellement, tout le monde ici sera ravi et il n'y a évidemment pas de souci à reprendre une partie du travail effectué ici.

Quelques petites touches facultatives concernant le SPA112 :

Les tonalités du SPA112 après une réinitialisation usine ne sont pas tout à fait celles que nous avions pris l'habitude d'entendre dans nos lignes françaises.
Voici quelques ajustements en provenance d'un SPA112 configuré par OVH en date de septembre 2023 :

Voice -> Regional -> Call Progress Tones

Code: [Sélectionner]

Dial Tone             : 440@-10;*(*/0/1)
Second Dial Tone      : 440@-10,330@-10;*(*/0/1+2)
Outside Dial Tone     : 440@-16;10(*/0/1)
Prompt Tone           : 440@-19,620@-19;*(*/0/1+2)
Busy Tone             : 440@-10;10(.5/.5/1)
Reorder Tone          : 440@-10;*(.5/.5/1)
Off Hook Warning Tone : 425@-10;*(.2/.2/1,.2/.6/1)
Ring Back Tone        : 440@-10;*(1.5/3.5/1)

Confirm Tone          : 440@-16;1(.25/.25/1)



Holding Tone          : 440@-20;*(.175/.175/1,.175/3.5/1)

Voice -> Regional -> Distinctive Ring Patterns

Code: [Sélectionner]

Ring1 Cadence : 2.25(.25/1.6);60(2/3.5)
Voice -> Regional -> Ring and Call Waiting Tone Spec

Ring Waveform : Sinusoid
Ring Voltage : 80

Pour ceux qui aimeraient jouer avec leur FAX, il faudra faire quelques essais, et peut-être utiliser ces paramètres ?

FAX Passthru Method : ReINVITE
FAX Passthru Codec : G711a

Voice -> Line 1 -> Dial Plan

Code: [Sélectionner]

(1[578]S0|11[259]S0|12[356]S0|1[06]xxS0|3xxxS0|11[68]xxxS0|00x.|0x.|2x.|7x.|90xxS0|**xx#|*xx#|#xx#|*xx*x.#|#xx*x.#|*941*xxxx*x.#|#94*xxxx*x.#|*61*x.*xx#|*61*x.*x#|*11*x.)

J'imagine que le but est ici que l'appel soit émit plus rapidement une fois qu'on a fini de composer le numéro (avec le réglage par défaut il faut attendre longtemps après avoir fini de composer le numéro, certainement parce que le SPA112 ne sait pas encore si on a fini de le taper).
-> TODO : essayer de déchiffrer ce Dial Plan, et vérifier qu'il n'y ait rien de spécifique à OVH dedans
-> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cata/19x/3PCC/english/admin-guide/at9x_b_ata191-192-admin-mp/at9x_b_ata191-192-admin-mp_chapter_011.html#reference_33B6863D421C2DA0440BAD73D1601D10

Voice -> Line 1 -> Audio Configuration
Preferred Codec : G711a (la version 'a' étant la version Europe et Afrique, la valeur par défaut en France c'est plutôt celle-ci donc).

Voice -> SIP -> NAT Support Parameters
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, voire 60 en cas de très petits nombres de paquets échangés.
Le SPA112 est configuré pour envoyer un paquet de "Keepalive" toutes les 15 secondes, finalement cette valeur est correcte (Wireguard conseille 25 secondes, OpenVPN 10 secondes...).

Règles NAT et désactivation des Keep Alives :
Cette variante est un peu moins "plug and play" mais il est possible de désactiver le Keep Alive, à condition d'aller dans les réglages de votre routeur pour ouvrir le port local d'émission (5060) en règle NAT vers le SPA112. Il resterait joignable depuis l’extérieur en permanence et sans restriction sur ce port. En contrepartie, dans Voice -> Line 1 -> SIP Settings, on peut passer l'option Restrict Source IP à YES pour que le SPA112 ne traite que les réponses du serveur auquel il s'est connecté.

Romain · « **Réponse #2 le:** 17 février 2020 à 15:24:43 »

Bonjour !

Merci beaucoup pour le travail accompli et pour le tutoriel !

Concernant la récupération des identifiants, ça ne fonctionnait pas chez moi tant que le tunnel IPv6 était activé sur mon routeur. Ça n'a fonctionné qu'en forçant IPv4. (Pour ma part j'ai simplement désactivé temporairement le tunnel sur mon routeur.) À préciser dans la rubrique "Récupération des identifiants" du tutoriel ?
L'auteur du logiciel m'a expliqué : "Leur serveur de provisioning a une IPv6 et il est possible qu'une des requêtes passe par le tunnel en v6."

Quoi qu'il en soit, j'ai essayé de connecter mon iPhone avec l'application Bria Mobile, sans succès. Les champs ne portent pas les mêmes noms, donc j'ai pu me tromper quelque part, et il manque certaines fonctions. Si quelqu'un y parvient, peut-il nous dire comment il a fait ?

jrobin28260 · « **Réponse #3 le:** 17 février 2020 à 18:05:44 »

Salut Romain !

En IPv6 les serveurs SIP de SFR semblent joignables (c'est encourageant), mais peut-être pas les identifiants donc. Comme j'avais récupéré mes identifiants par mon VPN IPv4 only (je n'étais pas chez moi mais j'ai triché), je ne m'étais pas rendu compte du souci lié à la récupération d'identifiants sous IPv6 (j'ai ajouté l'information que tu donnes ici).

J'ai également essayé depuis l'application "Téléphone" native d'Android sur un smartphone des plus génériques (Nokia 3.1, Android One 9.0)
Pour trouver cette fonctionnalité, Téléphone, 3 petits points, paramètres, compte téléphoniques.

Pour le débogage, OpenWRT sur Raspberry Pi4 (avec Gigabit Ethernet intégré en eth0 et Gigabit Ethernet USB3 en WAN en eth1, module "ax88179" à installer via opkg) permet de capturer eth0 et eth1 depuis la ligne de commande (tcpdump -i eth0 -w /tmp/fichier-en-ramdisk.pcap) ensuite il n'y a plus qu'a récupérer le fichier "pcap" et à l'ouvir sur Wireshark pour voir ce qui s'est passé : que du bonheur. N'hésites pas à regarder sur Synology si la même chose existe (tu peux même rejouer les conversations téléphones dans Wireshark).

Le client SIP d'Android a quelques problèmes :

Il ne sait pas résoudre residential.p-cscf.sfr.net : 5060 il faut donc lui donner trappes, mitry ou corbas sur 5062, qui ont plus de chances de changer à l'avenir
Le port d'émission local est choisi aléatoirement - c'est sensé être une qualité, mais dans ce cas précis, il faudrait ajouter ;transport=UDP dans les requêtes pour que le serveur de SFR nous prenne en charge correctement, or le client SIP natif d'Android ne le fait pas
L'entête contact vaut *, alors que le serveur de SFR tente de nous joindre précisément sur l'adresse définie dans Contact (pour ça qu'il faut y mettre notre véritable adresse externe, et utiliser les entêtes VIA ou les requêtes STUN pour connaitre cette adresse)
Je ne sais pas si c'est un problème, mais il manque Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER

En IPv6 :

Code: [Sélectionner]

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org SIP/2.0
Call-ID: 520618a3050eb81eb66721ca7ac6ea7c@IPv6-du-Smartphone
CSeq: 1655 REGISTER
From: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=1388042829
To: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>
Via: SIP/2.0/UDP [IPv6-du-Smartphone]:41296;branch=z9hG4bK5e0202b06ec02938a45d2c14fb50a981313333;rport
Max-Forwards: 70
User-Agent: SIPAUA/0.1.001
Contact: *
Expires: 0
Content-Length: 0

SIP/2.0 403 Forbidden
Call-ID: 520618a3050eb81eb66721ca7ac6ea7c@IPv6-du-Smartphone
Via: SIP/2.0/UDP [IPv6-du-Smartphone]:41296;received=IPv6-du-Smartphone;branch=z9hG4bK5e0202b06ec02938a45d2c14fb50a981313333;rport=41296
To: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=5e37ede7-5e49d257224013f1
From: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=1388042829
CSeq: 1655 REGISTER
Date: Sun, 16 Feb 2020 23:37:59 GMT
Server: Alcatel-Lucent-HPSS/3.0.3
Content-Length: 0

Essai en IPv4 only : même résultat

Code: [Sélectionner]

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org SIP/2.0
Call-ID: 89c22910a578c9134c1fef5f13a7a8ee@IPv4-Externe
CSeq: 126 REGISTER
From: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=1616902380
To: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>
Via: SIP/2.0/UDP IPv4-Externe:50393;branch=z9hG4bKaa5eca1cee3b1beb4fdd21ddcedf8bdd313333;rport
Max-Forwards: 70
User-Agent: SIPAUA/0.1.001
Contact: *
Expires: 0
Content-Length: 0

SIP/2.0 403 Forbidden
Call-ID: 89c22910a578c9134c1fef5f13a7a8ee@IPv4-Locale-Smartphone
Via: SIP/2.0/UDP IPv4-Locale-Smartphone:50393;received=IPv4-Externe-Smartphone;branch=z9hG4bKaa5eca1cee3b1beb4fdd21ddcedf8bdd313333;rport=50393
To: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=5e37ef5b-5e4a73f93108f4bb
From: "+33XXXXXXXXX" <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>;tag=1616902380
CSeq: 126 REGISTER
Date: Mon, 17 Feb 2020 11:07:37 GMT
Server: Alcatel-Lucent-HPSS/3.0.3
Content-Length: 0

Dans les deux cas, le serveur ne demande même pas au client SIP de s'authentifier : il se fait recaler direct.
J'utilise bien entendu le WiFi pour utiliser l'IP de mon abonnement SFR mais rien n'y fait : le client Android et le serveur SIP de SFR ne s'entendent pas (Alcatel-Lucent-HPSS/3.0.3 ça a pas l'air d'être hyper interopérable leur truc !)

Sur Zoiper ça marche sur PC mais sur Smartphone, pour une raison inconnue, il y a un bug :
A la réception d'appel, le client SIP est averti sur le lien avec le serveur SIP (requête "INVITE" contenant l'adresse IP et le port RTP à joindre pour démarrer la communication), le client se met donc au travail (démarrage des requêtes RTP vers le serveur demandé). Normalement le serveur qui reçoit les requêtes RTP commence rapidement à y répondre à son tour (en tout cas c'est ce qu'on constate sur PC), rendant la communication bidirectionnelle.

Sur Zoiper pour Android, cette dernière étape n'a pas lieu... les paquets RTP vont vers le serveur, mais celui-ci n'y répond pas. Comme la solution sur PC et Smartphone est grosso modo la même qui s'adresse au même serveur, c'est probablement une petite différence entre ce que demande Zoiper sur PC et Zoiper sur Android, mais je n'ai pas trouvé laquelle. Je vais essayer de zieuter ça, tiens...

Romain · « **Réponse #4 le:** 17 février 2020 à 18:10:30 »

Si quelqu'un comme toi ne parvient pas à configurer le client SIP natif d'Android, ce n'est pas moi qui vais y parvenir !

Mais j'ai un iPhone perso et un Google Pixel pro, donc je suis preneur de n'importe quelle solution pour l'un ou pour l'autre, si quelqu'un y arrive

jrobin28260 · « **Réponse #5 le:** 17 février 2020 à 21:13:53 »

Pour Zoiper sur Android il y a quelques problèmes, même en corrigeant le premier ça ne marche pas bien du tout.

Commençons par sa qualité : il demande explicitement transport=UDP dans ses requêtes, du coup le serveur SIP de SFR parvient à toujours le contacter. Dans le cas contraire, il aurait fallu fixer le port d’émission à 5060 mais Zoiper propose aussi de le faire, du coup là dessus, pas de souci.

En revanche, Zoiper n'utilise pas les entêtes "VIA" du coup pour connaitre l'IP externe il est obligé d'utiliser STUN.
En regardant de plus près ce qui n'allait pas sur Zoiper version Android, je me suis rendu compte que l'utilisation du serveur STUN était activée par défaut sous Windows, mais pas sur Zoiper sous Android (sans connaissance de l'adresse IP externe, il demandait donc au serveur SIP de nous contacter sur l'IPv4 locale - ce qui ne fonctionne pas sur le serveur SIP SFR, qui semble obéir texto à ce qu'on met dans l'entête "Contact"). Dans les paramètres avancés du compte, on peut activer STUN -> Problème résolu.

Un autre souci c'est que ça a parfois du mal à se connecter, ça fait un manège compliqué pour rien et parfois le serveur dit "Interval too brief", Zoiper insiste, et c'est bloqué pendant plusieurs dizaines de secondes.

Demande de REGISTER (en 4 étapes) avec expires=300 :

Code: [Sélectionner]

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0
Via: SIP/2.0/UDP IPv4-LOCALE:51035;branch=z9hG4bK-524287-1---5736e5ea50e502a8;rport
Max-Forwards: 70
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=e8852edd3f788bcf;transport=UDP>
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=6334495a
Call-ID: R7dsi-7BZfORC6S-C9gd0g..
CSeq: 2 REGISTER
Expires: 300
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rv2.10.6.2
Allow-Events: presence, kpml, talk
Content-Length: 0

SIP/2.0 401 Unauthorized
Call-ID: R7dsi-7BZfORC6S-C9gd0g..
Via: SIP/2.0/UDP IPv4-LOCALE:51035;received=IPv4-EXTERNE;branch=z9hG4bK-524287-1---5736e5ea50e502a8;rport=51035
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=udp>;tag=5e3899ba-5e4ae22b216b7ebc
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=6334495a
CSeq: 2 REGISTER
Date: Mon, 17 Feb 2020 18:57:47 GMT
Server: Alcatel-Lucent-HPSS/3.0.3
WWW-Authenticate: Digest realm="sfr.fr",
   nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
   opaque="ALU:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
   algorithm=MD5,
   qop="auth"
Content-Length: 0

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0
Via: SIP/2.0/UDP IPv4-LOCALE:51035;branch=z9hG4bK-524287-1---9372088580172c86;rport
Max-Forwards: 70
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=e8852edd3f788bcf;transport=UDP>
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=6334495a
Call-ID: R7dsi-7BZfORC6S-C9gd0g..
CSeq: 3 REGISTER
Expires: 300
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rv2.10.6.2
Authorization: Digest username="NDI0XXXXXXXXX.CTR.THD@sfr.fr",realm="sfr.fr",nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",uri="sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP",response="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",cnonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",nc=00000001,qop=auth,algorithm=MD5,opaque="ALU:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Allow-Events: presence, kpml, talk
Content-Length: 0

SIP/2.0 200 OK
Call-ID: R7dsi-7BZfORC6S-C9gd0g..
Via: SIP/2.0/UDP IPv4-LOCALE:51035;received=IPv4-EXTERNE;branch=z9hG4bK-524287-1---9372088580172c86;rport=51035
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=udp>;tag=5e3899ba-5e4ae22b2b878059
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=6334495a
CSeq: 3 REGISTER
Allow-Events: reg
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=e8852edd3f788bcf;transport=udp>;expires=300
Date: Mon, 17 Feb 2020 18:57:47 GMT
Path: <sip:pcgw-0006.imsgroup0-002.cor1isc11.ims.sfr.net:5062;lr;ottag=ue_term;bidx=17751257;access-type=ADSL>
P-Associated-URI: Main <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>
P-Associated-URI: Alias <tel:+33XXXXXXXXX>
Server: Alcatel-Lucent-HPSS/3.0.3
Content-Length: 0

Aussitôt suivi d'une demande de REGISTER en 2 étapes avec expires=0 :

Code: [Sélectionner]

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0
Via: SIP/2.0/UDP IPv4-LOCALE:51035;branch=z9hG4bK-524287-1---af8ae5a197055355;rport
Max-Forwards: 70
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=e8852edd3f788bcf;transport=udp>;expires=0
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=6334495a
Call-ID: R7dsi-7BZfORC6S-C9gd0g..
CSeq: 4 REGISTER
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rv2.10.6.2
Authorization: Digest username="NDI0XXXXXXXXX.CTR.THD@sfr.fr",realm="sfr.fr",nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",uri="sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP",response="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",cnonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",nc=00000002,qop=auth,algorithm=MD5,opaque="ALU:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Allow-Events: presence, kpml, talk
Content-Length: 0

SIP/2.0 200 OK
Call-ID: R7dsi-7BZfORC6S-C9gd0g..
Via: SIP/2.0/UDP IPv4-LOCALE:51035;received=IPv4-EXTERNE;branch=z9hG4bK-524287-1---af8ae5a197055355;rport=51035
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=udp>;tag=5e3899ba-5e4ae22b32382092
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=6334495a
CSeq: 4 REGISTER
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=e8852edd3f788bcf;transport=udp>;expires=0
Date: Mon, 17 Feb 2020 18:57:47 GMT
Path: <sip:pcgw-0006.imsgroup0-002.cor1isc11.ims.sfr.net:5062;lr;ottag=ue_term;bidx=17751257;access-type=ADSL>
P-Associated-URI: Main <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>
P-Associated-URI: Alias <tel:+33XXXXXXXXX>
Server: Alcatel-Lucent-HPSS/3.0.3
Content-Length: 0

C'est un UNREGISTER qui vient d'être fait donc.
Aussitôt suivie d'une demande de REGISTER en 4 étapes avec expires=Valeur réglable dans les paramètres réseau du compte sur Zoiper :

Code: [Sélectionner]

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0
Via: SIP/2.0/UDP IPv4-LOCALE:51035;branch=z9hG4bK-524287-1---d25fa6aaf514ad83;rport
Max-Forwards: 70
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=66010853744c4104;transport=UDP>
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=e368ac11
Call-ID: oT8FgUUY04eD4GlfDw4lPQ..
CSeq: 1 REGISTER
Expires: 300
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rv2.10.6.2
Allow-Events: presence, kpml, talk
Content-Length: 0

SIP/2.0 401 Unauthorized
Call-ID: oT8FgUUY04eD4GlfDw4lPQ..
Via: SIP/2.0/UDP IPv4-LOCALE:51035;received=IPv4-EXTERNE;branch=z9hG4bK-524287-1---d25fa6aaf514ad83;rport=51035
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=udp>;tag=5e28d6ff-5e4ae22c2956a7c
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=e368ac11
CSeq: 1 REGISTER
Date: Mon, 17 Feb 2020 18:57:48 GMT
Server: Alcatel-Lucent-HPSS/3.0.3
WWW-Authenticate: Digest realm="sfr.fr",
   nonce="11111111111111111111111111111",
   opaque="ALU:QbkRBthOEgEQAkgFAQ0NW0YPAhxeGQIRQkVbHxoLVwknMG0qIDJ9fXlze3c1Yy42OG9h",
   algorithm=MD5,
   qop="auth"
Content-Length: 0

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0
Via: SIP/2.0/UDP IPv4-LOCALE:51035;branch=z9hG4bK-524287-1---1c8fec625ca91972;rport
Max-Forwards: 70
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=66010853744c4104;transport=UDP>
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=e368ac11
Call-ID: oT8FgUUY04eD4GlfDw4lPQ..
CSeq: 2 REGISTER
Expires: 300
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rv2.10.6.2
Authorization: Digest username="NDI0XXXXXXXXX.CTR.THD@sfr.fr",realm="sfr.fr",nonce="11111111111111111111111111111",uri="sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP",response="xxxxxxxxxxxxxxxxxxxxxxxxx",cnonce="xxxxxxxxxxxxxxxxxxxxxxxx",nc=00000001,qop=auth,algorithm=MD5,opaque="ALU:xxxxxxxxxxxxxxxxxxxxxxxx"
Allow-Events: presence, kpml, talk
Content-Length: 0

SIP/2.0 200 OK
Call-ID: oT8FgUUY04eD4GlfDw4lPQ..
Via: SIP/2.0/UDP IPv4-LOCALE:51035;received=IPv4-EXTERNE;branch=z9hG4bK-524287-1---1c8fec625ca91972;rport=51035
To: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=udp>;tag=5e28d6ff-5e4ae22cfa186ff
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=e368ac11
CSeq: 2 REGISTER
Allow-Events: reg
Contact: <sip:+33XXXXXXXXX@IPv4-EXTERNE:51035;rinstance=66010853744c4104;transport=udp>;expires=300
Date: Mon, 17 Feb 2020 18:57:48 GMT
Path: <sip:pcgw-0006.imsgroup0-002.cor1isc11.ims.sfr.net:5062;lr;ottag=ue_term;bidx=17751263;access-type=ADSL>
P-Associated-URI: Main <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org>
P-Associated-URI: Alias <tel:+33XXXXXXXXX>
Server: Alcatel-Lucent-HPSS/3.0.3
Content-Length: 0

Même en mettant la valeur d'expiration à 300 il fait tout ce remue ménage quand même... et donc parfois il se fait jeter par le serveur avec message "Interval too brief", c'est alors qu'il se met à insister en boucle en envoyant une requête "REGISTER" toutes les 2 secondes (moi je sais pas vous, mais j'appelle ça du SPAM).

Troisième problème : lorsqu'un appel est passé avec succès, si on raccroche depuis Zoiper, le correspondant n'est pas prévenu que ça a raccroché (l'appel n'est pas correctement coupé).
Sous Wireshark j'ai trouvé le problème : Au moment de raccrocher depuis Zoiper, il faudrait envoyer le message SIP "Bye" au serveur SIP, or ce message n'est pas envoyé; à la place Zoiper finit d'envoyer son stream RTP via un paquet RTCP intitulé Goodbye, mais le serveur de communication RTP continue de nous envoyer son flux RTP indéfiniment.

Cela semble donc être une incompatibilité... Il faudrait pouvoir choisir la méthode de "fin d'appel" dans Zoiper, or je ne l'ai pas trouvé - et Zoiper utilise bien entendu la mauvaise (sinon c'est pas drôle).

Quatrième problème : Je n'ai pas encore compris pourquoi, certainement un problème de messages SIP du même genre que le précédent
Lorsque Zoiper reçoit un appel, et décroche, le stream RTP devient actif dans les deux direction (on peut parler et s'entendre), mais la communication n'est pas considérée comme "commencée" par le correspondant (et elle finit par se couper tel un appel qui n'aurait pas abouti). Je suppose que Zoiper se contente d'envoyer le flux RTP, sans signaler qu'il démarre la conversation au serveur SIP.
Mais ça ne me l'a pas fait à chaque fois...

Bref, Zoiper c'est assez mauvais sur ce coup.
Mais pour ceux qui aiment zieuter Wireshark et qui veulent jeter des coups d’œil à d'autres logiciels, voilà la méthode !

nextgens · « **Réponse #6 le:** 18 février 2020 à 10:41:48 »

Tous vos problèmes ont deux causes:

1) la translation d'addresse -> la solution c'est de faire tourner un proxy sip (siproxd par example) sur le routeur et d'y connecter votre client
2) le fait que pour les appels entrant la communication arrive toujours en TCP (même si votre client a fait un enregistrement en UDP). La aussi, la solution simple c'est siproxd qui permettra aux clients qui ne font que de l'UDP de fonctionner (y compris le client Android).

jrobin28260 · « **Réponse #7 le:** 18 février 2020 à 14:13:13 »

Salut Nextgens !

Effectivement, j'avais totalement oublié cette possibilité à force de l'écarter.
Pour ceux qui ne trouveront pas de clients SIP suffisamment bien ficelés pour communiquer correctement en direct avec le serveur SIP de SFR, les plus déterminés d'entre vous vont peut-être devoir se coller à l'installation et la configuration de siproxd dans leur routeur en intermédiaire entre le serveur SIP et leur client SIP.
maximushugus a fait un tutoriel pour ~~siproxd~~ (EDIT/correction : Asterisk, même si je suppose que le principe est le même) sur OpenWRT https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/

Du fait que les abonnements SIP vendus par OVH EverLink et autres utilisent des serveur bien réglés, qui peuvent se débrouiller sans intermédiaires ni réglage complexe, et ce avec à peu près tous les clients SIP existants (le serveur répond à l'envoyeur peu importe ce qu'il y a dans les entêtes, keepalive envoyés par le serveur lui même etc : tout fonctionne sans réglage), j'ai rapidement appris à éviter l'installation de cette machinerie supplémentaire. Du fait aussi que siproxd n'était pas forcément installable dans les Livebox/Freebox/etc et autres boites noires que j'ai un temps utilisé, ça m'a également poussé à toujours faire sans.

Et puis dans l'idée c'est un peu comme installer un youtbproxd, netflixproxd etc pour accéder à un service en ligne (le tout à configurer/déboguer soi même en lignes de commandes), j'ai tout de suite eu du mal avec cette idée... Mais il est vrai que pour le serveur SIP très pointilleux de SFR, et l'interopérabilité désastreuse de certains clients SIP, à moins de trouver une appli smartphone capable de s'adresser correctement au serveur SIP de SFR, ajouter cet intermédiaire dont le but ici est la correction d'une interopérabilité que nombre de développeurs SIP ont échoué à obtenir, va certainement être une solution à envisager.

Merci pour le conseil, et puis merci au nom de tout ceux à qui ça va rendre service

Asclèpios · « **Réponse #8 le:** 13 mars 2020 à 02:12:26 »

Pour ma part j'ai essayé avec un Gigaset C530H j'ai l'inscription OK, emission d'appel OK mais audio KO des idées ?

Merci à tous pour vos tutoriel et votre aide !

jrobin28260 · « **Réponse #9 le:** 13 mars 2020 à 11:25:55 »

Salut Asclèpios,

Le fait que l'enregistrement fonctionne et que les appels soient établis semble indiquer que la connexion au serveur en SIP est bonne, mais s'il n'y a pas d'audio, que les connexions de données (en RTP, négociées via le protocole SIP) ne se font pas correctement

D'expérience, cela peut se produire avec le serveur de SFR quand on n'utilise ni "STUN" ni les entêtes "VIA", deux moyens techniques différents (souvent proposés dans les clients SIP), qui sont une sorte de "What is My External IP". Leur but étant que lors de l'enregistrement, dans l'entête "Contact" envoyé par le client SIP, celui-ci demandera au serveur de travailler avec notre véritable adresse IP externe (celle avec laquelle il pourra nous joindre) et non avec une adresse IP de notre réseau local (que le serveur ne pourra pas joindre). Pour les transferts de voix en RTP, sur le serveur utilisé par SFR, cette entête "Contact" est importante.

N'hésites pas à jeter un coup d'oeil à ça, et à nous dire si ça a fonctionné : nul doute que quelqu'un qui aura le même appareil que toi et qui aura le même problème finira par tomber ici :p

Asclèpios · « **Réponse #10 le:** 13 mars 2020 à 11:37:52 »

Bonjour, et merci de ce début de piste ... cependant comment puis-je vérifier que cette ente s’affiche ? Et comment vérifier qu’il travail bien avec mon ip public, pour info j’ai ouvert un sujet spécifique avec les capture d’écran de mon appareil

Asclèpios · « **Réponse #11 le:** 13 mars 2020 à 19:46:13 »

Merci de la réponse sur le sujet dédié