Subscriber Discussion

How To Identify Network Problems In IP Video Systems

UE
Undisclosed End User #1
Sep 10, 2013

We design and deploy camera systems on a regular basis.

The systems usually range in size from 12 to 48 cameras, exclusively IP based. Communications paths are usually provided by our IT dept. on VLANs with in our back office networks.

Our dept. contracts the camera installations and administers the VMS servers, including configuration and turn up.

When it is all said and done, although similar, no two systems perform exactly the same. Obviously this is due to the nuances of each environment. What I am vexed by is the ability to quantify these properties. My questions:

  1. Is there one place that I can view activity on my VLAN network and observe (quantitatively) the traffic?
  2. Is there an analyzer software or device that is best suited for this task?
  3. Are there relevant standards for acceptable performance metrics of a video system overall?

Any input would really be appreciated. At the moment we just keep learning more and more, but it all seems very omni-directional…

JH
John Honovich
Sep 10, 2013
IPVM

Are your most interested in network load / bandwidth utilization? What are the performance issues you are interested in 'quantifying'?

UE
Undisclosed End User #1
Sep 10, 2013

John,

What I am looking for is any indication of bottle necks. I would then like to be able to translate those into functional/practical terms, for instance:

I would like to be able to certifiy that our camera system in it's current configuration can handle, up to 60% motion activated perfomance with out impairment to live viewing and any lost video packets.

I would like to know how often or when any network segments reached maximum through put, and what was the resulting effect? Buffering? Retransmissions? Or lost data and noise and jitter?

And more than anything, when a system starts "acting slow" at the viewing client, I would like to be able to quickly identify the dynamic... the item that changed and or went into overload?

Thanks.

Avatar
Marc Pichaud
Sep 10, 2013

I'm using Port miroring feature on L2+ or L3 switchs so you can mesure with your PC what really goes In and Out (then with networkx or Wireshark) from your VMS or NVR ( with 2 RJ45 ports or more) Same for camera

For bottle neck detection, Multiping is a good measurement tool to snif latency and jigle on 20,30 or 60 diffrent devices in the same time and keep graphical tracks

So you can detect a high unregular jigle on a switch or a camera struggling ( reaching their bugger limits or CPU for a server or a camera)

A lot of issues coming from bad camera settings especially at night .. , or too many and too high streams +motion saturating cameras can be quickly detected with that

When you knwo who is faullty, you can then use Wireshark to analyse in detail , services, protocols and packets

UE
Undisclosed End User #1
Sep 10, 2013

Thank you Marc,

You gave me a lot to look into, but I will.

Where would you get your Wireshark packets from? The VMS server camera LAN port?

Avatar
Jon Swatzell
Sep 10, 2013
IPVMU Certified

OpenRTSP is a great tool for diagnosing UDP packet drops by measuring QoS from the RTSP/RTP/UDP stream.

Using wireshark to review RTCP is great for root cause analysis, but if you just want to confirm from an independent tool (not the VMS) that you're losing packets, OpenRTSP has a simple command line interface. You can have it drop the stream to a folder as well so you can validate iframe interval and such.

UE
Undisclosed End User #1
Sep 10, 2013

Sorry Marc,

I completely over looked your diagram. Thank you. I will take some modeling in here to get the parts and pieces downloaded, but that seems like a good line of investigation.

UI
Undisclosed Integrator #2
Sep 11, 2013

If are they Cisco switches they manage VLAN networks diffrently. This link may help ? Understanding Management VLAN | Tom's Hardware Forum

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions