- From: Matthew Kaufman <matthew.kaufman@skype.net>
- Date: Mon, 18 Jul 2011 11:56:13 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Prakash <prakash.tester.im@gmail.com>, public-webrtc@w3.org
On Jul 18, 2011, at 11:50 AM, Ian Hickson wrote: > > >> For example, >> >> a. Can the js code, query the codecs, clockrates to send it over the >> signaling channel? > > It doesn't need to. The browser tells the script what to send. Does the browser format this in such a way that a web server in the middle can inspect and, if necessary, modify what is sent onwards to the far end, or is it intended to be entirely opaque? If the former (or even the latter, but with the expectation of cross-browser-vendor interoperability), where's the spec? > > >> b. Is each candidate i described above (local, stun and turn), created >> using three PeerConnection calls? Are these sent to R over the signaling >> channel? > > No, the PeerConnection object encapsulates all this behaviour. > > >> c. How do i get the remote candidates? Through my signaling channel? How >> do i pass it down to the browser? > > You call p.processSignallingMessage() when you receive the message on your > signalling channel. > > >> d. Who decides, which is the best candidate pair / codec? Browser or >> application code? > > Browser. > Potentially in conjunction with application code at the client OR server end, I would expect. But not necessarily... an opaque channel between the two browser ends is sufficient for many cases. Matthew Kaufman
Received on Monday, 18 July 2011 18:56:48 UTC