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

[Iñaki Baz Castillo <[e-mail]>]

2013/7/1 Stefan Håkansson LK <[e-mail]>:
> 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?

The fact that a capability exchange or media signaling negotiation
exists does not mean that it must be based on a opaque blob which is
unmanageable at JS level. The JS app should be able to understand
*what* exactly it is sending in-the-wire, and for that purpose a
opaque blob is not a ellegant solution. Instead a JS Object based API
(like *any* WWW API) makes sense. And then the JS app can decide how
to encode/serialize/whatever such a media information in-the-wire (and
yes, it can be into a SDP, but a SDP created by the JS library because
the author chose it, while others can use whatever format or send the
information "splitted" into different requests or whatever.

Of couse the SDP O/A model is a valid model, and of course SIP is a
valid model (which carries the SDP exchange), but that is not the only
one. IMHO the IETF/W3C should not mandate like-SIP-models for every
future RTC applications running in the web.

Best regards.


--
Iñaki Baz Castillo
<[e-mail]>