DEVICE_STATE() function returning incorrect status


The DEVICE_STATE() function is not working as expected. For example:

Peer B is offline (no internet connection). Peer A calls Peer B. DEVICE_STATE(SIP/PeerB) returns RINGING – when UNAVAILABLE is expected.

Also if we kill PeerB process (i.e. force-stop app), DEVICE_STATE(SIP/PeerB) returns NOT_INUSE (instead of UNAVAILABLE).

Does the DEVICE_STATE() function read from a cached memory in Asterisk or does it query the state in realtime? Is there any setting we can tweak to force it to read the actual state, a refresh timeout setting maybe?

Please help!

It depends on the channel driver whether things are pulled from memory or whether the channel driver is queried. I’d suggest providing console output, setting up a hint with the device and providing core show hints, the output of sip show peer, configuration, everything possible. For example - do you have qualify enabled for the peer? Are you using realtime from a database? Do you have realtime caching enabled in chan_sip?

You could try using the SIPqualifypeer AMI action.

I use a system call to a script that uses the AMI action PJSIPQualify early in the incoming part of the dial plan.
The Script looks up the users extensions from the mysql database and then qualifies them via the AMI action PJSIPQualify.
SIPqualifypeer should do the same for channel sip.
This isn’t perfect but is about as close to realtime as your going to get.

1 Like

How do I enable/disable realtime caching? I assume it should be disabled to get accurate state results??

I assume that calling SIPqualifypeer on a peer would be the same as setting qualify to yes for that peer? Should I call DEVICE_STATE() after SIPqualifypeer? And will it then return (as) accurate (as possible) result?


It is controlled using the rtcachefriends option:

;rtcachefriends=yes             ; Cache realtime friends by adding them to the internal list
                                ; just like friends added from the config file only on a
                                ; as-needed basis? (yes|no)

Caching must be enabled if qualify configured on the peer has any hope of working.

1 Like

SIPqualifypeer would send options packets to the extension(peer) until it either responds or times out.
I would still leave qualify set to yes.
There will need to be enough time between running SIPqualifypeer and checking with DEVICE_STATE to give your extensions time to respond. How long that will need to be will depend on what your using for extensions. Some Android phones can take a very long time like 2 - 6 seconds. Some respond quickly.