Named stream abstraction for WebRTC notification with P2P media

This is a continuation of my earlier article on WebRTC notification system and signaling paradigms which presents, among others, a named stream abstraction for WebRTC signaling. That article also mentioned my light weight notification server notify.py and sample client code webrtc.html as part of my open source rtclite project. 

In this article I present another light weight notification server streams.py and sample client code streams.html as part of that project. This enables named stream abstraction described in my earlier article. The named stream abstraction is closer to the traditional Flash Player's NetStream based publish-subscribe media, and facilitates wide range of application use cases.

The two source files linked above contain sufficient documentation to get started. The highlights are presented below as well. 

The server has a websocket listener. A client can connect to the server in publish or subscribe mode, by specifying it in URL parameter, e.g., wss://myserver.host.com/path/to/stream123?mode=publish

Once connected, the client receives its unique ID within the scope of the stream path, e.g., /path/to/stream123. The server allows at most one publisher and zero or more subscriber connections to any stream path. The publisher and subscriber connections can connect or disconnect in any order. The server facilitates communication between the publisher and subscribers of the stream path as they come and go, as follows.

The publisher is informed about all the subscribers, first on initial connection, and later whenever a subscriber connects or disconnects. The subscriber is informed about the publisher, first on initial connection, if the publisher is present, and later when the publisher connects or disconnects. This is done via event messages from the server on the websocket connection. Thus the publisher can know the ID of all the subscribers, and the subscriber can know the ID of the publisher.

Next, the server allows message passing from one client to another. The sender client specifies the ID of the receiver client in a message sent to the server, and the server proxies that to the receiver client, and injects the ID of the sender client in the message. 

This simple message passing allows the client to exchange WebRTC session negotiation and transport messages with another client, to establish a peer-to-peer media path with that client. The example web application linked above, uses this to implement a mesh media path from publisher to all the subscribers. In conjunction with the concepts mentioned in my flash-videoio project, this can allow wide range of application use cases such as two-party call, multi-party conferencing and video broadcast. 

The basic idea behind the named stream abstraction was earlier implemented in my vclick and restserver related projects. However, the open source implementation presented here is unrelated and does not use the general purpose resource oriented software architecture. Nevertheless, the project motivation is consistent with my earlier project. 

The server presented here also allows primitive access control, by using one-way hash for the stream  path when subscribing. This prevents a malicious client who knows only the hash value to publish that stream, and disrupt an ongoing interaction or application. More details are in the code. 

Happy coding !