Re: [rtcweb] interworking with non-WEBRTC endpoints

Xavier Marjou <xavier.marjou@orange.com> Fri, 04 May 2012 13:50 UTC

Return-Path: <xavier.marjou@gmail.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 6A68521F86F7 for <rtcweb@ietfa.amsl.com>; Fri, 4 May 2012 06:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pVVxqSk+bAqn for <rtcweb@ietfa.amsl.com>; Fri, 4 May 2012 06:50:40 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6E9121F86F6 for <rtcweb@ietf.org>; Fri, 4 May 2012 06:50:39 -0700 (PDT)
Received: by lagj5 with SMTP id j5so2347237lag.31 for <rtcweb@ietf.org>; Fri, 04 May 2012 06:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WDARojiQTDjDQ5b37M8CIPIVe502R31IBg09iWs72dc=; b=mB9EpnXRXRvrC5aAZjvLGA3HRct9okjAyE6Omfu4aGzf62LTKarGAyjbCXSsmWhM4y 5maCe9DIL9qYWt8vSrXgMh38rqwU14k5UisnjX8GaTg+Nf3w5Y8gv0Z7Rq8BxuPB6Xs2 CNV+RWK2P6H3A0IwML2mqYMernQX5MAOD47IXnblNiZSE1YVn5KFiyg9nkD2eLw7mnLR pIDGV4k3FvyvNgfnbMBngvmLs1F5CDJRHh86Cbrq8QjCvTVSGnj1xuOnbOUfl+Wu+gfw HaPU4ZEyJRnUN11FG3QHfkOB+uxObv/bEwdAD+Ky6lkTMShpyLvA7E+tDYnrIScLYRMs 8vKw==
MIME-Version: 1.0
Received: by 10.112.40.5 with SMTP id t5mr2979731lbk.55.1336139438548; Fri, 04 May 2012 06:50:38 -0700 (PDT)
Sender: xavier.marjou@gmail.com
Received: by 10.152.112.40 with HTTP; Fri, 4 May 2012 06:50:38 -0700 (PDT)
In-Reply-To: <014201cd29f7$c4f0f8c0$4ed2ea40$@us>
References: <CA+9kkMCYArLPRP3c00UdOja64WRT6ghN0PSy7XvM_wbxBBB+vA@mail.gmail.com> <E17CAD772E76C742B645BD4DC602CD810616F066@NAHALD.us.int.genesyslab.com> <BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl> <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com> <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <E2714FBC-D06B-4A12-9E07-C49EBF55084C@phonefromhere.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <CAJNg7VKENERKAFA-n5KeoeBNmGgHrnzDOU0BzC9+fSdsuGwdEw@mail.gmail.com> <E17CAD772E76C742B645BD4DC602CD810616F24F@NAHALD.us.int.genesyslab.com> <4FA0F43E.4020308@ericsson.com> <E17CAD772E76C742B645BD4DC602CD810616F336@NAHALD.us.int.genesyslab.com> <013101cd288c$09328250$1b9786f0$@com> <CALiegf=RsHHf9jCBhE55t7qFUpts8yJ1c8qUX12nc_vd4vgjSQ@mail.gmail.com> <CAJNg7VLCGgJGpV1+YTdBGjMOLBj4x=2-xyu8bpcjRt8Riyo6hA@mail.gmail.com> <BLU169-W71F02518D72C33DED96B90932F0@phx.gbl> <014201cd29f7$c4f0f8c0$4ed2ea40$@us>
Date: Fri, 04 May 2012 15:50:38 +0200
X-Google-Sender-Auth: VriCBjuSYIdMPtRH1FpRYXjBTkM
Message-ID: <CAErhfrzq8yfeYTHZa+4ZiH8vSqCUgYDvxNSDpSNHsw1f3RP=_Q@mail.gmail.com>
From: Xavier Marjou <xavier.marjou@orange.com>
To: rtcweb@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints
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, 04 May 2012 13:50:41 -0000

+1

On Fri, May 4, 2012 at 3:13 PM, Richard Shockey <richard@shockey.us> wrote:
> +1 another reason to mandate H.264
>
>
>
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Bernard Aboba
> Sent: Thursday, May 03, 2012 10:44 AM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints
>
>
>
> I concur with Marshall's objections, based on my discussions with customers.
>
> Video conferencing systems are frequently purchased with the expectation
> that they will be
> used to communicate outside the organization, as well as with other devices,
> including PCs,
> tablets and mobile devices.
>
> As an example, an enterprise with a video conferencing system may use it to
> communicate
> with employees in the field who are using a notebook, tablet or mobile
> device.
>
> Therefore, while an enterprise may have a finite number of video
> conferencing units,  it will
> often deploy them along with orders of magnitude more devices that
> interoperate with those
> units.
>
> The usual requirements for a desirable mobile or tablet implementation apply
> here -- power
> management (e.g. ability to utilize native encode/decode hardware) is an
> important capability.  Also,
> the cost of supporting video transcoding for a large number of devices will
> frequently be prohibitive,
> so that the expectation is that videoconferencing systems and
> implementations on PCs, tablets
> and mobile devices will be able to negotiate a mutually supported codec.
>
>
>
> On 05/02/2012 08:19 PM, Marshall Eubanks wrote:
>
> My objection is that the proposed system will require middleware to
>
> interoperate with the
>
> vast number of videoconferencing sessions out there, most of which use
>
> RTP. From the
>
> standpoint of a video service provider, buying hardware to support
>
> video to laptops is likely to
>
> lead to requests that participants download some other software which
>
> interoperates natively.
>
>
>
> This is an existing business with a fairly large scale and installed
>
> base. Not operating the way that they do is not likely to go over
>
> well.
>
>
>
> Marshall,
>
> I'd like to draw your attention to two numbers:
>
> - Number of installed room videoconferencing units: On the order of 1
> million.
>
> http://www.polycom.com/global/documents/company/video_conferencing_by_the_numbers.pdf
>
> - Number of installed Chrome browsers: On the order of 200 million.
>
> http://www.techradar.com/news/internet/google-chrome-browser-hits-200-million-users-1033951
>
> (pulling out Chrome just because I know we've promised to ship this stuff.
> And we auto-update, which means most of the users WILL be running a
> WebRTC-compatible browser the week after we release it.)
>
> I argue strongly for doing things in ways that we know work, which means not
> inventing stuff until we really have to. And I've even argued strongly for
> doing things in ways that *permit* interoperation with those older devices -
> but not in the cases where doing so risks harming the security, stability
> and operational complexity of the installed base that is to come.
>
>                     Harald
>
>
> _______________________________________________ rtcweb mailing list
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>