Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

Christer Holmberg <> Mon, 27 October 2014 18:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB2DD1A8956 for <>; Mon, 27 Oct 2014 11:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Br2iMJMDNBMK for <>; Mon, 27 Oct 2014 11:10:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C639A1A894A for <>; Mon, 27 Oct 2014 11:10:38 -0700 (PDT)
X-AuditID: c1b4fb3a-f79596d000001123-59-544e8a9c78ab
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DA.87.04387.C9A8E445; Mon, 27 Oct 2014 19:10:36 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 19:10:35 +0100
From: Christer Holmberg <>
To: "Ram Mohan R (rmohanr)" <>, "" <>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIw==
Date: Mon, 27 Oct 2014 18:10:34 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje6cLr8QgzUNshbLu3YwWqz9187u wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGV07jjBWnBdsGLRnFusDYy3ebsYOTkkBEwk drV9Y4ewxSQu3FvP1sXIxSEkcIRRYtvMW4wQzhJGiYMPJ7F2MXJwsAlYSHT/0wZpEBEIk5h+ YgELiC0skC/RenQSO0S8QOJ0wxlGCFtP4tbMiUwgNouAqsSpF2vB6nkFfCWezv0LFmcEWvz9 1Bowm1lAXOLWk/lMEAcJSCzZc54ZwhaVePn4HyuErSSx6PZnqHodiQW7P7FB2NoSyxa+ZoaY LyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAgM +4NbflvtYDz43PEQowAHoxIP74ca3xAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cBoVib1vJN74TVV+aCQU9/tLUQa2Be9XicRIaDIYdTJ32z/UOp82GkG N69tLbYRBxezvhco67l24dbpBytuPBeRlJ+0c3PuR+kUza8Gai5xZ/aKmeiznNPU4osuVTdX ClTcc0BuywLuq3IayV+PqZvzbThsutDQcWPLbsFKo8/ld+37/+jKP1FiKc5INNRiLipOBAD0 smaoXAIAAA==
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
X-Mailman-Version: 2.1.15
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, 27 Oct 2014 18:10:44 -0000


Thanks for putting together the new version! It makes a number of things more clear :)

I do still have a few comments/questions (hopefully editorial ones), though:


I think it would be good to explicitly clarify that, when consent expires on a 5-tuple/candidate pair, it does not affect other 5-tuples within the session. I have received questions on that, so I think some words would be useful to make it more clear.

(Of course, one CAN choose to terminate the whole session if consent expires on a candidate pair, but that depends on application policy).


If consent expires, and I stop sending application data, will I still send STUN keep-alives etc, to keep the candidate pair, NAT bindings etc alive? 

There IS text saying:

	"An endpoint that is not sending any application data does not need to
   	maintain consent.  However, the endpoint needs to ensure its NAT or
   	firewall mappings persist which can be done using keepalive or other
   	techniques (see Section 10 of [RFC5245] and see [RFC6263])."

However, that seems to be more related to cases where I don't intend to send application data to begin with.

So, perhaps the text above can be modified, to clarify that keepalives etc will still be sent if consent expires.


Section 4.1. says:

	"If the endpoint wants to send application data, it needs to first obtain
   	consent if its consent has expired."

If my consent has expired, is the a time period before I can try to obtain consent again? Can I just continue sending STUN binding requests even if my consent expires, and wait to obtain consent again?

(I obviously won't send any application data until I obtain consent again.)


When my consent expires, is it considered an error if I also choose to not receive any data? If not, I think it would be good to indicate that one may choose to also stop receiving data in case consent expires.


Assuming I send RTP and RTCP on separate 5-tuples, and consent expires on one of the 5-tuples. I assume that will impact both 5-tuples, and in that case I think it would be good to clarify.