Possible to change the trunk Reregistration before Expiration setting?

[tythomas (ETT)]

I’m trying to find where to modify something like a “Reregistration before Expiration” setting for my trunk. But I can’t find it, and I’m even sure what the setting is called.

Example…

If I go to Settings > Asterisk SIP Settings > Chan SIP Settings, I find the following.

Registration Default Expiry : [120 is the default]

Then under Reports > Asterisk Info > Registries, I can see the “Refresh” column shows “105” for my trunk.

If I change Registration Default Expiry to something like 300, the refresh will change to 285.

In other words, trunk Refresh is always 15 seconds before the Registration Default Expiry.

But sometimes my pbx clock and my sip server’s clock may drift more than 15 seconds apart, causing brief gaps in registration.

Is there a way to change that 15 second offset? I’d like to make it something like 30 or 60 seconds.

Thanks in advance.

[Stewart1 (Stewart)]

Sorry that I don’t know whether chan_sip or pjsip offers an option to alter the re-registration time.

However, assuming that your system is connected to the internet, something is wrong if the time is off by more than one second. By default, chronyd should be running and accessing NTP servers as needed. Possibly, your firewall is blocking access to NTP.

If your provider’s clock is off by more than one second, open a ticket and let them know. However, registration does not depend on absolute times at the server end; even a large offset should not cause loss of registration. But if the server suffers a sudden jump in its system time, it’s conceivable that it would incorrectly assume that your registration had expired.

If you have a static or de facto static IP address and your provider supports it, have them send calls directly to your IP, eliminating all causes of lost registration.

[TheWebMachine]

Consider this: Does Asterisk count re-reg times by setting a timestamp/‘alarm’ or does it simply start counting down from 120? If the latter, then any shift in the RTC would be entirely irrelevant to re-registration timers. From a programmatic standpoint, I’m not sure it would make sense to store a bunch of re-registration alarms for set timestamps when countdown timers would require fewer resources overall (vs scanning a long list of alarms every second)…so I suspect countdown timers are used here

That said, your trunk provider is perhaps setting this (time-15sec) offset on their end, which explains why you always see a lower number no matter what you set. This makes a little sense, if you think about it. We really don’t want to wait until the absolute last second to start trying to re-register or we risk missing the window and falling off. Since re-registrations in ye good ol’ days could take a couple seconds over slower networks or even require retries on congested networks, I believe 15 seconds of grace would fall into the “legacy” support category.

The way you should be tackling this is by setting Min, Max, and Default within a reasonable range. Your Max should be higher, and your Min lower, than your Default; 30 Min, 60 Default, 120 Max has always worked well in our deployments. This allows both servers to negotiate a re-registration timer that is suitable for BOTH parties. If you set the range too narrow, and your Trunk provider doesn’t want to accommodate something in that range, you will get unexpected results.

Even still, I doubt the RTC shifting due to an NTP update would affect this at all…most servers only resync over NTP every 60 minutes at most, some far less frequently than that. Public NTP servers won’t let you poll them more than once every 5 seconds, anyway. If you have a clock drifting that fast at either end, someone has a HARDWARE problem, not a software problem. RTCs just don’t drift like that…the physics of quartz is pretty solid.

In a related setting, you should have your Registration Timeout - which is how long Asterisk will wait for a current [re-]reg attempt to timeout without proper response before trying again - set to a low, but not crazy low number. I’d stay at 10 seconds. You could go a little lower, but I wouldn’t set it less than 5 (avoids flooding). IIRC, the launch time default is 20 seconds, which is generally fine for most deployments, but you can try lowering it if you are having re-reg issues.

[tythomas (ETT)]

Thanks guys, for the suggestions.

I guess I’m still unable to determine if the 15 second “pre-expiration” timer is set by the PBX, or by my service provider.

They have a web panel that shows the registration status and expiration in clock time (not duration). So it is a little hard to determine where the discrepancy is.

But if I refresh that status page towards the end of registration period, there’s about a 5 or 10 second period where the registration disappears. So any inbound calls during that period will fail.

If I try to set registration any lower than 5 minutes, it won’t go lower. So I think the provider has a 5 minute minimum on their side.

I can set the registration period fairly long, like an hour, to minimize the percentage of downtime.

However, it would be nice to figure out a way to get the downtime to zero.

If anyone know how to adjust that 15 second gap from the PBX side, let me know.

Meanwhile, I have a ticket open with the provider to see if they can spot the problem on their side.

Thanks again.

[Stewart1 (Stewart)]

Unless your provider requires registration (they won’t send calls to an IP address or SIP URI) or you don’t have a static or de facto static IP address, just stop using registration.

When you get a 200 OK response to REGISTER, the Contact header contains an expires tag e.g. expires=300. Asterisk subtracts 15 from that value and initiates a new registration after that many seconds.

At the Asterisk command prompt, type
sip set debug on
which will cause a SIP trace to be displayed on the console and included in the Asterisk log.

At a root shell prompt, type
ntpdate -q pool.ntp.org
which will tell you how much your system clock is off. If more than one second, find out what is wrong and fix it.

Using the timestamps in the Asterisk log, the responses to REGISTER and the expiration times shown by the provider, you should be able to determine where the problem lies.

Some providers send a Date header on an incoming INVITE. If yours does, you can determine if the provider’s clock is incorrect.

[tythomas (ETT)]

I asked my provider to refresh NTP time on their servers.

Amazingly that solved the problem. They’ve set a daily cron to avoid problem in future.

Now my trunks reregister 15 seconds early, and all is well.