Re: [rtcweb] rtcweb-transports reference to TRAM discovery

"Mo Zanaty (mzanaty)" <> Thu, 18 December 2014 21:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E47A1A6FF0 for <>; Thu, 18 Dec 2014 13:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 EH7Z9NbNjhag for <>; Thu, 18 Dec 2014 13:19:41 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAF571A86F7 for <>; Thu, 18 Dec 2014 13:19:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2923; q=dns/txt; s=iport; t=1418937581; x=1420147181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cu0SvxyV25erUsDaRpLJCfhomNmVeARAgt46hPvwX0g=; b=iMxvsn7fmqd1kqGbkpg5HreCBEnsSKiKvlW9ja8e+y/xjSdzLryaCFz3 wurR9k7uw2aA809phUtlmn5fXwVui7p3JnRx6I/MqicdmqK6mt74xSuc6 lPr1C3i314YCkw8eQQXUlE9mp6dedOTh129bEJYHhhSjOFn19UFluHu12 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="381176171"
Received: from ([]) by with ESMTP; 18 Dec 2014 21:19:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sBILJckr005183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 21:19:38 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 15:19:38 -0600
From: "Mo Zanaty (mzanaty)" <>
To: Adam Roach <>, "Cullen Jennings (fluffy)" <>, "Hutton, Andrew" <>
Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery
Thread-Index: AQHQGwhTFJHl4UEJ8EuMGhMMTLb7dw==
Date: Thu, 18 Dec 2014 21:19:37 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
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: Thu, 18 Dec 2014 21:19:43 -0000

The priority order that makes most sense to me is:

1. user override
2. app override
3. auto discovery
4. app fallback
5. user fallback

If any override is configured by the user or app, do not perform auto
discovery, stop here.

If auto discovery fails, use a fallback configured by the app or user.

There is a big difference between an override and a fallback, so both seem

Obviously, we need some mechanism for 3 as Adam said, in case it needs to
be invoked.


On 12/18/14, 3:40 PM, Adam Roach <> wrote:

So, I think it's important that we have some way to encourage deployment
of TURN servers both in the ISPs, and as part of firewalls (both
residential and enterprise). By putting TURN in paths that are already
going to bear the traffic in question, the overall cost associated with
calls goes down, and call quality (latency, loss) improves.

I'm sympathetic to the position that we don't want to give these
entities specific hooks to force specific servers to be inserted into
the flow. We need to find a balance here: something that allows the
relevant entities to deploy and advertise such servers; something that
allows WebRTC applications to discover and use them; and something that
puts the ultimate decision in the hands of the users. Off the top of my
head, adding a browser API that allows applications to  to retrieve
these servers and elect to use them if it wants to would serve part of
the purpose; giving users a means by which they can instruct the browser
not to return such a list would serve the remainder.

But that's all kind of orthogonal to the IETF issues: if we're going to
do *anything* in this space, we need the discovery mechanisms.


On 12/18/14 11:23, Cullen Jennings (fluffy) wrote:
> It seems that in the mobile case and many residential cases, doing that
>draft would allow a service provider to force all the traffic through a
>TURN server of the service providers choosing. Am I reading this
>correctly because I am pretty sure I would not be in favor of that.
>> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew <>
>> I am thinking that
>>should include a requirement that a WebRTC Browser MUST support the TURN
>>server discovery as described in
>> Andy
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list

rtcweb mailing list