[SR-Users] [sr-dev] Missing accounting events in ACC table
Daniel-Constantin Mierla
miconda at gmail.com
Sat Dec 27 22:22:36 CET 2014
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <http://1.0.0.127:5060>]: Call from 'you at kamailio.org
>> <mailto:you at kamailio.org>' to 'you at kamailio.org
>> <mailto: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
>> <mailto:sip%3A00xxxxxxxxxx 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
>> <http://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 list
>> sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#%21/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
> <mailto:sr-users at lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
>
--
Daniel-Constantin Mierla
http://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/20141227/2b9a3ba2/attachment.html>
More information about the sr-users
mailing list