Subject: Re: [rtcweb] STUN for keep-alive
From: Cullen Jennings <[email-masked]>
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 22 Sep 2011 13:29:30 -0600
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>

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:

> 
> Hi,
> 
> 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).
> 
> 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).
> 
> 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).
> 
> 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).
> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb