Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
Peter Thatcher <pthatcher@google.com> Fri, 19 July 2013 17:18 UTC
Return-Path: <pthatcher@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6021F9CE7 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level:
X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNHL+o-GCewx for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:18:52 -0700 (PDT)
Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2781B21F9C72 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:18:50 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id md12so4645768pbc.16 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:18:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2hQ9Obl7mM61INi7YiSdbyfLFr6FHf4tyZAibNi3lqM=; b=Nv4YlI02CeUc+OhOhzKBdK9mEDtyvVAqjnBfc9QyUHDtAxpnyjNK/ceBn6iKzzU93s ynop6LDGsz72VQYtc6MbdkaMwVpjbkpxR4kUjeIJLuHWZnzByLa2CsMNWkVEGBjk6TjX ckN9KAUp6uEsjteErZfM7JC9rEPV2nikp8F2iLNxow2YkMwwsr+zuyA6z3rk/vG730Fi fwQFUEsEcujs6MUz05YhQ4M1uJNjOzI9cjqoF4guNWvQyWJFWVD2MTizZVwxLlCJ95+t LF5S454Vvy/yTB64uaeasmAteYzRrpn4x0pswSaxP035eKpg8gCgwhZmOfv3r/hB3n57 zWPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2hQ9Obl7mM61INi7YiSdbyfLFr6FHf4tyZAibNi3lqM=; b=S2yUIrbf2/j0KwRjAKj0pyTAy7bPgJ1dvX1ZVdPVPDETCFlQUdNy0DqgOE2JqBcMEV 5HUdDitu0bo+dTOeQ6rWOUw3KtuP8rnG5GPynsXtZdpf/vo9LxFWVVtW9rIJi5rulsp8 SC/xkBtpsYUOBUYMyfdxDPkCaEPpia/vFiCtVu9trAUrF0bk7OtZjLt+O8N45iv6++7I dBRqHgQhqx1RGgySDg626XAeS6Ct7+PKWlbzmavpnp/Pd2vLldCRyjggge/Ip4JA+7Gw C5/nPjf4edudwjNS4BjUzUfK3z/RirHESQSlsw4xYhqj7Ro7u6mEArvoGgRzpj/2TRT0 0WHQ==
X-Received: by 10.66.217.195 with SMTP id pa3mr19411711pac.120.1374254329682; Fri, 19 Jul 2013 10:18:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 10:18:09 -0700 (PDT)
In-Reply-To: <51E96B5B.2050302@nostrum.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com> <CABcZeBPa4wBS8pYq=0wesMOfL6TkeC7QGAZ8pWwOcnkhkJqWfA@mail.gmail.com> <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com> <CABcZeBOTKpmFC34waqZ4kA-P8t+E6yY9gX1JFCHhsBH0+CF-Qw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <CAD5OKxtKLMf_d=8GSMrqfNhDHPe9MFP2ZTKzZHFn9CyMr-gSVQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <CAD5OKxvGfkgRp6tXwbOu_kVteHiBBqsyR5ixH18FMKjCNGO8VQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <AE1A6B5FD507DC4FB3C5166F3A05A484213E41E7@TK5EX14MBXC265.redmond.corp.microsoft.com> <C50FDAD5-492C-4A83-AD6D-464242FB4A05@iii.ca> <CALiegfneUj=kzDjR_E1=S-bqAajaPUE3f_A2g8oGriFyPhamPA@mail.gmail.com> <51E96B5B.2050302@nostrum.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 19 Jul 2013 10:18:09 -0700
Message-ID: <CAJrXDUFtPwHNznRHYgMpSr8U04Y+toDHubJ5fK-2qtnsURtL7g@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="047d7b5d438c26fb5104e1e085c4"
X-Gm-Message-State: ALoCoQkqZX4ur6dihFrVfuHZ6Qz6PiHsbdZ9JhK2XJGcJU5PNaGsi7HpTmqfV6IObNQTUcUEA1dC29TsvdDKTm8eeaJlGYsqUry5amBo0JLK9F+IxFfmHKbLs8nc3uK6JdmGx2zxvQqtp48mwoeWEINSRZHwajGwGI5Ly3Bctfnow1cHDFFN+Om2IZHmsVyk8Fe3Fjsjj+bs
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 17:18:53 -0000
On Fri, Jul 19, 2013 at 9:37 AM, Adam Roach <adam@nostrum.com> wrote: > On 7/19/13 10:03, Iñaki Baz Castillo wrote: > >> All these "smaller details" are in fact issues and problems we don't >> need. Issues not needed at all in WebRTC, issues that WebRTC >> developers and vendors should NOT care about. If those "smaller >> details" do exist is due the mandate of SDP. And all the time the WG >> (or WGs) will spent "fixing/defining" them is just wasted time, since >> nothing useful is being done for WebRTC by "defining" those "minor >> details". >> >> > I think this is a hopelessly naïve interpretation of the facts on the > ground. Simply discarding SDP doesn't magically make the underlying issues > go away. We would still need to settle a vast number of issues around > things like simulcast, FEC, codec parameters, indication of supported > codecs, correlation of RTP streams with MediaStreamTracks, attempts by both > parties to operate on the same stream simultaneously [1], etc. Basically, > with very rare exception, the same set of problems that we need to solve if > we *don't* throw SDP out the window. > It's interesting that most or your list of things that needed to be solved without SDP (simulcast, FEC, correlation of RTP streams with MediaStreamTracks, glare) still haven't been solved for WebRTC even with SDP, despite many months (years?) of effort. I don't think anyone is saying "without SDP, there would be issues". I think they're saying "without SDP, the issues are much easier/faster to solve, and the API would be much more usable and implementable". And I don't think that's a naive opinion. > > I understand the temptation to think that starting over makes all the > problems go away. There's a mental trap in thinking that all you really > need is to announce ports and codecs and get on with it. But then this > person over here really needs simulcast. And that person over there insists > that RTCP NACK feedback is critical for his application. And then I need to > be able to tell you that your 1280x720 video stream is going to overwhelm > my limited ability to decode and that you really need to turn it down to > QCIF. And, before you know it, you've reinvented something approximately > as complex as SDP I think you are conflating signalling with API surface. If we focus on making a good API rather than on signalling, we can make something much more simple and leave signalling up to the application. > that everyone is just going to shove into a JSON blob and send across the > wire. As an added bonus, by deciding that legacy interop is of no value, > you've limited the utility of the overall system by setting Metcalfe's law > on fire and throwing it over the railing of the third-floor balcony. Again, you are conflating API surface and signalling. An API that doesn't have SDP in it doesn't preclude web apps from using SDP for signalling. There's no loss here for those app that choose to use SDP. There is only gain for web developers chooses not to use SDP for the signalling in their web application. And if they choose not to use SDP and use JSON instead, why are you so opposed? There is a world outside of legacy interop, you know. > > > Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard. Your > pain point isn't offer/answer. Two unilaterally declared sessions that are > simply blasted out onto the wire only satisfies the simplest of use cases; > you need a negotiation, and any attempt to define how that negotiation > looks is going to arrive at something with enough rules that it is > substantially as complicated as offer/answer. > You are underestimating how painful it is to deal with the current API, both because you are very familiar with it (with many years of experience) and because the use cases you care about are the ones the API was defined for (legacy interop). But as soon as you ask someone who is not familiar with SDP (a lot of web devleopers), or someone who is doing more advanced or different things than what you have thought of, they will give you a different answer. They feel pain, and it is because of the poor API surface. > > No, your pain point here is that non-master-slave networked communications > are not easy to get right, and it is the height of hubris to think that you > inherently know better than everyone else who has worked in this space > before you. Consider that TCP has far fewer moving parts than even a simple > one-stream-audio-only call setup and took 85 pages to specify. > Please try to consider what you sound like to a web developer who is trying to use WebRTC and finding SDP to be difficult API surface. Maybe I'm wrong, but I'm guessing what you're saying will sound like. "my use case (legacy interop) is the most important and my solution (SDP) is the best solution for everyone and I know better because I've been working on it for longer". Hubris? > > I understand comment 22 at its core [2], but it has a corollary: any > system that replaces SDP O/A will end up being similar in complexity once > all interested parties' use cases have been factored in. > There is a vast difference that you are not taking into account. The SDP O/A, if in JS, is a complexity cost only paid by those web applications that need it. But if baked into the API, every app must pay the cost of the complexity. In general, this emails seems to be arguing that SDP is the optimal API surface for expressing all these complex things, and yet in other occasions, I've heard you admit it's a terrible API surface. So does that mean the optimal API surface is terrible? I don't think so. It will be work, but I think the work will be worth it in the end. That said, the chairs have asked us to delay discussing a better API, so we'll have to wait before we can discuss details of how an API could be done without SDP. > > /a > > ____ > [1] What we call "glare" in telecom and SIP, but a phenomenon that arises > whenever you have connections made between peers without a master/slave > arrangement; see RFC 793, page 32, for example. > > [2] For the uninitiated, "comment 22" was a shorthand developed at last > year's TPAC for the sentiment "SDP offer/answer is hard". > >
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- [rtcweb] Summary of Application Developers' opini… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- Re: [rtcweb] Summary of Application Developers' o… Philipp Hancke
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Binod
- Re: [rtcweb] Summary of Application Developers' o… Robin Raymond
- Re: [rtcweb] Summary of Application Developers' o… Matthew Kaufman
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Roman Shpount
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Saint-Andre
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Philipp Hancke
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Jim Barnett
- Re: [rtcweb] Summary of Application Developers' o… Roman Shpount
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Jim Barnett
- Re: [rtcweb] Summary of Application Developers' o… Roman Shpount
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- Re: [rtcweb] Summary of Application Developers' o… Roman Shpount
- Re: [rtcweb] Summary of Application Developers' o… Eric Rescorla
- Re: [rtcweb] Summary of Application Developers' o… Roman Shpount
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Silvia Pfeiffer
- Re: [rtcweb] Summary of Application Developers' o… Martin Thomson
- Re: [rtcweb] Summary of Application Developers' o… Silvia Pfeiffer
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Bernard Aboba
- Re: [rtcweb] Summary of Application Developers' o… Silvia Pfeiffer
- Re: [rtcweb] Summary of Application Developers' o… Bernard Aboba
- Re: [rtcweb] Summary of Application Developers' o… Matthew Kaufman (SKYPE)
- [rtcweb] e= lines (Re: Summary of Application Dev… Harald Alvestrand
- Re: [rtcweb] e= lines (Re: Summary of Application… Harald Alvestrand
- Re: [rtcweb] e= lines (Re: Summary of Application… Peter Thatcher
- Re: [rtcweb] e= lines (Re: Summary of Application… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Martin Thomson
- Re: [rtcweb] Summary of Application Developers' o… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Summary of Application Developers' o… Silvia Pfeiffer
- Re: [rtcweb] Summary of Application Developers' o… Justin Uberti
- Re: [rtcweb] Summary of Application Developers' o… Stefan Håkansson LK
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- [rtcweb] On babies and bathwater (was Re: Summary… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Martin Thomson
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Ted Hardie
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Martin Thomson
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Martin Thomson
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Roman Shpount
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Martin Thomson
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Roman Shpount
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Roman Shpount
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Roman Shpount
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Martin Thomson
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Bernard Aboba
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Adam Roach
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Cullen Jennings
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Cullen Jennings
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Cullen Jennings
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Cullen Jennings
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Summary of Application Developers' o… Robin Raymond
- Re: [rtcweb] Summary of Application Developers' o… Bernard Aboba
- Re: [rtcweb] Summary of Application Developers' o… Peter Thatcher
- Re: [rtcweb] Summary of Application Developers' o… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Matthew Kaufman (SKYPE)
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Iñaki Baz Castillo
- Re: [rtcweb] On babies and bathwater (was Re: Sum… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo
- Re: [rtcweb] Summary of Application Developers' o… Hadriel Kaplan
- Re: [rtcweb] Summary of Application Developers' o… Timothy B. Terriberry
- Re: [rtcweb] Summary of Application Developers' o… Iñaki Baz Castillo