|
Hello, I viewed the tm module source code and found the following code (openser version 0.9.5): file: t_reply.c function: reply_received (starting line 1204) /* make sure we know the associated transaction ... */ if (t_check(p_msg, &branch ) == -1) return 1; ... /* processing of on_reply block */ if (t->on_reply) { rmode = MODE_ONREPLY; /* transfer transaction flag to message context */ if (t->uas.request) p_msg->flags = t->uas.request->flags; /* set the as avp_list the one from transaction */ backup_list = set_avp_list(&t->user_avps); if (run_actions(onreply_rlist[t->on_reply], p_msg)<0) { LOG(L_ERR, "ERROR: on_reply processing failed\n"); } /* transfer current message context back to t */ if (t->uas.request) t->uas.request->flags=p_msg->flags; /* restore original avp list */ set_avp_list( backup_list ); } LOCK_REPLIES( t ); So I came to the following conclusions: - Before runing the onreply actions, the transaction avp list is set. - the t_check statement ensures we get the transaction - is the mutex set by LOCK_REPLIES( t ); ? So please let me know if these assumptions are right. And if LOCK_REPLIES( t ); sets the mutex, why not put it before processing the reply block? Thanks in advance! regards, Jonas On 06/06/06 22:12, Daniel-Constantin Mierla wrote: > Hello, > > On 06/06/06 17:51, Jonas Appel wrote: > > Hi all, > > > > I hava a question: Is there a reason why the avpops functions are not > > usable in reply routes? > > yes, it is a reason - reply routes are not executed under lock (mutex), > so the transaction's AVPs cannot be accessed safe. It is on the todo > list to find a solution for it, also, the default reply route does not > use tansaction AVPs, so there should not be any problem. If you know > what are you doing, you can change the source of avpops and allow usage > in onreply_route -- just be careful where you use them. > > > Cheers, > Daniel > > > Thanks in advance! > > > > regards, |
_______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
