Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

"Pal Martinsen (palmarti)" <> Thu, 13 February 2014 14:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 630361A02A1 for <>; Thu, 13 Feb 2014 06:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZFrQ3NlL5v_Z for <>; Thu, 13 Feb 2014 06:40:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7D9801A02A4 for <>; Thu, 13 Feb 2014 06:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2988; q=dns/txt; s=iport; t=1392302431; x=1393512031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wHwM7zX2zSPbLQdQWArravSYYgwofSOi9kUHNorGpgw=; b=FC796uqjAIOebE30CFiAHsNICQWFZDx/9DHwajiWQxKepR5FTt+zgCAB PiUmMseUS9AQ4ewsAEnIyNzDbAmtUtyd7ChFt/mU4Zr/dLUhkR9hurp84 l80AMlj4RUaZg7yUt2MfA/un1TFgx+OKi72TQ3gxkJqZWhS4G0LiEWpmf k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="20173826"
Received: from ([]) by with ESMTP; 13 Feb 2014 14:40:31 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1DEeVeR001304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 14:40:31 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:40:31 -0600
From: "Pal Martinsen (palmarti)" <>
To: "" <>
Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
Thread-Index: AQHPJ7mlTNEKdEV/S06oVknK3f+v9pqxnjCAgAABbgCAAB7xgIAAizSAgAAdCoCAAIjhgIAAsgGAgAAGhYA=
Date: Thu, 13 Feb 2014 14:40:30 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Simon Perreault <>
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Feb 2014 14:40:38 -0000

On 13 Feb 2014, at 15:17 pm, Simon Perreault <> wrote:

> Le 2014-02-12 22:40, Tirumaleswar Reddy (tireddy) a écrit :
>> There are other ways to solve the problem for example using PCP.
> True.
>> Can you clarify how deploying a TURN server in the Enterprise
>> protects the users and the network ?
> IMHO that's not the right question to ask. It is pretty clear to me
> that, technically, TURN does indeed have the potential to solve the
> problem identified by Karl. (I understand the problem to be: "ISP wants
> to provide enhanced QoS to WebRTC.")
> I have two questions in my mind:
> a) Is this a real problem that is worth fixing?
Yes.. But not just QoS. There should be some kind fairness and “share the resources” so everyone can get the best result. If the link is getting crowed it would be nice of the endpoint than can would for example reduce its bandwidth by dropping from 1080p to 720p. Tis have some impact on user experience, but uses half the bandwidth. 

I would like us to move away from hard reservations as that does not give us the best usage of a scarce resource (bandwidth) as video codecs are very elastic in its nature and it would be hard to know how much bandwidth to allocate for a video stream. 

But i might be dreaming.

> b) Is TURN the best, most appropriate solution?

Probably a part of the solution, It is a nice way of “forcing” media through a certain path. But I think that path only should be chosen by the endpoint if that is the best(*1) path.   (*1) For certain values of best..

I have been planning to write a draft: POLICE, Path Optimisation done Locally with ICE. But that probably belongs to MMUSIC. But to get that of the ground we need to figure out how to get more information from the network regarding bandwidth, cost and other decisions that might influence the path selection. (RTT we get from the connectivity checks). That would be something for the TRAM WG to figure out.. (And maybe the PCP WG)

Another thing to remember is that webRTC is probably going to use Trickle-ICE. In clear that means the host candidates will be tested as soon as they are ready. The rest of the candidate discovery might happen in parallel or after. This might affect how we discover the available TURN servers.

Due to security concerns the webRTC also severely limits the speed the connectivity checks happen. So unless Trickle ICE is in use it is good to keep the number o candidates to a minimum.  


> Simon
> -- 
> DTN made easy, lean, and smart -->
> NAT64/DNS64 open-source        -->
> STUN/TURN server               -->
> _______________________________________________
> tram mailing list