Introducing Ripple WebRTC Media Server

In the ever-evolving landscape of real-time communication, WebRTC stands as a groundbreaking technology. However, harnessing its potential often presents a formidable challenge. As a developer, I encountered these complexities firsthand and sought a solution. Thus, in mid-April 2023, I embarked on a journey to develop the Ripple WebRTC media server, an open-source hobby project.

Motivation

The motivation behind Ripple was clear: to provide a developer-friendly, Java-based WebRTC server solution using standard Java SE APIs with the aid of fast tools and libraries. The WebRTC ecosystem, with its steep learning curve and intricate concepts, can be intimidating to many developers. My goal was simple: streamline the server setup process, allowing developers to invest more time in client-side development.

Implementation

While Ripple isn't the first of its kind or the idea, with giants like Janus , Pion, and Jitsi in the WebRTC arena, it brings a newer developer-oriented perspective. Other open-source WebRTC media servers like Kurento and Ant Media have thriving communities and established codebases, making them attractive options for professional enthusiasts. Ripple, on the other hand, is in its infancy, and is and will be driven by tools and development experience as mentioned.

I was inspired to embark on this project after discovering the 'webrtc-java' library , which I employed in my TeamSpace desktop application project and others. Additionally, Ripple is designed with versatility in mind, featuring two main GitHub branches powered by Quarkus and Helidon. Helidon SE has caught my eye for its lightweight nature and avoidance of unnecessary library dependencies (bloating).

Server-Client Interaction

The client-server interaction in Ripple follows a straightforward pattern, I would like to assume lol. Clients must register with the server to obtain a unique client ID, which they will use in all subsequent requests. Clients are required to send periodic "remember me" requests to help manage memory usage. The server periodically performs housekeeping tasks to remove orphaned client IDs from memory.

Transport

At present, Ripple supports both WebSockets (powered by Jakarta) and REST, with WebSockets serving as the primary transport in the whole server. While initial attempts were made to utilise REST extensively, it proved to require a bit of more work on implementation in which time is another factor to always factor in in most cases.

What Is Complete

Ripple aims to be developed openly, I am inviting contributions to improve the server. Currently, the working available feature that is functional is the G-Streamer-powered WebRTC streaming broadcast capability. As a solo developer, some goals remain ambitious, but progress continues.

The Streaming feature

Refer to the demo HTML files labelled "G-streamer" for details on setting up WebRTC streaming. Without having to mention the WebRTC basic set up to connect, by creating a peer connection and sharing SDPs to connect and the client will start to get transmission from the webserver , this is primarily done to receive video, I did not dedicate a lot to transcode any other audio specific audio codecs as much . The focus here is primarily on video transmission at this given time, leveraging G-Streamer to adjust volume dynamically. The system is not limited to video; it can handle a wide range of media types as per G-Streamer .Transcoding is not limited here , its subject to what G-Streamer can do on the fly . This so far works by depending on the client defining the media it needs to stream for example "Medial-file.mp4" so meaning the client and setup can be defined to how the media is found and referred from the server side in terms of file path logic.

Client SDK

Ripple provides a JavaScript base file, 'rippleApp.js,' simplifying client-server interaction. Developers can focus on application logic while customizing callbacks as needed. In the future I look to expanding platform support to Android, Flutter, and JavaFX is on the roadmap.

Results

In testing, Ripple's streaming feature has proven reliable, delivering impressive video quality. It performed well even under the load of multiple simultaneous streams. The Streaming feature has proved to be very reliable on my local set-up (Windows 11, 16 GB RAM) and remote set-up (Ubuntu, 8 GB RAM) as well, audio quality was good and good video quality. On a remote platform located in this South African region so far there is no need yet to require or augment with a Turn server given the network set-up I was testing with. I managed to create over 8 instances of streams in different browsers (Google Chrome, Fire Fox, Edge) on the same machine and 12-14 instances with two different laptops streaming the same video file while utilising the same features at different intervals. The server proved to be performant. Memory management was optimized with JVM arguments, including enabling the G1 garbage collector and aggressive heap deallocation, For the purposes of this article I didn't provide memory snapshots to validate the performance metrics . In the tests, I used the following JVM arguments optionally ` ./mvnw quarkus:dev -Dquarkus.vm.args="-XX:+UseG1GC -XX:+AggressiveHeap" , or `-XX:+UseG1GC` enables the G1 garbage collector for memory optimization, `-XX:+AggressiveHeap` enables aggressive heap deallocation for better memory management, I did see a lot of memory footprint getting better.

Conclusion

Ripple is a work in progress, driven by the goal of simplifying WebRTC implementation and delivering standard WebRTC features. While the focus is currently on perfecting streaming capabilities, future plans include competing with servers like Red5 and expanding support for various media sources via WebRTC.

Thank you for reading my article; I've provided a condensed overview, leaving much to explore.