[webrtc-nv-use-cases] What is a "node" in the Low latency Broadcast with Fanout use case? (#85)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-nv-use-cases:

== What is a "node" in the Low latency Broadcast with Fanout use case? ==
The N39 requirement in the [ยง 3.2.2 Low latency Broadcast with Fanout](https://w3c.github.io/webrtc-nv-use-cases/#auction) use case reads:
- _"A node must be able to forward media received from another node to a third node. Applications require access to encoded chunk metadata as well as information from the RTP header to provide for timing, media configuration and congestion control. This includes a mechanism for a relaying peer to obtain a bandwidth estimate."_

I've received a question I couldn't answer about what a "node" is in this case, so this may require clarification.
1. If "node" is a user agent already in a position to perform playback ("relaying peer"), then this is not a new requirement
2. If "node" includes some sort of in-network intermediary, and the goal is to ensure forwarding by entities other than those involved in the session, we're potentially into sframe territory and that hasn't worked out well thus far. This also sounds more IETF than W3C.

More clarity seems needed.

I'd also like to understand whether optimizing [existing relay functionality](https://webrtc.github.io/samples/src/content/peerconnection/multiple-relay/) to skip unnecessary decode and re-encode would satisfy this requirement, challenging whether exposing more surface to "Applications" is a necessary requirement.

Please view or discuss this issue at https://github.com/w3c/webrtc-nv-use-cases/issues/85 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 January 2023 16:29:25 UTC