CUACA and Line Status 'Unavailable'

[richb1971]

Hi all,

Came across an interesting feature 'Line status is showing as unavailable (red cross)' in CUACA Client. Cisco TAC tell me this is due to which device the Client monitors.

Static phones - CUACA uses device name - SEPxxxxxxxxxxxx

Extension Mobility - CUACA uses UDP - UDPxxxxxxxx

Jabber - CUACA uses CSF.........

Believe it or not CUACA works by which device is associated with the User BY ALPHABETICAL ORDER!!!!!!

My problem was some users hadn't logged in to Jabber so CUACA displayed the red cross (even though they had logged in to Extension Mobility so should be available!). TAC workaround was to amend the UDP description in CUCM to start with a '0' ie 0UDPxxxxxx  This allows it to be seen first.

Please someone tell me this is wrong otherwise its very bad design.

Rich

[Jonathan Schulenberg · Accepted solution]

That's interesting since the Design Guide contradicts that statement. (Page 65)

Device Selection In Version 9.1.1
The Cisco Unified Attendant Console system uses the BLF Plug-in to monitor all devices.
The attendant requests data for a device from the BLF Plug-in and displays the busy lamp status that is returned:

1. The attendant sends the following information to the CTI server:
   • DN
   • Device Name (if the option is set to use this)
   • Partition
   • Resource Identifier (RID) - This is the MAC address populated in the Contact Directory if this is set to be used
2. The BLF server sends the following information to the Cisco Unified Communications Manager via AXL:
   • DN
   • Partition
   • Resource Identifier
3. The Cisco Unified Communications Manager returns all instances of devices matching the criteria it receives.
4. The BLF server then resolves (filters and sorts) the list of device instances, leaving it with a single device for which it requests the line state.

When resolving devices, the BLF Plug-in gives priority to those using Extension Mobility (EM). EM is supported in the directory but is not supported for any System Devices, such as CTI Ports and Route Points, nor for the devices used by attendants.

1. All matching DNs are sorted by EM Count, which ensures that all Extension Mobility profiles are prioritized. If any returned devices have an EM count, the other instances are deleted from data.
2. Existing lines are sorted by Line Index. A primary line has a Line Index of 0, a secondary line has an Index of 1, and so on. The line with the lowest index is selected.
3. If multiple instances remain, they are sorted by Device Description.
4. If there are still multiple matches, they are parsed by Device name: a unique alphanumeric sort of the MAC addresses of the devices.
5. The device at the top of the list is used and its Resource Identifier returned to the attendant. This device will also be queried by the CTI server via the TAPI TSP to ascertain its Device state and the states of its individual lines.

So, based on the documentation the alphabetical sort is a fourth-tier sort criteria which shouldn't apply if a User Device Profile is found in the AXL query results.

[richb1971]

Thanks Jonathan,

Thought it sounded too poor to be true. I'll ask TAC to have a rethink :)

I was reluctant to change all the CSFs to 0CSF.

Much appreciated

Rich

[richb1971]

Hi Jonathan,

In the CUACA 'Device Resolution' Page the Users UDP and CSF both have a Line Index of '1'. If those are the same I assume it will use the Alphabetical order hence CSF.

I would expect the UDP to have a lower Line Index and thus be selected.

Any suggestions?

Rich

[Jonathan Schulenberg]

Unless I misunderstand what the first rule means, I wouldn't expect this to be an issue.

All matching DNs are sorted by EM Count, which ensures that all Extension Mobility profiles are prioritized. If any returned devices have an EM count, the other instances are deleted from data.

UDP is Extension Mobility. So, if there is a UDP associated to the user, I read this sentence to say it get selected, game over.