A couple weeks back, I presented at the WebRTC Conference & Expo in Miami on the topic of Media Servers. This is a topic I've presented many times in the past but this time I took a slightly different approach - I wanted to present from the angle of the developer implementing their WebRTC services, the problems a media server can help solve and the benefits to the user experience. So I'm sharing the (3) frequently asked questions I get asked while discussing media servers and structured my slides around these questions. My slide deck can be downloaded here but I wanted to recap some of the points during the presentation. 

Q: WHY TERMINATE MEDIA? (and the slight variation, I thought WebRTC is peer-to-peer media, what do I need a media server for?) 

 A: Absolutely true, at it's purest form WebRTC media is peer-to-peer but there are a few reasons why you want must terminate media. First, Traversal Using Relay NAT (TURN) is a method of providing a public server (IP and port access) to relay WebRTC endpoint media for situations where direct peer-to-peer media fails such as when symmetrical NAT is present. Industry average for TURN server usage is ~15% and if you are looking to setup a reliable service that utilizes WebRTC then deploying a TURN server is a must (here is an easy to follow guide for setting up your own TURN server). Second reason for terminating media is if you want to gateway to an existing telephony network, you'll need to transcode the media from Opus/VP8 to G.7XX/H.264.  The last reason you would want to terminate media is for adding advanced functionality to your service that goes beyond your typical peer-to-peer such as centralized recording, multiparty conferencing or stream processing (adding image/video insertion, call analytics, or simply adding DTMF). These are the building blocks for creating feature-rich services today and can lead to even more in the not too distant future (see how this developer used the PowerMedia XMS media server along with openCV to create a facial detection software to deter nodding off during lectures here). 


A: Developers often have concerns that by architecting around a media server that they are then restricting their scalability when in reality it's the opposite. Scalability through a media server can be looked at in two ways - vertically and horizontally. Increasing the vertical scalability (or how we can get more out of a single instance) is tough because there is a hard limit to how much processing one server can do at a time but we can get smart about that processing in hopes of reducing the server cycles for a specific task. Take for instance multipoint conferencing - large and by far the biggest cycle expense for conferencing is the encode process of sending streams back out to the clients but Dialogic has developed a process called encoder sharing where it looks at the various streams sharing like resolution / frame rates and creating efficiencies by sharing that encoder with more than one client thus reducing the overall compute resources. Scaling horizontally (or seamlessly adding media servers into a cluster) can be achieved through a Media Resource Broker (MRB). The MRB is an intelligent load balancer and orchestrator for media servers. It sits in-line between the application server issuing the business logic commands and the media server cluster. It then can intelligently distribute call resources to various media servers based on the type of call or the destination. Combine this concept with the work happening around NFV and we can now start to programmatically scale services and be elastic to accommodate the need of the network on the fly. 


A: Reliability is always a concern but especially when it appears media has a single point of failure as when using a media server. I wrote about media server reliability earlier this year in "MRB is the WORD" but as part of the MRB role, it will actively poll the media servers in the cluster and can seamlessly move the active media streams from one media server to another upon failure detection. The slides I posted to slideshare and the previous blog i wrote both have a short video showing this failover. 

In summary, like it or not a media server will sometimes be needed regardless of WebRTC being P2P and terminating media will add feature-rich functionality to your services but be sure to always maximize the value you get from it.