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

Randell Jesup <randell-ietf@jesup.org> Wed, 10 December 2014 22:32 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03F41AC3A7 for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 14:32:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp1bA9PPpsow for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 14:32:52 -0800 (PST)
Received: from relay.mailchannels.net (aso-006-i440.relay.mailchannels.net [23.91.64.121]) by ietfa.amsl.com (Postfix) with ESMTP id 405611AC3A5 for <rtcweb@ietf.org>; Wed, 10 Dec 2014 14:32:40 -0800 (PST)
X-Sender-Id: wwwh|x-authuser|randell@jesup.org
Received: from r2-chicago.webserversystems.com (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id D1A65604A4 for <rtcweb@ietf.org>; Wed, 10 Dec 2014 22:32:38 +0000 (UTC)
X-Sender-Id: wwwh|x-authuser|randell@jesup.org
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.248.11.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Wed, 10 Dec 2014 22:32:39 GMT
X-MC-Relay: Neutral
X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org
X-MailChannels-Auth-Id: wwwh
X-MC-Loop-Signature: 1418250759168:4047187328
X-MC-Ingress-Time: 1418250759167
Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:54937 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1XypoD-000Aip-NS for rtcweb@ietf.org; Wed, 10 Dec 2014 16:32:37 -0600
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
X-AuthUser: randell@jesup.org
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)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 22:32:56 -0000

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