[OpenSIPS-Users] 404 indirectly causing tm errors, then crash

[Jeff Pyle]

Hello,

For more than a year now on all three of my Opensips production proxies I've seen the following errors from time to time:

 WARNING:tm:w_t_reply: ACKs are not replied
 ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module

There were only a handful a day, and they didn't seem to hurt anything.  Until today.  This specific instance is on opensips-1.6 build 6702.  (This is the most recent I can run due to an obscure CentOS/Python/Mediaproxy ICE dependency problem.)

Today's fun started when a downstream ALG decided it was going to return 404s for all Opensips' invites to it instead of routing the call.  In my Opensips config I handle the 404 by re-t_relaying the call to another destination for alternate handling after resetting some variables.  It seems that somewhere in the failure_route that catches the 404 or in the subsequent request route this error message is triggered.

After a few hundred of these after maybe 10 or 15 minutes time, Opensips then crashes with the following:

 CRITICAL:core:sig_alarm_abort: BUG - shutdown timeout triggered, dying...

I'm not a programmer, but words like CRITICAL, BUG and DYING do catch my attention.

I wouldn't be surprised if whatever bug it may be referring to has long since been resolved in more current versions of 1.6 and 1.7.  I'm not as curious or concerned about that as I am about what my script is doing to cause the tm and signaling errors in the first place.  I do not have any explicit t_reply or send_reply functions in the failure_route or subsequent request_route.  Perhaps I'm catching this in a loose_route portion?  I do have this towards the beginning of the script:

                if !(loose_route()) {
                        ... do some stuff ....
                } else {
                        if (is_method("ACK")) {
                                if (t_check_trans()) {
                                        t_relay();
                                        exit;
                                } else {
                                        exit;
                                }
                }

I must admit I never have completely understood the use of t_check_trans, or the transactional/non-transaction status of ACKs and how to handle them.  I have relied greatly on the example configurations.

Any thoughts?


- Jeff