Message-ID: <5488CA03.6060805@jesup.org>
Date: Wed, 10 Dec 2014 17:32:35 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com>
 <CAPF_GTaJwaS9+9uSSGTC1+RqKb=uF8UQxsP4u5jPJiRi=88-Nw@mail.gmail.com>
 <CAOW+2dvGH6jEp072GxfQwZ=O_QaxZpTrq3bgd2A-gOMj2PL9ZQ@mail.gmail.com>
 <CABcZeBPw+JoXmHM_nH=ZF6zWfMpw_V1MLZU=hD6kac8qv_Z5eQ@mail.gmail.com>
 <CAOW+2dsv9W9_x+RroLdsAKyhNAFGGdCTm9P3BMf1_L0XzB8UBQ@mail.gmail.com>
 <20141210012208.GK19538@hex.shelbyville.oz>
 <E425BA63-1BF0-4E51-AC4E-453A9E04C60F@apple.com>
In-Reply-To: <E425BA63-1BF0-4E51-AC4E-453A9E04C60F@apple.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZT13ozdHwSlz5501alE7s9RHQRQ
Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of
 the room: mti codec)
Precedence: list

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 t=
he baby=E2=80=99s room) and doesn=E2=80=99t do video, I would hope that i=
t could claim to be a webRTC endpoint, no?  Similarly for a silent survei=
llance camera =E2=80=94 audio codec requirements are irrelevant because i=
t doesn=E2=80=99t do audio at all.

Or one that does decode only (monitor viewer) or encode only (monitor=20
sender).  These wouldn't full WebRTC endpoint, but could be=20
webrtc-compatible.

> The codec requirements are effectively conditional on supporting the me=
dia. I suppose we could state that, and suggest that a webRTC endpoint th=
at 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=20
audio nor video could certainly exist.  (And might to do p2p data stuff=20
leveraging all the NAT-traversal/encryption/etc infra we've defined.)

I wanted/want VP8 only.  But I think this compromise (which is imperfect=20
from everyone's definition) fits the meaning of compromise well.  No one=20
will leave really "happy"; some may leave upset, but I think it's the=20
best we can get and better than status quo.  And I agree with Adam on=20
one point: Ron@debian has made some very good arguments (that I largely=20
agreed with) over this years-long discussion, in a very principled way. =20
If he can bring himself to accept this, what's stopping others?  I=20
realize some companies have stakes (financial, code, etc) in one side or=20
the other, but this is the IETF and people participate as individuals. =20
The people participating from Mozilla have definitely not all "voted"=20
the same way during this process, for example.

--=20
Randell Jesup -- rjesup a t mozilla d o t com