7 Reasons for WebRTC Server-Side Media Processing

June 6, 2014

My whitepaper on server-side media processing, sponsored by Dialogic.

Server side media processing for WebRTC

WebRTC is a great technology. It fixes a lot of the ailments of what came before it in media processing for VoIP. That said, it comes as a nice client-side package for browsers but nothing more.

This leaves a lot to be desired for some – there are things that can only be done on the server side; especially things around media processing.

Dialogic were kind enough to give me a freehand to write a whitepaper on this exact topic – what are the things in WebRTC that require server-side media processing. I came up with 7 reasons. The whitepaper is freely available on Dialogic’s website: 7 reasons for WebRTC server-side media processing

Go read it and tell me what you think.


You may also like

WebRTC is a marathon not a sprint

WebRTC is a marathon not a sprint

Your email address will not be published. Required fields are marked

  1. Quite a good intro. If prefer “SFU” for what you call router, but that is just because I have a favorite one.

    And since I can’t read papers or specs without finding an error: page 8 — chrome at least can do 1080p.

  2. Yeh, a good paper that covers most use cases.
    What mediaserver would you recommend for server-side processing?

    1. I’d recommend Dialogic – they sponsored this whitepaper 🙂

      Seriously, it all depends on the technical requirements and the business needs/constraints that you have.

      If you are looking for a free, open source solution; then many vendors I’ve seen are tinkering with Jitsi VideoBridge or exploring Janus. Also take a look at Kurento.

      If what you need is a commercial solution with an SLA attached, then Dialogic is definitely a choice to consider.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}