Running FreePBX 14.0.13.6
We are seeing our SIP trunk provider is sending us re-invites at 30-minute intervals but FreePBX isn’t sending back an ACK so the SIP trunk provider is terminating the call. Essentially the call drops right at 30-minutes.
What should I be looking for in this instance to resolve this?
Either a NAT issue, a session timer issue or a combination of both.
Thanks for the response.
I would think a NAT issue would show up in other ways as well like not getting audio or the call dropping after 30-seconds. These calls are being dropped after 30-MINUTES. I talked to the SIP provider and what they indicated was that they are sending a re-invite but we aren’t responding with an ACK. They send the reinvite automatically at 30-minutes. They changed it to 60-minutes but that’s not a great solution.
Again I would think that NAT issues would exhibit other more immediate issues but we are seeing any of the traditional NAT issues.
When I look at the NAT settings I see that I have our public static IP as the External Address. I’ve also got all of our subnets listed in Local Networks. We are using PJSIP for our SIP trunks and extensions.
It all depends on the particular router/firewall configuration, specially in relation to port forwarding. A NAT issue can manifest itself in so many different ways.
Have you confirmed by yourself that the ACK is indeed not being sent? Have you checked if your FreePBX is really getting the reinvite at all?
Re-invite is an in-dialog transaction. If you are not receiving it then your router/firewall is closing the path. You would likely see the same with a BYE message from the remote side. You can test this out by setting up a call from your PBX to your cell phone and leaving the call open for a while, and then hanging up on the cell phone. Your PBX should receive the BYE immediately. If there’s a delay, then the BYE is hitting the same wall as the re-invite.
I would think that simply enabling qualify on your trunk would solve this as that should keep the SIP path open between you and your provider.
I’m not sure how to check that the ACK is indeed being sent. I can say that we have another SIP provider, Twilio where we are not experiencing this issue. It’s only with this one new SIP provider.
I placed a couple calls to my cell phone and let them stay open at least five minutes. As soon as I hung up from the cell phone, the call dropped on my extension. There appeared to be no delay in hanging up the call.
The “qualify” setting for the trunk, are you talking about the “Qualify Frequency”? That’s set to 60 seconds right now.
No, the session timers on your NAT device.
You need to perform a sip debug and find what is happening when 30 minutes have been reached.
If the provider sends the Re-INVITE, it is they that have to send the ACK!
Our NAT device is a pair of Fortiguard 201e routers in an HA configuration. I would think that if the problem were with our NAT device that it would exhibit the same problem with our SIP trunks to Twilio which we have not seen any issue like this with. In fact, to get around the problem we took out the problem trunk from the outbound route and no dropping calls. So it would seem to me that there is something specific with this other provider that is causing the problem.
Cheap and cheerful diagnostic
sngrep
deeper inspection would be tsrhark/wireshark inspection of captured traffic on {UDP,TCP}/5000-5999 on your external network interface after Fortiguard has “done it’s stuff” (maybe pcapsipdump to pre-filter ?)
(There are likely in fact more than one “NAT device” in your deployment . . . )
This.
We use a Fortinet firewall and had to adjust the UDP timers to stop the re-invite causing the call to terminate. Can’t remember off the top of my head what the exact command was but this is the avenue you need to go down.
Alternatively you can use the timers=no trick on the trunk but that’s a workaround and not a fix.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.