[rtcweb] Interoperability and freedom to implement

[Ron <[e-mail]>]

On Tue, Jan 14, 2014 at 09:49:20AM +0000, [e-mail] wrote:
> There are several aspects how WebRTC compatibility or interoperability with
> "legacy" or non-WebRTC devices/services is relevant. I try to summarize them
> below since I think they have been mixed in this conversation:

Clarifying this is indeed useful for helping to decide what is and isn't
important here, so thanks for doing this.

> 1.) WebRTC interoperability with non-WebRTC endpoints or services through a gateway
> 
> In this scenario we have WebRTC and WebRTC compliant devices on one side of
> the gateway, and for instance SIP/IMS/H.323/proprietary video conferencing
> equipment on the other. The gateway may need to do various translations
> related to e.g. ICE, DTLS-SRTP, SDP and so on, but if both sides use the same
> video codec, the heaviest part, i.e. the video transcoding, can be avoided. 
> 
> I think this is the scenario that for instance Keith and Christer have
> brought up in this thread, and that some people thought essential in their
> video codec straw poll answers. H.264 is widely used in those current
> non-WebRTC systems. And they are not all "legacy", but their use and
> deployment may grow in parallel to WebRTC. 

I think there is a very important point about this particular class of
devices that so far people have alluded to in other discussion, but that
I haven't seen anyone really pin down precisely yet, except possibly in
the original language of the charter.

If any of these devices had actually been built using open and accessible
standards for all of their required functionality, then this particular
working group would have never needed to form in the first place to slave
over establishing a standard that was.  The needed work would have already
been done and we'd all be video conferencing to our heart's content today
with any of the numerous freely available implementation that would have
already existed.

Of all the methods of lock out used to keep them a closed shop, not the
least is the strictly guarded use of only highly encumbered codecs ...


So to say that this group must also provide the same degree of lock out
with its mandatory codec options, in order to be interoperable with these
devices, really just boils down to saying "this standard poses a grave
threat to our existing monopoly on video services, and we think that it
is very important that you do not do that".

That would seem to be in direct opposition to the chartered aims of this
group, and basically make it a complete waste of time and effort.


Which still isn't to say that transcoding isn't desirable to avoid.
But the onus should be on the closed devices to interoperate with the
open standard should they choose to -- not to cripple the open standard
and make it effectively just as closed as the things it was designed to
replace.  As you noted there are plenty of other inaccessible standards
that people could already choose from if they want that.  We certainly
shouldn't be reinventing or rubber-stamping any of those here.

Of all the options we might "consider for interworking with legacy VoIP
equipment", sabotaging the freedom of people to implement this standard
should be a clear no-brainer "thanks, but no thanks".

  hth,
  Ron