W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2012

Re: [Bug 17109] New: TURN server API changes

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sat, 19 May 2012 15:41:31 +0200
Message-ID: <4FB7A30B.6080207@alvestrand.no>
To: bugzilla@jessica.w3.org
CC: public-webrtc@w3.org
On 05/18/2012 07:49 PM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17109
>             Summary: TURN server API changes
>             Product: WebRTC Working Group
>             Version: unspecified
>            Platform: PC
>          OS/Version: All
>              Status: NEW
>            Severity: normal
>            Priority: P2
>           Component: WebRTC API
>          AssignedTo: public-webrtc@w3.org
>          ReportedBy: prakashr.ietf@gmail.com
>                  CC: public-webrtc@w3.org
> 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?
I went over this with Ian Hickson Way Back When - it seems that the TURN 
spec insists that any TURN server *has* to provide STUN service, so if 
you specify TURN, you either have a need to specify multiple servers (a 
completely different problem), or you don't need anything but TURN.
> 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?
Could we extend the parameters to the ICE handling callback?
> 4. How do we pass in a specific username/password for TURN or update it incase
> a username/password expires?
Strongest argument I've heard for making the config object be an object.

Received on Saturday, 19 May 2012 13:42:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:27 UTC