Chris Kranky

Recent Posts


Scaling WebRTC: The next question

Chris KoehnckeChris Koehncke

facebook-number-of-users-2012I’m elephant hunting at this week’s WebRTC Expo in Santa Clara. Forgetting for a moment the various technology dog fights that we’re embroiled in, I’m wondering how do you scale WebRTC to a commercial deployment. The nature of WebRTC is P2P or a 1:1 connection. That works great for a simple point-to-point video/voice call. You can scale that infinitely. But what happens when I have a more complex WebRTC communications session underway with all sort of media and data flows between multiple peers? This is a bit much for my 2 year old Dell laptop to manage perhaps (or maybe not).

I’m awaiting the next wave of discussion on centralized WebRTC services. Services managed from a secure location, with unlimited Internet and huge CPU horsepower at the ready.

One immediate notion is a WebRTC gateway. We’re seeing this now with WebRTC-to-SIP gateways providing an on-ramp into the telephony world. However these gateways are just that transit bridges between worlds. Clearly there will be competitive opportunities here to provide scale, reliability and manageability. But this type of gateway doesn’t carry with it loads of intelligence, it’s job being merely to transit traffic up/down stream.

As you build your service, do you need a central WebRTC server that can manage complex media and signaling among various peer points? Does this server have to be intelligent; a part of the application? If you answer YES, the complexity increases dramatically as this system has to handle multiple 1-to-many connections AND understand what it’s doing and why. Before too long, you’ll have re-invented the PSTN all over again.

I’m thinking about something simpler, more elegant.

I’m hoovering around the TURN element of WebRTC. To the casual WebRTC’er – TURN has a simple job of brokering media when all else fails. However, I’m starting to wonder whether TURN 2.0 or perhaps a new element, a WebRTC BOT whose sole job being to take instructions from WebRTC peers and set-up and manage connections on their behalf. Think Openflow for WebRTC.

I don’t want this BOT to be terribly intelligent. I’ll tell it what do do remotely. But the BOT should have near ∞ resources, never said no and always say yes to any request.  Managing, transcoding (this never goes away), replicating and reporting – all on an as needed demand basis. Sounds awesome doesn’t it? Companies like PubNub doing next gen push notifications are down this path already.

Clearly this is a scale issue. If you’re building something for 10 users, you didn’t bother to read this far. However, I do see opportunities for 3rd party service offerings offering all of the above , off loading some of the complexities of scale (even for 10 users) to a 3rd party makes total sense if the price is right and the offer compelling.

Comments 4
  • Philipp Hancke
    Posted on

    Philipp Hancke Philipp Hancke

    Author

    With some luck, you’ll see this “BOT” in Paris. It’s a bird actually.


  • Emil Ivov
    Posted on

    Emil Ivov Emil Ivov

    Author

    And it will be open source!


  • Costin
    Posted on

    Costin Costin

    Author

    Looking forward to catching up this week!


  • Tsahi Levent-Levi
    Posted on

    Tsahi Levent-Levi Tsahi Levent-Levi

    Author

    Chris,
    I think WebRTC has an edge when it comes to scaling because of its web origin. You see this with the types of technologies and paradigms WebRTC vendors are taking – most run on third party clouds like AWS, and have built their system in an architecture that at least theoretically is designed to scale overnight – something you don’t see often in VoIP soluitions.
    It will be interesting to see who gets to 100M users first in this space.


This site uses Akismet to reduce spam. Learn how your comment data is processed.