Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

[Roman Shpount <[e-mail]>]

On Wed, Jun 19, 2013 at 1:01 PM, Peter Thatcher <[e-mail]>wrote;wrote:

> There are two separate things here: 1.  adding to the current API to allow
> JS to avoid SDP.  2.  removing what is there that uses SDP.
>
> You're saying you want to add new things and remove olds things.  But I
> think really you just want to add what you want, and it would matter if
> what you didn't want to use were still there.  So I think it's better to
> talk about what we can add to the API to make it easier to work with rather
> than talk about starting from scratch.  Removing the existing pieces would
> not be nearly as easy as you make it sound.
>
>
Let me approach this from a different angle: Do you think it is possible to
create an interoperable, re-implementable API based on SDP? Currently, SDP
format changes with each release in a way that breaks both SDP mungling
code and external connected end-points. What I want is an API that does not
rely on a string blog to encapsulate every new feature. New features should
be implemented via new methods. I need something standard enough that I can
have a stable application implementation. As it stands right now WebRTC
will not pass the W3C standard process, so we need either spend a lot more
time tying down SDP or create the API that avoids it. I think you
 underestimate the amount of effort needed to finalize SDP. At the current
rate I see this  process taking another 2-3 years. It also creates a
dependency on MMUSIC, which has its own priorities. So, if you want a
realistic API standard, you need to look for a way around SDP.

Also, using SDP just for transport is wasteful. All you need are 3 string
parameters which can be passed individually without parsing/creating a
string blog which carries another 5 things that carry no meaning for
transport (version, origin, etc).
_____________
Roman Shpount