**Session Date/Time:** 10 Jan 2025 15:00

# [WISH](../wg/wish.html)

## Summary

The WISH Working Group held its first virtual interim meeting to discuss the ongoing debate regarding client-side versus server-side offer/answer mechanisms within the WebRTC-HTTP ingestion Protocol (WHIP) specification. No clear consensus was reached on a single mandatory approach. Key drivers for both client-side and server-side offers were discussed, including interoperability, codec constraints, SFU integration, and ease of adoption for various implementers. A potential compromise involving an initial client-side offer that a server could reject by sending a server-side offer was proposed. The discussion also highlighted the importance of out-of-band signaling (e.g., via URL or manifest) for pre-negotiation information.

## Key Discussion Points

*   **Welcome and Introductions**: The chairs, Sean Turner and Neils ten Oever, welcomed participants to the first virtual interim meeting for the WISH WG. Standard IETF Note Well and IPR policies were reviewed.
*   **Purpose of Meeting**: To decide on the offer/answer mechanism for WHIP and discuss any other outstanding issues to finalize the specification.
*   **Proposed Offer/Answer Options (Neils ten Oever)**:
    1.  Client-side offer only (current draft).
    2.  Client-side offer only, with server indicating support for server-side offers later.
    3.  Server-side offer only (early draft, no current advocates).
    4.  Both client and server can offer, both mandatory to support.
    5.  Both client and server can offer, one side is optional, and they negotiate who offers.
*   **Discussion on Drivers for Server-Side Offers**:
    *   **Codec Preferences**: Tim Panton suggested that a URL parameter could indicate the expected codec, allowing the client to set codec preferences before generating an offer. This would address the server's desire to constrain codecs.
    *   **Legacy SFUs**: Tim Panton expressed disinterest in supporting "legacy SFUs" that might prefer server-side offers, citing past negative experiences with WebRTC legacy support.
    *   **SFU Support and Multiple Streams**: Sergio Garcia Murillo and Lorenzo Miniero highlighted the need to support existing SFU architectures and use cases involving multiple audio/video tracks, camera angles, or languages. If the client offers first, it may not know the server's capabilities regarding stream counts, making it difficult to construct a suitable offer. Lorenzo emphasized that making server-side offers easier could foster wider adoption of WHIP among server developers.
    *   **Federation (WHIP/WHEP chaining)**: Lorenzo Miniero noted this as a "nice-to-have" side effect for servers to interact, but not a strong motivation for server-side offers.
*   **Flexibility vs. Mandatory Requirements**:
    *   Julius Smith argued strongly against option 4 (both mandatory) due to the risk of "two dialects" where implementers only support one, leading to interoperability issues. He advocated for picking *one* mandatory approach.
    *   Sergio Garcia Murillo stressed that IETF specifications require clear mandatory language (`MUST`), and excessive flexibility would likely lead to rejection by reviewers. He stated that making `both optional` is not aligned with IETF process.
    *   Paul Jensen and Dan Jenkins argued for maximum flexibility, allowing both client and server offers, as different implementers (especially embedded devices like Samsung TVs or Roku) have varying capabilities and existing architectures. They expressed skepticism that devices would implement `MUST` requirements if it meant significant re-architecture.
*   **Client-side vs. Server-side Implementation Burden**:
    *   Lorenzo Miniero stated that for his SFU, implementing client-side offers was significantly harder than server-side, due to existing architectural assumptions, and he wouldn't implement it for his primary SFU if server-side wasn't an option.
    *   Sergio Garcia Murillo countered that while server implementation can be complex, the promise of WHEP for simple embedded clients (e.g., a 200 Euro projector) means client simplicity is paramount, and they may never receive firmware updates. He believes server implementers are generally more capable of adapting.
*   **Out-of-Band Information and URL/Header Format**:
    *   Tim Panton's idea of codec preferences in the URL sparked discussion about a broader "WHIP manifest" or similar mechanism (suggested by Dan Jenkins) to convey server capabilities (codecs, simulcast envelopes, available streams/tracks) out-of-band.
    *   Sean Turner supported this, noting that current SFU/media server products already have known available streams/codecs, and forcing client-side offers might necessitate custom out-of-band communication anyway. This could make initial connection more efficient and avoid multiple round trips.
    *   Sergio Garcia Murillo agreed that SDP is not flexible enough for dynamic, rich semantic information (like camera angles or multiple languages) and would require an event backchannel (e.g., Data Channel) for renegotiations. However, this doesn't preclude defining how to signal initial capabilities.
*   **Potential Compromise (Sergio Garcia Murillo)**:
    *   The only acceptable solution Sergio could envision would be for the client to *first* send a client-side offer. The server could then reject this offer and *instead* send a server-side offer, which the client would then be mandated to accept. This would ensure client-side offer support is mandatory but allow servers to steer the negotiation.

## Decisions and Action Items

*   **Decision**: Option 4 (making both client and server offers mandatory) was largely dismissed as making the overall solution too complex and prone to fragmentation.
*   **Action Item**: Sean Turner and Neils ten Oever (Chairs) will formulate specific questions for the mailing list or a subsequent interim meeting, taking into account the discussion on offer/answer mechanisms and the related topic of URL/header format for conveying server capabilities (e.g., Tim Panton's URL proposal, WHIP manifest concepts).

## Next Steps

*   The WISH WG will continue the discussion, likely in another virtual interim meeting, to aim for a clear decision on the offer/answer mechanism.
*   The discussion on how to convey server capabilities via URL parameters or a "WHIP manifest" will be integrated into the ongoing offer/answer debate, as it appears to be a crucial component for addressing flexibility and efficiency concerns.
*   Watch the mailing list for further announcements regarding the next steps and discussion questions.