- 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