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

Re: WebRTC NV Use Cases

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sun, 13 May 2018 17:54:05 +0200
To: public-webrtc@w3.org
Message-ID: <848f58ed-c0cd-8567-f7c2-31a077f5bc67@alvestrand.no>
I would warn about presenting a proposed tool as an use case, though.
The use case is (to my mind, at least) the function that doesn't work
well in present day implementation, and the tool is a proposal for how
it will work better.

Without wanting to pick on Roman in particular, but because these
examples of tools seem so well written:


Den 11. mai 2018 03:04, skrev Roman Shpount:
> 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.

This would be a valuable tool in an use case where 0.5-second call setup
time is problematic. I'd suggest that these would be push-to-talk
scenarios, drop-connection-when-silent scenarios or other scenarios I
haven't imagined - those would, to my mind, be the use cases where fast
call start is an useful tool.

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

Similarly, this is a tool that is interesting in the use case where
paths switch on a shorter timeframe than lifetime of call, and current
technology (which is often break-before-make in practice even when it
shouldn't be) is unsatisfactory.
We should understand how to characterize our present solution (for
instance ICE continuious renominations) as part of the effort to figure
out what new things we want.


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

And here I'm unable to give a coherent formulation of an use case, so
I'd like to hand the token back to Roman to explain what the use case is.


> 
> Regards,
> _____________
> Roman Shpount
Received on Sunday, 13 May 2018 15:54:38 UTC

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