- What is the real purpose of the JS library?
- Do I need one for WebRTC?
- What should I consider when evaluating this component of a WebRTC solution?
- What makes a good JS library, what makes bad one?
These are the nagging questions that I wrestled in my own early research into WebRTC. At this point, I have certainly not personally used every WebRTC JS library out there, but have certainly tried quite a few. In this post I’ll attempt to address these questions, and my own thoughts on what is in a WebRTC JS library.
A bit of history…
an early impression stuck out to me: the realization that WebRTC’s power was going to be wielded by developers
You could say that the web had an already established, full scale signaling plane, that was just waiting to be used for WebRTC
A quick primer
Listing shows WebRTC JS libraries with public documentation. Check out our Tool Vendor Directory for a more complete list of WebRTC tools.
So many choices!
Initialization of the library
|After the library is initialized (and sometime in conjunction with initialization), it is common for some sort of registration function to take place. This can serve to nail up a connection to a signaling server somewhere, and let a service know that the user is ready to receive inbound signaling messages. It is common that registration also involve some security procedures to provide authentication of the user and/or the app as it connects back to the network (see security notes below).|
Create and Manage WebRTC Sessions
Ease of use
Extensibility and exposure
While ease of use is nice, it is also important that the library not sacrifice information and functionality for the sake making it more simple. As mentioned previously, the “call in X lines of code” is nice to get started, but inevitably you will find yourself needing much more code for greater functionality.
Under the hood
So, that means the important part is the actual functionality and capabilities delivered by a service, via the WebRTC JS library. Beyond the basic common methods, naturally much of this depends on the infrastructure and use case. Ranging from general telephony, conferencing, collaboration, IMS/RCS, customer relationship management, or social networking, the requirements of the web application can be quite different. Sadly we can’t possibly get into a complete analysis of all use case requirements, cross referenced with the features and functionality of the services that are represented by all the different WebRTC JS libraries. However, some questions to ask:
- Do I need access to a communications network (e.g. IMS, PSTN)?
- Is there an existing web, or communication architecture I need to integrate with?
- Can I plug into an external directory, or use my own?
- What are my security requirements (see note on security)?
- Do I have specific user experience requirements, like multi-party conferencing, co-browsing, file sharing, or screen share?
- Any requirements for Data Channels?
A Quick Note on Security
So, What’s in a WebRTC JS Library?
Doug Pelton says
Thanks for including EasyRTC in this fabulous post. I really like the Easy St and Functional Way picture.
I think two key considerations you could add in choosing an API is whether you need to control your own WebRTC signalling server on premise or in the cloud or use a PaaS,
AND whether the API and/or signalling server are open source or not.
Reid Stidolph says
Thanks Doug! You make a great point about deployment options and open source. Especially when it comes to the JS library, having it open source is definitely nice so you can contribute features, or make your own customization if needed.
Lorenzo Miniero says
Thanks for the interesting read, a really nice insight on what a library needs to provide.
One thing that had me thinking in particular was about the high level vs. low level approach for the library: this is a challenging question in general, as for instance it’s something that was part of the standardization process as well some time ago, which eventually led to JSEP. Eventually, considering the general purpose of the gateway, I chose a slightly lower level approach that does make things easier than using the WebRTC API, but also keeps some flexibility. After all, you can always tailor a higher level API on a lower level for some specific scenario, which is what I think I’ll try and face in the future.
Reid Stidolph says
Hi Lorenzo, thanks for the comments. Also, thanks for bringing Janus to my attention…I added Janus to the listing above.
You have a good memory on the early WebRTC API discussions, and what led to JSEP. I think developers will ultimately appreciate more, not less when it comes to functionality…but having an easy way to quickstart is always appreciated and can only help adoption. As you say, it’s good to start with all the power and functionality in mind, and then make it simpler as you need to.
I’ve been using AngularJS a lot lately, and I must say that there is just no easy way (that I’ve found) to quickstart the concepts of that API. I nearly gave up on it several times while climbing that learning curve, but In the end, I’m glad for all the super powers that you get with it.
Thank you for this superlative article. I am particular happy about that brief mention of AngularJs and steep learning curve, which leads to my question:
Have you implemented any of this with Angular? Which will be your personal choice with Angular?
Reid Stidolph says
Hey Mark, thanks for the comments. Personally I am a big fan of Angular, but for me the learning curve was steep. I found many of the concepts, conventions, and lingo can be quite abstract at times (directives, data bindings, and factories, oh my 🙂 !), and I really had to commit myself to learning them. That said, once you get the hang of it, it really does give you super powers, and it is amazing how fast you can create awesome, dynamic web apps.
As for implementing Angular with WebRTC (and the WebRTC JS libraries), yes I use it all the time. Angular goes really great with WebRTC, because WebRTC implicitly requires you to maintain a somewhat complex signaling state machine in the browser, and at the same time, manage the browser’s media engine state through the WebRTC API. Both of these result in a lot of asynchronous activity that has the get handled via lots of events. Of course, to make your web app awesome, you need to handle many of the async changes in state, and use them to update information on your HTML (e.g. on incoming call, activate a div containing a call notification and start playing a ringing audio file).
Handling this sort of dynamic state is where Angular really shines. My basic approach has been to gather all the different handlers and methods into a single object, and I define a set of very basic properties that become my Angular data model (e.g. primitives for signaling channel state, incoming call state, and so on). Once you have your data model set up and working, it is a snap to use the Angular data-bindings and directives in your HTML to automatically trigger HTML5 awesomeness whenever your state changes!
Anyways…hope this helps!
I am new to webrtc and your articles have been very informative. Thanks.
Please i would like some clarification.
Since there is no defined signalling protocol, which part of WebRTC makes the Signalling Data consistent across all Signalling Protocols ¬ and Why and how does it make signalling data consistent?
Chad Hart says
It’s called JSEP and it can be a little complex: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-11
I recommend looking at one of the many resources that walk through establishing and controlling a peerConnection.
I had a question, Is peerJS a signalling server that we use with WebRTC?