W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2018

Re: WebRTC NV Use Cases

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 14 May 2018 15:19:21 -0700
Message-ID: <CAJrXDUENDEqHxegrQObOGpQNBDyrQC8cFc=xCnTfoOBodBR=XA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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
Received on Monday, 14 May 2018 22:19:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC