Hi Daniel, Thank you for this advice.. I'm still struggling to get it work, still no luck even with t_flush_flags() immediately after setflag(). Maybe I will try to reproduce it during the weekend with kamailio default config. FTR the version used is kamailio 3.3.1.
On 09/27/2012 05:17 PM, Daniel-Constantin Mierla wrote: > Hello, > > you can try after you set the flag you wanted to be in transaction, to > be sure it gets there. > > Cheers, > Daniel > > On 9/26/12 7:43 PM, Andrew Pogrebennyk wrote: >> 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@lists.sip-router.org >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
