Re: Off-topic: making WebRTC work in practice (Re: a brief pondering)

Cullen Jennings <fluffy@iii.ca> Thu, 02 April 2020 20:30 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2FA3A1838 for <ietf@ietfa.amsl.com>; Thu, 2 Apr 2020 13:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DclybOUMD55 for <ietf@ietfa.amsl.com>; Thu, 2 Apr 2020 13:30:22 -0700 (PDT)
Received: from smtp127.ord1c.emailsrvr.com (smtp127.ord1c.emailsrvr.com [108.166.43.127]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C680F3A183D for <IETF@ietf.org>; Thu, 2 Apr 2020 13:30:22 -0700 (PDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp16.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E8CFBC0219; Thu, 2 Apr 2020 16:30:21 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [50.66.148.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 02 Apr 2020 16:30:22 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Subject: Re: Off-topic: making WebRTC work in practice (Re: a brief pondering)
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <E1FD746D-0BCD-4ECC-BB9B-75DFA05AA9DC@tzi.org>
Date: Thu, 02 Apr 2020 14:30:21 -0600
Cc: IETF Crazy <IETF@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9836670-02D6-4A01-8BD2-9F7FDBC990E5@iii.ca>
References: <fd6b7ee2-cdbe-14a1-0087-ce61282b22f6@lear.ch> <29D0DCA7-1D72-428F-A6DD-05511D90C039@cable.comcast.com> <31A798F0-9DE0-4231-A768-76BA9A1A2180@tzi.org> <E1FD746D-0BCD-4ECC-BB9B-75DFA05AA9DC@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.14)
X-Classification-ID: b85214d1-b64d-42a9-9fd2-2fceeca8842d-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/h6fTco-9fw7IeF_x6jvEvfrZuvk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 20:30:24 -0000

Many of the things you need to do this were identified in developing WebRTC and put in specs. Many of them had the API in W3C specs that you need. But then the W3C marked them at risk because browser vendors did not implement them and removed them. Now if you write a patch to browser them implements them, they will not accept the patch because it is not in the spec. 

The net effect is what is possible in the browsers experience is just worse than what is possible with non browser clients (it did not need to be like this but it is). Because of this you see all the major meeting systems heavily push users towards using a downloaded client instead of the browser experience. 

The basic problem AFAIC is that at W3C, the browser have a defacto veto on anything so the API is not a negotiation between the the apps need and the browsers provide, it is more of a fait acompli of what Chrome is willing to provide. Anything chrome does not want to do, will effectively get removed from the spec because it will not have enough implementations. Once the app vendors realized that, most of them moved their focus outside of the browsers which is really unfortunate as the browsers protect the users from many security problems you are seeing today. 

> On Apr 1, 2020, at 5:53 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> In the university, a lot of WebRTC is using Jitsi as a tool.
> This works mostly well, with occasional surprises.
> What we could use now is a better way to diagnose these surprises.
> This requires WebRTC knowledge that our IT people don’t have.
> A WebRTC troubleshooting guide that I could point them to would be most helpful.
> (Debugging and fixing Jitsi so it works reliably with both Firefox and Chrome would also help.)
> 
> Grüße, Carsten
> 
> 
>> On 2020-03-22, at 06:45, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> On 2020-03-21, at 16:54, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
>>> 
>>> what can this community (and similar/adjacent ones) do productively together to help
>> 
>> The one thing that would be most useful for me right now would be a document with operational considerations for keeping WebRTC running (e.g., How not to mess it up with your firewall).
>> 
>> Grüße, Carsten
>> 
>