I come from a Cisco Call Manager voice background. My new job is involved with UCCE. In traditional voice settings (not call center environments) we had mixed success and very little adoption of IP Communicator.
My question is - are there large / high volume call centers leveraging IP Communicator successfully?
The last 2 projects I've done have been UCCE 7.X with IP Communicator for the agents. Last one I did they are handling about ~25,000 calls/day. There were some issues around versions of IPC with CVP, make sure you go to the very latest version as we had to go to an ES to resolve some issues if you are using CVP.
The previous project to that the client used IPC with extension mobility for the agents and that is something I would recommend staying away from. UCCE + IPC = fine, UCCE + IPC + extension mobility = pain. Might be better now but at the time there were only a handful of implementations around the world who had done that combination and a significant percentage of those had gone CAP (Critical Account Program. Basically where Cisco step in, kick everyone out and try to fix issues).
There's a decent cost saving in handset costs by going IPC if it's a decent sized contact centre but it's generally weighed up against risk of being reliant on PCs being up.
That's my experience with IPC and UCCE anyways.
Thank you very much for your reply. Good information. Given that it is doable - I'll now have to focus on exactly what the QoS configuration would look like on the access-layer switch ports. Per the QoS SRND - the trust boundary would have to be extended to trust the PC traffic - and then it is recommened to ACL the traffic to only trust the IPC traffic sourced from the PC and lastly to police that traffic to prevent abuse.
AutoQos can squirt you out a compatible config that is fairly reasonable. If it's old IOS, you have to use the AutoQos trust cisco-softphone variant, but on newer versions even trust cisco-phone generates the input policy.
It's basically in line with the QoS SRND; and yes, what you have outlined is a suitable way to do it.
Please rate helpful posts...
It seems strange that auto-qos would, by default, extend the trust boundary to the PC. Is that what you are suggesting?
Ok - I used your post to perform some Google searches and found this hit which gives a specific example of auto qos voip cisco-softphone that should do the trick. Thanks for your nudge in the right direction!
The Cisco IP Communicator program runs on a PC and emulates a Cisco IP phone. The Cisco IP Communicator marks its voice traffic with a DSCP value instead of a CoS value. When you configure the port to trust the DSCP value that comes from the Cisco IP Communicator, the switch uses the DSCP value to prioritize the Cisco IP Communicator traffic.
AutoQoS supports the Cisco IP Communicator program with the auto qos voip cisco-softphone interface configuration command. When you enter the auto qos voip cisco-softphone interface configuration command on a port that is connected to a device running the Cisco IP Communicator program, the autoQoS feature does the following:
•If QoS was not already enabled, enables QoS globally.
•If VLAN-based QoS was configured for the port, reverts to the default port-based QoS (done for all ports on switching modules with1p1q0t/1p3q1t ports).
•If a trust state was configured for the port, reverts to the default untrusted state.
•Creates and applies ingress policers to trust DSCP 46 and remark DSCP 26 packets to DSCP 24. Packets with other DSCP values or out-of-profile packets are remarked with DSCP 0.
Personally, I've never been a fan of IPC for the contact center, like it was mentioned you're tied to the desktop. If a PC goes down, you're out two devices, a PC and a phone. At least with a hard phone you could always have the agent make manual out calls or put them in a hunt group, etc. However, I do see the savings both in money and real estate IPC has over a hard phone.