Essaies à tout hasard de créer une règle de forward de la plage RTP vers ton asterisk. Apparemment, pas mal de monde a des problèmes de RTP avec pfsense... J'ai vu aussi le paramétrage en statique du mapping des ports qui pourrait peut-être aider (cocher hybrid outbound NAT) tiré de la doc de 3CX : https://www.3cx.com/docs/pfsense-firewall/

Sinon tu pourrais tester openwrt (vu que t'es en virtuel tu peux faire ce que tu veux). Chez moi, j'ai zéro soucis avec asterisk et OVH. Aucune règle à créer, c'est presque trop facile. Et j'ai la même config que toi.

Le NAT est bien défini sur le trunk également ?  (force_rport = yes)

Oui j'avais déjà fait un port forward des ports RTP vers asterisk sur mon PfSense et l'audio fonctionne bien dans ce cas. Néanmoin je me vois difficilement laisser autant de ports ouverts sur mon pare-feu...

Pour ce qui est de "force_rport = yes", comme tu peux le voir dans la configuration c'est bien spécifié :
; -------------------------- ;
;      Proxy Server SFR      ;
; -------------------------- ;
;                            ;
; residential.p-cscf.sfr.net ;
;                            ;
; Mitry   : 92.91.129.8      ;
;         : 92.91.129.24     ;
;         : 92.91.129.40  <  ;
;         : 92.91.129.56     ;
;         : 92.91.129.72     ;
;                            ;
; Corbas  : 92.91.179.8      ;
;         : 92.91.179.24     ;
;         : 92.91.179.40     ;
;         : 92.91.179.56     ;
;         : 92.91.179.72  <  ;
;                            ;
; Trappes : 92.91.129.136 <  ;
;         : 92.91.129.152 < *;
;         : 92.91.129.168    ;
;         : 92.91.129.184    ;
;         : 92.91.129.200 <  ;
;                            ;
; -------------------------- ;

[registration]
auth_rejection_permanent=yes

[transport-udp-nat]
bind=0.0.0.0
external_media_address=XXX.XXX.XXX.XXX
external_signaling_address=XXX.XXX.XXX.XXX
local_net=192.168.1.0/24
protocol=udp
type=transport

[transport-udp-ipv6]
type=transport
protocol=udp
bind=::

; --------- ;
; Templates ;
; --------- ;

[my_codecs](!)
disallow=all
allow=alaw
allow=ulaw
allow=gsm
allow=g722

[aor_dynamic](!)
max_contacts=9999
remove_existing=yes
type=aor

[auth_userpass](!)
auth_type=userpass
type=auth

[endpoint_internal](!,my_codecs)
context=outgoing
direct_media=no
force_rport=yes
from_domain=ims.mnc010.mcc208.3gppnetwork.org
ice_support=yes
language=fr
;;rewrite_contact=yes
rtp_symmetric=yes
transport=transport-udp-ipv6
transport=transport-udp-nat
type=endpoint

; --------- ;
; Trunk SFR ;
; --------- ;

[sfr]
contact=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy=sip:92.91.129.152:5062\;lr
max_contacts=9999
type=aor

[sfr_auth]
auth_type=userpass
password=MOTDEPASSESFR
realm=sfr.fr
username=NDI0XXXXXXXXX.XXX.XXX@sfr.fr
type=auth

[sfr](my_codecs)
100rel=yes
aors=sfr
context=incoming
direct_media=no
force_rport=yes
from_domain=ims.mnc010.mcc208.3gppnetwork.org
from_user=+33XXXXXXXXX
ice_support=yes
outbound_auth=sfr_auth
outbound_proxy=sip:92.91.129.152:5062\;lr
rewrite_contact=yes
rtp_symmetric=yes
transport=transport-udp-nat
type=endpoint

[sfr]
endpoint=sfr
type=identify
match=sip:92.91.129.152:5062\;lr

[sfr]
client_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
server_uri=sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
contact_user=+33XXXXXXXXX
outbound_auth=sfr_auth
outbound_proxy=sip:92.91.129.152:5062\;lr
transport=transport-udp-nat
type=registration

; ------------------- ;
; Phone Line 'Zoiper' ;
; ------------------- ;

[zoiper](aor_dynamic)

[zoiper](auth_userpass)
password=zoiper
username=zoiper

[zoiper](endpoint_internal)
auth=zoiper
aors=zoiper
callerid=zoiper

Pour contourner ce problème de NAT, sur le tuto pour le Gigaset C530 (https://lafibre.info/remplacer-sfr/probleme-dinstallation-bypass-voip-red-avec-gigaset-c530-ip/) et sur le Cisco SPA112 (https://lafibre.info/cisco/utilisation-dun-cisco-spa112-pour-la-telephone-voip-de-votre-abonnement-sfr/) il est décrit l'utilisation soit de :
- STUN server (j'ai essayé de le configurer dans rtp.conf avec un serveur STUN que je gère pour un autre projet) : si je ne configure que les paramètres pour STUN dans rtp.conf d'asterisk, je ne vois aucune requete dans les logs de mon serveur STUN. Par contre si je configure STUN et TURN serveur, je vois bien des requetes dans les logs de mon serveur STUN/TURN mais celà ne fonctionne pas pour autant....
- soit utilisation de "VIA" sur le SPA112

Ok je viens enfin de comprendre et résoudre mon problème de NAT.

Pour rappel, j'ai un serveur Asterisk branché sur mon LAN derrière un routeur PfSense (qui remplace complètement la neufbox), le tout sur une connexion SFR.
Le problème était que je parvenais bien à passer les appels, mais aucun son ne parvenait jusqu'à moi.
Lorsque je faisait une capture réseau, sur mon LAN la communication SIP passait correctement dans les 2 sens (Asterisk <--> serveur SFR).
Mais sur mon LAN je ne voyais que la communication RTP (qui contient l'audio) dans le sens montant (Asterisk --> SFR) mais rien en descendant. Si je lançais la capture réseau sur la patte WAN de mon PfSense, je vois bien les paquets RTP dans les 2 sens (Asterisk <--> SFR) et je peux même extraire l'audio de la conversation.

A partir de là je me doutais qu'il s'agissait d'un problème de NAT sur mon PfSense, qui ne transférait pas le flux RTP descendant sur le WAN vers l'adresse IP d'Asterisk sur mon LAN.
J'ai donc fais d'autres explorations : j'ai lancé 2 captures réseaux simultanément sur mon PfSense : une sur le WAN et une sur le LAN.

Je me suis rendu compte qu'au cours de l'échange, le NAT de PfSense changeait le port source duquel sortait les paquets RTP depuis mon IP WAN.
Du côté LAN le port source d'Asterisk n'avait pas changé, mais PfSense faisait un NAT de port source sur le WAN.
Néanmoins le serveur SFR continue d'envoyer dans le sens descendant les paquets RTP vers mon IP WAN (ce qui est normal) mais vers le port de destination qui était celui d'avant le changement effectué par Pfsense (et qui restait le même que le port source d'Asterisk sur le LAN, qui lui n'a pas changé). C'est pourquoi ces paquets n'étaient pas nattés du WAN vers mon Asterisk sur le LAN.

Pour corrigé le problème j'ai créé une règle de mappage dans la partie NAT sur PfSense avec comme port source l'adresse IP d'asterisk / 32 (pour ne spécifier que cette adresse), sur l'interface WAN, et en cochant "port statique", pour éviter la randomisation du port source.

Et là, miracle, tout fonctionne comme prévu, sans ouvrir de port ni de redirection dans le pare-feu.

Maintenant si quelqu'un est capable de m'expliquer pourquoi PfSense à ce problème de NAT, je suis preneur de l'explication. J'ai l'impression que c'est un problème de timing du NAT, mais je ne sais pas comment regarder celà.

Alors, j'ai regardé de mon côté le comportement de mon pfsense et ça à l'air d'être ok.

La livebox annonce le 8008 dans l'INVITE et démarre bien le flux avec. Pfsense, dès le premier paquet le change pour 4702. Le NAT de virtualbox le change à son tour vers 43103 et mon openwrt le transmet sans modif.

Ça nous fait donc : Livebox (8008) > Pfsense (4702) > Virtualbox (43103) > OpenWRT (43103) > Orange

Je tourne avec la 2.3.4, si tu veux essayer des fois que ce soit un bug avec les versions plus récentes : https://archive.org/download/linuxtracker.org_p1/pfSense-CE-2.3.4-RELEASE-amd64.iso.gz

Autre truc à prendre en compte : il ne faudrait pas que SFR ait une implémentation un peu bizarre et se base uniquement sur le contenu du INVITE/SDP... Dans ce cas, le mapping statique est la seule solution 

J'ai fait un test avec asterisk qui, lui, s'adapte : si au premier coup il détecte l'ip dernière le NAT avec le port original (donc le SDP) à la seconde où le flux RTP arrive il switch sur l'IP/port source du NAT :

  == Using SIP RTP TOS bits 184
  == Using SIP RTP TOS bits 184 in TCLASS field.
  == Using SIP RTP CoS mark 5
       > 0x7fc00c044550 -- Strict RTP learning after remote address set to: 10.0.2.15:4004  <<<< INVTE/SDP
    -- Executing [123@internal:1] VoiceMailMain("SIP/304-00000042", "304@internal_vm") in new stack
    -- <SIP/304-00000042> Playing 'vm-password.slin' (language 'fr_xivo')
       > 0x7fc00c044550 -- Strict RTP learning after remote address set to: 10.0.2.15:4004
       > 0x7fc00c044550 -- Strict RTP qualifying stream type: audio
       > 0x7fc00c044550 -- Strict RTP switching source address to 192.168.1.11:50052 <<<< switch sur l'IP du NAT

Je pense que c'est ça : le serveur téléphonique de chez SFR ne doit se baser que sur le contenu de la communication SIP pour déterminer le port de destination dans le sens SFR -> chez moi. Or comme le port source depuis mon PfSense dans le sens moi -> SFR est modifié, randomisé, les 2 ports ne concordent plus et donc le pare-feu ne transfère pas le port en question sur Asterisk,en réponse au NAT comme c'est le cas normalement.
D'où le fait qu'en désactivant la randomisation de port sur le NAT cela fonctionne

Maintenant j'essaie de faire fonctionner les appels entrants.
Sans ouvrir le port 5060 de mon firewall vers Asterisk (avec une redirection), ce dernier ne voit aucune requete. Donc la connexion ne reste pas ouverte, même si j'ai effectué un appel sortant au préalable.
Si j'ouvre et redirige le port 5060 (uniquement depuis l'adresse source 92.91.129.152 par sécurité), et que je fais un appel entrant, cette fois Asterisk reçoit bien une requête mais ne sais pas quoi en faire :
NOTICE[1341]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'INVITE' from '<sip:+336XXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>' failed for '92.91.129.152:5062' (callid: LU-16941649088XX367-13536127@imsgroup-010.tng1asbc02.ims.sfr.net) - No matching endpoint foundEst ce que c'est du au fichier "extension.conf" ?
A suivre

@artemus24 Chez toi asterisk est sur le routeur donc pas de NAT, comme la box SFR. si tu pouvais monter un asterisk sur une autre machine, avec la meme configuration, tu aurais certainement les meme problèmes.

Maintenant j'essaie de faire fonctionner les appels entrants.
Sans ouvrir le port 5060 de mon firewall vers Asterisk (avec une redirection), ce dernier ne voit aucune requete. Donc la connexion ne reste pas ouverte, même si j'ai effectué un appel sortant au préalable.
Si j'ouvre et redirige le port 5060 (uniquement depuis l'adresse source 92.91.129.152 par sécurité), et que je fais un appel entrant, cette fois Asterisk reçoit bien une requête mais ne sais pas quoi en faire :

Code: [Sélectionner]

NOTICE[1341]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'INVITE' from '<sip:+336XXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>' failed for '92.91.129.152:5062' (callid: LU-16941649088XX367-13536127@imsgroup-010.tng1asbc02.ims.sfr.net) - No matching endpoint foundEst ce que c'est du au fichier "extension.conf" ?
A suivre

J'ai un doute. Si ça venait de extensions.conf, y'aurait un truc plus comme ça je pense :
NOTICE[24392][C-00000001]: chan_sip.c:26695 handle_request_invite: Call from '00339XXXXXXXX' (91.121.129.29:5962) to extension '00339XXXXXXXX' rejected because extension not found in context 'from-ovh'.

En gros il ne trouve pas le numéro associé. Dans ton cas, ça fait penser au nom de domaine...

Je crois que tu t'es gouré dans la section identity, tu as mis la syntaxe du outbound proxy

Il faut renseigner juste l'ip (ou le sous réseau avec /24 par ex) :

[sfr]
endpoint=sfr
match=92.91.129.152
type=identify