Si ca ne marche toujours pas, c'est qu'il faut certainement ajouter "neufbox" dans l'option dhcp vendorclass de wan6, voici le mien dans /etc/config/network
config interface 'wan6'
option device 'br-wan'
option proto 'dhcpv6'
option peerdns '0'
option reqaddress 'try'
option defaultreqopts '0'
option reqopts '23 25 26'
option noclientfqdn '1'
option noacceptreconfig '1'
option vendorclass '0000a00c00416e657566626f785f'
option clientid '00030001XXXXXXXXXXXX'
list dns '2001:4860:4860::8888'
list dns '2606:4700:4700::1111'
option reqprefix 'auto'
Les XXXXXXXXXXXX correspondent a l'adresse MAC de ma box SFR.
0000a00c00416e657566626f785f = neufbox_ en ASCII avec un prefix qu'il ne faut pas toucher.

La ligne option vendorclass n'est pas utile lorsqu'on est en IPV4 full stack. Peut-être qu'elle l'est en ipv4+ipv6 CGNAT...je n'en suis pas certain, mais dans le doute on l'ajouter ca ne posera pas de problème.

Tu as un autre option si tu ne veux pas t'embetter avec l'IPV6, c'est d'appeler le service client et demander le passage en ipv4 dédiée (Full Stack). en CGNAT ton adresse ipv4 est partagée ce qui empeche la redirection de ports.

je n'ai pas bien compris coment tu as solutionné ton probleme...
tu recois une ipv4 et une ipv6 ?

ok.
Donc openwrt arrive bien a gérer le CGNAT, sans rien faire de particulier donc.
Tu as fait ce que j'ai dit plus haut pour le WAN6, ou ce n'est pas nécessaire ?
Tu récupères bien une ipv4 et une ipv6 ?

Bonjour à tous et meilleurs vœux de connexions pour cette nouvelle année !

Ça faisait un moment que j'avais un Xiaomi AX3000T neuf qui attendait dans sa boîte que je prenne le temps de faire le flash OpenWRT puis la configuration proposée par maximushugus.

C'est fait, enfin !

Je tiens à remercier chaudement maximushugus pour ton tuto dont la lecture s'est arrêtée au premier conseil puisque je n'ai pas besoin de la TV et du téléphone. C'est ultra simple, à peine croyable ! 

Complément pour ceux qui veulent un Asterisk sur un serveur du LAN, et non sur le routeur (cas de farmouss, kdaffef91, olitask... resté sans solution publiée ici). Configuration en service depuis fin septembre 2026 : Asterisk 22 (PJSIP) sur un NAS Debian, derrière un Xiaomi AX3000T sous OpenWrt branché sur l'ONT, NB6VAC éteinte. Entrants, sortants, présentation du numéro, DTMF, urgences.

Prérequis : une IPv4 publique dédiée (pas de CGNAT, sinon aucune redirection possible, voir plus haut dans le fil) et fixe, puisqu'elle est écrite dans la configuration.

1. Routeur OpenWrt : deux redirections vers le serveur, MÊMES ports des deux côtés (Asterisk annonce ses ports tels quels ; une translation de port casse l'audio). Pas d'ALG SIP.

config redirect
option name 'SIP-SFR'
option src 'wan'
option dest 'lan'
option proto 'udp'
option src_dport '5062'
option dest_ip '192.168.1.X'
option dest_port '5062'
option target 'DNAT'
option reflection '0'
option src_ip '92.91.129.136'

(même bloc quatre fois de plus, avec src_ip 92.91.129.152, .168, .184 et .200)

config redirect
option name 'RTP-SFR'
option src 'wan'
option dest 'lan'
option proto 'udp'
option src_dport '20000-20099'
option dest_ip '192.168.1.X'
option dest_port '20000-20099'
option target 'DNAT'
option reflection '0'

Les cinq adresses sont celles de trappes.p-cscf.sfr.net (getent ahostsv4 trappes.p-cscf.sfr.net). Une redirection par adresse : je n'ai pas vérifié qu'une seule redirection avec une liste src_ip soit respectée par fw4. Vérifier après coup avec nft list chain inet fw4 dstnat_wan que chaque règle SIP-SFR porte bien son ip saddr. Le RTP reste sans restriction : les passerelles média de SFR ne sont pas connues d'avance. Le routeur conserve le port source 5062 en sortie (vérifié dans conntrack).

Constat intéressant : les compteurs des cinq règles SIP sont à 0 depuis le dernier redémarrage du routeur, alors que des appels entrants sont arrivés depuis. Les INVITE de SFR passent donc par la correspondance NAT que maintiennent les REGISTER et les OPTIONS sortants depuis le port 5062, et non par la redirection, qui ne sert qu'en secours. Ça va dans le sens du rôle des OPTIONS décrit plus bas, sans le démontrer.

2. rtp.conf

[general]
rtpstart = 20000
rtpend = 20099
strictrtp = yes

3. pjsip.conf (numéro, NDI et mot de passe remplacés)

[transport-sfr]
type = transport
protocol = udp
bind = 0.0.0.0:5062
external_signaling_address = <IP publique>
external_signaling_port = 5062
external_media_address = <IP publique>
local_net = 192.168.1.0/24

[sfr-auth]
type = auth
auth_type = digest
username = NDI...@sfr.fr
password = <mot de passe SIP>

[sfr]
type = registration
transport = transport-sfr
outbound_auth = sfr-auth
server_uri = sip:ims.mnc010.mcc208.3gppnetwork.org
client_uri = sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
contact_user = +33XXXXXXXXX
outbound_proxy = sip:92.91.129.168:5062\;lr
expiration = 3600
retry_interval = 60
max_retries = 10000
forbidden_retry_interval = 600
fatal_retry_interval = 600
auth_rejection_permanent = no

[sfr]
type = endpoint
transport = transport-sfr
context = depuis-sfr
disallow = all
allow = alaw,ulaw
dtmf_mode = rfc4733
direct_media = no
outbound_auth = sfr-auth
outbound_proxy = sip:92.91.129.168:5062\;lr
from_domain = ims.mnc010.mcc208.3gppnetwork.org
from_user = +33XXXXXXXXX
aors = sfr
rewrite_contact = yes
100rel = yes
rtp_symmetric = yes
force_rport = yes
trust_id_inbound = yes

[sfr]
type = aor
contact = sip:ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy = sip:92.91.129.168:5062\;lr
qualify_frequency = 60

[sfr]
type = identify
endpoint = sfr
match = 92.91.129.136
match = 92.91.129.152
match = 92.91.129.168
match = 92.91.129.184
match = 92.91.129.200

4. Sortants, dans extensions.conf : donner l'URI explicitement (les urgences 15, 17, 18, 112... de la même façon).

exten => _0XXXXXXXXX,1,Dial(PJSIP/sfr/sip:${EXTEN}@ims.mnc010.mcc208.3gppnetwork.org,120)

Deux pièges propres au cas « derrière NAT », qui m'ont coûté deux semaines (détail dans mon fil : https://lafibre.info/remplacer-sfr/asteriskopenwrt-entrants-perdus-apres-inactivite-ok-apres-un-sortant/) :

- Sans la qualification OPTIONS de l'AOR (qualify_frequency = 60, avec l'outbound_proxy répété DANS l'AOR, celui de l'endpoint ne vaut pas pour les OPTIONS), les appels entrants cessaient d'arriver après quelques heures sans communication, alors que l'inscription restait active. Avec : cinq silences de 6 h à 28 h tenus sans perte.

- Avec la qualification, si le proxy ne répond plus aux OPTIONS pendant quelques minutes, le contact passe Unavailable et la forme habituelle Dial(PJSIP/${EXTEN}@sfr) refuse localement TOUS les sortants, urgences comprises (« cause 3 - No route to destination »). L'URI explicite du point 4 contourne ce blocage : vérifié en forçant le contact Unavailable.