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

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

From: Roman Shpount <roman@telurix.com>
Date: Wed, 24 Jan 2018 15:39:20 -0500
Message-ID: <CAD5OKxsAwtxNXF446gUC9+qS+FjWz8+wzpsyuySEDZeaffn7Lw@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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.

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.

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.

Roman Shpount
Received on Wednesday, 24 January 2018 20:39:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 24 January 2018 20:39:45 UTC