Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
What kind of video, real-time or streaming?
If streaming, you just try to insure packets are not dropped and packets are not excessively delayed.
If real-time, ideally you want to treat it like VoIP bearer. However depending on your situation, placing real-time video, in the same PQ as VoIP bearer might introduce too much jitter for the VoIP. In that case, you might treat real-time video as best as possible after PQ.
For instance, a logical policy like:
policy sample
class VoIP_bearer
priority percent 33
class RT_Video
bandwidth remaining 99
class class-default
bandwidth remaining 1
fair-queue
BTW, some video source, I believe, have separate streams for its voice vs. its video, if so, you might place the voice stream in PQ and treat the video portion as above.
