Subject: [rtcweb] On the topic of MTI video codecs

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2013 12:55:11 -0500

As Jonathan mentioned earlier, this morning Cisco announced that it will 
be open sourcing an H.264 implementation as well as gratis binary 
modules compiled from that source and hosted by Cisco for download. 
Mozilla will be modifying Firefox to support H.264 by downloading 
Cisco's binary module.

In previous discussions of which codec should be MTI, Mozilla has stated 
that it could not accept H.264 as MTI, primarily because we could not 
deliver H.264 in Firefox. That obstacle is now removed, and we can 
accept either codec as MTI.

Mozilla intends to continue supporting VP8 in WebRTC, but we will also 
support H.264.

/a

---

From: Leon Geyser <[email-masked]>
Date: Wed, 30 Oct 2013 20:20:20 +0200

Unfortunately like Jonathan pointed out H.264 will only be able to be used
royalty free on certain(most popular) platforms.
To be able to avoid negotiation failure we need a MTI codec that every
potential now/future browser would be able to implement freely.
I like what Cisco did, but the solution seems a bit half-baked.

On 30 October 2013 19:55, Adam Roach <[email-masked]> wrote:

> be open sourcing an H.264 implementation as well as gratis binary modules
> compiled from that source and hosted by Cisco for download. Mozilla will be
> modifying Firefox to support H.264 by downloading Cisco's binary module.
>
> deliver H.264 in Firefox. That obstacle is now removed, and we can accept
> either codec as MTI.
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 30 Oct 2013 18:30:42 +0000

" As long as there are ports of the source code and automatic build scripts contributed as part of the open source, we do not see difficulties in adding additional platforms."

	Jeremy Laurenson
Distinguished Systems Engineer
Global UCC Strategy Group
+1 408 894-1349
Video chat now.    	Join my bridge    	Or find more contact options... 
http://cs.co/jlaurens	http://cs.co/jlaurensbridge 
Business relevant Unified Communications use cases...

On Oct 30, 2013, at 2:20 PM, Leon Geyser <[email-masked]> wrote:

> Unfortunately like Jonathan pointed out H.264 will only be able to be used royalty free on certain(most popular) platforms.
> To be able to avoid negotiation failure we need a MTI codec that every potential now/future browser would be able to implement freely.
> As Jonathan mentioned earlier, this morning Cisco announced that it will be open sourcing an H.264 implementation as well as gratis binary modules compiled from that source and hosted by Cisco for download. Mozilla will be modifying Firefox to support H.264 by downloading Cisco's binary module.
> 
> In previous discussions of which codec should be MTI, Mozilla has stated that it could not accept H.264 as MTI, primarily because we could not deliver H.264 in Firefox. That obstacle is now removed, and we can accept either codec as MTI.
> 
> Mozilla intends to continue supporting VP8 in WebRTC, but we will also support H.264.
> 
> /a
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2013 13:30:41 -0500

On 10/30/13 13:20, Leon Geyser wrote:
> Unfortunately like Jonathan pointed out H.264 will only be able to be 
> used royalty free on certain(most popular) platforms.

Fortunately, as I pointed out in an earlier message, the stated 
intention of Cisco's project is to support as many platforms as the 
development community is willing to work on. In light of that fact: is 
there a specific existing and viable platform that you think cannot 
support H.264 already *and* cannot use the OpenH264 library?

If not, can you tell a credible story about how such a platform might arise?

/a

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 30 Oct 2013 18:33:44 +0000

On Oct 30, 2013, at 2:20 PM, Leon Geyser <[email-masked]<mailto:[email-masked]>> wrote:

On 30 October 2013 19:55, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
As Jonathan mentioned earlier, this morning Cisco announced that it will be open sourcing an H.264 implementation as well as gratis binary modules compiled from that source and hosted by Cisco for download. Mozilla will be modifying Firefox to support H.264 by downloading Cisco's binary module.

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

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

---

From: "Jeremy Laurenson (jlaurens)" <[email-masked]>
Date: Wed, 30 Oct 2013 18:33:44 +0000

Contribute away...

---

From: Leon Geyser <[email-masked]>
Date: Wed, 30 Oct 2013 21:08:54 +0200

http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.media.capture.audiovideocapturedevice.supportedvideoencodingformats%28v=vs.105%29.aspx
Playback of H.264 should be supported on all Windows Phones, but encoding
looks like it is device specific.
It may or may not return H.264, but in reality most Windows Phones probably
do support it. I am not sure.
I don't think it would be possible to download and use the Cisco library
though.

The future is uncertain. I have no idea if new platforms will popup without
H.264 support.

On 30 October 2013 20:30, Adam Roach <[email-masked]> wrote:

> Fortunately, as I pointed out in an earlier message, the stated intention
> of Cisco's project is to support as many platforms as the development
> community is willing to work on. In light of that fact: is there a specific
> existing and viable platform that you think cannot support H.264 already
> *and* cannot use the OpenH264 library?
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Oct 2013 14:17:06 -0500

On 10/30/13 14:08, Leon Geyser wrote:
> Playback of H.264 should be supported on all Windows Phones, but 
> encoding looks like it is device specific.
> It may or may not return H.264, but in reality most Windows Phones 
> probably do support it. I am not sure.

Given that Microsoft has been pushing pretty hard to make H.264 the 
WebRTC MTi video codec, I doubt they would neglect to support it in 
their own platform.

> I don't think it would be possible to download and use the Cisco 
> library though.

I don't know why you'd want to. Native platform support is probably 
hardware accelerated.

> The future is uncertain. I have no idea if new platforms will popup 
> without H.264 support.

I didn't ask you to predict whether one would. What I asked for was 
much, much easier. What I asked for was a non-laughable story around how 
such a platform might arise in a way that precludes using the Cisco library.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Oct 2013 13:19:02 -0600

On 10/30/13 1:08 PM, Leon Geyser wrote:

> The future is uncertain.

This we can all agree on.

The codecs we have today won't last forever, and new codecs will be
developed and deployed. H.264 matters for immediate interoperability,
but we simply can't know what will enable interoperability 5 or 10 or
15 years from now. Presumably an update to the relevant RFC will need
to happen at that point. Assuming that, in the uncertain future, the
IETF and W3C still exist. ;-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 30 Oct 2013 21:40:08 +0000

> I like what Cisco did, but the solution seems a bit half-baked.

I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thing we could possibly figure out on how to make the internet today be the best it can be for users.

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 30 Oct 2013 18:36:23 -0400

On 10/30/2013 05:40 PM, Cullen Jennings (fluffy) wrote:
> I think that Mozilla put it pretty nicely in their blog. What this 
> annoucement gives us is not a perfect world. Mozilla is working 
> towards a better future but in the mean time, this is the best
> thing we could possibly figure out on how to make the internet
> today be the best it can be for users.

For those who haven't read it, I also recommend Monty's post:
http://xiphmont.livejournal.com/61927.html

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 31 Oct 2013 10:35:49 +0100

> I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thi…

For the Open Source community in general I beleve this is a big move forward and I want to thank everyone involved in getting this done. It can not have been an easy internal struggle through all layers of the company. Everyone will benefit from it.

For us in the Asterisk community I believe this opens up for use of video in a whole new way. I've been struggling to find legal ways to do things like video IVR for many years. The experiences we get from working with this will lead to new applications, regardless of which codecs we use in the future.

This statement is outside of the discussion of MTI for webrtc though. I still haven't sorted up my views of that part of the discussion... 

/O

---

From: Silvia Pfeiffer <[email-masked]>
Date: Thu, 31 Oct 2013 23:11:31 +1100

> I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thi…

This is a very grand gesture of CISCO.

I'm just a bit cautious, since it looks too good to be true: have you
considered that MPEG LA could change the license conditions on H.264
next year and make this impossible?

Regards,
Silvia.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 31 Oct 2013 14:15:23 +0000

> next year and make this impossible?

Yes, I have deeply considered that including discussion with relevant lawyers. 

I do not see any path where significant changes could be be made that could stop this from continuing. Keep in mind that many of the companies in the MPEG LA 264 pool are in favor of just making H.264 RF for use on the internet. Theses same companies, and they include people like, cough, cisco, and apple, have to approve changes that happen in the future. I would not be surprised to see the discussion on future changes to the MEPG LA license be around just making the license pool RF. Or perhaps just moving the price of the cap up a bit. 

Now you can say, ok, that is way too good to be true, no big company would ever give away valuable IPR. Lets clear up one thing, the amount of money that any large company gets in royalties from 264 MPEG LA pool is so small it is a joke - and a quick back of the envelope estimate will show you the limits. But ask yourself this instead, Why does Cisco care about webrtc at all? what would a company like Cisco pay to MPEG LA to improve the ability for lots of companies, particularly small companies or open source projects, to be able to produce, consume, and distribute video on the internet? What would it take to make it so video on the internet was far more important to people's lives than watching cats on skateboards. 

This whole discussion reminds me of a real blast from the past. In 2000 Cisco acquired Vovida (where I worked) and open sourced 100% of the technology. People said said Cisco was nuts to acquire that and give it away for fee - the numbers were much larger than anything being discussed here. People like vonage starting using the code. People said "It's a trap" and included the appropriate star wars images - Cisco has patents on SIP and is going to get you for using the open source. Cisco did not go after people for using the software and companies like vonage effectively helped drive lots of voice traffic that resulted in good business for Cisco. Open source helped enable that. You might say that was then this is now but you might want to look at what we did this month - 2.7 billion for the Sourcefire, a company that's most interesting product is open source. 

Snort is not a trap, it's exactly what it seem. This is the same - Cisco wants there to be a video codec that can be widely used on the internet as it exists today - Cisco will continue to want that and will continue to pay MPEG LA to make that happen. 

Which leads of of course to why this codecs and not some other one. We don't believe VP8 is the one that works with the internet today and given the reasons have been on this before I don't want to reiterate here. I'd be doing a little dance of joy at the IETF microphone if Daala can meet their goals of better than existing codecs, royalty free, and wide adoption and I really hope that happens but it clear that is not here today and this is project still at early stage. I'm glad they are working on something better for the future. Older codecs like, just for example, H.263 might be easier / cheaper to get to be RF but, sadly they sort of blow chunks. I don't believe a business model like apple iTunes, Netflix streaming video, or even Skype could be successful in today's market if it had to use a codec like 263, or for that matter any of the older codecs - thus they don't really meet Cisco's goals of widespread viable codec people can use today.

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 31 Oct 2013 15:39:21 +0100

Il giorno Thu, 31 Oct 2013 14:15:23 +0000
"Cullen Jennings (fluffy)" <[email-masked]> ha scritto:

> 
> On Oct 31, 2013, at 6:11 AM, Silvia Pfeiffer
> <[email-masked]> wrote:
> 
> >>> Unfortunately like Jonathan pointed out H.264 will only be able
> >>> to be used royalty free on certain(most popular) platforms. To be
> >>> able to avoid negotiation failure we need a MTI codec that every
> >>> potential now/future browser would be able to implement freely. I
> >>> like what Cisco did, but the solution seems a bit half-baked.
> >>> 
> >> 
> > I'm just a bit cautious, since it looks too good to be true: have
> > you considered that MPEG LA could change the license conditions on
> > H.264 next year and make this impossible?
> > 
> > Regards,
> > Silvia.
> 
> 
> I do not see any path where significant changes could be be made that
> could stop this from continuing. Keep in mind that many of the
> companies in the MPEG LA 264 pool are in favor of just making H.264
> RF for use on the internet. Theses same companies, and they include
> people like, cough, cisco, and apple, have to approve changes that
> happen in the future. I would not be surprised to see the discussion
> on future changes to the MEPG LA license be around just making the
> license pool RF. Or perhaps just moving the price of the cap up a
> bit. 
> 
> Now you can say, ok, that is way too good to be true, no big company
> would ever give away valuable IPR. Lets clear up one thing, the
> amount of money that any large company gets in royalties from 264
> MPEG LA pool is so small it is a joke - and a quick back of the
> envelope estimate will show you the limits. But ask yourself this
> instead, Why does Cisco care about webrtc at all? what would a
> company like Cisco pay to MPEG LA to improve the ability for lots of
> companies, particularly small companies or open source projects, to
> be able to produce, consume, and distribute video on the internet?
> What would it take to make it so video on the internet was far more
> important to people's lives than watching cats on skateboards. 
> 
> This whole discussion reminds me of a real blast from the past. In
> 2000 Cisco acquired Vovida (where I worked) and open sourced 100% of
> the technology. People said said Cisco was nuts to acquire that and
> give it away for fee - the numbers were much larger than anything
> being discussed here. People like vonage starting using the code.
> People said "It's a trap" and included the appropriate star wars
> images - Cisco has patents on SIP and is going to get you for using
> the open source. Cisco did not go after people for using the software
> and companies like vonage effectively helped drive lots of voice
> traffic that resulted in good business for Cisco. Open source helped
> enable that. You might say that was then this is now but you might
> want to look at what we did this month - 2.7 billion for the
> Sourcefire, a company that's most interesting product is open source. 
> 
> Snort is not a trap, it's exactly what it seem. This is the same -
> Cisco wants there to be a video codec that can be widely used on the
> internet as it exists today - Cisco will continue to want that and
> will continue to pay MPEG LA to make that happen. 
> 
> Which leads of of course to why this codecs and not some other one.
> We don't believe VP8 is the one that works with the internet today
> and given the reasons have been on this before I don't want to
> reiterate here. I'd be doing a little dance of joy at the IETF
> microphone if Daala can meet their goals of better than existing
> codecs, royalty free, and wide adoption and I really hope that
> happens but it clear that is not here today and this is project still
> at early stage. I'm glad they are working on something better for the
> future. Older codecs like, just for example, H.263 might be easier /
> cheaper to get to be RF but, sadly they sort of blow chunks. I don't
> believe a business model like apple iTunes, Netflix streaming video,
> or even Skype could be successful in today's market if it had to use
> a codec like 263, or for that matter any of the older codecs - thus
> they don't really meet Cisco's goals of widespread viable codec
> people can use today. 
> 

Interesting read, but it still doesn't address the concerns I raised
yesterday. Companies like yours may not be doing that much money on
licensee fees, but the fact itself that they exist makes them leverage
they can (whether they will or not) use, and clear the market of those
who can't.

I want to be free to use what I want, and H.264 doesn't allow that:
Cisco is providing a way to do so, but I want to be able to pick
alternatives. Telling the MPEG LA may make H.264 RF some day is smoke:
if the money you're getting is so pathetic, do that for real then and
make us poor guys happy.

Lorenzo

---

From: Neil Stratford <[email-masked]>
Date: Thu, 31 Oct 2013 09:02:09 +0000

> As Jonathan mentioned earlier, this morning Cisco announced that it will be open sourcing an H.264 implementation as well as gratis binary modules compiled from that source and hosted by Cisco for…

It seems like most of the groundwork is being done here for a real codec plugin API which would obviate the need for any particular codec to be selected as MTI.

Can we encourage this new codec plugin API to be developed in an open way as part of the standards process and therefore be supported in all browsers? (Enabling for example the addition of VP8 to a browser that may not natively ship with it.)

Neil

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 31 Oct 2013 16:10:27 +0100

> Can we encourage this new codec plugin API to be developed in an open way as part of the standards process and therefore be supported in all browsers? (Enabling for example the addition of VP8 to a…

I don't agree. The idea was to create a realtime web platform without the need for any plugins or downloadable modules. We've had that for ages and it is not a good solution.

I am still for a MTI codec or set of codecs so we always can set up video calls, regardless of implementation and if it's possible to download by policy or network conditions a specific binary.

/O

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Thu, 31 Oct 2013 21:51:03 +0100

On 10/31/13 10:35 AM, Olle E. Johansson wrote:
> For us in the Asterisk community I believe this opens up for use of video in a whole new way.
To my understanding, the release of the codec is for webrtc only, and 
particularly for client side/browsers. For clarification, is this 
codec/blob available to use for free in any application, no matter its 
relation with webrtc sessions?

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Thu, 31 Oct 2013 22:08:24 +0100

> I am still for a MTI codec or set of codecs so we always can set up video calls, regardless of implementation and if it's possible to download by policy or network conditions a specific binary.
Downloading a binary opens doors for tons of risks, knowing that lot of 
carriers do caching or interpose themselves (e.g., it happens very 
commonly for dns to redirect you to some adds page when typing an 
invalid domain), thus is easy to replace the original source, so a 
rather complex security mechanism has to be put in place.

Even the argument that the code can be compiled and signatures compared 
is not really feasible - simply it cannot be done by mobile devices - 
they don't have the sdk installed.

I can't see an impediment for Cisco to grant the main web browsers 
(e.g., Mozilla, ...) to simply have the codec built in, using the BSD 
open sourced codec. If the webrtc is going to the masses, then the 
yearly fee cap will be reached anyhow.

For the sake of clarification, I am not in a favor of a particular video 
codec, but the one to be selected has to be embedded directly in all 
browsers, specially in those open source, for full transparency. 
Otherwise, better as Neil said, make it a plugin API so there can be 
many providers - with binary blob download, there has to be an API 
anyhow, make that the standard.

Daniel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Oct 2013 14:27:47 -0700

On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <[email-masked]

>>>  As Jonathan mentioned earlier, this morning Cisco announced that it
>>>> will be open sourcing an H.264 implementation as well as gratis binary
>>>> modules compiled from that source and hosted by Cisco for download. Mozilla
>>>> will be modifying Firefox to support H.264 by downloading Cisco's binary
>>>> module.
>>>>
>>>
>>> It seems like most of the groundwork is being done here for a real codec
>>> plugin API which would obviate the need for any particular codec to be
>>> selected as MTI.
>>>
>>> Can we encourage this new codec plugin API to be developed in an open
>>> way as part of the standards process and therefore be supported in all
>>> browsers? (Enabling for example the addition of VP8 to a browser that may
>>> not natively ship with it.)
>>>
>> I don't agree. The idea was to create a realtime web platform without the
>> need for any plugins or downloadable modules. We've had that for ages and
>> it is not a good solution.
>>
>> I am still for a MTI codec or set of codecs so we always can set up video
>> calls, regardless of implementation and if it's possible to download by
>> policy or network conditions a specific binary.
>>
> carriers do caching or interpose themselves (e.g., it happens very commonly
> for dns to redirect you to some adds page when typing an invalid domain),
> thus is easy to replace the original source, so a rather complex security
> mechanism has to be put in place.
>

Solely on the security question...

I'm not sure what you mean by "rather complex". What I would expect is to
have signed
binaries. This addresses the question of attack from the network and is how
we
intend to handle things in Firefox.

Note that any product that auto-updates (like Firefox and Chrome) already
need
to have some mechanism for verifying that the things they download are
correct.

> Even the argument that the code can be compiled and signatures compared is
> not really feasible - simply it cannot be done by mobile devices - they
> don't have the sdk installed.
>

I don't see why this would be needed. The containing program (e.g., the
browser) doesn't compile, it just does signature verification.

Obviously, this only addresses the question of attack from the network,
not malicious binaries constructed by Cisco. I expect that to be addressed
by third parties doing verified builds and comparing the binaries.
Presumably,
one could invent some countersignature mechanism to allow clients to
verify that a specific third party had verified a build.

-Ekr

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Thu, 31 Oct 2013 22:40:16 +0100

On 10/31/13 10:27 PM, Eric Rescorla wrote:
>
>
>
> On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>         On 31 Oct 2013, at 10:02, Neil Stratford <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             On 30 Oct 2013, at 17:55, Adam Roach <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 As Jonathan mentioned earlier, this morning Cisco
>                 announced that it will be open sourcing an H.264
>                 implementation as well as gratis binary modules
>                 compiled from that source and hosted by Cisco for
>                 download. Mozilla will be modifying Firefox to support
>                 H.264 by downloading Cisco's binary module.
>
>
>             It seems like most of the groundwork is being done here
>             for a real codec plugin API which would obviate the need
>             for any particular codec to be selected as MTI.
>
>             Can we encourage this new codec plugin API to be developed
>             in an open way as part of the standards process and
>             therefore be supported in all browsers? (Enabling for
>             example the addition of VP8 to a browser that may not
>             natively ship with it.)
>
>         I don't agree. The idea was to create a realtime web platform
>         without the need for any plugins or downloadable modules.
>         We've had that for ages and it is not a good solution.
>
>         I am still for a MTI codec or set of codecs so we always can
>         set up video calls, regardless of implementation and if it's
>         possible to download by policy or network conditions a
>         specific binary.
>
>     Downloading a binary opens doors for tons of risks, knowing that
>     lot of carriers do caching or interpose themselves (e.g., it
>     happens very commonly for dns to redirect you to some adds page
>     when typing an invalid domain), thus is easy to replace the
>     original source, so a rather complex security mechanism has to be
>     put in place.
>
>
> I'm not sure what you mean by "rather complex". What I would expect is 
> to have signed
> binaries. This addresses the question of attack from the network and 
> is how we
> Note that any product that auto-updates (like Firefox and Chrome) 
> already need

Typically the updates you mentioned are done from the project's sites, 
so that is easier to handle. Now there is a third party involved, 
requiring some sync'ing between Cisco and browser's sites. It's like a 
menage-a-trios, pretty dirty affair. I wonder why flash plugin was not 
loaded this way, it was always free -- but had to be 
downloaded/installed explicitly by users.

>
>
>     Even the argument that the code can be compiled and signatures
>     compared is not really feasible - simply it cannot be done by
>     mobile devices - they don't have the sdk installed.
>
>
If we get to 'one could invent some ...' and wait for that, better wait 
for a pure open source video codec. Mozilla is working in that direction 
anyhow.

Daniel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Oct 2013 14:50:03 -0700

On Thu, Oct 31, 2013 at 2:40 PM, Daniel-Constantin Mierla <[email-masked]

> On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <
> [email-masked]> wrote:
>
>>
>>>> It seems like most of the groundwork is being done here for a real
>>>> codec plugin API which would obviate the need for any particular codec to
>>>> be selected as MTI.
>>>>
>>> I don't agree. The idea was to create a realtime web platform without
>>> the need for any plugins or downloadable modules. We've had that for ages
>>> and it is not a good solution.
>>>
>>> I am still for a MTI codec or set of codecs so we always can set up
>>> video calls, regardless of implementation and if it's possible to download
>>> by policy or network conditions a specific binary.
>>>
> binaries. This addresses the question of attack from the network and is
> how we
> Typically the updates you mentioned are done from the project's sites, so
> that is easier to handle. Now there is a third party involved, requiring
> some sync'ing between Cisco and browser's sites. It's like a
> menage-a-trios, pretty dirty affair.
>

I don't anticipate any problems implementing this in Firefox (and in case
I wasn't clear previously, I'm probably the person who will be responsible
for figuring out how to make it work).

>  I wonder why flash plugin was not loaded this way, it was always free --
> but had to be downloaded/installed explicitly by users.
>

Well, that's not true for Chrome, at least, which ships with Flash, though
I agree that that's somewhat different.

> for a pure open source video codec.
>

You might be interested in:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17

> Mozilla is working in that direction anyhow.
>

That's going to take rather longer than this.

-Ekr

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 31 Oct 2013 18:36:44 -0400

> intend to handle things in Firefox.

You would need something more than that if you don't trust Cisco not to
tinker with the binaries (no offense).  But even that doesn't have to be
complicated.  You could just do something like have the software call back
to the vendor whenever it gets a new binary from Cisco to check that the
binary it just got is good (say, by comparing hashes).

That way at least Cisco and the vendor would have to collude to introduce a
bad modification to the binary.  Which is not so bad, because the user is
already trusting the vendor not to screw them in all sorts of other ways.

--Richard

>> is not really feasible - simply it cannot be done by mobile devices - they

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Oct 2013 15:44:42 -0700

Keep reading below.

"Obviously, this only addresses the question of attack from the network,
not malicious binaries constructed by Cisco. I expect that to be addressed
by third parties doing verified builds and comparing the binaries.
Presumably,
one could invent some countersignature mechanism to allow clients to
verify that a specific third party had verified a build."

On Thu, Oct 31, 2013 at 3:36 PM, Richard Barnes <[email-masked]> wrote:

> That way at least Cisco and the vendor would have to collude to introduce
> a bad modification to the binary.  Which is not so bad, because the user is

---

From: cowwoc <[email-masked]>
Date: Thu, 31 Oct 2013 20:54:37 -0400

Everyone seems to be fixated on web browsers. What happens to those 
of us who wish to integrate WebRTC as a library into non-browser 
applications? What about standalone (client) applications? What about 
(auditing) web servers? Are we expected to download the binary module 
once per user? Or does our build machine download it once and deploy it 
to a million users?

     VP8 is far more attractive from a security and deployment point of 
view.

Gili

On 31/10/2013 5:08 PM, Daniel-Constantin Mierla wrote:
>>>> will be open sourcing an H.264 implementation as well as gratis 
>>>> binary modules compiled from that source and hosted by Cisco for 
>>>> download. Mozilla will be modifying Firefox to support H.264 by 
>>>> downloading Cisco's binary module.
>>>
>>> codec plugin API which would obviate the need for any particular 
>>> codec to be selected as MTI.
>>>
>>> Can we encourage this new codec plugin API to be developed in an 
>>> open way as part of the standards process and therefore be supported 
>>> in all browsers? (Enabling for example the addition of VP8 to a 
>>> browser that may not natively ship with it.)
>> the need for any plugins or downloadable modules. We've had that for 
>> ages and it is not a good solution.
>>
>> video calls, regardless of implementation and if it's possible to 
>> download by policy or network conditions a specific binary.
> Downloading a binary opens doors for tons of risks, knowing that lot 
> of carriers do caching or interpose themselves (e.g., it happens very 
> compared is not really feasible - simply it cannot be done by mobile 
> devices - they don't have the sdk installed.
>
> For the sake of clarification, I am not in a favor of a particular 
> video codec, but the one to be selected has to be embedded directly in 
> all browsers, specially in those open source, for full transparency.