Cloud server for Zodiak video surveillance

The service makes it possible to buy a camera in an online shop and add it to a user account specifying a unique camera identification code or details for authorisation (the camera's username and password). When a camera is successfully added a user can watch live video from the camera in the user account of a web interface for free and control the pan/tilt mechanism if supported by the camera. By subscribing to one of the price plans the user gets access to a video archive of footage recorded from the camera for a limited period of time. Cameras connected to the service are displayed on the world map in public (if enabled) and private sections of the site. The cartographic service Google Maps is used to display the cameras on a map. In the user account there is a feature for providing guest access to the camera to other users of the service, allowing them to view live video and video archives.

Paid services:

• Public access to the camera – live video from the camera is available to unauthorised users. Cameras are displayed in the world map and in the public cameras section;
• Notifications about camera events;
• Recording and storage of a video archive from the camera during a limited period of time depending of the chosen price plan;
• Additional month of recorded archives – adds 30 days to any price plan.

Payment aggregator is used to pay for services.

Timeline plugin for VideoJS video player

A plugin, Timeline, was developed for VideoJS player. The plugin enables scaling of the timeline (to hours, days, weeks or months), scrolling the scale across the entire length of the recorded video archive, and watching video fragments positioned on the scale at different timestamps.

The timeline shows fragments from the video archive of up to one hour in length as well as camera events (online/offline). After clicking on a fragment on the timeline video playback begins automatically. A marker for the current position synchronised with the time of video playback is shown on the timeline. Using the marker, a video can be skipped to any section within the fragment. This functionality replicates standard player functionality, making it more convenient when used together with the timeline scaling feature.

P2P module for Zodiak video camera

NAT punch-through is required to access the pan/tilt control API, camera authorisation and video stream capture since a camera doesn't have a static IP address. In addition, the camera can run in various network configurations, for example connected to several network switches in series.

A P2P module in C has been developed for the Zodiak video camera. NAT punch-through is conducted with the help of the COTURN server via the ICE/TURN protocol. The COTURN server acts as a link coordinating interaction between the Zodiak web service and the EVO Stream media service on the one side, and the Zodiak camera on the other.

Receiving an incoming connection from the camera, the COTURN server diagnoses the network connection, identifies the NAT type and, depending on the type, chooses a NAT punch-through method, opens a tunnel to the camera and sends connection parameters (host and port) to the camera. The P2P module sends the connection parameters to the Zodiak web service and keeps the open tunnel in an active state by sending keep-alive packets to the COTURN server.

The supervisory channel of the RTSP protocol while video stream is being captured from the camera is achieved via the following path: RTSP stream of the camera ⇔ Zodiak P2P module on the camera ⇔ COTURN server ⇔ EVO Stream.

• The Zodiak web service creates a URI for capturing video stream from the camera using the parameters for the connection to the COTURN server opened by the camera (rtsp://<coturn-host>:<coturn-port>/streamuri), and sends a control command to the EVO Stream media server to capture video from the camera.
• The EVO Stream media server addresses the camera through the COTURN server using the specified URI via the RTSP protocol.
• The COTURN server transmits the received TCP packets to the camera through the open tunnel.
• Using the RTSP protocol the camera's P2P module substitutes the host address and the port to local ones in the TCP request packets, transmitting them to the camera. After receiving a response from the camera, it substitutes the host address and port in the TCP response packets sent to the COTURN server address, transmitting them to the server through the open tunnel.
• Using the RTSP supervisory channel, the EVO Stream media server communicates the address where the video stream should be sent to the camera via the RTP protocol.

Authorisation on the camera when accessing the user account and camera pan/tilt mechanism control is processed through the following path: HTTP API of the camera ⇔ Zodiak P2P ⇔ COTURN server ⇔ Zodiak web service.

• The Zodiak web service creates a URI to call an available HTTP API method on the camera using the parameters for the connection to the COTURN server opened by the camera (http://<coturn-host>:<coturn-port>/api?params=...), then sends a request to the COTURN server.
• The COTURN server transmits the received TCP packets to the camera through the open tunnel.
• Using the RTSP protocol the camera's P2P module substitutes the host address and port for a local one in the TCP request packets, transmitting them to the camera. After receiving a response from the camera, it substitutes the host address and port in the TCP response packets sent to the COTURN server address, transmitting them to the server through the open tunnel.
• The Zodiak web service receives an HTTP response created on the camera side from the COTURN server.

The P2P module is implemented using the PJLIB and PJNATH libraries. The following difficulties were encountered during module development:

• The toolchain provided by the camera manufacturer contained a relatively old compiler which didn't support modern C-language standards. As a result, it was necessary to make a lot of corrections to the source code of the PJLIB and PJNATH libraries for successful compilation of the implemented P2P module.
• The PJNATH library doesn't provide ready modules for HTTP and RTSP traffic tunnelling. These modules had to be created from scratch using ready tunnelling tools for TCP traffic. The greatest difficulty was found when tunnelling RTSP traffic since this protocol is more complex than HTTP.
• The cameras have very little hardware resources, which meant that additional time was required for P2P module optimisation.