Re: Call for Consensus (CfC): WebRTC-NV Use Cases

My opinion is as follows:



  1.  Section 3.2: Low latency P2P broadcast: https://w3c.github.io/webrtc-nv-use-cases/#auction

[BA] I support inclusion of this use case. Since P2P has also been used to extend the scale of conventional streaming, it may also have value in scenarios which may not require "low latency" (e.g. HLS extended with P2P caching).


  1.  Section 3.4: Decentralized Internet: https://w3c.github.io/webrtc-nv-use-cases/#decent

[BA] I support inclusion of this use case.


  1.  Section 3.9: Reduced complexity signaling: https://w3c.github.io/webrtc-nv-use-cases/#urisig

[BA] I support inclusion of this use case.

Of the requirements, I support inclusion of N34, N36 and N39.

It seems to me that requirements N30, N31, N32, N35, N37, N38 may possibly be met without new APIs. For example, N30 and N32 can be accomplished via additional signaling, N31 can be accomplished by downloading the hold music prior to the interruption, N35 seems like it can be accomplished using a mesh topology, N37 seems like it might be satisfied by transporting containerized content over data channel and using EME for content protection (or is the idea to protect the media without containerization?).

N33 seems like it would require support for link local name resolution facilities beyond what is commonly implemented in most operating systems.

The new requirements include:

N30     The user agent must provide the ability to re-establish media after an interruption.
N31     The user agent must provide the ability to play selected media to the remote party during an interuption (c.f. on hold music).
N32     The user agent must provide the ability to 'park' a connection such that it can be retrieved and continued by a newly loaded page to prevent accidental 'browsing away' from dropping a call irretrievably.
N33     A 'long-term connection' must be able to be re-established without access to external services in the event of the local network becoming isolated from the wider network without compromising e2e security.
N34     Ability to intercept the fetch API and service it over a P2P link. One way to do this would be to support data channels in Service Workers which can already intercept fetch.
N35     A group member can encrypt and send copies of the encoded media directly to multiple group members without the intervention of the media server.
N36     Predictable auto-play for media elements that works for first time users and is testable.
N37     Ability to reuse DRM assets streamed over data channels.
N38     Ability to reuse subtitle assets streamed over data channels.
N39     A URI format that defines the remaining transport related fields (e.g. service address/port, ICE credentials, DTLS fingerprint).


We would now like to do a Call for Consensus (CfC) on addition of these new use cases and requirements.  For each of the new use cases and requirements, please indicate:


  *   I support inclusion within the WebRTC-NV Use Cases document.
  *   I object to inclusion within the WebRTC-NV Use Cases document.

If you would like to provide further explanation of your objections, you can file an Issue in the repo: https://github.com/w3c/webrtc-nv-use-cases/issues

The CfC will end on December 13, 2021 at midnight Pacific Time.

Bernard
For the Chairs