W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

ICE in MS Proposal

From: Li Li <Li.NJ.Li@huawei.com>
Date: Wed, 29 Aug 2012 19:03:43 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <B60F8F444AAC9C49A9EF0D12D05E0942216C077E@szxeml535-mbx.china.huawei.com>
Hi Martin,

Thanks for your reply. Just wanted to be sure that your proposal mandates an ICE state machine inside the browser that is shared by different local RealtimePort objects.
For example, if a JS pairs up the local and remote ports in random, the ICE machine would reorder the pairs by their pair priorities and check them accordingly.


-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, August 29, 2012 11:45 AM
To: Li Li
Cc: public-webrtc@w3.org
Subject: Re: Poll for preferred API alternative

On 29 August 2012 08:15, Li Li <Li.NJ.Li@huawei.com> 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:

We determined that the concerns raised with respect to timer
resolution were a non-issue.  The browser can manage the important
part of the pacing, that being the rate limiting of outgoing checks.

Section 6.4 [1] describes the behaviour expected of browsers, specifically:

    Binding requests must be globally rate limited by the browser.
    Any requests that cannot be immediately sent are enqueued.

[1] http://html5labs.com/cu-rtc-web/cu-rtc-web.htm#connectivity-checking

Received on Wednesday, 29 August 2012 19:08:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:29 UTC