Topics In Demand
Notification
New

No notification found.

Factors to Consider for your first WebRTC Project
Factors to Consider for your first WebRTC Project

146

0

Live Video Interactions and Experiences have become popular in a lot of applications across industries. From Enterprise Apps to Entertainment & Sports, Telemedicine to Online Education, Virtual Events to Ecommerce, many businesses have transformed over the past couple of years with Live Video and Real-time Engagement. WebRTC technology powers such real-time communication capabilities in applications.

While planning a WebRTC project, some paramount decisions need to be taken into consideration which will significantly impact the capabilities you will be able to offer in your application, the user experience you’ll be able to build, how future-proof your deployment is, and the amount of effort you will need to infuse in maintaining your service and keeping it up to date.

In this article, we will be discussing the factors that need to be considered while planning WebRTC applications. We will also be highlighting some common WebRTC issues and their solutions for better real-time communication.

NOTE: This article assumes that you are building your application with the open-source WebRTC project. However, PaaS platforms like Agora, AWS Chime, etc provide more scalable and optimized RTC SDKs that are compatible across a large variety of device and browser types. Therefore, for most of the factors we have highlighted, we have pointed out how Live Video PaaS like Agora handles that.

Before starting your WebRTC project, your team needs to consider scalability, as it plays a vital role in the success of WebRTC projects.

ScalabilityIn Mesh architecture, each participant in a video room sends and receives video, audio, and information about their connection to each participant. This means that if you are connected to 5 people, you have 5 connections open. But, WebRTC does not scale well if used in this way. If you want to have more users, you will encounter CPU and bandwidth issues. To overcome this problem, use a Media Server to distribute the video to the participants.

Mesh architecture

This will also allow more advanced features like integration with other technologies and processing video streams. Once we have solved the problem of participants’ scalability with a media server, there is a limit on how powerful a media server can be. At some stage, you may need more than one server. For a large number of participants, we will require a great effort in maintaining the media server else we can use a Live Video API platform.

API platforms (or PaaS – Platform as a Service) are a set of servers and client development kits (SDKs) that provide everything you need for developing a WebRTC application. On the server-side, basic functions are handled by all API platforms like signaling between the parties, session connections, and media flows across various network topologies and network address translations. There are some APIs that can handle advanced features as well. These APIs contain multi-party communications, streaming, recording, and third-party integrations support for identity management and other capabilities. However, on the client-side SDK, many API platforms offer support for desktop browsers as well as common mobile devices.

 

API Platforms

Basically, these API platforms enable you to focus only on your business logic. The complexity of maintaining and scaling your WebRTC service is addressed by them. They provide you the media server setup and the client-side SDK, so that you can have your WebRTC project executed effectively.

Below are some of the common API platforms for Real-time Communication which can scale upto one million participants, depending on the business use-case.

  • Agora
  • Vonage
  • Twilio
  • Red5Pro

Below are some of the commonly used Open Source API platforms:

  • Jitsi
  • Janus
  • Kurento
  • MediaSoup
  • Pion
  • Asterisk
  • FreeSwitch

General Issues Faced in WebRTC:

WebRTC removes a lot of complexity while building a real-time communication application, but you still have many decisions to make and many moving parts to handle. There is no denying that WebRTC technology is taking the industry by storm, however, businesses fail to achieve desired results when they implement WebRTC practically.

Below, are the list of issues that you will encounter in your WebRTC application:

1. Device Compatibility: In the mobile world, WebRTC support isn’t on a similar level for what it’s worth on a Desktop. Mobile devices have their own way, so WebRTC is also something different on mobile platforms. For example, there may be a scenario wherein 1 peer would be using an iPhone and another peer has joined via a chrome browser, which can lead to improper communication. To overcome this problem, we can detect the device at a very early stage and proceed accordingly.

2. Browser Compatibility: Every browser doesn’t have all the same WebRTC features at the same time. Different browsers may be ahead of the curve, which makes some WebRTC features work in one browser and not another. In this scenario, we can show the warning to the end-user or check whether that WebRTC functionality is accessible in that browser or not and handle the case accordingly.

3. Device Permission Issue: When developing for the web, the WebRTC standard provides APIs for accessing cameras and microphones connected to the computer or smartphone. Device permission issues may exist, if someone has not given permission to another device for real-time communication. This issue can be solved on a pre-call screen.

4. Network Connectivity: Bad network has a notable effect on the WebRTC real-time communication, as video call/audio call works perfectly in one environment but degrades rapidly in another. This issue can be resolved by optimizing the bandwidth and setting up the appropriate video codec. In the case of Agora SDK, we have some inbuilt functions through which we can optimize the bandwidth and have a smooth video experience.

5. Session Recording: Recording is not possible, if we just use the browser WebRTC API. To get the session recording, we will require a media server to be set up, as the recording will be handled on the server-side. In the case of Agora SDK, it provides a set of REST APIs using which we can record and store the session for future purposes.

6. Not able to switch between different layouts smoothly: Sometimes we need to render different layouts according to business usecase. If we use different UI components for different layouts, then it might not give us a smooth experience. We should have a single UI component for different layouts for a better user experience.

7. High latency: If you are using core WebRTC API to get your project done, you will face a bit of latency in streaming as latency is dependent on the media server processing, and how efficient your media server is. To have a better user experience, you can use a third-party platform which has optimized streaming latency. In the case of Agora, it provides ultra-low latency to its users.

8. RTMP live stream appendment into the conference call: In WebRTC, there is a challenge while appending a live stream URL into your video conference. Suppose you want to append your Vimeo live into the WebRTC conference. It can be challenging in the case of WebRTC but in the case of Agora SDK, we have a direct function for this functionality.

Conclusion:

WebRTC is creating a storm, as it enables real time engagement and interaction among the participants. To harness its full potential, the correct decision needs to be made before starting the project as per your business needs. 

This article was originally published on BigStep Technologies.

About the author:

 

Kailash - BigStep Technologies

Kailash Malveeya, is Software Engineer at BigStep Technologies. Specialized in WebRTC Technology and expert in solving modern technology problems.

 

 


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.