La Fibre
Datacenter et équipements réseaux => Routeurs => 
Téléphonie VoIP / SIP => Discussion démarrée par: 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
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 Configuration
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 !
-
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
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
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
(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é.
-
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 ? :)
-
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 :
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
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...
-
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 :)
-
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 :
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 :
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 :
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 !
-
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).
-
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
-
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 !
-
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
-
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
-
Merci de la réponse sur le sujet dédié
-
Bonjour, j'ai de nouveau des problème avec la configuration d'un Yealink W60 ... (voir sujet dédié) je ne vois pas les options de configuration nécessaire comme sur le Gigaset C530IP
-
J'ai suivi ce super tuto mais j'ai un problème. Je peux appeler ( donc je suis bien enregistrer sur la ligne) mais je ne reçois pas les appels.
Merci de votre aide.
-
Bonjour Jrobin,
Merçi beaucoup pour votre temps d'analyse et le partage de votre parcours. :)
Mois, je suis chez RED FTTH et je viens d'installer un NG R7000 (FreshTomato) pour remplacer le NB6VAC et ça marche ...un peu moins pour le débit fibre mais ça marche et pour l'instant beaucoup plus stable que le NB6VAC qui déconnectais avec tout download de taille majeur.
Avec le SPA112 je peut maintenant aussi appeler...encore un grand merçi (aussi a Florent pour le truc d'identifiants)
D'abord, c'est fou qu'il faut (?!) dépenser env. 180EUR pour remplacer le materiel mi-qualité du fournisseur.
-
Bonjour,
Je n'arrive pas à récupérer les identifiants via le script.
J'ai un Edgemax : ER12 l'IPV6 est désactivé, mais dès que je lance le script la fenêtre ce ferme immédiatement.
-
il faut l'executer d'une fenêtre decommande ( 'cmd' )
-
Pareil, la fenêtre se referme.
Avant d'avoir changé mon routeur, avec le routeur SFR direct, la cmd restée affichée, mais rien ne se passe, normal puisqu'il faut changer le routeur pour que le script fonctionne, mais maintenant une fois changé voilà mon souci ;-)
-
En détail ce que j'ai fait:
- le routeur connecté WAN avec le réseau SFR (chez moi)
- j'ai utilisé un laptop windows 10 qui n'appartient pas à mon entreprise (car son antivirus a immediatement effacé l'outil)
- le laptop était directement wifi-connecté avec le routeur (même subnet 192.168.1.xyz)
- j'ai stocké 'extract-voip-parameters_v1.exe' dans c:\temp
- j'a lancé 'cmd' et changé pour c:\temp
- j'ai executé 'extract-voip-parameters_v1.exe' et l'ecran m'a fourni les détails
-
J'ai fait comme toi mais pareil toujours la fenêtre qui disparaît.
-
Ajouter l'équivalent d'un "pause" à la fin du script.
-
Ajouter l'équivalent d'un "pause" à la fin du script.
Que entend tu par mettre une pause.
J'ai tenté un .bat
cd c:/temp
start extract-voip-parameters_v1.exe
pause
Mais vue que c'est un .exe il ouvre une seconde fenêtre et la referme aussitôt...
-
Le plus simple d'ouvrir un invité de commande (WIN^r cmd)... et de faire un drag&drop de l'executable dessus
-
Que entend tu par mettre une pause.
J'ai tenté un .bat
Mais vue que c'est un .exe il ouvre une seconde fenêtre et la referme aussitôt...
C'est le "start" qui ouvre une seconde fenêtre... essaies sans.
-
Et bien super !!! ça fonctionne
-drag&drop
-2 fois un appuie sur entrée et j'ai bien les paramètres !
MERCI !
Je vais finir mon paramétrage et voir si ça marche :-)
edit : Voilà tout fonctionne avec le C530IP, un grand merci à tous pour votre tuto !
-
J'ai suivi le paramétrage à la lettre et tout semble fonctionner, sauf que parfois je reçois les appels mais je n'entends pas l'interlocuteur alors qu'il m'entend bien. Vous avez une idée ? ???
-
Oui, un problème de NAT... la seule solution qui fonctionne bien c'est un proxy SIP (siproxd)
-
J'ai le même souci, je viens de tout paramétrer. Lorsque j'appelle tout fonctionne bien.
Mais lorsque je reçois un appel, une fois sur 2 mon interlocuteur ne m'entend pas, alors que moi je l'entend.
Est ce qu'on peut changer un paramètre dans le SPA112 pour corriger ce problème ?
Merci
-
J'ai abandonné, cela vient du routeur qui bloque les appels entrants pour mon cas et sortants pour toi à priori. Je me suis résigné à rebrancher ma box devant le routeur et le téléphone sur la box :-\
-
J'utilise un routeur synology. J'ai ouvert le port udp 5600 mais ça n'a rien changé. J'ai pas envie de remettre la box sfr pour si peu... Surtout que j'utilise peu le téléphone fixe. Mais si qqn a un tuyau je suis preneur :)
-
Bonjour,
je viens de passer sur un routeur RT2600ac et jusqu'ici tout semble fonctionner au mieux. Cependant, en essayant de récuperer mes identifiants pour le téléphone IP, l'execution de la commande './extract-voip-parameters_v1' sous linux mint 19.3 me revoie l'erreur suivante :
panic: This program only work from an SFR/RED line with the ISP supplied DNS servers configured as local resolvers.
Je n'ai rien changé coté dns sur le RT2600ac et le dns indiqué dans la conf est 109.0.66.10, ce qui semble correct. J'ai aussi désactivé ipv6 partout.
Une idée de l'origine de l'erreur ?
Merci
-
En fait, je viens de reussir en executant directement sur mon synology. Sans doute un pb de conf reseau sur mon linux
-
Bonjour,
j'ai acheté un SP1112 et configuré comme indiqué.
J'arrive bien a recevoir des appels mais pour les appels que j'emet, la communication coupe systematiquement au bout de 32 secondes...
Pour l'instant, j'ai encore la box RED / SFR qui est branchée au réseau. Une idée ?
-
Bonjour,
merci a tous pour les efforts fournis sur ce forum.
Je suis chez RED en ADSL ::) et dés J1 j'ai remplacé la box par un modem routeur ASUS qui fait un excellent job pour internet.
depuis peu je m'interesse à la voip et j'aimerais récuperer mes identifiants voip de chez sfr, je me suis equipé d'un cisco SPA122 pour l'occasion.
Voici le problème: étant sur une ligne adsl le script de @nextgens se termine avec
panic: Get : unsupported protocol scheme ""
goroutine 1 [running]:
main.main()
/home/nextgens/boxsfr/fibre/voip/getconf/getconf.go:116 +0xe7b
ce qui est apparemment normal vu que le script est prévu pour fonctionner en FTTH.
La question est donc: y-a t-il moyen de récuperer les identifiants voip en étant sur une ligne adsl soit par le script de @nextgens ou par un autre moyen?
mon tout nouveau SPA122 n'attend que ça..
merci d'avance!
-
Salut,
J'en sais rien. Installes wireshark et envoies moi le contenu du fichier XML récupéré sur general.neufbox.sfr.net (quand tu lances l'outil) en PM si tu veux que je regardes.
-
Merci beaucoup de ta réponse @nextgens, la bonne nouvelle c'est que je viens de me faire raccorder a la fibre ( longue histoire, en résumé ma residence était fibrée depuis plus d"un an mais mal référencée par orange, pendant tout ce temps mon adresse etait inéligible au ftth)
la mauvaise nouvelle c'est que n'ayant pas pu installer wireshark entre-temps je n'ai pu recuperer l'xml sur la ligne adsl.
Merci encore, j'attends un wrt3200acm pour remplacer la box. Je vous tiens au courant si j'arrive a configurer le spa122.
Bonne soirée !
-
Alors ayant reçu tout le matos j'ai réussi sans embrouilles a bypasser la box plus par un wrt3200acm que je viens de passer en Openwrt. J'ai configuré le SPA122 avec les paramètres du premier post et les résultats du script de @nextgens. Sauf que le SPA ne s'enregistre pas.
Product Information
Product Name: SPA122 Serial Number: CCQ-----2CE
Software Version: 1.4.1(SR5) Hardware Version: 1.0.0
MAC Address: B0#####44 Client Certificate: Installed
Customization: Open
System Status
Current Time: 5/7/2021 16:32:32 Elapsed Time: 00:00:16
RTP Packets Sent: 0 RTP Bytes Sent: 0
RTP Packets Recv: 0 RTP Bytes Recv: 0
SIP Messages Sent: 2 SIP Bytes Sent: 1155
SIP Messages Recv: 0 SIP Bytes Recv: 0
External IP:
Line 1 Status
Hook State: On Registration State: Failed
Last Registration At: 0/0/0 00:00:00 Next Registration In: 15 s
Message Waiting: No Mapped SIP Port:
Call Back Active: No
Last Called Number: Last Caller Number:
Si j'ai bien compris le SPA122 n'arrive pas à avoir l'IP externe de mon routeur (external ip reste vide). Etant en IPv6 avec de l'IP4 en CGNAT, est ce qu'installer un serveur STUN sur Openwrt resoudrait le probleme? quelqu'un a déja réussi à avoir la VOIP avec l'IPv6?
merci d'avance!
-
Le SPA122 permet-il de rentrer les paramètres d'une serveur STUN?
Dans ce cas, pourquoi ne pas essayer avec un serveur stun existant? Par exemple:
stun.3cx.com, port 3478
-
Le SPA122 permet-il de rentrer les paramètres d'une serveur STUN?
Dans ce cas, pourquoi ne pas essayer avec un serveur stun existant? Par exemple:
stun.3cx.com, port 3478
Avec le stun activé j'obtiens bien une adresse ipv4 mais qui n'est pas la mienne (je comprends que c'est a cause du cgnat?)
Du la registration échoue a tous les coups. Le spa122 n'est pas compatible ipv6 au dernier fw et le produit a été EOL par cisco.
J'imagine qu'à moins d'essayer d'obtenir une ip4 full stack de chez red ya pas moyen d'utiliser le spa122 en standalone? Un serveur asterisk sur le wrt pourrait etre une solution?
J'apprends tout doucement les bases du home networking mais l'idée serait d'éviter au max les solutions degradees et éventuellement avoir tout mes appareils en ipv6.
Merci d'avance!
-
[Update]
J'ai remplacé l"ata de cisco par un gigaset c590ip. Apres activation du stun ca marche sans problèmes sur la fibre RED en ipv6 avec ipv4 en cgnat.
Merci a tous et bon week-end.
-
Hello
Je partage mon expérience avec le SPA112, j'ai l'impression que personne n'a eu le même problème que moi, mais au cas où...
J'ai appliqué toutes les recettes données par jrobin28260 (merci bcp pour toutes ces infos !), tout marchait bien (réception, appel...), et puis au bout d'1h je réessaie, et plus rien. Je reboot, cela remarche, et puis pareil au bout d'un moment, plus rien.
J'ai expérimenté pas mal de changements de réglage, surveillé la connexion avec mon Mikrotik (qui étaient bien maintenue), retiré l'option SIP Helper... je ne voyais pas le problème.
J'ai finalement regardé la sortie du programme pour extraire les identifiants, et me suis dit que j'allais tester l'adresse d'un des proxy qui étaient listés. Et là miracle, cela marche sans problème depuis 3 jours.
Donc au lieu de mettre : Outbound Proxy : residential.p-cscf.sfr.net, j'ai remplacé par xxx.p-cscf.sfr.net:5062 avec xxx = le nom du serveur qui semble le plus proche dans la liste extraite par l'outil.
Je ne suis pas sûr de savoir pourquoi cela marche mieux (est-ce que certains des serveurs ne sont pas compatibles avec ma ligne.... mystère) mais en tout cas tout fonctionne et je croise les doigts pour que cela dure !
-
Bonjour,
Merci pour le tuto, ça fonctionne parfaitement!
Savez-vous comment configurer le SPA pour que les numéros s'affichent en 0XXXXXXXXX et non en 33XXXXXXXXX ?
Merci d'avance
-
merci @jrobin28260, pour ce sujet que je découvre aujourd'hui, je vais voir si j'arrive à récupérer mes identifiants SFR pour tester un accès direct dessus, mais pour info cela fait déjà plusieurs années, que j'utilise un
spa112 en fait correction c'est un SPA232D, couplé à un raspberry sous distribution raspbx. Ce qui me parait une solution plus aboutie, et du coup qui ne nécessite pas les identifiants SFR puisque je configure mes propres identifiants sous freepbx. Le drawback est que cela rajoute du hardware sur le reseau privé mais bon de toute façon je l'utilise entre autre comme serveur VPN.
Edit: j'avais confondu les références, en fait si je comprends bien ce tuto est destiné à recuperer la téléphonie VOIP via le SPA112 lorsqu'on veut changer la box SFR par une autre box.
Ceci dit ma remarque concernant le SPA232D, reste valide si on souhaite utiliser plusieurs postes VOIP via le PABX.
-
Salut à tous,
Toutes mes excuses pour ma faible assiduité sur ce forum !
Je viens de mettre à jour ce tutoriel, après avoir ressorti le SPA112 et mis en service un ATA191 (un tutoriel similaire arrive)
Les modifications les plus importantes concernent
- L'absence de possibilité de se connecter en IPv4 derrière un CGNAT
- La valeur NAT Keep Alive Intvl qui, à 150 secondes, pouvait poser problème en fonction du routeur utilisé
Je vais aussi tacher de jeter un œil aux 4 pages de messages du sujet afin de voir s'il y a des choses intéressantes à ajouter au tutoriel