Slides for the "WebRTC broadcasting: standardization, challenges and opportunities" presentation I made at TADSummit 2023 in Paris. It presents the problems traditional broadcasting has with new scenarios that would benefit from a much lower latency solution, and how WebRTC can help. It also introduces the standard WHIP and WHEP protocols for ingestion and egress, with a few details on how a WebRTC stream could be scaled to a very wide audience using something like SOLEIL (Streaming Of Large scale Events over Internet cLouds).
2. Who am I?
Lorenzo Miniero
• Ph.D @ UniNA
• Chairman @ Meetecho
• Main author of Janus
Contacts and info
• lorenzo@meetecho.com
• https://fosstodon.org/@lminiero
• https://www.slideshare.net/LorenzoMiniero
• https://lminiero.bandcamp.com
3. Just a few words on Meetecho
• Co-founded in 2009 as an academic spin-off
• University research efforts brought to the market
• Completely independent from the University
• Focus on real-time multimedia applications
• Strong perspective on standardization and open source
• Several activities
• Consulting services
• Commercial support and Janus licenses
• Streaming of live events (IETF, RIPE, etc.)
• Proudly brewed in sunny Napoli(*), Italy
10. Why not WebRTC instead?
• Traditional broadcasting efficient but higher latency
• At best (live), delay will typically be in the range of a few seconds
• Besides, different users may experience different delays (buffering)
• WebRTC natively conceived for very low latency, instead
• Born for conversational audio/video/data
• Can be (and often is) easily used for monodirectional streaming as well
• Strangely not really considered by the industry up until recently, though
• Good audio quality (Opus, RED/FEC, stereo/multiopus, etc.)
• Good video quality (multiple codecs, simulcast/SVC, etc.)
• Tooling an important aspect to foster WebRTC adoption, here
• e.g., a standard way to send media, and tools à la OBS, XSplit, or others
11. Why not WebRTC instead?
• Traditional broadcasting efficient but higher latency
• At best (live), delay will typically be in the range of a few seconds
• Besides, different users may experience different delays (buffering)
• WebRTC natively conceived for very low latency, instead
• Born for conversational audio/video/data
• Can be (and often is) easily used for monodirectional streaming as well
• Strangely not really considered by the industry up until recently, though
• Good audio quality (Opus, RED/FEC, stereo/multiopus, etc.)
• Good video quality (multiple codecs, simulcast/SVC, etc.)
• Tooling an important aspect to foster WebRTC adoption, here
• e.g., a standard way to send media, and tools à la OBS, XSplit, or others
12. Why not WebRTC instead?
• Traditional broadcasting efficient but higher latency
• At best (live), delay will typically be in the range of a few seconds
• Besides, different users may experience different delays (buffering)
• WebRTC natively conceived for very low latency, instead
• Born for conversational audio/video/data
• Can be (and often is) easily used for monodirectional streaming as well
• Strangely not really considered by the industry up until recently, though
• Good audio quality (Opus, RED/FEC, stereo/multiopus, etc.)
• Good video quality (multiple codecs, simulcast/SVC, etc.)
• Tooling an important aspect to foster WebRTC adoption, here
• e.g., a standard way to send media, and tools à la OBS, XSplit, or others
13. Why not WebRTC instead?
• Traditional broadcasting efficient but higher latency
• At best (live), delay will typically be in the range of a few seconds
• Besides, different users may experience different delays (buffering)
• WebRTC natively conceived for very low latency, instead
• Born for conversational audio/video/data
• Can be (and often is) easily used for monodirectional streaming as well
• Strangely not really considered by the industry up until recently, though
• Good audio quality (Opus, RED/FEC, stereo/multiopus, etc.)
• Good video quality (multiple codecs, simulcast/SVC, etc.)
• Tooling an important aspect to foster WebRTC adoption, here
• e.g., a standard way to send media, and tools à la OBS, XSplit, or others
20. WebRTC-HTTP ingestion protocol (WHIP)
• HTTP-based signalling to create sendonly PeerConnections
• HTTP POST to send SDP offer, and get an SDP answer in the response
• Teardown of sessions using HTTP DELETE
• Authentication and authorization via Bearer tokens
• https://www.rfc-editor.org/rfc/rfc6750.html
• Trickle and ICE restart via HTTP PATCH and SDP fragments
• https://www.rfc-editor.org/rfc/rfc8840.html
• Everything else is your usual WebRTC!
• ICE, DTLS, etc.
21. WebRTC-HTTP ingestion protocol (WHIP)
• HTTP-based signalling to create sendonly PeerConnections
• HTTP POST to send SDP offer, and get an SDP answer in the response
• Teardown of sessions using HTTP DELETE
• Authentication and authorization via Bearer tokens
• https://www.rfc-editor.org/rfc/rfc6750.html
• Trickle and ICE restart via HTTP PATCH and SDP fragments
• https://www.rfc-editor.org/rfc/rfc8840.html
• Everything else is your usual WebRTC!
• ICE, DTLS, etc.
22. WebRTC-HTTP ingestion protocol (WHIP)
• HTTP-based signalling to create sendonly PeerConnections
• HTTP POST to send SDP offer, and get an SDP answer in the response
• Teardown of sessions using HTTP DELETE
• Authentication and authorization via Bearer tokens
• https://www.rfc-editor.org/rfc/rfc6750.html
• Trickle and ICE restart via HTTP PATCH and SDP fragments
• https://www.rfc-editor.org/rfc/rfc8840.html
• Everything else is your usual WebRTC!
• ICE, DTLS, etc.
23. WebRTC-HTTP ingestion protocol (WHIP)
• HTTP-based signalling to create sendonly PeerConnections
• HTTP POST to send SDP offer, and get an SDP answer in the response
• Teardown of sessions using HTTP DELETE
• Authentication and authorization via Bearer tokens
• https://www.rfc-editor.org/rfc/rfc6750.html
• Trickle and ICE restart via HTTP PATCH and SDP fragments
• https://www.rfc-editor.org/rfc/rfc8840.html
• Everything else is your usual WebRTC!
• ICE, DTLS, etc.
25. Enter the Janus WebRTC Server
Janus
General purpose, open source WebRTC server
• https://github.com/meetecho/janus-gateway
• Demos and documentation: https://janus.conf.meetecho.com
• Community: https://janus.discourse.group/
26. Prototyping WHIP with Janus
https://github.com/meetecho/simple-whip-server
https://github.com/meetecho/simple-whip-client
27. OBS + WebRTC = r (thanks Sean DuBois!)
https://webrtchacks.com/webrtc-cracks-the-whip-on-obs/
28. OBS + WebRTC = r (thanks Sean DuBois!)
https://webrtchacks.com/webrtc-cracks-the-whip-on-obs/
29. Next step: broadcasting the stream
• WHIP server allows ingestion, and it’s a good starting point
• We have a WebRTC stream in an SFU, now (e.g., Janus)
• This now needs to be distributed somehow, though
• Not a big problem per se
• It’s a “regular” 1-to-many distribution
• Most servers and services provide ways to do that
• What’s the standard way to consume this stream now, though?
• SFUs will obviously provide their own custom APIs...
• ... but a standard approach would be much better!
Enter WHEP!
https://www.ietf.org/archive/id/draft-murillo-whep-02.html
30. Next step: broadcasting the stream
• WHIP server allows ingestion, and it’s a good starting point
• We have a WebRTC stream in an SFU, now (e.g., Janus)
• This now needs to be distributed somehow, though
• Not a big problem per se
• It’s a “regular” 1-to-many distribution
• Most servers and services provide ways to do that
• What’s the standard way to consume this stream now, though?
• SFUs will obviously provide their own custom APIs...
• ... but a standard approach would be much better!
Enter WHEP!
https://www.ietf.org/archive/id/draft-murillo-whep-02.html
31. Next step: broadcasting the stream
• WHIP server allows ingestion, and it’s a good starting point
• We have a WebRTC stream in an SFU, now (e.g., Janus)
• This now needs to be distributed somehow, though
• Not a big problem per se
• It’s a “regular” 1-to-many distribution
• Most servers and services provide ways to do that
• What’s the standard way to consume this stream now, though?
• SFUs will obviously provide their own custom APIs...
• ... but a standard approach would be much better!
Enter WHEP!
https://www.ietf.org/archive/id/draft-murillo-whep-02.html
32. Next step: broadcasting the stream
• WHIP server allows ingestion, and it’s a good starting point
• We have a WebRTC stream in an SFU, now (e.g., Janus)
• This now needs to be distributed somehow, though
• Not a big problem per se
• It’s a “regular” 1-to-many distribution
• Most servers and services provide ways to do that
• What’s the standard way to consume this stream now, though?
• SFUs will obviously provide their own custom APIs...
• ... but a standard approach would be much better!
Enter WHEP!
https://www.ietf.org/archive/id/draft-murillo-whep-02.html
34. WebRTC-HTTP egress protocol (WHEP)
• Twin protocol of WHIP
• WHIP takes care of ingestion (sendonly for users)
• WHEP takes care of consuming (recvonly for users)
• Pretty much the same approach too
• HTTP-based protocol (offer/answer)
• Bearer token authentication
• HTTP PATCH and SDP fragments for trickle/restarts
• WebRTC PeerConnection as a result
• Both WHIP and WHEP expecting an offer means they can’t be chained, though...
• https://www.meetecho.com/blog/whep-qui/
• </rant>
35. WebRTC-HTTP egress protocol (WHEP)
• Twin protocol of WHIP
• WHIP takes care of ingestion (sendonly for users)
• WHEP takes care of consuming (recvonly for users)
• Pretty much the same approach too
• HTTP-based protocol (offer/answer)
• Bearer token authentication
• HTTP PATCH and SDP fragments for trickle/restarts
• WebRTC PeerConnection as a result
• Both WHIP and WHEP expecting an offer means they can’t be chained, though...
• https://www.meetecho.com/blog/whep-qui/
• </rant>
36. WebRTC-HTTP egress protocol (WHEP)
• Twin protocol of WHIP
• WHIP takes care of ingestion (sendonly for users)
• WHEP takes care of consuming (recvonly for users)
• Pretty much the same approach too
• HTTP-based protocol (offer/answer)
• Bearer token authentication
• HTTP PATCH and SDP fragments for trickle/restarts
• WebRTC PeerConnection as a result
• Both WHIP and WHEP expecting an offer means they can’t be chained, though...
• https://www.meetecho.com/blog/whep-qui/
• </rant>
41. Using SOLEIL for the purpose
• “Streaming Of Large scale Events over Internet cLouds” (Ph.D Thesis)
• In a nutshell, tree-based distribution of WebRTC feeds
• Ingest and edges are WebRTC (Janus), everything in the middle just RTP
• Working with RTP in intermediate layers has many advantages
• No WebRTC overhead, and easier to route/manipulate by non-WebRTC tools
• You can even take advantage of multicast and/or SDNs, here
• Just needs RTP forwarding to kickstart everything
• Simple WHIP Server does support it (VideoRoom −→ RTP)
• ... and Simple WHEP Server uses Streaming plugin, which consumes RTP!
42. Using SOLEIL for the purpose
• “Streaming Of Large scale Events over Internet cLouds” (Ph.D Thesis)
• In a nutshell, tree-based distribution of WebRTC feeds
• Ingest and edges are WebRTC (Janus), everything in the middle just RTP
• Working with RTP in intermediate layers has many advantages
• No WebRTC overhead, and easier to route/manipulate by non-WebRTC tools
• You can even take advantage of multicast and/or SDNs, here
• Just needs RTP forwarding to kickstart everything
• Simple WHIP Server does support it (VideoRoom −→ RTP)
• ... and Simple WHEP Server uses Streaming plugin, which consumes RTP!
43. Using SOLEIL for the purpose
• “Streaming Of Large scale Events over Internet cLouds” (Ph.D Thesis)
• In a nutshell, tree-based distribution of WebRTC feeds
• Ingest and edges are WebRTC (Janus), everything in the middle just RTP
• Working with RTP in intermediate layers has many advantages
• No WebRTC overhead, and easier to route/manipulate by non-WebRTC tools
• You can even take advantage of multicast and/or SDNs, here
• Just needs RTP forwarding to kickstart everything
• Simple WHIP Server does support it (VideoRoom −→ RTP)
• ... and Simple WHEP Server uses Streaming plugin, which consumes RTP!