I have a client with a VCS Control appliance running X7.2.2 s/w. QoS has been set to DiffServ with a value of 34 and the VCS rebooted. Packet captures show that no DSCP marking is being applied. The alarm status page shows no errors or warnings.
The following option keys are present; non Traversal Calls, Traversal Calls, Encryption, Interworking, FindMe, Devide Provisioning and Enhanced OCS Collaboration.
Any help would be very much appreciated.
Is the switch port that the VCS is connected to (and others within the path you're investigating) actually configured to trust and pass on the DCSP markings, or are they overriding it with the defaults?
Further to what Wayne has suggested, it might not be a bad idea to move the tagging of packets back to the endpoints. This would provide you with end-to-end tagging, however (as Wayne said), the intermediate switches and routers still need to be configure to do something with those tags and not overwrite them. The VCS has some limitations WRT to QoS marking in that ALL traffic (both media and signalling) get marked at a single blanket value. You have much more granularity when marked at the endpoint and as such you could design a more robust and extendible QoS system. If you use TMS, then you can apply template to various endpoints to update those QoS markings very easily.
Cisco have recently run some excellent webcasts on the subject of QoS which are will worth a watch.One of the best series of technical presentation I have watch in a long time.
Hi Wayne & Chris,
Thanks for the replies. This system is integrated with Lync 2010 using B2BUA, an Advanced Media Gateway and also a 5310 MCU booked via TMSXE/Outlook. All endpoints and infrastructure devices are configured to mark packets with the correct DSCP values. Every device apart from the VCSc is marking correctly. I have asked the engineer who configured the switches in the data centre where the VCS resides to confirm that it is trusting the QoS from the device.
I will update this discussion when I receive a reply to that question.
Cheers, Paul R.
A further update,
xConfiguration IP shows that QoS Mode is DiffServ and QoS Value is 34 (AF41.) The VCS is connected to a Nexus 5500 switch which trusts QoS by default. The VCS port is configured identically to the AMGW & MCU ports, and markings are seen from those devices.
Has the VCS been rebooted since the QoS was configured? The change doesn't actually take place until a reboot has occurred.
The VCS has been rebooted after the QoS was setup. Running an xconfiguration IP command shows that QoS is set as DiffServ with a value of 34.
Cheers, Paul R.
I would question why (if you have QoS tags set at the endpoints and assuming that you QoS policy across your network infrastructure (switches and routers) don't re-write tags) would to use the VCS to re-write DSCP values? I see no value in this as the VCS will override all media AND signalling with a single DSCP value, yet the CODECs and MCU will apply tag in a more refined way. As long as you are not overwriting tags, the tags should persist.
The only time I can think you might want to use the VCS to tag media and signalling is when you have video traffic cross your into you domain from outside that you don't have direct control over, and that maybe is not tagged at all.
What is the purpose of using the VCS to tag media in your deployment?
As I stated, the Cisco environment is integrated with Lync 2010 via an Advanced Media Gateway. If you check the Cisco VCS-Lync integration documents, you will observe that the media goes from VCS to AMGW, back to VCS and then via B2BUA to the Lync environment. The reason for marking the VCS traffic is to ensure that media entering the Lync environment is being given correct queuing and QoS. As the packets are not being marked, the client is having call quality issues on Cisco - Lync calls.
Cheers, Paul R.
Hmm, interesting, I will need to check this out. Are you saying that traffic traversing the B2BUA and AMGW is somehow stripped of its QoS tags? My gut feeling is that they should be preserved throughout the process.
Obviously, the B2BUA acts as a go-between for the standards based world and the MS SIP world effectively altering the SIP signalling, and the AMGW transcodes the video media stream contained within the SIP conversation, but I would have thought that and QoS tag contained in the IP headers on the packets either coming from or going to the Lync domain (and vice versa) should be preserved and copied from the input to the output. The fact that they maybe overwritten is kind of worrying and as the VCS only has a blanket hammer approach to tagging that could overwrite other, more refined values, it might be nice to dig a bit deep as to why this is happening and if it is "by design" or not.
I will look at out test Lync enviroment although we don't utilise an AMGW. Our Lync domain is base around Lync 2013, but we can test a variety of Lync 2010 and Lync 2013 clients.
Packets from the AMGW are being tagged correctly, as are packets coming from the Lync environment. Packets from the VCS via B2BUA to Lync are not being tagged. :(
Oh. My guess is that this is NOT supposed to happen. It would be nice to get a response from Cisco on this, or perhaps just other members thoughts on here. As far as I can see, there is nothing on the B2BUA WRT QoS, but I certainly would not expect tags to be overwritten.
Failing a response from Cisco, maybe a TAC case would be advisable?
Examination of a new packet capture shows that TCP & TLS signalling packets are being marked, but UDP media steams are not. I have opened a TAC case and supplied debug level diagnostic logs of calls from a Cisco endpoint to a Lync client via B2BUA and also to a Cisco CUBE neighbor zone.
I will update this conversation with any TAC resolution details.
Cheers, Paul R
I have been unable to test this as we have depreciated our use of the VCS for Lync involvement, but I am still interested to find out the results.
This is a bit of an old forum so this might be more intended for other people looking for information and run across this one.
The VCS not marking QoS on this specific media streams is expected, when the B2Bua is engaged, the VCS is not able to mark packets with QoS tagging.
B2Bua can be engaged when the VCS is doing media encryption or with Lync deployments.
See the bug below, it might be implemented in the future but it is currently working as designed.