WebRTC API Platform Pricing is… Complicated

Are you doing your WebRTC pricing per minute? per gigabyte? per device? You’re a developer. You decide it is time to build an application. But you don’t really want to do everything from scratch. Hell - you don’t even want to maintain and update all of that media backend - what do you really know about video? So you go look for someone to do it for you, finding a nice set of vendors offering WebRTC PaaS services. You can easily plug into their SDK and in no time have your service do group calling. You probably won’t be conquering the world as the next Whatsapp with such an approach, but getting that healthcare service up and running an education application or a visual contact center is now within easy reach. And you won’t be alone in this either. About a third of the dataset of vendors using WebRTC that I am tracking is using third parties. Most of them use managed services. But here comes the question. Do you know how much you’re going to pay for that WebRTC PaaS service? I get requests to assist in vendor selection on a weekly basis. This has been going for a few years now. This year, one of the main focus areas in this process has been pricing. Or more accurately, understanding the pricing schemes or the different vendors, and comparing the costs of these vendors. There’s no easy way to get that done… Why?

1. Because vendors have different pricing models
2. Because you need to fully understand your scenario
3. Because it just isn’t straightforward

Let's review the 3 leading pricing parameters are going to dictate your costs:

Minutes

This one may seem easy. You are going to pay for the number of minutes you use in a service. It should be easy to calculate. Easy to understand the value (the more you use the more you pay). But somehow, people translate minutes to the “old” days of telecom, where you paid top dollars to make phone calls. By the minute of course. The devil is in the details here. Here are few differences you’ll see between vendors.

1. Is there a minimum allowance of minutes? In many cases, a baseline monthly fee will be requested. That monthly fee will include pre-calculated minutes that you can use. They will usually be priced at their cost value. This is:
   • Seriousness fee. You pay so the vendor will spend the time necessary in answering your nagging support questions
   • Signal to customers. If that fee is high (hundreds of dollars or more), it is meant to signal you they are interested in businesses with money to spend - probably enterprises: “we’re taking only premium customers”. The alternative of very low monthly fee indicates a stance of “we cater all developers and happy to embrace the long tail”
   • Reduce noise. Non-paying”free-tier” customers are noise. Lots and lots of noise. They ask the most amount of questions, and usually these questions (and demands) won’t lead to a sale anyway. So vendors put some built-in must-pay price point to filter out the free riders who probably won’t help their bottom line anyway
2. Flat rate? Tiered? Pre-commit? Call us? Different vendors offer different methods to offer better price points (discounts) based on usage. Here’s what I’ve seen vendors do:
   • Flat rate. There’s a single price point. Take it or leave it. You just take the number, multiply it by the minutes and voila! You get your costs. It always comes with text saying that high volume pricing is available
   • Tiered. First X minutes are free (included in the plan). Next Y minutes come at a certain price. Z following minutes are at a lower price point and so one. Later minutes cost you less
   • Pre-commit. Commit in advance (and pay) for a certain number of minutes. If you pass that number, the low price point you already committed to will continue to apply
   • Call us. Almost always there in all plans. For big enough customers, we will negotiate deals suitable for both sides
3. What gets counted? Saying the price is per minute is nice, but what are these minutes counted against? Here are a few examples:
   • Actual media minutes. This is a common approach. You got an SDK of the vendor connected to a session, the time starts ticking
   • Connected devices. Then there’s the approach of connected devices. You are connected - you pay. Even if you send or receive nothing. This isn’t a common approach, but it does exist when the price per minute is low and combined with bandwidth payment (see below). It can also be tiered
   • Subscriptions. See below

The great thing about minutes? They are easy to comprehend and count. If you have 10 people in a call for 10 minutes - that’s 100 minutes (assuming we count per device here). The downside is that with minutes, there’s usually less regard to what is done in that minute. A video minute is the same as a voice minute on most platforms when it comes to pricing. And a low resolution video minute is the same as a high resolution video minute.

Subscriptions

Subscriptions is related to minutes, and deals with the question of what it is you count the minutes against? The two most common practices here is to count devices or count subscriptions. Some of the WebRTC PaaS services work off the notion of a publish subscribe mechanism. Devices can publish media streams into a session, and devices can subscribe to media streams from the session. This is an elegant approach that can nicely be used when describing a complex scenario with asymmetric behaviors. In an SFU group video call model, where each user publishes his own media streams and subscribes to the media streams of all other participants, the number of subscriptions grows at a polynomial rate: with N active users in a session, you’ll be counting N*(N-1) subscribed media streams. In WebRTC PaaS, paying per subscribed minutes tends to be cheaper than paying per device minutes for lower group sizes (and vice versa). It makes sense for a vendor to apply a per-subscription price as in many cases, his own costs are probably tightly coupled with the number of media subscriptions in the system. Subscriptions are slightly harder to count than devices, but it is still gives you a solid number and an easy estimate.

Bandwidth

The main complaint about per minute pricing is that it is a reminder of the old telecom days. The notion was that once we go for VoIP, cloud, web, WebRTC or whatever you want to call it, you can price it closer to the usage and not stay at the high level of a minute concept. If you AppRTC, Google’s “hello world” implementation of WebRTC, you can easily get 2.5mbps in each direction over a 720p or full HD resolution using VP8. Audio only? That would normally take 40kbps: If it was limited only to the difference between audio and video then so be it. Give two price points per minute and you’re done. But video is different. It becomes more of a hassle with video. You can probably get video going with as little as 300kbps with 10-20mbps being applicable to 4K video resolutions. That’s not including things like 360 videos and other crazy trends like 8K or 10K resolutions that were just added to the HDMI spec. So vendors are now looking into taking the route that is so common in IaaS - pricing per bandwidth processed. Usually, that would be subscribed bandwidth. The reason for that is that cloud services usually cost the vendor based on the bandwidth he sends to browsers and mobile devices and not for bandwidth it receives on its cloud servers. Here are a few quick things to validate in this price schemes:

1. Is price calculated on subscribed bandwidth only or on both send and receive?
2. If media gets routed towards the vendor (recording or SFU usually) AND the session needs to be relayed via a TURN server. Do you count the costs of TURN related traffic AND server processing traffic?

Note that if you’re doing peer-to-peer sessions (that means doing a 1-on-1 session where you don’t want media to go through the vendor’s servers), you won’t be paying for bandwidth at all - unless the media gets relayed via TURN. TURN relay depends on network conditions and can’t be estimated properly (highly reliant on your users), but a rule of thumb of 15-20% of the sessions is usually used here. Paying per bandwidth will tend to be cheaper than by minute. The reason is that the end result will be tailored to your exact usage pattern. That said, there are several downsides here:

1. It is usually hard to estimate in advance, as translating minutes of use to bandwidth isn’t straightforward
2. Different services will give different bitrates for seemingly the same service (I am working for a customer now, looking into the differences across many group video services, and it is devilishly hard to find commonality across the applications)
3. It is harder to calculate than the rest, and it usually contains also a per minute counting to go alongside the bandwidth calculation

Going for this IaaS type of a model is a great way to lower price points for customers, but at the same time it is a great way of dealing them with a huge headache. At testRTC, I’ve been trying for some time now with my colleagues there to estimate what are costs are/should be. How much will we end up paying for our IaaS vendors every month? It is so hard, that I usually can’t even understand the detailed invoices we receive at the end of each month. I fear that the same is/will occur with per bandwidth pricing in WebRTC PaaS.

Where Do We Go From Here?

In the latest update to my WebRTC PaaS report I’ve included a new appendix explaining pricing models in this space. But the coolest thing yet was the inclusion of a new tool - a price calculator. It is probably the 4th or 5th that I’ve created in 2017, each with its own nuances, target use cases and complexities. This one was meant to be as generic and as simple as possible. You enter the expected number of sessions you plan to have on a monthly basis, the number of users and the bandwidth per stream (there are a few suggested values in there). Then you enter the pricing model and the price points of the vendors you want to compare, and the result will be the expected monthly cost you’ll have for each vendor. Need something a bit more tailored? Reach out to me and I’ll help you out.