Re: [rtcweb] MTI Video Codec: a novel proposal

On 11/10/2014 05:20 PM, David Singer wrote:
> On Nov 10, 2014, at 17:10 , Ron <ron@debian.org> wrote:
>
>> His option guarantees that anyone implementing only their preferred
>> codec will be able to interop with any compliant implementation,
>> though it may not be able to do so with another non-compliant
>> implementation that similarly opted out of supporting that codec.
> I am sorry, I don’t get it.  The spec. defines “WebRTC-compatible endpoint”
>
> A WebRTC-compatible endpoint is an endpoint that is capable of
>       successfully communicating with a WebRTC endpoint, but may fail to
>       meet some requirements of a WebRTC endpoint.  This may limit where
>       in the network such an endpoint can be attached, or may limit the
>       security guarantees that it offers to others.
>
> but says nothing about it being ‘non-compliant’.  So anyone can say “I claim that this is compliant to the spec.” (as a webrtc-compatible endpoint) — and it might not interoperate. Basically, this proposal assigns different names to the devices that implement both, and those that implement only one or none, but does that really further the cause of interoperability?
Video codecs weren't part of the discussion when we introduced those terms.

The obvious examples were ICE-Lite for gateways that reside at public IP
addresses, and datachannel and video for POTS telephone gateways - and
yes, also OPUS codecs for POTS gateways. (those that have *only* g.711
on the other side - there are better codecs in that environment too,
where bridging to OPUS may make sense.)

The theory is that those devices will exist and do what they will do no
matter what we specify here, so we might as well

We'll go through terminology in an hour or so in the meeting.

>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.