Re: WebRTC NV Use Cases

On Thu, May 10, 2018 at 6:09 PM Roman Shpount <roman@telurix.com> 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.
>
>
Isn't this already possible with the existing WebRTC API?  In fact, I'm
aware of a product that does something that sounds exactly like this using
the existing WebRTC API.


> 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.
>

You're talking about two different things:

- graceful switching
- multipath

One is harder than the other.  Which one do you want more?  Or do you just
want both?


>
> 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
>