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

Rajmohan Banavi <> Wed, 24 July 2013 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C71B11E81FF; Tue, 23 Jul 2013 23:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5v4Ee7YqYGTW; Tue, 23 Jul 2013 23:54:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::22d]) by (Postfix) with ESMTP id 3028611E80E3; Tue, 23 Jul 2013 23:54:36 -0700 (PDT)
Received: by with SMTP id j1so76597oag.32 for <multiple recipients>; Tue, 23 Jul 2013 23:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yeAOOUID4SqBHOremPsOvPkkv9C6njiYcfA6HHmeWKk=; b=eC98Q+FKhnP2CLoP1XzDrw3Q1cygqnHgud/kxolLt0KYOt4UWduk7t3qcFI2dk/LoK 0wwqp4b7QfXmKBjgQ3Vi80HnOWkP92y2Cxkf958GfHhsr9gADETp3jREozujhOCSjqn0 93TVszfFTeI23RCEKDOMP8QTTD2D6DkeyRxxZTmlMe9fb/wck02bUVmrG7JyQ/eaGnGQ CgWgc6cLhfDwlWgleAbmIXe2nPjEn8Dsi4lbY9Y5pJ2nex+c+nl+Hd9NxQeEHMHm2j0c iLOhtgHATkQhlXuly1dVJ8WEvw1e/jGZfNPfDvTiwzBr0jHBi1J8WcxF/Rp8HvXWMg5c r8Gw==
MIME-Version: 1.0
X-Received: by with SMTP id 14mr244058igk.60.1374648874510; Tue, 23 Jul 2013 23:54:34 -0700 (PDT)
Received: by with HTTP; Tue, 23 Jul 2013 23:54:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 24 Jul 2013 12:24:34 +0530
Message-ID: <>
From: Rajmohan Banavi <>
To: Justin Uberti <>
Content-Type: multipart/alternative; boundary="047d7bdc119adb319c04e23c619a"
Cc: behave <>, Oleg Moskalenko <>, "" <>
Subject: Re: [rtcweb] [BEHAVE] 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: Wed, 24 Jul 2013 06:54:37 -0000

> So there are two parts to the proposal - the HTTP request for the
> credentials and interactions with WebRTC, and the stateless implementation
> that avoids the need for communication between web and TURN servers. And it
> is true that other implementations besides the suggested stateless one are
> possible, e.g. OAuth2.
> Would you prefer that I address the protocol and implementation parts
> separately in the document, and mention that other implementations with the
> same HTTP protocol are possible? RFC 5766 does something similar, where it
> defines the TURN protocol, but in Section 6.2 talks about how a "stateless
> stack" implementation can be used to simplify the processing on the TURN
> server.
> As you pointed out, the draft essentially has 2 parts - the REST API and
the stateless stack implementation which are completely independent. So
yes, separating them would help because we want other implementations to
also be compliant to the spec. Having said that, I would like opinions and
consensus from others as well.

Just to make my earlier point clearer - The credentials are generated by
TURN server and validated by TURN server. None of the other components in
the chain - web server, web application and the webrtc client, are
concerned with it (sort of like a blob). So the interoperability is not an
issue at all irrespective of what implementation approach you take.

I had some other comments earlier, which are collated below.

   1. What does the web server do with the shared (with TURN server) secret
   key? This is not clear from the text.
   2. Sec 4.2 Server - "Note that the REALM value supplied by the server is
   not meaningful in this context, and can be set to any valid value". Which
   realm value is being referred here? The REALM attribute value in the 401
   challenge response sent by the TURN server (in response to initial ALLOCATE
   3. The 2 statements seem to be contradictory: sec 1 "However, as a relay
   service, it imposes a nontrivial cost on the service provider". sec 5.1
   "The assumption is that TURN services are of low enough value that waiting
   for the timeout to expire is a valid approach for dealing with
   possibly-compromised credentials". I am OK with the text, but would prefer
   if this could be reworded in anyway.