[RTW] List is now open

[Justin Uberti]

On Mon, Oct 11, 2010 at 12:11 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Sun, 10 Oct 2010, Justin Uberti wrote:
> >
> > My idea is that we will tie these various pieces together like a filter
> > chain, i.e.
> >
> > <device> -> [encoder] -> [transport] -> [decoder] -> <video>
>
> This is basically what's in the HTML spec today:
>
> On the sending side:
>
>  <device> is <device>
>  [encoder] is a Stream object
>  [transport] is a PeerConnection object
>
> On the receiving side:
>
>  [transport] is a PeerConnection object
>  [decoder] is a Stream object's .url attribute
>  <video> is a <video>
>
> The details are abstracted out a lot at this point; the idea is that
> future versions of the API can add specific knobs and dials to allow
> authors to control what they want to change; we can decide what to expose
> based on what people most want. This dramatically limits the complexity of
> what we have to implement, and makes it more likely we'll get interop
> sooner. However, I need to do some work on this spec to merge in the ideas
> from some of Justin's work, so this may change a bit. What will certainly
> change is the way the low-bandwidth channel maintained by the script is
> interfaced with on the PeerConnection object; I also need to move some of
> the Session stuff into the spec, e.g. sending of DTMF tones.
>
> Work still has to happen to define how information is conveyed to the
> browser, in particular, what format the browser should expect server
> configuration to be in. We also need a spec defining how browsers use
> ICE/STUN/etc, e.g. how they identify which PeerConnection object an
> incoming connection is related to -- imagine the situation of a script
> trying to open two simultaneous connections between the same two browsers.
>
> One thing that might make sense is for me to write a skeleton of what I
> imagine the "next layer" would look like (the spec layer that defines the
> format of the data that the browsers use to talk over the low-latency
> channel, defines how ICE/STUN/relays/etc are used, defines what the
> relays are, defines how to do video codec negotiation, defines how to
> identify which packets go with which PeerConnection, defines how to
> respond to specific API calls in terms of data on the wire, etc), and to
> then hand that off to someone who actually knows how that is all to be
> defined. Would that make sense?
>

Sure. As you mention, our previous discussions on the Session API are
probably a good start for this. I'd be happy to work with you on the
details.

>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20101013/59b2f3dc/attachment.html>