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

Re: SDP wrapper? Object-oriented API?

From: Roman Shpount <roman@telurix.com>
Date: Thu, 20 Jun 2013 09:54:24 -0400
Message-ID: <CAD5OKxuYdN4hCYzaOUnO6Rsbqk37jXKr2FZ15iq8qmk2yC0xdg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
On Thu, Jun 20, 2013 at 9:18 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 06/19/2013 05:05 PM, Roman Shpount wrote:
> On Wed, Jun 19, 2013 at 10:56 AM, piranna@gmail.com <piranna@gmail.com>wrote:
>> So, for your answer, I should understand it would be done/masked using
>> high-level libraries, but on the bottom frames of the stack (hidden by
>> WebRTC API or not, like it's at this moment) an offer/answer exchange will
>> be always required, isn't it?
>  No this is wrong. Offer/Answer is something that should be implemented
> in JavaScript. What you need are much more basic operations, such as "get
> the list of supported media types" , "get the list of codecs for a media
> type", "select the transmit codec for a media stream", "pause/resume media
> stream" etc. Currently offer/answer in webrtc is build on top of API like
> this. Look at
> https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%2Fwebrtc%2Fvoice_engine%2Finclude
> and
> https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%2Fwebrtc%2Fvideo_engine%2Finclude
>  These are the API that are used internally. Wrapping them in JavaScript
> is something that would make sense to me.
> You did notice that these interfaces have absolutely no idea what DTLS is
> or what ICE is, right?

I did notice that DTLS/ ICE/SRTP are not part of these interfaces. I have
even said so in one of my previous messages. It would be part of external
transport. I can point you to the right portion of libjingle but I assume
you know where it is.

> There are just a *few* more libraries used to provide the whole set of
> functionalities.
> And:
> video_engine/include line count: 1695
> voice_engine/include line count: 2121
> You are not talking about small, simple, easily usable interfaces here.
And what value would I get if I add up line count of current JSEP
specifications and drafts? Anybody who ever wrote a line of code would
understand that either of those line counts would be irrelevant to our
discussion. 80% of the lines in the mentioned directories are comments, so
you are essentially comparing the size of the documentation of two APIs.
>From what is left, a big portion of API would not be needed since media
sources are implemented externally, so volume control, audio and video
device enumeration and similar things are implemented in media streams.

Thus, what I am saying is that comparing to what we have now these are
simple, easily understandable interfaces, especially if you add the amount
of code needed on top of current JSEP specification to implement the same
functionality. Most importantly these interfaces implement things people
need (at least based on the number of commercial real time communication
products based on this) vs someones vision of how offer/answer is supposed
to work (but almost never does).

Roman Shpount
Received on Thursday, 20 June 2013 13:54:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC