In this fourth of our newsletters that have focused on the types of IP video, we will investigate surveillance video. Cameras that send and receive IIP packets and are used for surveillance, are called network cameras. I chose to have a separate discussion about these cameras because their video streams can take three forms:
RTP over UDP
RTP over RTSP (over TCP)
RTP over RTSP over HTTP
Surveillance cameras can create a stream using a combination of two, three, or four of these protocols. Other forms of video such as video conferencing, IPTV, and adaptive bit rate (ABR) video do not provide for this variety of formats.
Since our focus in these four newsletters has been on how the video interacts with the network, it is apparent that surveillance traffic has the most possible outcomes. So, let’s review an important point from the previous three newsletters: in the data packet carrying the video, it is the protocol header following IP, either TCP or UDP, which determines primarily how the traffic will behave on the network. If that header is UDP, the video flow usually must have a relatively fixed level of bandwidth (BW) and cannot tolerate packet loss. Packet loss most often occurs because of overfilling network buffers. If other traffic consumes too much of the bandwidth at any given time, the UDP video will cause packets to be discarded. Network congestion will have the same effect. Therefore, the first type of video listed, RTP over UDP, will face these network obstacles.
You may ask, “Why use RTP over UDP?” It’s simple and has been used for decades in video conferencing and VoIP. However, it may be difficult to get the traffic through a firewall because it tends to use a range of ports rather than a single port.
Turning now to the second format, RTP over RTSP over TCP, we see a completely different set of outcomes. If the available bandwidth is high, TCP will throttle up to use as much as it requires. For example, a 6 MB/sec HD stream being sent to a playout device will be delivered at that rate. If the receiver is a storage device, TCP will move above 6Mb/sec. A one hour video could be delivered in much less than an hour. If other traffic restricts the available bandwidth to below 6Mb/sec, the video will need to be encoded at a lower resolution so that it can tolerate the lower BW. Dropped packets won’t be much of an issue since TCP provides retransmission of lost packets. Delay can be a problem if you need to see the security video immediately as delay can vary with TCP. Another disadvantage of RTSP based video forms is that they require an RTSP proxy in any firewall the traffic will pass through.
RTP over RTSP over HTTP is also based on TCP. Therefore, it will behave much like RTP over RTSP over TCP. What advantage is there to using HTTP? Flows based on HTTP will pass easily through firewalls. They use TCP port 80 like all web applications. So, firewalls rarely restrict these flows. Cameras that support RTP over RTSP over HTTP usually also support the variant, RTP over RTSP over HTTPS. This makes it possible to encrypt the video.
While many manufacturers support all three of these modes in their cameras, you might check out Axis Communication’s P3707-PE. I referenced their documentation in preparing this newsletter. There is also considerable information in the Internet standard RFC 7826, RSTP Version 2.0.
