Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

QoS for video

I am looking at implementing qos on our network for some ip surveilence cameras and also for streaming video from a quicktime server on mostly 2960 and 3560 switches. Can I use autoqos for this or am I better off creating MQC policies? If I use autoqos what would be the best configuration.

Thanks for your help.

3 REPLIES

Re: QoS for video

Firstly AutoQoS is primarly geared around VoIP - does not really take Video into account.

Personally I always write my own QoS policy using MQC.

HTH>

New Member

Re: QoS for video

Thanks. From what I had read AutoQos seemed more for voice traffic.

New Member

Re: QoS for video

I recently had to design a global QoS solution for VideoConf installation on large dual-MPLS WAN network. Helps with DSCP tag recommendations and queuing.

HTH,

Andy

Here is a really great whitepaper on this exact topic: http://hive2.hive.packetizer.com/users/h323forum/papers/QoSforIPVideoconferencing.pdf

Details:

AF41 is therefore considered the most suitable for video traffic. As there is no advantage in treating voice packets better than the video packets in an IP videoconferencing application, AF41 should be used as

the DSCP value for both voice and video media in a videoconference. The EF marking is not a good choice for use with video conferencing for these reasons:

· Video packets are much larger than voice packets, usually as large as the maximum link

MTU size. If video packets are marked as EF then they will be allowed into the same

priority queue as voice. If a small VOIP packet enters the queue behind a large video packet

(or worse, a whole bunch of such packets), then the delay in the VOIP packet may

increase depending upon the traffic engineering in the network. Such delay will adversely

affect the performance of VOIP applications.

· Given that most EF queues are very small, using them for video traffic may lead to dropped

packets.

· Video coders tend to have much longer coding delays than voice coders, and hence giving

the audio stream(s) of a videoconference absolute priority only causes them to arrive early

and be held in order to achieve lip sync. Therefore, it does not help to put voice packets

associated with a videoconference in a queue with better service than that given to the video

packets.

187
Views
0
Helpful
3
Replies