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 > <shaherya...@gmail.com <mailto:shaherya...@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 > <shaherya...@gmail.com <mailto:shaherya...@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 > <shaherya...@gmail.com <mailto:shaherya...@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 > <mico...@gmail.com <mailto:mico...@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 'y...@kamailio.org >> <mailto:y...@kamailio.org>' to 'y...@kamailio.org >> <mailto:y...@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:00xxxxxxx...@sip.domain.com >> <mailto:sip%3a00xxxxxxx...@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-...@lists.sip-router.org >> <mailto:sr-...@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@lists.sip-router.org > <mailto:sr-users@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
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
