IETF Logo Mail Archive

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

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Fri, 19 July 2013 18:29 UTC

Return-Path: <matthew.kaufman@skype.net>
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 B18BD21F9EAF for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 11:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.028
X-Spam-Level:
X-Spam-Status: No, score=-5.028 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 wyzPySeKxZRJ for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 11:28:57 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB6021F9E12 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 11:28:57 -0700 (PDT)
Received: from mail67-tx2-R.bigfish.com (10.9.14.229) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 18:28:57 +0000
Received: from mail67-tx2 (localhost [127.0.0.1]) by mail67-tx2-R.bigfish.com (Postfix) with ESMTP id D21373802DB; Fri, 19 Jul 2013 18:28:56 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI
X-SpamScore: 0
X-BigFish: VS0(zzc85dhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h18c673h1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail67-tx2: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail67-tx2 (localhost.localdomain [127.0.0.1]) by mail67-tx2 (MessageSwitch) id 1374258534335554_22599; Fri, 19 Jul 2013 18:28:54 +0000 (UTC)
Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.226]) by mail67-tx2.bigfish.com (Postfix) with ESMTP id 4CF85360243; Fri, 19 Jul 2013 18:28:54 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Jul 2013 18:28:53 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 18:27:49 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Roman Shpount <roman@telurix.com>, Adam Roach <adam@nostrum.com>
Thread-Topic: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
Thread-Index: AQHOhKarH2OEESXTmUGDjlCXp/3ZDplsUWdg
Date: Fri, 19 Jul 2013 18:27:48 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A48423716F6B@TK5EX14MBXC266.redmond.corp.microsoft.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> <CAD5OKxsvUzXttQmdZrpR8-dW8UGY0srdRHSmcRsE2Jibqs+E0Q@mail.gmail.com>
In-Reply-To: <CAD5OKxsvUzXttQmdZrpR8-dW8UGY0srdRHSmcRsE2Jibqs+E0Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.76]
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A48423716F6BTK5EX14MBXC266r_"
MIME-Version: 1.0
X-OriginatorOrg: skype.net
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 18:29:03 -0000

+1 to Roman's comment below. No matter what additional API is produced, as long as the offer/answer state machine is there and there is SDP going between the browsers the JavaScript is either A) not actually in control of what's happening or B) manipulating a bunch of SDP and running the other side of that state machine so as to achieve that control.

There's another way, we wrote it down and published it almost a year ago, and I still believe that starting with that would get us to a full spec sooner than the current path... even more so, now that the last 9 months has achieved approximately nothing.

Matthew Kaufman

From: Roman Shpount [mailto:roman@telurix.com]


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

v2.23.0 | Report a Bug | By Email