After the expiry of a contact due to “maximum_expiration” or by manually removing it: “database del registrar/contact …” it appears that Asterisk is sometimes unaware of an extension’s devstate and it’s impossible to correct/refresh those devstates automatically.
For example: when a device is registered to another node (multi PBX environment), the devstate on this node falsely remains “NOT_INUSE”.
The only workaround I have is to temporarily disable the aor from pjsip.conf and to a “pjsip reload” to reset it to the default “UNAVAIBLE”.
Is there any way I can make Asterisk regenerate its devstates by looping over all existing contacts for example?
You might configure a script to connect to Asterisk and parse out the NOT_INUSE devices, then do something else with that list eg. try to qualify them.
I currently have two asterisk instances behind a F5 bigip loadbalancer. This is working pretty great.
Before initializing a call from one instance to another, I’m simply requesting the devstate using a custom module. This output is exactly the same as a routine check done with AMI, so there is no issue within that module.
The problem is that when I manually delete a contact, for example: database del registrar/contact 205430;@b3bb87259890bedd413682c9dc0eb5ce
And when requesting the device state afterwards, the node where I deleted this contact still suggests that the device is NOT_INUSE:
I know that doing a manual delete isn’t best practice, but I’ve seen this happen at random times too (maybe because of maximum_expiration?).
When the problem occurs, the device in question has registered to the other node (thus not sending a new register (aka re-creating a contact) to the node that has the wrong devstate.
Deleting it from astdb directly is not supported, and there’s not really a mechanism to delete a contact except the normal way (a REGISTER that removes it). This is because there’s nothing in astdb that tells device state it was deleted.
So basically, the parameter “max_expiration” will also remove the contact but without resetting the devstate since there’s no register that removes it?
No, max_expiration does not inherently do that. It controls the Expires value which is used as part of the REGISTER itself. This Expires time controls the lifetime of the Contact, once it passes it is removed and the device state updated. The endpoint in question could request a lower one if it wanted. The max_expiration just sets a maximum. I haven’t seen any reports of the device state failing to update for anyone, so you’d need to provide logs and details for how to reproduce/specifics.