ADMIN: Technical questions (Re: Poll for preferred API alternative)

When asking questions, or commenting on others' positions, please use a 
different subject line than the "Poll" line, to make it less difficult 
for us who are trying to catch all the answers and tally them.

Thank you!

                     Harald

On 08/29/2012 05:15 PM, Li Li wrote:
>
> Regarding implementing ICE in Javascript, this analysis [1] raises the 
> issue that JS may not be able to satisfy the ICE timing requirements.
>
> In the Microsoft proposal [2], there is a JS example demonstrating ICE 
> connectivity checking between local and remote ICE candidates:
>
> Example 5
>
> function receivePeerCandidates(remotePorts) {
>
> var candidatePairs = localCandidates.forEach(function(local) {
>
> local.addEventListener('checksuccess', checkSuccessCallback);
>
> return remotePorts.forEach(function(remote) {
>
> local.check(remote);
>
> });
>
> });
>
> }
>
> Will local.check(remote) queue the checking requests and send them at 
> 20ms interval as required by ICE, thus avoid the problem in [1]?
>
> I hope someone, especially the Microsoft team, can clarify this issue 
> to help us make an informed decision.
>
> Thanks.
>
> Li
>
> [1] http://tools.ietf.org/id/draft-cbran-rtcweb-nat-00.txt
>
> [2] http://html5labs.com/cu-rtc-web/cu-rtc-web.htm
>
> *From:*Roman Shpount [mailto:roman@telurix.com]
> *Sent:* Wednesday, August 29, 2012 10:26 AM
> *To:* Stefan Hakansson LK
> *Cc:* public-webrtc@w3.org
> *Subject:* Re: Poll for preferred API alternative
>
>
> On Wed, Aug 29, 2012 at 8:30 AM, Stefan Hakansson LK 
> <stefan.lk.hakansson@ericsson.com 
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
> 1) Continue with a design based on the PeerConnection object, using 
> SDP as part of the API, roughly in the style of the current API 
> description.
> 2) Remove the PeerConnection object and all use of SDP from the API, 
> and pursue an API roughly in the style of Microsoft's CU-WebRTC proposal.
>
>
> I would hope 2 is chosen.
>
> PeerConnection API was created to simplify interoperability, but ended 
> up as something that will not work with SIP (modified offer/answer, a 
> large number of SDP extensions that are not supported by anything 
> currently existing, no support for forking) or  Jingle (Jingle was not 
> using SDP to begin with). I think having a big black box of SDP will 
> make interoperability harder, not easier.
>
> I also think that keeping the offer/answer and ICE state machines 
> hidden within the browser is undesirable. WebRTC application would 
> primarily need to communicate and interoperate with other instances of 
> the same WebRTC application. If some sort of session negotiation 
> protocol is chosen and used by this application, it should be possible 
> to enforce it for this application, without it being changed with the 
> browser update. If WebRTC application needs to interop with external 
> real time communication devices, it should also be possible to fix the 
> session negotiation protocol within the application and do no depend 
> on browser updates to modify it.
> _____________
> Roman Shpount
>