RE: ICE in MS Proposal

Martin,

My question actually has two parts: 1) how an application gets other ICE candidate items; and 2) how it conveys that information to the peer.

You answered the first part. For the second part, I had these steps in my mind following the current W3C API model:

1) browser A gathers its ICE candidates;
2) browser A converts the candidates to a predefined JS structure X and hands them over to the signaling component;
3) the signaling component converts X to a wired format and transmits it to browser B;
4) browser B signaling component receives the format and converts it back to X for further processing;

The MS API defines X to be RealtimeMediaDescription(Dictionary) in case of media streams. I thought there should be a X for the ICE candidates as well. Or maybe the MS API has a different model?

Thanks.
Li

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, August 30, 2012 2:31 PM
To: Li Li
Cc: public-webrtc@w3.org
Subject: Re: ICE in MS Proposal

On 30 August 2012 10:37, Li Li <Li.NJ.Li@huawei.com> wrote:
> Hi Martin,
>
> I find MS proposal interesting as I study it more. But I do have this follow-up question.
>
> I didn’t find a JS structure in the API to represent ICE candidates that contains information in SDP a=candidate lines, as RealtimePort doesn't contain attributes like candidate type and priority.
> Without a predefined structure like RealtimeMediaDescription for media, how would a browser convey complete information about its ICE candidates to its peer?

I assume that you refer to priority.  The other items don't need to
come from the browser.  Foundation, component ID and candidate type
are known to the application.

Priority was omitted for a number of reasons.  Mainly, this was an
efficiency choice.  ICE operates well enough without it.  That said,
it is relatively trivial to add if it turns out that additional
sorting guidance is found to be useful.

Starting with a minimally functional set of features is generally a good policy.

Received on Thursday, 30 August 2012 19:29:51 UTC