Finally i have found the problem and fixed it. I was creating new
transaction for initial invite request too early (immediately after
authentication and checking for re-transmits of initial requests), e.g.
...
# request with no Username in RURI
if ($rU==$null) {
sl_send_reply("484","Address Incomplete");
exit;
} else {
t_newtran();
...
The interesting thing is that it was causing problem only for accounting
events and everything else was working perfectly fine. A single line of
code that wasted my full 2 weeks. :-(
Thank you for your help and support.
On Tue, Jan 6, 2015 at 7:00 AM, Muhammad Shahzad <shaherya...@gmail.com>
wrote:
> OK, finally back at office after holidays.
>
> I have done extensive testing of various kamailio revisions (backwards up
> to November) and it seems that problem is not related to any change in
> native code. It is somehow related to kamailio.cfg, which is very strange,
> since only changes in previous deployment and currently deployment of cfg
> file are related to dialog module (there are a lot of them, e.g. dialog
> timeout added, dialog profile setup, several dialog variables added and
> set, dialog start, end and failure event routes configured etc. etc.).
> However, there is no change related to acc setup and its configuration is
> still compatible with default kamailio.cfg. Does this make any sense to you?
>
> Looking at debug level 3 kamailio logs and mysql query logs, there is no
> attempt to insert data in acc table at all except for BYE message.
>
> Today i will try to compare working cfg file (back from mid-November,
> which inserts all ACC event records) with current cfg file (which only
> inserts BYE event records) and see if i can find that configuration changes
> that are causing this behavior.
>
> Thank you.
>
>
>
> On Tue, Dec 30, 2014 at 2:56 AM, Muhammad Shahzad <shaherya...@gmail.com>
> wrote:
>
>> 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 <
>> mico...@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 <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> 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> 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> 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 '
>>>>>>> y...@kamailio.org' to '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]
>>>>>>> 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-...@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@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
>>>
>>>
>>
>
_______________________________________________
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
