Re: [rtcweb] interworking with non-WEBRTC endpoints

Bernard Aboba <> Thu, 03 May 2012 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D69B21F861D for <>; Thu, 3 May 2012 07:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.203
X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ibB71TiXj7rD for <>; Thu, 3 May 2012 07:44:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 21CC021F8606 for <>; Thu, 3 May 2012 07:44:03 -0700 (PDT)
Received: from BLU169-W71 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 07:44:02 -0700
Message-ID: <BLU169-W71F02518D72C33DED96B90932F0@phx.gbl>
Content-Type: multipart/alternative; boundary="_7926cf3c-d1ca-4718-89cb-d01010157f80_"
X-Originating-IP: []
From: Bernard Aboba <>
Date: Thu, 03 May 2012 07:44:02 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <013101cd288c$09328250$1b9786f0$@com>, <>, <>, <4FA21FA3.1090702@alvestrand .no>
MIME-Version: 1.0
X-OriginalArrivalTime: 03 May 2012 14:44:02.0556 (UTC) FILETIME=[2E9E7BC0:01CD293B]
Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 May 2012 14:44:04 -0000

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

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



    I'd like to draw your attention to two numbers:


    - Number of installed room videoconferencing units: On the order of
    1 million.



    - Number of installed Chrome browsers: On the order of 200 million.



    (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.





rtcweb mailing list