- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 21 Jan 2014 11:35:36 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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