Cannot make inbound and outbound trunk work at the same time (except for first 5min)

We are having troubles making the trunk work for both inbound and outbound calls.

We cannot make outbound calls if the qualify frequency is set to 60, inbound calls are no problem.
This can be fixed by setting the qualify frequency to 0. See theat:

But if the qualify frequency is set to 0 there now is a different problem… If the qualify frequency is 0 no keep alive packages are send, this makes the Fritzbox 7590 we have think there isn’t a connection anymore so after 5minutes it deletes the NAT information … Which means no inbound calls can be made anymore. If we make a call, the connection is once again open for only 5min. The connection is made by UDP.
So stuck between a rock and a hard place… or we cannot make outbound calls or we cannot receive inbound calls…
Anyone any clue on how to fix this?

Try leaving Qualify Frequency at 0, but set Expiration to 120. If that doesn’t help, paste a log (including pjsip logger) showing a registration sequence.

It sounds to me as though the OPTIONS is needed to keep the firewall/NAT open, but no reply is being received for it, so the outbound calls are being railed because of the apparent loss of connectivity.

Could have been a nice solution, but remote server won’t allow it. minimum expiration is 3600.
See log file.
https://pastebin.freepbx.org/view/16630b14#

That sounds about right.
This log is the one where Qualify freq is set at 60
https://pastebin.freepbx.org/view/931620c3#

Getting a 404 error on both logs.

sorry forgot to change expiration time, new links added to posts

Try setting Qualify Frequency for your trunk to 0, but also set up a dummy trunk (no routes use it) with Registration None, Authentication None, Qualify Frequency 60, other settings same.

Will try that, though we are wondering if either setting a STUN server (probably not as the timeout will still occur) or using port forwarding may work as well?
Also note the service route return value from the KPN server with a different “5090” instead of the usual “5060” port number, if the server actually uses that to reply then NAT will fail and may be the cause of no SIP option responses being received?

This seems to work, let’s see if it holds.
It’s a bit of a dirty trick, but so far it survived for longer then 5 minutes on the inbound route (outbound remains operational in this setup anyway).