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

4 Dec 2008

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