December 2010 - RTC-Web - alvestrand.no

Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
by Heinrich Sinnreich 12 Jan '11

12 Jan '11

>I think we should consider the balance > between cost, risk, quality, and existing adoption, and it would be foolish to > omit cost-bearing codecs from that analysis, as H.264 is widely used already. I am not sure where this discussion is going, though it reminds us of the discussions when arguing about SIP vs. H.323 in the IETF. "Everybody" was shipping H.323 in overwhelming quantity, but somehow the IETF did not buy it. As an hopeless optimist; maybe H.264 will have the same fate since at least it's considerable IP baggage is so well known... It is hard to imagine the IETF and indeed the market will ignore the creativity of all the codec developers out there and the evolving technology that empowers them. Plain self interest should motivate embracing new IP-free a/v codecs for the RTC Web. They will arrive anyway one way or another. [Well deployed technology has a proven way to make it over the threshold into history :-)] Henry On 12/22/10 5:46 PM, "David Singer" <singer(a)apple.com> wrote: > I should say that I am perfectly happy to have the discussion about whether, > and what, to mandate codec(s). If the placeholder is there to spark the > discussion, you succeeded! > > For me, significant IPR risk is worse than a payment -- free but risky is not > an improvement on costs-but-low-risk. But others may differ, of course. > > I do think we should be looking carefully at layered design. Ideally, we > define the missing technology bits -- HTML, Javascript/DOM, and so on; and > then, perhaps, we write an umbrella specification that uses those, and other > technology pieces, to achieve an interoperable end. But the pieces should > 'make sense' by themselves, and be usable with other assemblages, I think, if > the specs are to have 'legs' and survive over years. The pieces are ideally > stable standards/publications in their own right (and I agree, sometimes, > rarely, something is stable and well-known enough, such as ZIP or ID3 tags, > without being a 'standard'). > > I also agree that RF codecs are happening and are here to stay. Those of you > who know me from MPEG will have heard this before. They will exist, and they > will have a place. MPEG is working (slowly) on RF codecs as well. > > As to what MPEG-LA is doing, I am afraid I don't actually know. We'd have to > ask them, and they tend not to reply. The silence is strange, but I don't > think that mitigates the possibility that there is an IPR entanglement. > > Despite Henry's position (that mentioning VP8 results in no rat-holes and > flames, and that mentioning H.264 will) I think we should consider the balance > between cost, risk, quality, and existing adoption, and it would be foolish to > omit cost-bearing codecs from that analysis, as H.264 is widely used already. > > The link between open-source and royalty-free is not perfect; there are > quality open-source implementations of non-free codecs, for a start, and there > are companies who license proprietary systems royalty-free. Let's not confuse > the two, even if they often occur together. > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch

14 27

Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
by Ingemar Johansson S 26 Dec '10

26 Dec '10

Hi Not meaning to express any preference in any direction but more a question to the more experiened IETFers. My impression here is that algorithms devised outside the IETF are rarely mandated in IETF frameworks. Two examples that I can come up with are SRTP (RFC3711): Only specifies the framework for secure RTP but does not mandate any encryption/authentication algorithms. Not sure if excryption algos are specified in separate RFC's FECFRAME (RFC6015): Specifies the framework for generic FEC, generic enough to plug in any FEC algo, the actual FEC algos are specified in separate drafs (http://tools.ietf.org/wg/fecframe/) Perhaps there are similar examples in other IETF areas that can serve as guidance ?, you may want to ping the eriIetf list on this (I leave it up to you) So to me it seems like there is preference to _not_ mandate algorithms (compression, fec, encryption) in IETF frameworks (I can imagine one specific reason to this). And... as I believe that RTC-Web will be some kind of framework I would say that this would apply here as well ?. Please feel free to bash my conclusion. /Ingemar ------------------------------------------- Message: 1 Date: Tue, 21 Dec 2010 21:38:42 +0000 From: <Markus.Isomaki(a)nokia.com> Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 To: <peter.musgrave(a)magorcorp.com>, <harald(a)alvestrand.no> Cc: rtc-web(a)alvestrand.no, dispatch(a)ietf.org, ted.ietf(a)gmail.com Message-ID: <DD8B10B86502AB488CB2D3DB4C546E3806DA99(a)008-AM1MPN1-003.mgdnok.nokia.com> Content-Type: text/plain; charset="us-ascii" Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces(a)ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web(a)alvestrand.no; dispatch(a)ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is there. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool <idsubmission(a)ietf.org><mailto:idsubmission@ietf.org> To: harald(a)alvestrand.no<mailto:harald@alvestrand.no> A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat. _______________________________________________ dispatch mailing list dispatch(a)ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch

4 6

Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
by Harald Alvestrand 22 Dec '10

22 Dec '10

This is the overview document for the IETF-related RTC-WEB work. -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 Date: Wed, 10 Nov 2010 03:31:05 -0800 (PST) From: IETF I-D Submission Tool <idsubmission(a)ietf.org> To: harald(a)alvestrand.no A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 00 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2010-11-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document gives an overview of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion. The IETF Secretariat.

10 13

Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
by Markus.Isomaki＠nokia.com 22 Dec '10

22 Dec '10

Hi, The good thing about Opus codec is that as it has been developed through the IETF process, the ownership and change control issues are clear. This makes referencing and even mandating it by IETF or W3C more comfortable. Markus From: ext Henry Sinnreich [mailto:henry.sinnreich@gmail.com] Sent: 22 December, 2010 04:32 To: Isomaki Markus (Nokia-CIC/Espoo); peter.musgrave(a)magorcorp.com; harald(a)alvestrand.no; codec(a)ietf.org Cc: rtc-web(a)alvestrand.no; dispatch(a)ietf.org; ted.ietf(a)gmail.com Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 It is interesting, almost funny (or sad depending on the perspective) how the reaction to a _God Forbid_ IP-free video codec is mirroring the opposition to the Internet audio codec. That opposition proved eventually futile and we have now a CODEC WG. I hope the AD's will have now the same fortitude as was shown when the Internet audio codec WG was formed. I have taken the liberty to copy the CODEC WG and hope they can participate now in the video codec discussion as well. My apology for the double posting. Thanks, Henry On 12/21/10 3:38 PM, "Markus.Isomaki(a)nokia.com" <Markus.Isomaki(a)nokia.com> wrote: Hi Peter, all, About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created. So I don't at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. I'm working on a separate review on Harald's drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter's point here. Regards, Markus From: dispatch-bounces(a)ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave Sent: 17 December, 2010 13:48 To: Harald Alvestrand Cc: rtc-web(a)alvestrand.no; dispatch(a)ietf.org; Ted Hardie Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 I'd also like to echo Alan's thanks for these drafts. The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ] One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have). Regards, Peter Musgrave Nits Introduction s/veichle/vehicle/ Section 2 Para "Within each.." s/implementaiton/implementation/ Section 4 Para1 "such as" (something missing here?) Section 5 Para2 "There is no third mandatory to implement" ? Was there a mention of a third before. Not sure why this statement is there. On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: This is the overview document for the IETF-related RTC-WEB work. -------- Original Message --------

1 0

Re: [RTW] [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00
by David Singer 22 Dec '10

22 Dec '10

I have to agree. If IPR issues are what we want to avoid, VP8 seems like a poor choice (e.g. <http://www.digitaltrends.com/computing/mpeg-la-looking-at-patents-for-googl…>). On Dec 21, 2010, at 13:38 , markus.isomaki(a)nokia.com wrote: > Hi Peter, all, > > About the video codec: Are there any arguments on why VP8 would not have IPR issues? It is available as an open source implementation, but that does not mean there are no IPR against it. My understanding is that the IPR situation wrt. VP8 is still unclear and thus risky. The other issue with VP8 is, as far as I know, the lack of a clear spec out of which independent interoperable implementations can be created. > > So I don’t at least buy the argument that we should choose VP8 as mandatory to implement video codec because of IPR reasons. > > I’m working on a separate review on Harald’s drafts (thanks for putting them together) and will come back to the codec issue there in more detail, but just wanted to respond to Peter’s point here. > > Regards, > Markus > > From: dispatch-bounces(a)ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Musgrave > Sent: 17 December, 2010 13:48 > To: Harald Alvestrand > Cc: rtc-web(a)alvestrand.no; dispatch(a)ietf.org; Ted Hardie > Subject: Re: [dispatch] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 > > I'd also like to echo Alan's thanks for these drafts. > > The protocol doc is very clear. [If you read only one dispatch draft this Christmas, make it this one. ;-) ] > > One observation to the group. The mandatory to implement video CODEC is VP8 (presumably since it does not have IPR issues - which some other choices would have). > > Regards, > > Peter Musgrave > > > Nits > Introduction > s/veichle/vehicle/ > > Section 2 Para "Within each.." > s/implementaiton/implementation/ > > Section 4 Para1 > "such as" (something missing here?) > > Section 5 Para2 > "There is no third mandatory to implement" > ? Was there a mention of a third before. Not sure why this statement is there. > > > On 2010-11-10, at 6:34 AM, Harald Alvestrand wrote: > > > This is the overview document for the IETF-related RTC-WEB work. > > -------- Original Message -------- > Subject: > New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00 > Date: > Wed, 10 Nov 2010 03:31:05 -0800 (PST) > From: > IETF I-D Submission Tool <idsubmission(a)ietf.org> > To: > harald(a)alvestrand.no > > > A new version of I-D, draft-alvestrand-dispatch-rtcweb-protocols-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. > > Filename: draft-alvestrand-dispatch-rtcweb-protocols > Revision: 00 > Title: Overview: Real Time Protocols for Brower-based Applications > Creation_date: 2010-11-11 > WG ID: Independent Submission > Number_of_pages: 9 > > Abstract: > This document gives an overview of a protocol suite intended for use > with real-time applications that can be deployed in browsers - "real > time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This work is an attempt to synthesize the input of many people, but > makes no claims to fully represent the views of any of them. All > parts of the document should be regarded as open for discussion. > > > > The IETF Secretariat. > > > > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch David Singer Multimedia and Software Standards, Apple Inc.

5 4

Fwd: [Standards-discuss] [Work started on Web Real-Time Communications Working Group (Advance Notice)]
by Harald Alvestrand 17 Dec '10

17 Dec '10

Status report on the work of establishing a W3C activity to do the API work. If your company is a W3C member, you should make sure your AC representative knows you're aware of and engaged in this. Cullen and I are bashing out a corresponding IETF charter proposal. Harald ---------- Forwarded message ---------- From: Ian Jacobs <ij(a)w3.org> To: W3C Members <w3c-ac-forum(a)w3.org> Date: Thu, 16 Dec 2010 12:52:00 -0600 Subject: Work started on Web Real-Time Communications Working Group (Advance Notice) Dear Advisory Committee Representative, This is an advance notice that the Team has started work on a charter for a Working Group to produce specifications that enable Real Time Communications in Web browsers. While Web browsers have gained good capabilities to play audio and video files, they currently don't make possible to establish a direct communication link between clients. Based on discussions at an informal workshop in October, a number of W3C Members have expressed interest in specifying the technologies needed to enable this: the protocol considerations would be taken to the IETF, and the proposed W3C Working Group would work on the client-side technologies, such as the ones needed to facilitate synchronization of streams, or echo cancellation. A draft charter is available (this is not a formal review, just an early draft): http://www.w3.org/2010/12/webrtc-charter We welcome your general expressions of interest and support on <w3c-ac-forum(a)w3.org>. You may also send comments directly to Dominique Hazaël-Massieux <dom(a)w3.org>. This announcement follows section 6.2.2 of the Process Document: http://www.w3.org/2005/10/Process-20051014/groups#WGCharterDevelopment For Tim Berners-Lee, Director, Philipp Hoschka, Ubiquitous Web Domain Lead, and Dominique Hazaël-Massieux, Mobile Web Initiative Activity Lead, Ian Jacobs, Head of W3C Communications -- Ian Jacobs (ij(a)w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 --

1 0

Status update, organizational
by Harald Alvestrand 07 Dec '10

07 Dec '10

Just to keep people updated... we're pursuing two organization-level efforts: - Establishing the groundwork for an IETF working group. This will likely be a BOF at the IETF meeting in Prague in March, and we hope to have approval for it shortly afterwards. - Doing the same thing for a W3C working group. Timeline less certain - we're still figuring this out, but have had great help from our friends at W3C. In both cases, we hope to have charters for public discussion by the end of this year. Harald

4 5