WAMP support

Viinex video management SDK has received support for Web Application Messaging Protocol (WAMP).

What WAMP support means and why we think this is an important thing?

For those who are unfamiliar with the concept, WAMP is a protocol for performing remote procedure calls and for sending/receiving events. Basically it serves for the same purpose as CORBA, DCOM, gRPC, and so on, — although some technical distinctions make WAMP, in our opinion, better suited for web-oriented applications than mentioned alternatives. One essential difference is that WAMP uses routed RPC approach, which means that there’s always a mediator (so called WAMP router) between the remote procedure caller and callee, as well as between event published and subscriber. To learn more on Web Application Messaging Protocol, one may find useful the official site https://wamp-proto.org/, and perhaps another good place to start with is https://crossbar.io/, the website of WAMP router implementation and client libraries for a number of programming languages, which is developed by the authors of protocol specification.

Now, how is Viinex related to that, and what is the use of WAMP for Viinex and its users?

As for the first question, this is simple: being an SDK, Viinex exposes its programming interfaces to clients. Originally there was an HTTP API which is really easy to use. The downside is that with HTTP API, you need to have a direct access to Viinex instance, or at least do some kind of port forwarding so that a client can issue these HTTP requests to Viinex HTTP server. There are two other parts of API perimeter, which is what we call a “native” API (for low-level video-related functionality), and the “scripting” API, — that’s what is available for builtin scripts running inside of Viinex. Now what we did is basically made the scripting API available over WAMP. There are some differences coming from the nature of flow control (scripts are single-threaded while remote calls come and are executed concurrently) and from conventions taken in WAMP, but the semantics of programming interfaces and calls, and the syntax of data structures for call arguments and results were preserved.

How this can be used by Viinex client software? The WAMP API is implemented by a “WAMP client” object within Viinex. It needs to be created in Viinex configuration, and linked with other objects to which an access over WAMP needs to be provided. Once such “WAMP client” object is started, it connects to a WAMP router (at the WebSocket URL specified in configuration), and publishes the endpoint for remote calls. It also starts publishing the events from the event sources within Viinex config. After that, the components of client software may connect to the same WAMP router and issue remote calls and receive events from Viinex. Both Viinex instance and client software need to connect to the same WAMP router, but none of them needs to be directly accessible by another party. It’s only the router needs to be available to connect to.

This approach agrees well with the use of WebRTC for streaming video. While WAMP, as the RPC protocol, is used for signaling and control, — media needs not and does not follow the same path on the network as WAMP traffic. Instead, a client may use WebRTC server at Viinex to create a streaming session, and then control that session to play this or that live or archive video source. The streaming in this scenario happens directly from Viinex to the client, or, in worst cases, is relayed via a TURN server.

As a proof of concept, we added the support for WAMP to our existing demo user interface. The demo is located at the URL http://demo.viinex.com:8080/. Note that there’s no Viinex instance at this 8080 port, — it’s just WAMP router who serves the static files containing the demo UI application. Our setup requires an authentication at WAMP router; use realm name “lwo”, user name “guest” and an empty password. Basically this is the same UI which works over HTTP API; it’s just it automatically detects whether HTTP or WAMP should be used, and in the latter case the RPC implementation over WAMP is chosen. By the way, here’s an illustration of how interchangeable the API transports are with Viinex: https://github.com/viinex/viinex-demo-ui/blob/master/src/app/viinex-rpc.ts.

To sum up, — the Web Application Messaging Protocol works well when you need to deploy a system with zero network setup. That’s most often scenario, when an end-user does not want to or is unable to deal with VPNs, port forwarding, and so on. From now on, this RPC mechanism is available in Viinex. Together with WebRTC for peer-to-peer media streaming, we now have the whole stack of protocols suitable for building a consumer-friendly distributed video management solution.