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

[Bug 17109] New: TURN server API changes

From: <bugzilla@jessica.w3.org>
Date: Fri, 18 May 2012 17:49:29 +0000
To: public-webrtc@w3.org
Message-ID: <bug-17109-4991@http.www.w3.org/Bugs/Public/>
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?

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?

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
Received on Friday, 18 May 2012 17:49:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:35:45 UTC