PJSIP trunk reinvite behind NAT

I’m encountering a problem with one of my asterisk server which is located behind NAT. I’m using PJSIP.

The trunk is established with the provider, we can start call and everything is ok up to 16 minutes where the call drop.

The provider says that it sends us Re-invite but that we do not respond to any of them, so he cut the call after 7 re-invite without response.

I tcpdumped our server and sees no reinvite coming back to my asterisk. I would not like to open/nat 5060 udp port on the firewall/router. I think my firewall/router is not letting incoming trafic on 5060 re-enter.

Is there a way to keep the 5060 udp session up by sending regular keepalives (re-invite) at specific frequence (so firewall do not close the session).

I configured the trunk like :slight_smile:

type = registration
transport = transport-udp-nat
retry_interval = 150
expiration = 1800
max_retries = 20

type = auth
auth_type = userpass

type = endpoint
rtp_keepalive = 30
rtp_timeout = 30
context = SipD
transport = transport-udp-nat
disallow = all
allow = ulaw,alaw,speex,gsm
type = transport
protocol = udp
bind =
local_net = <my_local_net>
local_net =

I’m not familiar with NAT configuration for VoIP. Can anyone help me understand how to solve this problem ?


The first thing I would do is to check the Contact; headers on the responses to the original INVITE. If those are good, you need to try to get protocol traces from the provider, confirming they are sending the Re-INVITE to the correct place.

1 Like

The contact was correct, but there was also a problem with incoming call.
Our customers changed his firewall and this one just cleared the active session within 10 minutes.

I added the qualify_frequency parameter to aor section of my trunk and set it up to 120 seconds so the firewall session is refreshed and never expires again.

I hope this qualify_frenquence (keepalive) will not add other type of problems.

Thanks for your help.

Some Providers do not even respond to options messages or only send a 404 not found.

But why not open port 5060 on your firewall with a whitelist policy in place that will only allow traffic from your providers IP addresses?