March 2011 - RTC-Web - example.com

New HTML5 API proposed for peer-to-peer communication
by Harald Alvestrand 22 Mar '11

22 Mar '11

Note: Ian Hickson has just published a new proposal for a peer-to-peer connection API, as part of his editing the HTML5 specification. The spec can be found around this URL: http://www.whatwg.org/specs/web-apps/current-work/#peerconnection-ice-agent Harald

1 0

NOTE WELL - notification
by Harald Alvestrand 17 Mar '11

17 Mar '11

For the avoidance of doubt: At the moment, this is the mailing list for a scheduled IETF BOF, and falls under IETF rules. In particular: Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: * The IETF plenary session * The IESG, or any member thereof on behalf of the IESG * Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices * Any IETF working group or portion thereof * The IAB or any member thereof on behalf of the IAB * The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules ofRFC 5378 <http://www.ietf.org/rfc/rfc5378.txt>andRFC 3979 <http://www.ietf.org/rfc/rfc3979.txt>(updated byRFC 4879 <http://www.ietf.org/rfc/rfc4879.txt>). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consultRFC 5378 <http://www.ietf.org/rfc/rfc5378.txt>andRFC 3979 <http://www.ietf.org/rfc/rfc3979.txt>for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

1 0

Re: [RTW] New proposed charter text. Please review before the BoF.
by Ted Hardie 17 Mar '11

17 Mar '11

2011/3/17 Philippe Le Hegaret <plh(a)w3.org>: > On Thu, 2011-03-17 at 09:18 -0700, Ted Hardie wrote: >> 8. Provide W3C input for the APIs that comes from the >> communication model and the selected components and protocols that are >> part of the solution. > > >From a W3C point, I'd like to understand what item 8 means. W3C is > putting in place a working group to develop the APIs. > > Will the IETF Group also work on them in order to provide input? > > There is certainly a need for coordination between the two groups but > I'm concerned that the IETF Group would work on the APIs... > > Regards, > > Philippe Probably poor wording on my part; the intent here was to say that the IETF would provide W3C with information on the communication models and underlying protocols so that they could develop the APIs with this data in hand. As many have noted, coordination of the work is critical to getting a working system, and we've tried different ways of putting that in the charter. But I think that it's a general feeling that just needs capturing well. regards, Ted Hardie

1 0

DISPATCH Ad-HOC meetings on RTCWeb at IETF 80
by Cullen Jennings 15 Mar '11

15 Mar '11

The dispatch WG will an ad-hoc meeting to discuss the technical contents of drafts related to the proposed RTCWeb WG. Tentative time: RTCWeb's is Friday 1415-1515 in the Grand Ballroom Send Agenda requests for time to Mary and I. Thanks, Mary & Cullen

1 0

Requirement F9 - Audio processing
by Kavan Seggie 15 Mar '11

15 Mar '11

Hi all Firstly congratulations on a great initiative. Video and voice chat in the web browser is incredibly powerful and will without doubt change the communications industry. A quick introduction. We are a small startup that over a two year period have created a video chat plugin. Due to our limited resources we have used open source technologies where ever possible. The one area that is very difficult to find quality open source libraries is in audio processing. As you all probably know, the overall communications experience of a video chat is greatly dependent on audio quality. The audio codec is important, but just as important are the other DSP elements like the jitter buffer, AGC, noise suppression and AEC. Without this audio processing even the best video and audio can be useless. This is what happened with the Flash plugin and AEC became the most/2nd most requested feature in Flash. They have finally implemented AEC, AGC and noise suppression in 10.3 beta and it is now usable as a communications tool. Before, without the audio processing, it wasn't in my opinion. To the best of my knowledge the only reasonable open sourced software in this field is Jean-Marc Valin's Speex DSP library. We have been working on optimising this for a few months and will continue to do so. But it is a basic implementation and to be honest our optimisations are not great yet. The infinite permutations of hardware, differing latency in the network and the system, and the different environments the user can be in, make this an incredibly difficult problem to solve. Also if we want to support different audio codecs, these libraries need to be optimised for each codec. I have read in the proposed documents that AEC is a requirement (F9) but I have not been able to find any plans on addressing the issue. After Google bought GIPS, I thought that Google may open source GIPS's rock solid audio technology. However that was almost a year ago so there may be issues with this. It is also just a guess, Google may have other plans for the technology. So perhaps, since this is an important requirement for the adoption of RTC, the group could work on bettering the Speex algorithms? We would be happy to contribute our amendments to the Speex algorithms as well as other work we have done, and so kick start a project. We could also commit our audio engineer to work on it almost full time. He has considerable experience in creating voice codecs and is learning his way through the other DSP elements. All thoughts and recommendations welcome. Regards Kavan Seggie SayMama

1 0

Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
by Dean Willis 15 Mar '11

15 Mar '11

Well, THAT was an interesting time-warp. Sorry about that. But I guess the sentiment still stands even if the mail was stuck in my outbox for a while... On Mar 14, 2011, at 11:37 PM, Dean Willis wrote: > > Oh hell no.... > > Really, what we need are the primitives that make a web app able to do things like slurp data from a microphone and send it someplace useful. We might also need interfaces to A/V streams (maybe even RTP), and mixers. We need those primitives exposed to things like Javascript. What we don't need is an API that turns every browser into a generic SIP UA capable of being reused in haphazard fashion, such that everybody and his chihuahua reskins their "SIP browser phone" with CSS, and every browser swells to the size of the Hindenberg just before the fatal spark. > > -- > Dean >

1 0

Does RTC-WEB need to pick a signaling protocol?
by Jonathan Rosenberg 15 Mar '11

15 Mar '11

I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself, and here are my thoughts on it. If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP. As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections. That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall. One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC-WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen(a)skype.net http://www.skype.com jdrosen(a)jdrosen.net http://www.jdrosen.net

13 19

Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-01
by Harald Alvestrand 13 Mar '11

13 Mar '11

I don't think there should be much additional contoversial stuff here, but some of the language may have improved. Biggest additional text by line count: tried to add in the reasoning behind my argument in favour of a mandatory-to-implement baseline. This is still my input, not attempting to represent a consensus position (yet). Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-01 Date: Sun, 13 Mar 2011 01:34:00 -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-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-dispatch-rtcweb-protocols Revision: 01 Title: Overview: Real Time Protocols for Brower-based Applications Creation_date: 2011-03-13 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document gives an overview and context 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, with the intended discussion forum being the "RTCWEB" WG (in formation). Currently, discussion is on the rtc-web(a)alvestrand.no mailing list. The IETF Secretariat.

1 0

Fwd: I-D Action:draft-perkins-rtcweb-rtp-usage-00.txt
by Magnus Westerlund 13 Mar '11

13 Mar '11

Hi, Colin Perkins, Joerg Ott and I have created this draft about RTC-WEB's usage of RTP. Feedback and discussion are most appreciated. Cheers Magnus

6 12

Fwd: [new-work] Proposed W3C Charter: Web Real-Time Communications Working Group (until 2011-03-18)
by Cullen Jennings 09 Mar '11

09 Mar '11

FYI Begin forwarded message: > From: Ian Jacobs <ij(a)w3.org> > Date: February 17, 2011 11:12:50 AM MST > To: new-work(a)ietf.org > Subject: [new-work] Proposed W3C Charter: Web Real-Time Communications Working Group (until 2011-03-18) > > Hello, > > Today W3C Advisory Committee Representatives received a Proposal to revise the Ubiquitous Web Applications Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Real-Time Communications Working Group: > http://www.w3.org/2010/12/webrtc-charter > > As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. > > W3C invites public comments through 2011-03-18 on the proposed charter. Please send comments to public-new-work(a)w3.org, which has a public archive: > http://lists.w3.org/Archives/Public/public-new-work/ > > Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. > > If you should have any questions or need further information, please contact François Daoust, Team Contact <fd(a)w3.org>. > > Thank you, > > Ian Jacobs, Head of W3C Communications > > [0] http://www.w3.org/2007/uwa/ > [1] > http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation > [2] http://www.w3.org/Consortium/Member/List > -- > Ian Jacobs (ij(a)w3.org) http://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 > > _______________________________________________ > new-work mailing list > new-work(a)ietf.org > https://www.ietf.org/mailman/listinfo/new-work

1 0