Be careful! Danger ahead while selecting the video infrastructure for your next use case!

by admin | Nov 7, 2025 | WebRTC

Are you a planning to start working on building a WebRTC based audio-video calling infrastructure for your upcoming use case? If yes, then be careful, there can be danger ahead if you don’t select the correct media server for your use case today. We are here to help you selecting the correct media server or infrastructure based on your use case need as well as the phase of the execution of the project you currently are in.

The possible alternatives for your use case are agora, tokbox, twillio, jitsi, janus, mediasoup, kurento, openvidu etc. This list has many other names in it as well. Her we have considered the most popular options out there to help you build your video infrastructure.

We primarily divide these above mentioned options into 2 categories. First one are the vendors who provide video apis so that other applications integrate them with less to very less effort. Second one are the open source media servers which one can use to build video applications on top of it as well but in this case the implementer i.e. you need to take care of the implementation part of it as well as the infrastructure part of it. Let’s analyse both of these options more elaborately and provide specific suggestions for each of these options.

agora / twillio / tokbox :- These are good, dependable and scalable api services. Agora is my top pick among them. Use these if you are building a MVP for a demo or if your video calling solution is not core to your business and your product’s customer satisfaction index is not directly dependent on this solution which you have build on top of them. The reason is that if they change their apis overnight, it shouldn’t break the core of the product. It is better to have less dependencies for the core of your product. 

Jitsi:- Jitsi is a really nice end to end solution for in house video conferencing needs when you don’t want to depend on zoom or MS teams for your team video conferencing needs. You can deploy the whole solution quickly and run it on premise cloud or managed cloud and use it without any issue. It is a good open source zoom alternative, may be the best one but it is not very good if you want to integrate it with your product to build your solution on top of it as it is less agile, modular and customisation unfriendly. It’s architecture and  it’s approach of getting things done in a certain way make’s it the best open source zoom alternative but not a great media server for your next webrtc project.

Janus/ mediasoup:- The 2 best open source media servers available today ready for integration in any use case. These are stable enough and scale nicely without much issues. Some amount of tweaking will be needed  to align it to your use case. The only point to mention about mediasoup is that it is currently available only as a npm module which means it can only be integrated with a nodejs backend server. Nodejs is a great backend server according to me and I use it for may use cases. I can assure you that Nodejs+mediasoup work very well with each other and is a wining combination. These both can handle 100+ participants in one conference call if implemented properly on a scalable infrastructure.Use these if your use case is more focussed on large group calls.

Kurento/openvidu :- Kurento is one of the most versatile open source media servers out there with capabilities of MCU and SFU based upon configuration. It also has options to integrate different type of filters like face detection filters, chroma filters etc. on the live media stream. It also provides capabilities to record the streams to a file or a http end point. Use this if you have unique use case where you don’t need a large group call and if you have in house kurento expertise. Openvidu is a signalling and application server combination built on top of kurento which can be used as an Jitsi alternative.

BigBlueButton:- BBB(BigBlueButton) is a good option for online classroom/ learning use cases. If you are a school or college OR a business catering to the needs of schools and colleges, looking for an online teaching learning solution on self hosted/ cloud based online classroom solution on your own domain name with full control, then this is a good solution for you. It has all the option needed for the teacher to control the students including muting all students in the class.

Finally there can be a question in your mind that should one own the video infrastructure or use it as a service? To answer this question of owning the WebRTC infrastructure, our take is this. If the WebRTC infra is core to your business and your monetisation strategy is directly dependent on it’s performance, it is advisable to own the whole infrastructure else go for a managed service or even outsource it.

In case you are looking for developing your next video project or adopt an open source one for your own use case, we will be delighted to provide our support in helping you achieve a great result for your use case. Don’t hesitate to drop us a mail at hello@centedge.io for a free 1st round consultation. #Happytohelp.

Using getUserMedia effectively in production video conferencing applications

by admin | Nov 7, 2025 | WebRTC

This is going to be an advanced post on using getUserMedia effectively in real world use cases while creating production grade applications. If you you are a beginner, please check this post first before going through this post.

While developing video conferencing applications, the getUserMedia browser API provides the capabilities to capture the audio and video streams and send these streams to the receiving parties with the help of RTCPeerConnection. In this article, we will discuss the twin concepts of capabilities and constraints to understand the browser’s capabilities of capturing the media streams with the applied constraints.

Here is how the process works.

• Call MediaDevices.getSupportedConstraints() (if needed) to get the list of supported constraints, which tells you what constrainable properties the browser knows about. This isn’t always necessary, since any that aren’t known will simply be ignored when you specify them—but if you have any that you can’t get by without, you can start by checking to be sure they’re on the list.

• Once the script knows whether the property or properties it wishes to use are supported, it can then check the capabilities of the API and its implementation by examining the object returned by the track’s getCapabilities() method; this object lists each supported constraint and the values or range of values which are supported.

• Finally, the track’s applyConstraints() method is called to configure the API as desired by specifying the values or ranges of values it wishes to use for any of the constrainable properties about which it has a preference.

• The track’s getConstraints() method returns the set of constraints passed into the most recent call to applyConstraints(). This may not represent the actual current state of the track, due to properties whose requested values had to be adjusted and because platform default values aren’t represented. For a complete representation of the track’s current configuration, use getSettings().

Defining Constraints

A single constraint is an object whose name matches the constrainable property whose desired value or range of values is being specified. This object contains zero or more individual constraints, as well as an optional sub-object named advanced, which contains another set of zero or more constraints  which the user agent must satisfy if at all possible. The user agent attempts to satisfy constraints in the order specified in the constraint set.

We also need to check first if the constraints we are going to apply are supported by the user agent / browser or not. In the below code, it first checks if the constraints are supported or not and then applies the constraints.

let supports = navigator.mediaDevices.getSupportedConstraints();

if (!supports["width"] || !supports["height"] || !supports["frameRate"] || !supports["facingMode"]) {
  // We're missing needed properties, so handle that error.
} else {
  let constraints = {
    width: { min: 640, ideal: 1920, max: 1920 },
    height: { min: 400, ideal: 1080 },
    aspectRatio: 1.777777778,
    frameRate: { max: 30 },
    facingMode: { exact: "user" }
  };

  myTrack.applyConstraints(constraints).then(function() => {
    /* do stuff if constraints applied successfully */
  }).catch(function(reason) {
    /* failed to apply constraints; reason is why */
  });
} 

Here, after ensuring that the constrainable properties for which matches must be found are supported (width, height, frameRate, and facingMode), we set up constraints which request a width no smaller than 640 and no larger than 1920 (but preferably 1920), a height no smaller than 400 (but ideally 1080), an aspect ratio of 16:9 (1.777777778), and a frame rate no greater than 30 frames per second. In addition, the only acceptable input device is a camera facing the user (a “selfie cam”). If the width, height, frameRate, or facingMode constraints can’t be met, the promise returned by applyConstraints() will be rejected.

MediaStreamTrack.getCapabilities() is used to get a list of all of the supported capabilities and the values or ranges of values which each one accepts on the current platform and user agent. This function returns a MediaTrackCapabilities object which lists each constrainable property supported by the browser and a value or range of values which are supported for each one of those properties.

Example

The most common way of using constraints is while calling getUserMedia() to capture the streams.

navigator.mediaDevices.getUserMedia({
  video: {
    width: { min: 640, ideal: 1920 },
    height: { min: 400, ideal: 1080 },
    aspectRatio: { ideal: 1.7777777778 }
  },
  audio: {
    sampleSize: 16,
    channelCount: 2
  }
}).then(stream => {
  videoElement.srcObject = stream;
}).catch(handleError);

In this example, constraints are applied at getUserMedia() time, asking for an ideal set of options with fallbacks for the video.

The constraints of an existing MediaStreamTrack can also be changed on the fly, by calling the track’s applyConstraints() method, passing into it an object representing the constraints you wish to apply to the track.

videoTrack.applyConstraints({
  width: 1920,
  height: 1080
});

Retrieving current constraints and settings

It’s important to remember the difference between constraints and settings. Constraints are a way to specify what values you need, want, and are willing to accept for the various constrainable properties, while settings are the actual values of each constrainable property at the current time.

If at any time we need to fetch the set of constraints that are currently applied to the media, we can get that information by calling MediaStreamTrack.getConstraints(), as shown in the example below.

function switchCameras(track, camera) {
  let constraints = track.getConstraints();
  constraints.facingMode = camera;
  track.applyConstraints(constraints);
}

This function accepts a MediaStreamTrack and a string indicating the camera facing mode to use, fetches the current constraints, sets the value of the MediaTrackConstraints.facingMode to the specified value, then applies the updated constraint set.

Unless we only use exact constraints (which is pretty restrictive, so be sure we mean it!), there’s no guarantee exactly what we are going to actually get after the constraints are applied. The values of the constrainable properties as they actually are in the resulting media are referred to as the settings. If we need to know the true format and other properties of the media, we can obtain those settings by calling MediaStreamTrack.getSettings(). This returns an object based on the dictionary MediaTrackSettings. For example:

function whichCamera(track) {
  return track.getSettings().facingMode;
}

This function uses getSettings() to obtain the track’s currently in-use values for the constrainable properties and returns the value of facingMode.

In case you are looking for any specific help with your production video conferencing application related to camera quality issues, do let us know at hello@centedge.io. We will be delighted to help.

Going to build a video conferencing app!! Consider these things before starting the trek

by admin | Nov 7, 2025 | WebRTC

In this new world of post covid-19, video collaboration is the new normal irrespective of the industry segment. As the work is going remote, video collaboration is a must in order to keep that human touch. A secure video collaboration tool is a need of the hour but there is no one size fits all tool available even today as every need is not the same. Building a video collaboration tool doesn’t mean it should cost a lot of time and resources. There are very good open source libraries available with their unique strength and weaknesses. But as the open source is not designed while keeping your unique needs in mind, a good amount of resources in terms of time and money need to to be dedicated to create a video conferencing system from scratch. We are here to help as a consultant in the complete life cycle of your product development for your unique use case. Listed below are the high level things to consider for developing a production grade video conferencing app.

The steps of building a video conferencing app can broadly be divided in to the below mentioned steps.

Defining your need (real need, aka the product road map)

Building a video conferencing system is not like building another web app. It is much more complicated than that as it has much more complexities in terms of technical things to deal with. That’s why we help our clients with the need definition so that we are crystal clear before writing even a single line of code. This also helps in setting our esteemed customer’s expectations properly and helps the development team in achieving the defined milestones in a timely manner without time and cost overruns. Click this link to Learn more about building a product road map.

Choosing the correct tech stack

Choosing the correct tech stack to build your app is very critical to meet the timelines as defined in the product road map. A product road map is a bunch of assumptions which meets the reality through the correct tech stack. There will be considerations like availability of good developers in the chosen stack, availability of reusable open source components according to the architecture, architecting the app to support agile development practices while sticking to the defined time lines, modularity along with flexibility and maintainability of the code base etc. There is no right or wrong approach here. Based on the use case, the tech stack and the architecture will vary. But overall, from our experience we can say that Javascript as a language, Nodejs as server and Reactjs as frontend language go well for building a production grade video conferencing system.

Building the app

Once the product road map is there, tech stack is decided and a high level architecture is in place, It is time to write the code. The code has to be written in a modular manner so that is will be easy to maintain a large code base a t a later point in time when the use case grows which leads to a swell in the number of lines of code. Keeping things DRY (Don’t Repeat Yourself) also becomes super important to follow as the code base grows. There are many other coding best practices to follow so that it is easy for a new developer joining at a later stage to understand the codebase within a short period of time. Below is a link to 50 coding best practice to follow for Javascript.

Testing the app

Testing the app is super critical to deliver the consistencies knowing that the best of the best developers also make mistakes while writing codes. Testing a WebRTC app in it’s length and breadth also become super critical not only to test the logic written in the code directly but also to test the indirect part of it like testing the app in different network conditions, different browsers, different devices etc. Here is a nice blog written by a globally renowned WebRTC evangelist about his view on WebRTC testing. Here is the link.

DevOps (Cloud deployment / Scaling)

Devops plays a very critical part in success or a failure of a WebRTC app. WebRTC needs at least 2 kind of servers(application and signalling) which can go upto 6 servers( application, signalling, media, recording, NAT Traversal and recording post processing). Specifically media and recording servers need good CPU, Memory and Network bandwidth even for 1 successful call. The ideal media server is a c5.xLarge VPS which is 4 core CPU with 8-16gb of RAM and 10GBPS network. Ideal recording server is a c5.large VPS. It is always good to prefer a compute intensive VPS for media and recording related things. Scaling from 1 meeting to 100 meetings is more of an Art than science. It needs a good command over dev-ops best practices and a deep knowledge of your chosen cloud vendor to achieve good results in scaling.

Post implementation

As WebRTC is a moving target, keeping a good post implementation support team is critical to the success of the product. The point to note about the post implementation support is that, the service can break any time due to not fault of your code but for some random change in a popular browser after a recent upgrade. Therefore it is important to keep a good post implementation support team for your production grade WebRTC app.

We recently started our consulting practice to help others plan and execute their video conferencing trek in a better way. Do drop us a mail at hello@centedge.io about your plans and we will be happy to help you.

Videoedge Magic rooms v2.0, now available for public beta at your nearest available Chrome browser!

by admin | Nov 6, 2025 | WebRTC

As this post is being written, videoedge magic rooms v2.0 is now out and has opened it’s doors for public beta starting from today i.e. 21/01/2021. The biggest change from v1 to v2 is that private rooms are now available for use with all the features that were available on our public demo room released in the v1 last month. As we were completely occupied with fixing the bugs reported by our early users, we didn’t get any time to write a v1 release note. We are sorry for that. Going forward, we will try to write a release note for every major release. We also are hugely thankful to our early users who used the buggy v1 and gave us the important feedback in order to make the v2 possible.

Below are the list of primary features which are currently available and ready for use.

• Unique shareable room link

• Private meeting rooms for registered users. The public demo room is available as usual for all the non registered users.

• Pre-call Camera /Mic / Speaker selection

• Group conferencing up to 6 participants (Our code can handle up to 30 but our tiny demo server cannot !)

• In call Mute/ Un-mute and camera on /off

• Moderator mode for being able to authenticate users before joining the room

• Moderator able to mute/ un-mute others, switch camera off of others (can’t switch on others camera due to privacy concerns) and kick others out of the room

• Viewer mode enabled for people to join as a viewer / listener only without participating in the ongoing discussion

• Screen-share by one or more moderator or participant. Viewers can’t screen-share!!

• Publish an IP camera to the room for everybody to view. This is particularly useful for security and surveillance use cases where a video conferencing can be done to take real time decisions while viewing IP / cctv / drone cameras. Keep in mind that, it currently supports an input source in the RTSP format only.

Here is the link to the recently released videoedge magic rooms.

In case you are facing any issue with the videoedge magic rooms while using it or it is not working for some reason, don’t hesitate to let us know the issue and we will try to fix it up with priority. In case you like it and want us to add a new feature for your use case, please let us know as well. We are reachable at hello@centedge.io

Meet the new Centedge Magic rooms for all your upcoming meetings!

by admin | Nov 6, 2025 | WebRTC

Centedge Magic room is here, finally! It was long last month where many battles had to be fought, both inside inside and outside of VS code(the code editor we use!) to reach here. The whole story will take it’s own time to come out.

Now coming to straight to the point as this post is going to be a release note for our latest release. This is the most anticipated release from our side as it has all of the things needed to run a meeting, audio/video, screen sharing, recording, chat along with innovative room configuration options to configure your video rooms for any kind of use case from a intuitive dashboard.

Here are the key features.

• Unlimited group meetings in personal room(without recording !)
• Configure and use magic rooms with all features including recording
• 2 configurable magic rooms with up-to 100 hours of usage and 1 GB of free cloud recording are included in the free plan
• Option use it as a shared service at meet.centedge.io or have it at your own custom sub domain like arbalest.centedge.io as a dedicated service
• Fully possible to host it in your own enterprise cloud / data centre
• Perfectly possible to consider this as a base video room and build your own service on top of it with our custom support and customisation plans
• All cutting edge things like Simulcast/SVC, Auto scaling of infrastructure based on demand, active speaker detection, real time bandwidth monitoring etc. are either already implemented or in the pipeline. To check simulcast implementation, join the room from a desktop and a mobile device to verify that they both are using different bit-rates (XX Kb/s) for the same user video.

Currently once either has to build a video conferencing service from scratch if one want to own the service but it needs a good amount of time, effort and expertise for the same. The other option is to rent out from somebody with less cost but you really can’t own the service. Our goal is to provide you the best of both worlds where we let you own your own video conferencing service without renting it out as well as without spending a good amount of time and effort in building it. With us, you can own a video conferencing service within a day or 2 with resources as low as $$$$ / year and use it for unlimited time and unlimited users.

We also are working on a not for profit plan so that not for profit organisations looking for dedicated video conferencing applications for their needs can now adopt our dedicated solution at a unbelievable price of 1$$$ / year with support and up-to 3 customisation requests included in that plan. A separate detailed post will be shared in a couple of days with relevant details regarding this offering.

Here are the full set of features.

• Unique room Link
• Select Camera / Mic
• Live streaming up-to 20 participants
• Group conferencing up-to 12 participants
• Mute/ Un-mute
• Video On/Off
• Option to join as presenter / viewer
• Room Moderator settings
• Screen share
• Publish IP camera to meeting Room
• web/mobile browser(Chrome/Safari)
• Recording (Sever side Only)
• Store recordings in AWS S3
• Unlimited personal room usage (without recording!)
• Create Static and / or Dynamic room from dashboard
• Active speaker detection
• Real time bandwidth monitoring

Note :- As we are running on a small scale infrastructure based on the available credits we have from AWS, the service may not be as great as a production grade video conferencing application. The purpose of this app is to let everybody know that there are guys like us also exist who build good things silently and let the app make noise at its own time. We know that we may not have reached there yet so that our app will make noise but we will reach there soon.

If you are looking for building a video conferencing app either for video banking, video insurance, video surveillance,video education or video health, do let us know. We will be super happy to help you build your own app or enhance your existing one to make it better. There is also another great option to adopt our service as a managed service for your own use case and build on top of it.

Here is the link to our latest video rooms:- Magic rooms

We are reachable on email at hello@centedge.io. You also can chat with us using the chat widget on this website. We typically respond within 5 minutes or sooner for chat and 1 day (max.) for email . You can schedule a free 30 mins call with one of our senior consultants using this link for resolving your doubts/ concerns not only about our services but also about how your existing services using WebRTC for video conferencing or live streaming can be improved. Here is our LinkedIn page to stay connected.

Happy to help.