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

From: Sean Turner <[email-masked]>
Date: Fri, 5 Dec 2014 08:36:30 -0500

All,

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.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Dec 2014 11:21:43 -0800

> 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-i…

I believe it should go without saying, but I agree with the room consensus.

/a

---

From: "Krasimir D. Kolarov" <[email-masked]>
Date: Fri, 05 Dec 2014 11:22:28 -0800

To re-iterate what I said at the mike during the meeting, at this point we can not support this draft, due to the existence of “unwilling to license" declaration on a technology required for compliance. The discussion on point 1 below during the meeting and on the list has not changed that situation.

Krasimir

> On Dec 5, 2014, at 5:36 AM, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 5 Dec 2014 11:41:29 -0800

I also do not support the draft proposal for the following reasons:

1. The proposal imposes a dual MTI obligation on devices and
applications.  We should expect this recommendation to be widely ignored in
practice because it offers no interoperability benefits, while increasing
footprint and adding unnecessary liability/fees. The RFC 6919 "MUST (BUT WE
KNOW YOU WON'T)" is appropriate here.  Definition:

   The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate
   requirements that are needed to meet formal review criteria (e.g.,
   mandatory-to-implement security mechanisms), when these mechanisms
   are too inconvenient for implementers to actually implement.

2. The codec standardization process is important from a legal and IPR
disclosure point of view.  VP8 has not yet completed this process.

On Fri, Dec 5, 2014 at 11:22 AM, Krasimir D. Kolarov <[email-masked]>
wrote:

> To re-iterate what I said at the mike during the meeting, at this point we
> can not support this draft, due to the existence of “unwilling to license"
> declaration on a technology required for compliance. The discussion on
> point 1 below during the meeting and on the list has not changed that
> situation.
>
> Krasimir
>
>
> > 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]).
> >
> > 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:
> >
> > 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.
> >
> > 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.
> >

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 05 Dec 2014 14:58:44 -0500

Considering that:
1) We have committed to an MTI video codec
2) All consensus calls on "VP8 only" and "H.264 only" have failed
3) This is the only proposal that gets support from both camps
I strongly support this MTI proposal.
Please, let's close this debate once and for all. This compromise is
by no means great, but it's much better than anything else we're going
to get otherwise (i.e. more wasted time and still no MTI).

	Jean-Marc

On 05/12/14 08:36 AM, Sean Turner wrote:
> All,
> 
> 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]).
> 
> 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:
> 
> 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:
> 
> 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.
> 
> 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.
> 
> Cheers, spt (as chair)
> [0] 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
> [1] 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
> [2] 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
> [3] The one that begins with "If compelling evidence ..." [4] 
> http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf 
> _______________________________________________ rtcweb mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Dec 2014 19:59:20 +0000

In that case you are agreeing with something that did not happen. By no stretch of the imagination can the result of the RTCWEB session be declared as "consensus".

The chairman declared "rough consensus" in the room, which is an entirely different concept.

Keith 

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 05 December 2014 19:22
> To: Sean Turner; [email-masked]
> Subject: Re: [rtcweb] confirming sense of the room: mti codec
> 
> > 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.
>

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 5 Dec 2014 13:05:49 -0700

> I strongly support this MTI proposal.

+1

jack.

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 5 Dec 2014 20:18:00 +0000

I don’t support the proposed text either, and +1 on the two points below.

I would like to point out few issues and request that:
(all requests are independent)
a) we have a discussion on mandating codec versus decoder. There was apparently little to no time at the meeting to discuss this and prior discussions on this topic did not include the three categories that are now considered.
b) The browser and non-browser categories  are not bundled together when making the decision. If there is no intention to revisit the browser category, I would propose that non-browser shall support H.264 (reasoning: most if not all apps are WebRTC-compatible endpoints and can do whatever they chose, non-browser is a narrower category which could include devices which have to support H.264 anyway)
c) the revisiting note should not have the same rules for the two codecs, as VP8 proponents are claiming that VP8 is free and AVC proponents are not, instead are claiming AVC is needed for legacy reasons. The note should be revisited before the draft becomes an RFC.

Gaëlle

From: rtcweb [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, December 05, 2014 2:41 PM
To: Krasimir D. Kolarov
Cc: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

1. The proposal imposes a dual MTI obligation on devices and applications.  We should expect this recommendation to be widely ignored in practice because it offers no interoperability benefits, while increasing footprint and adding unnecessary liability/fees. The RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" is appropriate here.  Definition:

2. The codec standardization process is important from a legal and IPR disclosure point of view.  VP8 has not yet completed this process.

On Fri, Dec 5, 2014 at 11:22 AM, Krasimir D. Kolarov <[email-masked]<mailto:[email-masked]>> wrote:
To re-iterate what I said at the mike during the meeting, at this point we can not support this draft, due to the existence of “unwilling to license" declaration on a technology required for compliance. The discussion on point 1 below during the meeting and on the list has not changed that situation.

Krasimir

> On Dec 5, 2014, at 5:36 AM, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
>
> All,
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 5 Dec 2014 21:35:43 +0100

I support the proposal as the lesser of two evils.

That said, it's peculiar and a bit depressing that the only ones that are complaining and keeping on wanting to impose on everybody an encumbered codec represent the only missing major browsers in the field, and so organizations that haven't contributed a single line of code so far to what WebRTC is today. All this talk of RFC6919 makes it quite clear that the "must implement both" will be blatantly ignored by H.264 advocates, and so one way or another they'll win anyway. I doubt that solutions that generate VP8 streams only (maybe because they can only do that), for instance, will be able to succeed in an ecosystem where half of the endpoints support both the codecs and half just one (the wrong one, of course), and the outcome is easy enough to guess.

Lorenzo

On Fri, 5 Dec 2014 08:36:30 -0500

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: David Singer <[email-masked]>
Date: Fri, 05 Dec 2014 15:26:28 -0800

> On Dec 5, 2014, at 11:58 , Jean-Marc Valin <[email-masked]> wrote:

if you could speak only for yourself, and not others, that might be better.  You’re claiming support by other people here.

David Singer
Manager, Software Standards, Apple Inc.

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Dec 2014 17:05:00 -0800

> In that case you are agreeing with something that did not happen. By no stretch of the imagination can the result of the RTCWEB session be declared as "consensus".

I guess I should have picked up from the other thread that it's pedantry 
hour. I'll play one round on-list.

The common English definition I'm familiar with for "consensus" is the 
one described by Merriam-Webster online 1b: " the judgment arrived at by 
most of those concerned."

I recognize that in the game of pedantry, this is simply moving my pawn 
out from its starting ranks at the beginning of the tournament. If you'd 
like to continue the match by, say, quibbling over the meaning of "most" 
in that context, please call me on +1 650 903 0800, extension 863. I'm 
sure this is neither topical for this list, nor of interest to its 
members, and I suspect we can conclude the matter much more quickly in 
real-time.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Dec 2014 17:50:10 -0800

> if you could speak only for yourself, and not others, that might be better.  You’re claiming support by other people here.

If I read Jean-Marc's statement correctly, it's not speaking on behalf 
of other people; it's using what they have already said, on the record 
[1], as a valid part of his rationale.

I'd like to reinforce this sentiment. I support this proposal not 
because I think it is the best solution, but because it is the first MTI 
video codec proposal that the actual implementors in this technology 
space have even remotely agreed on since the discussion began. I support 
this proposal primarily because it is the only solution we have yet seen 
that has a credible chance of succeeding.

That's a powerful reason -- at least, for those people invested in this 
technology -- but it necessarily involves pointing to the positions of 
others. This is not the same as making statements on their behalf, as 
you claim; it is merely acknowledging that they've already made such 
statements.

/a

____
[1] I'm not going through the effort of gathering citations here, as I 
would expect that you, and all other involved participants, are 
sufficiently familiar with the ongoing conversation to make doing so 
unnecessary. If you'd like to make the claim such positions have *not* 
been asserted by the parties in question, I'll happily point you to a 
trove of relevant emails, meeting minutes, slide decks, and audio 
recordings.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 5 Dec 2014 17:58:00 -0800

I would also distinguish between "I am willing to support dual MTI in our product" and "I have no intention to implement it in our product but am happy to impose the burden on someone else."  

> On Dec 5, 2014, at 3:26 PM, David Singer <[email-masked]> wrote:
> 
>

---

From: David Singer <[email-masked]>
Date: Fri, 05 Dec 2014 17:58:53 -0800

> On Dec 5, 2014, at 17:50 , Adam Roach <[email-masked]> wrote:
> 
> If I read Jean-Marc's statement correctly, it's not speaking on behalf of other people; it's using what they have already said, on the record [1], as a valid part of his rationale.
> 
> I'd like to reinforce this sentiment. I support this proposal not because I think it is the best solution, but because it is the first MTI video codec proposal that the actual implementors in this technology space have even remotely agreed on since the discussion began. I support this proposal primarily because it is the only solution we have yet seen that has a credible chance of succeeding.

OK, we are potential implementor, and so are Blackberry, and we don’t agree. 

You seem to hypothesize two camps only and that this has support of both. You are therefore trying to claim a state of consensus which does not exist.  There was pushback both in the room and on the list.

David Singer

---

From: Andrew Allen <[email-masked]>
Date: Sat, 6 Dec 2014 02:23:02 +0000

Adam,

However if you look at it another way:

A majority of the market share of the desktop browser market (Microsoft and Apple) are against this and a significant share of the mobile browser market (Apple, Microsoft and BlackBerry) are against this.

That doesn’t seem to me as major progress towards consensus by the people who are supposed to actually comply with the two MTI decision in order to ensure interoperability. At least not in the real world of shipping product where it really matters.

Andrew

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Friday, December 05, 2014 8:50 PM
To: David Singer; Jean-Marc Valin
Cc: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

That's a powerful reason -- at least, for those people invested in this technology -- but it necessarily involves pointing to the positions of others. This is not the same as making statements on their behalf, as you claim; it is merely acknowledging that they've already made such statements.

/a

____
[1] I'm not going through the effort of gathering citations here, as I would expect that you, and all other involved participants, are sufficiently familiar with the ongoing conversation to make doing so unnecessary. If you'd like to make the claim such positions have *not* been asserted by the parties in question, I'll happily point you to a trove of relevant emails, meeting minutes, slide decks, and audio recordings.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 5 Dec 2014 19:31:59 -0800

On Dec 5, 2014, at 17:50 , Adam Roach <[email-masked]> wrote
>> If I read Jean-Marc's statement correctly, it's not speaking on behalf of other people; it's using what they have already said, on the record [1], as a valid part of his rationale.

[BA] While this does appear to be a statement from an implementer about support in their own product, it does not correctly characterize the nature of the "consensus" as a whole. The "consensus" here did not involve acceptance by RTCWEB implementers of the necessity for them to support both H.264 and VP8.  Had such a proposal been made it most probably would have failed. Instead the "consensus" call involved imposing an obligation on a subset of implementers without their agreement.  There is a term for *that*, but it isn't "consensus" - the 13 colonies called it "taxation without representation".

---

From: cowwoc <[email-masked]>
Date: Sat, 06 Dec 2014 00:09:00 -0500

Andrew,

I don't know where you're getting your numbers from, but according to 
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_table 
Chrome, Firefox and Opera make up the majority market-share on the 
desktop and mobile.

Most sources seem to agree that IE is on the decline, while Safari is 
increasing slowly.

Gili

---

From: Monty Montgomery <[email-masked]>
Date: Fri, 5 Dec 2014 21:27:50 -0800

>There is a term for *that*, but it isn't "consensus" - the 13 colonies called it "taxation without representation".

There's a difference between 'not represented' and 'holding a minority opinion'.

Monty

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 5 Dec 2014 22:01:02 -0800

On Dec 5, 2014, at 9:27 PM, Monty Montgomery <[email-masked]
> There's a difference between 'not represented' and 'holding a minority opinion'.

[BA] Rather than applying equally to all RTCWEB implementers, the dual MTI requirement is applied unequally to implementers of a JS API specification created in another SDO.  The W3C gets to decide the requirements for implementers of their specifications, not the IETF. So no, this isn't just an IETF consensus issue.

---

From: Andrew Allen <[email-masked]>
Date: Sat, 6 Dec 2014 08:33:11 +0000

http://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0

http://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=1

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Saturday, December 06, 2014 12:09 AM
To: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

Andrew,

I don't know where you're getting your numbers from, but according to http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_table
Chrome, Firefox and Opera make up the majority market-share on the desktop and mobile.

Most sources seem to agree that IE is on the decline, while Safari is increasing slowly.

Gili

---

From: Maik Merten <[email-masked]>
Date: Sat, 06 Dec 2014 10:16:59 +0100

Am 05.12.2014 um 20:58 schrieb Jean-Marc Valin:
> Considering that: 1) We have committed to an MTI video codec 2) All
> consensus calls on "VP8 only" and "H.264 only" have failed 3) This
> is the only proposal that gets support from both camps I strongly
> support this MTI proposal.

+1

Maik

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 06 Dec 2014 10:38:59 +0100

> A majority of the market share of the desktop browser market (Microsoft and Apple) are against this and a significant share of the mobile browser market (Apple, Microsoft and BlackBerry) are agains…

Please .... if you bring market share into the discussion, tell us which
numbers you are using.

Clearly you are not using StatCounter:

http://gs.statcounter.com/#desktop-browser-ww-monthly-200807-201411

http://gs.statcounter.com/#mobile_browser-ww-monthly-201311-201411

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 06 Dec 2014 04:46:03 -0500

On 05/12/14 10:31 PM, Bernard Aboba wrote:
> [BA] While this does appear to be a statement from an implementer 
> about support in their own product, it does not correctly 
> characterize the nature of the "consensus" as a whole. The 
> "consensus" here did not involve acceptance by RTCWEB implementers
> of the necessity for them to support both H.264 and VP8.  Had such
> a proposal been made it most probably would have failed. Instead
> the "consensus" call involved imposing an obligation on a subset
> of implementers without their agreement.  There is a term for
> *that*, but it isn't "consensus" - the 13 colonies called it
> "taxation without representation".

OK, so it's browsers implementer that matter now? Let's see, the
original position from Google and Mozilla -- who represent more than
50% of the market and (AFAIK) 100% of WebRTC browsers -- was
originally "VP8 or die". Despite that, the "VP8 or die" option failed
the consensus call (as did the "H.264 or die" option). Now, the same
implementers are agreeing to make VP8 *and* H.264 MTI, while rallying
some of the H.264 supporters (obviously not you) and you're still
thinking it's a minority imposing its will on the majority of browser
implementers? I'd like to understand what other outcome you're aiming
for here:
1) Call for consensus on "H.264 or die" until enough people in the
other camp get distracted;
2) No MTI, voice only ought to be good for everyone; or
3) Some other clever compromise we haven't yet heard of

	Jean-Marc

---

From: Andrew Allen <[email-masked]>
Date: Sat, 6 Dec 2014 13:06:09 +0000

Harald

I already stated my source (which I picked at random based on a google search :) ) in a previous email and we could argue about the accuracy of the statistics on one site or another, the statistical trends, what snapshot window in time to take, how to measure it (based on website usage or number of deployed units, etc). 

But I think my point was clear. Several significant players in the browser space that are supposed to implement the video MTI "compromise" are not in support of this "compromise".

Easy to get a hum to support both codecs from other people when they aren't the ones that have to implement both codecs.

Andrew

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Saturday, December 06, 2014 4:39 AM
To: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

> A majority of the market share of the desktop browser market (Microsoft and Apple) are against this and a significant share of the mobile browser market (Apple, Microsoft and BlackBerry) are agains…

Please .... if you bring market share into the discussion, tell us which numbers you are using.

---

From: Adam Roach <[email-masked]>
Date: Sat, 6 Dec 2014 06:00:34 -0800

> On Dec 6, 2014, at 05:06, Andrew Allen <[email-masked]> wrote:
> 
> But I think my point was clear. Several significant players in the browser space that are supposed to implement the video MTI...

Well, there's "supposed to" and then there's "plan to."

https://status.modern.ie/?term=WebRTC%20v1.0

/a

---

From: Adam Roach <[email-masked]>
Date: Sat, 06 Dec 2014 15:30:02 -0600

> OK, we are potential implementor, and so are Blackberry, and we don’t agree.

That's been taken into account. As Keith so helpfully pointed out, what 
was reached in the room was *rough* consensus, and you've made it 
abundantly clear that you're part of the rough.

As *you* pointed out in the other active video-related thread, one 
generally "wouldn’t be here if [one] hadn’t chosen to implement," and it 
was sufficiently clear that people who "were here" in Hawaii thought 
that pursuing this plan was better than not. Lest you think I'm putting 
words in anyone's mouth when I say that, I cite the chairs' declaration 
on the topic rather than claiming my subjective evaluation of the room's 
sense (which would involve several more adjectives than my rather 
subdued statement here).

Keep in mind that this is all being said in the context of making a 
point about why I support this course of action (because I think it has 
a good chance of success), so don't read more than that into it.

> You seem to hypothesize two camps only and that this has support of both.

I'm actually not claiming that it's as simple as two camps; however, I 
think it's pretty fair to say that the participants have historically 
held positions that could be broadly characterized as "pro-VP8" and 
"pro-H.264." My claim is that a non-trivial number of people who have 
historically supported one of those positions to the exclusion of the 
other have expressed a willingness to go along with this plan.

> You are therefore trying to claim a state of consensus which does not exist.  There was pushback both in the room and on the list.

Rough consensus is not the lack of push-back. The IETF would specify 
approximately nothing if all decisions required unanimity.

In terms of the rough accord I'm citing as part of my rationale, I'm far 
more inclined to consider the working group chairs' declaration about 
the sense of the room to be a valid indicator of the positions of 
interested parties than I would yours or even my own.

/a

---

From: David Singer <[email-masked]>
Date: Sat, 06 Dec 2014 17:41:56 -0800

Adam

we are at cross purposes.  I am complaining about a language usage.  When you say “both camps support” you imply (a) that there are only two camps, and everyone is a member of one or other and (b) that they have reached agreement — and therefore we are done. Perhaps you don’t mean it, but it’s a technique some people use to try to give the appearance of an agreement, and given the sensitive nature of the subject, I’d prefer you not do that.

If you say “there was support for the position from several camps”, or somesuch, that would be fine. That leaves room for people to say that they dissent, that’s all.

Got it?

David Singer

---

From: Adam Roach <[email-masked]>
Date: Sat, 06 Dec 2014 21:17:50 -0600

> If you say “there was support for the position from several camps”, or somesuch, that would be fine. That leaves room for people to say that they dissent, that’s all.

Is this the colloquial use of the word "you" to mean "one"? As in "when 
one says 'both camps support'"?

Or are you making a claim that *I* used the phrase "both camps support" 
or something equivalent?

I think if you go looking for something you could quote directly, 
anything that I've said on the topic is far more nuanced than that. But 
I suspect you already know that, since you oddly chose not to quote me 
at all: it's easier to apply a strawman logical fallacy to parody my 
position if you don't provide contrary evidence at the same time.

/a

---

From: David Singer <[email-masked]>
Date: Sun, 07 Dec 2014 09:07:42 -0800

> On Dec 6, 2014, at 19:17 , Adam Roach <[email-masked]> wrote:
> 
> Is this the colloquial use of the word "you" to mean "one"? As in "when one says 'both camps support’"?

Yes, “you” as in the sense of “one”.  Correct, Jean-Marc used the phrase first; but you responded to my message about its use, not him.

David Singer

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 08 Dec 2014 17:05:47 +0100

Since others who were present in the room are repeating their position
on the list, I'll do so too.

I support the rough consensus as presented by the chair.

---

From: Mohammed Raad <[email-masked]>
Date: Mon, 8 Dec 2014 19:12:11 +0200

I also support the rough consensus reached by those attending the meeting.

Mohammed

-- 
Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 414451478
Email: [email-masked]

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 08 Dec 2014 09:22:43 -0800

+1

I had hoped to spare people's inboxes, but for the convenience of the 
chairs, everything I said in 
<https://www.ietf.org/mail-archive/web/rtcweb/current/msg13443.html> 
still applies to this thread.

---

From: Nathan Egge <[email-masked]>
Date: Mon, 08 Dec 2014 12:24:10 -0500

+1

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Dec 2014 09:27:04 -0800

> on the list, I'll do so too.

That's probably a good thing to do.  An almost anonymous humming sound
isn't a good basis for establishing a record.

+1

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Dec 2014 09:39:55 -0800

As stated before - I think this plan represents a legitimate compromise in
what had previously seemed like a stalemate. While not my ideal outcome, I
think this is good for the WebRTC ecosystem - it ensures interoperability,
and provides a reasonably clear path for reaching a completely RF solution.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Dec 2014 09:44:25 -0800

> and provides a reasonably clear path for reaching a completely RF solution.

"It has been said that democracy is the worst form of government
except all the others that have been tried."

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Dec 2014 12:55:51 -0500

> to get otherwise (i.e. more wasted time and still no MTI).

+1 - it's by no means my preferred solution, but it's one I can live 
with, and better than the alternative of the status-quo - no MTI at 
all.  If it wasn't for OpenH264, my answer would be different.

I can't see adopting H.264 as sole MTI, and I can't see that we'd get 
consensus to adopt VP8 as sole MTI.  That basically leaves stone knives 
and bear skins (aka H.261) just to claim we have MTI, nothing (wild 
west), or this.  (Unless magically MPEG-LA changes their mind - in which 
case that might trigger the kickout here.)

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Dec 2014 19:00:28 +0100

2014-12-08 18:55 GMT+01:00 Randell Jesup <[email-masked]>:
> +1 - it's by no means my preferred solution, but it's one I can live with,
> and better than the alternative of the status-quo - no MTI at all.  If it
> wasn't for OpenH264, my answer would be different.
>
> consensus to adopt VP8 as sole MTI.

There was a much better solution:

- Don't make VP8 nor H264 MTI.
- So for now no MTI video codec.
- And a W3C compromise: First video codec 100% royalty free would
become MTI in WebRTC.

Things would be exactly as they are now, but at least we avoid a
"MUST" that will be ignored by 50% of the market.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Mon, 8 Dec 2014 18:14:38 +0000

+1      ...fully support the consensus, even if rough and non-unanimous

Chris Cavigioli
Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Communications Group (MCG)
*
This e-mail may contain confidential and privileged material for the sole use of the intended recipient(s).  Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Randell Jesup
Sent: Monday, December 08, 2014 9:56 AM
To: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

> 3) This is the only proposal that gets support from both camps I

> strongly support this MTI proposal.

with, and better than the alternative of the status-quo - no MTI at all.  If it wasn't for OpenH264, my answer would be different.

I can't see adopting H.264 as sole MTI, and I can't see that we'd get consensus to adopt VP8 as sole MTI.  That basically leaves stone knives and bear skins (aka H.261) just to claim we have MTI, nothing (wild west), or this.  (Unless magically MPEG-LA changes their mind - in which case that might trigger the kickout here.)

--

rtcweb mailing list

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Dec 2014 13:30:52 -0500

_____________
Roman Shpount

---

From: Andrew Allen <[email-masked]>
Date: Mon, 8 Dec 2014 18:34:58 +0000

I think it’s pretty clear from my statements in the IETF session on this topic and on this list that I don’t support having two MTI  video codecs for any WebRTC entity and I don’t think it is technically justified. But I state this here formally.

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Monday, December 08, 2014 1:31 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

_____________
Roman Shpount

On Mon, Dec 8, 2014 at 11:05 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
Since others who were present in the room are repeating their position
on the list, I'll do so too.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 08 Dec 2014 11:51:04 -0700

On 12/8/14, 11:34 AM, Andrew Allen wrote:
> I think it’s pretty clear from my statements in the IETF session on this
> topic and on this list that I don’t support having two MTI  video codecs
> for any WebRTC entity and I don’t think it is technically justified. But
> I state this here formally.

To those (not just Andrew) who are opposed to two MTI video codecs: were 
you also opposed to two MTI audio codecs? I'm trying to understand the 
differences between audio and video here...

Peter

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Dec 2014 20:05:32 +0100

Just to reiterate what I said in the room, I agree with this.

-Ekr

On Mon, Dec 8, 2014 at 6:39 PM, Justin Uberti <[email-masked]> wrote:

> As stated before - I think this plan represents a legitimate compromise
> in what had previously seemed like a stalemate. While not my ideal outcome,
> I think this is good for the WebRTC ecosystem - it ensures
> interoperability, and provides a reasonably clear path for reaching a
> completely RF solution.
>

---

From: Nathan Egge <[email-masked]>
Date: Mon, 08 Dec 2014 12:21:06 -0500

+1

---

From: Gustavo Garcia <[email-masked]>
Date: Mon, 8 Dec 2014 11:33:19 -0800

I support the rough consensus too (this is the least-worst option)

---

From: Tim Panton <[email-masked]>
Date: Mon, 8 Dec 2014 20:07:18 +0000

> On 8 Dec 2014, at 17:39, Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
> 
> As stated before - I think this plan represents a legitimate compromise in what had previously seemed like a stalemate. While not my ideal outcome, I think this is good for the WebRTC ecosystem - it ensures interoperability, and provides a reasonably clear path for reaching a completely RF solution.
> 
> On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> On 8 December 2014 at 08:05, Harald Alvestrand <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> ____

+1

P.S. 
(Why are we still having this discussion? I feel like I fell into a time vortex and wiped out 18 months of progress)

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 9 Dec 2014 07:17:23 +1100

I wasn't at the meeting, but I too support the compromise. It's non
optimal, but pragmatic and all that's achievable in the given circumstances.

Best Regards,
Silvia.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 08 Dec 2014 13:31:14 -0700

I support the rough consensus reached during the meeting..

> This message serves to confirm the sense of the room.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 8 Dec 2014 20:42:23 +0000

I support the rough consensus reached in the meeting. I support those
willing to accept this compromise, and agree with the chair declaring that
was the dominant sense of the room. I also support those unable to
implement this compromise at this time for their stated reasons, in the
sense that I understand their reasons for their reasonable positions.
Despite the potential future importance of the current minority positions,
I think proceeding with this compromise propels WebRTC forward on an
important issue, because no other proposal has come remotely close to
achieving even rough consensus.

To reiterate another point from the meeting, there are technical
advantages to supporting multiple codecs. Dynamic discovery of local
capabilities, negotiation of remote capabilities, understanding how
different error resilience mechanisms can work (or not) with different
codecs, faster adoption of new (non-mandatory) codecs, easier path to
deprecating old (mandatory) codecs, etc. All those legs never get
exercised effectively in single-codec implementations, leaving land mines
in browsers, apps, services and sometimes even specs. They become easier
or free once the groundwork is laid for multiple codecs. While some have
argued against that extra complexity, I see it as essential for any
important standard.

Mo

On 12/5/14, 8:36 AM, Sean Turner <[email-masked]> wrote:

All,

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:

2) Time:

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.

3) Trigger:

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

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.

Cheers,
spt (as chair)

---

From: Ron <[email-masked]>
Date: Tue, 9 Dec 2014 07:33:20 +1030

> - And a W3C compromise: First video codec 100% royalty free would

We've had a 100% RF codec on the table since the very beginning.
Two if you include the later proposal of H.261 as the MTI fallback.
(three if you include theora ...)

We apparently failed to get consensus on either of those as sole MTI.

I think the consensus that we do have, which at least includes an RF
video codec, is better than perpetuating the chaos of no MTI.  So I
also confirm my support for this as being the consensus of the group.

I still have a tiny candle burning with the hope that the people who
have so far done everything they could to try to thwart having a
single RF MTI codec, will finally come to their senses and pull the
trigger we've given them to enable that to still happen.  But even
if they don't, I think this standard will benefit far more from this
agreement than it would by letting the obstructing factions keep us
locked in a stalemate with no MTI video at all.

  Ever the optimist,
  Ron

> "MUST" that will be ignored by 50% of the market.

I'm not sure I follow your logic here?  Right now 100% of the current
implementations have not ignored this.  That includes something like
75% of the browser user market share.  The rest of the market will do
whatever their market research dept. tells them their customers want
them to do.  This compromise gives the best chance for people who
really are wedged through no fault of their own to be able to produce
something that still will interop with that majority of 'the market'.

The only people currently claiming they are inclined to ignore this
are people who so far have shown no real indication that they are going
to do anything but ignore this standard anyway, regardless of what we
specify about anything.  While the IETF does give everyone a voice to
express real technical concerns and propose solutions, I don't think
it grants a veto to people who simply want to obstruct something they
feel their business is threatened by.  Whatever their "market share".

Anyway, if you want to discuss that (again), we probably ought to move
it off the "sense of the room" thread, so as not to make the hard job
of the chairs even harder :)

---

From: Ron <[email-masked]>
Date: Tue, 9 Dec 2014 08:08:49 +1030

> argued against that extra complexity, I see it as essential for any

I think this might actually be the most sensible and important new
thing anyone has actually said on the list on this topic for a long
time now :)

It gives me that warm fuzzy sense of hope that this is not just a
difficult compromise we've become resigned to, but actually something
with some real technical merits all of its own.  It hadn't really
crossed my mind in this discussion that there'd be some implementers
who really would just ignore the whole negotiation thing to hardcode
only their preferred codec -- which is kind of like saying I'd not
thought about what colour my hair is, I don't have to think for very
long to know what the real world answer to that would be.

Thanks for bringing this up for those of us who didn't make it to
the meeting and have been too busy to watch the recording yet!

  Ron

---

From: Maire Reavy <[email-masked]>
Date: Mon, 08 Dec 2014 16:40:38 -0500

On 12/5/2014 2:58 PM, Jean-Marc Valin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Considering that:
A big +1

We have spent *so* many hours already considering, discussing, & 
debating what to do about the MTI video codec.  One could argue an 
"insane amount" of time relative to the other issues we need to 
resolve.  We did this because most of us realized that "no MTI" could be 
horrific for the standard.  We should embrace consensus around anything 
less than horrific, and most of us agree that this compromise is less 
than horrific (not great, but less than horrific).

Right now I fear we're on the verge of shooting ourselves in the foot or 
head (I'm not sure which) by reopening this discussion even though we're 
in sight of the end.  I ask that the working group and the chairs put 
the proverbially safety back on the gun, declare consensus on this 
less-than-horrific proposal, and finish our work on "v1.0" of the spec.

Please.

-Maire
-------------------------
Maire Reavy
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 8 Dec 2014 14:49:33 -0700

I, too, support the Honolulu compromise.

Simon

---

From: Andrew Allen <[email-masked]>
Date: Mon, 8 Dec 2014 23:28:33 +0000

We are not re-opening this discussion. This list discussion is the decision making process.

What took place in Honolulu was only a consensus hum of those present in the room.

In IETF all decisions are made on the list and it was clearly stated by the chair in Honolulu that the decision would need to be endorsed on the list.

On 1) We have committed to an MTI video codec

I note the small word "an".

If we decide on two MTI video codecs then we have clearly failed to meet this commitment.

On 3) This is the only proposal that gets support from both camps

As David pointed out we are not in two monolithic camps (this isn't the cold war here). Different companies and different individuals have different positions for different reasons. The fact that some people who might have been perceived as being in "one camp" have found a way to agree to a "compromise" based upon a definition that doesn't force them in their product to implement what they don't agree to implement does not mean that the fundamental reason behind the difficulty in reaching consensus on MTI video codecs by those whose products would be forced to implement both codecs has changed.

It's very easy to agree to someone else to have to do something that you are not willing to do yourself.

Andrew

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Maire Reavy
Sent: Monday, December 08, 2014 4:41 PM
To: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

A big +1

We have spent *so* many hours already considering, discussing, & debating what to do about the MTI video codec.  One could argue an "insane amount" of time relative to the other issues we need to resolve.  We did this because most of us realized that "no MTI" could be horrific for the standard.  We should embrace consensus around anything less than horrific, and most of us agree that this compromise is less than horrific (not great, but less than horrific).

Right now I fear we're on the verge of shooting ourselves in the foot or head (I'm not sure which) by reopening this discussion even though we're in sight of the end.  I ask that the working group and the chairs put the proverbially safety back on the gun, declare consensus on this less-than-horrific proposal, and finish our work on "v1.0" of the spec.

Please.

-Maire

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Dec 2014 00:46:15 +0100

> We apparently failed to get consensus on either of those as sole MTI.

My concern is that, regardless companies' interest on certain no RF
codecs, the W3C should mandate some requirements in order to adopt a
MTI codec. IMHO the main requirement should be being a 100% RF codec.
Unfortunately IMHO such a requirement does not exist and here we are,
mandating vendors and other players to implement non RF codecs to be
W3C compliant.

> also confirm my support for this as being the consensus of the group.

That sounds nice, but let's be realistic: will 50% of main vendors
accept this resolution? For me it is clear that they already exposed
their refusal to it. So what is solved here?

> something that still will interop with that majority of 'the market'.

Well, let's imagine both IE and Safari implement WebRTC within the
next 4 months and, as announced, they just support H264. What is the
value of having VP8 as MTI? I mean: a company providing a WebRTC
service will need to implement H264 (because at least the 25% of their
use IE or Safari), so?

It may happen that certain famous applications just allow VP8 so
"customers" will indeed demand Microsoft and Apple to add support for
VP8 in their browsers.

IMHO nothing would change (and this is what I meant) if the WG would
have mandated no MTI video codec. The only difference (and a good one
IMHO) is that vendors and players would not be required to assume
"license / patent risks" in order to conform with a W3C specification.

> of the chairs even harder :)

AFAIU the resolution is already taken, and won't change. I don't want
to spend more time on this (I would prefer to invest it into ORTC
adoption which is the real next step).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Mon, 8 Dec 2014 23:53:53 +0000

I agree with Maire's sentiments.  Let's *please* not re-open this endless discussion.   It is tedious and tiring.   We achieved a consensus decision, and it doesn't have to be unanimous.  Let's declare victory for WebRTC and move on.

Here are 3 things that will never be decided 100% unanimously.  Some things just cannot be.

1.       Electing a president to lead a nation

2.       Deciding on codecs in a standards body

3.       Solving the Israel - Palestine conflict

I propose we work together as global citizens, move forward, get things done, ...

-chris

P.S.  I think we have all realized that there is no such thing as a 100% guaranteed RF codec, especially one that is performant.   Even ones that are declared as RF can always be argued in court...

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: Monday, December 08, 2014 3:29 PM
To: Maire Reavy; [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

Andrew

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>

A big +1

Please.

-Maire

Maire Reavy

[email-masked]<mailto:[email-masked]>

rtcweb mailing list

rtcweb mailing list

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Dec 2014 17:57:13 -0600

> On Dec 8, 2014, at 17:28, Andrew Allen <[email-masked]> wrote:
> 

Do you have a constructive and plausible proposal?

/a

---

From: Andrew Allen <[email-masked]>
Date: Mon, 8 Dec 2014 23:57:49 +0000

We didn't define two audio MTI codecs for interoperability between RTCweb compatible devices. 

We defined OPUS as MTI for interoperability between RTCweb compatible devices and G.711 for interoperability with just about everything else out there (i.e with Legacy). Much to the consternation of some of my colleagues in the mobile industry I have been proactive in the audio codec discussion on resisting IETF defining any additional audio MTI codecs to these two.

Selecting H.264 as the single MTI for video would have fulfilled both the RTCweb interoperability and the legacy interoperability .

It also should be noted that G.711 is trivial to implement and does not have IPR concerns (G.711 is in that respect the equivalent of H.261 in the audio codec world).

Andrew

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Peter Saint-Andre - &yet
Sent: Monday, December 08, 2014 1:51 PM
To: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

On 12/8/14, 11:34 AM, Andrew Allen wrote:
> I think it's pretty clear from my statements in the IETF session on 
> this topic and on this list that I don't support having two MTI  video 
> codecs for any WebRTC entity and I don't think it is technically 
> justified. But I state this here formally.

To those (not just Andrew) who are opposed to two MTI video codecs: were you also opposed to two MTI audio codecs? I'm trying to understand the differences between audio and video here...

Peter

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Dec 2014 16:20:55 -0800

On Mon, Dec 8, 2014 at 3:28 PM, Andrew Allen <[email-masked]> wrote:

> In IETF all decisions are made on the list and it was clearly stated by
> the chair in Honolulu that the decision would need to be endorsed on the
> list.
>

> If we decide on two MTI video codecs then we have clearly failed to meet

Goodness. If you're going to descend to this level of pedantry, at least
look at the charter:

*"6. Define a set of media formats that must or should be supported by a
client to improve interoperability."*

Clearly this compromise is entirely satisfactory in this regard.

> As David pointed out we are not in two monolithic camps (this isn't the
> cold war here). Different companies and different individuals have
> different positions for different reasons. The fact that some people who
> might have been perceived as being in "one camp" have found a way to agree
> to a "compromise" based upon a definition that doesn't force them in their
> product to implement what they don't agree to implement does not mean that
> the fundamental reason behind the difficulty in reaching consensus on MTI
> video codecs by those whose products would be forced to implement both
> codecs has changed.
>
> We have spent *so* many hours already considering, discussing, & debating
> what to do about the MTI video codec.  One could argue an "insane amount"
> of time relative to the other issues we need to resolve.  We did this
> because most of us realized that "no MTI" could be horrific for the
> standard.  We should embrace consensus around anything less than horrific,
> and most of us agree that this compromise is less than horrific (not great,
> but less than horrific).
>
> head (I'm not sure which) by reopening this discussion even though we're in
> sight of the end.  I ask that the working group and the chairs put the
> proverbially safety back on the gun, declare consensus on this

---

From: Andrew Allen <[email-masked]>
Date: Tue, 9 Dec 2014 00:45:03 +0000

Adam

Our preference is for H.264 to be the single MTI. We believe that Cisco's open source royalty free code offer goes a long long way to address the concerns of many related to IPR on H.264 and the prevalence now of APIs to access embedded codecs (such as H.264) on mobile devices goes even further to address those concerns. See http://www.ietf.org/id/draft-burman-rtcweb-h264-proposal-05.txt

We also have proposed as a compromise having 2 MTI decoders but only have to implement one encoder.

I know the above doesn't make everyone happy either. 

But this current proposed "compromise" whilst succeeding in garnering a significant hum in the room is opposed by some rather significant vendors in the browser space. So whilst it may make the RTCWEB Video RFC look pretty and complete it is unlikely to ensure interoperability in the market any more than simply leaving it to the market to decide (which is what will happen if we fail to agree on a single MTI video codec).  Having a standard that is not fully implemented by some of the primary participants in the market does not  bode well for the success of the standard even more than not agreeing on a single MTI codec IMHO. CLUE has agreed not to define MTI codecs but does this mean that telepresence interoperability will be a failure - I think not.

BetaMax vs VHS and Blu Ray vs HD DVD have shown that ultimately the market will resolve these entrenched interoperability issues which are based on business reasons not technical merit without everyone having to agree in a standards body to support both or to support only one.

Andrew

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Monday, December 08, 2014 6:57 PM
To: Andrew Allen
Cc: Maire Reavy; [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

/a

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 9 Dec 2014 06:23:41 +0530

+1 for the rough consensus as presented by the chair and totally in favor
of the novel solution in the spirit of moving RTCweb forward.
Keeping end user's experience in mind and making RTCWeb an interoperable
platform  the consensus reached in Hawaii is a worthy compromise to proceed
further.

Cheers
Suhas

---

From: David Singer <[email-masked]>
Date: Mon, 08 Dec 2014 17:19:24 -0800

> On Dec 8, 2014, at 10:00 , Iñaki Baz Castillo <[email-masked]> wrote:
> 

That would be more honest, indeed. It is effectively where we are going to be.  And it offers a carrot in the right direction.

I am curious to know how many of the people supporting the proposed position actually would implement both encode and decode of both codecs?  This follows from comments on this thread that people who feel they fall into a different category are asking others to solve their problem.

So, rather than +1, please say “I would expect to implement both” (non-binding, of course) — it would be a more useful thing to see, I think.

Another possible choice:

* admit that we already have possible non-interoperability (WebRTC-compatible Endpoints that choose differently), and that anyone who doesn’t want to do both will say that this what they are making (as was suggested):  simply delete the requirement or definitions for WebRTC User-agent and Device. Nothing stops those that want to from implementing both, without or without the mandate.  I don’t think this would make any material difference to what happens, but it makes the spec and reality a little closer.

Finally, I wonder, what would it be like if we actually tried to get closer to interop: ALL endpoints — anything that can operate at one end of a WebRTC session, be it device, UA, gateway, compatible-endpoint, whatever — must be able to decode (actually, offer to receive) both, and must be able to encode at least one?  I’d have to think about the consequences of doing decode-only, but it’s a loss less work than a decent encoder, for a start. This would result in interop if people actually did it.

David Singer

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Tue, 9 Dec 2014 10:41:41 +0800

On Tue, Dec 9, 2014 at 9:19 AM, David Singer <[email-masked]> wrote:

> with,
> That would be more honest, indeed. It is effectively where we are going to
> be.  And it offers a carrot in the right direction.
>
> I am curious to know how many of the people supporting the proposed
> position actually would implement both encode and decode of both codecs?
> This follows from comments on this thread that people who feel they fall
> into a different category are asking others to solve their problem.
>
> So, rather than +1, please say “I would expect to implement both”
> (non-binding, of course) — it would be a more useful thing to see, I think.
>
>
>
> Another possible choice:
>
> * admit that we already have possible non-interoperability
> (WebRTC-compatible Endpoints that choose differently), and that anyone who
> doesn’t want to do both will say that this what they are making (as was
> suggested):  simply delete the requirement or definitions for WebRTC
> User-agent and Device. Nothing stops those that want to from implementing
> both, without or without the mandate.  I don’t think this would make any
> material difference to what happens, but it makes the spec and reality a
> little closer.
>
>
>
> Finally, I wonder, what would it be like if we actually tried to get
> closer to interop: ALL endpoints — anything that can operate at one end of
> a WebRTC session, be it device, UA, gateway, compatible-endpoint, whatever
> — must be able to decode (actually, offer to receive) both, and must be
> able to encode at least one?  I’d have to think about the consequences of
> doing decode-only, but it’s a loss less work than a decent encoder, for a
> start. This would result in interop if people actually did it.
>
>
> David Singer

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Dec 2014 22:18:50 -0500

>> - And a W3C compromise: First video codec 100% royalty free would

And engender endless further discussions about what is "100% royalty 
free".  I'll note that even MPEG-LA deciding to RF baseline H.264 
doesn't mean it's 100% royalty-free (witness Nokia's lawsuits). You can 
never say "100%" with royalties/patents unless something is so old every 
possible patent has expired - and you're still not really safe on your 
encoder even then, unless you use an old, published encoder largely 
unchanged.  I hear we haven't boiled the Indian Ocean yet.... ;-)

> So, rather than +1, please say “I would expect to implement both” (non-binding, of course) — it would be a more useful thing to see, I think.

Easy for me.  Mozilla has already implemented both, and have been 
shipping them for months.

> Finally, I wonder, what would it be like if we actually tried to get closer to interop: ALL endpoints — anything that can operate at one end of a WebRTC session, be it device, UA, gateway, compatib…

That option was floated when we did the survey.  I rated it above many 
others myself (though not as good as vp8-only).  IIRC it didn't do well; 
too many people in the A and not B or B and not A camps.

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Dec 2014 21:44:20 -0600

I see two proposals in your response, both of which have been explored 
already. One is "choice 1" from the straw poll, which garnered only 48% 
support, and the other is "choice 12", which received only 7%.

Which is to say that these are not merely implausible, but demonstrably 
non-viable. So, when I asked whether you had a "constructive and 
plausible proposal," you could have saved us all some time by simply 
saying "no."

/a

---

From: Ron <[email-masked]>
Date: Tue, 9 Dec 2014 14:36:41 +1030

On Tue, Dec 09, 2014 at 12:45:03AM +0000, Andrew Allen wrote:
> 
> Our preference is for H.264 to be the single MTI. We believe that
> Cisco's open source royalty free code offer goes a long long way to
> address the concerns of many related to IPR on H.264 and the
> prevalence now of APIs to access embedded codecs (such as H.264) on
> mobile devices goes even further to address those concerns.

"Our preference is for VP8 to be the single MTI. We believe that
 Google's open source royalty free code offer goes a long long way to
 address the concerns of many related to IPR on H.264 and the
 prevalence now of APIs to access embedded codecs (such as VP8) on
 mobile devices goes even further to address those concerns."

Do you see how this works?  If you don't care about my concerns,
why should I give the smallest rat's about yours?  When your only
argument to dismiss mine is a straw man, and a pretty shabbily
stuffed one at that, then it's going to get torn to shreds by the
cold steel facts of the matter -- because despite the mirrored
expression, those two statements aren't direct equivalents in
their veracity at all once you really look into them.

I'd invite you to (re)read:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13739.html

Repeatedly.  Until you begin to gather some glimmering of understanding
about why it's not the IPR on H.264 that is a problem, it's the crippling
*licence* conditions on it.  And the farce of pretending there's a pool
you can maybe try to licence it from, if they'll even talk to you, when
there are numerous companies outside of it, which also demand you have
separate agreements with them.  It's not just Nokia.  AT&T also has their
own out of pool IPR on H.264.  All of which the people pushing H.264-only
have pretended do not exist and handwaved away every time someone asks.

None of which goes away just because somebody else was kind enough to pay
the first installment of the protection racket bill for you.

You are right that there are more than just these two camps though.
There's also a (clearly large) subset of both that cares enough about
the success of this project to compromise with each other in its best
interests.  With enough options and workarounds to get by until we have
an IETF video codec to solve it properly (and I still do think that
clarifying that is important here.  If we're going to do something as
audacious as mandate a patent minefield like H.264 when there is an
equivalent that actually meets the IETF's aspirational requirements for
RF technology, we need a better reason for that than "some people with
H.264 patents insisted" if it's going to survive being challenged, or
ridiculed, in later review).

It's kind of laughable to describe people who don't share that interest
who've not participated in the implementation and interop testing, who
only seem concerned about their own narrow business interest (which may
well be in direct conflict to the charter of this group) as being some
form of "primary participants" we ought to kowtow to.

If they can't come up with a proposal that is more acceptable than the
current compromise, that doesn't give them a right to veto it.  It just
means they are in the rough.  If they weren't going to implement it
anyway, then nothing changes for them.  If they are, the onus is on them
now to offer something workably constructive.  Stamping your feet and
repeating the same old, tired, thoroughly debunked, chestnuts isn't
actually challenging the emerging consensus at all.

This group formed precisely to avoid the sort of "VHS vs Beta" debacle
that you are proposing as a solution.  I'm not sure why you'd be at all
surprised that the answer to that suggestion is a resounding ...

  Uh. No.

We can't stop you from doing that yourself anyway.  But we can stand
together united behind this group's charter.  And I suspect you know
who'll win that competition if we do ...

  The users.

---

From: Andrew Allen <[email-masked]>
Date: Tue, 9 Dec 2014 04:46:50 +0000

And the 3rd alternative is that we agree that we cannot agree on a single MTI video codec and let the market decide. IMHO the sky will not fall if that ends up being the outcome. There is too much interest in WebRTC for it to fail just because we failed to mandate a single video codec. SIP based communication has had considerable market success without mandating any audio or video codecs and CLUE do not see it necessary to mandate codecs for telepresence.

I believe the current proposal also failed to garner 50% in the original straw poll and IMHO only garners more support now because a way has been found through the use of definitions that immunize many of the parties from being impacted by this decision. Support level for a variant of "choice 12" in tandem with the definitions in the overview document has not yet been polled.

In terms of the parties actually impacted by the decision a significant section of that community still opposes the current proposal. 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Monday, December 08, 2014 10:44 PM
To: Andrew Allen
Cc: Maire Reavy; [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

I see two proposals in your response, both of which have been explored already. One is "choice 1" from the straw poll, which garnered only 48% support, and the other is "choice 12", which received only 7%.

Which is to say that these are not merely implausible, but demonstrably non-viable. So, when I asked whether you had a "constructive and plausible proposal," you could have saved us all some time by simply saying "no."

/a

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Tue, 9 Dec 2014 05:55:23 +0000

I like that proposal, Dave.

+1    INTEL CORP has already implemented both H.264 and VP8 ... both encode and decode.   Done.   

We already demonstrated hardware WebRTC to the public at MWC'14 in Barcelona in February on our smartphone platform.   Done.

We welcome the consensus decision made by IETF and look forward to moving forward with WebRTC.
-chris

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of David Singer
Sent: Monday, December 08, 2014 5:19 PM
To: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

>> +with,
>> and better than the alternative of the status-quo - no MTI at all.  
>> If it wasn't for OpenH264, my answer would be different.
>> 

Another possible choice:

David Singer

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 09 Dec 2014 15:08:43 +0900

+1.   Regards,   Martin.

---

From: Monty Montgomery <[email-masked]>
Date: Tue, 9 Dec 2014 05:11:14 -0500

+1; I agree there was rough consensus (the overwhelming majority
appeared to support the compromise, though there were strong
objections from the remaining minority).

(See also ietfmemes 'Am I the only one here who wants to make a decision?")

My personal position is in favor of the compromise as presented and
hummed.  I don't _like_ it, but it's better than the alternatives,
including doing nothing.

Monty

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 9 Dec 2014 03:03:53 -0800

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <[email-masked]> wrote:

> add (aka “shove”) the proposed text into draft-ietf-rtcweb-video.  In

---

From: Bo Burman <[email-masked]>
Date: Tue, 9 Dec 2014 12:24:27 +0000

+1. I support the rough consensus as presented by the chair.
Best Regards,
Bo

> From: rtcweb [mailto:[email-masked]] On Behalf Of "Martin J. Dürst"
> Sent: den 9 december 2014 07:09
> To: Silvia Pfeiffer; Justin Uberti
> Cc: [email-masked]
> >> As stated before - I think this plan represents a legitimate
> >> compromise in what had previously seemed like a stalemate. While not
> >> my ideal outcome, I think this is good for the WebRTC ecosystem - it
> >> ensures interoperability, and provides a reasonably clear path for
> >> reaching a completely RF solution.
> >>
> >>> On 8 December 2014 at 08:05, Harald Alvestrand
> >>> <[email-masked]>
> >>> wrote:
> >>>> Since others who were present in the room are repeating their
> >>>> position on the list, I'll do so too.
> >>>
> >>> That's probably a good thing to do.  An almost anonymous humming
> >>> sound isn't a good basis for establishing a record.
> >>>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 9 Dec 2014 13:51:59 +0000

+1 I support the compromise plan as presented by the chair.

Also agree with Maire and hope we can put a lid on this and return to useful discussion.

Andy

> Sent: 08 December 2014 21:41
> To: [email-masked]

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 9 Dec 2014 15:28:04 +0100

I support having both VP8 and H.264 as MTI -- however, believe
decision should be revisited not only for non-browsers but also
browsers.

Current text: "To promote the use of non-royalty bearing video codecs,

      participants in the RTCWEB working group, and any successor
      working groups in the IETF, intend to monitor the evolving
      licensing landscape as it pertains to the two mandatory-to-
      implement codecs.  If compelling evidence arises that one of the
      codecs is available for use on a royalty-free basis, the working
      group plans to revisit the question of which codecs are required
      for Non-Browsers, with the intention being that the royalty-free
      codec will remain mandatory to implement, and the other will
      become optional.

      These provisions apply to WebRTC Non-Browsers only.  There is no

      plan to revisit the codecs required for WebRTC Browsers."

-Victor

-- 
Victor Pascual Ávila

---

From: Adam Roach <[email-masked]>
Date: Tue, 09 Dec 2014 10:08:59 -0600

On 12/8/14 22:46, Andrew Allen wrote:
> And the 3rd alternative is that we agree that we cannot agree on a single MTI video codec and let the market decide.

Wait... didn't this subthread start with your objecting to the proposal 
on the grounds that that it failed to meet some commitment to specify 
"an MTI codec"? How do you believe this alternative meets that commitment?

I'm sorry, you're grasping at straws so furiously that you can't even 
argue on the same side of the issue for very long -- but I guess that's 
to be expected when you're simply fast-forwarding through other people's 
old arguments that have been heard and considered by the group already.

It's hard to believe that this is anything but a clumsy attempt at 
targeted obstruction.

/a

---

From: cowwoc <[email-masked]>
Date: Tue, 09 Dec 2014 11:49:08 -0500

Hi Harald,

I am in favor of the compromise as presented by the chair.

(I also second Victor Pascual Avila's suggestion to revisit this 
decision for browsers as well as non-browsers in the future should 
anything of substance change.)

Gili

On 09/12/2014 4:44 AM, Harald Alvestrand wrote:
> I note that the "confirming sense of the room" thread has gotten a lot
> of messages that are not declaring a position on the question.
>
> I also note that from the messages on the thread, I can't figure out if
> Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a
> position (I could guess, but I don't want to - besides, they might not
> want to take a position, which is perfectly OK).
>
> It would be nice for me as a reader if people could:
>
> - state their position on the "confirming sense of the room" thread
> - change the subject line when they want to say anything else
>
> That's my preference - of course, people who have "mute thread" in their
> email readers might want the whole discussion to stay on thread, and
> will hate me for the last suggestion....
>
> Harald
>
>

---

From: John Leslie <[email-masked]>
Date: Tue, 9 Dec 2014 11:57:19 -0500

>       plan to revisit the codecs required for WebRTC Browsers."

   This indeed is quite close to what I remember hearing.

   But the WGC calling consensus is the person who should post it.

   Indeed, I am unable to correctly respond to the consensus-call
without seeing the entire text in question. (It's obvious that many
people posting don't share a single belief of what text they're
agreeing or not agreeing to.)

--
John Leslie <[email-masked]>

---

From: <[email-masked]>
Date: Tue, 9 Dec 2014 17:12:38 +0000

I support the rough consensus as declared by the Chair: 

There is no more "no decision" option and all the work done on this topic and the time and effort spent to achieve this result show there is no more any other possible option.

-----Message d'origine-----
De : rtcweb [mailto:[email-masked]] De la part de Sean Turner
Envoyé : vendredi 5 décembre 2014 14:37
À : [email-masked]
Objet : [rtcweb] confirming sense of the room: mti codec

All,

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:

2) Time:

3) Trigger:

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

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.

Cheers,
spt (as chair)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: David Singer <[email-masked]>
Date: Tue, 09 Dec 2014 09:28:19 -0800

> On Dec 8, 2014, at 15:53 , Cavigioli, Chris <[email-masked]> wrote:
> 
> I agree with Maire’s sentiments.  Let's *please* not re-open this endless discussion.   It is tedious and tiring.   We achieved a consensus decision, and it doesn’t have to be unanimous.  Let’s declare victory for WebRTC and move on.

Because (a) we didn’t; there was a tentative direction selected by the room and (b) it’s not a victory, not even for interop.

> I propose we work together as global citizens, move forward, get things done, …

That would be great.

> -chris
>  
> P.S.  I think we have all realized that there is no such thing as a 100% guaranteed RF codec, especially one that is performant.   Even ones that are declared as RF can always be argued in court…
>  

David Singer

---

From: cowwoc <[email-masked]>
Date: Tue, 09 Dec 2014 13:43:51 -0500

It has come to my attention that I misunderstood the chair proposal. I 
was under the impression that non-browsers were still given the option 
of only implementing one MTI (this was an older proposal).

In light of this, I am withdrawing my support for the compromise as 
presented by the chair. I plan to abstain on this decision.

Thank you,
Gili

---

From: Erik Lagerway <[email-masked]>
Date: Tue, 9 Dec 2014 12:16:07 -0800

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 <http://ca.linkedin.com/in/lagerway> | *Hookflash
<http://hookflash.com/>* | 1 (855) Hookflash ext. 2 | Twitter
<http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> *

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 Dec 2014 12:31:08 -0800

Setting aside my reservations about the dual-MTI requirement for browsers,
I also oppose the other elements of the proposal.

Mandating that applications support both codecs makes no sense - they
should only be required to support one of them (their choice).   If this
change were made the trigger clause would serve no purpose, other than to
keep this discussion going ad-infinitum.  So I oppose that as well.

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 Dec 2014 23:01:04 +0100

> that I am at a loss for words.

I believe you have misread the proposal. The term "WebRTC compliant" never
appears
anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. Indeed,
the word
"compliant" does not appear.

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

-Ekr

>> 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.
>>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 Dec 2014 17:03:34 -0800

My bad.

New question:  How can an endpoint that implements video but none of the
MTI codecs be construed as "WebRTC Compatible"?

On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <[email-masked]> wrote:

> anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03.
> Indeed, the word
>>>> 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
>>>> 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.
>>>>

---

From: Ron <[email-masked]>
Date: Wed, 10 Dec 2014 11:52:08 +1030

> MTI codecs be construed as "WebRTC Compatible"?

And what about an endpoint that implements coffee making, but not audio?

Do you see something in the document that doesn't explain this, or in
Adam's repeated explanations that *this* proposal in no way changes
anything about that?

---

From: Tim Panton <[email-masked]>
Date: Wed, 10 Dec 2014 08:16:01 +0000

> On 10 Dec 2014, at 01:03, Bernard Aboba <[email-masked]> wrote:
> 
> My bad. 
> 
> New question:  How can an endpoint that implements video but none of the MTI codecs be construed as "WebRTC Compatible”? 

At the risk of falling down the semantic trap you set, it could be pushing an experimental webGL based codec over the data channel.
or an art installation. It might implement encode only of one of the MTIs - one way survelliance - or even encode on VP8 and decode on h264
because of some whacky licensing shenanigans.

It is very easy to see these standards in terms of classic video calls, while forgetting that the web is a wild and exciting place full of 
strange and unexpected surprises.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 10 Dec 2014 09:33:24 +0100

> > New question:  How can an endpoint that implements video but none of
the MTI codecs be construed as "WebRTC Compatible”?

Even taking this subject into the telephony world: how can thousands of SIP
phones that do not even support video be labeled as "RFC 3261 Compliant"?

> At the risk of falling down the semantic trap you set, it could be
pushing an experimental webGL based codec over the data channel.
> or an art installation. It might implement encode only of one of the MTIs
- one way survelliance - or even encode on VP8 and decode on h264
> because of some whacky licensing shenanigans.

I see many use cases for bidirectional audio and just video decoding.

> It is very easy to see these standards in terms of classic video calls,
while forgetting that the web is a wild and exciting place full of

+1

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 10 Dec 2014 09:47:23 +0100

> strange and unexpected surprises.

Or you could implement a video chat application for multiple users and 
use only VP9. Check Google hangouts in a couple of months for that..

Best regards
  Sergio

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Dec 2014 12:17:36 +0100

> 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

-Ekr

On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <[email-masked]> wrote:
>> I believe you have misread the proposal. The term "WebRTC compliant"
>> never appears

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 10 Dec 2014 14:47:27 +0000

+1
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.
Gaëlle

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

On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> 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:

video codecs

-Ekr

On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> 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 https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. Indeed, the word
"compliant" does not appear.

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

-Ekr

On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Sean,

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<http://ca.linkedin.com/in/lagerway> | Hookflash<http://hookflash.com/> | 1 (855) Hookflash ext. 2 | Twitter<http://twitter.com/elagerway> | WebRTC.is Blog<http://webrtc.is/>

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
All,

1) IPR:

2) Time:

3) Trigger:

Cheers,
spt (as chair)

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 10 Dec 2014 15:58:43 +0100

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
Sergio

On 10/12/2014 15:47, Gaelle Martin-Cocher wrote:
> 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?
>
> It might be more appropriate to relax requirements for both the WebRTC 
> gateway and a new entity than having such a vague category.
>
> Gaëlle
>
> *From:*rtcweb [mailto:[email-masked]] *On Behalf Of *Eric 
> Rescorla
> *Sent:* Wednesday, December 10, 2014 6:18 AM
> *To:* Bernard Aboba
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] confirming sense of the room: mti codec
>
> On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> My bad.
>
> the MTI codecs be construed as "WebRTC Compatible"?
>
>     On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     compliant" without implementing either of the MTI codecs is so
>     wrong-headed that I am at a loss for words.
>
>     anywhere in
>     https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. Indeed,
>     the word
>
>         On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Thanks Sean,
>
>         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 <http://ca.linkedin.com/in/lagerway> | Hookflash
>         <http://hookflash.com/> | 1 (855)**Hookflash ext. 2 | Twitter
>         <http://twitter.com/elagerway> | WebRTC.is Blog
>         <http://webrtc.is/>
>
>             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
>             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:
>
>             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.
>
>             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.
>
>
>             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.
>
>             [4]

---

From: Ron <[email-masked]>
Date: Thu, 11 Dec 2014 01:46:42 +1030

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

Yes, I thought the definition was already very clear; but given that even
with Adam's clarification, people in this group (who you might reasonably
expect to have read these documents) appear to be confused, are already
transmuting the defined term WebRTC-compatible to "WebRTC Compatible" or
even "WebRTC compliant", and are foreshadowing their fear that some
implementers might abuse this to deliberately mislead the market (for
whatever that is worth); then maybe renaming this term is useful.

Maybe s/WebRTC-compatible endpoint/non-WebRTC endpoint/ ?

That would be consistent with "It is not constrained by this specification",
would still include my WebRTC controlled coffee maker, and might better
avoid any sort of "Vista Capable" vs "Vista Ready" word games.

  Ron

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Dec 2014 17:19:58 +0000

Hi,

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.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Sergio Garcia Murillo<mailto:[email-masked]>
Sent: ‎10/‎12/‎2014 16:59
To: [email-masked]<mailto:[email-masked]>
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
Sergio

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

video codecs

-Ekr

-Ekr

1) IPR:

2) Time:

3) Trigger:

Cheers,
spt (as chair)

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 10 Dec 2014 17:59:47 +0000

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

The WebRTC gateway in https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt 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).

Gaëlle

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

Hi,

Regards,

Christer

Best regards
Sergio

video codecs

-Ekr

-Ekr

1) IPR:

2) Time:

3) Trigger:

Cheers,
spt (as chair)

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 10 Dec 2014 19:09:26 +0100

Den 10. des. 2014 18:59, skrev Gaelle Martin-Cocher:
> The WebRTC gateway in
> https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt 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.

Renaming the term is certainly possible.

And this thread has certainly made the point that the -gateways draft
needs to be informative, not standards-track.

> 
>  
> 
> 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 see absolutely no reason to go down this path.
If you want a standard that specifies conformance to a spec that is part
of the WebRTC spec, you are of course free to try to do so.

But I see no reason to join in on that journey.

---

From: David Singer <[email-masked]>
Date: Wed, 10 Dec 2014 11:15:48 -0800

> On Dec 9, 2014, at 17:22 , Ron <[email-masked]> wrote:
> 

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.

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.

David Singer

---

From: Ron <[email-masked]>
Date: Thu, 11 Dec 2014 06:30:27 +1030

On Wed, Dec 10, 2014 at 11:15:48AM -0800, 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.

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

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Wed, 10 Dec 2014 21:25:01 +0000

Inline with [gmc]

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Wednesday, December 10, 2014 1:09 PM
To: [email-masked]
Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec)

Den 10. des. 2014 18:59, skrev Gaelle Martin-Cocher:
> definition  "It is not constrained by this specification."  applies to 
> the gateway.

And this thread has certainly made the point that the -gateways draft needs to be informative, not standards-track.

[gmc] what does it change to be on the informative or standard track? VP8 is on the informative track too, right? Though VP8 or gateway would be "well defined". I don't see why it should not be the same for legitimate other WebRTC-to-be-renamed endpoints, that makes them easier to market. 

>  
> 
> 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 .
> 
>  
> 

I see absolutely no reason to go down this path.
If you want a standard that specifies conformance to a spec that is part of the WebRTC spec, you are of course free to try to do so.

[GMC] conformance is only one reason.
  
Let's take 3 sensor based hardware devices that do not need one feature (say audio for simplicity) and are used in home automation. Both indicate they are WebRTC-compatible devices on their packaging.  
Though they are different, one would have all the other WebRTC features including all security mechanisms, the second would have less security mechanisms, and the third, well, hard to say what it does. 
Tthe first device should benefit of the WebRTC enpoint terminology (as audio is not needed for that device), the second from the WebRTC-compatible terminology, the third maybe should not have any WebRTC related label.

How do a user know which one to pick and if each of them will work with my WebRTC mobile home automation apps with full protection or not if they are all called a WebRTC-compatible endpoint?

Basically that WebRTC-compatible label becomes irrelevant, though one product offers all of what is needed and not the other ones. 
How is it clear to the user that the Mobile home automation WebRTC endpoint is not the failing point when trying to interact with the second or third device?

Gaëlle

---

From: Florian Weimer <[email-masked]>
Date: Wed, 10 Dec 2014 22:46:29 +0100

* Andrew Allen:

> address the concerns of many related to IPR on H.264

Cisco is required to say this about the patent license they allegedly
confer:

“THIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR
THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT
RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC
STANDARD (“AVC VIDEO”) AND/OR (ii) DECODE AVC VIDEO THAT WAS ENCODED
BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM
A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO.  NO LICENSE IS GRANTED
OR SHALL BE IMPLIED FOR ANY OTHER USE.  ADDITIONAL INFORMATION MAY BE
OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM”

This rules out commercial use.  Doesn't this fail the “reasonable”
part of RAND because it is expected that commercial end users obtain a
separate patent license of their own (which is not part of a product
that can be purchased)?  If this is still considered “reasonable”, is
the fact relevant that all published MPEG-LA material about H.264
refers to patent licensing in a broadcasting context (either the
production side, or the receiver side)?  This strongly suggests to me
that they may lack the rights to license H.264 for use in video
conferencing applications.

Furthermore, a service using WebRTC is not a “consumer”, so this
patent license does not extend to the service provider.

---

From: David Singer <[email-masked]>
Date: Wed, 10 Dec 2014 13:50:50 -0800

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 <[email-masked]> wrote:
> 

David Singer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Dec 2014 13:59:05 -0800

> conferencing applications.

I recommend that you consult counsel on these sorts of questions.
Seeking legal opinion on an internet mailing list might not produce
the best results.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Dec 2014 17:32:35 -0500

Moving to the other thread for clarity...

> 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 su…

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 duc…

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.

---

From: Ron <[email-masked]>
Date: Thu, 11 Dec 2014 09:30:13 +1030

[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.

  Ron

---

From: Richard Barnes <[email-masked]>
Date: Wed, 10 Dec 2014 18:04:46 -0500

+1

This conversation is out of scope for this mailing list.

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 11 Dec 2014 00:13:17 +0100

On Wed, 10 Dec 2014 18:04:46 -0500

> This conversation is out of scope for this mailing list.

And yet it does raise some flags, though. Had I blindly trusted the claims that have been made on this ML (not out of scope at the time, apparently) about what the infamous plugin allegedly provided, I could have ended up offering services based on openH264 and hopefully try and make some money out of it: only to find myself suitable in the process, and in perfectly good faith. I don't think raising awareness on such a delicate issue that matters to the discussion is so out of scope.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Andrew Allen <[email-masked]>
Date: Wed, 10 Dec 2014 23:15:12 +0000

It could be a telemetry device supporting only the data channel so no audio or video (not such an odd duck I think).

Andrew

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of David Singer
Sent: Wednesday, December 10, 2014 2:16 PM
To: [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

ah, that’s different.

David Singer

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 11 Dec 2014 00:17:49 +0100

No it is not.

The availability of OpenH264 was proposed here in this list as one 
argument in favor of adopting H264, so IMHO, this should be explained.

Best regards
Sergio
On 11/12/2014 0:04, Richard Barnes wrote:
> On Wed, Dec 10, 2014 at 4:59 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 10 December 2014 at 13:46, Florian Weimer <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > This rules out commercial use.  Doesn't this fail the "reasonable"
>     > that can be purchased)?  If this is still considered
>     "reasonable", is

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 11 Dec 2014 00:17:54 +0100

On Thu, 11 Dec 2014 00:13:17 +0100

> And yet it does raise some flags, though. Had I blindly trusted the claims that have been made on this ML (not out of scope at the time, apparently) about what the infamous plugin allegedly provide…

PS: I guess "suitable" is not the word I was looking for (maybe "impeachable"? I should work on my vocabulary!) but, hey, hope you got what I meant :-)

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Dec 2014 18:19:56 -0500

On Wed, Dec 10, 2014 at 6:13 PM, Lorenzo Miniero <[email-masked]>
wrote:

> And yet it does raise some flags, though. Had I blindly trusted the claims
> that have been made on this ML (not out of scope at the time, apparently)
> about what the infamous plugin allegedly provided, I could have ended up
> offering services based on openH264 and hopefully try and make some money
> out of it: only to find myself suitable in the process, and in perfectly
> good faith. I don't think raising awareness on such a delicate issue that
> matters to the discussion is so out of scope.
>
>
You might as well discuss such things as what is the definition of RAND and
if such things as IPR declarations are legally enforceable. Both are very
tricky and very heavily depend on the the standard body.
_____________
Roman Shpount

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 11 Dec 2014 00:21:47 +0100

> 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
Sergio

---

From: David Singer <[email-masked]>
Date: Wed, 10 Dec 2014 15:35:05 -0800

> On Dec 10, 2014, at 15:15 , Andrew Allen <[email-masked]> wrote:
> 
> It [non-video non-audio device] could be a telemetry device supporting only the data channel so no audio or video (not such an odd duck I think).

ah yes, thanks

David Singer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Dec 2014 15:43:40 -0800

On 10 December 2014 at 15:17, Sergio Garcia Murillo
<[email-masked]> wrote:
> The availability of OpenH264 was proposed here in this list as one argument
> in favor of adopting H264, so IMHO, this should be explained.

I recommend that you reach your own conclusions about whether to
consider OpenH264 as having any bearing on the discussion.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 11 Dec 2014 08:24:18 +0100

> Seeking legal opinion on an internet mailing list might not produce

This is about IETF policy towards RAND licensing.  It's a working
group and IETF decision, not something that can be left to lawyers.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 11 Dec 2014 05:19:10 -0500

> group and IETF decision, not something that can be left to lawyers.

When discussing RAND terms in general, I would suggest reading something
like this
http://www.cravath.com/files/Uploads/Documents/Publications/3233990_1.pdf
and then talking to your legal counsel.

Typically, as far as standards are concerned (this comes with a a huge
IANAL disclaimer), obligation to license IPR under RAND terms implies only
that some licensing terms will be offered for this IPR to anybody who is
willing to implement the standard. What these terms are is up to the IPR
holder. In a lot of cases, obligation to license under RAND terms is
meaningless and the actual licensing policy by IPR holders must be
considered.

In case of H.264, as far as our company is concerned, this implies that we
cannot license H.264 IPR. To work around this, we are planning to offer
H.264 in client software on the platforms where H.264 is provided by the
platform itself or via OpenH264. In both cases, we consider H.264 licensing
will be something that will occur between the end user and the platform
provider, or, in case of OpenH264, between the end user and Cisco. If end
users decides to ignore the H.264 licensing terms, as they typically do,
this is between the end user and whoever provided them with the H.264
license. We will not license H.264 ourselves or provide any H.264 licenses
from us to our customers. In anything that we license directly to our
customers or operate ourselves (which typically means professional
conferencing services), we are planning to support VP8 only and will not
claim WebRTC compliance. End points which implement H.264 only will not be
fully supported by the services we operate and would only be provided with
limited feature set that can be enabled based on peer-to-peer
communications or relay without the need for transcoding or
other H.264 related server functionality. This is why the currently offered
compromise works for us even though H.264 licensing policy is less then
ideal.
_____________
Roman Shpount

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 11 Dec 2014 14:39:15 +0000

> On Dec 10, 2014, at 2:46 PM, Florian Weimer <[email-masked]> wrote:
> 
> * Andrew Allen:
> 
> This rules out commercial use. 

I don't think that is the case. This is really not in scope for this list but I'm going to answer anyways. This terms personal and consumer are defined in a way that might surprise you in the MPLEG-LA license. This can be used for what most people consider commercial in the usual use of the word. The best document to understand theses is  http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf and work with your legal team. 

The license Cisco is providing for openh264 is  the same MPEG-LA license that is used by products such as Cisco video phones, tele pretenses systems, soft phones, webex, jabber ect. Most people think of the prices of our video and tele presence systems as most definitely "commercial" and people pay to use webex. You can use openh264 for things like that with the license provided. 

It's also well worth noting that if you ship less than 100k units/year, it free and you can just compile in your favorite 264 open source code  (there are multiple to choose from) and ship it. 

I don't want to start a thread about how to understand a complex legal document from MPEG-LA but I did want to just provide pointers to the above info. 

Cullen (with my individual contributor hat on)

---

From: cowwoc <[email-masked]>
Date: Thu, 11 Dec 2014 10:14:22 -0500

> Cullen (with my individual contributor hat on)

This just reinforces the point made by others which is when it comes to 
H264 this isn't so much a royalty problem (hence "free" is nice but not 
all that meaningful) but rather a problem where you have no way of using 
English or common sense in evaluating whether you are breaking the law 
or not. On the one hand, we have H264 proponents claiming OpenH264 
solves all our woes. On the other hand, we have a legally-binding 
statement that pretty clearly states the opposite. Now you would have us 
believe that:

 1. This is out of scope for this mailing list (which I disagree with as
    it has a profound impact on our members)
 2. "You have nothing to worry about. But you can't take our word for
    it. Go pay a lawyer >$10,000 to find out for sure"

Honestly. MPEG-LA is shooting itself in the foot by making these 
licensing terms so complex. Even if I wanted to give them my money the 
sheer complexity of the matter prevents me from touching their codec 
with a 10 feet pole.

Gili

---

From: Tim Panton <[email-masked]>
Date: Thu, 11 Dec 2014 15:46:24 +0000

> On 11 Dec 2014, at 14:39, Cullen Jennings (fluffy) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  tele pretenses systems

Do you do one that can join conference calls pretending to be me?

:-)

T.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 11:42:21 -0500

I would like to re-emphasize that discussions of license terms are out of
scope for this list.  This thread is closed.

On Thu, Dec 11, 2014 at 10:14 AM, cowwoc <[email-masked]> wrote:

>  On Dec 10, 2014, at 2:46 PM, Florian Weimer <[email-masked]> <[email-masked]> wrote:
>
> * Andrew Allen:
>
>
> H264 this isn't so much a royalty problem (hence "free" is nice but not all
> that meaningful) but rather a problem where you have no way of using
> English or common sense in evaluating whether you are breaking the law or
> not. On the one hand, we have H264 proponents claiming OpenH264 solves all
> our woes. On the other hand, we have a legally-binding statement that
> pretty clearly states the opposite. Now you would have us believe that:
>
>    1. This is out of scope for this mailing list (which I disagree with
>    as it has a profound impact on our members)
> Honestly. MPEG-LA is shooting itself in the foot by making these licensing
> terms so complex. Even if I wanted to give them my money the sheer
> complexity of the matter prevents me from touching their codec with a 10
> feet pole.
>
> Gili
>

---

From: John Leslie <[email-masked]>
Date: Thu, 11 Dec 2014 13:32:48 -0500

Roman Shpount <[email-masked]> wrote:
>...

   This explanation is definitely helpful. Thank you!

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 13:37:50 -0500

Let me re-iterate: This thread is closed.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 13:53:37 -0500

Just to clarify: The above messages closing the thread were with my RAI AD
hat on, so as a matter of IETF process.

---

From: cowwoc <[email-masked]>
Date: Thu, 11 Dec 2014 14:39:10 -0500

Richard,

I don't want to start a flamewar but I don't get the IETF's reasoning on 
this matter.

Is the IETF planning to pick one or more MTI codecs based purely on 
technical merits?  Or are they taking other matters (such as licensing) 
into consideration?

If you are judging based purely on technical merits, why are we 
entertaining this "compromise" proposal? I thought we had agreed long 
ago that both codecs were more or less equivalent from a technical merit 
point of view.

If you are not judging purely based on technical merits, why are we not 
allowed to debate matters that are part of the judging criteria?

Gili

On 11/12/2014 1:53 PM, Richard Barnes wrote:
> Just to clarify: The above messages closing the thread were with my 
> RAI AD hat on, so as a matter of IETF process.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 15:51:23 -0500

Hi Gili,

Fair question.  Keep in mind that the context here is Sean's message of
December 5, which was to confirm the consensus in the room at the IETF
meeting.  He noted three objections that were discussed in the room,
including one about IPR. He sought to confirm consensus on the list, and
asked that anyone raise any other, additional issues by December 19.

Appropriate responses to his message would include: people who were in the
room re-stating their positions, people who were not in the room stating
positions, and people raising issues that were not in his issue list.

That said, it is important that all relevant facts be on the table.  So
participants should feel free to point out direct, factual things about the
options, technical or not.  However, any discussion or *analysis* of those
facts, however, has to be off the table.  For example, "X open-source
project is available under Y license" is OK, but "Y license doesn't allow Z
use" is not.

Obviously, participants are welcome to come to their positions by whatever
means they choose.  Participants may consider technical characteristics,
IPR terms, legal issues, or anything else.  However, this working group is
chartered to develop technical solutions, and the expertise on this list is
technical.  So I am precluding discussion of non-technical matters in this
forum.

Thanks,
--Richard

On Thu, Dec 11, 2014 at 2:39 PM, cowwoc <[email-masked]> wrote:

> entertaining this "compromise" proposal? I thought we had agreed long ago
> that both codecs were more or less equivalent from a technical merit point
> of view.
>
>> Just to clarify: The above messages closing the thread were with my RAI
>> AD hat on, so as a matter of IETF process.
>>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 11 Dec 2014 16:02:07 -0500

Richard,

Is it fair to state things like due to licensing considerations, as we see
them, we will implement things X and Y in the following manner, and because
of this we support the proposed compromise?

_____________
Roman Shpount

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 16:51:13 -0500

Yes.  It is a fact, about you -- namely, the fact that you intent to
implement.  As above, analysis of that position would be off the table.

--Richard

On Thu, Dec 11, 2014 at 4:02 PM, Roman Shpount <[email-masked]> wrote:

>> Appropriate responses to his message would include: people who were in
>> the room re-stating their positions, people who were not in the room
>> stating positions, and people raising issues that were not in his issue
>> list.
>>
>> Obviously, participants are welcome to come to their positions by
>> whatever means they choose.  Participants may consider technical
>> characteristics, IPR terms, legal issues, or anything else.  However, this
>> working group is chartered to develop technical solutions, and the
>> expertise on this list is technical.  So I am precluding discussion of
>> non-technical matters in this forum.
>>
>> Thanks,
>> --Richard
>>
>>

---

From: cowwoc <[email-masked]>
Date: Thu, 11 Dec 2014 16:54:16 -0500

Hi Richard,

Please try to emphasize this fact (what is acceptable vs what is not) 
the next time you close a thread. I agree with your position, but I was 
not aware of what you meant until now.

Thanks,
Gili

On 11/12/2014 3:51 PM, Richard Barnes wrote:
> Hi Gili,
>
> Fair question.  Keep in mind that the context here is Sean's message 
> of December 5, which was to confirm the consensus in the room at the 
> IETF meeting.  He noted three objections that were discussed in the 
> room, including one about IPR. He sought to confirm consensus on the 
> list, and asked that anyone raise any other, additional issues by 
> December 19.
>
> stating positions, and people raising issues that were not in his 
> issue list.
>
> That said, it is important that all relevant facts be on the table.  
> So participants should feel free to point out direct, factual things 
> about the options, technical or not. However, any discussion or 
> *analysis* of those facts, however, has to be off the table.  For 
> example, "X open-source project is available under Y license" is OK, 
> but "Y license doesn't allow Z use" is not.
>
> characteristics, IPR terms, legal issues, or anything else.  However, 
> this working group is chartered to develop technical solutions, and 
> the expertise on this list is technical.  So I am precluding 
> discussion of non-technical matters in this forum.
>
> Thanks,
> --Richard
>
>
> On Thu, Dec 11, 2014 at 2:39 PM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Richard,
>
>     I don't want to start a flamewar but I don't get the IETF's
>     reasoning on this matter.
>
>     Is the IETF planning to pick one or more MTI codecs based purely
>     on technical merits?  Or are they taking other matters (such as
>     licensing) into consideration?
>
>     entertaining this "compromise" proposal? I thought we had agreed
>     long ago that both codecs were more or less equivalent from a
>     technical merit point of view.
>
>     If you are not judging purely based on technical merits, why are
>     we not allowed to debate matters that are part of the judging
>     criteria?
>
>     Gili
>
>         Just to clarify: The above messages closing the thread were
>         with my RAI AD hat on, so as a matter of IETF process.
>
>

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Thu, 11 Dec 2014 22:41:02 +0000

Answering your questions below with [gmc] and repeating myself, sorry.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Sergio Garcia Murillo
Sent: Wednesday, December 10, 2014 6:22 PM
To: [email-masked]
Subject: Re: [rtcweb] WebRTC endpoint categories

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 
[gmc] for me, that is an option if 'WebRTC-compatible endpoint' is not better defined.
Currently that unclear category correspond to both ‘meaningful’ entities (gateway, current WebRTC librairies, or Ron’s coffee maker) and possibly some sub-standard implementation.

  -Change definition of a webrtc compatible endpoint 
[gmc] yes, or actually clearly set out the requirements that apply to them. As said before: The WebRTC gateway in https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt 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.
Proposal A: define in a draft the minimal requirements that apply to a WebRTC-compatible endpoint to “successfully communicate with a WebRTC endpoint”.    This draft can be an extension of the gateway draft.
Proposal B:  the WebRTC gateway could be removed from the WebRTC-compatible endpoint category and called a webRTC gateway with its own draft. As, there might be enough differences to  justify two entities, there would be the gateway draft and a draft for WebRTC-compatible endpoint as in proposal A.
Changing the naming of “WebRTC-compatible” to a less confusing term is a cosmetic change (but might be a good thing).

[gmc] No. 

Proposal C: allow an endpoint that do not required some functions (by function it means that function in its entirety) to be called a WebRTC endpoint.
Example: an endpoint that does not need to do audio at all is a webRTC endpoint. An endpoint that chose to implement a single audio codec out of the two MTI audio codec is not a WebRTC endpoint.

Gaëlle

Best regards
Sergio

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 18:17:53 -0500

Will do.  Thanks for the feedback :)

--Richard

On Thu, Dec 11, 2014 at 4:54 PM, cowwoc <[email-masked]> wrote:

>  Hi Richard,
>
> Please try to emphasize this fact (what is acceptable vs what is not) the
> next time you close a thread. I agree with your position, but I was not
> aware of what you meant until now.
>
> Thanks,
> Gili
>
>

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 12 Dec 2014 23:45:39 +1300

I also support the rough consensus reached by those of us in the room in Honolulu.

It has been said that “a good compromise is one in which all parties are unhappy”.  By that measure, this is most definitely a good compromise :-)

I think that just about everybody is unhappy about at least some aspect of this compromise.  (For example, as I noted at the microphone in Honolulu, I dislike the fact that making two codecs MTI in browsers for perpetuity - and with the likelihood that at least one of these codecs will be somewhat encumbered for at least the near future - may dampen the possibility of a flourishing ecosystem emerging in the browser space.  But I understand why many others feel that this requirement on browsers is necessary.)

So yes, we’re all a bit unhappy, but I haven’t seen any sign - in any of the recent postings on this mailing list - of an alternative compromise that is likely to gain close to the same degree of consensus.  So, continuing to debate this ad nauseam does nothing but cause further delay (which I'm sure nobody would want :-)

It’s time for us to collectively hold our noses, declare consensus on this issue, and move forward.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Dec 2014 12:14:23 +0100

Question: If the World gets a new "Opus for video" codec, will this WG
make it MTI for WebRTC at the same time it removes both VP8 and H264
from the list of MTI codecs?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 12 Dec 2014 20:31:57 +0900

> from the list of MTI codecs?

1) This is a good question. I wish I knew :-).

2) This is conditional on a hypothetical event in the future ("Opus for 
video"). At that point, this WG may no longer exist. Or it may do 
whatever it pleases (as long as it is within its charter).

3) Even if VP8 and H264 are removed from the list of MIT codecs in a 
future spec, implementations still may need them for quite a while to be 
backwards compatible with other not yet updated implementations and old 
content.

Just my 3¢.   Regards,   Martin.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 12 Dec 2014 07:26:34 -0700

> whatever it pleases (as long as it is within its charter).

Sure, but that can all happen through normal IETF processes (form a new 
WG, write an I-D that obsoletes this dual-MTI solution, etc.).

IMHO it would still be good to address some aspects of the various 
possible scenarios that I mentioned here:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg13754.html

I have it on my to-do list to draft some text.

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Dec 2014 08:45:10 -0600

On 12/12/14 08:26, Peter Saint-Andre - &yet wrote:
> Sure, but that can all happen through normal IETF processes (form a 
> new WG, write an I-D that obsoletes this dual-MTI solution, etc.).
>
> possible scenarios...

I think that the future-looking clause is one of the wartiest parts of 
this proposal. On the other hand, it's the one thing that makes it 
different than things we've considered in the past, and is clearly a key 
part of what allowed it to gather the support that it has so far. So: 
ugly, necessary, and sufficient.

Given that it's sufficient to gain the current level of support, the 
need for change is unclear.

Given that it's necessary, we can't remove it, or the whole thing falls 
apart.

And, given that it's ugly, making it more expansive would only make the 
proposal qualitatively worse.

There's no point trying to map out large decision trees for the future, 
especially since we've had such a contentious time coming to some 
semblance of agreement on the current direction. Pushing more 
future-looking decisions into the text would only serve to give us more 
things to disagree about.

And, as you point out, if something comes up in the future that 
materially changes the landscape, it's completely within the purview of 
the IETF to apply rational analysis to make a decision based on the 
actual facts at that time.

/a

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Dec 2014 15:57:40 +0100

2014-12-12 15:45 GMT+01:00 Adam Roach <[email-masked]>:
> I think that the future-looking clause is one of the wartiest parts of this
> proposal. On the other hand, it's the one thing that makes it different than
> things we've considered in the past, and is clearly a key part of what
> allowed it to gather the support that it has so far. So: ugly, necessary,
> and sufficient.
>
> Given that it's sufficient to gain the current level of support, the need
> for change is unclear.
>
> especially since we've had such a contentious time coming to some semblance
> of agreement on the current direction. Pushing more future-looking decisions
> into the text would only serve to give us more things to disagree about.
>
> And, as you point out, if something comes up in the future that materially
> changes the landscape, it's completely within the purview of the IETF to
> apply rational analysis to make a decision based on the actual facts at that
> time.

That would sound really nice if the already chosen MTI codecs were
100% RF with no licensing/patent issues. That's not the case so IMHO
the door should remain open for, at least, the inclusion of a new 100%
RF video codec.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Dec 2014 09:06:39 -0600

On 12/12/14 08:57, Iñaki Baz Castillo wrote:
> IMHO the door should remain open for, at least, the inclusion of a new 100% RF video codec.

Then you already have what you want: there's no way we could close that 
door, no matter how hard we tried.

/a

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 12 Dec 2014 15:27:57 +0000

Multiple codecs can be supported even if there is only a single MTI defined in WebRTC. 
This has been confirmed by those who will implement scalable codecs.

I am not aware of anyone asking for removing the codec negotiation/capability discovery even if there is a single MTI. 
As such supporting multiple codecs is independent from the MTI discussion.
The question is not do we need multiple codecs but do we need multiple MTIs (and which). 

Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: Monday, December 08, 2014 3:42 PM
To: Sean Turner; [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

To reiterate another point from the meeting, there are technical advantages to supporting multiple codecs. Dynamic discovery of local capabilities, negotiation of remote capabilities, understanding how different error resilience mechanisms can work (or not) with different codecs, faster adoption of new (non-mandatory) codecs, easier path to deprecating old (mandatory) codecs, etc. All those legs never get exercised effectively in single-codec implementations, leaving land mines in browsers, apps, services and sometimes even specs. They become easier or free once the groundwork is laid for multiple codecs. While some have argued against that extra complexity, I see it as essential for any important standard.

Mo

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 12 Dec 2014 07:51:55 -0800

Ross Finlayson wrote:
> I think that just about everybody is unhappy about at least some aspect
> of this compromise.  (For example, as I noted at the microphone in

Yes. From reading the comments in this discussion, it seems to me many 
people are unhappy with many _different_ aspects of the proposal. 
However, there's no one aspect that everyone universally agrees is bad 
[1]. I include myself among those unhappy people, despite my overall 
support for the proposal.

[1] The one possible exception is the term "WebRTC-compatible" to 
describe a thing that doesn't obey the WebRTC specs, but as Christer 
pointed out, that's not an issue with the proposal, that's an issue with 
draft-ietf-rtcweb-overview.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Dec 2014 17:32:44 +0100

> The question is not do we need multiple codecs but do we need multiple MTIs (and which).

We need MTI codecs, but no patent/license polluted ones. That's the
reason of my question. Will those non 100% RF video codecs be removed
as MTI *if* a new 100% RF good video codec appeared? Will we have to
deal with non RF MTI codecs forever?

The arguments I'm reading in this thread about the no-need for more
MTI codecs in the future could also be applied for the no-need of
defining any MTI codec now. At the end we do have a "codec
negotiation/capability discovery" mechanism, right?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 12 Dec 2014 16:48:01 +0000

This is not at all what I implied.
I believe we will need new codecs in the future, say one that provide more compressions.
Will that have to be mandatory or recommended is TBD.

At the same time, if we have a new codec we need to ensure legacy systems will continue to work. 
This is the reason I do not agree with the note under webrtc-compatible endpoint which only take in account RF aspects.
I have proposed that the notes take RF aspects for VP8 and takes legacy aspects for H.264 as these are the arguments put forward by respective proponents.

Gaëlle

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Friday, December 12, 2014 11:33 AM
To: Gaelle Martin-Cocher
Cc: Mo Zanaty (mzanaty); [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

> The question is not do we need multiple codecs but do we need multiple MTIs (and which).

We need MTI codecs, but no patent/license polluted ones. That's the reason of my question. Will those non 100% RF video codecs be removed as MTI *if* a new 100% RF good video codec appeared? Will we have to deal with non RF MTI codecs forever?

The arguments I'm reading in this thread about the no-need for more MTI codecs in the future could also be applied for the no-need of defining any MTI codec now. At the end we do have a "codec negotiation/capability discovery" mechanism, right?

--
Iñaki Baz Castillo
<[email-masked]>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 12 Dec 2014 17:54:39 +0000

Agreed, from the viewpoint of specifications. But from the viewpoint of
implementations, there is often quite a difference between the level of
support when the spec says ³can² versus ³MUST².

Mandatory codec agility is even more important than specific mandatory
codecs, but it may take the latter to force the former.

My comment was not based on hypothetical concerns or foresight. It was
from direct experience trying to add H.264 into the webrtc.org codebase
and Mozilla¹s fork. The current support in Firefox barely meets the bar of
shippable, and webrtc.org support is not shippable at all. (I think your
Blackberry colleagues who also started down this path can corroborate
this.) There are still many holes, and lots of refactoring is still in
progress to have a truly robust multi-codec media engine where resilience
and other aspects are harmonized for all codecs. The end result will be a
platform that can more easily and rapidly handle VP9, H.265, Daala, netvc,
etc. without lots of additional refactoring or gaps in functionality
across codecs. It does require extra effort, but I see it as essential
investment that should not be deferred.

Actually implementing multiple codecs can also reveal gaps in specs. For
example, I strongly support your argument for decoding many formats even
if you can only encode one or a few. It is a good technical direction. But
try to implement it with current standards, and you will hit some walls.

Mo

On 12/12/14, 10:27 AM, Gaelle Martin-Cocher <[email-masked]>
wrote:

Multiple codecs can be supported even if there is only a single MTI
defined in WebRTC. 
This has been confirmed by those who will implement scalable codecs.

I am not aware of anyone asking for removing the codec
negotiation/capability discovery even if there is a single MTI.
As such supporting multiple codecs is independent from the MTI discussion.
The question is not do we need multiple codecs but do we need multiple
MTIs (and which). 

Gaëlle

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Mo Zanaty
(mzanaty)
Sent: Monday, December 08, 2014 3:42 PM
To: Sean Turner; [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

Mo

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 12 Dec 2014 19:13:09 +0000

-----Original Message-----
From: Mo Zanaty (mzanaty) [mailto:[email-masked]] 
Sent: Friday, December 12, 2014 12:55 PM
To: Gaelle Martin-Cocher; [email-masked]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

Agreed, from the viewpoint of specifications. But from the viewpoint of implementations, there is often quite a difference between the level of support when the spec says ³can² versus ³MUST².
[gmc] but no so much when the spec says should versus must. 

E.g. WebRTC endpoints must implement at least one of VP8 and H.264 and should implement the other one. 
That says: unless you have a very good reasons, you have to implement both. 
This allows implementations to evolve from one to two codecs while not changing the spec.
I think everybody should be equally unhappy but might actually deliver products according to the specs; making the consensus translatable in something tangible.
Would that be acceptable?

Mandatory codec agility is even more important than specific mandatory codecs, but it may take the latter to force the former.
[GMC] generally agree.  There is quite a few more options to the above one: Shall implement at least two codecs, one is a defined MTI, the other if up to you (or is in a list of recommended codecs). The second codec can be a future looking codec. Other option: browser and non-browser do not have the same number of codecs to implement. A third option is an asymmetry in the number of decoders and encoders.

My comment was not based on hypothetical concerns or foresight. It was from direct experience trying to add H.264 into the webrtc.org codebase and Mozilla¹s fork. The current support in Firefox barely meets the bar of shippable, and webrtc.org support is not shippable at all. (I think your Blackberry colleagues who also started down this path can corroborate
this.) 
[gmc] we are aware of some current limitations in some implementations. It was stated also by a few that the video codec is currently not the bottleneck to launch services, but the state of overall WebRTC implementations in various browsers. 

There are still many holes, and lots of refactoring is still in progress to have a truly robust multi-codec media engine where resilience and other aspects are harmonized for all codecs. The end result will be a platform that can more easily and rapidly handle VP9, H.265, Daala, netvc, etc. without lots of additional refactoring or gaps in functionality across codecs. It does require extra effort, but I see it as essential investment that should not be deferred.

Actually implementing multiple codecs can also reveal gaps in specs. 

[gmc] Agree. We are in a situation where some mobile apps/libraries/SDKs already implement multiple codecs (not necessarily the MTI ones) and are on the forefront of "debugging" webRTC for these aspects. 
Browser wise, well, yes I agree, that may take much more time.
Achieving interoperability is also (usually, in some worlds) achieved via conformance tests.
If these tests are limited in the OTT/WebRTC world, it is not by multiplying MTI functions (whatever they are) that implementations will be better. It will still be product A attempting to interoperate with e.g. browsers B, C, product D... hit/miss, try again. Indeed that will take time to verify all of WebRTC functions across a large list of implementations.

For example, I strongly support your argument for decoding many formats even if you can only encode one or a few. It is a good technical direction. But try to implement it with current standards, and you will hit some walls.

[gmc] Standards are/should be evolving ? 

Gaëlle
Mo

Gaëlle

-----Original Message-----

Mo

---

From: David Singer <[email-masked]>
Date: Fri, 12 Dec 2014 15:33:41 -0800

> On Dec 12, 2014, at 7:06 , Adam Roach <[email-masked]> wrote:
> 
> Then you already have what you want: there's no way we could close that door, no matter how hard we tried.

Quite.  I rather suspect that stating “If the situation changes, we may change this specification” is stating the obvious.  These forward-looking statements don’t seem to inform implementations, or constrain or de-constrain the group. I am unclear as to what purpose they serve.

As a humorist once remarked, “what am I supposed to do about road-side signs that warn of low-flying aircraft? take my hat off?”

David Singer

---

From: David Singer <[email-masked]>
Date: Fri, 12 Dec 2014 15:39:38 -0800

> On Dec 12, 2014, at 8:32 , Iñaki Baz Castillo <[email-masked]> wrote:
> 
> We need MTI codecs, but no patent/license polluted ones.

I think hoping for an RF codec is optimistic but may be achieved.  Hoping for a codec which has needs/has no license is definitely further out on the optimism scale.

We can hope for Reasonable licenses, of course, but then we rapidly find that we don’t have a consensus definition, in the industry, for what is reasonable. I have struggled with this for years.

> That's the

My experience is that once something is mandatory in a spec., it can get very wedged; people say (reasonably) it has to remain mandatory to ensure interop with the established base.  Part of my concern is that it may lock almost everyone into a state of perpetual unhappiness.

For example, it took many years to get 3GPP to move H.263 from mandatory to only recommended. :-(

This is, I admit, at odds with the “be agile” mood of the times.  YMMV.

best wishes of the season! sorry to be dismal.

David Singer

---

From: David Singer <[email-masked]>
Date: Fri, 12 Dec 2014 15:42:32 -0800

> On Dec 12, 2014, at 11:13 , Gaelle Martin-Cocher <[email-masked]> wrote:
> 

Yes, indeed.  If your goal is to make sure everyone can negotiate, we don’t have to say what over, as long as the support is for more than one.

We could also split (as I said before) transmit and receive.  Encoders are harder to do well than decoders, generally. If everyone can decode multiple codecs, they only need to be able to encode one. This also exercises negotiation.

David Singer

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 12 Dec 2014 16:49:19 -0700

> Quite.  I rather suspect that stating “If the situation changes, we may change this specification” is stating the obvious.  These forward-looking statements don’t seem to inform implementations, or…

Right now the spec makes forward-looking statements.

       To promote the use of non-royalty bearing video codecs,

       These provisions apply to WebRTC Non-Browsers only.  There is no
       plan to revisit the codecs required for WebRTC Browsers.

I am now thinking that if we're not going to define how all this is 
supposed to work (automatic triggers? RFC to replace this one? etc.), 
then it would be best to remove that text.

And yes, any future RFC that has IETF consensus can update or obsolete 
this one (should it become an RFC), so there's no reason to run through 
all the scenarios.

See you at the NETVC BoF! ;-)

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 13 Dec 2014 01:00:21 +0100

>       plan to revisit the codecs required for WebRTC Browsers.

Clear. H264 mandatory for browsers forever. Congrats patent holders.

BTW this is the first specification/standard/draft/RFC that states how
future revisions of itself should behave. A clear lock-in IMHO.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ron <[email-masked]>
Date: Sat, 13 Dec 2014 13:42:16 +1030

On Fri, Dec 12, 2014 at 04:49:19PM -0700, Peter Saint-Andre - &yet wrote:
> I am now thinking that if we're not going to define how all this is supposed
> to work (automatic triggers? RFC to replace this one? etc.), then it would
> be best to remove that text.
> 
> And yes, any future RFC that has IETF consensus can update or obsolete this
> one (should it become an RFC), so there's no reason to run through all the
> scenarios.

Well, there is still the question of how we're complying with the charter
which says:

 The working group will follow BCP 79, and adhere to the spirit of BCP 79.
 The working group cannot explicitly rule out the possibility of adopting
 encumbered technologies; however, the working group will try to avoid
 encumbered technologies that require royalties or other encumbrances that
 would prevent such technologies from being easy to use in web browsers.

Can we show how we've "tried to avoid that", in the light of having
consensus that VP8 is acceptable as MTI?

And I still really don't get how we've complied with 6.1.1/6.1.2 of
BCP 79, in spirit or letter, if we still *only* have disclosures for VP8.

Yes I know some people keep repeating "it's an ISO standard, not an IETF
one", but that's not an escape clause BCP 79 offers.  If we make H.264
MTI then it becomes a technology required to implement this standard.
For which BCP 79 says:

 Contributors must disclose IPR meeting the description in this section;
 there are no exceptions to this rule.

  Ron

---

From: Sean Turner <[email-masked]>
Date: Sat, 13 Dec 2014 11:36:03 -0500

> future revisions of itself should behave. A clear lock-in IMHO.

Just to be clear:  "No plan" does not mean that the requirement is immutable forever, just that we don't have a plan right now.  MTI requirements in IETF documents can always be updated, and they very frequently are.

In fact, coming from the security area the idea of an MTI for life is really odd to me.  MTI cipher suites get changed often enough that many security protocols don’t include the MTI algorithms in the base spec.  For ones that die hard they get the draft names like draft-ietf-krb-wg-des-die-die-die, which became RFC 6649, that deprecates the use of DES the original MTI in Kerberos 5.

On the flip side, there are plenty of RFCs that either hint at or specify future requirements (a non exhaustive list):
1) RFCs 4305/4835/7321, RFC 5750 and 5751 use MUST+/-, SHOULD+/-, etc. to telegraph what algorithms future versions are likely to support.
2) BGP-3/4(RFC 1163/4271) specify that future verions MUST retain the format of the OPEN and NOTIFICATION messages.
3) LDAP specifications (RFC 1487/1777) indicated new authentication mechanisms would be included.
4) Diameter (RFC 3588) says future versions may mandate that clients support SCTP.
5) DOCSIS (RFC 4131) says future versions are expected to support IPv6.
6) NETCONF over TLS (RFC 5539) applies to a particular version but says it applies to future versions as well and the later MTI cipher suite MUST be supported.
7) MRCPv2 (RFC6787) includes the following "If in the future voice biometric providers standardize on such a mechanism, then a future version of MRCP can mandate it.” 

Cheers,

spt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 13 Dec 2014 14:15:04 -0500

I support the rough consensus reached in the room in Honolulu.

-Jonathan R.

On Fri, Dec 12, 2014 at 9:57 AM, Iñaki Baz Castillo <[email-masked]> wrote:
> this
> semblance
> materially

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 14 Dec 2014 01:46:56 +0100

> I support the rough consensus reached in the room in Honolulu.

Thanks Jonathan. Any other feedback about WebRTC in general?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 14 Dec 2014 01:58:32 +0100

> Just to be clear:  "No plan" does not mean that the requirement is immutable forever, just that we don't have a plan right now.  MTI requirements in IETF documents can always be updated, and they v…

That sounds good, but I'm still waiting for a response to my question
made yesterday:

>>  The rationale here is browser accommodation for very constrained "WebRTC compatible" devices, which will most typically be concerned with browser interoperation. The example that's been tossed around in this space is the "WebRTC doorbell" -- when someone rings the bell, you navigate to its interface using WebRTC, and stream an image from a small, embedded camera. In these kinds of very-low-cost devices, you're going to likely see hardware video encoding (e.g. do a web search for NVS2200), which will likely be one codec or another, but not both.
>>
>> The goal is continued browser support for such devices in perpetuity.

> May I know where in the WG chapter is that goal defined please?

If the above is a real goal of this WG (is it?) then that means that
future revisions should respect it ad aternum. This is: even if in the
future a new *good* video codec 100% RF appears, implementations MUST
still include both VP8 and H264 (and deal with patent/licensing
issues, which is a show stopper for certain players in the web
ecosystem).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Dec 2014 11:06:02 +0100

On the "confirming sense of the room" thread, there have been lots of
messages over the last few days - but only *one* new position stated.

Could those who wish to comment further (like the 3 levels of poster
below) PLEASE change the subject line?

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 15 Dec 2014 09:36:56 -0700

On 12/13/14, 5:58 PM, Iñaki Baz Castillo wrote:
>> Just to be clear:  "No plan" does not mean that the requirement is
>> immutable forever, just that we don't have a plan right now.  MTI
>> requirements in IETF documents can always be updated, and they very
>> frequently are.
>
> That sounds good, but I'm still waiting for a response to my
> question made yesterday:
>
>>> The rationale here is browser accommodation for very constrained
>>> "WebRTC compatible" devices, which will most typically be
>>> concerned with browser interoperation. The example that's been
>>> tossed around in this space is the "WebRTC doorbell" -- when
>>> someone rings the bell, you navigate to its interface using
>>> WebRTC, and stream an image from a small, embedded camera. In
>>> these kinds of very-low-cost devices, you're going to likely see
>>> hardware video encoding (e.g. do a web search for NVS2200), which
>>> will likely be one codec or another, but not both.
>>>
> future revisions should respect it ad aternum. This is: even if in
> the future a new *good* video codec 100% RF appears, implementations
> MUST still include both VP8 and H264 (and deal with patent/licensing

The IETF can *always* obsolete one RFC (e.g., one that says "dual-MTI 
for H.264 and VP8") with another RFC (e.g., one that says "no more 
dual-MTI for H.264 and VP8, we have much better options now"). That's a 
core aspect of the Internet Standards Process.

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/

---

From: John Leslie <[email-masked]>
Date: Mon, 15 Dec 2014 14:24:09 -0500

> core aspect of the Internet Standards Process.

   This is, of course, true...

   But we don't obsolete a MTI because "we have much better options":
we obsolete a MTI because "nobody's using it anymore".

   We are all trusting, I hope, that VP9, H.265, etc. will "just be
used in preference" as soon as two endpoints support them.

   I don't expect to revisit the MTI selection... (That is what we
want, right?)

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 15 Dec 2014 14:37:41 -0700

> we obsolete a MTI because "nobody's using it anymore".

Actually we can obsolete an MTI for any reason we please, at long as 
there's IETF consensus to do so.

>     I don't expect to revisit the MTI selection...

I do. It's a question of when.

> (That is what we

Not as far as I can see.

Ten years ago if we'd had this discussion, H.261 might have been MTI. 
Ten years from now, H.264 will seem ancient, too.

I fully expect that someone in the IETF (perhaps not us) will revisit 
the MTI decision once we have better alternatives.

Peter

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Dec 2014 14:03:18 -0800

On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet <[email-masked]>
wrote:

> Not as far as I can see.
>
> Ten years ago if we'd had this discussion, H.261 might have been MTI. Ten
> years from now, H.264 will seem ancient, too.
>
> I fully expect that someone in the IETF (perhaps not us) will revisit the
> MTI decision once we have better alternatives.
>
> Peter
>

​The nice thing is that our current model allows us to have nice things
right away; as soon as they are in common, they may be selected by
negotiation.  What the MTI gives us is a way to avoid interoperability
failure.  So the key question isn't really "Is there something better?" but
"Is the current MTI so bad that folks aren't willing to use it, so we are
once again at risk of interoperability failure?".

Whenever we are at risk of interoperability failure, the IETF may have to
revisit the question.  But the future group will have an option we lack:
if nothing else seems more likely to be adopted, it can fall back on the
current MTI.  That may make the calculus a bit easier; we may also have
enough interoperability with some later codec that the answer will be
obvious.  I have no crystal ball, but I certainly hope we will not have to
go through this whole experience again.

regards,

Ted

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 15 Dec 2014 15:18:10 -0700

On 12/15/14, 3:03 PM, Ted Hardie wrote:
> On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Not as far as I can see.
>
>     Ten years ago if we'd had this discussion, H.261 might have been
>     MTI. Ten years from now, H.264 will seem ancient, too.
>
>     I fully expect that someone in the IETF (perhaps not us) will
>     revisit the MTI decision once we have better alternatives.
>
>     Peter
>
>
> failure.  So the key question isn't really "Is there something better?"
> but "Is the current MTI so bad that folks aren't willing to use it, so
> we are once again at risk of interoperability failure?".

Some folks have expressed a concern that whatever we choose as an MTI 
codec now must always be an MTI codec. I'm trying to allay that concern 
by saying that yes, indeed, we can change our MTI codec(s) in the future 
if we please (naturally, keeping interoperability in mind at that future 
time).

Peter

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Dec 2014 16:22:06 -0600

On 12/15/14 16:18, Peter Saint-Andre - &yet wrote:
> codec now must always be an MTI codec. I'm trying to allay that 
> concern by saying that yes, indeed, we can change our MTI codec(s) in 
> the future if we please (naturally, keeping interoperability in mind 
> at that future time).

I agree 100%, but I don't think we need to get consensus on what this 
effort might look like 10 years in the future. Let's leave tomorrow's 
battles for tomorrow, or we'll never make progress.

/a

---

From: John Leslie <[email-masked]>
Date: Mon, 15 Dec 2014 17:24:27 -0500

Peter Saint-Andre - &yet <[email-masked]> wrote:
>><snip>

   Technically, we "can"...

   In actual practice, though, as long as someone pipes up during
Last-Call saying "These folks are still using that!", we generally
back down from declaring things "Obsolete".

> I do. It's a question of when.

   Well, Peter _is_ younger than me... ;^)

   But this is a sign of a pretty serious disconnect between "old-fogies"
and "young-turks" that I'd like to call attention to:

   Young-Turks want to "do it right" and have a standard ensure the
best possible outcome; old-fogies have been-there, done-that, and
gotten-the-T-shirt -- and things never ended up the way we expected.

   Old-fogies view the world as a continuum where small changes add up
to big progress over time, but too-large changes get mired and wander
in the weeds, tiring everybody and usually leave misguided folks as
the last-men-standing.

   A wise friend once told me that the true problem with democracy is
that the results are unstable: when the electorate wants a change,
the resultant changes goes too far; and walking it back to the middle
"stable-ground" takes too long.

   This is a big part of why I "just don't get the hint" when the
majority disagrees with me -- and I prize the IETF consensus-process
whenever we can get it to work. And it's why I would have been perfectly
happy with H.261 as the Mandatory-To-Implement codec.

   We cannot be effective if we have to turn around next month and say
that VP9 must replace VP8 as MTI or H.265 must replace H.264. Market
forces _really_can_ be trusted to get the better codec(s) used in
preference to whatever we designate as MTI.

>> (That is what we want, right?)
> 
> Not as far as I can see.

   I honestly believe this "compromise" is getting majority approval
because folks are _really_ tired of the MTI discussions.

   But there _are_ young-turks who believe the MTI question is _so_
important that we have to discuss it every IETF-week until we reach
consensus-by-exhaustion.

   "Are we there yet?"

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 15 Dec 2014 15:24:56 -0700

> battles for tomorrow, or we'll never make progress.

Yes, that's why I'm now saying to leave out all future-oriented text. 
Those who want to influence better MTI decisions in the future can get 
involved with building better codecs today. :-)

Peter

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Dec 2014 16:45:00 -0600

> Yes, that's why I'm now saying to leave out all future-oriented text.

I take the point, but there is one key future-looking component of the 
current accord. Leaving it undocumented basically violates the agreement 
that many people have signed up for. As I pointed out in a previous 
message, this particular little wart is necessary [1], even if untidy.

Which basically points to a need to document this intention (which, as 
Sean pointed out, has a non-trivial body of precedent), and to hold the 
line against documenting any further intended decision trees.

I suppose we could, without harm, document obvious points of IETF 
process like "RFCs can be obsoleted by other RFCs, and those new RFCs 
can say anything that the IETF comes to consensus around," but I doubt 
it's useful to do so, and it seems somewhat outside the purview of this 
WG to do so anyway.

/a

____
[1] To put a finer point on the necessity I mention here: in the straw 
poll last year, this option *without* the forward-looking provision 
received a mere 9% of participants supporting it, with 53% actively 
opposing it. The forward-looking provision is basically the "special 
sauce" that makes this approach palatable for some significant number of 
WG participants.

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Mon, 15 Dec 2014 23:53:21 +0100

> the future if we please (naturally, keeping interoperability in mind
Perhaps that concern was created by the phrasing of the current
proposal/draft that MTI is not going to be revisited for browsers.

On the other hand, if this is going to be adopted (not to be
misinterpreted, I don't agree with this proposal), is a quite "ugly"
compromise, probably the most unclean rough consensus so far, nothing
that is backed up with technical merits. I find it more fair to make it
explicit that this was a "last resort" compromise, with a trigger for
revisiting. It will accelerate the process for a RF codec, when having a
clear benefit out of it -- what interest would be to push money on a new
RF codec when you have to implement a paid one anyhow.

Moreover, IETF has an affinity of stating backward compatibility (see
RFC3261/SIP doing that for RFC2543), there will be always enough people
asking for that to get in the same kind of debate like here.

Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Dec 2014 12:07:08 +0100

2014-12-15 23:03 GMT+01:00 Ted Hardie <[email-masked]>:
> The nice thing is that our current model allows us to have nice things right
> away; as soon as they are in common, they may be selected by negotiation.
> What the MTI gives us is a way to avoid interoperability failure.  So the
> key question isn't really "Is there something better?" but "Is the current
> MTI so bad that folks aren't willing to use it, so we are once again at risk
> of interoperability failure?".
>
> revisit the question.  But the future group will have an option we lack:  if
> nothing else seems more likely to be adopted, it can fall back on the

Hi Ted,

No mention to "royalty free", "licensing" or "patents" in your
comment, but just concerns about "what users use" and
"interoperability" and "fall back to current MTI codecs".

> but "Is the current MTI so bad that folks aren't willing to use it, so we are once again at risk
> of interoperability failure?".

And is it better to depend on Cisco's benevolence forever and forcing
vendors and service providers to any kind of patent trolling from now
on? I cannot understand how you do not mention anything about these
important subjects.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Tue, 16 Dec 2014 10:03:03 -0500

Adam Roach <[email-masked]> wrote:
> that many people have signed up for...

   This bothers me enough, even after sleeping on it, to comment:

   We are watching a model of "back room deals" such as the US Congress
uses. I strongly believe we should reject this model.

   (That doesn't mean we need to reject the consensus called by a WGC.)

   The US Congress typically includes the text of every "important"
lobbyist in the final bill; and expects the congress-critters to vote
for it pretty much sight-unseen. The "leadership" tells the individual
members what to vote for.

   Here, not only do we have Adam Roach defending the back-room deal, we
have the WGCs failing to post an "official" version of the text we are
consenting to.

   I cry "TILT"! Let's have the WGC calling consensus publish the
text we're being asked to consent to.

   And I strongly recommend all of us read Pete Resnick's RFC 7282 "On
Consensus and Humming in the IETF", especally Section 3.

   I have heard a lot of points raised relating to this consensus call.
I have not heard much discussion about how to accomodate those concerns.
Instead we hear "Take it or leave it: this is the only deal which can
get enough votes!"

   Granted, Pete's RFC is strictly Informational: it cannot override
RFC 2418, which says:
]
] Consensus can be determined by a show of hands, humming, or any other
] means on which the WG agrees (by rough consensus, of course). Note
] that 51% of the working group does not qualify as "rough consensus"
] and 99% is better than rough. It is up to the Chair to determine if
] rough consensus has been reached.

   Thus this is not a "process appeal" -- the WGCs are entitled to
say "A strong majority agrees with the consensus of the Hawaii session"
and say that is consensus. But I might appeal if they don't tell us what
text we're agreeing to until _after_ declaring consensus.

   And I really do recommend we all try to follow Pete Resnick's advice
on consensus rather than turn this into an exercise in voting. The word
"consensus" _does_ have a meaning quite different from "2/3 vote".

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Dec 2014 07:08:00 -0800

> text we're being asked to consent to.

Huh? The relevant text is here:

https://tools.ietf.org/html/draft-ietf-rtcweb-video-03#section-5

-Ekr

---

From: John Leslie <[email-masked]>
Date: Tue, 16 Dec 2014 10:21:00 -0500

> https://tools.ietf.org/html/draft-ietf-rtcweb-video-03#section-5

   Perhaps it is; perhaps not: we'd have to listen to the audio to be
sure. Even after hearing the audio once, I'm not quite sure...

   Besides, Eric isn't the WGC calling consensus.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Dec 2014 16:35:14 +0100

> sure. Even after hearing the audio once, I'm not quite sure...

If the chairs say that the text in video-03 section 5 is the text they 
think they're calling consensus on, I'm happy to have consensus called 
on that.

It's close enough to what I believe we agreed on in Honolulu that I'm 
willing to consider the changes from what I remember editorial (the 
biggest difference I see offhand is the indentation of the 
future-pointing section, but there might have been grammar changes too.)

I agree that having the consensus-calling chair state that this text is 
what he's calling consensus on would be beneficial.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Dec 2014 07:36:07 -0800

> sure. Even after hearing the audio once, I'm not quite sure...

Again, huh?

The version that was discussed in Honolulu is on the slides here:

on page 14. The text isn't exactly the same but it's substantively
the same as what's in the draft. Needless to say, having WG
consensus on the substance and letting the editor wordsmith
the text is totally normal IETF process. I haven't heard anyone
who was at HNL and in favor of the text on the slides object
that Adam's text in the draft doesn't reflect those slides.

No, the chairs did here:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html

And this message clearly points to the slides above.

-Ekr

---

From: John Leslie <[email-masked]>
Date: Tue, 16 Dec 2014 11:25:34 -0500

>> sure. Even after hearing the audio once, I'm not quite sure...

   No, "still".

> the same as what's in the draft.

   You prove my point...

> Needless to say, having WG consensus on the substance and letting the
> editor wordsmith the text is totally normal IETF process.

   In some cases, yes. IMHO, this is not one of them. YMMV...

> I haven't heard anyone who was at HNL and in favor of the text on the
> slides object that Adam's text in the draft doesn't reflect those
> slides.

   Probably you haven't...

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html
] 
] From: Sean Turner <turners at ieca.com>
] 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.

   Actually, as I read this more carefully, that isn't a consensus call.
Sean goes on to dismiss the objections he heard in 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.

   Sean is stating his view of consensus-of-the-room.

] 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. The first agenda proposal for the WG included this
] topic, 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.

   Sean is defending the action of the WGCs.

] 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.

   Sean is specifically saying the text should be discussed on-list.

] 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.

   Sean is specifically saying the "trigger" should be discussed
on-list.

] 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.

   This _is_ calling for consensus.

   But Sean omitted saying _what_ text; and agreed that the exact text
may not have been clear to those in the room.

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

   (And folks have been doing so.)

   I have asked on-list for the exact text before raising my issues,
since my issues relate to the text, not the choosing to have two MTIs.

> And this message clearly points to the slides above.

   I don't find it helpful to attack the people who raise issues. YMMV.

   But what EKR thinks really doesn't matter. He is not a WGC.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Dec 2014 08:52:47 -0800

>    In some cases, yes. IMHO, this is not one of them. YMMV...

Indeed it does, since I have *never* heard of such a case where
the editor had no discretion to change the text in purely editorial
ways (subject to WG consensus of course). Feel free to cite one
if you have one.

> > slides object that Adam's text in the draft doesn't reflect those

To the best of my knowledge it hasn't happened. Can you cite anyone
who has so objected.

> Sean goes on to dismiss the objections he heard in the room:

He's addressing them. What exactly is the problem with this?

>    Sean is specifically saying the "trigger" should be discussed

I don't read this this way at all, Rather he's saying that in the future we
can update the RFC. But yes, we can discuss the trigger on-list. Do you
have some substantive objection that wasn't raised in HNL and/or
hasn't been discussed to death here?

> may not have been clear to those in the room.

Huh? The "proposed text" that was discussed in HNL is on the slide and
that's what's being referred to here. Adam edited text which is
substantially
the same into the draft.

> since my issues relate to the text, not the choosing to have two MTIs.

As I pointed out in my original message, that text is in Adam's draft.

Again, it's totally procedurally regular to have rough consensus on text in
the WG meeting and on the list and then have the editor edit in
substantively
the same text to the draft. If you think there is some respect in which
those
two blocks of text are not in fact the same, please point to it. Otherwise,
this is just dilatory.

Ironic that you would complain about "attack"s in a thread where you
started out by attacking Adam Roach and here say "what EKR thinks
really doesn't matter"

-Ekr

---

From: John Leslie <[email-masked]>
Date: Tue, 16 Dec 2014 12:03:06 -0500

> started out by attacking Adam Roach and here say "what EKR thinks

   Folks, please excuse me for deciding not to respond.

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Tue, 16 Dec 2014 19:26:13 +0000

From: rtcweb [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Tuesday, December 16, 2014 11:53 AM
To: John Leslie
Cc: [email-masked]
Subject: Re: [rtcweb] revisiting MTI

 I think what has not been discussed is a differentiated text for both codecs.
VP8 to be deprecated if failing to meet RF statements from proponents
H264 to be deprecated when not used anymore by legacy services in accordance with H264 proponents statements

Gaëlle

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Tue, 16 Dec 2014 19:31:42 +0000

I have little confidence that the choice between H265 and VP9 will be easier than it is today between VP8 and H264.
Are we going to multiply similarly performing codecs  going forward (in the spec or in practice) or be stuck with mandatory low performing codecs because we cannot make better decision?
Time frame for H265 / VP9  is up to two years from now
And possibly the timeframe for H.266/Dalaa is four years from now

This is one more drawback of the proposed text for MTI, not only it multiplies encoders and decoders to be supported but  can prevent the evolution of webrtc toward more advances codecs. (assuming we will not require 4 or 6 encoders and 4 or 6 decoders to be supported by every single endpoints. Two MTI seems largely enough, no?).

Gaëlle

On Tue, Dec 16, 2014 at 8:25 AM, John Leslie <[email-masked]<mailto:[email-masked]>> wrote:
Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
> On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <[email-masked]<mailto:[email-masked]>> wrote:

   Probably you haven't...

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html
]
] From: Sean Turner <turners at ieca.com<http://ieca.com>>

] 3) Trigger:

Huh? The "proposed text" that was discussed in HNL is on the slide and
that's what's being referred to here. Adam edited text which is substantially
the same into the draft.

Again, it's totally procedurally regular to have rough consensus on text in
the WG meeting and on the list and then have the editor edit in substantively
the same text to the draft. If you think there is some respect in which those
two blocks of text are not in fact the same, please point to it. Otherwise,
this is just dilatory.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Dec 2014 11:31:19 -0800

On Tue, Dec 16, 2014 at 11:26 AM, Gaelle Martin-Cocher <
[email-masked]> wrote:
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Eric
> Rescorla
> *Sent:* Tuesday, December 16, 2014 11:53 AM
> *To:* John Leslie
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] revisiting MTI
>
>
>
>
> H264 to be deprecated when not used anymore by legacy services in
> accordance with H264 proponents statements
>
>
>
I would not be in favor of either of these changes.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 16 Dec 2014 14:32:30 -0500

> accordance with H264 proponents statements
How about
VP8 to be depreciated if it fails to pass the ISO or other standardization
process or if licensing is confirmed in court to be a non royalty free.
H264 to be depreciated if VP8 passes the standardization process and
confirmed to be royalty free, unless H264 becomes royalty free as well?
_____________
Roman Shpount

---

From: David Singer <[email-masked]>
Date: Tue, 16 Dec 2014 11:33:09 -0800

> On Dec 16, 2014, at 7:35 , Harald Alvestrand <[email-masked]> wrote:
> 
> If the chairs say that the text in video-03 section 5 is the text they think they're calling consensus on, I'm happy to have consensus called on that.
> 
> It's close enough to what I believe we agreed on in Honolulu that I'm willing to consider the changes from what I remember editorial (the biggest difference I see offhand is the indentation of the future-pointing section, but there might have been grammar changes too.)
> 
> I agree that having the consensus-calling chair state that this text is what he's calling consensus on would be beneficial.

Unless I am being blind or lacking sufficient coffee, there is a problem:

"For the definitions of "WebRTC Brower," "WebRTC Non-Browser", and
   "WebRTC-Compatible Endpoint" as they are used in this section, please
   refer to [
I-D.ietf-rtcweb-overview
]."

Except I can’t find the text “non-browser” in the referenced document.  (And I don’t formally know what a Brower is either :-( [typo]).

If it means WebRTC Device, then this sentence comes into play

"All WebRTC browsers (UAs) are WebRTC devices, so any requirement on a
   WebRTC device also applies to a WebRTC browser.”

?

David Singer

---

From: Sean Turner <[email-masked]>
Date: Tue, 16 Dec 2014 14:34:29 -0500

John,

This is normal IETF process.  We had a session in Hawaii, we had a
consensus call, and now I'm confirming it on the list as well as
asking for any unaddressed issues to be raised.

The text on which I am are calling for consensus is 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]). Specifically:

  1. WebRTC User Agents (Browsers) MUST implement both VP8 and H.264.

  2. WebRTC devices (Non-Browsers) MUST implement both VP8 and
  H.264. If compelling evidence arises that one of the codecs is
  available for use on a royalty-free basis, such as all IPR
  declarations known for the codec being of (IETF) Royalty-Free or
  (ISO) type 1, the IETF will change this normative statement to
  indicate that only that codec is required.

The definitions of these terms are found on slide 12.

Note that there was a 3rd bullet but as noted in [2] and on slide 14
of [4], it’s really a throw away statement because it’s more of an
observation that WebRTC-compatible endpoints are free to whatever they
want.

My original message also included a summary of the major issues that
were raised at the meeting. Obviously, the numbered points are
summaries but I do consider those to be an unbiased summary of the
conversation that took place at the mic. As chair, I'm asking that we
not continue to rehash discussion on those points because both sides
of each numbered point were clearly articulated.  In other words, we
need not  bike shed on one those topics any longer unless something
new is raised.

spt

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Dec 2014 20:35:28 +0100

+1

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Dec 2014 11:38:01 -0800

On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher <
[email-masked]> wrote:
>
>  I have little confidence that the choice between H265 and VP9 will be
> easier than it is today between VP8 and H264.
>
> Are we going to multiply similarly performing codecs  going forward (in
> the spec or in practice) or be stuck with mandatory low performing codecs
> because we cannot make better decision?
>

It's important to remember that the requirement for an MTI codec
is to guarantee basic interoperability. I would not imagine that we
would define a new required codec unless it was not just technically
superior but also definitively RF in the sense contemplated by Adam's
text.

-Ekr

> This is one more drawback of the proposed text for MTI, not only it
> multiplies encoders and decoders to be supported but  can prevent the
> evolution of webrtc toward more advances codecs. (assuming we will not
> require 4 or 6 encoders and 4 or 6 decoders to be supported by every single
> endpoints. Two MTI seems largely enough, no?).
>
>
>
> Gaëlle
>
>
>

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Tue, 16 Dec 2014 19:42:09 +0000

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Monday, December 15, 2014 5:45 PM
To: Peter Saint-Andre - &yet; Ted Hardie
Cc: [email-masked]
Subject: Re: [rtcweb] revisiting MTI

____
[1] To put a finer point on the necessity I mention here: in the straw poll last year, this option *without* the forward-looking provision received a mere 9% of participants supporting it, with 53% actively opposing it. The forward-looking provision is basically the "special sauce" that makes this approach palatable for some significant number of WG participants.

Since last year the situation has changed drastically with regards to codec access. I don't believe pointing at previous results make any sense and we could be very surprised if we were to ask again the same questions.
Gaëlle

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Tue, 16 Dec 2014 19:56:05 +0000

I am not sure on what you are basing your opinion.
Waiting for an RF technically superior codec might not be pragmatic and can indeed prevent any evolution of WebRTC codec for a long time.
Deprecating MTI can be done in steps (e.g. become SHOULD, then MAY)

If this MTI text prevents codec evolution, this is a serious issue.
Gaëlle

From: Eric Rescorla [mailto:[email-masked]]
Sent: Tuesday, December 16, 2014 2:38 PM
To: Gaelle Martin-Cocher
Cc: John Leslie; [email-masked]
Subject: Re: [rtcweb] revisiting MTI

On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher <[email-masked]<mailto:[email-masked]>> wrote:
I have little confidence that the choice between H265 and VP9 will be easier than it is today between VP8 and H264.
Are we going to multiply similarly performing codecs  going forward (in the spec or in practice) or be stuck with mandatory low performing codecs because we cannot make better decision?

-Ekr

Gaëlle

From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Tuesday, December 16, 2014 11:53 AM
To: John Leslie
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] revisiting MTI

   Probably you haven't...

]

] 3) Trigger:

-Ekr

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Dec 2014 19:56:04 +0000

Forget it.

You are making an attempt to reduce the entire issue to IPR, and the discussion prior to the last meeting had been wider that that, including issues of interoperability with endpoints outside webRTC.

As far as I am concerned an IPR free codec is irrelevant if I cannot talk to the endpoints I need to, and just concentrating on the webrtc community as the available endpoint may meet some deployers use cases, but not others.

Keith

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: 16 December 2014 19:35
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] revisiting MTI

+1

On 16 Dec 2014 20:32, "Roman Shpount" <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Dec 16, 2014 at 2:26 PM, Gaelle Martin-Cocher <[email-masked]<mailto:[email-masked]>> wrote:

How about
VP8 to be depreciated if it fails to pass the ISO or other standardization process or if licensing is confirmed in court to be a non royalty free.
H264 to be depreciated if VP8 passes the standardization process and confirmed to be royalty free, unless H264 becomes royalty free as well?
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Dec 2014 11:59:22 -0800

>  I am not sure on what you are basing your opinion.

As I said, the purpose of an MTI is to provide basic interop.

 Waiting for an RF technically superior codec might not be pragmatic and
> can indeed prevent any evolution of WebRTC codec for a long time.
>

It doesn't prevent codec evolution. That's why we have negotiation. Browsers
are free to implement non-MTI codecs and I would anticipate that they
will do so.

-Ekr

 Gaëlle
>
>
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Tuesday, December 16, 2014 2:38 PM
> *To:* Gaelle Martin-Cocher
> *Cc:* John Leslie; [email-masked]
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Dec 2014 14:10:00 -0600

On 12/16/14 13:33, David Singer wrote:
> Except I can’t find the text “non-browser” in the referenced document.

Huh. I see the following (cf. 
<https://tools.ietf.org/html/draft-ietf-rtcweb-overview-13#section-2.2>):

>     o  A WebRTC non-browser is something that conforms to the protocol
>        specification, but does not claim to implement the Javascript API.
>        This can also be called a "WebRTC device" or "WebRTC native
>        application".

In terms of the text you cited about the relationship between terms, 
which is an outdated version of:
>     All WebRTC browsers are WebRTC endpoints, so any requirement on a
>     WebRTC endpoint also applies to a WebRTC browser.

If you think you see somewhere that we're imposing a requirement on an 
endpoint that doesn't *also* apply to a browser, please call it out 
explicitly.

If this is some oblique attempt to complain about the reference to the 
-12 version of the overview document [1]  by pretending to be daft [2]: 
you're not fooling anyone, so you can stop it. You may be misguided, but 
we all know that you're not stupid.

/a

____
[1] Rather than the -13 version that came out three days after *this* 
document
[2] As you did with the "Brower" typo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Dec 2014 20:17:55 +0000

Hi,

The decision to use that terminology (browser, non-browser and compliant) was made during the first RTCWEB session at the same IETF meeting, when Harald presented the status of the overview draft.

I assume Harald will implement that decision into the next version of the overview draft.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 16 December 2014 22:10
To: David Singer; Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] revisiting MTI

Huh. I see the following (cf. <https://tools.ietf.org/html/draft-ietf-rtcweb-overview-13#section-2.2><https://tools.ietf.org/html/draft-ietf-rtcweb-overview-13#section-2.2>):

      application".

In terms of the text you cited about the relationship between terms, which is an outdated version of:

If you think you see somewhere that we're imposing a requirement on an endpoint that doesn't *also* apply to a browser, please call it out explicitly.

If this is some oblique attempt to complain about the reference to the -12 version of the overview document [1]  by pretending to be daft [2]: you're not fooling anyone, so you can stop it. You may be misguided, but we all know that you're not stupid.

/a

____
[1] Rather than the -13 version that came out three days after *this* document
[2] As you did with the "Brower" typo

---

From: David Singer <[email-masked]>
Date: Tue, 16 Dec 2014 12:18:39 -0800

> On Dec 16, 2014, at 12:10 , Adam Roach <[email-masked]> wrote:
> 
> Huh. I see the following (cf. <https://tools.ietf.org/html/draft-ietf-rtcweb-overview-13#section-2.2>):

Ah, the document linked to -12, which is different. I just followed the links/references.

> If you think you see somewhere that we're imposing a requirement on an endpoint that doesn't *also* apply to a browser, please call it out explicitly.

no, quite the reverse.  If all browsers are also devices, then we only need to state the requirements for browsers if they differ from devices, and they don’t, do they?

> If this is some oblique attempt to complain about the reference to the -12 version of the overview document [1]  by pretending to be daft [2]: you're not fooling anyone, so you can stop it. You may…

seriously, I just (quickly) reviewed the text and references as cited as being the ones people are asking for consensus on.

David Singer

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Tue, 16 Dec 2014 20:35:08 +0000

From: Eric Rescorla [mailto:[email-masked]]
Sent: Tuesday, December 16, 2014 2:59 PM
To: Gaelle Martin-Cocher
Cc: John Leslie; [email-masked]
Subject: Re: [rtcweb] revisiting MTI

On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Cocher <[email-masked]<mailto:[email-masked]>> wrote:
I am not sure on what you are basing your opinion.

That point is clear to all.  Sorry I was referring to “I would not imagine that we
would define a new required codec unless it was not just technically
superior but also definitively RF in the sense contemplated by Adam's
text.”
And I am not sure that holds true.

It doesn't prevent codec evolution. That's why we have negotiation. Browsers
are free to implement non-MTI codecs and I would anticipate that they
will do so.
And non-browser as well, but the spec will let us stuck for ever with low performing codec.

Gaëlle

-Ekr

Gaëlle

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 16, 2014 2:38 PM
To: Gaelle Martin-Cocher
Cc: John Leslie; [email-masked]<mailto:[email-masked]>

-Ekr

Gaëlle

   Probably you haven't...

]

] 3) Trigger:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Dec 2014 12:40:10 -0800

On Tue, Dec 16, 2014 at 12:35 PM, Gaelle Martin-Cocher <
[email-masked]> wrote:
> *Sent:* Tuesday, December 16, 2014 2:59 PM
Making a new non-RF codec MTI doesn't enhance basic interop.

> And non-browser as well, but the spec will let us stuck for ever with low

This doesn't follow at all. The IETF is free to in the future designate some
other codec as MTI and these not and this text doesn't preclude that.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 16 Dec 2014 15:42:03 -0500

On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:
>
>  Forget it.
>
> You are making an attempt to reduce the entire issue to IPR, and the
> discussion prior to the last meeting had been wider that that, including
> issues of interoperability with endpoints outside webRTC.
>
> As far as I am concerned an IPR free codec is irrelevant if I cannot talk
> to the endpoints I need to, and just concentrating on the webrtc community
> as the available endpoint may meet some deployers use cases, but not others.
>

There is no such thing as IPR free codec, unless you are talking about
H.261 or MJPEG where IPR has expired. What we are looking for is a video
codec with an acceptable quality (both VP8 and H.264 qualify) and
reasonable licensing (both VP8 and H.264 have serious issues here). If it
is confirmed the VP8 licensing issues are resolved (i.e. it went through
the standardization process, all IPR declaration against it which prevent
licensing are confirmed to not apply in court or due to some sort of
licencing agreement), then VP8 is clearly superior. If H.264 fixes its
licensing (i.e. present a clear, published, no royalty licensing terms with
no use restrictions), it can be a superior codec. Legacy interop support is
important, but to me at least, it is secondary to unrestricted use. Please
see Opus vs AMR-WB+ for clear similarities.

Also, VP9 or H.265 would clearly  improve video quality, but both VP8 and
H.264 with the current connection speeds allow for the highly usable video
communications. I think that quality wise, either one of VP8 and H.264 can
serve as usable MTI for a lot longer then the next two years or whatever
time is required for the next great video codec to be developed. Especially
in another 5-6 years when all the IPR on these codecs will expire.
_____________
Roman Shpount

---

From: tim panton <[email-masked]>
Date: Tue, 16 Dec 2014 21:52:05 +0000

> On 16 Dec 2014, at 20:42, Roman Shpount <[email-masked]> wrote:
> 
> 
> There is no such thing as IPR free codec, unless you are talking about H.261 or MJPEG where IPR has expired. What we are looking for is a video codec with an acceptable quality (both VP8 and H.264 qualify) and reasonable licensing (both VP8 and H.264 have serious issues here).

When does the H264/VP8 IPR expire? It is clear this discussion will be kept going around in circles ‘till then.

T.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Dec 2014 17:30:08 -0500

> no, quite the reverse.  If all browsers are also devices, then we only need to state the requirements for browsers if they differ from devices, and they don’t, do they?

[BA] Let us get real.  The idea that codecs are holding back WebRTC web site development is entirely bogus. 

Today developers are building WebRTC mobile apps that interoperate across platforms, based on a codec chosen by the developer. This works well enough that there are at least half a dozen major apps, each serving (tens? hundreds?) of millions of users. 

What we have NOT seen is a comparable blossoming of Web sites based on WebRTC. Clearly this cannot have to do with codecs because both WebRTC-enabled browsers support a common codec. So at present, a developer can build a mobile app and web site using VP8 that interoperates.

Yet that has not been enough. It doesn't take a genius to figure out why. The IETF RTCWEB protocols are relatively mature (with the exception of new stuff like ICE mobility) since they are mostly based on RFCs that were already implemented in working open source prior to WebRTC. So give a mobile developer open source code that works and they will figure out the APIs and what fixes/customizations they need to make it work. 

However the browser model is very different. The browser app developer typically cannot compile their own browser or fix browser bugs so they have to live with what is there. Today's polyfills typically only work for audio so writing a multi-browser video app that supports multiple video streams is a nightmare even without a codec problem. 

Imposing a dual MTI requirement will not solve this problem and in fact is likely to make it worse, because I fully expect that video capabilities will differ markedly between implementations. So today with the same codec we see browsers differ in multi stream, simulcast and SVC capabilities. From these three dimensions, adding more codecs is likely to add to the dimensions of difference on several more dimensions. Care to guess how much more time it will take to polyfill all the *new* differences?

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Dec 2014 17:33:34 -0500

> When does the H264/VP8 IPR expire? It is clear this discussion will be kept going around in circles ‘till then.

[BA] Oh my. Aren't you the optimist? I fully expect the debate to continue beyond that point because by then we will have moved on to a debate about next generation MTI and how soon we can expire the existing proposal (assuming it isn't OBE).

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Dec 2014 16:34:50 -0600

On 12/16/14 16:30, Bernard Aboba wrote:
> Today's polyfills typically only work for audio...

What are you talking about?

/a

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Dec 2014 17:39:04 -0500

Show me a polyfill that works for multi-stream video. 

> On Dec 16, 2014, at 5:34 PM, Adam Roach <[email-masked]> wrote:
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Dec 2014 14:43:51 -0800

On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba <[email-masked]>
wrote:

> However the browser model is very different. The browser app developer
> typically cannot compile their own browser or fix browser bugs so they have
> to live with what is there. Today's polyfills typically only work for audio
> so writing a multi-browser video app that supports multiple video streams
> is a nightmare even without a codec problem.
>
>
​So, can I confirm here that you mean polyfill in the same way ​Remy Sharp
did?  That is, a piece of Javascript that replicates an API and
functionality that the browser lacks?

And so you are asserting that there are downloadable Javascript bits that
replicate both the audio functionality and relevant API, but there are no
downloadable Javascript bits that replicate the video functionality and
relevant API?

Have I gotten your meaning?

Ted

---

From: Roman Shpount <[email-masked]>
Date: Tue, 16 Dec 2014 17:44:14 -0500

On Tue, Dec 16, 2014 at 5:33 PM, Bernard Aboba <[email-masked]>
wrote:
> [BA] Oh my. Aren't you the optimist? I fully expect the debate to continue
> beyond that point because by then we will have moved on to a debate about
> next generation MTI and how soon we can expire the existing proposal
> (assuming it isn't OBE).
>
>
The way it goes we would be discussing remote holographic presence before
this issue is resolved.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Dec 2014 18:32:47 -0500

It is possible to write a single stream audio/video app that runs on any browser.  But if you include the video features that enable collaborative Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there are no polyfills today.  So these Web apps need to be written for a particular browser.  By now people are getting used to installing a browser to run their favorite WebRTC web app. That's not the IETF's problem really (WebRTC protocols and open source SDKs implementing same are in much better shape, and are being widely used). But it is indicative of the mountain that WebRTC needs to be climb to be a successful Web standard. 

> On Dec 16, 2014, at 5:43 PM, Ted Hardie <[email-masked]> wrote:
> 
>> On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba <[email-masked]> wrote:
> ​So, can I confirm here that you mean polyfill in the same way ​Remy Sharp did?  That is, a piece of Javascript that replicates an API and functionality that the browser lacks?
> 
> And so you are asserting that there are downloadable Javascript bits that replicate both the audio functionality and relevant API, but there are no downloadable Javascript bits that replicate the video functionality and relevant API?
>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 16 Dec 2014 19:43:39 -0500

On 12/16/2014 3:42 PM, Roman Shpount wrote:
> On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     As far as I am concerned an IPR free codec is irrelevant if I
>     cannot talk to the endpoints I need to, and just concentrating on
>     the webrtc community as the available endpoint may meet some
>     deployers use cases, but not others.
>
>
> H.261 or MJPEG where IPR has expired. What we are looking for is a 
> video codec with an acceptable quality (both VP8 and H.264 qualify) 
> and reasonable licensing (both VP8 and H.264 have serious issues 
> here). If it is confirmed the VP8 licensing issues are resolved (i.e. 
> it went through the standardization process, all IPR declaration 
> against it which prevent licensing are confirmed to not apply in court 
> or due to some sort of licencing agreement), then VP8 is clearly 
> superior. If H.264 fixes its licensing (i.e. present a clear, 
> published, no royalty licensing terms with no use restrictions), it 
> can be a superior codec. Legacy interop support is important, but to 
> me at least, it is secondary to unrestricted use. Please see Opus vs 
> AMR-WB+ for clear similarities.

+1.  "IPR-free" barely would even apply to H.261 - you'd also have avoid 
any of the (patented) tricks on the encoding side that have shown up 
during later codec evolution from that  - but you always *can* avoid 
them by basing on ancient implementations.

> Also, VP9 or H.265 would clearly  improve video quality, but both VP8 
> and H.264 with the current connection speeds allow for the highly 
> usable video communications. I think that quality wise, either one of 
> VP8 and H.264 can serve as usable MTI for a lot longer then the next 
> two years or whatever time is required for the next great video codec 
> to be developed. Especially in another 5-6 years when all the IPR on 
> these codecs will expire.

+1 (Well, most of the patents on the decoder side and basic 
non-performant encoders may expire.  Patents are weird.)

We have better things to do...

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Wed, 17 Dec 2014 01:43:37 +0000

+1    There is no such thing as a guaranteed IPR free codec.

From: rtcweb [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Tuesday, December 16, 2014 12:42 PM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [rtcweb] revisiting MTI

On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
Forget it.

There is no such thing as IPR free codec, unless you are talking about H.261 or MJPEG where IPR has expired. What we are looking for is a video codec with an acceptable quality (both VP8 and H.264 qualify) and reasonable licensing (both VP8 and H.264 have serious issues here). If it is confirmed the VP8 licensing issues are resolved (i.e. it went through the standardization process, all IPR declaration against it which prevent licensing are confirmed to not apply in court or due to some sort of licencing agreement), then VP8 is clearly superior. If H.264 fixes its licensing (i.e. present a clear, published, no royalty licensing terms with no use restrictions), it can be a superior codec. Legacy interop support is important, but to me at least, it is secondary to unrestricted use. Please see Opus vs AMR-WB+ for clear similarities.

Also, VP9 or H.265 would clearly  improve video quality, but both VP8 and H.264 with the current connection speeds allow for the highly usable video communications. I think that quality wise, either one of VP8 and H.264 can serve as usable MTI for a lot longer then the next two years or whatever time is required for the next great video codec to be developed. Especially in another 5-6 years when all the IPR on these codecs will expire.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Dec 2014 16:24:40 +0100

On 12/17/2014 12:32 AM, Bernard Aboba wrote:
> It is possible to write a single stream audio/video app that runs on 
> any browser.  But if you include the video features that enable 
> collaborative Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. 
> then yes there are no polyfills today.  So these Web apps need to be 
> written for a particular browser.  By now people are getting used to 
> installing a browser to run their favorite WebRTC web app. That's not 
> the IETF's problem really (WebRTC protocols and open source SDKs 
> implementing same are in much better shape, and are being widely 
> used). But it is indicative of the mountain that WebRTC needs to be 
> climb to be a successful Web standard.

Isn't it rather indicative of the fact that a couple of Web browser 
vendors haven't chosen to ship WebRTC support yet?

We'll get the differences between Firefox and Chrome/Opera ironed out 
eventually. But it's hard to emulate "deep" functionality like this on 
top of a browser that refuses to support it.

>
> On Dec 16, 2014, at 5:43 PM, Ted Hardie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba 
>>     On Dec 16, 2014, at 3:18 PM, David Singer <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     However the browser model is very different. The browser app
>>     developer typically cannot compile their own browser or fix
>>     browser bugs so they have to live with what is there. Today's
>>     polyfills typically only work for audio so writing a
>>     multi-browser video app that supports multiple video streams is a
>>     nightmare even without a codec problem.
>>
>>
>> ​ So, can I confirm here that you mean polyfill in the same way ​Remy 
>> Sharp did?  That is, a piece of Javascript that replicates an API and 
>> And so you are asserting that there are downloadable Javascript bits 
>> that replicate both the audio functionality and relevant API, but 
>> there are no downloadable Javascript bits that replicate the video 
>> functionality and relevant API?
>>

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 17 Dec 2014 17:39:39 +0100

> It is possible to write a single stream audio/video app that runs on any browser.  But if you include the video features that enable collaborative Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there are no polyfills today.  So these Web apps need to be written for a particular browser.  By now people are getting used to installing a browser to run their favorite WebRTC web app.

Based on my experience, if you stick to the Maximum Common Divisor (e.g., by avoiding SSRC multiplexing, on hold, some forms of bundling, etc) you can still offer a rich end-user experience on a wide set of browsers (Chrome, Firefox, Opera at least). This is indeed what we try and do with the 'stable' version of Meetecho (which you probably forgot to mention). BTW, I think this is unavoidable as long as the standardization process has not yet reached the steady state.

Simon

> That's not the IETF's problem really (WebRTC protocols and open source SDKs implementing same are in much better shape, and are being widely used). But it is indicative of the mountain that WebRTC needs to be climb to be a successful Web standard. 
> 
> On Dec 16, 2014, at 5:43 PM, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 16, 2014, at 3:18 PM, David Singer <[email-masked] <mailto:[email-masked]>> wrote:
>> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Dec 2014 08:55:49 -0800

It's also worth observing that a lot of the problem with multiple stream
polyfills
isn't a result of the state of standardization but just that Firefox
doesn't do
it yet, so you have to simulate with multiple PCs. We're working on it now,
though.

-Ekr

On Wed, Dec 17, 2014 at 8:39 AM, Simon Pietro Romano <[email-masked]>
wrote:
>
> It is possible to write a single stream audio/video app that runs on any
> browser.  But if you include the video features that enable collaborative
> Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there are
> no polyfills today.  So these Web apps need to be written for a particular
> browser.  By now people are getting used to installing a browser to run
> their favorite WebRTC web app.
>
>
> Based on my experience, if you stick to the Maximum Common Divisor (e.g.,
> by avoiding SSRC multiplexing, on hold, some forms of bundling, etc) you
> can still offer a rich end-user experience on a wide set of browsers
> (Chrome, Firefox, Opera at least). This is indeed what we try and do with
> the 'stable' version of Meetecho (which you probably forgot to mention).
> BTW, I think this is unavoidable as long as the standardization process has
> not yet reached the steady state.
>
> Simon
>
> That's not the IETF's problem really (WebRTC protocols and open source
> SDKs implementing same are in much better shape, and are being widely
> used). But it is indicative of the mountain that WebRTC needs to be climb
> to be a successful Web standard.
>

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Fri, 19 Dec 2014 00:55:27 +0100

I am not supporting the proposal.

The licensing around H264 is a mess, blocking safe usage in open source
software (which had really big impact in the evolution of open web &
internet) that cannot control its distribution. Moreover, it is imposing
unnecessary costs, or in other words, even worse, a revenue to a
particular group of interests, and exposing new players to unknown
risks. These are serious impediments for innovation and not something I
would expect from an open specification from IETF.

On some of the bits of the proposal: mandating that the two codecs stay
mandatory is odd and somehow overruling IETF system where a new RFC can
obsolete a new RFC. Different requirements for different entities will
create a mess of terminologies (e.g., how an app implementing JS API and
one codec is going to be presented: a *web browser* but not a *webrtc
browser*, just a *webrtc device*).

Ending up now with an bad solution for present and the future, just to
close the door on this topic, is not appropriate for how open Internet
communications are supposed to evolve. Better let time to come with a
better solution and applications negotiate what they like meanwhile
(even with no MTI video codec so far, there are successful webrtc services).

Daniel

Ps. I reiterate my opinions on this thread, because I expressed them on
other threads of recent discussions, which may count or not.

On 09/12/14 21:31, Bernard Aboba wrote:
> Setting aside my reservations about the dual-MTI requirement for
> browsers, I also oppose the other elements of the proposal. 
>
> should only be required to support one of them (their choice).   If
> this change were made the trigger clause would serve no purpose, other
> than to keep this discussion going ad-infinitum.  So I oppose that as
> well. 
>
>     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 <http://ca.linkedin.com/in/lagerway> | **Hookflash
>     <http://hookflash.com/>** | 1 (855)* *Hookflash ext. 2 | Twitter
>     <http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> **
>     ********
>
>         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]).
>
>         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:
>         this meeting was provided on short notice and did not provide
>         some the opportunity to attend in person.
>
>         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.
>
>         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:
>
>         current proposal can be changed through the consensus process
>         at any other time.
>
>
>         rough consensus in the room to add (aka “shove”) the proposed

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 22 Dec 2014 21:31:16 +0100

2014-12-19 0:55 GMT+01:00 Daniel-Constantin Mierla <[email-masked]>:
> unnecessary costs, or in other words, even worse, a revenue to a particular
> group of interests, and exposing new players to unknown risks. These are
> serious impediments for innovation and not something I would expect from an
> open specification from IETF.

+1, but WONTFIX. It seems that there is already consensus and "there
are not open issues to address", which makes sense given than the open
source related issue that you mention hasn't been ever discussed here
so it cannot be an open issue.

-- 
Iñaki Baz Castillo
<[email-masked]>