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

makes sense - totally agree we need a way to get these errors up. It's really hard to debug when stuff is going wrong with ICE/TURN/STUN. We will need some careful thought about how to design the error reporting such that JS applications can be coded in a way where they can deal with the errors in a reasonable way. 

On Aug 13, 2012, at 8:09 PM, Prakash <prakashr.ietf@gmail.com> wrote:

> Cullen,
> 
> This was filed a while back on the old spec, when there was no way to specify, multiple servers etc. Using a url  instead of a separate host and port seems fine to me.  It is part 2. that we want to discuss. STUN and TURN allocation can fail or can have availability errors. We may want to figure out, how to bubble these up to JS if required.
> 
> -Prakash
> 
> On Mon, Aug 13, 2012 at 7:37 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> 
> I'm strongly against the changes suggested in this but. This needs list discussion.
> 
> Using a URL has many advantages in that it allows us to correctly interact this thing like v4, v6, DNS SRV, and so on without hard coding them into the API. It also allows extensibility for future relay mechanism such as one that looks like HTTPS.
> 
> 
> On May 18, 2012, at 11:49 AM, 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?
> >
> > 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 Tuesday, 14 August 2012 03:09:35 UTC