Re: WebRTC NV Use Cases

Hi all,

A couple more:

  * End to end media encryption for conferences
  * (from the webrtc survey) Per frame (meta) information to allow
    correlating data with a single frame. This allows data loaded on a
    side channel to match on a single frame. [uses cases are subtitles,
    video overlays, iot metadata...]

Best regards
Sergio

On 11/05/2018 3:04, Roman Shpount wrote:
> Here are a few use cases I suggested before:
>
> 1. Fast Call Start
>
> Client creates a session to a communications server. Client gets 
> notification from the server in this existing session about a new call 
> and immediately gets call preview media (0-RTT since this an existing 
> session). If call is accepted by the user, client starts sending media 
> over this existing session to the server. Client then collects local 
> candidates, establishes a new peer-to-peer connection with the remote 
> party, selects the best path based on local preferences (lowest 
> latency based on STUN round trips, lowest cost with WIFI preferred to 
> mobile), negotiates encryption for this new peer-to-peer session and 
> then moves the existing media session from server to peer-to-peer 
> connection without media re-negotiation. Session between client and 
> the server is maintained to receive new calls for the client.
>
> 2. Redundant data path
>
> Client maintains two data paths to the remote party, one direct p2p 
> and another with lower bandwidth through a different network path like 
> a TURN server. If p2p connection fails or experiences packet loss, 
> media is recovered using packets received over the alternative media 
> path. It should be possible to gracefully switch media paths, i.e 
> start sending the same media over two paths to make sure new path 
> works before disconnecting old path, so that things like switch from 
> LTE to WiFi works without media artifacts.
>
> 3. Distributed SFU
>
> Client maintains multiple sessions with a network of interconnected 
> SFUs and other clients which also act as mini-SFU. Same media is sent 
> to one or more remote SFU and clients. Application uses STUN 
> round-trips or other methods to measure link latency. Client media is 
> dynamically moved between SFU and client connections to create the 
> lowest total latency for the media transmitted through the network. 
> Furthermore, instead of relying on RTCP to do things like require 
> I-Frames or provide statistics for each individual connection, API is 
> used to collect this data and custom protocol is used to distribute 
> this data to other conference peers avoid things like RTCP munging 
> done by current SFU. Functionality required from SFU should be limited 
> to simple packet forwarding so that these SFU can be implemented using 
> SDN switches.
>
> Regards,
> _____________
> Roman Shpount