Flussonic Agent Installed on Cameras Helps to Connect with Flussonic from behind NAT

December 5, 2016

We already have first customers for whom we’ve launched our new Flussonic Watcher video surveillance complex (we’ll tell about it in detail a bit later) with such an important point as Flussonic Agent.

Agent is a small program that we add to the IP camera firmware in order to be able to get video from a camera in a local network.

Such an agent makes things much easier for the users: it’s enough just to turn on the camera and forget about setting ports on the router, about UPnP and other stuff that makes everyone yawn and switch to other, more interesting things. Besides, Agent is an additional means of protection against camera hacking, since cameras саnnot be exposed in the Internet .

How Flussonic Agent works

When launched, the agent gets connected to the pre-configured server with Flussonic Watcher on it, and reports that it is alive and kicking, and is ready for video transmission. But this video is not needed on the server with Watcher: it’s only the system web-interface and its business logic that work there. This server is a controlling one and is called endpoint in the agent terminology.

If Watcher recognizes the agent (mutual password verification has place), it can tell the agent to connect one of the running Flussonic servers, which the video will be transmitted to. In the agent terminology such Flussonic is called streampoint. Also the endpoint can cause the agent to quickly switch to another streampoint in order to work over the situation with Flussonic breakdown.

After connecting to Flussonic (streampoint) the agent waits for the command to open the connection in a similar way it is arranged in SSH tunnel. When Flussonic decides to take video from camera, it refers to the agent with the request to set TCP tunnel. Both video from RTSP and screenshots from camera can be transmitted by this tunnel.

The agent already provides the opportunity to switch between the main and the backup endpoints, as well as between the Flussonic streaming servers.

What are the options?

Different companies already provide the schemes that let people simply bring a camera home and switch it to a cloud service.

Some of them follow a really wrong way and configure the address of the server, where video should be published, directly on the camera. It means video will be forwarded to this server regardless of what goes on the server. Once we’ve come across such a camera and, as you can easily guess, there was no server by the hardcoded address, i.e. the camera was sold with the knowingly invalid service.

The most common way today is OpenVPN tunnel arrangement. OpenVPN and nothing else, because nowadays the firmware for the most of the cheap cameras is created with the help of buildroot — an environment for the creation of firmware for various add-in devices; buildroot already has openvpn in it, and it is really easy to activate.

The connection certificate and the openvpn server address are somehow configured on the camera, and then the streaming server sees the camera in the cloud via the openvpn server and so can get video from it.

This is very easy to arrange, but that’s actually the only advantage of this approach.

First of all, OpenVPN requires one more server nearby, which means your server-related expenses are doubled. Put “x2” in the “servers” column.

Second, all the settings responsible for the selection of servers, where the camera sends video to, reside directly on the camera. There is no way to quickly add a new server instead of a destroyed one and forward video from your camera to it — you’ll have to change DNS, and on the way between your DNS-server and the camera there will definitely appear an accommodative day-long-caching someone else’s DNS-server, that will be willing to take care of you and substitute your new data with the old address of the OpenVPN server.

In case with flussonic agent such a bounding to DNS also has place, but it is still much easier to provide the failover for a little virtual server, with just web-interface and controlling server on it, than the failover for a high loaded server with the wide channel.

Third, OpenVPN needs more resources because it does more than this task requires: this server arranges full-featured tunnel, passing the traffic through the Linux kernel. This does not happen in case with flussonic agent and Flussonic, all the traffic comes and stays in one process, and this gets noticeable and important when you have a Gb of the incoming video.

What else is the agent good for?

The unexpected and important property of the agent is the automatic solution of the “nonexistent bug” (i.e. bug with the invalid handling of non-blocking sockets, renounced by manufacture and not visible to customers).

The truth of the matter is, that as soon as an IP camera gets a notification that it should hold on with the data submission because the receiver is overloaded, the camera starts sending trash, that needs to be painstakingly recovered, to the net. The problem is caused by the incorrect processing of the non-blocking sockets in the Chinese program installed on the camera and broadcasting video. That’s not the only problem of its kind, and we have security facilities for a bunch of other nasty surprises, but still this is a serious issue for the most modern cheap (and atually pretty well-done) cameras, made in China with Chinese firmware.

The agent resides as near to RTSP streamer as possible, i.e. directly on the camera, it properly receives all the video and transmits it all right through the net. Traditional for the long-distance video transmission issues like scattering image, squares and green stripes go away, so video runs smoothly.

What cameras can the agent be installed on?

This question is probably bothering you from the first lines of the article, but there is no simple answer.

We have successfully launched the agent on cameras like RVi-IPC11, LTV CNM-320 and others. The agent also functions well on street cameras based on HiSilicon, TI DaVinchi and MIPS routers based on dd-wrt.

Some cameras are easier to work with, others are harder, and besides we have two cameras that we have failed to install the agent to (in spite of the eagerness of their vendor’s branch in Moscow). But generally we can say, that our agent can run on almost all the Lunix-based cameras, provided that they have the original firmware.

How to use it in a project

As far as it goes flussonic agent is not an end product, that does people good – it is just a part of a large complex mentioned at the beginning of the article. We are going to describe in detail how the agent gets its identifiers, how to initialize (activate) cameras with the factory-supplied firmware and so on, so stay tuned.