Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Jiri Kuthan [mailto:[EMAIL PROTECTED] >> >> Actually TCP keep-alive is even simpler, even though, alas, just >> TCP-specific. >> There are some rumours though that some NATs drop TCP keep-alives, even >> though I have not witnessed that yet. > > Obviously I'm not a client guy, but I've been told not all clients have the > ability to set their sockets to do that, depending on the OS.
That's unfortunately true but I would not let myself distract by it in protocol design. There is however another issue -- the rumours are true that some NATs ignore TCP-keep-alives when refreshing their bindings. I made a bit of survey of a couple of home-routers and I found at least one that didn't honor it. This is IMO more concerning. So eventually CRLF^2 may be a better idea. > > >> I think that's a bit network-centric viewpoint. I'm comfortable with >> leaving the NAT-traversal responsibility on the client. (which kind of >> gets to the root of the problem, which is NATs are client-server >> centric). Then some things (such as server's decision how to keep the >> connections alive) don't have to concern us. > > Ironically I'm also trying to let the client do it - by having it tell the > proxy "I'm smart enough to keep this connection alive by myself, if you're > smart enough to use these mechanisms". :-) well made point, it just occurs to me that lack of CRLFs can be used as signaling "I'm dumb enough to resort to your help", which is in negation exactly the same thing. Or without negation, "as I show using CRLF ..." and then as you wrote. In the end really I would like to have clients doing CRLF type-of-thing and servers responding to it, without all of this. -jri > > -hadriel > _______________________________________________ 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
