video/data

Unanswered Question
Sep 14th, 2008

Dear Sir,

I have a query on video/data traffic. I have a head office and two branch office .The two branch offices were connected to head office through leased line. In branch office we are having CC cameras (not Cisco), for monitoring the staff .As the monitoring is done at head office my data traffic is going down. I came to know that QOS will help me in this issue .Please help me to resolve this issue.

Please find the attached doc.please give me configuration example also...

Regards,

satya.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Giuseppe Larosa Mon, 09/15/2008 - 02:51

Hello Satya,

first of all I would look at the cameras configuration because using a lower definition for the video stream will allow to use less bandwidth.

Once that there is some space for traffic you can use modular QoS to provide some resources to data traffic.

You need to define traffic classes with the class-map object

Let's suppose that the video stream use RTP realtime transport protocol

access-list 125 permit udp any any eq 16232 range 16232

class-map video_traffic

match ip address 125

policy-map scheduler-2mbps

class-map video

bandwidth 768

class-map class-default

fair-queue

on interface outgoing the branch router

int ser0/0

service-policy output scheduler-2Mbps

we had similar issues and we had to use a lower definition so that the video stream had a lower bit rate.

in other words: if the camera is sending 3,5 Mbps of traffic over a 2Mbps link the QoS can help to allow other traffic to pass but the the video stream will be unusable with high drop percentages.

Hope to help

Giuseppe

Joseph W. Doherty Mon, 09/15/2008 - 04:10

Giuseppe makes a great point about whether the video cameras can adjust their bandwidth demand! If there are various camera picture quality and/or picture size settings, it's often helpful to use those that demand the least amount of bandwidth yet still meets your viewing requirements.

You do want to know what the expected bandwidth demand for the video stream will be, and as a rough rule, you'll likely not want to use use a video stream that consumes more than 1/4 to 1/2 the link's bandwidth. This both to allow bandwidth for your data and to also allow some video bandwidth headroom since many video stream's actual bandwidth demand, at any instant, can be much higher than its average demand.

Giuseppe's example is good, but if this is all new to you, here are thoughts to hopefully further clarify his example.

First, Giuseppe's example appears to be assuming a E1 least line with a 768 Kbps video stream. Whether you have an E1 or T1, fractional variant of either, or even other WAN technology, the intent is really the same. Namely to insure your video steam obtains the bandwidth it requires. I.e. the principle is what's important, not the name of the policy with "-2mbp" or "bandwidth 768".

Second, Giuseppe's example assumes the video stream is running across RTP. What's important is that the video stream is correctly identified. Giuseppe's example of using RTP might work just fine, but there are often other methods to match the video traffic. Another method might be to match source and/or destination IP addresses.

There is one possible problem with Giuseppe's example, and that is, using FQ within class-default while placing video into its own non-LLQ class.

Giuseppe's example is 100% correct, from a text book perspective, but my reading of other Cisco documention has led me to believe class-default FQ, on many Cisco platforms, can keep the other defined classes from obtaining the bandwidth specified for them. If this is indeed a problem, Giuseppe's example could be amended one of two ways:

policy-map scheduler-2mbps

class-map video

bandwidth 768 (or bandwidth percent ##)

class-map class-default

no fair-queue

or

policy-map scheduler-2mbps

class-map video

priority 768 (or priority percent ##)

class-map class-default

fair-queue

PS:

BTW:

Depending on your overall traffic, and what bandwith the video stream needs to work well, just FQ, alone, might work for you. This could be done as:

interface serial#

fair-queue (normally the default on E1 and slower - if default, might not show in config - you don't want to see "no fair-queue" in the config)

or

policy-map yourPolicyname

class class-default

fair-queue

interface serial#

service-policy output yourPolicyname

Marwan ALshawi Mon, 09/15/2008 - 05:56

Giuseppe great add this is 5 point :)

just about the rtp range u were mean:

range 16384 32767 right ?

Giuseppe Larosa Mon, 09/15/2008 - 09:31

Hello Marwan,

thanks for your good remarks.

We had the same problems some mounths ago and the three cameras were consuming more then 10 Mbps together with default setting, after tuning they used 3 Mbps allowing space for data traffic.

I was meaning the range of RTP udp ports but I didn't check with a working configuration so I can remenber wrong both the command syntax details and the port range.

I also think that Joseph added value to the config the priority queue should be a much better choice.

Best Regards

Giuseppe

Actions

This Discussion