Re: JavaScript API on top of SDP

+1

2013/7/15 Roman Shpount <roman@telurix.com>:
>
> 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
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Monday, 15 July 2013 19:05:10 UTC