Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt

Adam Roach <> Mon, 22 July 2013 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E66611E813F; Mon, 22 Jul 2013 13:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0xIj3z6JHUKN; Mon, 22 Jul 2013 13:16:36 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 699C911E8145; Mon, 22 Jul 2013 13:16:36 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r6MKGTvC065788 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 15:16:30 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Mon, 22 Jul 2013 15:16:24 -0500
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Rajmohan Banavi <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070307020801070707040107"
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: behave <>, "" <>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt
X-Mailman-Version: 2.1.12
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, 22 Jul 2013 20:16:37 -0000

On 7/18/13 07:28, Rajmohan Banavi wrote:
> Hi  Justin, comments inline with additional comments at the end.
>     Correct, but that is a significant advantage, especially when the
>     web and TURN servers are separate entities.
> IMHO, the standard spec should not be based on any specific 
> implementation method. Now I agree that the TURN server validation 
> becomes easier using this method because it does not have to do some 
> sort of lookup. However, some another TURN server implementer can 
> achieve the same functionality by providing REST API but using 
> randomly generated pasword (rather than use HMAC) and using some sort 
> of lookup for TURN username when TURN ALLOCATE request is received.

I think the value here -- the value in defining a common scheme for 
password generation -- is that I could get an off-the-shelf TURN server 
from arbitrary vendor A, and run an off-the-shelf credential server from 
abitrary vendor B, and it would all work together. What you propose 
requires collusion between the TURN server provider and the credential 
server provider, using a not-yet-defined (and, if I read your proposal, 
never-publicly-defined) protocol to share credential information via a 

What Justin proposes gets us this inter-vendor interop cheaply and 
easily. What you're counterproposing forces people into a single-vendor 
(or, at least, partnered) solution, which kinda defeats the purpose of 
defining this in an SDO in the first place.