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

[Roman Shpount <[e-mail]>]

On Mon, Jul 1, 2013 at 1:33 PM, Stefan Håkansson LK <
[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. 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