Cisco has performed tests that placed video in the priority queue. The tests were with link speeds greater than 768 kbps and with proper CAC to avoid oversubscription. Cisco found that the placement of video in the priority queue did not introduce a noticeable increase in delay to the voice packets.
In general, you can select one of these models. Cisco has tested both models:
Voice, video, and audio in the priority queue and provision appropriately
Voice in the priority queue, with video and audio in a bandwidth queue
If I want to implement the last option which separates Voice from Video and Audio in a separate class-map within the policy-map. Please see my sample configuration and provide comments.
class-map Voice match access-group 101 class-map Video-Conf match access-group 102 class-map Voice-Video-Control match access-group 103
policy-map QoS-Policy class Voice priority 256 class Video-Conf bandwidth 512 class Voice-Video-control bandwidth 128 class class-default fair-queue
access-list 101 permit udp any any range 16384 32776 access-list 101 permit udp any range 16384 32776 any
access-list 102 permit ip any any «-- what port should i use? access-list 102 permit ip any any «-- what port should i use?
access-list 103 permit ip any any «-- what port should i use? access-list 103 permit ip any any «-- what port should i use?
Another question is that cisco also provided a sample configuration (see below) from the link I provided above. Cisco separated the Video-conf and streaming-video. I do not understand the difference between the two? One is in PQ one in CBWFQ..... but why they are separated?
Sample Configuration class-map Video-Conf match access-group 102 class-map Streaming-Video match access-group 103 ! policy-map QoS-Policy class Video-Conf priority 450 30000 class Streaming-Video bandwidth 150 class class-default fair-queue ! ! -- Video-Conf Traffic access-list 102 permit ip any any dscp cs4 access-list 102 permit ip any any dscp af41 ! ! -- Streaming Traffic access-list 103 permit ip any any dscp cs1 access-list 103 permit ip any any dscp af13
With relation to your proposed config, matching RTP based on udp ports is not the best way imho, a better way would be to match using DSCP. same as the cisco config you bring below that.
As for the difference between video-conf and streaming video, the first is for an actual call between users which is interactive (one user talks and the other answers) and delay sensitive. the streaming video is like an IPTV broadcast, a few seconds delay will not be an issue there.
Thank you for your reply. I do understand that the best way is match using DSCP but just for discussion sake, what port range should I use to separate the control singalling and data for Voice and Video. I am not sure if voice UDP port range is the same for video conferencing as pure Voice over ip. For pure VOIP i have been using these UDP ports (16384-32767) for cisco. The reason I am asking this is because I have encountered companies cannot provide DSCP markings for their contol signalling as well as RTP traffic which the Cisco router is able to do.
My goal is to identify the Control sigals and data (RTP and Video data) using port number so that i can be flexible in my QoS implementaion using the class-map with access-list.
This command matches IP RTP packets that fall within the specified UDP port range. The "match ip rtp" feature matches UDP packets destined to all even port numbers within the specified range. Its limitation is that it will match any UDP packet using an even port number that falls within the range configured. There is a risk that another application could use UDP ports that fall in the same range, as specified by the "match ip rtp" match criteria. This application traffic will now be queued in the Low Latency queue with the delay sensitive voice traffic, and might hamper the quality of voice calls. It is therefore very useful to have a classification engine that can classify applications above the port number criteria.
Control/signaling traffic uses different ports, based on what protocol is used (H.323, SCCP, SIP, MGCP) and can be identified using it's ports.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...