i'd like to become BLF lamps on an attendant console SPA500S Orange (Solid) when an extension is in the state UNAVAILABLE.
Which string i need to send from asterisk to phone via SIP Notify Subscription to achieve this goal?
Thanks in advance
Thanks Alex for your tip.
I check the config and i found that all fields in page Attendant Console relating Attendant Key LED Pattern was blank (i think the dafault values).
Could you please show me which parameter is related to the UNAVAILABLE state of an extension?
I tried Serv Subscribe Failed LED: with "c=a;p=nb" with no result.
I too see the same issue, other SIP clients understand the state 'unavailable' ie if the device is offline (not registered) - they show the state accordingly.
Using Asterisk as a back end, we can see the state listed doing a core show hints:
blah1@blah-Hints : SIP/blah1 State:Idle Watchers 3
blah2@blah-Hints : SIP/blah2 State:Idle Watchers 3
blah3@blah-Hints : SIP/blah3 State:Idle Watchers 3
blah4@blah-Hints : SIP/blah4 State:Unavailable Watchers 3
blah5@blah-Hints : SIP/blah5 State:Unavailable Watchers 3
blah6@blah-Hints : SIP/blah6 State:Unavailable Watchers 3
To all of the angry / complaining end-users', it is impossible to tell the difference between an idle or disused DN versus an offline handset!
Does anyone know if it's possible to script Asterisk in a way that we CAN give the LED's another color when the state is unavailable?
We have the latest stable Astrisk server with the Cisco SPA508G phones AND the
If the phone is not available to Asterisk, then Asterisk cannot control the color of the phone's LEDs.
The way to control the phone's LEDs is via provisioning.
For example, to use Gianluca's colors, configure the phone as follows:
The above will cause the sidecar's LED to be solid orange when a subscribe fails.
when the subscribtion failes, the color is indeed orange...
BUT the phone I subscribe to is definend in Asterisk so the subscribtion suceed!
ONLY because the phone is offline the status of this phone in Asterisk is: State:Unavailable
AND the led on the Cisco phone is green..
Can you help me understand what you mean by "ONLY because the phone is offline the status of this phone in Asterisk is: State:Unavailable AND the led on the Cisco phone is green.." please?
1. By offline, do you mean the phone was registered to Asterisk but for example, the network between Asterisk and the phone is down?
1b. What must happen for the phone to change from registered to "Unavailable".
1c. What must happen for the phone to be "offline".
2. I'm wondering if you have defined speed dial (sd). A configured speed dial LED is green once configured.
3. Are you using UDP or TCP for the monitoring phone? If you're using UDP, the phone LED state can become confused when/if SIP NOTIFY messages about the remote phone's state fails to reach your phone. If your phone's BLF LED was last told that the remote phone is registered and idle and then the remote phone goes down, but your phone never receives the SIP NOTIFY, it will continue to display a green BLF LED.
Just some ideas for you.
I have made the following script / dailplan on Asterisk (extensions.conf)
exten => 104,hint,Custom:example
exten => 111,1,Set(DEVICE_STATE(Custom:example)=UNKNOWN)
exten => 112,1,Set(DEVICE_STATE(Custom:example)=NOT_INUSE)
exten => 113,1,Set(DEVICE_STATE(Custom:example)=INUSE)
exten => 114,1,Set(DEVICE_STATE(Custom:example)=BUSY)
exten => 115,1,Set(DEVICE_STATE(Custom:example)=INVALID)
exten => 116,1,Set(DEVICE_STATE(Custom:example)=UNAVAILABLE)
exten => 117,1,Set(DEVICE_STATE(Custom:example)=RINGING)
exten => 118,1,Set(DEVICE_STATE(Custom:example)=RINGINUSE)
exten => 119,1,Set(DEVICE_STATE(Custom:example)=ONHOLD)
And subcribed one of my buttons on the Cisco SPA500s with: fnc=blf+sd+cp;firstname.lastname@example.org
(The phone SPA508G and extension SPA500S are factory default)
Unkown >> LED stays the color it was before it did get the status unknown!
Not_inuse >> LED goes Green
Inuse >> LED goes Red
Busy >> LED goes Red
Invalid >> LED goes Green
Unavailable >> LED goes Green
Ringing >> LED goes blinking fast Red
Ringinguse >> LED goes blinking fast RED
Onhold >> LED goes blinking slow Red
It would be nice to get an option in de phone to program a 'Attendant Key LED Pattern' for 'unkown', 'invalid' and 'unavailable'. This way we can program the following patterns which make more sence for us:
Serv Subscribe Failed LED >> Blinking Fast Orange
Status Unkown >> Blinking Slow Orange
Status Invalid >> Blinking Slow Orange
Status Unavailable >> Solid Orange
The issue I believe is that Asterisk keeps a state table of the phone's status and the phone has its own state table which is not really related to or controlled by Asterisk, aside from registered, ringing, busy, and so on.
I can't think of a way for Asterisk, or any other call control to affect LED behavior. The phone is preconfigured for specific general states and if a state matches, then the phone sets the appropriate LED color.
I'll check with my extended team next week to determine if anyone has a suggestion for driving the behavior you suggest.
Okay, I'm having the same problem here. I've added a BLF entry for a SIP extension that doesn't yet exist (extension 370). The Asterisk server doesn't have this extension configured at all so the only way it can know about it is from the SPA504G with the SPA500S connected.
Asterisk "show core hints" command therefore shows the extension as Unavailable.
Why does the SPA500S show extensions as green when they don't exist at all!
At the first, catch the SIP packets between phone and Asterisk. The state reported by Asterisk to phone needs to be verified. At the second, turn on syslog and debug messages (level 3) on phone and catch them. It may help to analyze the issue. At the third, start new thread for your particular issue. Your issue seems to have little relationship with the question starting this thread. You may refer this thread in description of your's issue ...
Thanks for replying to both of my threads, they are really about the same thing. Changing the LED colour for SIP extensions in an Unavailable state. I believe this is the same as is being discussed here, the fact that the SIP extension in this case doesn't exist is simply another example of how to replicate the issue.
I'll see if I can get logs but the SPA500S if deployed live now and I don't know if I'll get to tinker with it any more. I'll do my best and update with what I find.