Daniel-Constantin Mierla writes: daniel, thanks for the pointer. in order to clarify this, would be appropriate to remove tcp_persistent_flag parameter from registrar module, because it does not have any effect in sr? also, when the param is removed, k users would clearly notice that a config change is necessary. now the change can go too easily unnoticed especially when registrar module README does not say anything about this (yes, i did read register README before posting to the list). -- juha

Daniel-Constantin Mierla schrieb: Isn't it possible to implement tcp_persistent_flag on sr core? IMO it is a nice feature. regards klaus

On Dec 08, 2009 at 07:33, Juha Heinanen <jh(a)tutpro.com> wrote: It is possible, but do we really need it? (in theory is useful, but I'm not sure about the practice :-)). The side effect is that it would use more bytes per tcp connection (4 or 8) and that global runtime timeout changes (e.g. sercmd cfg.set_now_int tcp connection_lifetime 120 ) will not affect anymore existing connection, only new ones. I think the change would be quite trivial, but still I would need some volunteer testers and it's also pretty late for sr3.0. Note also that after a quick look I don't believe it ever worked correctly in k. I might be wrong but to me it looks like in k it has the following problems: - timeout is changed only once, when the REGISTER is received. After that the first receive on the same connection (be it another sip message or a simple CRLF ping) or the first send on the connection will _reset_ the timeout back to tcp_con_lifetime. So it works only if the connection is completely idle after the first REGISTER. - timeout is changed after tcp reader exits => error of at least 2s and with extra 10s added by registrar (less important). Andrei