Re: [rtcweb] interworking with non-WEBRTC endpoints

"Richard Shockey" <> Fri, 04 May 2012 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF1FA21F864D for <>; Fri, 4 May 2012 06:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.628
X-Spam-Status: No, score=-99.628 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ucdf1yXYy6ta for <>; Fri, 4 May 2012 06:14:03 -0700 (PDT)
Received: from ( [IPv6:2605:dc00:100:2::a1]) by (Postfix) with SMTP id A221B21F85E1 for <>; Fri, 4 May 2012 06:14:02 -0700 (PDT)
Received: (qmail 18106 invoked by uid 0); 4 May 2012 13:14:01 -0000
Received: from unknown (HELO ( by with SMTP; 4 May 2012 13:14:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=oTcHu/2ggEE6/xgl0SafqtMlSu+UgbqQ9M6f9f+u6mk=; b=DJ/G5d+nfwTewrR3u86F29p3H7780N2BctlVF06dFAhayMrZa+NdTgF/5wA+PIT9ZA3VsuWuD0RXZNbeLQq6eiQvdjEi3nGycRAFR7ZTh0G2QAWakHuURdVLhFT5wqtr;
Received: from ([] helo=RSHOCKEYPC) by with esmtpa (Exim 4.76) (envelope-from <>) id 1SQIKe-0007kF-4n for; Fri, 04 May 2012 07:14:00 -0600
From: Richard Shockey <>
References: <>, <>, <BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <013101cd288c$09328250$1b9786f0$@com>, <>, <>, < 4FA21FA3.1090702@alves trand .no> <BLU169-W71F02518D72C33DED96B90932F0@phx.gbl>
In-Reply-To: <BLU169-W71F02518D72C33DED96B90932F0@phx.gbl>
Date: Fri, 04 May 2012 09:13:58 -0400
Message-ID: <014201cd29f7$c4f0f8c0$4ed2ea40$@us>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0143_01CD29D6.3DDF58C0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0pOzOmzQoskONmSRWt0D0xw2jvswAvHMHw
Content-Language: en-us
X-Identified-User: {} {sentby:smtp auth authed with}
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: Fri, 04 May 2012 13:14:03 -0000

+1 another reason to mandate H.264  


From: [] On Behalf Of
Bernard Aboba
Sent: Thursday, May 03, 2012 10:44 AM
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
with employees in the field who are using a notebook, tablet or mobile

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

- 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