Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]

Randell Jesup <> Thu, 22 September 2011 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2739D21F84D2 for <>; Thu, 22 Sep 2011 09:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7dKnlTbOVFLf for <>; Thu, 22 Sep 2011 09:51:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9545621F84D9 for <>; Thu, 22 Sep 2011 09:51:57 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R6mXd-0003j7-E9 for; Thu, 22 Sep 2011 11:54:29 -0500
Message-ID: <>
Date: Thu, 22 Sep 2011 12:51:00 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
References: <><><><><><><><092401cc749b$8fd64940$af82dbc0$@com><><><0ced01cc76de$28731630$79594290$@com> <> <> <> <> <4E7B2C04.401 0204@eri> <> <> <4E7B5A2F.8020102@ericss>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
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: Thu, 22 Sep 2011 16:51:58 -0000

On 9/22/2011 11:54 AM, Magnus Westerlund wrote:
> On 2011-09-22 17:09, Randell Jesup wrote:
>> There certainly may be use-cases where media in one (or both)
>> directions are inactive or DTX-muted for considerable periods of time
>> - remember, many of the use-cases (and unknown interesting future
>> uses) aren't "phone calls".
>> In particular, I have some interesting use-cases bubbling in the back
>> of my brain where the data channel remains open at low/no activity
>> and the media channels are inactive or non-existant for long periods,
>> or where data traffic predominates and media are often inactive.
> Yes, I definitely believe you. Which only points that we will need to
> consider issues like how much background traffic that occurs just from
> having the PeerConnection up and being ready for sending media. Maybe
> mandate maximum levels when in practice inactive.
> It also has implication I think on the continued media consent. As the
> point raised Muthu is that when none sends media, there is in fact zero
> entropy in the RTCP RR compound packets. Thus RTCP can't be used for that.
I wonder: could we create a default reliable data channel in all
PeerConnections that's used (solely?) for a heartbeat/"consent freshness"?
In that case, we get to define the heartbeat and can mandate enough entropy.
(Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.)

Randell Jesup