Hello! We are running the following:
CUCM v9.1.2
CCX v9.0.2
Cisco IP Communicator v8.6.6
For switching, we are running 6880s on a VSS core.
Our phone network is on the 10.200.0.0 subnet.
Our PC/Server network has a subnet of 10.131.0.0.
The phones and PCs each have 1GB throughput.
Recently, we moved our Contact Center employees from desk phones to Cisco IP Communicator softphones. In doing so, the IP Communicator softphone takes on the IP address of the PC which is a 10.131.x.x address, whereas before the physical desk phone took an IP address from the 10.200.x.x subnet.
Everything operates fine with one exception. The agents like to perform warm transfers when transferring calls. Meaning that if an agent is on a call and needs to transfer, they hit the "More" hotkey and then "Join" followed by typing in the extension of the person they wish to transfer the call to. That person picks up the call on their Cisco IP Communicator softphone and all 3 parties are on the line. When the original calling party/agent goes to drop off of the call, it ends the call altogether/freezes the app on the agent's computer/drops the caller. This doesn't happen on every warm transfer call, only periodically. There doesn't seem to be any rhyme or reason to it, nor does it happen to specific agents more than the others.
I opened a previous case with TAC on the IP Communicator team and after looking at CIPC trouble reports from several of the PCs the TAC engineer suggested that it is in fact a QoS issue due to the fact that the voice traffic changed from one subnet to another but that type of reconfiguration was out of his wheelhouse. It is also out of my wheelhouse as I have very little experience with QoS but I looked at the switch to see if anything in the config stuck out at me. Below is the QoS config from the core switch:
================================================================================
ip access-list extended qos-CALL-SIGNALING
permit tcp 10.200.4.0 0.0.3.255 any range 2000 2002
permit tcp 10.200.76.0 0.0.3.255 any range 2000 2002
permit tcp 10.200.80.0 0.0.3.255 any range 2000 2002
permit tcp 10.200.84.0 0.0.3.255 any range 2000 2002
permit tcp 10.200.4.0 0.0.3.255 any eq 5060
permit tcp 10.200.76.0 0.0.3.255 any eq 5060
permit tcp 10.200.80.0 0.0.3.255 any eq 5060
permit tcp 10.200.84.0 0.0.3.255 any eq 5060
permit udp 10.200.4.0 0.0.3.255 any eq 5060
permit udp 10.200.76.0 0.0.3.255 any eq 5060
permit udp 10.200.80.0 0.0.3.255 any eq 5060
permit udp 10.200.84.0 0.0.3.255 any eq 5060
permit tcp 10.200.4.0 0.0.3.255 any eq 5061
permit tcp 10.200.76.0 0.0.3.255 any eq 5061
permit tcp 10.200.80.0 0.0.3.255 any eq 5061
permit tcp 10.200.84.0 0.0.3.255 any eq 5061
permit udp 10.200.4.0 0.0.3.255 any eq 5061
permit udp 10.200.76.0 0.0.3.255 any eq 5061
permit udp 10.200.80.0 0.0.3.255 any eq 5061
permit udp 10.200.84.0 0.0.3.255 any eq 5061
permit udp 10.200.4.0 0.0.3.255 any range 11000 11999
permit udp 10.200.76.0 0.0.3.255 any range 11000 11999
permit udp 10.200.80.0 0.0.3.255 any range 11000 11999
permit udp 10.200.84.0 0.0.3.255 any range 11000 11999
permit udp 10.200.4.0 0.0.3.255 any eq 2427
permit udp 10.200.76.0 0.0.3.255 any eq 2427
permit udp 10.200.80.0 0.0.3.255 any eq 2427
permit udp 10.200.84.0 0.0.3.255 any eq 2427
permit tcp 10.200.4.0 0.0.3.255 any eq 2428
permit tcp 10.200.76.0 0.0.3.255 any eq 2428
permit tcp 10.200.80.0 0.0.3.255 any eq 2428
permit tcp 10.200.84.0 0.0.3.255 any eq 2428
permit udp 10.200.4.0 0.0.3.255 any eq 1719
permit udp 10.200.76.0 0.0.3.255 any eq 1719
permit udp 10.200.80.0 0.0.3.255 any eq 1719
permit udp 10.200.84.0 0.0.3.255 any eq 1719
permit udp 10.200.4.0 0.0.3.255 any eq 1720
permit udp 10.200.76.0 0.0.3.255 any eq 1720
permit udp 10.200.80.0 0.0.3.255 any eq 1720
permit udp 10.200.84.0 0.0.3.255 any eq 1720
ip access-list extended qos-CC-AGENT-DESKTOP-TRAFFIC
permit tcp 10.131.80.0 0.0.3.255 any eq 3001
permit tcp 10.131.80.0 0.0.3.255 any eq 3002
permit tcp 10.131.80.0 0.0.3.255 any eq 12028
================================================================================
10.200.80.0 is the subnet that housed the physical IP phones for the agents before we moved them to the IP Communicator softphones. Now the agents' softphones run through their PC via the 10.131.80.0 subnet. I have a couple of questions...
-Has anyone else experienced a problem like this before? And if so, is this in fact a QoS issue, or does it sound more like a bug?
-If it is a QoS issure, what lines of config would I need to change in the current QoS configuration on the switch to make it where the softphones received the same QoS treatment as the physical desk phones?
Any recommendations/help is greatly appreciated. Thanks!
