[cisco-voip] CUxAC queue handling

[Jamie Gale]

Hi Andre,

The first issue is not something I have heard of or seen before, I will try to replicate it in my lab with a high call volume. If you do see it happen again then it would be worth gathering the traces from the client and server along with some screenshots and then a case can be opened with TAC to investigate, I realize that taking screenshots whilst having high call volume isn't ideal but think we will need it regardless.

The second item is something that cannot currently be done but I have added to a feature tracker in order to try and get this implemented as part of a new release.

Kind Regards

Jamie Gale
Technical Marketing Engineer, Cisco Unified Attendant Consoles
Arc Solutions, onsite at Cisco
IP Communications Business Unit
jamgale at cisco.com
D +1 919 392 4671
M +1 919 699 4910

Join the Cisco Unified Attendant Console Forum at Arc Solutions! http://forum.arcsolutions.com/forumdisplay.php?f=4

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html





On Oct 10, 2011, at 9:09 AM, Beck, Andre wrote:

> Hi,
> 
> at a customer using CUBAC for some weeks now, two questions arose:
> 
> 1) Under heavy load (a full E1 PRI sinking into a queue, with up to 30
>   calls waiting), some long-waiting calls suddenly didn't bubble up
>   to the top any more. While there were a lot of calls waiting for
>   a shorter time, scrolling down the queue revealed some entries that
>   were already waiting for 25min or times close to that. The operators
>   simply didn't notice first, as they are used to the longest waiting
>   calls being always on top (unless calls from other, priorized queues
>   would preempt them). While I was struggling to prepare for making
>   a screen shot, the whole issue disappeared as suddenly as it came,
>   and sorting was back to normal - the excessively long waiting calls
>   were gone and the order was correct again. I don't know whether the
>   callers just gave up or the operators picked them manually from the
>   middle of the queue, though.
>   Anyone ever seen this in CUBAC (or another CUxAC)?
> 
> 2) Queue entry coloring is currently hardcoded to show internal numbers
>   in blue, while external numbers get a red background. That seems to
>   disturb operators at this customer more than it helps them, and they
>   ask why it doesn't color the entries by queue instead. They have three
>   queues, a high-traffic low-priority queue and two rather low-traffic,
>   but important ones. While the important calls pop up on top, they would
>   like more visual feedback so they even might put a current caller on
>   hold in order to answer a priority call. Colorized entries, especially
>   if the queue color would be configurable, would help a lot with this.
>   They have noticed that the "All Queues" selector already has an icon
>   visualizing multiple queues as individually colored entities, so they
>   assumed that could be configured in some way - but I didn't find anything
>   helpful yet. Maybe it's on a roadmap? If not, maybe it's a good idea
>   to consider the feature? The console is already configured to show
>   routing information, so the name of the queue is displayed in the list.
>   IMO that would be the text that could easily be colored in a unique
>   way, ideally with user-configurable colors.
> 
> TIA,
> Andre.
> -- 
>                    Cool .signatures are so 90s...
> 
> -> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20111010/a1aa9abf/attachment.html>