IETF Logo Mail Archive

Re: [rtcweb] Consent Freshness: Connection liveness/heartbeats

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 14 October 2014 10:29 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2F71A7023 for <rtcweb@ietfa.amsl.com>; Tue, 14 Oct 2014 03:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level:
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lelfpvslnnZM for <rtcweb@ietfa.amsl.com>; Tue, 14 Oct 2014 03:29:03 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212241A7008 for <rtcweb@ietf.org>; Tue, 14 Oct 2014 03:29:03 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id EC19D1AFC13E3; Tue, 14 Oct 2014 10:29:00 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9EASxOS016974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 06:29:01 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 06:29:00 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Thread-Topic: [rtcweb] Consent Freshness: Connection liveness/heartbeats
Thread-Index: Ac/khDonWu2om5LnTYiCouL4O3PwFQC9NuygAAx2CAAAAA3cgAAEujXQ
Date: Tue, 14 Oct 2014 10:28:59 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E5DE35A@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1D474980@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47B520@ESESSMB209.ericsson.se> <CAKz0y8zsKN0cJtR2_9b55rSvYs-RFRyn3mh=jOQpUceed7Goxw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D47B97B@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47B97B@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5DE35AUS70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MMnIccPfodCweZvlDJplPg9FuYU
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consent Freshness: Connection liveness/heartbeats
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 14 Oct 2014 10:29:05 -0000

1. Retain this simple functionality and fix the text, if we think this is useful/sufficient for applications.
2. Remove liveness entirely from the document, if we need a full-fledged liveness functionality. There are different ways of determining liveness depending on the use case (RTCP, DTLS heartbeat, TCP keepalive etc), so we could spin off a new doc and start with the problem/requirements.
<Raju>
Liveliness can and has to be detected at each level. For e.g. lack of RTCP could be caused of lack of STUN liveliness or crash of RTP/RTCP endpoint; it is crucial to know the exact cause for debugging purpose.
I am ok with either option, with a slight lean towards a separate draft, as long as liveliness at all levels are captured; either in one single combined draft or in respective drafts.
</Raju>

v2.23.0 | Report a Bug | By Email