I have installed freePBX and selected VOIP Innovations as my VOIP ISP.
I have noticed that most times after about 30 minutes on call, SIP refresh timeout drops call.
VOIP sending refresh to customer but getting no response.
Reinvites will come out from VOIP (based on SIP packet)
According to my research The SIP protocol uses a mechanism called a Session Refresh Timer. This is used to ensure the far end is still responding, to identify dropped calls and when far end network is lost. This enabled ‘dead’ calls to be cleared out, rather than hanging around forever in the event of an unclean disconnection.
When in a call, the two devices negotiate a timer, and device is nominated as the ‘refresher’, which is responsible for initiating the session refresh, using either an UPDATE or INVITE sip message.
If the timer expires without the refresh having been sent and a response received, the call is to be considered as dead and it will be dropped.
Before I start running captures and tear apart my firewall any ideas what I can try on PBX side?
Thanks in advance and any advice is greatly appreciated.
SIP ALG in your hardware firewall causing trouble. If it’s on, try disabling it.
Re-invite sent to incorrect address, e.g. because PBX sent incorrect Contact header.
Re-invite blocked by hardware firewall.
If PBX on VM, re-invite blocked by virtualization platform.
Re-invite blocked by FreePBX firewall.
Re-invite received by PBX but response indicates an error or is sent to wrong address or port.
Some things that could block re-invite would also block BYE. Make a test call from an extension to your mobile. Answer the mobile and confirm two-way audio. Hang up the mobile (without hanging up the extension). Within a few seconds, you should see the call drop on the extension. If not, we have something easier to debug. A SIP trace should show what’s wrong.
To see SIP traffic at the PBX, at the Asterisk console type pjsip set logger on
(for a pjsip trunk) or sip set debug on
for a chan_sip trunk.
If incoming BYE works ok, the SIP trace will show whether the re-invite reaches the PBX. If it doesn’t, a packet capture with tcpdump on the PBX will show if firewall software on the PBX is blocking it (the capture is in front of iptables).
If tcpdump doesn’t see it, it’s likely blocked by your hardware firewall. Make/model? Forwarding traffic from VI explicitly? If not, what are you doing to keep the NAT association open, e.g. qualify requests? Do you have a way to capture traffic on the WAN interface?
Are you using an ISP-supplied gateway? If so, provide details; that could also be blocking the re-invite.