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

[Peter Thatcher <[e-mail]>]

On Wed, Jun 19, 2013 at 10:17 AM, Roman Shpount <[e-mail]> wrote:

>
> On Wed, Jun 19, 2013 at 1:01 PM, Peter Thatcher <[e-mail]>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.
>

I think an API that allows JS to not have to do SDP munging it much better.
 That's why I proposed a step in that direction.


>
> 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).
>

Agreed.  I'd rather not have it, but I'm trying to make incremental
improvements here.   I don't want to blow up everything and start from
scratch.


>  _____________
> Roman Shpount
>
>