Re: [rtcweb] STUN for keep-alive

Göran Eriksson AP <> Wed, 14 September 2011 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A4CC21F8B50 for <>; Wed, 14 Sep 2011 10:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X8yH3lqyXkqI for <>; Wed, 14 Sep 2011 10:19:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A206121F8783 for <>; Wed, 14 Sep 2011 10:19:55 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-3f-4e70e2bc7915
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 95.CD.20773.CB2E07E4; Wed, 14 Sep 2011 19:22:04 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Wed, 14 Sep 2011 19:22:04 +0200
From: Göran Eriksson AP <>
To: Eric Rescorla <>, Harald Alvestrand <>
Date: Wed, 14 Sep 2011 19:22:04 +0200
Thread-Topic: [rtcweb] STUN for keep-alive
Thread-Index: AcxzAtIrLPZKGABkTMGGxQs4774q6A==
Message-ID: <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] 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: Wed, 14 Sep 2011 17:19:56 -0000

Can we assume that all PeerConnections will include an audio/video stream-
some may have only a 'data' connection between the
browsers- can't rely on RTCP can we (assuming we don't use RTCP for
generic data)?


On 2011-09-14 19:13, "Eric Rescorla" <> wrote:

>One new concern in this context is maintaining the consent freshness.
>The browser
>needs to be sure that the recipient of traffic is stil responding in a
>way that can't be
>forged. It's likely RTCP provides this (though we'd need to analyze to
>be sure) but
>perhaps better would be to mandate STUN checks at enough frequency that
>you get some sort of level of freshness.... maybe every 2 minutes or
>On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand <>
>> On 09/14/11 15:07, Christer Holmberg wrote:
>>> Hi,
>>>>> |Sure, but there is still a max time between the keep-alives.
>>>> You are free to set it to a very long duration that disables
>>>> keepalives for all practical purposes (assuming such duration
>>>> is represented by a 32-bit unsigned integer you can set it to
>>>> ~136 years).
>>> Yes, but at the end of the day something has to be sent in order to
>>> the NAT binding open.
>>>>> |Using e.g. RTP, the media handler would not have to be prepared to
>>>>> |receive the STUN keep-alives in the first place, it could
>>>>> |simply just
>>>>> |relay whatever comes on the media plane.
>>>> If the media handles can handle STUN binding requests
>>>> efficiently I don't see why they can't handle STUN binding
>>>> indications (keepalives) in a similar manner.
>>> I believe it knows when to expect those. But, in any case, the main
>>> behind the proposal is to decrease the number of STUN requests.
>> I think it's a more urgent desire that we should minimize the number of
>> variants of protocols in use.
>> Defining a variant of ICE that modifies the keepalive mechanism seems
>>to me
>> like a Bad Idea.
>>                     Harald
>> _______________________________________________
>> rtcweb mailing list
>rtcweb mailing list