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

[David Singer <[e-mail]>]

Hi Ron

I don’t think we need to change definitions. In some specs, there is an explicit “if the device supports the audio media type, it must…” and I took it as implicit that that was the case for the codecs for a given media type here. Users would not expect a device that states it doesn’t do audio to interop on audio.  But if a device claims to be a general-purpose device that supports audio and video in webRTC, I think we’d all like it if it actually interoperated, right? Isn’t that the main thrust of looking for MTI codecs?

Yes, of course there is always room for experimental devices, or devices intended for more controlled environments (‘we use the webrtc protocols but only the theora codec’ etc.), but they are then rather qualified in their claims. “Only suitable for use in…”, “experimental, not general purpose…” and so on.



> On Dec 10, 2014, at 12:00 , Ron <[e-mail]> wrote:
> 
> 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
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Manager, Software Standards, Apple Inc.