W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2011

Re: Low Level Javascript API Proposal

From: Matthew Kaufman <matthew.kaufman@skype.net>
Date: Tue, 04 Oct 2011 19:24:12 -0700
Message-ID: <4E8BBFCC.9040007@skype.net>
To: Neil Stratford <nstratford@voxeo.com>
CC: public-webrtc@w3.org
On 9/28/2011 7:56 AM, Neil Stratford wrote:
> To provide input to the ongoing discussion around architecture and 
> inclusion/exclusion of SDP in the Javascript API we would like to put 
> forward the following proposal.  The proposal is in Google doc form 
> for now because our goal was to get this to the list as quickly as 
> possible, but we are happy to re-structure as a full W3C proposal or 
> editorís draft if required.
>

I will not be available to attend the interim teleconference tomorrow, 
but this API is *much* more like the API I had originally envisioned 
when we started talking about adding RTC capabilities to browsers.

I think there's a fair amount of work required to unify this API with 
all the other W3C work going on in the area of audio playback (a very 
rich audio playout API was published recently), microphone capture, 
camera access, and video playout... but once done, it would be a very 
flexible set of components that didn't overlap in strange ways. (As an 
example, the audio APIs allow for panning... we really don't want to 
have a separate L/R panning control for audio streams that are playing 
RTC audio, especially if we are trying to combine the RTC audio with 
locally generated sound, or even process the RTC audio via an audio 
chain... for instance to make players in a game sound like they are "in 
the next room over".)

This API provides all the flexibility required to do SDP construction 
locally in Javascript or remotely at a server, and likewise to handle 
SDP offer/answer (if one wishes to engage in that for some reason) at 
either point as well.

I think there might be room for a "simple" way of asking the browser to 
do RTC, but I imagine it can be implemented *on top* of this, either in 
Javascript or if absolutely necessary, in the browser itself... but not 
in such a way that the flexibility of being able to reuse the other work 
done for audio and video is lost entirely.

Matthew Kaufman
Received on Wednesday, 5 October 2011 02:25:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC