Asynchronous event/state notifications in the Janus WebRTC server
Providing administrators and developers with more tools to manage a Janus instance
This presentation introduces a new modular mechanism for implementing live state and event notifications within the context of Janus WebRTC server instances, for the purpose of allowing administrators and developers to monitor and handle WebRTC sessions more effectively.
Janus is a general purpose open source WebRTC server and gateway. It allows you to implement heterogeneous and complex WebRTC multimedia applications using the different functionality it provides as modules, and can interact with legacy technologies as well in the process (e.g., SIP or RTSP). An introduction to Janus was made ad Fosdem '16. This new presentation is aimed to address a new feature recently added to Janus, and currently being worked on in a separate branch that will soon be merged.
Specifically, a modular mechanism has been designed and implemented to allow modules to receive asynchronous and live events of several different types from Janus and its plugins, in order to then handle them accordingly. Notifications can be about whatever is happening in a Janus instance, e.g., Janus sessions/handles and their states, PeerConnections and their lifecycle (SDP exchanges, ICE and DTLS state changes, etc.), application plugin internals and related events, and so on. These new modules can then decide whether to just forward these events, or a subset of them, to an external backend for further processing, or process them themselves. Use case examples are simple debugging, live monitoring, troubleshooting, storing on DBs or other systems in a structured way, CDRs, etc. Within the context of Janus, this is particularly useful as so far the only API available to administrators has been a query/response API to monitor the WebRTC internals of Janus itself and a few other aspects, which limited the scope of what admins could do to effectively manage a Janus instance.
At the time of writing, a single module implementing this mechanism exists, one we implemented ourselves as a proof of concept and that simply forwards all events as JSON objects to an external web server. In the future more modules will be implemented to cover more practical scenarios, hopefully by third-party developers as well.