Re: [rtcweb] Use Case draft - legacy interop

Bernard Aboba <> Fri, 04 May 2012 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 536C421F85C7 for <>; Fri, 4 May 2012 07:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.224
X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BiUlsPQ7kkPn for <>; Fri, 4 May 2012 07:46:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8E4C521F85B5 for <>; Fri, 4 May 2012 07:46:39 -0700 (PDT)
Received: from BLU169-W86 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 07:46:39 -0700
Message-ID: <BLU169-W86972AB36EAE1F089A7A27932C0@phx.gbl>
Content-Type: multipart/alternative; boundary="_fe0a380e-3a14-4ffa-8bd3-4fcdd05acc00_"
X-Originating-IP: []
From: Bernard Aboba <>
Date: Fri, 04 May 2012 07:46:38 -0700
Importance: Normal
In-Reply-To: <>
References: <><><BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl><><><><><><><><> <> <> <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 May 2012 14:46:39.0404 (UTC) FILETIME=[B68556C0:01CD2A04]
Subject: Re: [rtcweb] Use Case draft - legacy interop
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 14:46:40 -0000

> My memory of our last rounds of discussion was that we decided not to 
> have a non-gateway legacy interop case because
> a) given the variety of legacy equipment, it would basically require a 
> specific device as the "interop partner" (a rathole), and
> b) it would bind the architecture of RTCWeb in ways that might prevent 
> us from achieving our goals in other ways (especially security issues).

[BA] That was my recollection as well.  

The discussion we're getting into now involves how much the "gateway" will
need to do.  This will of necessity vary depending on how ancient the "legacy"
equipment is.  For example, if the "legacy" is only a few years old, it may 
support SRTP, and with appropriate RTCWEB accommodation (e.g. EKT or
SDES), the "gateway" would not need to decrypt/encrypt every media frame. 
In this scenario, the "gateway" functionality needed by WebRTC would be in
the range of capabilities already supported by SBCs (which are proliferating
like weeds even in "legacy" deployments).  So one could claim that the 
additional burden imposed by WebRTC interop gateways would be tolerable.

If the "legacy" is older (e.g. circa mid-2000s), then it will probably not
support SRTP, and the burden on the gateway becomes greater.  Personally,
I'm ok with this because many of those "extreme legacy" deployments are
nearing (or have already passed) "end of life" and by the time RTCWEB
is widely deployed, they will have become difficult to support/maintain. 
Since those "extreme legacy" deployments don't support most of the 
capabilities of WebRTC anyway without an upgrade (e.g. typically no video 
or IM&P), it doesn't seem sensible to me to warp the entire WebRTC
architecture to accommodate them.