Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

Oleg Moskalenko <> Tue, 18 February 2014 06:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB3A41A05E8 for <>; Mon, 17 Feb 2014 22:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v4rJm8posZ3X for <>; Mon, 17 Feb 2014 22:24:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c02::235]) by (Postfix) with ESMTP id 7ACE71A0363 for <>; Mon, 17 Feb 2014 22:24:04 -0800 (PST)
Received: by with SMTP id y10so15651893pdj.26 for <>; Mon, 17 Feb 2014 22:24:01 -0800 (PST)
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=ZXbDLsJYaTnRKiOY5XqIbWSYjuh4wz9hrqJXS/i8AVs=; b=Jki7XjUaqh6PQkt+oZCx9keOLqNolNzhK1ZbLwwII0eFDDmAwk7a8MLsQVUG5e5LE6 SXBLbCS+R5QwEAK3P2OD4UGd+LsXgqQbEC1pgBurFlvC10UNLNDJt0wrYECYsqMPMZKB ymjeLf84Hyh7iKoSqgIys5Het1ja8opF8q/7erjXgbifhiZ54z+vnOrtSaMnFfGsFImT E0GrCkfdZFMQSmNmiP2u0QEHDIntaOLVeEugtAZH9/bsnWnBBVMWdkx1sqGdN+wuOg8d MEEeqGqeqfUqbFdJa3Bnggxk5kdq4FR9uty39qIEwnNOMO9BR0VqbXdeOB9dLpSWKH8a Ygwg==
MIME-Version: 1.0
X-Received: by with SMTP id xg2mr30739899pab.23.1392704641755; Mon, 17 Feb 2014 22:24:01 -0800 (PST)
Received: by with HTTP; Mon, 17 Feb 2014 22:24:01 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 17 Feb 2014 22:24:01 -0800
Message-ID: <>
From: Oleg Moskalenko <>
To: "Tirumaleswar Reddy (tireddy)" <>
Content-Type: multipart/alternative; boundary="047d7bacb47c72ef0904f2a851ea"
Cc: "" <>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt
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: Tue, 18 Feb 2014 06:24:07 -0000

Hi Tiru

regarding the refresh requests, please below:

On Mon, Feb 17, 2014 at 9:34 PM, Tirumaleswar Reddy (tireddy) <> wrote:

>   [Oleg]: Tiru, I'd still like to hear a more definite language: what
> about "new requests" within the existing session ? They are allowed to use
> the old token - right ? When you are saying "new requests" you mean "new
> session allocation requests", right ?
> [TR1]
> These are my initial thoughts (we probably need more discussion on this
> topic):
> [a] New token is definitely applicable for "new session allocation
> requests".  If the client uses the token after its lifetime then the TURN
> server MUST return error that the token is invalid which is in line with
> the steps defined in
> [b] For "new request" within the existing session why not use the new
> token ? This way the client has to maintain only one token.  We can clarify
> in the draft that Refresh request can carry the new access token.
> [c The actual lifetime provided by the server in the Allocate/refresh
> response should be less than or equal to the lifetime of the token.
I re-read the appropriate section of STUN RFC 5389:

and I have a feeling that the password in the existing TURN clients and
TURN servers is supposed to be cached for the lifetime of the session. If
we allow the token to be valid for the lifetime of the session that was
established with that token (for this particular session only) then
probably the draft specs will be easier to implement and it will be more
directly related to the original STUN RFC 5389.

But I have no strong opinion on that, it can be both ways.