Session Date/Time: 05 Nov 2024 15:00

wish

Summary

This meeting focused on progressing the WebRTC HTTP Ingestion Protocol (WEP) draft towards RFC publication. The main discussion points revolved around addressing open issues, particularly regarding server-sent offers, event stream handling, and extension mechanisms. Several actions were identified to move the document forward.

Key Discussion Points

Server-Sent Offers (Issue #12): A significant discussion centered on whether WEP should support server-sent offers in addition to client-sent offers. Concerns were raised about the RESTfulness of server-sent offers, potential interoperability issues, and the lack of concrete proposals for implementation. The main use case brought up was interoperability with whip.
Event Stream Handling (Issue #19): Julius proposed an alternative event stream architecture where the event stream is initiated before the WEP session, allowing for pre-session communication of information like simulcast envelopes. Sergio expressed concerns about delaying RFC publication due to substantial redesign. An alternative of using a data channel for events was brought up to avoid HTTP overhead.
Extension Mechanism: Discussed the possibility of splitting the draft into a core WEP specification and an experimental extension specification for features like server-sent events and simulcast negotiation. An AD advised caution about experimental status. Agreement that a generic extension mechanism is important.
Data Channels for Events: Discussed using data channels instead of HTTP for server-sent events, potentially alleviating HTTP-related overhead. Tim proposed modifying the current spec to be future-compatible with this by allowing the "m=application" line in the SDP offer, but instead of doing a 400 error, the client would just not include that M-line.
URL Discoverability (Issue #7): Discussed how to differentiate WEP URLs from other HTTP-based protocols, given that WEP uses HTTP URLs. The suggestion to use a ".wep" file extension was deemed impractical.
Server Behavior for Misbehaving Clients (Issue #20): Discussed whether the specification should define server behavior when a client requests an event that the server has not announced. It was determined that a one-sentence statement clarifying that the server is free to ignore or reject such requests would be beneficial.

Decisions and Action Items

Server-Sent Offers: The chairs requested a concrete proposal (PR) for server-sent offers. If no proposal is submitted within a reasonable timeframe, the issue will be closed. (Action: Open Issue #12 comment).
Data Channels and Events: Tim will create a PR for supporting the M line today with data channel support to the spec and splitting the RFC into core WEP and the data channel extension RFC.
Misbehaving Clients: A sentence clarifying server behavior when dealing with non-compliant clients will be added to the specification. (Action: Sergio to add the sentence).

Next Steps

Tim to submit PR for data channel.
Sergio to add one sentence regarding non compliant clients.
Continue discussion on the mailing list to resolve open issues.
Sergio will backport all changes from HTTP review.