[SR-Users] Testing dialog module (and acc with dialog cdrs)
Daniel-Constantin Mierla
miconda at gmail.com
Fri Oct 14 11:21:04 CEST 2022
Based on your parameters, it seems that acc should send cdrs also to
syslog. I think I identified an issue on that code and pushed a fix, can
you test with latest master git branch?
Cheers,
Daniel
On 14.10.22 10:25, Daniel-Constantin Mierla wrote:
>
> OK. Can you run the tests for a while and then execute:
>
> kamctl rpc corex.pkg_summary idx 1
>
> The value for idx should be the kamailio process expected to handle
> sip traffic. If it is mostly udp and the first socket is the
> corresponding udp socket, then the value 1, like above, is ok. If it
> is tcp/tls or you have different listen parameters on udp, see the
> processes index with:
>
> kamctl ps
>
> It should not be required to wait till you get out of memory errors,
> but be sure you run it long enough to have many accounting records
> written by the process that is going to print the pkg summary. You can
> eventually set the children to 1 or 2, to "force" traffic via a
> smaller group of processes.
>
> Cheers,
> Daniel
>
> On 14.10.22 10:12, mayamatakeshi wrote:
>> Hi,
>> I am using acc for CDR generation. Here is the module configuration
>> I'm using:
>>
>> modparam("acc", "db_url",
>> "mysql://kamailio:kamailiorw@localhost/kamailio")
>> modparam("acc", "db_flag", 1)
>> modparam("acc", "db_missed_flag", 2)
>> modparam("acc", "failed_transaction_flag", 3)
>> modparam("acc", "cdr_enable", 1)
>> modparam("acc", "cdrs_table", "cdr")
>> modparam("acc", "cdr_extra",
>> "callid=$ci;caller_domain=$dlg_var(caller_domain);callee_domain=$dlg_var(callee_domain);caller_username=$dlg_var(caller_username);callee_username=$dlg_var(callee_username);calling_number=$dlg_var(calling_number);destination=$dlg_var(destination);anonymous=$dlg_var(anonymous);forwarding=$dlg_var(forwarding);tracing=$dlg_var(tracing);relay=$dlg_var(relay);sip_code=$dlg_var(sip_code);status_code=$dlg_var(status_code);start_time=$dlg_var(start_time)")
>> modparam("acc", "cdr_start_on_confirmed", 1)
>> modparam("acc", "cdr_start_id", "answer_time")
>> modparam("acc", "log_level", 9)
>> modparam("acc", "log_facility", "LOG_LOCAL0")
>> modparam("acc", "log_flag", 10)
>> modparam("acc", "cdr_facility", "LOG_LOCAL0")
>> modparam("acc", "cdr_log_enable", 1)
>>
>>
>> On Fri, Oct 14, 2022 at 3:57 PM Daniel-Constantin Mierla
>> <miconda at gmail.com> wrote:
>>
>> Hello,
>>
>> are you using accounting to generate CDRs with dialog module
>> (records in acc_cdrs table)? Or only for getting the event
>> records in the acc table?
>>
>> Cheers,
>> Daniel
>>
>> On 13.10.22 23:19, mayamatakeshi wrote:
>>>
>>>
>>> On Mon, Oct 3, 2022 at 11:41 AM mayamatakeshi
>>> <mayamatakeshi at gmail.com> wrote:
>>>
>>>
>>>
>>> On Mon, Sep 26, 2022 at 8:32 PM Daniel-Constantin Mierla
>>> <miconda at gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> as I am not a user of dialog variables, I am turning to
>>> community to ask
>>> for help testing the current master branch with
>>> configurations that make
>>> use of dialog variables and acc dialog-based cdr generation.
>>>
>>> With a few reports of issues related to dialog modules
>>> and unexpected
>>> crashes, I looked over the code and noticed that the
>>> access of the value
>>> for dialog variables was not protected, making them
>>> vulnerable of
>>> invalid memory access in case of the variable was
>>> updated by another
>>> process or dialog was terminated.
>>>
>>> I introduced a couple of new functions to try to cover
>>> different use
>>> cases of getting the dlg variable values, dialog
>>> management code was not
>>> affected, but given that these commits need to be
>>> backported to stable
>>> branch (5.6), I want to get proper feedback from
>>> community that things
>>> work fine.
>>>
>>> A previous attempt of a simpler fix was not enough,
>>> having side effects
>>> to acc module for dialog-based cdr generation, because
>>> it was keeping
>>> referenced to many dlg variables at the same time.
>>>
>>> In short, it would be appreciated any feedback on
>>> testing dialog and acc
>>> with dialog-based cdr generation using git master branch.
>>>
>>>
>>> I have started 4 load test environments today with latest
>>> commit 6f400a8074fe60916867596431ca26dff00435d1.
>>> I usually leave a commit load test running for 2 months
>>> before consider it ready for production release.
>>> I will report any crash/problem.
>>>
>>>
>>> After a few hours of load test, all 4 load test environments
>>> start to log memory allocation problems:
>>>
>>> [root at lab002107-flip-server ~]$ grep memory
>>> /var/log/kamailio/kamailio.log |head
>>> 2022-10-13T01:36:10.429809+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> rtpengine [rtpengine.c:2721]: rtpp_function_call(): out of
>>> memory - bencode failed
>>> 2022-10-13T01:36:12.923609+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> rtpengine [rtpengine.c:2721]: rtpp_function_call(): out of
>>> memory - bencode failed
>>> 2022-10-13T01:36:12.961677+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> acc [acc_extra.c:234]: extra2strar(): could not allocate private
>>> memory from pkg pool
>>> 2022-10-13T01:36:14.983281+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> rtpengine [rtpengine.c:2721]: rtpp_function_call(): out of
>>> memory - bencode failed
>>> 2022-10-13T01:36:14.983537+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> acc [acc_extra.c:234]: extra2strar(): could not allocate private
>>> memory from pkg pool
>>> 2022-10-13T01:36:14.983665+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> acc [acc_extra.c:234]: extra2strar(): could not allocate private
>>> memory from pkg pool
>>> 2022-10-13T01:36:20.861558+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> rtpengine [rtpengine.c:2721]: rtpp_function_call(): out of
>>> memory - bencode failed
>>> 2022-10-13T01:36:20.864388+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> acc [acc_extra.c:234]: extra2strar(): could not allocate private
>>> memory from pkg pool
>>> 2022-10-13T01:36:20.878469+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> acc [acc_extra.c:234]: extra2strar(): could not allocate private
>>> memory from pkg pool
>>> 2022-10-13T01:36:23.174159+09:00 lab002107-flip-server
>>> /usr/local/src/git/kamailio-master/src/kamailio[3286370]: ERROR:
>>> rtpengine [rtpengine.c:2721]: rtpp_function_call(): out of
>>> memory - bencode failed
>>>
>>>
>>> I reverted 2 of the load test envs to previous kamailio 5.6
>>> commit 61e86a1f502388ffd4dce6e52811ba640337c813 and restarted
>>> the load tests, then again, kamailio master commit
>>> 6f400a8074fe60916867596431ca26dff00435d1 started to write the
>>> above logs but this doesn't happen with 5.6.
>>>
>>>
>>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>> Kamailio Advanced Training - Online
>> Nov 7-10, 2022 (Europe Timezone)
>> * https://www.asipto.com/sw/kamailio-advanced-training-online/
>>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
> Nov 7-10, 2022 (Europe Timezone)
> * https://www.asipto.com/sw/kamailio-advanced-training-online/
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
Nov 7-10, 2022 (Europe Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20221014/188f1ab4/attachment.htm>
More information about the sr-users
mailing list