Bob's Adventures in Wireless and Video Headline Animator

Saturday, August 28, 2010

IP Video Transport Protocols

There was a post on LinkedIn regarding why the transport protocol between the the VMS software (NVR) and an IP Camera matters. I thought I would share my response.

Camera and VMS manufacturers are big on promoting their video compression algorithms such as Motion JPEG, MPEG4, or H.264. But try to pry out of them what transport protocols they use to communicate and it is a completely different story.

The need to know transport protocols supported (HTTP, Unicast, Multicast, RTSP/RTP over TCP, RTSP/RTP over UDP, TFTP/proprietary) is essential for determining performance over wireless and wide area network links.

For instance, if the VMS and the camera are remote from each other over a routed network (aka Internet) protocols like TFTP simply will not work at all. HTTP may work, but it will depend on how much buffer the camera has and how much jitter buffer the VMS will have, and how important latency is to your application.

Then we get to RTSP/RTP. ONVIF decided to implement RTSP/RTP over TCP as the preferred transport protocol because it is efficient and easy (lets the application off the hook for verifying guaranteed delivery). ONVIF used TCP because they wanted to enforce guaranteed packet delivery for chain of evidence and intrusion detection. But TCP forces packet level acknowledgment which is sub optimal on limited bandwidth networks. IPTV has been using RTP/RTP over UDP for years because it is more efficient and runs well over networks that are not deterministic (aka Internet). But UDP does force the application (aka VMS) to verify data delivery. We really wish that ONVIF had specified the use of UDP as the preferred method so that surveillance could scale over the Internet. UDP is an optional method in ONVIF, but we know of only one VMS system that supports it.

Anyway, for the last two years we have been testing cameras and VMS systems over our wireless links and carefully watching their transport protocol behavior and efficiency. We keep a list of the best and the worst VMS/camera combinations and have developed work around solutions (full duplex wireless for example) for transport protocols that are sub-optimal. Typically these sub-optimal protocols are very latency

Since our wireless protocol is optimized for video (TDMA derivative) we only say how these combinations work with our gear and not over 802.11, mesh, EV-DO, or other networks.

Our preference list for transport is:
RTSP/RTP over UDP (IPTV spec)
RTSP/RTP over TCP (ONVIF spec)
TFTP (these are always proprietary implementations, not actual TFTP) 

We have found that getting information on what transport the VMS has implemented with a particular camera is impossible. Many of the VMS tech support folks don't even know. We have even been told by some VMS mfgs that they are using RTSP/RTP but when we sniff it, they are actually using HTTP.

We are hoping that an independent third party would provide a definitive list of who is using what as it would help people out immensely. One place to start is which at least tells you which cameras support RTSP, but not how they have implemented it or which VMS are supporting same.

Let me know if you have other ideas about how to solve this.


  1. This is one of my favorite blog because whenever i visit this blog found something interested and different,you are doing very well job,keep it up
    Phone Call Recording

  2. Thanks . We’ve built our entire security camera system based on SecuritySpy and cameras from your previous recommendations, and everything’s been working perfectly. Thanks for the great software, and keep up the good work.
    This post is very helpful .Thanks a lot for this post that share with us . You can get more information here:
    ip camera
    goedkope ip camera
    ip camera kopen
    bewakingscamera kopen
    goedkope bewakingscamera