Re: [rtcweb] WebRTC endpoint categories

Sergio Garcia Murillo <> Wed, 10 December 2014 23:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 16D011A1B32 for <>; Wed, 10 Dec 2014 15:21:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 94NIQ7q1lJn8 for <>; Wed, 10 Dec 2014 15:21:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 600801A0105 for <>; Wed, 10 Dec 2014 15:21:50 -0800 (PST)
Received: by with SMTP id ex7so6886223wid.0 for <>; Wed, 10 Dec 2014 15:21:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SsCfd404y9ybpyG7e53OdYsf77ciULQhzw+qeRzMBuA=; b=iTCJHQxBOdbTdbSdu0uDQ+9yLnNR3U7AGbedDWax2syj4bdVBFbhZsZlIDCol2RY6n k5ri2AHDsKIsJyxljyPW0x2y9BH0uQcnL5nyW0K+6YCFPoPiCf0Ls5z3i+yu5/EJZs4G mzpTGThU3l5R/y6VCo/5EXjcUu+rYxV2nwqyE6zGq/jfWqjI1IPgQ7Zvtm3qEp0oeQ2P f1PHk7JsYKRWuj9BZybLTYeK3w2rnQ+8kmRe4h6SzScieAVjJia54SHeBXtFF5l0KPPD 0sgb4+34s5IbxkQ7CdeK1McuPcVheTN7Fp2OU0nTL6gXRZ7EiCCPNmHgcOXycPeDb3fX 8CWA==
X-Received: by with SMTP id pd7mr17422680wic.21.1418253709141; Wed, 10 Dec 2014 15:21:49 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id cz3sm7666615wjb.23.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 15:21:48 -0800 (PST)
Message-ID: <>
Date: Thu, 11 Dec 2014 00:21:47 +0100
From: Sergio Garcia Murillo <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <> <> <> <20141210012208.GK19538@hex.shelbyville.oz> <> <20141210200027.GM19538@hex.shelbyville.oz> <> <20141210230012.GN19538@hex.shelbyville.oz>
In-Reply-To: <20141210230012.GN19538@hex.shelbyville.oz>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] WebRTC endpoint categories
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 23:21:52 -0000

On 11/12/2014 0:00, Ron wrote:
> [Changing the subject of this thread as requested earlier]
> On Wed, Dec 10, 2014 at 01:50:50PM -0800, David Singer wrote:
>> 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?
> I'm afraid I'm missing the crux of the distinction you see if you think
> we're not just agreeing with each other now :)
> A device is a WebRTC endpoint (browser or not) if it implements the
> mandatory requirements of the WebRTC protocol (which includes MTI
> codecs).
> Anything which doesn't do that, but can otherwise do some subset of
> WebRTC to operate with WebRTC endpoints, in some unspecified here way,
> is in the WebRTC-compatible class of devices.  Whatever we end up
> calling those, if the definition remains the same, they can do anything
> they please, however they please, which obviously video and audio is a
> subset of.  I don't see how we could sensibly say they must not do
> either of those things at all, when the definition says they are not
> constrained by, or defined in, or implementations of, this spec.
> There's no confusion about the expectations for interop though, because
> they are "non-WebRTC" devices, so nothing at all can be expected except
> what the device itself says it is actually capable of.  They might
> implement some melange of various standards or they might be an entirely
> proprietary thing.  The IETF isn't really concerned with marketing
> appellations, these classes are just language to use in the spec itself
> when we need to say something referring to these categories of things.
> A device which doesn't implement the WebRTC protocol, doesn't implement
> the WebRTC protocol.  It doesn't really matter what its reasons for that
> might be, or what other things it does implement.  Does it?
> If I implement a protocol that shares the same first 8 octets with an
> IPv4 header, that doesn't mean I have implemented RFC 791.

+1 It is quite difficult to not agree with anything that Ron says.. :)

Also, I hear some people complaining about the definition of a WebRTC 
compatible endpoint, but it would be good if those people expose what 
are the changes that they want to introduce:
  -Remove webrtc compatible endpoints mentions from spec
  -Change definition of a webrtc compatible endpoint
  -Mandate webrtc compatible enpoints to implement both MTI video codecs

Best regards