[sr-dev] [SR-Users] DB accounting missing if t_newtran() is called explicitly

[Andrew Pogrebennyk]

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 at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>