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
>>>
>>>
>>
>
_______________________________________________
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
