Re: [tram] Points that should be clarified in STUN-bis and TURN-bis

Simon Perreault <> Mon, 10 February 2014 16:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C80E61A07EE for <>; Mon, 10 Feb 2014 08:37:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q6ikjKT5QVAa for <>; Mon, 10 Feb 2014 08:37:14 -0800 (PST)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id A839C1A06F2 for <>; Mon, 10 Feb 2014 08:37:14 -0800 (PST)
Received: from ( [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by (Postfix) with ESMTPSA id 3DB814690D for <>; Mon, 10 Feb 2014 11:37:14 -0500 (EST)
Message-ID: <>
Date: Mon, 10 Feb 2014 11:37:13 -0500
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis
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: Mon, 10 Feb 2014 16:37:17 -0000

Le 2014-02-10 10:18, Paul Kyzivat a écrit :
>> Option 3 means you don't have to keep backward compatibility around
>> forever. Practically, all TURN-bis servers would be backward compatible
>> from day 1. Then as time passes the client population would gradually
>> migrate to TURN-bis. When the non-TURN-bis client population becomes too
>> small to justify the cost of backward compatibility, you can throw
>> compat away. For example, if you start a new implementation of STUN
>> today, it could be possible to ignore STUNv1 (depending on your target
>> market), and thus make the implementation smaller, simpler, easier to
>> test, and faster to develop.
> It would be more of an issue of there was a real issue if there was a
> significant cost to supporting backward compatibility. But IIRC, the
> only cost for backward compatibility here is filling in a standard
> default if the parameter is missing.

You are correct in this particular instance, of course. In general,
things may be different.

> The consequence of not requiring backward compatibility is that a
> developer does exactly as you describe above - ignore STUNv1
> compatibility in his server because he thinks his target market won't
> need it. Then it turns out that there is a STUNv1 client. And that
> client just fails because of this.

Correct. And then either 1) the developer realizes that this STUNv1
client is important enough to warrant additional development, or 2) the
developer says "tough luck" to the client, and the client's only
recourse it to upgrade to STUNv2. IMHO, that's exactly the kind of
thinking that we want to encourage! :)

Anyway, we're just philosophizing, this has no practical impact on
anything at this point.

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->