W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: Allowing RTCIceServer to contain multiple URLs

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Thu, 6 Jun 2013 06:21:23 +0000
To: Eric Rescorla <ekr@rtfm.com>
CC: Justin Uberti <juberti@google.com>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Mallinath Bareddy <mallinath@google.com>
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11355173C@xmb-aln-x02.cisco.com>

On Jun 1, 2013, at 3:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Wed, Apr 24, 2013 at 9:34 PM, Justin Uberti <juberti@google.com> wrote:
> I wasn't suggesting that you couldn't have multiple RTCIceServers - clearly that's something we still want to support. 
> 
> The idea was mainly to indicate a specific TURN server could be reachable via different protocols - while that can be accomplished via multiple RTCIceServers, it might not be desirable to try to use all protocols at once and allocate 3 TURN candidates (e.g. for UDP, TCP, and TLS). If there were multiple transports available for a single TURN server, TCP and TLS could be ignored if UDP worked (i.e. and only a single candidate would be allocated).
> 
> Agree this may not be needed if we can rely on using S-NAPTR to look up the TURN server addresses, but is this widely deployed today?
> 
> 
> I agree with Justin that it's highly desirable to be able to have the semantics that
> this is a single TURN server which is reachable via three mechanisms rather
> than three separate TURN servers, since I only really want to be connected
> to one of them.

+1

But have a read of section 6.1 of http://tools.ietf.org/html/rfc5766

and 

http://tools.ietf.org/html/rfc5389#page-21

I thought TURN already did what you needed (and did not rely on NAPTR or S-NAPTR)




> 
> I am not enough of an expert on DNS to know if S-NAPTR is practical here,
> but I've certainly heard plenty of complaints about how all but the most basic
> DNS features don't work. Do we have measurements about the accessibility
> of S-NAPTR from browser-class endpoints?
> 
> -Ekr
> 
> 
> 
> 
> On Wed, Apr 24, 2013 at 10:50 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 23 April 2013 23:06, Justin Uberti <juberti@google.com> wrote:
> > So to do this using the existing RTCIceServer syntax, one must create
> > separate RTCIceServer objects for each URI, all with the same credentials.
> > It seems like it would be cleaner to allow a list of URIs to be supplied in
> > a RTCIceServer, which would all share the same credentials. To achieve this,
> > we could simply change the current .url property from a DOMString to a list,
> > or add a new .urls property that is a list of DOMStrings.
> 
> > Any objections?
> 
> Yeah, what Cullen said, plus: if you have multiple URIs with the same
> credentials, make multiple RTCIceServers.  It's not especially hard:
> 
> var iceServers = stunServers.concat(turnUris.map(function(turnUri) {
> return { url: turnUri, credential: cred, username: user }; }));
> 
> 
Received on Thursday, 6 June 2013 06:22:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC