- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Thu, 23 Oct 2014 10:59:22 +0200
- To: Jiannan Zheng <jzheng@exchange.microsoft.com>
- Cc: "public-ortc@w3.org" <public-ortc@w3.org>
2014-10-23 3:05 GMT+02:00 Jiannan Zheng <jzheng@exchange.microsoft.com>: > 8.1.1. Nominating Pairs > > The controlling agent nominates pairs to be selected by ICE by using > one of two techniques: regular nomination or aggressive nomination. > If its peer has a lite implementation, an agent MUST use a regular > nomination algorithm. If its peer is using ICE options (present in > an ice-options attribute from the peer) that the agent does not > understand, the agent MUST use a regular nomination algorithm. If > its peer is a full implementation and isn't using any ICE options or > is using ICE options understood by the agent, the agent MAY use > either the aggressive or the regular nomination algorithm. However, > the regular algorithm is RECOMMENDED since it provides greater > stability. > " > We cannot blindly throw it away at JS layer. Upon seeing unknown ice-options, browser must switch to regular nomination, however we don't have a way to retrieve/set it on browser through ORTC. Yes, I know that. However let me make it clear: - There is no one standardized ice-option yet. - It is 100% unclear the reasons for which adding a future ice-option means that devices not supporting them must fall back to regular nomination. - There is no room in the ORTC API for setters that add no value or unknown fields. - ORTC does not define the "signaling format". So, for example, let's have a JS shim implementing WebRTC 1.0 (SDP). - An SDP offer is received containing "a:ice-options:foo". Should the ORTC API include an API setter like "setIceOption(name, value)"? what for? Basically the internal/native ORTC stack will do: if (iceOptions.length > 0) { // force regular nomination } That is a no sense in a well designed API. Instead we need a simple setter "forceRegularNomination()" (or a param in RTCIceParameters), and our JS shim should set it when the remote SDP (or whatever it receives via signaling) includes any ice-option (or any ice-option that it is known to force regular nomination). -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Thursday, 23 October 2014 09:00:09 UTC