On Wed, Mar 4, 2020 at 3:43 AM Toerless Eckert <tte@xxxxxxxxx> wrote:
On Wed, Mar 04, 2020 at 02:03:40AM -0500, Phillip Hallam-Baker wrote:
> On Tue, Mar 3, 2020 at 11:07 PM Larry Masinter <LMM@xxxxxxx> wrote:
>
> > https://etherpad.ietf.org:9009/p/ManyCouches
> >
> > I thought the whole point of WebRTC was to get rid of need
> > for native clients of need for conferencing vendors (or at least
> > those who could charge per-minute.)
>
> It is relatively easy to get 2 person communications working peer-peer
> 'most of the time'. All you need to work out is the NAT traversal.
> But NAT traversal isn't going to be 100% reliable
WebRTC protocols rely on the BEHAVE standards for NAT traversal
and that already allows for it to be more flexible to get across
NAT than solutions that would e.g.: rely on TCP connections.
BEHAVE works if the NAT implements it. Otherwise, not. A reflector in the cloud is a sure bet.
Maybe we are getting to 100%. But remote meeting technology is still sufficiently twitchy for it to be an issue. VOIP does seem to have crossed that hurdle though.
Its true that you want to have a reflector/mixer to optimize bandwidth
utilization when all your transport is unicast. Alas WebRTC WG was
not interest to add support for IP multicast, or else it could have
offloaded large-group communications first to AMT relays and not bother
whether or when native IP multicast would be adopted. Water under a very
long and annoying bridge of IETF and IP multicast. But each WG is only
representing the interests of the parties creating rough consensus in
it.
I did think of a different way to do multicast stacking multiple IP headers on a single frame and then bursting where the ASNs diverge but it puts a lot of complexity into the network.
> My complaint is that these are not end-to-end secure.
You just need a design where the reflector/mixer (WebRTC server) is
included in the group trust of the other endpoints. Typically the
organizer/initiator of a multi-party call should be able to decide
on a trustworthy WebRTC service. If not, then such an
organizer/initiator should set up its own WebRTC server.
No, you do not get to call your system end-to-end secure by defining the cloud as an endpoint.
IMHO this is not a workaround, but an intrinsic result of the desire/
benefits of being able to process/mix media in a bandwidth/latency
optimized location which typically can not be any of the client
endpoints.
Most client drops have far more spare upload bandwidth than download. So I disagree with the last assertion.
