Blog

Bandwidth pricing versus per minute pricing

September 16, 2014

Time for another blog post! Only this time, we’re going to focus on the business side of things. For quite a while, our pricing model was shrouded in mystery. We weren’t very good at thoroughly explaining it to our clients, but we knew it would fit the peer-to-peer nature of WebRTC like a glove. We decided to roll out a pricing model based on bandwidth — not the standard telecom per minute pricing.

If you’re new to the telecom space, here’s how the standard pricing model was like (and still is like) over the past decade. Say you’re using a service that allows you to call another user in the browser with audio chat. This service would charge you on a per minute basis for every user in the call. For example, if the service charged you $0.0035 per user per minute, and you had 4 users chatting in a conference room for 2 hours, that would cost you 4 users x $0.0035 per user per minute x 120 minutes = $1.68 A worthy, tested and true business model. However, it was made for a streaming technology that requires one to stream all of the data through the service provider’s servers. So it made absolute sense to charge for all of the data.

WebRTC is a tad bit different. One of the foundational traits of said tech is that it is mostly a peer-to-peer technology, meaning that the typical use cases involve data bypassing the service provider’s servers, streaming directly from client-to-client. Finally, we were able implement audio chat and video chat in an inexpensive manner via the web browser. I still can’t believe WebRTC is only a couple of years old! When I first ventured into this space about a year ago, I remember noticing that most of the companies I came across still hadn’t considered switching from the old model. Even though the technology itself promised cheap delivery, the companies providing it did not. The per minute model was still a showstopper for small startups hoping to go large-scale. From what I see now, prices have improved over the years. But at the time, there was only one choice.

Enter XirSys, the first and (correct me if I’m wrong) only company that was charging based on client-to-server bandwidth usage. This was hands down the best solution for my startup. Since ~85% of WebRTC traffic is true peer-to-peer, XirSys would never see those video streams; it would only see the last ~15%. Statistically speaking, these latter users are behind complicated firewalls that prevent a standard peer-to-peer connection from being made, so they must instead connect via the traditional method of relaying through the service provider. Lo and behold, ~85% of my website’s traffic would not even reach XirSys’s bandwidth counter. Peer-to-peer connections are called STUN connections, and relay connections are called TURN connections.

And of the 15% that I was billed for, I was lucky to have been building an audio chat startup. I’d be spending some more if I had been developing a video chat app, as this type of streaming is inherently more expensive. But that’s also the beauty of bandwidth-based metrics. Are you building an audio chat app? Video chat app? Screen sharing functionality? A data-intensive multiplayer game? It not only fits WebRTC like a glove, it fits almost every use case.

Let’s do some quick math. Say we’ve got 1,000 users, and each user is video chatting with 1 user. In other words, 500 users are each having a one-to-one video conversation with one of the other 500 users. Let’s also say they were talking for 10 hours over the course of a month.

The traditional telecom model turns out to be pretty simple. Let’s assume this service charges a rate of $0.005 per user per minute. This scenario would cost the app’s owner 1,000 users x $0.005 x 600 minutes = $3,000 per month. Pretty straightforward.

Now for bandwidth-based pricing. Let’s use a worst-case scenario of 25% TURN connections. And let’s assume this service is relaying video streams of high quality at 1,152 kb/s per stream. This would come out to 1,000 users x 0.75 = 750 STUN users whose streams never reach the platform’s billing system. And 1,000 users x 0.25 = 250 TURN users that do. These 250 TURN users are streaming to themselves symmetrically, so that comes out to 250 users x 2 streams per user = 500 streams. In GB consumed, this would amount to 0.000144 GB/s per stream x 500 streams x 36,000 seconds = 2,592 GB. This particular service’s Pro plan says that you get 500 GB for $199 per month, with a charge of $0.09 per additional GB. This leaves us with 2,592 GB - 500 GB = 2,092 GB of overages, costing us 2,092 GB x $0.09 per GB = $188.28. This leaves us with a grand total of: $199 + $188.28 = $387.28 per month.

With this particular scenario, the difference between per minute and bandwidth pricing is a whopping $2,612.72 per month. That’s valuable SF rent money! Of course, I picked arbitrary numbers for this scenario (and took some math shortcuts), but the underlying concept really can’t be beat. If you choose a plan that charges per minute on a mostly peer-to-peer technology, you’re going to be paying for connections that were designed to be free. But if you choose a plan that charges based on bandwidth usage, you’re going to ensure that your costs hold true to the WebRTC mantra.

Hopefully this helped to shed some light on our pricing system. If you haven’t already, check out our bandwidth calculator. And as always, happy coding!

 

 


Blog

Leave a Reply