WebRTC Development Tools – Where to Begin

I just reviewed 120+ companies that have some direct support of  WebRTC (click here for the directory). The good news is that there is a multitude of companies and products out there for supporting WebRTC developers–more than 60+ and growing. WebRTC is still in its infancy so this number could easily double in the next couple of years as adjacent industries and the laggards get on board. The bad news with the large number of tools out there means there are a lot of hard choices to make. I’ll attempt to provide some starting guidelines based on my observations here.

Who are you developing for?

Since the WebRTC software and tool market is already crowded, most vendors are aligning themselves with specific communities. Generally, they appear to fall into the following camps:

• Personal & SMB websites
• Enterprise web-sites
• Web-based services
• Telecom-based services

The needs of a personal or small-scale blog (like this one) are relatively basic. There are several simple plug-ins for WordPress, Drupal and widget code you can add to your site to allow people to call you with WebRTC.

On the enterprise side of things, functionality is generally more critical to customer satisfaction and driving revenue. There are enterprise-grade offerings suited to businesses and contact centers who need high stability and instant support when WebRTC calls stop working. Supporting enterprise developers is typically an adjunct to the larger platform and custom coding may not be required.

Communications technology organizations like many web-based services or traditional telecom companies have very different sets of needs. Vendors that support these communities orient themselves to serve application and service developers. They typically provide developer forums, sample code, and specialized support specifically for developers in addition to their products or services. There are many WebRTC companies aimed at serving the unique reliability and regulatory expectations of the approximately 2000 traditional fixed and mobile service providers. There are even more who target the many thousands of companies in the burgeoning web and mobile app market place.

Since WebRTC is still an evolving technology, aligning with the right vendor community is critical for making sure you continually get catered products and services for your specific needs.

What kind of development are you good at?

Assuming you have a good idea of what WebRTC community you best align with, the next step is to evaluate what kind of development skills you have and what will be required.

If you have no development expertise, you have three choices:

1. Stick with a basic plug-in or widget-based service
2. Hire a firm who will do the development for you
3. Learn to some basic coding and come back to your project

There are a handful of companies with embeddable widgets and standard web-site plug-ins today and I expect many more will emerge.

Hiring someone to do your WebRTC development is another option. There are a relatively small number of firms aligning themselves with those capabilities. That being said, I am sure many of the cash-strapped startups out there would be happy to do custom development work if it somewhat aligns with their product ambitions. Many of the larger firms already have consulting groups that do this already.

If you are a developer, then odds are, you can do some front-end development – statistically speaking and that is the largest development audience. Fortunately many tools are oriented at front-end developers and require little to no expertise outside of making REST API calls. Most include some kind of basic JavaScript SDK to make this even easier. All you need to do is to sign up for an API key.

For those wanting to build something more sophisticated on the server-side, there is a smaller number of back-end tools meant to run on the server using PHP, node.js, or .NET.

As mentioned earlier, there are also many tools oriented at the traditional telecom service provider, large Contact Centers, and enterprise Unified Communications Communities. As the IETF’s SIP is telecom’s universal signaling protocol, these tools almost universally utilize or interface with it. While there are many companies offering API’s to connect to the SIP world, Telecom-oriented WebRTC tools assume you want to manipulate telecom protocols yourself for deeper integration or more advanced used cases. The front-end oriented API-based services are geared towards web-developers and only offer relatively basic calling and messaging capabilities for PSTN connectivity.

Lastly, while WebRTC starts with “Web”, it is not limited to the browser. There are many SDK’s out there for supporting WebRTC in mobile environments. This is fairly critical since there is no easy means of supporting WebRTC with Safari on iOS (and other mobile browsers like Windows, BlackBerry, etc.). The better SDK’s use native mobile OS API’s to access the camera and microphone. iOS SDK support seems to be popular, likely due to its large market share and Apple’s silence on supporting WebRTC.

Are you willing to pay?

Like most things in an open market, there is a broad spectrum of prices and options out there. Are you broke and just looking to experiment with some ideas that use WebRTC? There are freemium services for you. In fact there are many WebRTC companies out there in Beta mode who haven’t even figured out their pricing models yet. I still call these freemium – you can use them free for now but it is inevitable that they will need to charge you something once they figure out how.

Do you just hate the idea of paying anyone ever? There are more open source tools popping up every day. Often, but not always, these require a higher degree of expertise to deploy and manage. Of course if you are really 1337, you can just download Google’s various WebRTC source code here and skip the rest of this blog.

Are you a part of an enterprise IT organization where your boss would laugh at a project proposal that doesn’t use any budget? There are plenty of commercial companies out there that will take whatever you are willing to pay and suffer your vendor abuse as a result.

Can you host the solution?

Next, you need to think about infrastructure. In today software-oriented world, it seems like an antiquated notion to consider server and networking. WebRTC is not like your standard software that can run anywhere in the cloud without negative repercussions. It is real-time and media-oriented (unless you are just using the data channel). Real-time means networking issues do matter, especially if you plan to terminate media server-side. You want as few hops as possible and consistent routes in your media flow for low-latency and minimal jitter. You also want to make sure you are not behind an overly restrictive firewall or funky NAT device to reduce the need for TURN relay (see below).

If you follow the WebRTC specs, and you should, all WebRTC services require access to a TURN server as part of the ICE protocol. TURN relay is used as a last resort when two end-points cannot communicate directly due to NAT & firewall issues.

Other than for TURN relay, is there a reason to run WebRTC server-side? There are many applications that could benefit or require server-side media resources, including:

• Multi-party conferencing – combining multiple media streams is best done with a Multi-point Conferencing Unit (MCU)
• Transcoding – converting from one codec to another for interoperability purposes (i.e. VP-8 to H.264)
• Camera & voice UI applications – many applications are based on a central server doing heavy analysis on the media stream may not involve other parties
• Real-time media modification – if you plan to do significant alteration of the media stream – like inserting an avatar over someone’s face – it may make sense to do it on the sever

Media manipulation can certainly be done in a peer-to-peer model. However, if you plan to support mobile devices, you need to consider processing and battery-power. Media manipulation is always a huge drain. As companies like Skype have realized, even peer to peer signaling is not always optimal for mobile devices.

Hosted solutions should include at a minimum a TURN server as part of their offering. Ideally, they will also have architected their network infrastructure to minimize latency too. While going with a hosted provider is certainly the easiest route, they may not meet your technical or cost requirements. It may be more effective to do your own hosting if you have unique feature, performance, or scalability requirements.

Do you need to call the PSTN?

The last major area to consider is if you want to connect to the PSTN. Most WebRTC applications do not and that is not likely to change. Still, there are roughly 6 billion phones connected to the PSTN so this feature can potentially add a lot of value to certain services. If you want to connect to the PSTN, you have a couple of options:

1. Host software that includes a WebRTC to SIP gateway and plug it into a SIP trunk (or your own SIP infrastructure that is already connected) – there are a whole range of products out there for this than span open source to high-end commercial infrastructure.
2. Use a hosted service that does this for you – most of these have simple API’s you can use and pay by the minute or message

 

Where to Next?

Hopefully, that helps to provide some direction. Some of the choices are fairly obvious. If you are a telco service provider that has been serviced by a specific vendor community, obviously it is much easier to turn to that community for WebRTC support. If you are developing a mobile app and your vendor does not have iOS support, then that is most likely a problem. If you don’t have your own data center and have no idea how to set one up, then you probably are going to need to use a hosted service. Similarly, if you are extending an existing SIP-based telecom service, then you probably will want your tools to have SIP support or a PSTN gateway.

Other choices are less obvious – how do you easily tell if a hosted provider’s network has been truly optimized to maximize for media quality and to reach the most users? Is there an advantage in one JavaScript API for making calls vs. another? How do you make the peer-to-peer vs. peer-to-server-to-peer cost and performance trade-off’s? Unfortunately there are no easy answers to these questions but we hope to dig into them further in future blog posts.

In the mean time please check out the WebRTC Developer Tool Directory and my Introduction for it.

{“author”, “chad“}