RE: Poll for preferred API alternative

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