Im hoping to check if anyone knows (or knows where to find) how long it takes to Expire a stale pjsip contact.
my use case:
User is at home, registered with a softphone (contact 1)
they undock their laptop, and it registers on their wifi (contact 2)
they come in to the office, laptop connects to wifi (contact 3)
and they dock their laptop at their desk (Contact 4)
so now, I have 3 “Unavailable” contacts and 1 active registration for this user.
In itself, that is not a problem, I am just hoping to understand the mechanism for how the system drops an Unavailable contact from a PJSIP AOR
Yes, I know that has been the guidance regarding this. I just don’t understand the use case for maintaining unavailable contacts.
I think a better way of going about this is to have remove_existing=yes first remove unavailable contacts, then proceed to expiring soonest.
remove_existing=no should remove unavailable instead of rejecting the registration. If there is good reason not to change this, then create a third option remove_existing=unavailable to have this functionality. This should be the default in FreePBX when max_contacts>1
I recently have been frequently submitting code to FreePBX.
This is a patch to Asterisk and my C knowledge is limited, as well as my understanding of the core functions like aststrdup, the different structs etc. I can at least try though but just opening this up to anyone better suited.
The Asterisk project doesn’t currently accept feature requests on the issue tracker. I’ve closed out the issue for now, if someone wants to take up the work then they could. I’ve also recorded the desire.
I disagree with most of this thread. IMO it’s far more important to complete calls successfully than to save a few CPU cycles. More horsepower is cheap!
Because they may become available again. With the (IMO inadequate) default qualify_timeout of 3 seconds, a 3 second network outage at the wrong time can cause an endpoint to be marked unreachable. Normally, the next qualify (a minute later) will make it reachable again. But if the contact were removed, the endpoint would not be reachable until the next registration. With the (IMO grossly excessive) default registration expiry of 3600 seconds, that could take up to an hour.
If your system has adequate resources, IMO registration expiry should be 2 or 3 minutes. If there is little spare capacity, perhaps 10 minutes is reasonable.
On most systems, the overhead for stale contacts is negligible, because most only occurs when the endpoint is actually called. When idle, it’s just the QUALIFY requests.
Understood. I’m not saying to remove unavailable contacts once they become unavailable. If we see another inbound registration, 99 times out of 100 it is the device that went unavailable that is attempting to reregister. I see this regularly when and endpoint behind NAT reboots - it will get a different outbound port number. If set to remove_existing=no, the registration will fail.
Yes, we can increase max_contacts but there’s no limit to the mayhem… Should it be 10x? 20x? Just junk the unavail contact. We already have twice the amount of contacts as the amount of actual endpoints.
This conversation really belongs on the Asterisk forums. My bad for hijacking this thread.
