Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt

[Jiri Kuthan <jiri at iptel.org>]

Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Jiri Kuthan [mailto:jiri at iptel.org]
>>
>> 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip