Re: ACTION-95: Constraints usage in the WebRTC spec

On 2014-01-21 10:41, Adam Bergkvist wrote:
> On 2013-11-26 15:33, Adam Bergkvist wrote:
>> ## IceTransports
>> Used with PeerConnection() Constructor and updateIce()
>>
>> Controls which types of candidates the ICE agent is allowed to use.
>>
>> The possible values are "none", "relay" and "all". If a browser, for
>> some special reason, is configured to not support all these values, that
>> might be a reason to have it as a constraint.
>>
>> Proposal: Move to RTCConfiguration?
>
> updateIce() is changing from
>
> void updateIce (optional RTCConfiguration configuration, optional
> MediaConstraints constraints);
>
> to
>
> void updateIce (RTCConfiguration configuration);
>
> Both arguments used to be optional, but unless someone comes up with a
> reason why you would like to run updateIce() with no arguments, I'll
> make the first argument mandatory as well.
>
> To the real question.. Does updateIce() accept changes to everything in
> the RTCConfiguration dictionary?
>
> dictionary RTCConfiguration {
>      sequence<RTCIceServer> iceServers;
>      RTCIceTransports       iceTransports = all;
> }

Follow up question.. The spec doesn't say anything about what should 
happen when the RTCConfiguration dictionary contains bad input. For 
example, malformed ice server urls (SyntaxError is usually thrown in 
this case). It would be nice to have some text that validates the 
content of the RTCConfiguration that could be shared between the 
RTCPeerConnection() constructor and the updateIce() method (since they 
both deal with this dictionary). So what can go wrong and what errors 
should be throw?

/Adam

Received on Tuesday, 21 January 2014 10:37:20 UTC