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

Ron <> Wed, 10 December 2014 20:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 988871A8BBE for <>; Wed, 10 Dec 2014 12:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nGbstwl08t-t for <>; Wed, 10 Dec 2014 12:00:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 12BC51A89D3 for <>; Wed, 10 Dec 2014 12:00:29 -0800 (PST)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 11 Dec 2014 06:30:29 +1030
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id E85B1FFCCA for <>; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id Ku65XhuI_tub for <>; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 54469FF841 for <>; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 4090680470; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT)
Date: Thu, 11 Dec 2014 06:30:27 +1030
From: Ron <>
Message-ID: <20141210200027.GM19538@hex.shelbyville.oz>
References: <> <> <> <> <> <20141210012208.GK19538@hex.shelbyville.oz> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Dec 2014 20:00:38 -0000

On Wed, Dec 10, 2014 at 11:15:48AM -0800, David Singer wrote:
> > On Dec 9, 2014, at 17:22 , Ron <> 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?