Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec)

[Randell Jesup <[e-mail]>]

Moving to the other thread for clarity...

On 12/10/2014 2:15 PM, David Singer wrote:
> 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.

Or one that does decode only (monitor viewer) or encode only (monitor 
sender).  These wouldn't full WebRTC endpoint, but could be 
webrtc-compatible.

> The codec requirements are effectively conditional on supporting the media. I suppose we could state that, and suggest that a webRTC endpoint that does neither video nor audio is at best an odd duck, but I thought it was fairly obvious.

A WebRTC-compatible endpoint that implements DataChannels but neither 
audio nor video could certainly exist.  (And might to do p2p data stuff 
leveraging all the NAT-traversal/encryption/etc infra we've defined.)

I wanted/want VP8 only.  But I think this compromise (which is imperfect 
from everyone's definition) fits the meaning of compromise well.  No one 
will leave really "happy"; some may leave upset, but I think it's the 
best we can get and better than status quo.  And I agree with Adam on 
one point: Ron@debian has made some very good arguments (that I largely 
agreed with) over this years-long discussion, in a very principled way.  
If he can bring himself to accept this, what's stopping others?  I 
realize some companies have stakes (financial, code, etc) in one side or 
the other, but this is the IETF and people participate as individuals.  
The people participating from Mozilla have definitely not all "voted" 
the same way during this process, for example.

-- 
Randell Jesup -- rjesup a t mozilla d o t com