If you’re searching for an embedded solution that allows your customers to access live and recorded video from your system remotely, enables them to manage video from your web application anywhere in the world without the hassle of network setup, and avoids the need for cloud services, this article is for you.
Viinex middleware provides various functionalities for software developers looking to incorporate video surveillance features into their applications. With its support for WAMP (The Web Application Messaging Protocol), which we will discuss in this article, implementing edge-based video management has become a seamless task. The WAMP support makes the middleware a ready-to-use solution for developers who want to offer their customers secure and convenient web access to video stored on the edge without the need for cloud-based recording. This approach grants customers greater control over data privacy and ensures the security of sensitive end-user videos.
What exactly is The Web Application Messaging Protocol?
WAMP, which should not be confused with the abbreviated name for the software stack Windows, Apache, MySQL, PHP, is registered at IANA as “The WebSocket Application Messaging Protocol” by Tobias Oberstein. The complete specifications can be found at https://wamp-proto.org/spec. The original design and proposal for WAMP were created by Crossbar.io developers in 2012, and WAMP development has been sponsored by Crossbar.io ever since. It’s important to note that the WAMP specification is freely available under an open license for anyone to use or implement.
WAMP is an open application-level protocol offering two messaging patterns: Routed Remote Procedure Calls (RPC) and Publish & Subscribe (PubSub). The WAMP Router passes these patterns between application components. WAMP is easy to use, designed to support various languages, simple to implement, and based on modern Web standards, which enable two-way real-time communication between software components. These standards include WebSocket, JSON (a data interchange format), and URIs (Uniform Resource Identifiers). The following description provides an overview of how the WAMP protocol works and the roles of its components: Publisher and Subscriber in the PubSub model; Caller and Callee in remote call procedures; and Broker and Dealer, which are responsible for routing. Please note that some WAMP-described materials, copied and adapted from https://wamp-proto.org, are used in this text with permission from the website.
The WAMP protocol introduces the concept of a Router by combining two routing components: Broker and Dealer. The Router is a WebSocket server to which applications connect as WebSocket clients. After establishing a connection, components can make remote procedure calls, subscribe to events, and publish events.
The publish-subscribe model allows a Publisher to submit information to an abstract “topic,” and Subscribers receive information indirectly by expressing their interest in a respective “topic.” Both parties are unaware of each other and are decoupled via the “topic” and the Broker, which is responsible for routing. The Broker maintains a record of subscriptions, tracking who is currently subscribed to which topic. When a Publisher publishes information (“event”) to a topic, the Broker identifies the Subscribers interested in that topic and forwards the information (“event”) to all those Subscribers.
The process of determining receivers of information (independently of the information submitted) and forwarding the information to receivers is called routing. Similar to the Broker’s role with PubSub, the Dealer is responsible for routing a call from the Caller to the Callee and routing back results or errors vice versa. Both parties are unaware of each other’s location and how to reach one another: where the peer resides and how to reach it. This functionality is encapsulated in the Dealer.
With WAMP, a Callee registers a procedure at a Dealer under an abstract name: a URI identifying the procedure. When a Caller wants to call a remote procedure, it communicates with the Dealer and provides the URI of the procedure to be called, along with any call arguments. The Dealer looks up the procedure to be invoked in its record of registered procedures.The information from the records includes where the Callee implementing the procedure resides, and how to reach it.
Leveraging WAMP for Video Surveillance: Exploring the Mechanism and Use Cases
Viinex middleware supports WAMP as a client while avoiding the implementation of a WAMP Router, as video management middleware concentrates on streamlining video surveillance tasks. A wide range of open-source and commercial WAMP router options are available, enabling partners in the IoT sector to independently leverage this technology based on compatibility with their applications. Additionally, some partners may already be utilizing this technology.
In the Viinex architecture, a “WAMP client” is implemented as an object, with each Viinex object responsible for specific functionality. After creating a “WAMP client” object, it needs to be linked to other Viinex objects that require WAMP access. Upon startup, the “WAMP client” connects to a WAMP Router (using the WebSocket URL specified in the configuration) and publishes an endpoint for remote calls for the functionalities of these Viinex objects. External software clients can connect to the same WAMP router, issue remote calls, and receive events from the Viinex middleware. Both the Viinex “WAMP client” and external software client must connect to the same WAMP router; however, direct accessibility between them is unnecessary, as application components communicate through the WAMP router.
WAMP support allows external software clients to interact with Viinex by calling methods via RPC and managing its functionality via its API. External web clients can execute role-based commands for the Viinex middleware. For example, for users, these commands may include network IP camera discovery, live and archived video playback, IP camera PTZ control, video stream switching, archive timeline selection, and other middleware functions.
Another essential feature of routed remote procedure calls is the ability to manage a Viinex instance by controlling its configuration. The Viinex middleware provides manageable internal clusters within the instance, enabling real-time functionality changes. Our partners often begin with a basic configuration of Viinex and add or modify cluster configurations for the active operation of features. As a result, external software clients can upload new configurations to orchestrate multiple middleware instances on edge devices, implement license policy control, and make administrative adjustments on the edge, such as modifying camera numbers, recording settings, and more.
The “WAMP client” also publishes events from event source endpoints of objects within the Viinex configuration, such as IP camera onboard detectors, results of integrated analytics, embedded script state changes, or digital inputs. This enables external software users to subscribe to these events and receive them as they occur within their security systems.
Interestingly, the WAMP Router approach is fully compatible with using WebRTC for video streaming. WAMP, as an RPC protocol, is used for signaling and managing, while media does not follow the same network path as WAMP message traffic. Instead, external software clients can leverage the WebRTC server in Viinex to establish a direct WebRTC streaming session and control the playback of live or recorded video sources. In this scenario, streaming occurs directly from Viinex to the external software client, without involving the WAMP Router.
By converging WAMP and WebRTC protocols, a fundamental P2P streaming technology that enables secure, real-time video streaming, our partners can avoid heavy traffic through data centers and reduce costs associated with incoming and outgoing traffic to and from data center providers. This is achieved by having the technical possibility to stream video directly from the edge to web clients. Typically, a WebRTC STUN server is sufficient for most network configurations; however, in the worst-case scenarios of a user’s network architecture, a WebRTC TURN server can be employed for video delivery to ensure coverage in remaining cases (both servers are supported by the Viinex middleware).
Viinex’s support for WAMP has addressed the challenge of deploying video surveillance systems on the internet. It has simplified network setup requirements for communication between video servers and clients, removed the need for direct interactions between software applications, and enabled remote messaging and control of the system. As a result, concerns about VPN and expensive public IP addresses or port forwarding adjustments and are no longer necessary. Both Viinex middleware and web clients can communicate with each other through a known WAMP router, regardless of their location, even when behind NAT.
For example, managing WebRTC streams and other middleware functions through Viinex’s HTTP API previously required direct access to the Viinex instance. However, now that the Viinex HTTP API is available through the WAMP router, web clients can interact with the middleware in a decoupled manner.
Insofar as the “WAMP client” enables access to other Viinex objects’ APIs through the network, it must adhere to the security guidelines established for the Viinex instance. WAMP relies on WebSockets, which enable connections similar to HTTPS, and uses WSS (WebSockets with SSL/TLS) to encrypt information, providing protection against man-in-the-middle attacks. As a result, the wss:// protocol is preferable to the less secure ws:// transport.
It is important to note that the WebSocket protocol does not handle authorization or authentication itself, but Viinex middleware offers these security features. Viinex employs role-based access control and introduces an authentication & authorization provider object for use that grants access to functions.
Regarding video streaming, which operates differently from WAMP connections, it is worth noting that WebRTC utilizes SRTP (Secure Real-time Transport Protocol) for video streaming. With this secure transport for users, various attacks become unfeasible.
Indeed, the WAMP router may pose a potential risk to the system, as its failure could render the entire system inoperable. This technical issue can be addressed by using WAMP router clusters. Configuring the Viinex instance with the address of a WAMP router cluster instead of a single WAMP router offers a solution. For example, specifying the WAMP router’s DNS name, which resolves to multiple addresses, is a simple and effective approach.
The primary market niche for implementing WAMP support was to accommodate a use case where some users prefer not to store their videos in the cloud. Users who employ video management systems at home or in offices to monitor events or view verification video from alarm systems, video management systems, and smart home systems may not always be comfortable with the idea that their home videos could be stored elsewhere. Some customers undoubtedly prefer having a “box” at home or their office. Storing video on-site is not only appealing to vigilant users but also beneficial for service vendors, particularly those providing services globally. In addition to freeing vendors from expenses associated with heavy video traffic for data center providers, data protection regulations enforced by governments, which impose fines for operators, processors, controllers, and personal data transfers to third countries, can pose significant challenges for global service vendors.
Viinex implemented WAMP support in early 2022 to help such vendors by enabling our partners to access the Viinex middleware remotely and with an independent tool, using the standard SubWebSocket protocol. By offering WAMP support, Viinex now provides a comprehensive set of essential features for implementing video surveillance on the edge without the need for cloud deployment.