Issue with NAT settings being ignored

[frac]

We’ve got two Asterisk 18 servers that we use to route calls to partner call centers. This is done through a few different gateways, mostly through the AWS Chime SDK, though we have a few partners where we route directly to their SIP servers.

We’re setting up a new partner for direct routing that requires NAT to be enabled for our outbound RTP traffic. I got this working on the first server without much issue. I then copied the configuration from the pjsip.conf file for their endpoint over to the second server, where it seems to be ignoring the NAT settings; while the SIP portion is fine, the RTP traffic is going to their endpoint’s RFC 1918 address. The two servers have slightly different configurations in terms of call processing logic in the extensions.conf file, but are on the same version of Asterisk.

The relevant portions of our pjsip.conf file are as follows:

[global]
type=global
user_agent=FPBX-15.0.17.24(18.2.0)
default_outbound_endpoint=dpma_endpoint
taskprocessor_overload_trigger=pjsip_only

[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
local_net=
local_net=127.0.0.1/32
external_media_address=
external_signaling_address=
allow_reload=no
tos=cs3
cos=3

[NEWPARTNER]
contact=sip:+@:5060
qualify_frequency=60
type=aor

[NEWPARTNER]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=ulaw,g722
aors=TLCX_A
language=en
user_eq_phone=no
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rtp_symmetric=yes
dtmf_mode=auto
rewrite_contact=yes

[jcolp]

The rtp_symmetric option only kicks in if RTP is received for it to latch onto, so you need to provide logging showing that RTP is actually being received by Asterisk - as well as logging of the call flow.

[frac]

Thanks, that helped me find the issue. I had done packet captures that showed our outbound RTP traffic going to their RFC 1918 address. I didn’t see anything coming back, but just assumed that it was because we were going to the wrong place. That was a foolish assumption, in retrospect. It turns out that they hadn’t whitelisted our IP for outbound RTP traffic.

Thanks again.