WLTT Watcher Agent

Our first customers have already appreciated the unique opportunities of Agent working with the new WLTT Watcher video surveillance complex that we’ve installed for them (we shall return to the detailed description of WLTT Watcher a bit later).

Agent is small program installed in addition to the IP camera firmware so that you could receive video from a local net camera.

The agent simplifies the entire process for a user: the only thing you’ll need to do – is to turn the camera on. You don’t have to configure the router ports, set UPnP or something that causes headache for users and makes them switch their attention to more interesting things

Moreover, Agent will provide additional protection against the camera hackers, since it makes it impossible to expose cameras in the Internet.

Agent’s Operating Principles

After launch the Agent synchronizes with a preconfigured server with WLTT Watcher on it, reports it is alive and well, and is ready to transfer video. Nonetheless in case of a server with Watcher on it there is no need for such a video, since it’s nothing more than a system web-interface needed for the program execution logic. In the agent terminology this server is called endpoint and is a controlling one.

In case of a successful mutual password verification the Watcher identifies the Agent and connects it with one of the WLTT servers running that the video will be sent to. Such a server is called streampoint in the agent terminology. Furthermore, in the event of WLTT servers’ disruptions, the endpoint may force the agent to quickly switch to a different streampoint.

When connected to a streampoint (WLTT Server) the agent waits for a server’s command so that it could open the connection in the same way it works in a SSH tunnel. The server sends a request to the agent to set TCP tunnel once it decides to get a video from the camera, though this tunnel is able to transfer both screenshots from the camera and video from RTSP. You can even switch between the streaming servers via Agent as well as between the main and the backup endpoints.

Any other options?

Several companies now offer different technical schemes for the users to buy a home camera and connect it to a cloud service.

But we must say that some of those companies actually follow the wrong direction and set up the server address designated for publishing videos directly on the camera. In this case video will be uncontestedly transferred to this server, no matter what happens to the server itself. As you can easily guess, this means there will be no working server by the hardcoded address, in other words, such a camera is sold with a deliberately invalid service.

Nowadays users most often use the OpenVPN tunnel arrangement. Actually, there is no credible alternative, since the firmware for the most of the cheap cameras is created via buildroot tool – a set of files and patches that simplifies the process of creation of firmware for different add-in devices; buildroot has a preinstalled OpenVPN and it is really easy to activate.

The OpenVPN server address and the connection certificate are somehow set to the camera – that is why the streaming server is able to identify the camera in the cloud through OpenVPN server and receive video from it.

In fact, it is extremely easy to organize, but it’s the only advantage of such an approach.

First and foremost, OpenVPN requires at least one more server nearby, which means your expenses on the server are doubled. Just multiply them by 2.

Secondly, all the parameters responsible for selection of servers, on which the video is sent, exist directly in the camera. It is impossible to quickly replace the destroyed server with a new one and adjust the video transmission from your camera – you’ll need to set another DNS, and it is likely that there will appear some sort of accommodative day-long-caching DNS-server belonging to someone else – somewhere on the route between DNS-server and your camera – and it will be more than happy to take care of you and replace your new data with the old OpenVPN server address.

If you deal with Peeklio agent, a bounding to DNS still takes place, though it is much easier to provide a crash recovery for a small virtual server with a single web-based server and to further monitor it, than for high-loaded server with expanded channel.

And thirdly, since OpenVPN does more than this task requires: arranges full-featured tunnel and transferring traffic through the Linux kernel – it requires additional resources. You will be saved from this problem if you choose to install Agent and our servers – since all the traffic comes and stays in a single process, which is especially desirable and important in case you have a Gb of the input video.

Why else would you need the agent?

You would be surprised but Agent is an automated solution for “nonexistent errors” (for example, bug with the invalid handling of non-blocking sockets, virtually refused to manufacture and invisible to customers).

The truth is that once the IP-camera is notified that it must hold on to transfer the data, since the receiver is overloaded, the camera begins to send trash, which must be carefully repaired, to the network. The problem is caused by improper handling of the non-blocking sockets in the Chinese program installed on the video broadcasting camera. To be honest, there might appear other similar problems and we provide security tool for heaps of other unpleasant surprises – yet there is still a serious problem for the latest cheap (and pretty well made actually) cameras produced in China with a Chinese firmware.

The Agent is located as close to the RTSP streamer as possible, i.e. directly on the camera, it correctly receives all the video and sends it directly over the network. Traditional video transmission problems over long distances, such as a scattering image, squares and green stripes disappear, so that the video go smoothly.