The document discusses the potential of WebRTC for broadcasting, highlighting its low latency and high quality compared to traditional broadcasting methods. It introduces new protocols like WHIP for ingestion and WHEP for consumption, which streamline the integration of WebRTC into broadcasting systems. Additionally, it addresses challenges related to distribution and scaling, proposing RTP-based solutions for improving performance in large-scale environments.

1. WebRTC broadcasting: standardization,
challenges and opportunities
Lorenzo Miniero
@lminiero@fosstodon.org
TADSummit 2023
20th October 2023, Paris

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

4. Hello from sunny Naples, Italy!

5. How “traditional” broadcasting typically works

6. What if we want more interactivity, though?

7. What if we want more interactivity, though?

8. What if we want more interactivity, though?

9. What if we want more interactivity, though?

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

14. Two main challenges: ingestion...

15. Two main challenges: ... and distribution

16. (and yeah, maybe scaling too! )

17. A new Working Group in the IETF
https://datatracker.ietf.org/wg/wish/about/

18. Making WebRTC ingestion easy: WHIP!
https://www.meetecho.com/blog/whip-janus/ (September 2020)

19. Making WebRTC ingestion easy: WHIP!
https://www.meetecho.com/blog/whip-janus-part-ii/

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.

24. WebRTC-HTTP ingestion protocol (WHIP)

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

33. WHIP, WHEP & WHAP!
https://www.meetecho.com/blog/whip-whep/

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>

37. WebRTC-HTTP egress protocol (WHEP)

38. Prototyping WHEP (too) with Janus
https://github.com/meetecho/simple-whep-server
https://github.com/meetecho/simple-whep-client

39. Ingestion 2
, distribution 2
, what about scaling?

40. Ph.D Thesis on WebRTC broadcasting (2015)

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!

44. Distributing WHIP Janus streams via SOLEIL

45. Distributing WHIP Janus streams via SOLEIL

46. Distributing WHIP Janus streams via SOLEIL

47. Distributing WHIP Janus streams via SOLEIL

48. Distributing WHIP Janus streams via SOLEIL

49. Leveraging multicast internally for RTP

50. Leveraging multicast internally for RTP

51. Thanks! Questions? Comments?
Contacts
• https://fosstodon.org/@lminiero
• https://twitter.com/elminiero
• https://twitter.com/meetecho
• https://www.meetecho.com/blog/

52. JanusCon is back, see you soon in Napoli!
April 29-30, 2024, Napoli — https://januscon.it

53. JanusCon is back, see you soon in Napoli!
April 29-30, 2024, Napoli — https://januscon.it