[Kamailio-Users] reply_route is not called though a response is received
gstelzz at yahoo.fr
Thu Dec 4 11:48:38 CET 2008
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
if ( method=="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
- 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.
More information about the Users