- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 20 Jun 2013 15:18:39 +0200
- To: public-webrtc@w3.org
- Message-ID: <51C3012F.2030006@alvestrand.no>
On 06/19/2013 05:05 PM, Roman Shpount wrote: > > On Wed, Jun 19, 2013 at 10:56 AM, piranna@gmail.com > <mailto:piranna@gmail.com> <piranna@gmail.com > <mailto: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? 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.
Received on Thursday, 20 June 2013 13:19:12 UTC