Re: [rtcweb] confirming sense of the room: mti codec

[Ron <[e-mail]>]

On Wed, Dec 10, 2014 at 11:15:48AM -0800, David Singer wrote:
> 
> > On Dec 9, 2014, at 17:22 , Ron <[e-mail]> wrote:
> > 
> > On Tue, Dec 09, 2014 at 05:03:34PM -0800, Bernard Aboba wrote:
> >> My bad.
> >> 
> >> New question:  How can an endpoint that implements video but none of the
> >> MTI codecs be construed as "WebRTC Compatible"?
> > 
> > And what about an endpoint that implements coffee making, but not audio?
> 
> ah, that’s different.
> 
> “I do video” —  but I chose a strange codec and I don’t interoperate
> with anyone else who does, only myself
>    and
> “I don’t do video at all”
> 
> are very different places to be.
> 
> If I build a web app that is a baby monitor (relays just the sound of
> the baby’s room) and doesn’t do video, I would hope that it could
> claim to be a webRTC endpoint, no?  Similarly for a silent
> surveillance camera — audio codec requirements are irrelevant because
> it doesn’t do audio at all.

I'm not really sure these are all that different in the sense of the
categories of devices that the spec needs to differentiate between
(which is the purpose of the definitions that we have about this).

In all of the cases above, the device is not a WebRTC endpoint, since
it can't be relied upon to do everything that the baseline WebRTC spec
requires.  If a real WebRTC endpoint could nonetheless still interact
with it in some more limited way, then it falls into the catch-all
category Which May Need A Better Name.

I think it's correct to say these aren't WebRTC endpoints, and to say
as little about them as we absolutely need to beyond acknowledging they
will exist, and will likely do things we can't exhaustively enumerate.


Even the case of "I can do video but none of the MTI codecs" could
include things like future devices which do Daala in hardware, but
don't have sufficient resources to do any other codec.  A device
like that could interop with a wide variety of other things,
including WebRTC endpoints that support negotiating that codec, but
it wouldn't itself be a card carrying WebRTC endpoint that provides
the guaranteed interop and full functionality which being one does.

It's not clear to me how this poses any sort of problem that we
need to address beyond what is currently proposed for them?

  Ron