Re: [rtcweb] STUN for keep-alive
"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 14 September 2011 11:22 UTC
Return-Path: <mperumal@cisco.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 5E41321F8A97 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 04:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level:
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 PIvoDtkCqRwF for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 04:22:02 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AC17D21F8AF1 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 04:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3061; q=dns/txt; s=iport; t=1315999448; x=1317209048; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=XIs8Z7bB/qMFnzc6kMXFYCIrlBTHqeHs5qKatOf3cpE=; b=NAFNoR5Vm1+HIUm5w898wTQdBJFNt7ru663ZlMv7Dm53CTCzMjEURwFe DyUmkb5wOdaBi+5VmSgpyId0Dpp7YRbxBAS6Qqrc/Pqh6hw82ErnYf5IO y4silSQHGkpN/vRoGyb0unHtIRPq78+FM0fQJPW+nSNUty1YcAMwKjGRM Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcAABGOcE5Io8UR/2dsb2JhbABBmGuPD3iBUwEBBRIBHQpLBAIBCBEEAQELBhcBBgFFCQgBAQQBCggIGp9uAZ41hg5gBIdskHeMCQ
X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208";a="115383244"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2011 11:23:53 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8EBNrKc004538; Wed, 14 Sep 2011 11:23:53 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 16:53:53 +0530
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Sep 2011 16:53:52 +0530
Message-ID: <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] STUN for keep-alive
Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4A==
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, rtcweb@ietf.org
X-OriginalArrivalTime: 14 Sep 2011 11:23:53.0212 (UTC) FILETIME=[C8A803C0:01CC72D0]
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 11:22:04 -0000
|Well, it depends on the amount of outgoing media traffic, |but in cases where you only receive media you would still |need to send keep-alives. If you are not sending anything the NAT binding in that direction will likely timeout. On the other hand, if you are operating in a controlled environment ICE already allows you to set the STUN keepalive duration to the longest duration possible in your environment, so it is already flexible. However, it mandates STUN keepalives to be used when an agent is a full ICE implementation and is communicating with a peer that supports ICE (lite/full). Are you saying it should allow a different UDP keepalive method because it can possible have a lesser performance impact? Muthu |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Wednesday, September 14, 2011 3:59 PM |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org |Subject: RE: [rtcweb] STUN for keep-alive | | |Hi, | |>|Because, eventhough the keep-alives messages aren't authenticated, and |>|do not trigger responses, a gateway would still have to |>|process them, and since a gateway typically would serve a large number of browser |>|clients, that could have quite big performance impact (the number of |>|STUN keep-alives sent per session of course depend on how much other |>|media traffic there is, but still). |> |>STUN keepalives are required by ICE only in the absence of |>media traffic. | |Yes. That's what I meant with the: | | "(the number of STUN keep-alives sent per session of course depend on how much other media |traffic there is, but still)" | |...statement :) | |>Here are the snip from RFC 5245: |> |><snip> |>10. Keepalives |> |>If there has been no packet sent on the candidate pair ICE is |>using for a media component for Tr seconds (where packets |>include those defined for the component (RTP or RTCP) and |>previous keepalives), an agent MUST generate a keepalive on |>that pair. Tr SHOULD be configurable and SHOULD have a |>default of 15 seconds. Tr MUST NOT be configured to less |>than 15 seconds. |></snip> |> |><snip> |>20.2.3. Keepalives |> |>STUN keepalives (in the form of STUN Binding Indications) are |>sent in the middle of a media session. However, they are |>sent only in the absence of actual media traffic. In |>deployments that are not utilizing Voice Activity Detection |>(VAD), the keepalives are never used and there is no increase |>in bandwidth usage. When VAD is being used, keepalives will |>be sent during silence periods. This involves a single |>packet every 15-20 seconds, far less than the packet every |>20-30 ms that is sent when there is voice. Therefore, |>keepalives don't have any real impact on capacity planning. |></snip> |> |>Do you think there is still a problem? | |Well, it depends on the amount of outgoing media traffic, but in cases where you only receive media |you would still need to send keep-alives. | |Regards, | |Christer
- [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Jonathan Lennox
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] STUN for keep-alive sisalem
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Göran Eriksson AP
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- [rtcweb] consent freshness [was RE: STUN for keep… Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Eric Rescorla
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive Cullen Jennings
- Re: [rtcweb] STUN for keep-alive Michael Tüxen
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Harald Alvestrand
- Re: [rtcweb] consent freshness [was RE: STUN for … Stefan Håkansson LK
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo