I currently running Callmanager version 8.6 Attendant console server 8.6, and the Attendant console client version is 8.6.
Having some issues with Qos. I have a remote site that runs a multilink connection. I have a policy-map in place that works fine with SCCP phone to SCCP phone. My issues is when the link gets congested I have issues with the Attendant console client. After reading some documentation. It appears to me that the Attendant console client packets are getting marked as best effort instead of AF. I have heard two different things so far. The UDP ports are random coming from the client to the AC server. I have also seen some documentation saying just to configure the qos for port UDP 4321 for call control. Has any one ever configured a policy-map for this? Not sure what the ports are. I have a TAC case open for this information but them seem to not know at this point. So when the link get congested I have no issue with voice SCCP to SCCP. Just using the AC client. What happens is when the call comes in they can't transfer the call. I believe that is because the call control from the client to the AC server is being marked as best effort, instead of AF.
Regarding the Attendant Console - QoS marking issue, Cisco doesn't recommend any QOS configuration on Windows clients with respect to Attendant Console application.
However, a possible way is by prioritizing certain ports is on the Switch for QoS.
Please check the below link for these ports (Cisco Unified Attendant Console Ports ):
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucmac/arc/CUAC_V9_Design_G.pdf (Page 2-13)
Check Table 8 in the below link:
Also, on researching about the QoS concept with Attendant Console, I cam across an old defect which is postponed as of now, and does not have any document updated for the same. You can refer to the below defect:
CSCdz76356 Attendant Console client not marking QOS on Call Control packets
Keeping the above in mind, I would recommend that, if this is really a problem with QoS over WAN, get in touch with the network team, or otherwise open a case with TAC to ensure the call transfer failure is actually happening because of network congestion or if there are some other AC related issues.
Hope this helps.
I had read most of the doc’s already. Since I could not find a for sure answer on the ports. I just created an ACL and matched all traffic going to the AC server. Seemed to have fixed my issue.