Re: What would you like to see in WebRTC next? A low-level API?

> On Jan 24, 2018, at 1:39 PM, Roman Shpount <roman@telurix.com> wrote:
> 
> Hi All,
> 
> I would be interested in API which un-bundles transport, encryption, media encoding and decoding, media capture and playback. I would also be interested in something which allows me to negotiate each of those components separately without constraints of offer/answer. I am looking for an API which would allow me to implement the following scenarios:
> 
> 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.

+1 

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

+1 and let me sharpen this a little bit. I think we need multi path with “make before break” meaning we know the new path works before we stop sending on old path so there is no media artifacts and you switch from say LTE to WiFi. 

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

+1 - in fact I think we should rethink SFU based on what we have learned from SDN and ask if a SFU can run on a switch instead of one server.  Distributed SFU at where speed seem very conceivable on modern SDN switches. 

> 
> Regards,
> _____________
> Roman Shpount

Received on Friday, 26 January 2018 18:25:53 UTC