This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
These are some of the questions for TURN server based on read the spec here. http://dev.w3.org/2011/webrtc/editor/webrtc.html 1. The PeerConnection constructor takes in a configuration to specify TURN/STURN server configuration. Currently it states "The configuration string gives the address of a STUN or TURN server to use to establish the connection." Shouldn't we allow to pass two different IPs for STUN and TURN and not restrict either or? 2. The configuration parameter is taken in as a string. Isn't it easier to make this an object, like we did for "audio video" in getUserMedia? 3. There should be some way for PeerConnection to get a feedback back to Javascript layer in case of an error. A relay/stun server can throw different types of errors, like unauthorized, insufficient capacity. Also username/password have a life time and can expire in a relay server. When this happens, the app will have to refresh the relay server info in some way. So we need a callback/update mechanism for these things. This does not seem to exist currently? 4. How do we pass in a specific username/password for TURN or update it incase a username/password expires?
Here are some suggestions on the API. -- 1. Configuration : The PeerConnection should take in a array of configuration object instead of a string. [NoInterfaceObject] interface IceConfiguration { readonly attribute DOMString type; readonly attribute DOMString host; readonly attribute short port; readonly attribute DOMString username; readonly attribute DOMString password; }; type - one of TURN/TURNS/STUN/STUNS host - <hostname/ip> port - port for STUN/TURN username - optional username for STUN/TURN password - optional password for STUN/TURN The reason for the array is that if STUN/TURN fails, the code may have fall back to STUNS/TURNS. Open question: Can users include a separate STUN and TURN server, in which case the provided STUN is used and the TURN server is used for relay purpose only? Note that startIce() takes in a parameter to say no_relay or only_relay. So the implementation has to use that to decide what to connect and not just based on the values provided in the configuration. 2. Error callbacks. STUN and TURN can return a number of errors which has to be bubbled up to JS. A summary of error codes are available here. http://www.iana.org/assignments/stun-parameters/stun-parameters.xml#stun-parameters-6 The options for JS in case of errors are: to either throw it to the user and stop peerconnection if unrecoverable (like relay quota exceeded) or create a new peerconnection (say with a new TURN/STUN configuration - incase of server error or stale credentials) and retry. An error callback is passed on to the PeerConnection along with the iceCallback. [Constructor (DOMString configuration, IceCallback iceCallback, IceErrorCallback iceErrorCallback)] interface PeerConnection { ... } The IceErrorCallback takes in an IceError object [NoInterfaceObject] interface IceError { const unsigned short UNAUTHORIZED = 401; ... readonly attribute unsigned short code; }; code - A subset of http://www.iana.org/assignments/stun-parameters/stun-parameters.xml#stun-parameters-6. To be documented.
I think this needs some list discussion.
A lot has happened in the draft compared to when this bug was filed. I will close it unless someone objects in the next couple of days.
There was no comment, so I conclude that this is now fixed (with all updates that has come since the bug was filed).