For the purpose it’s the way SIP registration works. When an endpoint registers there is a time of how long that registration is valid for. When that time is over, then Asterisk will remove the registration. It’s up to the endpoint to re-register before expiration. This is so contacts don’t stick around indefinitely and pile up.
There is a minimum and maximum setting on the AOR, but as I don’t work on FreePBX I can’t comment on where those are. As well, your issue may still continue to exist if the endpoint doesn’t re-register early enough which is not something Asterisk can control.
According to the Asterisk log and the wireshark, it occurred at pretty much the same time of expiration. The endpoint is supposed to re-register before (for example Asterisk re-registers 10 seconds before expiration). If it re-registers at the exact moment or extremely close to it (1 second or less) there’s no guarantee of overlap and so expiration can occur. Things take time to process.
Whilst it is within the 300 seconds, as seen at the point where the packet capture was done, it is far too close to the brink for good practice. I believe chan_pjsip would start at 290 seconds, but there is advice to start at 150 seconds.
At the 800ms before expiry, seen here, the registration will timeout before the maximum number of resends of the request has been reached, so, even with perfect timing, there is a significant chance of a registration dropping out.
My guess is that Asterisk has an off by one error in the calculation of the expiry point, but with the expected safety margins, that wouldn’t be a problem.
