Ayant passé presque 48 heures non-stop à essayer de faire fonctionner le VoIP, en grainant des infos ça et là, je me suis dit que ce serait bien d'avoir quelque chose de simple et qui explique le pourquoi des configs.

Comme tout le monde, je suis passé en IPv4 du coté WAN. et j'ai utilisé le programme de Florent Daignière pour récupérer les informations de compte
https://florent.daigniere.com/posts/2019/04/extracting-voip-credentials-from-my-broadband-router/

Display name   :  +33*********
Username   :  NDI0*********.ALP.THD@sfr.fr
Password   :  ************************
Domain      :  ims.mnc010.mcc208.3gppnetwork.org
Servers      :  (pick the one with the lowest latency)
   corbas.p-cscf.sfr.net.:5062
   venissieux.p-cscf.sfr.net.:5062
   mitry.p-cscf.sfr.net.:5062


Dans le forum certains suggèrent residential.p-cscf.sfr.net comme serveur.
Comme on voit ci-dessous, cela revient au même si on fait une requête DNS SRV sur le service _sip._udp - à voir si votre client SIP peut faire cela.

;; ANSWER SECTION:
_sip._udp.residential.p-cscf.sfr.net. 327 IN SRV 10 0 5062 venissieux.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net. 327 IN SRV 10 0 5062 corbas.p-cscf.sfr.net.
_sip._udp.residential.p-cscf.sfr.net. 327 IN SRV 10 0 5062 mitry.p-cscf.sfr.net.


Pour le NAT traversal, j'utilise STUN avec le service de Google: stun.l.google.com:19302
Ensuite il faut s'assurer que le client SIP met bien l'adresse WAN dans le champ Contact du message REGISTER.
Pour l'expiration de ce même REGISTER, j'ai mis 2 minutes (minimum accepté par SFR) comme ça en cas de changement d'IP, ça sera prendra 2 minutes max pour être joinable.
Pour le Keep Alive, j'utilise le message OPTIONS plutôt que NOTIFY, avec un intervalle de 20 seconds. Ca c'est pour s'assurer que le router garde le mapping NAT ouvert (le port UDP entrant redirigé vers mon client SIP).

Le plus grand problème que j'ai eu a résoudre est que SFR indique, dans le champ Contact de certains messages SIP, le serveur interne qui traite les appels (par example pcgw-0006.imsgroup-019.mit2asbc03.ims.sfr.net). Hors, les DNS publiques de SFR ne connaissent pas ces serveurs et certains clients SIP (incluant le mien) échouent à envoyer le message ACK nécessaire lors d'un appel sortant, ce qui cause une coupure de la communication par SFR après environ 32 secondes.
Il semble que le message ACK peut simplement aller au même endpoint (IP + port) utilisé depuis le début de la session SIP. Cela indiquerait que les noms des servers mentionnés précédemment sont des load balancers.
A ce stade je ne sais pas si le client SIP de la box SFR a accès à des serveurs DNS différents, ou bien si le champ Contact est ignoré (tout le temps ou ignoré si la résolution DNS échoue). Ca ne m'étonnerait pas que le client SIP des box SFR ignorent simplement l'erreur et que personne chez SFR ne s'est rendu compte que ces serveurs sont inconnus des serveurs DNS utilisés par la box.

Pour éviter une requête DNS qui va échouer, il semble que certains sur ce forum utilisent Asterisk avec la configuration rewrite_contact=yes.
Comme je ne voulais pas installer Asterisk, j'ai configuré le client SIP directement avec une des IPs (92.91.129.72) d'un des serveurs et j'ai mis dans mon routeur une règle DNS wildcard. Ca marche, mais évidement ça va planter le jour ou SFR change les IPs.

Ca devrait marcher, mon routeur utilise Dnsmasq

OK pour de photos de mon ATA, je ferais ça dans les jours qui viennent.

Bonjour,

Je suis également en train d'essayer de faire fonctionner la Voip de SFR avec mon routeur openwrt.
J'ai lu beaucoup de posts sur cec forum à ce sujet.
Je voulais vous faire part de mes investigations quand j'aurais tout terminé, mais je profite de ce post pour commencer.

Je que je veux faire à terme :
- conserver mon téléphone analogique : il a une fonctionnalité anti spam qui marche bien.
- je dispose de deux ATA anciens : un cisco ATA190 et un linksys 2102 ; j'espère en utiliser un pour faire fonctionner mon téléphone.
- je ne veux pas utiliser asterisk : je trouve que la solution est lourde pour l'usage. Au pire, j'utiliserai siproxd

J'ai voulu d'abord faire fonctionner microsip, pour valider ; en direct, sans siproxd. Comme vous, je me suis cassé les dents sur le fameux pcgw-0006.imsgroup-019.mit2asbc03.ims.sfr.net (ou autre) dans le champ Contact.
Je l'ai réglé en mettant la règle que vous proposez dans la conf de dnsmasq du routeur.
Ca peut se faire depuis Luci :
Network -> DHCP and DNS -> General
Il suffit d'ajouter ceci dans la partie Adresses : /.ims.sfr.net/92.91.179.56
L'IP cible peut être la meme IP, ou une IP différente de celle utilisée dans SIP Proxy
Ca ajoute ceci dans /etc/config/dhcp :
 list address '/.ims.sfr.net/92.91.179.56'

Tout marche très bien, sans  avoir à ajouter de règles de firewall ou de redirection de port.

Coté linksys 2102 'en direct' (sans siproxd), mission impossible : il est trop vieux, ca ne passe pas la première requete REGISTER. Ca échoue avec un "CLF interrogation failure"
La seule différence notable que je vois entre la trame REGISTER générée par microsip et cette du linksys 2102 est le champ Allow :
pour microsip : Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
pour linksys 2102 : Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER

Je vais donc essayer avec siproxd.

J'ai déja commencé avec microsip et siproxd. Ca marche bien, pas besoin de règles de redirection ou de firewall. Cerise sur le gateau, plus besoin de faire la bidouille DNS pour .ims.sfr.net.
Je vois dans la log de debug siproxd qu'io n'arrive pas à résoudre pcgw-0006.imsgroup-019.mit2asbc03.ims.sfr.net ou son équivalent, mais il continue en renvoyant la requete PRACK au proxy avec lequel il est en relation.
Pour le moment, dans la conf siproxd, j'ai mis une des IP de proxy :
option outbound_proxy_host '92.91.179.56'

J'ai bon espoir de pouvoir le faire fonctionner en profitant du round robin, avec :
option outbound_proxy_host 'corbas.p-cscf.sfr.net'

Une fois que ce sera fait, je commencerais les tests avec le linksys2102 + siproxd.