IETF Logo Mail Archive

Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web

Simon Pietro Romano <spromano@unina.it> Wed, 17 December 2014 16:39 UTC

Return-Path: <spromano@unina.it>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB61A8AF5 for <rtcweb@ietfa.amsl.com>; Wed, 17 Dec 2014 08:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.03
X-Spam-Level:
X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4FJwY2pqwbgG for <rtcweb@ietfa.amsl.com>; Wed, 17 Dec 2014 08:39:45 -0800 (PST)
Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70D21A8AD8 for <rtcweb@ietf.org>; Wed, 17 Dec 2014 08:39:44 -0800 (PST)
X-ASG-Debug-ID: 1418834381-05ce37732643c4b0001-4f8tJD
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id C22jRtda5zwoUORz (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 17:39:41 +0100 (CET)
X-Barracuda-Envelope-From: spromano@unina.it
X-Barracuda-Apparent-Source-IP: 192.132.34.61
Received: from [192.168.1.104] ([151.77.231.24]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id sBHGdee6000383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 17:39:41 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_B949B37F-4C15-482E-BF82-3B80EB9DE39A"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Simon Pietro Romano <spromano@unina.it>
X-ASG-Orig-Subj: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web
In-Reply-To: <F7F3EFE2-7258-4AE6-B736-71850692429B@gmail.com>
Date: Wed, 17 Dec 2014 17:39:39 +0100
Message-Id: <554C8171-7804-4887-AE19-407C5DF816C8@unina.it>
References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <CA+9kkMDNhRdbzCs9vrqDeD4CoWWK1xS5o0z3jL0DvNpDuLfCPw@mail.gmail.com> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <CABcZeBOAfuscG28PMAu8JJ4yAAt1-ohnuqCaeoa+jkpDkJhhpw@mail.gmail.com> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <FC77807D-E811-46DE-920C-2019C2E0A563@apple.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> <CA+9kkMBjCOnv+b7yNUSKCUscgQOozEcAvuCmymzyCY8+Kudczw@mail.gmail.com> <F7F3EFE2-7258-4AE6-B736-71850692429B@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.1993)
X-Barracuda-Connect: smtp1.unina.it[192.132.34.61]
X-Barracuda-Start-Time: 1418834381
X-Barracuda-Encrypted: AES256-SHA
X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at unina.it
X-Barracuda-BRTS-Status: 1
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210
X-Barracuda-Spam-Score: -2.02
X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.13015 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NE18tHIK-PY9nhKy9J8bPIEvBzo
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 17 Dec 2014 16:39:48 -0000

> It is possible to write a single stream audio/video app that runs on any browser.  But if you include the video features that enable collaborative Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there are no polyfills today.  So these Web apps need to be written for a particular browser.  By now people are getting used to installing a browser to run their favorite WebRTC web app.

Based on my experience, if you stick to the Maximum Common Divisor (e.g., by avoiding SSRC multiplexing, on hold, some forms of bundling, etc) you can still offer a rich end-user experience on a wide set of browsers (Chrome, Firefox, Opera at least). This is indeed what we try and do with the 'stable' version of Meetecho (which you probably forgot to mention). BTW, I think this is unavoidable as long as the standardization process has not yet reached the steady state.

Simon

> That's not the IETF's problem really (WebRTC protocols and open source SDKs implementing same are in much better shape, and are being widely used). But it is indicative of the mountain that WebRTC needs to be climb to be a successful Web standard. 
> 
> On Dec 16, 2014, at 5:43 PM, Ted Hardie <ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>> wrote:
> 
>> On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> wrote:
>> On Dec 16, 2014, at 3:18 PM, David Singer <singer@apple.com <mailto:singer@apple.com>> wrote:
>> 
>> However the browser model is very different. The browser app developer typically cannot compile their own browser or fix browser bugs so they have to live with what is there. Today's polyfills typically only work for audio so writing a multi-browser video app that supports multiple video streams is a nightmare even without a codec problem.
>> 
>>  
>> ​So, can I confirm here that you mean polyfill in the same way ​Remy Sharp did?  That is, a piece of Javascript that replicates an API and functionality that the browser lacks?
>> 
>> And so you are asserting that there are downloadable Javascript bits that replicate both the audio functionality and relevant API, but there are no downloadable Javascript bits that replicate the video functionality and relevant API?
>> 
>> Have I gotten your meaning?
>> 
>> Ted
>> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

v2.23.0 | Report a Bug | By Email