[OpenSIPS-Users] Possible Bug / Unexpected behavior with ACC.

[Răzvan Crainea]

Hi, Jim!

That was exact scenario I tried, but did not find anything. Is there any 
chance I could get access to your testing environmen?
Or can we meet on IRC so we can run the debugging live?

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 09/01/2016 03:20 PM, Jim DeVito wrote:
> Hi Răzvan,
>
> It is a single leg of the call. And I am doing CDR accounting with the 
> flags below.
>
> if (is_method("INVITE")) {
>                 do_accounting("db", "cdr|failed|missed", "acc");
>
> ---
> Jim DeVito
>
> On 2016-09-01 01:43, Răzvan Crainea wrote:
>> Hi, Jim!
>>
>> I tried to reproduce this but did not succeed. Is there a single leg
>> for the call? Are you doing manual or cdr accounting?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutions
>> www.opensips-solutions.com
>>
>> On 08/31/2016 09:54 PM, Jim DeVito wrote:
>>> Hi All,
>>>
>>> Strange situation. I'm using the ACC module with Flatstore and it 
>>> was working fine until the update to 2.2.1 a couple days ago. It 
>>> seems the variable $rU is populated with hex for all 0's in very 
>>> specific situations. Namely receiving a 503 back from the carrier. 
>>> This is causing it to get put into the ACC Flat store file. See 
>>> below for the specifics and relevant configuration info. I do have a 
>>> dev system I can reproduce the problem on if there is some specific 
>>> debugging you suggest.
>>>
>>> ACC Flatstore file line (the 
>>> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 is the 
>>> bad part. It should be 011610408287261)
>>>
>>> INVITE|TM1AqTt8A57InEKZ75B293||20160831182524021875-339cad6d567da38f5d19c82b315b47ef|503|Service 
>>> Unavailable|1472667931|\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|115|sip-proxy02|from-c5-ns||||| 
>>> modparam("acc", "db_url","flatstore:/var/log/opensips/acc")
>>> modparam("acc", "db_extra", "to_tn=$rU; ....etc....)
>>>
>>> $rU is the extra parameter that is supposed to be 011610408287261 
>>> but it comes out as 
>>> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
>>>
>>> Thanks!!
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users