Re: [rtcweb] New Draft - WebRTC JS Object API Model

[Stefan Håkansson LK <[e-mail]>]

On 2013-07-01 20:24, Roman Shpount wrote:
> On Mon, Jul 1, 2013 at 1:33 PM, Stefan Håkansson LK
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     What if first browser generated a JS Object that said (for this example
>     we assume one single audio track) it preferred to send audio using
>     Opus2.0 but could also do Opus and G.711. If the second browser (which
>     has not yet been upgraded) could only decode Opus and G.711, would it
>     not have to tell the first browser about this?
>
>     Are you perhaps assuming a capability exchange of some sort before any
>     media can be set up?
>
>
> Any API that we propose would include methods to expose browser
> capabilities (ie list of available codecs, with default payload type,
> payload name, clock rate, number of channels, and preferred codec
> parameters). Generation of SDP c line, rtpmap, and fmtp lines from this
> would be trivial, as well as generation of other media descriptions for
> XMPP or other negotiation protocols.
>
> In other words, we are not removing the need for negotiation. All we
> want is to unbundle it from single offer/answer exchange with single
> string blob into separate methods where transport negotiation (ie DTLS,
> SRTP, and ICE candidates), mapping transport to streams (ie any sort of
> bundle related mapping remote address, SSRC, payload or others), and
> media encoding/decoding (ie send and receive codecs, codec parameters,
> payload times, etc) are all negotiated separately and independently.

Roman, thanks for clarifying. Personally (wearing no hat) I think 
splitting things up makes a lot of sense. In fact, our first prototype 
browser (back in early 2011) was sort of implemented this way: each 
MediaStream was described and negotiated separately. We used SDPs for 
the purpose though (each addStream lead to a separate SDP O/A setting up 
that unidirectional MediaStream with its tracks).

But I think we should not underestimate the work needed to describe all 
the nitty gritty details using another "language" than SDP.

> This is what is happening with the API anyway with trickle ICE and
> no-plan proposal adding ability to update transport and media parameters
> once the initial connection is established. All we want is to extend the
> same logic to the initial connection establishment,
> _____________
> Roman Shpount