Re: [rtcweb] STUN for keep-alive

Göran Eriksson AP <goran.ap.eriksson@ericsson.com> Wed, 14 September 2011 17:19 UTC

Return-Path: <goran.ap.eriksson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4CC21F8B50 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 10:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8yH3lqyXkqI for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 10:19:56 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A206121F8783 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 10:19:55 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-3f-4e70e2bc7915
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 95.CD.20773.CB2E07E4; Wed, 14 Sep 2011 19:22:04 +0200 (CEST)
Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.112]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 14 Sep 2011 19:22:04 +0200
From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= <goran.ap.eriksson@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>, Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 14 Sep 2011 19:22:04 +0200
Thread-Topic: [rtcweb] STUN for keep-alive
Thread-Index: AcxzAtIrLPZKGABkTMGGxQs4774q6A==
Message-ID: <CA96AE8D.F43F%goran.ap.eriksson@ericsson.com>
In-Reply-To: <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
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==
Cc: IETF RTCWEB <rtcweb@ietf.org>
Subject: Re: [rtcweb] STUN for keep-alive
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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)?

Göran

On 2011-09-14 19:13, "Eric Rescorla" <ekr@rtfm.com> 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
>something.
>
>-Ekr
>
>On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand <harald@alvestrand.no>
>wrote:
>> 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
>>>keep
>>> 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
>>>reason
>>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb