In the last 10 to 12 years, security and surveillance systems have taken on a larger and more important role in communications networks. The problems we might see in these types of networks will usually start from video freezes due to lack of bandwidth but can also be much more complicated as will be discussed in this recipe. In this recipe we will discuss some of the problems with these systems and how to approach and solve them.
Usually, you will be called to solve problems that users experience when watching security cameras. In this case, you can port mirror the specific camera (1), the communication line in the remote site (2), and a camera server (3), or you can monitor the central line with a filter to the remote network (4).
To identify problems in this network, follow these steps:
- First, if possible, port mirror a connection between the viewer and a locally connected camera (over the LAN). When doing so, you will be able to note the required bandwidth for every picture resolution you try.
Tip
When watching a video, the bandwidth can start at 128 Kbps for a very basic black-and-white movie at a low resolution, average around 0.5 to 1.0 mbps for a black-and-white or colored video stream at a reasonable resolution, and go up to several megabits per second for high definition streaming (usually at 6 to 8 mbps).
- As a basic—make sure your bandwidth is sufficient.
- Make sure you don't have any packet losses or significant delays or Jitter.
- For packet losses, log in to the communications equipment or use SNMP
- For delay and Jitter, you can use the
pingcommand or graphical utilities (many of them are free, for example, from Colasoft)
- While monitoring a remote camera feed, if you have short freezes, navigate to Statistics | TCP Stream Graph | Time Sequence (Stevens). Make sure all I and P frames are received at constant intervals.
- The problem here is that there were cameras in the customer sites that transmitted the video to a central server and the central server transmits it to the monitors. What we see in the preceding graph is the server delayed some of the p-frames and that was the reason for the short freezes in that case. It turned out to be a software problem on the server.
- When trying to log in to a camera server, several ports may be in use and you may not get the picture; or it may so happen that you get the picture but something else does not appear. To verify that all TCP port numbers are open, you can do this:
- In the following screenshot, you see how the HTTP session (1) is running between the internal office address 10.0.0.3 and the external address of the web camera 82.82.182.182 (don't use these; they are just sample values). In the line 2614, you see a SYN packet is sent from 10.0.0.3 to 82.82.182.182; this packet is blocked in packet 2615 via the TCP RST (reset) PDU (2). The same event occurs twice more (3 and 4). The fact that you see one established connection does not mean that there are no other connections being attempted.
- In this case, the HTTP connection had connectivity to the web server. To log in, another connection was opened. Since the log in connection was blocked, it was possible to see the camera server but not to log in to it and watch the video.
Video streams are made of I-frames (Intra-coded frames), P-frames (Predicted frames), and B-frames (Bi-predictive frames). I-frames are frames that contain the full picture, while P-frames contain changes from the previous one. There are also B-frames, which also use prediction mechanism for the next frame.
In TCP, each video frame, I, P, or B, is divided between several TCP packets; therefore, when you have TCP problems (retransmissions and others) it can directly influence the video stream.
The quality of video transmission depends on the codec that you are using, number of frames per second that are transmitted, time interval between frames, and more parameters that can be configured in the camera or on the camera server. Make sure you've set all parameters correctly to get a good picture.