[SR-Users] [sr-dev] Missing accounting events in ACC table

Muhammad Shahzad shaheryarkh at gmail.com
Wed Dec 24 10:36:48 CET 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141224/90e3952b/attachment.html>


More information about the sr-users mailing list