Petition to change pricing for "Participant Connections"

[vincentwoo]

Apologies, for this is not a code issue. However, I believe this is something the community should give feedback on.

Currently, Twilio bills customers $0.001/min (or 6 cents per hour) for each participant subscribed to a Twilio Room. This is problematic because many applications have use cases that require people "waiting" in a lobby for a call to start. Right now, the only way to be notified that there are other participants who want to start a call is to subscribe to the Twilio room.

There are many common edge cases that can make this very expensive very quickly. For instance, if a user leaves a tab open in a room with no one else present, this will cost me $1.50 per day. If a thousand users all spend an hour on my product and do not even use Twilio Video, this will cost me $60.

This is a strong financial incentive to move the single bit of information of whether a user is "interested in doing a call" into a secondary communication layer like Firebase or our own primary web service. I would in fact prefer to pay Twilio for this functionality, but along more equitable lines. I think the participant connection service should be either:

• charged by bandwidth transferred over Twilio's websocket connection
• peak number of concurrent users per time period

I am more than happy to pay for value derived from using Twilio, by GB of media transferred, but the separate charge for simply knowing if users want to start a call seems like a tax on customers.

[jamesgraham]

I agree it is expensive. We have a similar use case and use Pusher to handle awareness. Once >1 participant(s) wish to connect, create the room over API and return the tokens on-demand.

[carterbryden]

I agree, if developers need to build additional components to ensure that they don't get hosed with wasteful participant minutes, the business premise of having Twilio just handle things for us dwindles.

It seems like this would be easily solved by only charging participant minutes once at least 2 participants are connected (edit: for P2P). If the cost per participant minute has to go up slightly to accommodate that, but it doesn't waste minutes, that seems fair.

For p2p in particular, it's not like the system needs to stream video/audio unless there's more than one participant connected, and Twilio isn't actually doing a whole heck of a lot (edit: websocket signalling, which does have a small operational cost), which should make operational costs very very low - and the margins would remain high.

[rfbrazier]

Hey all, Rob Brazier, PM for Video here.

Thanks for the feedback on pricing--you've raised some good points, and we'll take this into consideration.

Have you considered displaying a notification of some kind after a period of inactivity to check to see if the user is still present, and disconnecting the user from the Room if they don't respond in a set period of time? This is a common pattern for a variety of streaming services (Pandora, etc.) and it works well.

Related half-baked idea: What would you think about an approach where Twilio implements a timeout check for single-Participant Rooms? We could raise an event before kicking what we presume to be an "idle" Participant. Your application would have some period of time to confirm that the user is still present. If unconfirmed, we would disconnect the Participant. We could even make this an optional feature (maybe something in the connect options) that saves you the trouble of having to implement "abandoned tab" handling.

Let me know what you think about the above. In the interest if transparency, a bit of background on why we charge per Participant minute, in case you're interested:

• As you've indicated above, keeping a websocket connection open to for Room signaling does incur cost on our part--we've got to keep a socket open on a machine, and machines have limited capacity.
• We want to support the broadest range of use cases possible. With Group Rooms, we already see a good amount of 1:0 use cases on the platform (a single Participant recording a video, for example). In cases like these, there will be no egress Media Routed fee, since there's only one Participant, but the Participant is still consuming media server resources in Twilio's cloud, in addition to the websocket mentioned above. Billing for duration in single-Participant Rooms allows us to cover these costs and support 1:0 use cases at a fair price.
• A similar situation applies in audio-only Group Rooms--the egress Media Routed revenue from an audio-only Group Room is low, and doesn't cover the full cost of the media server instance required to route the audio. Charging for Participant duration allows us to support these use cases at a fair price.
• We wanted to pricing across Group and Peer-to-Peer Rooms as symmetrical as possible so that the two topologies are easy to compare and developers can quickly grok the pricing, so we decided to use the same approach to metering in the two products.

These reasons aside, your feedback regarding single-Participant Peer-to-Peer Rooms is helpful, and we'll give some thought to ways to address this problem.

Thanks as always for using Programmable Video, and keep the feedback coming.

[vincentwoo]

The heartbeat/inactivity solution you propose is already what I (and others) have implemented - a second system built around Twilio to protect us from relying on it for presence updates. My point is that this should be unnecessary.

My concerns are not only with single-participant rooms. They are with multi-participant rooms where no media resources are being either published nor subscribed. I understand that you have sort of vague technical reasons where you'd like to capture value from this, but I don't think that's a good idea. If you need to bill a single user in a room, publishing their stream to no one, that's fine with me, but please charge for that and not idling in a room doing nothing.

[carterbryden]

Thanks for the detailed reply Rob, I understand your points and where you're coming from. I think the main concern for my team is that if we need to build that presence system ourselves in order to avoid potentially wasteful costs, we might as well just use that presence system for signalling as well and avoid Twilio signalling all together.

It seems to me that the main cost issues for Twilio here are:

-1:0 rooms where the user is recording (or just sending to nowhere?), because they aren't billed for egress. It seems like it would make more sense to increase the price in those particular cases rather than across the board. That could mean raising recording prices, having a unique 1:0 price, etc.

-sockets for signalling. I'm not sure what you're running to handle those, but websocket server connections are very, very cheap these days.

To give an idea of how much it costs (rough approximations) for websocket servers:

-Here's an example of someone handling 600k concurrent connections two years ago with socket.io (not the most performant) on one server: link.

-Here's an example of the phoenix framework on elixir serving over 2 million concurrent connections: link

These both were benchmarked on the equivalent of an AWS m4.xlarge, which is $0.2/hour on demand, or $0.116/hour if on reserve paid up front (1 year). That's $144/month on demand and $83.52 on reserve. You can get better deals with longer term contracts - which I'm assuming Twilio gets an even better deal on because they have contracts with AWS to provide services for them already.

So if you were maxing out connections all day long - and lets use the lower end 600k concurrent connections per server to be conservative - you would have 864 million participant minutes, bringing in a total of $864,000, or 25.9 million dollars a month. That's a 180,000% margin on participant minutes for signalling websocket connections. If you were using phoenix websockets it would be around 540,000% profit margins.

Note: This is all rough napkin math I haven't double checked at all, please correct me on any and all of this if it's wrong.

That seems like it's maybe an unnecessarily wide margin to have on participant minutes for signalling. I understand there are almost certainly inefficiencies and other things to consider in this equation, but that's a lot of room in the margins to handle those.

I'm not trying to say that Twilio shouldn't make money for providing a valuable service, but the pricing model specifically for participant minutes does seem a bit off.

[jamesgraham]

One fairer model might be to charge by published/subscribed minutes.

That way, as soon as someone binds to a track you charge, but they can be present in the room from the moment they join.

This more closely represents your actual costs of providing the service ie. bandwidth. For P2P scenarios I don't really see where the costs are since sockets are cheap and TURN traffic is billed separately.

[rfbrazier]

These are really helpful suggestions. We'll consider ways to improve pricing for this scenario in the future and provide more feedback when we decide what, if any, changes to make.

Thanks again all.

---

Rob Brazier Product Management, Twilio m: (330) 419-0950

On Sun, Jun 18, 2017 at 9:51 AM, James Graham notifications@github.com wrote:

One fairer model might be to charge by published/subscribed minutes.

That way, as soon as someone binds to a track you charge, but they can be present in the room from the moment they join.

This more closely represents your actual costs of providing the service ie. bandwidth. For P2P scenarios I don't really see where the costs are since sockets are cheap and TURN traffic is billed separately.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_twilio_twilio-2Dvideo.js_issues_121-23issuecomment-2D309289160&d=DwMFaQ&c=x_Y1Lz9GyeGp2OvBCa_eow&r=g4LA7GVMZvyLENPBWHHJ2ET2KVbQd9nR8P1BJI3ADJo&m=ADggmHfOcn66uDqNU5K3DwA1N71VgnN48SJ3U9Gw6hM&s=6PrXGB5X2L5UtJMP-dqUAJndNkFrMjVQnOli9tlnpxo&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAHJjybpdPF6MSWHq4g0HjVIXBYZkUWnks5sFVWZgaJpZM4N2jFt&d=DwMFaQ&c=x_Y1Lz9GyeGp2OvBCa_eow&r=g4LA7GVMZvyLENPBWHHJ2ET2KVbQd9nR8P1BJI3ADJo&m=ADggmHfOcn66uDqNU5K3DwA1N71VgnN48SJ3U9Gw6hM&s=wAoc4Sch7ZjoAAr0ZOVkhH0O8p5a4XMwDd0SKYWuKYI&e= .

[vincentwoo]

@rfbrazier It's been about a month. Can you please comment as to whether you are still considering changes, and if so, on what timeline you will have something to announce? With no information it is very likely I will switch to something like Tokbox instead.

[rfbrazier]

@vincentwoo, I reached out to you via email with some questions on how you'd like to see this work. Please take a look and let me know your thoughts.

We don’t have a date set for any modifications to the pricing model. If we do decide to make any changes it will not be until September in alignment with other product announcements.

[vincentwoo]

@rfbrazier i did not receive a mail, but you can resend it to vincent@coderpad.io

[Staszy]

@rfbrazier are you still considering this?

[rfbrazier]

@Staszy, we don't have any pricing changes planned at this time, but improvements here aren't off the table.

Please drop me a note at rbrazier [at] twilio dot com if the current pricing is a barrier to you using Twilio Video–there's likely something we can do to make this a bit easier for you.