5 Considerations Before Starting That WebRTC Project

As with any deployment, adding WebRTC to your environment requires careful consideration to ensure the execution produces the capabilities and User Experience that you expect. In this post on No Jitter, WebRTC commentator Amir Zmora discusses five considerations before beginning a WebRTC project.

API Platform

API platforms provide browser support on the client SDK side, with the server side handling basic functions like signalling, session connections, and media flow, among others. While they are useful, drawbacks include vendor lock-in and usage-based pricing that can hinder future growth. Since WebRTC is an open source standard, developers are free to leverage the code in their own way. This approach raises some developmental concerns, but there are also various components and SDKs that will ease the technical burden.


Whether you are using the available wrapper SDKs and server components or not, you will need to address signalling. The WebSocket API is commonly used for transport, but if you intend to connect with existing telephony systems, which typically use SIP, then it makes more sense to choose SIP over WebSocket. But it is important to assess your communication needs before choosing one.


The codecs you choose can have considerable repercussions on the quality of your communications. For voice and video, finding the right balance between cost and quality will depend on your specific needs. Common browser expectations should also be taken into account, as should future plans.

Server-Side Functional Elements

In addition to these server-side functional components, you should prioritize the list of server functionalities you may require to support your decisions on using third-party components or self-developing. Despite vendor lock-in, third-party server-side components can save considerable time and money.


Mobile support for WebRTC covers browsers and applications. Browsers tend to experience more occasional usage since most mobile phone interactions occur in apps. Safari still doesn’t support WebRTC, and the author believes this may happen in 2017. WebRTC is already being integrated into apps on both Android and iOS, but historically this has been a complex task. iOS development requires compiling the Integration manually while Android WebView’s support for WebRTC makes the technology usable in hybrid applications. Alternatively, you could follow IBM’s lead and use the IOSRTC plugin of Cordova for a device-agnostic Framework.
Researching your requirements and relevant options before beginning any development is essential for ensuring an efficient deployment that improves your service to benefit your users.

Be sure to read the next Mobile article: MightySignal Reveals the SDKs that iOS Apps are Using

Original Article

5 Factors to Consider for Your WebRTC Project