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

"Tirumaleswar Reddy (tireddy)" <> Mon, 27 October 2014 12:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 66BA41A923B for <>; Mon, 27 Oct 2014 05:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VYKtMpQuU1X3 for <>; Mon, 27 Oct 2014 05:10:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EFAF1A9232 for <>; Mon, 27 Oct 2014 05:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14992; q=dns/txt; s=iport; t=1414411816; x=1415621416; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CfieLu/xeP6ZI5zt3nD7/VkKQS7QYIqy6Q1CfsiU0l8=; b=L2n0OXN3Y73EgISl7vgyQqHS8q4RKbeEwMqlJ21Z2Keg52BpS0Dai0lT 6OoxVtNViF3P/difkcpSFvzGkbH9rEAWmjq9MmtrU0bQ42Nm0CG3XoweL 7x7PyroL1+Om9mlV9potxcZvqwdyUSkO+GT7V4+8OzGLH6CfV0FexnrB1 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.04,795,1406592000"; d="scan'208,217"; a="90640612"
Received: from ([]) by with ESMTP; 27 Oct 2014 12:10:15 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9RCAFgp029226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 12:10:15 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 07:10:15 -0500
From: "Tirumaleswar Reddy (tireddy)" <>
To: "" <>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-transports-07.txt
Thread-Index: AQHP8d5ZlbbCz7ldKkqyzNNpC1BdnZxD2P0g
Date: Mon, 27 Oct 2014 12:10:14 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2834FE75xmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-07.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Oct 2014 12:10:55 -0000

In order to avoid the confusion, we recently published 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.


From: Justin Uberti <<>>
Date: Friday, October 24, 2014 1:01 AM
To: "Olle E. Johansson" <<>>
Cc: "<>" <<>>
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 <<>> wrote:

On 22 Oct 2014, at 16:57, Benjamin Schwartz <<>> wrote:

FYI, the purpose of the RETURN draft ( 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.


On Wed, Oct 22, 2014 at 10:51 AM, Christer Holmberg <<>> wrote:

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.



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

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.

rtcweb mailing list<>

rtcweb mailing list<>

rtcweb mailing list<>