Re: [rtcweb] STUN for keep-alive

On Sep 22, 2011, at 9:29 PM, Cullen Jennings wrote:

> 
> 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).
... if you run DTLS/UDP, DTLS provides a HB mechanism:
http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-02
Best regards
Michael
>> 
>> Regards,
>> 
>> Christer
>> 
>> _______________________________________________
>> 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
> 