Re: WebRTC NV Use Cases

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