Re: Off-topic: making WebRTC work in practice (Re: a brief pondering)
Toerless Eckert <tte@cs.fau.de> Wed, 08 April 2020 21:46 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 02E833A1279; Wed, 8 Apr 2020 14:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level:
X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 BkopOTH4hbCP; Wed, 8 Apr 2020 14:46:30 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB783A182B; Wed, 8 Apr 2020 14:46:29 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E9A60548045; Wed, 8 Apr 2020 23:46:24 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DBD85440040; Wed, 8 Apr 2020 23:46:24 +0200 (CEST)
Date: Wed, 08 Apr 2020 23:46:24 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Cullen Jennings <fluffy@iii.ca>
Cc: Carsten Bormann <cabo@tzi.org>, IETF Crazy <IETF@ietf.org>, manycouches@ietf.org
Subject: Re: Off-topic: making WebRTC work in practice (Re: a brief pondering)
Message-ID: <20200408214624.GA42640@faui48f.informatik.uni-erlangen.de>
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> <C9836670-02D6-4A01-8BD2-9F7FDBC990E5@iii.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <C9836670-02D6-4A01-8BD2-9F7FDBC990E5@iii.ca>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9_i-OMDH3y7JmdeF-cxaX9QkLWM>
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: Wed, 08 Apr 2020 21:46:32 -0000
[adding manycouches as this is really technical. ] [can not well Bcc ietf as mailman seems to hate it] Thanks for the insight, Cullen, Harald. I can well understand that it is frustrating if you really want to build a high-functional browser based app and are then not given all the necessary support by browsers. It also makes perfect sense though for google to only care for where their money comes from, and if that means that android is the reference for what to do across all other platforms and forces this onto W3C, then one just needs to take this into account accordingly and make the community understand those limitations of RTCweb/W3C solutions. The question for IETF/manycouches is IMHO, what IETFs priority order of requirements against conference tools in the future should be. I would ideally like an open source solution working on Mac, Windows, Linux. In other communities i would include android, but i think for our work style its irrelevant, and if the solution is open source, someone will port it from linux to android anyhow when needed. Could the solution be RTCweb based ? Sure, why not, but thats just an option to achieve such results, it should not be a mandate. I do not quite understand Haralds argument, that full standards should only include what vendors utimately implemented in draft standard stage. Assume that there are only 2 vendors implementing some protocol and they just could not be bothered to implement the security requirements, does that mean the full IETF standard should drop the security requirements ? I am not sure though how this all relates to what i thought the root of the discusion was, diagnostics: I would certainly be interested to better understand what tracing options at the RTCweb ap-to-browser API level exist, because my past decades troubleshooting of (native) conferencing app networking issues always came down to logs, syscall-traces and network traces. All the TLS security of course makes that tracing a lot more difficult. Cheers Toerless On Thu, Apr 02, 2020 at 02:30:21PM -0600, Cullen Jennings wrote: > > 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 > >> > > -- --- tte@cs.fau.de
- Re: a brief pondering Livingood, Jason
- a brief pondering Eliot Lear
- Re: a brief pondering Narelle Clark
- Re: a brief pondering Carsten Bormann
- Re: a brief pondering Michael Tuexen
- Re: a brief pondering Nick Hilliard
- Re: a brief pondering Carsten Bormann
- Re: a brief pondering Spencer Dawkins at IETF
- Re: a brief pondering Michael Tuexen
- Re: a brief pondering Adam Roach
- Re: a brief pondering Adam Roach
- WebRTC (Re: a brief pondering) Harald Alvestrand
- Re: a brief pondering Michael Richardson
- Re: a brief pondering Phillip Hallam-Baker
- Re: a brief pondering Narelle Clark
- Re: a brief pondering Toerless Eckert
- Re: a brief pondering Nick Hilliard
- Off-topic: making WebRTC work in practice (Re: a … Carsten Bormann
- Re: Off-topic: making WebRTC work in practice (Re… Spencer Dawkins at IETF
- Re: Off-topic: making WebRTC work in practice (Re… Carsten Bormann
- Re: Off-topic: making WebRTC work in practice (Re… Philipp Hancke
- Re: Off-topic: making WebRTC work in practice (Re… Cullen Jennings
- Re: Off-topic: making WebRTC work in practice (Re… Harald Alvestrand
- Re: Off-topic: making WebRTC work in practice (Re… Benjamin Kaduk
- Re: Off-topic: making WebRTC work in practice (Re… Bob Hinden
- Re: Off-topic: making WebRTC work in practice (Re… Harald Alvestrand
- RE: Off-topic: making WebRTC work in practice (Re… Larry Masinter
- Re: Off-topic: making WebRTC work in practice (Re… Keith Moore
- Re: Off-topic: making WebRTC work in practice (Re… Phillip Hallam-Baker
- Re: Off-topic: making WebRTC work in practice (Re… Michael Richardson
- Re: Off-topic: making WebRTC work in practice (Re… Eric Rescorla
- Re: Off-topic: making WebRTC work in practice (Re… Christer Holmberg
- Re: Off-topic: making WebRTC work in practice (Re… Peter Saint-Andre
- Re: Off-topic: making WebRTC work in practice (Re… Nico Williams
- Re: Off-topic: making WebRTC work in practice (Re… Cullen Jennings
- Re: Off-topic: making WebRTC work in practice (Re… Mary B
- Re: Off-topic: making WebRTC work in practice (Re… Harald Alvestrand
- Re: Off-topic: making WebRTC work in practice (Re… Christer Holmberg
- Re: Off-topic: making WebRTC work in practice (Re… Harald Alvestrand
- Re: Off-topic: making WebRTC work in practice (Re… Christer Holmberg
- Re: Off-topic: making WebRTC work in practice (Re… Simon Pietro Romano
- Re: Off-topic: making WebRTC work in practice (Re… Toerless Eckert
- Implementation requirement (Re: Off-topic: making… Harald Alvestrand
- COVID-19 contacts tracker (Re: a brief pondering) Benoit Claise
- Re: COVID-19 contacts tracker (Re: a brief ponder… Carsten Bormann
- Re: COVID-19 contacts tracker (Re: a brief ponder… Keith Moore
- Re: COVID-19 contacts tracker (Re: a brief ponder… John Wroclawski
- Re: COVID-19 contacts tracker (Re: a brief ponder… Bob Hinden
- Re: COVID-19 contacts tracker (Re: a brief ponder… Dirk-Willem van Gulik
- Re: COVID-19 contacts tracker (Re: a brief ponder… Keith Moore
- Re: COVID-19 contacts tracker (Re: a brief ponder… Joel M. Halpern
- Re: COVID-19 contacts tracker (Re: a brief ponder… Eric Vyncke (evyncke)
- Re: COVID-19 contacts tracker (Re: a brief ponder… John Wroclawski
- Re: COVID-19 contacts tracker (Re: a brief ponder… Keith Moore
- Re: COVID-19 contacts tracker (Re: a brief ponder… John Wroclawski
- Re: COVID-19 contacts tracker (Re: a brief ponder… Rob Sayre
- Re: COVID-19 contacts tracker (Re: a brief ponder… Fred Baker
- Re: COVID-19 contacts tracker (Re: a brief ponder… Rich Kulawiec
- Re: COVID-19 contacts tracker (Re: a brief ponder… Keith Moore
- Re: COVID-19 contacts tracker (Re: a brief ponder… Vittorio Bertola
- Re: COVID-19 contacts tracker (Re: a brief ponder… Stephane Bortzmeyer
- Re: COVID-19 contacts tracker (Re: a brief ponder… John Wroclawski
- Re: COVID-19 contacts tracker (Re: a brief ponder… Christian Huitema
- Re: COVID-19 contacts tracker (Re: a brief ponder… Jeff Tantsura
- Re: COVID-19 contacts tracker (Re: a brief ponder… Robert Raszuk
- Re: COVID-19 contacts tracker (Re: a brief ponder… Rob Sayre
- Re: COVID-19 contacts tracker (Re: a brief ponder… Phillip Hallam-Baker
- Re: COVID-19 contacts tracker (Re: a brief ponder… Harish Pillay
- RE: COVID-19 contacts tracker (Re: a brief ponder… Andrew Campling
- Re: COVID-19 contacts tracker (Re: a brief ponder… Christian
- Re: COVID-19 contacts tracker (Re: a brief ponder… Rich Kulawiec
- Re: COVID-19 contacts tracker (Re: a brief ponder… Stephane Bortzmeyer
- Re: COVID-19 contacts tracker (Re: a brief ponder… Christian
- Re: WebRTC (Re: a brief pondering) Cullen Jennings