[SR-Users] [sr-dev] Missing accounting events in ACC table
Muhammad Shahzad
shaheryarkh at gmail.com
Tue Dec 30 02:56:06 CET 2014
OK, i will run some tests and get back to you.
Thank you.
On Sat, Dec 27, 2014 at 10:22 PM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:
> I did a basic test (acc with parameters as in default kamailio.cfg) and
> invite is accounted ok. I used master branch, but there is no difference
> with acc from 4.2.
>
> Can you run with debug=3 and see all the log messages, maybe you get a
> further hint from there.
>
> Also, you can try with clone_msg parameter set to 0 - it is one of latest
> additions to acc module, just be sure you don't have some corner case
> situation...
>
> Cheers,
> Daniel
>
>
> On 24/12/14 15:23, Muhammad Shahzad wrote:
>
> After upgrade to version 4.2.1-a2aa22, result is same.
>
> Thank you.
>
>
>
> On Wed, Dec 24, 2014 at 1:32 PM, Muhammad Shahzad <shaheryarkh at gmail.com>
> wrote:
>
>> Looking at log level 3 logs, i see when INVITE has been authenticated
>> ACC module creates the dialog,
>>
>> --
>> DEBUG: acc [acc_cdr.c:726]: cdr_on_create(): dialog '0xa5936e70' created!
>> --
>>
>> But acc callback is only triggered AFTER 200 OK of BYE request,
>>
>> --
>> DEBUG: acc [acc_logic.c:644]: tmcb_func(): acc callback called for
>> t(0xa591d840) event type 2, reply
>> code 200
>> --
>>
>> Between these two log lines there is no log from acc module.
>>
>> Thank you.
>>
>>
>>
>> On Wed, Dec 24, 2014 at 11:04 AM, Muhammad Shahzad <shaheryarkh at gmail.com
>> > wrote:
>>
>>> See attached SIP trace.
>>>
>>> Note, i have obfuscated source and destination number and IPs etc. due
>>> to privacy reasons.
>>>
>>> Thank you.
>>>
>>>
>>>
>>> On Wed, Dec 24, 2014 at 10:36 AM, Muhammad Shahzad <
>>> shaheryarkh at gmail.com> wrote:
>>>
>>>> OK, i will upgrade my staging server and do some testing.
>>>>
>>>> The acc module does not post records anywhere, neither syslog nor db.
>>>> The problem is happening to all calls (not any specific call).
>>>>
>>>> Regarding the FROM header, the only change done is to add "+" to
>>>> callerid (after replacing 00 if present), this is extensively tested
>>>> feature in past 6 months.
>>>>
>>>> I have analyzed all the SIP packets in call using ngrep, they all seem
>>>> perfectly fine. All packets (request + reply) are correctly received and
>>>> forwarded by kamailio. Unfortunately i deleted them and need to get new
>>>> trace. I will send it to you in the afternoon.
>>>>
>>>> Thank you.
>>>>
>>>>
>>>>
>>>> On Tue, Dec 23, 2014 at 10:10 PM, Daniel-Constantin Mierla <
>>>> miconda at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> you can try with latest git branch 4.2 and see the results.
>>>>>
>>>>> At a quick look between the version you reported to work and the new
>>>>> version you run, I couldn't spot a commit that could be the reason.
>>>>>
>>>>> Do you get the acc record in syslog for INVITE?
>>>>>
>>>>> How do you set the values for replacing From header? If you load from
>>>>> database, be sure the values are valid. I see the uac module complains
>>>>> about restoring operation. It might be the reason for the issues -- config
>>>>> could be ok, but the subscriber data wrong.
>>>>>
>>>>> You should save the traffic for a while and check the packets for
>>>>> missing records -- you can use tools such as tcpdump, sipgrep, ngrep to
>>>>> store the traffic in a file for later analysis. When you find a missing
>>>>> record, search in the file with the sip traffic and see if something is
>>>>> broken there.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 23/12/14 21:45, Muhammad Shahzad wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> About 3 weeks ago i upgraded one of my production server with latest
>>>>> stable kamailio version 4.2.1-fad00a. Now i am getting a lot of complaints
>>>>> about missing CDR events in ACC table. I observe following problems,
>>>>>
>>>>> 1. There are only BYE records in acc table, no record for INVITE or
>>>>> ACK.
>>>>> 2. In kamailio logs when ACK is received against 200 OK response for
>>>>> INVITE, i see following errors,
>>>>>
>>>>> --
>>>>> ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to
>>>>> parse From uri
>>>>> ERROR: pv [pv_core.c:434]: pv_get_xto_attr(): cannot parse From URI
>>>>> NOTICE: <script>: [udp:<null>@1.0.0.127:5060]: Call from '
>>>>> you at kamailio.org' to 'you at kamailio.org' has been hanged up by
>>>>> '<null>' at '1419364717.255484'
>>>>> --
>>>>>
>>>>> Of course all these errors are bogus, I have checked all headers in
>>>>> ACK (not just FROM header), they all seem perfectly fine and valid.
>>>>>
>>>>> 3. Then the dialog times out,
>>>>>
>>>>> --
>>>>> WARNING: dialog [dlg_handlers.c:1440]: dlg_ontimeout(): timeout for
>>>>> dlg with CallID '6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9' and tags
>>>>> '1D3ECD34F5731AB845BA3064AC95BB2D'
>>>>> '7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4'
>>>>> --
>>>>>
>>>>> 4. Any further sequential requests complain about "unable to find
>>>>> dialog", e.g.
>>>>>
>>>>> --
>>>>> NOTICE: <script>: Sequencial 'BYE' request received from caller
>>>>> ERROR: uac [replace.c:591]: restore_uri(): new URI [] shorter than old
>>>>> URI [sip:00xxxxxxxxxx at sip.domain.com]
>>>>> WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find
>>>>> dialog for BYE with route param '5ae1.d595' [7845:22877]
>>>>> --
>>>>>
>>>>> 5. However the acc record for BYE is written to db and log file,
>>>>>
>>>>> --
>>>>> NOTICE: acc [acc.c:318]: acc_log_request(): ACC: transaction answered:
>>>>> timestamp=1419364760;method=BYE;from_tag=7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4;to_tag=1D3ECD34F5731AB845BA3064AC95BB2D;call_id=6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9;code=200;reason=OK;src_user=00xxxxxxxxxx;src_domain=
>>>>> sip.domain.com
>>>>> ;src_ip=xx.xx.xx.xx;dst_ouser=+1xxxxxxxxxx;dst_user=1xxxxxxxxxx;dst_domain=yy.yy.yy.yy
>>>>> --
>>>>>
>>>>>
>>>>> The same config was working fine with older version 4.2.0-97cab8.
>>>>> The kamailio config i am using is pretty much standard,
>>>>>
>>>>> --
>>>>> #!define FLT_ACC 1
>>>>> #!define FLT_ACCMISSED 2
>>>>> #!define FLT_ACCFAILED 3
>>>>> #!define FLT_DLG 4
>>>>>
>>>>> ...
>>>>>
>>>>> modparam("acc", "early_media", 1)
>>>>> modparam("acc", "report_ack", 1)
>>>>> modparam("acc", "report_cancels", 1)
>>>>> modparam("acc", "detect_direction", 1)
>>>>> modparam("acc", "log_flag", FLT_ACC)
>>>>> modparam("acc", "log_missed_flag", FLT_ACCMISSED)
>>>>> modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
>>>>> # log to db
>>>>> modparam("acc", "db_flag", FLT_ACC)
>>>>> modparam("acc", "db_missed_flag", FLT_ACCMISSED)
>>>>> modparam("acc", "db_url", "DBURL")
>>>>>
>>>>> ...
>>>>>
>>>>> request_route {
>>>>> # per request initial checks
>>>>> route(REQINIT);
>>>>>
>>>>> # NAT detection
>>>>> route(NATDETECT);
>>>>>
>>>>> # handle requests within SIP dialogs
>>>>> route(WITHINDLG);
>>>>>
>>>>> # CANCEL processing
>>>>> if (is_method("CANCEL")) {
>>>>> if (t_check_trans()) {
>>>>> t_relay();
>>>>> };
>>>>> exit;
>>>>> };
>>>>>
>>>>> #### only initial requests (no To tag) ####
>>>>> t_check_trans();
>>>>>
>>>>> ....
>>>>>
>>>>> # account only INVITEs
>>>>> if (is_method("INVITE")) {
>>>>> setflag(FLT_DLG); # create dialog
>>>>> setflag(FLT_ACC); # do accounting
>>>>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>>>>>
>>>>> $avp(dlg_timeout) = 60;
>>>>> dlg_manage();
>>>>> ....
>>>>>
>>>>> }
>>>>>
>>>>> --
>>>>>
>>>>> Any ideas why its happening? Since it is 3 weeks old so may be
>>>>> problem has already been spotted and fixed by someone else. Otherwise let
>>>>> me know how can i provide more info to help fix this issue.
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sr-dev mailing listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>>
>>>>>
>>>>> --
>>>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141230/c116d4e9/attachment.html>
More information about the sr-users
mailing list