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

Re: Allowing RTCIceServer to contain multiple URLs

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Wed, 24 Apr 2013 14:14:18 +0000
To: Justin Uberti <juberti@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Mallinath Bareddy <mallinath@google.com>
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11349B1B2@xmb-aln-x02.cisco.com>

On Apr 24, 2013, at 12:06 AM, Justin Uberti <juberti@google.com> wrote:

> Right now RTCIceServer has two properties, url and credential, and we recently agreed to add a third property, username, since STUN/TURN URIs no longer contain a username.
> While looking into the implementation of this change, we realized that one will typically specify several URIs for the same TURN server, for the different transports that can be used to access it (UDP, TCP, TLS). However, the username/credential will be the same, regardless of transport.
> 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.
> This is a mostly cosmetic change, but it seems like it's a better fit for what a "RTCIceServer" really is. 
> Any objections?

Uh, often you have multiple servers that have different credentials - so whatever we do, I don't want to break or complicate that.

Second, I don't see why you would have multiple URL for the various transports. You should have one with no transport specified and the the multiple protocol stuff in RFC 5928 will take care of letting you know which transports are supported. So for most use cases, you should only need one URI per server. 
Received on Wednesday, 24 April 2013 14:14:47 UTC

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