On May 8, 2008, at 11:14 AM, Juha Heinanen wrote: > Francois Audet writes: > >> I think the point is that some proxies WANT to know. They want to use >> the keep-alive to keep tract of the availability of the UA without >> waiting for a request to fail. > > then we are talking about a different application than keeping tcp NAT > binding alive. was scope of christer's draft to define a general > purpose "is UA alive" detection protocol?
It's about keeping your NAT binding alive and KNOWING that it is alive, rather than just hoping. That requires bidirectional traffic. Ideally, it requires bidirectional traffic that changes with each operation and is not symmetric -- something different comes back than what was sent. Otherwise there are some weird "echo" failure scenarios where you think your NAT binding is alive but you're really just talking to yourself. And if this occurs in a CRLFCRLF->CRLF mode, then every "probe" sent by the UA doubles the "think it is alive" timer, and things get very strange. > > > i don't think that existing UA implementations that support CRLF send > them if they are not behind NAT. if proxy wants to know if UA is > still > alive or not, then we need to mandate CRLF keepalive for all UAs > whether > behind NAT or not. in my opinion this would be a quite fundamental > addition to sip UA behavior. Mostly it's about the UA knowing whether or not the proxy (or the connection to that proxy) is alive, and knowing it in a timely fashion so that it can re-establish the connection quickly if it fails. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
