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. > and when you get to a > group call, you really have to make use of some sort of reflector service. > And video is quite a bit of bandwidth, especially if you have lots of > people. I don't think the NAT traversal issue changes dramatically whether you have p2p or multipoint sessions. 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. > 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. 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. Cheers Toerless
