W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: JavaScript API on top of SDP

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 16 Jul 2013 07:33:05 +1000
Message-ID: <CAHp8n2mC9BzMU=9tRwgq68L+LtKKPm9aUYx-LKgtubodtvejJA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: public-webrtc <public-webrtc@w3.org>, Jim Barnett <Jim.Barnett@genesyslab.com>
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
>
>
Received on Monday, 15 July 2013 21:33:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:34 UTC