Table Of Contents
Frequently Asked Questions for the Design and Implementation of IP Video Surveillance
Created: August 25, 2009
The recording of the Network Design Best Practices for IP Video Surveillance—Cisco Knowledge Network is available at the following URL:
The recording and presentation of the Design and Implementation of IPVS - Cisco Design Zone Webinar is avialable at the following URL:
The following are frequently asked questions about the design and implementation of the Cisco Video Surveillance (IPVS) solution.
Q. How does quality-of-service (QoS) differ for video versus VoIP?
A. The Cisco recommendation is based on RFC 4594 (Configuration Guidelines for DiffServ Service Classes). Cisco recommends a 12-class service policy to include various forms of video traffic in addition to VoIP. In addition to a class for VoIP telephony, Broadcast Video (Video Surveillance/Enterprise TV), realtime interactive (Telepresence), multimedia conferencing (desktop collaboration) and multimedia streaming (VoDs/Digital Media System) are included. For IPVS, the media is marked DSCP CS5 and signaling is CS3. These can be marked by the either the camera or the Layer-2 switch. These value map nicely to the three-bit values for Layer-2 CoS and by default put IPVS in the appropriate ingress and egress switch queue.
Q. I understand that IPVS media is to be marked CS5 for Broadcast Video. Would Digital Signage or Enterprise TV with streaming video be in the Broadcast Video class as well?
A. Digital Signage and Enterprise TV would be provisioned in the Multimedia Streaming class (AF3 per RFC 4594); however, live Enterprise TV events may be assigned to the Broadcast Video class.
Q. Because Cisco IP cameras and switches both support Cisco Discovery Protocol (CDP), what is the constraint if the network does not have a Cisco infrastructure, then not CDP?
A. IP video surveillance can still be implemented on a network that is not both Cisco IP cameras and switches; the network manager will not simply have this management and troubleshooting tool available.
Q. Why is the IPVS media stream placed into the CBWFQ instead of priority queue?
A. An IPVS media stream can be placed into either a CBWFQ or priority queue, depending on how much priority queue traffic currently exists on the network. As a rule of thumb, no more than 33 percent of the bandwidth should be allocated to the strict priority queue. Both MPEG-4 and H.264 are more sensitive to loss than latency or jitter. Adequate service levels can be achieved via CBWFQ. The RFC 4594 (Configuration Guidelines for DiffServ Service Classes) allows the Broadcast Video class (which is used for IPVS) may be provisioned with a strict priority (EF) service; so LLQ is an option.
Q. Is DSCP used as CS5?
A. Yes, this is based on the RFC 4594 recommendation that IP Video Surveillance be included in the Broadcast Video traffic service class. Cisco is marking this class to CS5. See the following link for more details: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp60882
The most significant of the differences between Cisco's QoS baseline and RFC 4594 is that the RFC 4594 recommendation to mark Call Signaling to CS5. Cisco has completed a lengthy and expensive marking migration for call signaling from AF31 to CS3 as such, there are no plans to embark on another marking migration in the near future. It is important to remember that RFC 4594 is an informational RFC (in other words, an industry best-practice) and not a standard.
Therefore, for Cisco recommended designs, RFC 4594 marking values are used throughout, with the one exception of swapping Call-Signaling marking (to CS3) and Broadcast Video (to CS5). On all Cisco unified communications products, Cisco marks signaling traffic (by default) to CS3. However, this marking value is user-configurable.
Q. Does jitter result in packets out of order? We had problems previously with VSM deployments over wireless with large packets out-of-order. Did you test larger jitter?
A. Jitter alone will not result in out-of-order packets. Wireless can have other issues (for example, multipath issues and retransmissions) that can cause out-of-order packets. Only if traffic is being load-balanced across multiple paths would this be a consideration. However, the design recommendations of a dedicated queue (and potential LLQ) will minimize jitter effects.
Q. Customers have asked for H.264 support. Are we looking for H.264 support for the SD cameras as well?
A. The HD cameras (4000 series cameras) support H.264 and Motion JPEG. The SD cameras (2500 series cameras) hardware does not support H.264. The 2500 series cameras support MPEG-4 and Motion JPEG. The data sheets are available at the following URLs:
Cisco Video Surveillance 4000 Series IP Camera:
Cisco Video Surveillance 2500 Series IP Camera:
Cisco Video Surveillance 2000 Series IP Domes:
Q. What are some of the bandwidth issues that must be considered when transporting video surveillance feeds over the IP network?
A. First, let us provide some ranges of bandwidth for different encodings. A Cisco 2500 series SD camera in 4CIF/D1 using MPEG-4 generally a Constant Bit Rate (CBR) value of 1-2Mbps is a good starting point. A Cisco 4000 series HD camera in 1920x1080 (1080p) at a CBR rate of 4 or 6Mbps is a good starting point. In a LAN environment, these data rates are easily handled by the access layer switch and aggregated into the distribution and core layer in the campus.
In the WAN, with a T1/E1 link, more bandwidth is required than the 1.5/2.0Mbps for T1/E1. The key is to archive video locally, on the LAN and only transport the video that is needed remotely over the WAN.
Q. Regarding the bandwidth and file size of video archives, is it our compression algorithm the challenge with file sizes or do all our competition have the same problem (i.e., is it a standards-based issue rather than a vendor issue)?
A. This is a function of the CODECs. All vendors will have this issue. While MJPEG and MPEG-4/H.264 have different advantages and disadvantages, in terms of bandwidth consumption, with everything else being similar, Motion JPEG consumes the most bandwidth, then MPEG-4, and H.264 is most efficient.
Q. Any comments on deploying WAAS for IPVS? Either to send the data to the central office or for backup?
A. We have looked into WAAS for IPVS. Since video is already highly compressed by the CODEC, you typically do not see significant improvements with WAAS and video traffic. WAAS can help to a certain extent, but not as much as with other types of media.
Q. Don't you still get some optimization with TFO in WAAS?
A. IPVS using MPEG-4 uses UDP/RTP, which would be unaffected by TFO. Because of the data rates required for transporting video surveillance (DS3 or higher) the serialization delay attributed to the interface is minimal compared to lower bandwidth links like T1/E1. Additionally, the links must have low loss characteristics to be suitable for transporting video. Because of this, the advantages of TFO are less pronounced for the TCP transport of either MJPEG of video archives transported as iSCSI.
Q. So the bottom line is that DRE does not really improve the amount of data being sent, which means it is not part of the recommended deployment. Is this correct?
A. There is only a modest improvement, 5 to 10 percent range.
Q. How high of a frame rate would a high security camera typically require?
A. It depends on several factors. Direction of motion within the view of the camera is one. If the subject is moving toward the camera (vertically within in the frame), less frames per second (fps) is needed if the motion is from left to right within the frame. The velocity of the motion is also important, and that is also relative to how close the object is to the camera. Some rules of thumb are 2 to 3 fps for parking lots with wide field of view, 5 fps for school hallways, 12 to 15 fps at cash registers.
Typically, full motion video is not required for surveillance applications. Movies are 24 fps as a point of reference. The Cisco 4000 series supports 6 fps at 1280 x 720 (720p) and 30 fps at 1920 x 1080 (1080p) resolution.
Q. Why are there different lenses for HD and SD cameras?
A. You can use a lense from a HD camera on a SD camera. If you use a SD rated lense on a HD camera, the resolution of the HD camera is much better and you will see imperfections from the lense that may distort the image.
Q. I am new to IP Video Surveillance. Do you have a portal or community I can join? What do you recommend to get started?
A. The Design Zone for Video is a good starting point. The URL is as follows: http://www.cisco.com/en/US/netsol/ns819/networking_solutions_program_home.html
Q. What is the minimum bandwidth required over WAN?
A. Bit rates for MPEG-4 range from 5Mbps to 56Kbps and frame rates for MJPEG range from 30 fps to over a frame per minute. Higher values generate more data every second, translating into smoother video and a more accurate representation of the scene.
Q. Do you have any basic recommendations for SD/HD IP cameras parameters (bandwidth, quality and frame rate) for standard deployment scenarios (street view, room, etc.)?
A. There are resource available. First you need to consider the business requirements. Is the scene an overview or a detailed view? The overview deployment is where you are looking for things like traffic congestion or parking lots. You need less detail and a lower frame rate for an overview. And a SD camera at 4CIF/D1 resolution with less than 5 fps is a good starting point.
For a detailed view, where the goal is face recognition, you need to consider the number of pixels per foot. Generally face recognition requires 80 - 150 pixels per foot (ppf). Consider a 7-foot high doorway. To cover that space at 150 ppf, the camera placement would need to encompass (7 feet x 150 ppf) 1050 pixels to cover the doorway area. In this deployment, a HD camera with a frame rate of 5-10 frames per second at 720P or 1080p might be a good starting point.
Q. I have heard that there is a standard organization called PSIA. How does this impact video surveillance deployments?
A. There are organizations looking to standardize physical security:
PSIA: http://www.psialliance.org/ lead by Cisco, Panasonic, Pelco, Honeywell, GE, DvTel, Verint, and IQinVision.
ONVIF: http://www.onvif.org/ lead by Axis, Bosch, and Sony.
Standards allow for interoperability between network video products from different manufacturers. For the consumer, they decrease costs and foster competition.
Q. When suggesting IP video cameras, I constantly hear the argument that IP video cameras still suffer when in an outdoor environment due to daylight. How would I combat that argument?
A. The Cisco IP cameras have day/night operation. There is an IR filter that automatically switches to night mode in low light scenes. There also is automatic white balance (AWB), automatic back lighting, automatic gain control (AGC), and auto/manual iris. The Cisco IP cameras offer excellent image quality compared to analog cameras as well as the IP cameras of other manufacturers. Demonstrating the image quality in the intended deployment environment is the best way to counter that argument.
Q. Is there any advantages for cameras to have PoE+?
A. Power-over-Ethernet (PoE) is important to facilitate installation of these cameras as a single Category 5 Ethernet cable can provide both Ethernet connectivity and power-reducing installation costs. The Cisco IP cameras support Cisco Discovery Protocol (CDP). Currently PoE is sufficient to meet these needs; PoE+ may be able to provide additional functionality to future cameras, because of the higher power levels delivered.
Q. Does the NME-VMSS-HP16 module having PoE feature?
A. No. The module does not have an integrated switch for connecting cameras. To connect IP cameras at the branch, you need either an external access switch or a Cisco EtherSwitch Service Modules with IEEE 802.3af Support for the ISR router.
Q. How do you determine how many cameras can be supported on one Media Server?
A. The general guideline is a Media Server should not have more than 200Mbps of input and output traffic. The input traffic is for the most part, camera feeds. The output from the Media Server is viewing of live or archived feeds. If there is little or no viewing, more cameras could be supported and keep within the 200Mbps aggregate of both input and output.
Q. Are all video streams viewed by `proxy' from the Media servers?
A. The video flows from the camera to the media server. The clients do not watch video directly from the cameras.
Q. Can you correlate between frame rate in motion JPEG versus frame rate with H.264 in VSOM?
A. In both H.264 and MPEG-4 a CBR, constant bit rate (CBR) value is specified the CODEC adapts the frame rate to target the CBR value. In MJPEG, the resolution and the frame rate will determine the bandwidth required. There is no concept of a CBR target with Motion JPEG.
Q. Will you be discussing local storage options for IPVS using iSCSI appliances and how to integrate these third-party devices?
A. There is a whitepaper on iSCSI at the following URL: http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/IPVS/ipvs_iscsi.html
Q. How high a frame rate would a high security camera typically require?
A. Motion pictures use a frame rate of 24 frames per second. Video surveillance generally does not need full motion video. In some instances 1 to 5 frames per second is sufficient, but in most cases 12 to 15 frames per second is adequate. It depends on the business requirement how fluid the motion must appear. A higher frame rate means more bandwidth and storage for the archive.
Q. Are there any resources for calculating adequate frame rate for high velocity motion? Such as speeding vehicles?
A. The frame rate required is also a function of the direction of the movement. For example, if the vehicle is moving from left to right within the frame, a higher frame rate is required than if the vehicle is moving vertically, either toward the camera or away from the camera. It also depends on if the objective is to show an overview, where you only care about traffic congestion or the make, color and model of vehicle, or a detailed view, where you are trying to identify a license plate. The best advice is to conduct a pilot installation and try different cameras, resolutions and frame rates.
Q. What is FCAPS?
A. FCAPS is an acronym for Fault, Configuration, Accounting, Performance, Security which are the management categories into which the ISO model defines network management tasks. Network management software and systems can monitor the availability of IP video surveillance cameras and network servers and verify the service levels of the network path between these end points.
Q. Comparing to the analog install-based, are the built-in anti-tempering features (e.g., SNMP, CDP) on par with them?
A. Tamper resistant domes are commonly deployed in both analog and digital video cameras. Cisco is shipping the Video Surveillance 2400 Series IP Dome camera for this market. Enabling port security on the switch port can be an effective tool to alert the network management station if someone unplugs the cameras and attempts to access the network through the network port of the IP camera. However, the network management system must be configured to alert an operator to take action immediately because the video feed is disrupted even if the camera is attached again on the same switch port.
Q. I noticed the requirements indicated a Media Server and Operations Manager. Can these be collocated within the same appliance?
A. Yes. However, as the number of Media Servers grows past the single instance, it would be a good consideration to implement a dedicated Operations Manager.
Q. I looked at the link but do not see the security whitepaper that was mentioned with VRFs and encryption?
A. The whitepapers are available from this main link. http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/IPVS/ip_video_surv.html
Q. Does Cisco offer an IPVS certification?
A. Not at this time. Our full list of certifications are listed at the following URL: http://www.cisco.com/web/learning/le3/learning_career_certifications_and_learning_paths_home.html
Q. Do we have a book coming out on Video Surveillance Fundamentals anytime soon?
A. No, but there is a design guide published in August 2009, which can be accessed at the following URL: http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/IPVS/IPVS_DG/IPVS-DesignGuide.html
Q. Can you also talk about Cisco's recommended practices to protect against some attack vectors I'm currently seeing used against IP surveillance systems like IP video sniffing, ARP poisoning, over writing stored video data with old video data, DoS attacks, etc?
A. We are seeing some customers implementing separate VRFs on their networks for isolation of video surveillance deployments. Refer to the white paper at the following URL:
Another white paper specifically around network security can be found at the following URL:
Q. What is the latency between what is being recorded and what is seen?
A. That would be (the encoding time of the camera) + ( network travel time) + (decoding time of the viewing station or PC). The total time would typically be less than 500 msec. You can view recorded video anywhere from 1 to 90 seconds after "live time" depending on where in the recoding process you request to view.
Q. How can I integrate the VS with a multicast architecture?
A. Multicast feeds are available between some cameras/encoders and the VSMS (Media Server). There is no multicast needed between the VSMS and viewing clients.
Q. When planning the bandwidth for a video network, if the cameras themselves take up about 1 to 2MB/S for sending the video to the VSM, is it the same bandwidth for the video streaming from the VSM to the client application?
A. Yes, unless you are using MJPEG and requesting lower framerate at the client.
Q. If I have a video wall showing 30 video streams, do these streams match in size to the streams coming from these cameras to the VSM server?
A. Yes, for MPEG and H.264 and depends for MJPEG. The VSMS does nothing to change the size of the streams unless you are using MJPEG and changing frame rate requested by the client.
Q. Does a client have the ability to request live and/or archive video at a reduced rate from what was recorded?
A. Yes, but only with MJPEG.
Q. What is status of record on motion with 2500 cameras. Will it be in next release?
A. Record on motion is supported with a workaround (immediate setup of record on motion after the camera is added to VSOM) in 4.2/6.2. The need for the workaround will go away when the 2.1.2 firmware for the 2500 becomes available very soon.
Q. Is it a parameter in the API when our application is requesting the video feed?
A. Yes. When using MJPEG, live proxies can be setup at one framerate(high or low), recoding can be setup at a framrate <= the live proxy framerate, and the client can request a framerate <= the live proxy or archive (recorded) source.
Q. Is there a new version or alternative to Smart Search available? Or will be made available in the near future? The "indexing time" is significant.
A. We are looking into improving Smart Search in a release that will be available in approx 10 months. We agree that the index time is too large, using realtime motion events today can be a great alternative.
Q. Can we use PfR for voice as well? If so, what is the requirement?
A. Yes. Refer to the following PfR design guide for details:
Q. Does the wireless camera support 802.11n? Do you have any design guide for wireless architecture?
A. The wireless SD2500 camera supports 802.11 b/g.
Q. Any general timelines for integration of VS with physical security and DMS?
A. Clips from VSM can be sent through the MXE for display on the DMP today. Live feed support will be available in a future release.
Q. In what release will there be support for streaming from IPVS to an DMP live?
A. Not committed yet.