Re: JavaScript API on top of SDP

That makes a lot of sense to me and we can do this even with keeping a
backdoor open for SDP manipulation while we're working towards a more
abstract API. It would start decoupling the API from the wire protocol.
Silvia.
 On 16 Jul 2013 04:28, "Roman Shpount" <roman@telurix.com> wrote:

>
> On Mon, Jul 15, 2013 at 2:05 PM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:
>
>>  I think that the group has always known/assumed that we would need to
>> specify what SDP features are supported, what can be modified, etc.  Maybe
>> I’ve missed something, but I haven’t heard anyone say that this wasn’t
>> necessary.   It’s just that we haven’t gotten around to it yet.  ****
>>
>>
>>
> My first point is that SDP would need to be defined before any
> over-the-top SDP API is proposed. Otherwise such API would the waste of
> effort, unless, of cause, it is intended to replace SDP. My second point
> is, that defining such replacement API might be a much smaller effort then
> defining all the required details associated with SDP, since we would not
> need to waste time on such "important" topics as the meaning of "t=" line
> or address in "c=" line in SDP in WebRTC context.
>
> Bottom line, and my proposed compromise for the group, why would not we
> take the current SDP feature set in the browsers, map the parts that
> actually do something to the API and get rid of SDP? This would require a
> fairly limited effort, and would get us to 1.0 specification the quickest.
> This would also greatly reduce the number of external dependencies on the
> spec. This is not ideal from my point of view since it will still keep the
> offer/answer, but it least this would be something that implementations
> would be able to use with some level predictability.
> _____________
> Roman Shpount
>
>