Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 22 Oct 2014 16:43:59 +0200

Section 3.4

" WebRTC browsers MUST support configuration of STUN and TURN servers,
   both from browser configuration and from an application."

Should we mention which takes precedence? If configured in the browser, start with that server.
If not use the one provided by the application.

Maybe we should clarify that turn DNS discovery MUST be used to provide failover and load balancing.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Oct 2014 14:51:31 +0000

Hi,

The advantage of an application configuration is that it can be dynamically provided/updated, based on location based etc - assuming the webpage provider has knowledge about STUN/TURN servers, of course.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: [email-masked]
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

/O
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Benjamin Schwartz <[email-masked]>
Date: Wed, 22 Oct 2014 10:57:53 -0400

FYI, the purpose of the RETURN draft (
https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03) is to try to
specify the precise interaction and precedence when both the browser and
the application provide TURN servers.  (It's not as simple as "one or the
other".)

I haven't considered the issues related to browser-provided STUN servers,
though.

On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> The advantage of an application configuration is that it can be
> dynamically provided/updated, based on location based etc - assuming the
> webpage provider has knowledge about STUN/TURN servers, of course.
>
> Regards,
>
> Christer
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 Oct 2014 08:58:44 -0600

I just want to mention this:

http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00

I think that both browser and application configuration are included in
step #1 of the discovery algorithm, so that doesn't answer Olle's question.
But we still need to keep the whole discovery process in mind.

Simon

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 23 Oct 2014 14:26:59 +0200

On 22 Oct 2014, at 16:57, Benjamin Schwartz <[email-masked]> wrote:

> FYI, the purpose of the RETURN draft (https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03) is to try to specify the precise interaction and precedence when both the browser and the application provide TURN servers.  (It's not as simple as "one or the other".)
> 
> I haven't considered the issues related to browser-provided STUN servers, though.
Cool! I'll take a look at that. Maybe Haralds draft need to refer to that.

/O
> 
> On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg <[email-masked]> wrote:
> Hi,
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 23 Oct 2014 12:31:54 -0700

Generally, I think there is a fair amount of confusion about how these
various types of TURN servers are going to work. The RETURN draft takes a
first stab at defining the interactions here, and ideally it can be adopted
as a WG draft and referred to by -transports.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 27 Oct 2014 12:10:14 +0000

In order to avoid the confusion, we recently published http://tools.ietf.org/html/draft-patil-tram-turn-serv-selection-00 which describes TURN selection criteria, as guidelines, that can be used by a client to perform an informed TURN server selection decision when a client discovers multiple TURN servers.

-Tiru

From: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 24, 2014 1:01 AM
To: "Olle E. Johansson" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Generally, I think there is a fair amount of confusion about how these various types of TURN servers are going to work. The RETURN draft takes a first stab at defining the interactions here, and ideally it can be adopted as a WG draft and referred to by -transports.

On Thu, Oct 23, 2014 at 5:26 AM, Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

On 22 Oct 2014, at 16:57, Benjamin Schwartz <[email-masked]<mailto:[email-masked]>> wrote:

/O

On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Olle E. Johansson
Sent: 22 October 2014 17:44
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] draft-ietf-rtcweb-transports-07.txt

Section 3.4

/O
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb