Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se>
Date: Thu, 22 Sep 2011 13:29:30 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F7F4274-1AF6-4162-A177-51E1CDD0BCCD@cisco.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] STUN for keep-alive
Precedence: list

In the past, we had too many ways of doing keep alive and it resulted in =
poor interoperability when two sides choose different ways - I'd rather =
avoid that sort of problem

On Sep 14, 2011, at 3:48 AM, Christer Holmberg wrote:

>=20
> Hi,
>=20
> Assuming we would use ICE for media authorization, it has been =
indicated that, for legacy interoperability, a gateway would be required =
in many cases (as the legacy entities might not support ICE).
>=20
> ICE "bundles" functions together, meaning that if you use STUN for =
media authorization purpose (which is a part of the connectivity check =
purpose), you will also use STUN for keep-alive purpose (for UDP based =
media).
>=20
> My question is: would we be able to relax the requirement to use STUN =
for keep-alive? 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).
>=20
> So, for RTP based media, one could use RTP, and for UDP based data =
channels "dummy" UDP packets (unless there is a protocol on top of UDP =
which provides a keep-alive mechanism itself).
>=20
> Regards,
>=20
> Christer
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb