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

Re: Allowing RTCIceServer to contain multiple URLs

From: Justin Uberti <juberti@google.com>
Date: Wed, 24 Apr 2013 21:34:26 -0700
Message-ID: <CAOJ7v-2LD+rM3qoTcxbLzKP0KBJUbZMVh_osnRxNgFcENZPcuQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, Mallinath Bareddy <mallinath@google.com>
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

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?

On Wed, Apr 24, 2013 at 10:50 AM, Martin Thomson

> 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, 25 April 2013 04:35:22 UTC

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