Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

Roman Shpount <roman@telurix.com> Fri, 19 July 2013 17:37 UTC

Return-Path: <roman@telurix.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 D95B021E80C7 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.882
X-Spam-Level:
X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 WHYm0Ej8Aw-2 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:37:41 -0700 (PDT)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A021E8108 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:37:36 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t59so4325699wes.34 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:37:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=y6HFwPjrd2JYT8Lx5dTu+sebBuwzjJ5+ior62uPE2pY=; b=nBXCA54ZCB7u6xy8/qj7UMlZtRUGJRyCJP8ApBZNYMiSsV9Hy8loPB7RaZLttmQv/g hV6ZwTFWsWaftunSr3b7ZnUBp5GNJfqQpuusMskv6dDEtr344LBGLWm9d1NhdtRj01gP cN8BZBE59s47+KTFGEQYpUb3+fjQCdTWpgoXzdR6Ehy0ZTl+J0p06Nxw6k0KpKtRyKrJ 6HTYaBZhX+MmxF66MTV3RSHsjeadeGDgoD5FByJfvmB9j12O35UvIGgc8N01gfsnEGei QC2tH4NXEb6imRFDPiffA6hR2enAqtxVM3ktb6RHhwdc+culFIO5CSdWxnbR3qVoJM0f 0N1A==
X-Received: by 10.194.83.195 with SMTP id s3mr13092913wjy.82.1374255455516; Fri, 19 Jul 2013 10:37:35 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [2a00:1450:400c:c00::230]) by mx.google.com with ESMTPSA id b20sm24460029wiw.4.2013.07.19.10.37.34 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:37:34 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id f11so4234535wgh.27 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:37:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.173.71 with SMTP id bi7mr12898105wjc.2.1374255454006; Fri, 19 Jul 2013 10:37:34 -0700 (PDT)
Received: by 10.216.221.202 with HTTP; Fri, 19 Jul 2013 10:37:33 -0700 (PDT)
In-Reply-To: <51E97677.1020902@nostrum.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@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> <CABkgnnXa-eTzRHcLMnHam4c+1D9kkvRwi9=V-9P43+p+pKE_sw@mail.gmail.com> <CA+9kkMCjt2UHFynLqwns0J0f5ZtnxtMX3ppzR66e5q_rJ9D5Ug@mail.gmail.com> <51E97677.1020902@nostrum.com>
Date: Fri, 19 Jul 2013 13:37:33 -0400
Message-ID: <CAD5OKxsvUzXttQmdZrpR8-dW8UGY0srdRHSmcRsE2Jibqs+E0Q@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="089e0112cf9a2ad3f304e1e0c8ce"
X-Gm-Message-State: ALoCoQlPbxa0Sc3mmGRbZXDT6yj8oBnGPvI7fKFyV5MuiMhFlXjSy9EIY+UKYKwyKQj91MuHEw2J
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:37:47 -0000

On Fri, Jul 19, 2013 at 1:25 PM, Adam Roach <adam@nostrum.com> wrote:

>  I can't +1 this hard enough. I certainly don't want every javascript
> application that makes use of the WebRTC API to independently discover that
> mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable
> if you try to send it more than 320x200 video, and then try to solve that
> problem.
>
> Again and again, for every permutation of phone and operating system
> version.
>
> Yeah, someone has to do this kind of characterization, and some of it can
> be done real-time if you're interacting directly with the operating system.
> So... maybe we could add yet another API to WebRTC to allow applications to
> build this functionality themselves rather than counting on them
> characterizing the systems they care about and blowing up on the ones they
> don't.
>
> But, honestly, any course of action that relegates this to the
> applications seems to have the dual properties of forcing it to be
> implemented hundreds of thousands of times while making the actual user
> experience worse.
>

You cannot be more wrong. Each application deals with predictable set of
scenarios (ones it produces) and interfaces with predictable set of non
webrtc devices. These external devices are under control of the application
developer. Application developer is responsible for interop with these
devices. What is needed is predictable media and signaling generated by
webrtc devices running the same application. With negotiation and SDP
backed into the webrtc device it is very hard to achieve. So, for me as
webrtc developer let me develop a negotiation scheme that works for me and
make sure it stay working regardless of the browser type or version. Right
now controlling webrtc application feels like driving the boat down the
river by tickling the captain.
_____________
Roman Shpount