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

Re: Moving forward with SDP control

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 19 Jul 2013 11:41:08 -0400
Message-ID: <51E95E14.6030401@bbs.darktech.org>
To: Kiran Kumar <g.kiranreddy4u@gmail.com>
CC: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Jesús Leganés Combarro <piranna@gmail.com>, Cullen Jennings <fluffy@iii.ca>, Likepeng <likepeng@huawei.com>
On 19/07/2013 6:55 AM, Kiran Kumar wrote:
> Dear Gili,
> Thanks for the comment.
>
> The suggested video is good.
>
>              I just want to explain that, in future, SDP mangling may 
> not be used that much, which can be achieved by constraints API.  I am 
> not mapping SDP and Constraints API, but generally constraints will 
> modify SDP internally inside the webrtc platform.

     Agreed.

>              I don't even support to expose the low level API and 
> implementation detail. For signalling purpose, we have to share some 
> information, regarding capabilities, with the other peer. And this 
> information should be exposed to the application.

     That is not strictly true. Any immutable low-level property should 
be hidden from the application developer. Meaning, as an application 
developer I don't care that the signaling layer is using encryption key 
"9823cuj980ru890e" and yet (I think) this shows up in the SDP. If I 
don't ever need to know about it, I shouldn't have access to it.

     The more I think about it, the more I am beginning to believe we 
need to define two sets of APIs:

 1. A low-level API for integrators
 2. A high-level API for application developers (layered on top of the
    low-level API)

     And browser vendors would be expected to interact with the 
signaling layer directly.

>
>                Also from the video you specified ( gegarding this 
> http://lcsd05.cs.tamu.edu/slides/keynote.pdf) slide 31, it is 
> suggested to provide an Programmatic access to all data, even though, 
> that is also available in the form of string. So the approach to 
> implement the capabilities in the form of API seems to be good even 
> according that video.

     It's definitely moving in the right direction, but we can improve 
further as mentioned above. I totally agree with you though, no one 
should have to parse Strings manually unless they are interacting with 
the signaling layer directly.

Gili
Received on Friday, 19 July 2013 15:41:51 UTC

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