Regarde si ton application ne forge pas des paquets avec l'IP publique en IP source. Car sinon ton routeur il forward bêtement vers l'extérieur, et il y aura un pb sur le retour.
Car oui, moi Optix, petit routeur de famille, je reçois un colis à mon adresse, mais qui a commandé ?
Donc il faut se concentrer sur la requête que TOI tu émets.

a priori, s'il faut capturer le traffic depuis mon PC lorsque j'emet un appel, j'ai déjà ces captures là dans ce post :
https://lafibre.info/remplacer-sfr/red-by-sfr-appels-sip-sortant-coupes-au-bout-de-32-secondes/msg1028600/#msg1028600
Mon IP publique n'apparait a aucun moment.

je suis pas certain que c'est là qu'il faut regarder mais, je dirais que c'est bien mon ip publique qui apparait dans le "colissimo" 

ce serait pas une question d'outbound/proxy?

enfin je dis ca..

Mhhh, j'ignore si le SIP ALG est coupé ou non sur ton routeur, car là il devrait voir que la requête qui part avec le port source 5060.

Par acquis de conscience, tu as forwardé le port 5060 vers ton IP privée ? Ou le forward si ce n'est pas le cas ?

j'avais lu de droite et de gauche tout et son contraire a ce sujet. actuellement je n'ai pas de SIP ALG activé, ni port forwarding sur le 5060.
J'ai par ailleurs quand meme testé  avec et sans, ca n'a rien changé au probleme.

J'ai testé le SIP passthrough d'openwrt : https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_nat#sip_passthrough

Bah le problème est déjà au niveau IP (et non applicatif) : pourquoi le routeur reçoit la réponse, mais pas son soft ?

ha ben non, dans les captures depuis le routeur, sur le WAN, j'ai pas non plus les status "180 RINGING" et "200 OK"...Donc ces 2 status là ne sont pas reçu au niveau du routeur. Mais est-ce que seulement ils sont envoyés ? 
Le serveur sait envoyer tous les autres status au bon endroit, et il ne saurait pas où envoyer les 180/200 ?

les proxy/outbound ne sont pas des options de second degré, loin de là..

Je ne dis pas le contraire, mais là les paquets arrivent sur son WAN, mais visiblement son soft ne reçoit rien. Il faut déjà régler ça amha

Dixit l'intéressé :

Mais malheureusement, ca coupe toujours...Les status RINGING et INVITE n'arrivent pas jusqu'a l'application.

Si la couche IP (la couche basse) a déjà une merde, tu auras beau trifouiller sur la couche applicative au-dessus, le pb restera le même selon moi.

Du coup rooot, configure déjà une règle de forwarding (dst-nat) pour que les paquets qui arrivent sur ta patte publique, arrivent jusqu'à ton softphone. On verra s'il arrive à enchainer la suite du dialogue SIP proprement.

edit: bon finalement rooot a répondu entre temps et le périmètre a changé, je remets mon cerveau dessus ce soir

@ Rooot : le compte de ton MicroSIP me parait bizarre :
--> SIP Server : il n'y a pas de username "+33xxxxxxxxx". Je dois en mettre un chez moi, sinon, ça ne fonctionne pas.
--> SIP Proxy : residential n'existe pas. Il faut mettre "mitry", "corbas" ou "trappes".
--> Public Address : que je mette mon adresse IP WAN ou pas, c'est pareil.

Le paramétrage :
--> j'ai les mêmes codecs.
--> source port : je n'ai rien mis.
--> RTP Ports : je n'ai rien mis.
--> nameserver : je n'ai rien mis.
--> STUN Server : j'ai coché, sinon ça ne fonctionne pas chez moi.

Ne vous perdez pas les réglages et essayez de suivre la logique et le chemin des paquets.

J'ai testé plusieurs combinaisons dans le paramétrage, sans avoir résolu le problème. La solution se trouve ailleurs que dans le SoftPhone.

@ Rooot : l'adresse IP 92.91.128.24 est celle du serveur proxy de mitry.
Concernant la fin de la requête SIP, celle où il manque ceci (en rouge) : "Request: INVITE sip:+33xxxxxxxxx@ims.mnc010.mcc208.gppnetwork.org:5062;transport=udp;ob". Ne serait ce pas ça le problème ?

Je ne dis pas le contraire, mais là les paquets arrivent sur son WAN, mais visiblement son soft ne reçoit rien. Il faut déjà régler ça amha

Je me suis mis en DMZ dans la Box SFR et ouvert le pare-feu Windows afin de ne rien avoir de bloquant. Le SIP ALG est coupé aussi. Pareil, le problème persiste.
Sous Debian, derrière l'ONT, sans pare-feu (iptables), j'ai aussi le même problème.

sur d'autres postes dans le forum, certains ne semblent pas avoir ce souci lorsqu'ils utilisent des téléphones ou adaptateurs SIP, dans lesquels il y a d'ailleurs un peu plus de paramètres a renseigner.

Justement, avec un téléphone VOIP/SIP comme les Gigaset IP, est ce que le problème ne se serait pas résolu de lui même ?
Ce qui voudrait dire qu'il manque quelque chose dans la configuration des routeurs et des ordinateurs.
Un problème de NAT peut-être, sans savoir lequel.