Hi, I have found recently that in order to detect retransmits I have to create a transaction explicitly when the request comes in: force_rport(); if(!t_check_trans()) t_newtran(); sl_send_reply("100", "Trying"); xlog("L_INFO", "New request - $ci\n"); it appears like there are carriers or UAs that do not honor the T1 retransmission interval retransmit the INVITE sooner than proxy creates a transaction in t_relay(). And since we are counting concurrent calls, we count the same call multiple times, which is not good. But with this patch we've faced another sporadic problem - if the transaction is created beforehand the accounting record is lost.. we use acc_db mode and set flag to account the transaction. And there are no errors in kamailio log but no insert into acc in mysql binlog either. I wasn't successful reproducing it in the lab systems with identical setup. Is anybody here perhaps aware of some limitation in acc module or callbacks which makes a transaction created beforehand not accountable? On a related note, it could make sense to create a transaction implicitly if dlg_manage() is called to avoid counting same call many times, I just don't know yet how common this issue is in real life. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Daniel, No, I don't. Thanks for the tip. Could you advice where t_flush_flags() should be placed? I tried in branch_route and immediately before t_relay(), it didn't help.. On 09/26/2012 05:53 PM, Daniel-Constantin Mierla wrote: > Hello, > > do you use t_flush_flags()? > > http://kamailio.org/docs/modules/3.3.x/modules_k/tmx.html#id2543767 > > Cheers, > Daniel > > On 9/26/12 3:30 PM, Andrew Pogrebennyk wrote: >> Hi, >> >> I have found recently that in order to detect retransmits I have to >> create a transaction explicitly when the request comes in: >> force_rport(); >> if(!t_check_trans()) >> t_newtran(); >> sl_send_reply("100", "Trying"); >> xlog("L_INFO", "New request - $ci\n"); >> >> it appears like there are carriers or UAs that do not honor the T1 >> retransmission interval retransmit the INVITE sooner than proxy creates >> a transaction in t_relay(). And since we are counting concurrent calls, >> we count the same call multiple times, which is not good. >> >> But with this patch we've faced another sporadic problem - if the >> transaction is created beforehand the accounting record is lost.. we >> use >> acc_db mode and set flag to account the transaction. And there are no >> errors in kamailio log but no insert into acc in mysql binlog either. I >> wasn't successful reproducing it in the lab systems with identical >> setup. >> >> Is anybody here perhaps aware of some limitation in acc module or >> callbacks which makes a transaction created beforehand not accountable? >> >> On a related note, it could make sense to create a transaction >> implicitly if dlg_manage() is called to avoid counting same call many >> times, I just don't know yet how common this issue is in real life. >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users