Comme asterisk est sur le routeur n°1, ce n'est pas des redirections de port qu'il faut faire mais bien des "règles de trafic". Les redirections de port sont utiles notamment pour un service hébergé dans la zone lan et sans ip publique : le cas de ton serveur minetest. Ici ce n'est pas le besoin donc tu peux supprimer les règles VOIP SFR / SFR 2.

Dans "règles de trafic" :
from wan to "cet appareil" port 5060 UDP. Action INPUT
from wan to "cet appareil" ports 10000-20000 UDP. Action INPUT
from lan to "cet appareil" port 5060 UDP. Action INPUT

Je n'ai volontairement pas regardé le routeur 2. Il faut d'abord cibler la configuration du 1.

Avec 0 parametrages dans le routeur j'arrive a recevoir et envoyer des appels, j'ai juste été limité a des appels de 30s sur les appels recus. T'es sur que le souci chez toi n'est pas dans la config du client SIP ?

Sinon @artemus24 a posté sa config Asterix qui fonctionne, après suivant les version les parametres peuvent etre différents ou absents...
https://lafibre.info/remplacer-sfr/utilisation-dasterisk-sous-debian-11/msg1029659/#msg1029659

Le paramètre "rewrite_contact=yes" dans le fichier pjsip.conf d'Asterisk est utilisé pour indiquer à Asterisk s'il doit ou non modifier l'en-tête de contact des messages SIP entrants. L'en-tête de contact contient l'adresse IP et le port du client SIP qui envoie la demande.

Lorsque "rewrite_contact" est défini sur "yes", Asterisk va remplacer l'adresse IP et le port dans l'en-tête de contact par ses propres informations d'adresse IP et de port avant de relayer la demande. Cela peut être utile dans certaines situations, par exemple, si Asterisk est situé derrière un NAT (Network Address Translation) et doit s'assurer que les réponses SIP parviennent correctement au client SIP.

En résumé, "rewrite_contact=yes" est utilisé pour que Asterisk modifie l'en-tête de contact des messages SIP entrants afin de garantir la bonne transmission des messages dans des configurations réseau spécifiques.

Il faut effectivement  bien reprendre ta configuration, par exemple :

Les deux adresses external correspondent à l'adresse WAN/IP publique, pas l'adresse LAN de ton routeur.

Effectivement, j'ai indiqué mon IPV4 publique, et cette fois, je reçois bien les appels via SIP, merci ! 
Par contre, c'est amené à poser un sacré problème, étant donné que l'adresse IP allouée par SFR n'est pas fixe, il faudra systématiquement la mettre à jour dans le fichier de configuration ? 
J'ai bien essayé de la remplacer dans le fichier de configuration par un ndd no-ip qui pointe vers celle-ci (ddns installé et configuré sur OpenWRT), mais ça ne fonctionne pas.

Avec 0 parametrages dans le routeur j'arrive a recevoir et envoyer des appels, j'ai juste été limité a des appels de 30s sur les appels recus. T'es sur que le souci chez toi n'est pas dans la config du client SIP ?

Sinon @artemus24 a posté sa config Asterix qui fonctionne, après suivant les version les parametres peuvent etre différents ou absents...
https://lafibre.info/remplacer-sfr/utilisation-dasterisk-sous-debian-11/msg1029659/#msg1029659

Je me suis justement inspiré de ce qu'il a fait, et mon fichier de configuration contient bien ce paramètre pour éviter ce souci des 37 secondes ! :-)

L'adresse ip n'est pas fixe contractuellement mais elle ne bougera que lors de changements dans l'infra par exemple. Donc rarement.

D'accord, mais je pense que je potasserais sur la mise à jour automatique du fichier de conf' asterisk pour prévenir toute nécessité de changement. 
Du coup la partie SIP sur le routeur N°1 est réglée, aurais tu une idée du pourquoi du comment ça ne passe pas via le routeur N°2 ?

As-tu réessayé ? Quel domaine SIP renseignes-tu sur tes clients ?

Oui, je viens de réessayer.

Depuis Linphone sur mon smartphone Android, quand je suis connecté par wifi à mon routeur N°1, ça roule, la connexion au serveur asterisk fonctionne, et quand j'appelle le 1023 par exemple, la communication s'établit bien.

Par contre, quand je connecte par wifi le smartphone au routeur N°2, la connexion semble bien s'établir avec Asterisk sur le routeur N°1 via Linphone, j'indique comme dans l'exemple précédent dans ce client SIP le domaine 192.168.1.1 qui est celle du routeur N°1, mais par contre si je tente un appel, la communication apparaît établie (temps qui passe), mais il n'y a aucun son, pas de tonalité d'appel, rien.

Essaie en changeant la valeur de local_net dans pjsip.conf :
local_net=192.168.1.1/255.255.255.0
local_net=192.168.1.1/22

Avec ta première valeur de netmask à 255.255.255.0 (équivalent /24), asterisk considère ton réseau local sur les adresses 192.168.1.1 -> 192.168.1.254, et ton deuxième sous-réseau est donc exclu de son mécanisme NAT.
Avec un netmask plus grand "255.255.252.0" ou noté "/22", la plage devient 192.168.0.1 -> 192.168.3.254

Tu peux utilement regarder avec un outil de ce genre :
https://www.cidr.eu/en/calculator

EDIT : vire ces sous-réseaux et déploie ipv6  , d'autant que tu n'as aucune règle de filtrage entre les deux.

Alors, j'ai tenté de changé les valeurs que tu as indiqué ;

J'ai remplacé "192.168.1.1/255.255.255.0" par "192.168.1.1/22", redémarré le service asterisk, et même le routeur, et je n'ai toujours aucun son quand je tente les appels depuis le routeur N°2.
J'ai également tenté de remplacer par "192.168.1.1/255.255.252.0" ou "192.168.1.1/255.255.255.255", ou "192.168.1.1/32", et les appels continuent de faire les sourds tant que je suis sur le routeur N°2.

Je note que depuis le routeur N°1 "192.168.1.1", il m'est toujours impossible de contacter le routeur N°2 (ni les équipements connectés dessus) directement avec son IP "192.168.2.1", dont l'ip allouée (par wifi) par le routeur N°1 (via l'étendeur wifi servant de relais) est "192.168.1.60". Est ce que ça pourrait être un indice du problème ?

Concernant l'IPV6, à terme ça serait intéressant d'en rajouter la configuration, mais je voudrais déjà commencer par la base et terminer l'IPV4, comme ça je pourrais intégrer les deux à un tutoriel.
Je gage que certaines personne dans une situation similaire, mais sans forcément SFR, seront contents de trouver une solution pour un problème identique via une recherche web.