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

Gaelle Martin-Cocher <> Wed, 10 December 2014 18:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8FDDB1A8763 for <>; Wed, 10 Dec 2014 10:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2EZSabrguQuD for <>; Wed, 10 Dec 2014 09:59:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A15731A00BD for <>; Wed, 10 Dec 2014 09:59:56 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 10 Dec 2014 12:59:48 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 10 Dec 2014 12:59:48 -0500
Received: from ([fe80::fcd6:cc6c:9e0b:25bc]) by ([::1]) with mapi id 14.03.0210.002; Wed, 10 Dec 2014 12:59:47 -0500
From: Gaelle Martin-Cocher <>
To: Christer Holmberg <>, Sergio Garcia Murillo <>, "" <>
Thread-Topic: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec)
Thread-Index: AQHQFInbVBWK6YoLoEyBNpmZ4G+pQ5yJZckA//+unHA=
Date: Wed, 10 Dec 2014 17:59:47 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF35E6EFXMB111CNCrimnet_"
MIME-Version: 1.0
Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: 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 18:00:04 -0000

The main problem is with what the terminology covers and its inconsistent usage.

The WebRTC gateway in is defined as a WebRTC-compatible endpoint with some requirements being applied to it.
I am not sure how the last sentence in the WebRTC-compatible endpoint definition  “It is not constrained by this specification…”  applies to the gateway.

If a mobile app is centered around text or text and audio, it should not be relegated in the WebRTC-compatible endpoint category and should be able to benefit from the WebRTC non browser/endpoint terminology .

If a WebRTC-compatible endpoint supports everything but a subset of functions (e.g. does not support bundle)  there could be requirements applied to it; in IETF or in other standardization groups that are referring to the IETF terminology.

I don’t think it is fine to have in a specification an unclear category in which both ‘meaningful’ entities (gateway, current WebRTC librairies, the above examples or Ron’s coffee maker) and possibly some sub-standard “things” belong.

One way would be to defined the minimum requirements for a WebRTC-compatible endpoint to “successfully communicate with a WebRTC endpoint”.
In addition, the WebRTC gateway could be removed from the WebRTC-compatible endpoint category. There might be enough differences to  justify two entities.
Changing the naming of “WebRTC-compatible” to a less confusing term is a cosmetic change (but might be a good thing).


From: rtcweb [] On Behalf Of Christer Holmberg
Sent: Wednesday, December 10, 2014 12:20 PM
To: Sergio Garcia Murillo;
Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec)


Note that Adam didn't define the terminology - he used the terminology defined in the rtcweb-overview document. So, if someone has issues with the terminology, I think those issues should be addressed against that document.



Sent from my Windows Phone
From: Sergio Garcia Murillo<>
Sent: ‎10/‎12/‎2014 16:59
Subject: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec)
Hi Gaelle

It is vague on purpose. What WebRTC does in regards of "WebRTC compatible endpoints" is just describing a reality, there will be some entities that do not comply with the WebRTC specs, but still are able to speak with WebRTC devices/browsers/endpoints/gateways because they implement a set of specs that WebRTC is built upon.

So you can either ignore them, or assume that they are in the wild outside and describe how they look like and how they could interact with WebRTC. And, by definition, you can't put any kind of requirement to entities that do comply with the spec.

Best regards

On 10/12/2014 15:47, Gaelle Martin-Cocher wrote:
The vagueness of the WebRTC-compatible endpoint definition and the feature set it covers is worrisome.
It is introducing sub-standards within a specification.
The various discussions show that we have been essentially looking at it either as containing  all features but one codec, or the feature set needed for a gateway. That category could covers something that does only does 15% of WebRTC. It might “successfully communicate with a WebRTC endpoint” but what does it means?
How painful will that be to deal with such endpoint, assuming it somewhat connects to your own product?

It might be more appropriate to relax requirements for both the WebRTC gateway and a new entity than having such a vague category.

From: rtcweb [] On Behalf Of Eric Rescorla
Sent: Wednesday, December 10, 2014 6:18 AM
To: Bernard Aboba
Subject: Re: [rtcweb] confirming sense of the room: mti codec

On Wed, Dec 10, 2014 at 2:03 AM, 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"?

Well, this seems like a generic complaint about the term "compatible", since such
endpoints are explicitly not required to meet any requirements:

     A WebRTC-compatible endpoint is an endpoint that is able to

      successfully communicate with a WebRTC endpoint, but may fail to

      meet some requirements of a WebRTC endpoint.  This may limit where

      in the network such an endpoint can be attached, or may limit the

      security guarantees that it offers to others.  It is not

      constrained by this specification; when it is mentioned at all, it

      is to note the implications on WebRTC-compatible endpoints of the

      requirements placed on WebRTC endpoints.

So, perhaps we need a new term, but this doesn't seem like an issue limited to

video codecs


On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <<>> wrote:

On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <<>> wrote:
Allowing an endpoint that implements video to call itself "WebRTC compliant" without implementing either of the MTI codecs is so wrong-headed that I am at a loss for words.

I believe you have misread the proposal. The term "WebRTC compliant" never appears
anywhere in Indeed, the word
"compliant" does not appear.

Rather, endpoints which implement neither codec qualify as "WebRTC Compatible".


On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <<>> wrote:
Thanks Sean,

We can not support this draft at this time.

As RTC SDK vendors we very likely will support both codecs, but we can not stand by a decision that will "impose" dual MTI on our developer community.

According to this, every dev must use both codecs for every app that is built using our tools. Codec selection should be their choice and not be forced upon them. This seems to be a rather unreasonable expectation.

Erik Lagerway<> | Hookflash<> | 1 (855) Hookflash ext. 2 | Twitter<> | Blog<>

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <<>> wrote:

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise."  The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I’m paraphrasing here), which I’ll take the liberty of categorizing as IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particular organization feels comfortable with including in their browser implementations.

Response:  IPR concerns on this topic are well known.  There is even a draft summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litigation.  The sense of the room was still that adopting the compromise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting was provided on short notice and did not provide some the opportunity to attend in person.

Response:  Six months ago the chairs made it clear discussion would be revisited @ IETF 91 [0]. The first agenda proposal for the WG included this topic [1], and the topic was never removed by the chairs.    More importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was among the options in the straw poll conducted more than six months ago.  All decisions are confirmed on list so there will be ample time to discuss the proposal.

3) Trigger:

Objection: The “trigger” sentence [3] is all kinds of wrong because it’s promising that the future IETF will update this specification.

Response: Like any IETF proposal, an RFC that documents the current proposal can be changed through the consensus process at any other time.

After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shove”) the proposed text into draft-ietf-rtcweb-video.  In keeping with IETF process, I am confirming this consensus call on the list.

If anyone has any other issues that they would like to raise please do by December 19th.

spt (as chair)

[3] The one that begins with "If compelling evidence ..."