Daniel-Constantin Mierla writes:

http://sip-router.org/wiki/migration/kamailio-tips#tcp_connection_lifetime

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:

Hello,

On 12/7/09 6:23 PM, Juha Heinanen wrote:

...

ua sets up tcp connection to sr and registers. expires parameter of contact header is 3600 and tcp_persistent_flag was set before save() was called.

after registering, ua sends some other requests and becomes idle 8 second later. 2 minutes 10 seconds after that, wireshark shows that sr closes the tcp connection.

why is tcp connection closed? it looks like a bug to me, but perhaps i am missing something?

check this info: http://sip-router.org/wiki/migration/kamailio-tips#tcp_connection_lifetime

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@tutpro.com wrote:

Klaus Darilion writes:

...

Isn't it possible to implement tcp_persistent_flag on sr core? IMO it is a nice feature.

i agree, lets wait what andrei says about it. if not possible, i'll remove the flag from registrar module.

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