Re: [rtcweb] Use Case draft - legacy interop

[Bernard Aboba <[e-mail]>]

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