Pjsip trunk defaults favor NAT

A case of broken dialogue…

After some back-and-forth with a PSTN provider about why hangups weren’t getting processed, we found that Asterisk’s BYEs weren’t following the route set but instead being sent back to the (TCP) source port from the original incoming INVITE on the call.

I found two default settings in the pjsip trunk that I think would be uncommon unless you are dealing with a remote NAT, which would not normally apply to trunks, only phones. Namely, “Force rport” and “Rewrite Contact.” Switching these off allowed the request to follow the correct path defined by the route set and Contact header and BYEs worked properly.

1 Like

As a general design philosophy when it comes to PJSIP, I believe that FreePBX strives to use the same defaults as Asterisk. Perhaps @jcolp can confirm that the GUI is not arbitrarily setting these values to non-asterisk defaults.

The Asterisk defaults are for force_rport to “yes”, which shouldn’t impact this in practice I believe. For rewrite_contact the default is “no”.

That being the case, a feature request to revisit the default setting for rewrite_contact for new pjsip trunks is in order.

I think where this matters is where the provider is not facing the Internet with a topology-hiding SBC.

I have seen several cases where the provider’s traffic shows a multi-hop route set or a Contact header containing internal IP addresses. All of which are valid of course. But aggressive NAT handling might see those internal IPs and try to “fix” them, which then breaks the message flow.

Other providers hide all their topology and all Asterisk sees is a single point that it is talking to and all is well.

In this case I do believe the force_rport needed to be disabled because I am using TLS. The incoming TLS call is not sourced from the provider’s port 5061 but from an ephemeral port. The provider is expecting Asterisk to send requests back to it (such as BYE) on 5061 per the headers. With force_rport turned on, Asterisk was trying to send the BYE request to the ephemeral port which was already closed.

The force_rport option should only apply to responses. The rewrite_contact option, however, would have caused what you are seeing.

1 Like

Perfect… thank you for the clarification.

It would be nice to go ONE DAY without a reminder that my memory sucks:
https://issues.freepbx.org/browse/FREEPBX-18699

edit - now resolved

Latest edge release of core module is setting this parameter default to ‘NO’. Refer to https://issues.freepbx.org/browse/FREEPBX-18699 for more details. Thanks.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.