[Kamailio-Users] reply_route is not called though a response is received

Hi, I am running a rather old version of openser, but since in a production context, I cannot upgrade anytime I want to catch up with newer releases. I searched bugs and googled for my problem without any result. There it is. I have a module with functions beginning with mn_ mn_received handle any incoming request and prints it out. my module has a callback on response which prints out responses. My configuration file is something like // handle register mn_received() ; record_route() ; if ( method=="INVITE") { t_on_failure(ROUTE_INVITE) ; t_on_reply(ROUTE_INVITE) ; } Then the request is t_relayed to destination. The onreply_route[ROUTE_INVITE] prints some output, and fix_contact on 200, ... whatever. Then this happens : - An INVITE is received from A (I see it with mn_received) - INVITE is relayed to destination B - B replies 180, I see the response on my module output and I see my onreply_route[INVITE] statements. - B replies 200, I see the response on my module output, but, I *do not* see my reply_route statements. - A sends ACK for INVITE - ACK is relayed to B 2 minutes later (fr_inv_timer), the failure_route[INVITE] is triggered ! Since I use failure routes to manage serial forking, this means openser forward the initial INVITE to the other destination, though first call was established ! Moreover, first call, which seems ok is CANCELED by the openser (I can see a 200 answer to a cancel from B) Openser did not disarm the fr_inv_timer on "200" answer to INVITE ? Openser did not triggered my onreply_route... Has someone already experienced this ? Has someone a clue where it may come from ? - Sometimes it works ok - Sometimes, 180 is not "seen" and 200 is ok - Sometimes 180 is seen but not 200 - Sometimes neither 180, nor 200 are seen - Headers in 180 and 200 are the same except for content - I'm running openser-1.2.0 (ouch !) I'm stuck ! Could this be related to 2008-05-15 10:59 Bogdan-Andrei Iancu, <bogdan at voice-system dot ro> * [r4191] modules/tm/t_reply.c: backport from trunk (rev #4190): - fixed race condition that may lead to deadlock on the transaction lock. As the reply route (t_on_reply()) stored in transaction may be changed in reply route br the current process or any other process, to avoid race conditions, it is better to make a local copy of the reply route number to be sure it will not be changed. The deadlock can appear as the reply route number is used in several conditions to determine id locking is required. But as this value may be changed (by current or other process), it may lead to multiple lockings with no unlock -> deadlock. NOTE: this might happen only if onreply_avp_mode is turned on. Aurelien