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

David Singer <singer@apple.com> Wed, 10 December 2014 21:50 UTC

Return-Path: <singer@apple.com>
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 AE1EF1A89AF for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 13:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2RySi_j8FxRj for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 13:50:51 -0800 (PST)
Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D511A89A3 for <rtcweb@ietf.org>; Wed, 10 Dec 2014 13:50:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418248251; x=2282161851; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HeUIuIaY/o1e+v4TgpB+p8ceshCvdov5g5FgUvCmDLA=; b=ILG9gvl8w9Wi4w1qqRREbj7AbzPrgDXwD36UU2bZAWNpulzJ9NA3iLylCU5cn3V9 WKBJ3I4SYIGthwtolIs1HcKgdYksNtBUoJY6Diu8upwhZnA3SYf6bdL94gF0sw5s 7ckK28XpGBZsBkqwi4UYQnvSukHm/zRDdwgSPYjqc+Iqn/iwiIC+bRkxdc/TgsMf pBJb7ra4mvghL/KFqaWun69laZT8j6fMlmDRU24/vnBcT4/VgBFnMQUbyJL31URd ghj/3i9Lg8wGaDMckBmIyS7n/YTAgk31ocXB0OBXJLXMIQN5o6G6j5T2m6UHlIOK OYHD2i6klQVGf9IGvvW/ZA==;
Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 3B.FC.06819.B30C8845; Wed, 10 Dec 2014 13:50:51 -0800 (PST)
X-AuditID: 11973e13-f79656d000001aa3-be-5488c03b3432
Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id BA.4D.05998.C40C8845; Wed, 10 Dec 2014 13:51:08 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGD002JPZCQNK10@marigold.apple.com> for rtcweb@ietf.org; Wed, 10 Dec 2014 13:50:51 -0800 (PST)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: David Singer <singer@apple.com>
In-reply-to: <20141210200027.GM19538@hex.shelbyville.oz>
Date: Wed, 10 Dec 2014 13:50:50 -0800
Content-transfer-encoding: quoted-printable
Message-id: <F233B756-AF95-4DE0-B974-67AE552534E1@apple.com>
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> <20141210200027.GM19538@hex.shelbyville.oz>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1993)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAYrmt9oCPEYM4OaYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseHeBPaCNrmKWf+3MzcwTpXoYuTgkBAwkdj3WKiLkRPIFJO4 cG89WxcjF4eQwF5GiQdLP7NDJEwkfq3/zwyRmMQk0b1lH5Qzn0niwMbjjCCTmAXUJaZMyQVp 4BXQk2h68pgJJCwsYCux9XoQSJhNQFXiwZxjYNWcAhYSh/qDQcIsQOFve1Yxg9jMAtoST95d YIWYYiPRcH8aWFxI4BmzxI4f8SC2iICwxNZXvUwQp8lK/Lt4hh3kGgmBp6wS5/uWM09gFJqF cNAsJAfNQrJiASPzKkah3MTMHN3MPFO9xIKCnFS95PzcTYygQJ1uJ7yD8fQqq0OMAhyMSjy8 K662hwixJpYVV+YeYpTmYFES5z2yGygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMTLV6OXJ /+K33t6rVru0WniS1pL7L69nv1m4UDz5GO/lFxMnlx14W3uh+UXyC5n/ApHVVmf++66SXDYn 76lX15mS2yseRSWn3rJfvfnEpAtVHBbvr0f4MvvaGUmu0ZFQ5C76vKWJ92Dkz6tTomsmxMa/ /idXXpt66ex5zcNRe8VanHv0T7V8KFFiKc5INNRiLipOBABp7O/LNQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FDcoutzoCPEYMF/G4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseHeBPaCNrmKWf+3MzcwTpXoYuTkkBAwkfi1/j8zhC0mceHe erYuRi4OIYFJTBLdW/YxQzjzmSQObDzO2MXIwcEsoC4xZUouSAOvgJ5E05PHTCBhYQFbia3X g0DCbAKqEg/mHAOr5hSwkDjUHwwSZgEKf9uzCmwVs4C2xJN3F1ghpthINNyfBhYXEnjGLLHj RzyILSIgLLH1VS8TxGmyEv8unmGfwMg/C+GGWUhumIVk6gJG5lWMAkWpOYmVJnqJBQU5qXrJ +bmbGMGhVRi+g/HfMqtDjAIcjEo8vCuutocIsSaWFVfmHmKU4GBWEuH9sq0jRIg3JbGyKrUo P76oNCe1+BCjNAeLkjhv87vGECGB9MSS1OzU1ILUIpgsEwenVAOj2AebB0Wdmx9zJMSxPnn4 9iO/57I/Wr//1yfnR7zYqXIrmsOd9cC/DcJh0oUKohx+kSyX/vLP+5LSkufJlCBz4dTM36zL 8oK/LRMXdLXd83iNRJ7QO98bhusulR1SOjX5fOW8gy/S6gpPTHLP3696a+fGmevFDW94/9kl 9fLe0my+G0JZIXH6SizFGYmGWsxFxYkAwc5slSkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Jgaz5Wy1Fv9RBh3Z57YSEwqZCsM
Subject: Re: [rtcweb] 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 21:50:53 -0000

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 <ron@debian.org> wrote:
> 
> On Wed, Dec 10, 2014 at 11:15:48AM -0800, David Singer wrote:
>> 
>>> On Dec 9, 2014, at 17:22 , Ron <ron@debian.org> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Manager, Software Standards, Apple Inc.