An API platform with a touch of Java.
There are many ways in which API platforms come to life. From those that started off with WebRTC from day one, to those adding it to an existing communications API focused on PSTN or a video conferencing cloud API.
Frozen Montain is one of the players providing an API for developers to assist them in building services that require video communications. WebRTC came for them just in time to leverage on its promise.
I took the time to sit with Anton Venema, CTO and President of Frozen Mountain Software, to understand more about his offerings, why and how do they make use of WebRTC.
What is Frozen Mountain all about?
We are all about creating powerful, easy-to-use SDKs for other developers across all platforms. We want to take complex application requirements and boil them down to their essence, making it easy for developers to assemble enterprise-class applications in record-time. One of our primary focus areas right now is IceLink and WebRTC, making peer-to-peer communications as simple and intuitive as possible and taking away all the hard stuff so developers can focus on what makes their application unique.
Who are your potential customers? What do they usually want to develop?
Our potential customers are application developers, from indie start-ups to mature teams. Many of our customers are interested in improving communication, both within their organization and without. They do this in a variety of ways, using our technology to stream video conferences, offer online tutoring and classrooms, or stream other highly visual data such as medical imagery. In many cases, our customers are especially interested in our WebRTC solution for Internet Explorer and Safari, which allows them to use one API and instantly gain support for legacy browsers as well.
What made you start using WebRTC?
We have always been interested in building a reliable peer-to-peer SDK. We had already laid out the fundamentals of IceLink when WebRTC emerged as a viable standard, and with backing from some large and trust-worthy names like Google and Mozilla, it only seemed natural that we would create a WebRTC-compatible layer on top of IceLink. When we realized that Internet Explorer and Safari weren’t going to have a native implementation any time soon, we saw an opportunity to use our SDK to provide the missing functionality.
What excites you about working in WebRTC?
There is serious power behind peer-to-peer communications. Universal video chat has always been a lofty goal, but WebRTC seems capable of actually making it happen. On top of that, decentralized applications are gaining significant popularity. Previously well-established application designs are being rethought as the economic and sometimes political advantages of peer-to-peer become apparent. Being able to do all this in a web browser is astounding, and a clear indication of how far the web has come since its inception.
What signaling have you decided to integrate on top of WebRTC?
IceLink itself is compatible with any signaling mechanism. Out-of-the-box, we ship our examples using WebSync, our Bayeux-compliant “HTTP push” solution, since it works natively in JavaScript and every other platform we support. Some of our clients, especially those integrating with existing enterprise systems, have opted to use another signaling solution, most frequently XMPP or SIP.
Backend. What technologies and architecture are you using there?
IceLink uses the ICE algorithm for connectivity (hence the name), which uses STUN/TURN. Media packets use RTP/RTCP for unencrypted streams and SRTP/SRTCP with AES for encrypted streams. Both DTLS-SRTP and SDES are supported for key exchange, and SDP is used for the offer/answer/candidate exchange. IceLink also includes a server component for .NET, Java, and Objective-C so you can run your own STUN/TURN server.
When you mention RTP/RTCP and SDES – these don’t apply for WebRTC. How and when do you use them?
RTP and RTCP are built into the IceLink core and provide the necessary foundation for SRTP and SRTCP. Since IceLink supports non-WebRTC applications as well, the unencrypted option is still available for use cases with that specific requirement.
SDES was the key exchange mechanism originally used by Google Chrome’s WebRTC implementation, so it’s been a part of IceLink for quite some time. The WebRTC consortium later agreed to use DTLS-SRTP, which IceLink and Chrome both use by default now. SDES remains available as an alternative for non-WebRTC applications that use secure signaling.
Where do you see WebRTC going in 2-5 years?
We hope to see Microsoft and Apple take a positive position towards the emerging standard and perhaps take steps towards integration with their web browsers, both desktop and mobile. A Java applet will never be quite as fast as a native solution, and we hope that they don’t miss out on this opportunity to take their browsers to the next level.
If you had one piece of advice for those thinking of adopting WebRTC, what would it be?
Take the leap! WebRTC is very robust and getting more so every day. It is highly useful right now for a wide range of applications.
Given the opportunity, what would you change in WebRTC?
Given the opportunity, we would have made the SDP requirement optional. For web-only implementations, the SDP message format is clunky and difficult to work with. While it has tremendous value when integrating with existing systems, we would rather have seen it materialize as an optional layer used when needed for those specific cases.
What’s next for Frozen Mountain?
Besides keeping up with the WebRTC standard, we want to offer a cross-platform SIP/XMPP option and add support for server-side media multiplexing and recording.
–
Note: Frozen Mountain didn’t make it into my latest report on WebRTC API Platforms. I will be adding them in an update to that report next quarter.
The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.