[cisco-voip] CUxAC queue handling

[Jamie Gale]

Hi Andre,

Thanks for your further ideas, all feedback/ideas are always welcome so we can improve the product in the best way possible.

Some of these are already under consideration for the future but I will make sure I have them all captured so I can discuss them with Product Manager.


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 14, 2011, at 7:55 AM, Beck, Andre wrote:

> Hi Jamie,
> 
> On Mon, Oct 10, 2011 at 09:45:53AM -0400, Jamie Gale wrote:
>> 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.
> 
> Ok, if this ever surfaces again, I'll try to get all the traces and screen
> shots. We have, however, meanwhile applied an overflow target that keeps
> the queue down to 16 callers, so if it really depends on the volume we had
> when it struck first, it could well be gone forever.
> 
>> 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.
> 
> Thats wonderful, neither me nor the customer expected an instant solution,
> having it on a roadmap is great.
> 
> When we are at discussing feature ideas: Do you consider to split up
> the overflow targets (so a different destination could be specified per
> reason) in some future version? I think there are a lot of scenarios where
> it would make sense to deal with a queue growing too long, a user dangling
> in there for an excessive time and - specifically - "no operator" overflow
> in slightly different ways.
> 
> Something else that I'm missing, maybe I just didn't read the docs correctly:
> When pushing the CTI Gateway/Service/Park port configuration to CCM, all of
> the CTI ports use the same template for the Phone/DN settings. In our case,
> we always have to clean up after that as MOH has to be different for the
> Gateway ports vs. the Service/Park ports. I think that's also what most
> other users want, as having the Queue MOH undistinguishable from the MOH
> when being held by an operator is quite disturbing for callers (when that
> happens to me, I always fear the operator has dropped me back into the
> entry queue for another long wait). I understand that Gateway ports are
> allocated on a first come first serve schedule, so you cannot have individual
> MOH per queue (that, of course, would be really cool, but it would require
> some kind of Gateway port grouping and may explode the number of ports that
> have to be configured) - but I think having individual templates for Gateway
> ports vs. Service ports vs. Park ports would already go a long way towards
> a solution. Or am I missing something?
> 
> Thanks a lot,
> Andre.
> -- 
>                    Cool .signatures are so 90s...
> 
> -> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-

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