Initial Custom Device States

We’re experimenting with replacing some of the HINT functionality with “Custom” Device States.

It’s working great, however, I’m at a loss on how to set an initial state without the end-user having to place a call to invoke the DEVICE_STATE() function.

Is there a way to pre-set the Custom Device State to “NOT_INUSE”?

Right now, it just defaults to “Unknown”.

Thanks for any advice :smiley:

Just something I noticed as a data point …

If all the members of a queue have an “Unknown” state, all of the members are dialed normally after a restart.

However, if just one is set to “Not in use” then that’s the only one that gets dialed.

Note that I tried to just pre-stuff the asterisk database with the values:


While the data is in the database, the queues don’t reflect what I manually inserted, even on a restart … some inner workings I don’t understand.

From the console or using the AMI command action you issue

devstate Custom:Hint100 NOT_INUSE

So devstate Custom:<customdevice> <state>

Thanks for the reply @BlazeStudios, I know how to do it manually, was wondering if I’m just overlooking a way to have a device state NOT_INUSE instead of UNKNOWN by default (so I don’t have to do it manually).

I think the reason there might not be a way to do this is that’s basically just making something up that can’t be verified. How do we actually know that all devices are not in use, as opposed to unavailable? If I powered off a bunch of SIP devices and restarted Asterisk, it would be wrong to deem them “not in use” initially. If there were such a capability, it seems like it would make it easy to mess up the correctness of device state and hence messing up other things internally.

Typically channel drivers will update the device state as they are able. I’ve noticed myself though that this can take arduously long. It certainly would be good to be able to speed this process up a bit, but that could be a channel driver issue as opposed to a device state issue.

It is a custom device not a tech based device. It doesnt have a state unless you set one. How do you expect the state to change?

@BlazeStudios thanks, got it. The default state is “Unknown”, we have to set it manually.

Options to do this are:

  1. AMI
  2. CLI
  3. Dialplan

There isn’t a way to set a default state to avoid manually setting the state to NOT_INUSE.

Big thanks :smiley:

Hacking around in devicestate.c (18.14.0) I can change the following to get the default device state to “NOT_INUSE”.

Wondering if this is a reasonable way to handle this, as my requirement is for all “UNKNOWN” device states to be treated as “NOT_INUSE”.

Not knowing what this may impact makes me hesitant to put this into production without someone who knows this subsystem’s blessing, any advice appreciated!

enum ast_device_state ast_devstate_val(const char *val)
        if (!strcasecmp(val, "NOT_INUSE"))
                return AST_DEVICE_NOT_INUSE;
        else if (!strcasecmp(val, "INUSE"))
                return AST_DEVICE_INUSE;
        else if (!strcasecmp(val, "BUSY"))
                return AST_DEVICE_BUSY;
        else if (!strcasecmp(val, "INVALID"))
                return AST_DEVICE_INVALID;
        else if (!strcasecmp(val, "UNAVAILABLE"))
                return AST_DEVICE_UNAVAILABLE;
        else if (!strcasecmp(val, "RINGING"))
                return AST_DEVICE_RINGING;
        else if (!strcasecmp(val, "RINGINUSE"))
                return AST_DEVICE_RINGINUSE;
        else if (!strcasecmp(val, "ONHOLD"))
                return AST_DEVICE_ONHOLD;

        // return AST_DEVICE_UNKNOWN; 

I posted this to the dev mailing list as well.

My thought is this is still wrong, for the reason I mentioned.

This would apply to ALL device states, not just custom ones. This very well may cause things to not function right since you are effectively treating unknown as not in use.

I think a better (safer) approach would be to add code to simply update all custom device states to a value so you could do that with a single operation.

That’s what we decided in the end, thanks again for the advice.

Cheers :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.