The WISH Working Group: Server-Offer vs. Client-Offer Debate

The IETF WISH Working Group, responsible for the WHEP (WebRTC-HTTP Egress Protocol) spec, is currently embroiled in a heated debate over the inclusion of server-initiated (server-offer) SDP exchange alongside client-initiated (client-offer) SDP exchange.

What is the current debate?

Two camps have emerged over the right choice for which side initiates an SDP offer. One side believes that Client-offer only is the best choice, while the other believes that both modes should be supported. 

What’s the difference between the two Modes?

• Client-Offer Mode: The client initiates the session by sending a fully formed SDP offer to the server via an HTTP POST request. The server then responds with an SDP answer. This simplifies the client’s role but requires the client to know the available media streams in advance and being responsible for generation of the SDP offer content itself whether or not the client has libraries to support it (think hardware / embedded systems). 
• Server-Offer Mode: The client sends an empty SDP offer to the server. The server then responds with a fully formed SDP offer. Once the client processes the server offer, the client sends its answer SDP as a PATCH request. This approach gives the server more control over the session setup and accommodates more dynamic use cases, such as complex multi-stream scenarios. It can however place more work and dependency requirements on the client, since it must process the server SDP offer.

The spec initially supported both modes but was later reduced to only client-offer mode. Recently, many WebRTC developers—including prominent voices like Dan Jenkins, Lorenzo Miniero, and Jonas Birme—have pushed for the reintroduction of server-offer mode. Their argument: supporting both modes would make WHEP more flexible and future-proof, accommodating diverse server architectures and advanced use cases.

The Debate Heats Up

Sergio Garcia Murillo, the primary author of the WHEP spec and a Dolby Millicast employee, has been a vocal opponent of server-offer mode. He argues that:

• It increases client implementation complexity.
• It raises interoperability testing burdens.
• It risks fragmenting the ecosystem if clients implement only one method.

Critics, however, feel that these concerns are overstated. Dan Jenkins pointed out that compromise is essential for consensus and that removing server-offer mode without thorough discussion led to unnecessary limitations. Lorenzo Miniero emphasized that client-offer mode complicates server-side development, as seen in Janus’ implementation efforts.

For details on the debate, check out the latest comments in this pull request from the Github repository as well as the video recording of the last IETF meeting. Note that the above pull request was made in response to the meeting. 

Slack Discussion Highlights

The discussion spilled onto Slack’s video-dev channel:

• Dan Jenkins: Advocated for compromise and collaboration, highlighting that server-offer mode simplifies media server adoption.
• Lorenzo Miniero: Argued that adding server-offer mode is crucial for broader adoption, reducing server complexity.
• Sergio Garcia Murillo: Defends his position, claiming that server-offer mode does not solve real-world problems and increases risks.
• Jonas Birme: Author of the pull request stepped away from active contribution, citing frustration with the lack of progress.

Sergio’s position has frustrated many developers, who accuse him of obstructionism. Lorenzo Miniero noted that the refusal to include server-offer mode has dampened enthusiasm for WHEP and may hinder adoption.

Red5’s Perspective

First of all, we want to start by saying how grateful we are for all the work that Sergio has put into WHEP and the effort into producing a standards spec with the IETF. His heart is clearly in the right place. He cares deeply about the technology and the success of WHEP. So while we disagree on his current position on this particular matter, we will still support and promote the WHEP spec whatever the final outcome.   

We at Red5 feel strongly that the final spec should involve both a client initiated offer as well as server initiated offer. We currently support both modes for WHEP in Red5 Pro and Red5 Cloud. We believe flexibility is vital for developers, and supporting both from the get-go made sense for us. 

Media servers should be able to support both methods to accommodate diverse workflows, and we believe that client side implementations should be able to do the same. While adding both modes might require clients to implement additional logic, we believe this burden is minimal. Furthermore, concerns about fragmentation are overstated—implementing both modes allows for a balanced and robust spec without alienating specific use cases. After all, the whole idea of having a standardized spec is that people implement the standard, not go and write half implementations of it. 

We encourage the WISH Working Group to consider reintroducing server-offer mode, returning to the spec’s original intent of flexibility and interoperability. This approach will ensure WHEP remains a future-proof standard capable of supporting real-world use cases across diverse platforms and implementations. More importantly, doing so will show other developers in the WebRTC community that they are heard and that their voices matter. 

---

For the latest developments on WHEP and WebRTC, stay tuned to our blog.