- From: Roman Shpount <roman@telurix.com>
- Date: Thu, 20 Jun 2013 09:54:24 -0400
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
- Message-ID: <CAD5OKxuYdN4hCYzaOUnO6Rsbqk37jXKr2FZ15iq8qmk2yC0xdg@mail.gmail.com>
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