On Sunday, February 22, 2015 12:16:33 PM Daniel-Constantin Mierla wrote:

Hello,

On 22/02/15 01:09, Anthony Messina wrote:

...

On Saturday, February 21, 2015 12:47:08 PM Anthony Messina wrote:

...

Good day. Is anyone able to let me in on what this means "WARNING:

<core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I just started seeing this after pulling down 5c1a9df from git and it seems like something that I probably don't want happening.

It appears that the tcpops.so module must be loaded to prevent these timer errors, even if not using any of the functions provided by the module. Is this the future intention?

You are running master branch (devel version), right?

Yes.

The tcpops module is new and probably this issue is due to its latest addition to allow custom lifetime value per tcp connection. It has to be fixed to work without a need to load tcpops module, perhaps Camile will look at it next week.

Cheers, Daniel

Thanks Daniel and Camille, that's what I was thinking. I can report that tcp_set_connection_lifetime is working nicely. -A

On Friday, February 27, 2015 07:08:05 AM Anthony Messina wrote:

On Friday, February 27, 2015 11:53:22 Camille Oudot wrote:

...

Le Sat, 21 Feb 2015 12:47:08 -0600,

Anthony Messina amessina@messinet.com a écrit :

...

Good day. Is anyone able to let me in on what this means "WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I just started seeing this after pulling down 5c1a9df from git and it seems like something that I probably don't want happening.

Hi Anthony,

Are you using TLS? I've just sent a patch to master that will fix an issue I introduced with the per-socket lifetime on TLS connections. Can you try it?

-- Camille

Thanks Camille. I am using TLS, but I've had some long days at work. I'll rebuild and give it a shot this weekend. -A

I no longer see this issue. Thank you. I've added a check in onreply_route for $avp(caller_conid)!=$null since it appears the AVP isn't always available for some reason. -A

#!ifdef WITH_TCPOPS if(proto!=UDP && status=="200") { if(is_method("INVITE")) { # enable on callee's connection tcp_keepalive_enable("60", "5", "5"); # enable on caller's connection if($avp(caller_conid)!=$null) tcp_keepalive_enable("$avp(caller_conid)", "60", "5", "2"); } if(is_method("BYE")) { tcp_keepalive_disable(); tcp_keepalive_disable("$avp(bye_conid)"); } } #!endif }

On Monday, March 02, 2015 08:41:27 Daniel-Constantin Mierla wrote:

On 01/03/15 22:54, Anthony Messina wrote:

...

On Friday, February 27, 2015 07:08:05 AM Anthony Messina wrote:

...

On Friday, February 27, 2015 11:53:22 Camille Oudot wrote:

...

Le Sat, 21 Feb 2015 12:47:08 -0600,

Anthony Messina amessina@messinet.com a écrit :

...

Good day. Is anyone able to let me in on what this means "WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I just started seeing this after pulling down 5c1a9df from git and it seems like something that I probably don't want happening.

Hi Anthony,

Are you using TLS? I've just sent a patch to master that will fix an issue I introduced with the per-socket lifetime on TLS connections. Can you try it?

Thanks Camille. I am using TLS, but I've had some long days at work. I'll rebuild and give it a shot this weekend. -A

I no longer see this issue. Thank you. I've added a check in onreply_route for $avp(caller_conid)!=$null since it appears the AVP isn't always available for some reason. -A

#!ifdef WITH_TCPOPS

    if(proto!=UDP && status=="200") {

            if(is_method("INVITE")) {

                    # enable on callee's connection
                    tcp_keepalive_enable("60", "5", "5");
                    # enable on caller's connection
                    if($avp(caller_conid)!=$null)

                            tcp_keepalive_enable("$avp(caller_conid)",

"60", "5", "2");

            }
            if(is_method("BYE")) {

                    tcp_keepalive_disable();
                    tcp_keepalive_disable("$avp(bye_conid)");

            }

    }

#!endif }

AVPs are available only the transaction transaction. It is in onreply_route[abc], not in reply_route. Also, what you set for INVITE transaction is not in the other requests of other transactions in the same call (such as BYE) -- use dialog vars for that.

Cheers, Daniel

Thanks Daniel. The TCP Ops module README will probably need some updates then. My example above is sourced from there.

On Monday, March 02, 2015 08:41:27 AM Daniel-Constantin Mierla wrote:

On 01/03/15 22:54, Anthony Messina wrote:

...

On Friday, February 27, 2015 07:08:05 AM Anthony Messina wrote:

...

On Friday, February 27, 2015 11:53:22 Camille Oudot wrote:

...

Le Sat, 21 Feb 2015 12:47:08 -0600,

Anthony Messina amessina@messinet.com a écrit :

...

Good day. Is anyone able to let me in on what this means "WARNING: <core> [local_timer.c:83]: _local_timer_dist_tl(): 0 expire timer added"? I just started seeing this after pulling down 5c1a9df from git and it seems like something that I probably don't want happening.

Hi Anthony,

Are you using TLS? I've just sent a patch to master that will fix an issue I introduced with the per-socket lifetime on TLS connections. Can you try it?

-- Camille

Thanks Camille. I am using TLS, but I've had some long days at work. I'll rebuild and give it a shot this weekend. -A

I no longer see this issue. Thank you. I've added a check in onreply_route for $avp(caller_conid)!=$null since it appears the AVP isn't always available for some reason. -A

#!ifdef WITH_TCPOPS

    if(proto!=UDP && status=="200") {
            if(is_method("INVITE")) {
                    # enable on callee's connection
                    tcp_keepalive_enable("60", "5", "5");
                    # enable on caller's connection
                    if($avp(caller_conid)!=$null)
                            tcp_keepalive_enable("$avp(caller_conid)",

...

"60", "5", "2");

            }
            if(is_method("BYE")) {
                    tcp_keepalive_disable();
                    tcp_keepalive_disable("$avp(bye_conid)");
            }
    }

#!endif }

AVPs are available only the transaction transaction. It is in onreply_route[abc], not in reply_route. Also, what you set for INVITE transaction is not in the other requests of other transactions in the same call (such as BYE) -- use dialog vars for that.

Cheers, Daniel

Thanks Daniel. I do have the above in my onreply_route[MANAGE_REPLY], and have set t_on_reply("MANAGE_REPLY"). Are you saying that $avp(caller_conid) when set on the initial INVITE, for example, wouldn't be available in the onreply_route to the INVITE? If so, the examples in the TCP Ops README will need to reflect the need for using dialog vars instead.

By the way, I'm only using if(proto!=UDP) since the TCP Ops module checks whether or not it can apply itself, but also logs each time it does so. Is it more efficient for the script to introduce the check for the proto (avoiding the clutter in the logs), or more efficient for the module to just return when it isn't applicable?

request_route {

...

#!ifdef WITH_TCPOPS if(proto!=UDP) { if(is_method("INVITE")) $avp(caller_conid)=$conid;

if(is_method("BYE")) $avp(bye_conid)=$conid; } #!endif

...

}

# Manage incoming replies onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=~"[12][0-9][0-9]") route(NATMANAGE);

#!ifdef WITH_TCPOPS if(proto!=UDP && status=="200") { if(is_method("INVITE")) { # enable on callee's connection tcp_keepalive_enable("60", "5", "5"); # enable on caller's connection if($avp(caller_conid)!=$null) tcp_keepalive_enable("$avp(caller_conid)", "60", "5", "2"); } if(is_method("BYE")) { tcp_keepalive_disable(); tcp_keepalive_disable("$avp(bye_conid)"); } } #!endif }

On Thursday, March 05, 2015 12:34:36 PM Camille Oudot wrote:

...

Are you saying that $avp(caller_conid) when set on the initial INVITE, for example, wouldn't be available in the onreply_route to the INVITE? If so, the examples in the TCP Ops README will need to reflect the need for using dialog vars instead.

Hi Anthony,

the AVP you set on a request will be available in the onreply_routes that have been registered with t_on_reply().

The example in the tcpops readme uses some AVPs, but you might of course need different ways of memorizing connection information that fits your specific needs (stateless, dialog-aware, use a database, a hashatable, ...).

Thanks, Camille, then I should be all set as I am calling onreply_route[MANAGE_REPLY].

...

By the way, I'm only using if(proto!=UDP) since the TCP Ops module checks whether or not it can apply itself, but also logs each time it does so. Is it more efficient for the script to introduce the check for the proto (avoiding the clutter in the logs), or more efficient for the module to just return when it isn't applicable?

The messages complaining about the connection not being a TCP connection use the ERROR log level, because I felt like calling these TCP tuning functions on something else than TCP should not remain unnoticed and should be fixed at script level. I would recommend that you keep this logic in your script, and in your case, "if(proto!=UDP)" is efficient (probably more than writing a log line).

Again, thank you. BTW, I'm looking forward to modparam("usrloc", "close_expired_tcp", 1) when I rebuild later...