The broadcasting industry has for years been dominated by a specific set of technologies (RTMP, HLS, etc.) that, while effective, suffer from high latencies and so are not always a good option. The IETF has started to look into WebRTC for that, starting from ingestion using the WHIP protocol. This presentation will introduce WHIP, some existing implementations, and how this could be expanded to distribute streams to a wide audience via WebRTC as well. The broadcasting industry has for years been dominated by a well known and specific set of technologies (RTMP, HLS, etc.). These solutions do work and are widely deployed, taking advantage of CDNs for distributing streams to a potentially very large audience in an effective way. That said, they do suffer from some limitations, the stronger one being a high latency that cannot really be reduced, if not slightly. Considering there are scenarios where a very low latency may be desired, WebRTC has started to gain some traction, due to its real-time nature that, although originally conceived for conversational scenarios, has actually often used for streaming purposes as well. When it comes to broadcasting, there are two main aspects to take into account: ingestion (providing a stream to broadcast) and distribution (feeding the stream to an audience). The IETF has started addressing ingestion in the WISH Working Group, with a draft describing the WHIP protocol. This presentation will introduce what WHIP is, its requirements, and how it's supposed to work, plus some details on existing implementations. It will then move to some considerations on how distribution could be handled via WebRTC as well, possibly at scale, using the open source Janus WebRTC Server as a reference implementation.