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@kamailio.org' to 'you@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@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.
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,
- There are only BYE records in acc table, no record for INVITE or ACK.
- 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@kamailio.org mailto:you@kamailio.org' to 'you@kamailio.org mailto:you@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.
- 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' --
- 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@sip.domain.com mailto:sip%3A00xxxxxxxxxx@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] --
- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@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,
- There are only BYE records in acc table, no record for INVITE or ACK.
- 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@kamailio.org' to 'you@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.
- 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' --
- 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@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] --
- 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@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
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@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@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,
- There are only BYE records in acc table, no record for INVITE or ACK.
- 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@kamailio.org' to 'you@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.
- 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' --
- 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@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] --
- 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@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
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@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@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@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,
- 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@kamailio.org' to 'you@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.
- 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' --
- 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@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] --
- 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@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
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@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@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@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@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,
- 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@kamailio.org' to 'you@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.
- 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' --
- 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@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] --
- 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@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
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@gmail.com mailto:shaheryarkh@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@gmail.com <mailto:shaheryarkh@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@gmail.com <mailto:shaheryarkh@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@gmail.com <mailto:miconda@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@kamailio.org <mailto:you@kamailio.org>' to 'you@kamailio.org <mailto:you@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@sip.domain.com <mailto:sip%3A00xxxxxxxxxx@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@lists.sip-router.org <mailto:sr-dev@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
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 < miconda@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 shaheryarkh@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@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@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@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,
- 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@kamailio.org' to 'you@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.
- 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' --
- 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@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] --
- 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@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
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 shaheryarkh@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 < miconda@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 shaheryarkh@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@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@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@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,
- 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@kamailio.org' to 'you@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.
- 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' --
- 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@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] --
- 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@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
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 shaheryarkh@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 shaheryarkh@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 < miconda@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 <shaheryarkh@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@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@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@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@kamailio.org' to 'you@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@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@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
On 07/01/15 09:21, Muhammad Shahzad wrote:
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. :-(
Good that you sorted out.
If you create the transaction and set flags later, then you need to sync back with transaction via:
- http://kamailio.org/docs/modules/stable/modules/tmx.html#tmx.f.t_flush_flags
Cheers, Daniel
On Tue, Jan 6, 2015 at 7:00 AM, Muhammad Shahzad <shaheryarkh@gmail.com mailto:shaheryarkh@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 <shaheryarkh@gmail.com <mailto:shaheryarkh@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 <miconda@gmail.com <mailto:miconda@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 <shaheryarkh@gmail.com <mailto:shaheryarkh@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@gmail.com <mailto:shaheryarkh@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@gmail.com <mailto:shaheryarkh@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@gmail.com <mailto:miconda@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@kamailio.org <mailto:you@kamailio.org>' to 'you@kamailio.org <mailto:you@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@sip.domain.com <mailto:sip%3A00xxxxxxxxxx@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@lists.sip-router.org <mailto:sr-dev@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://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
i would like to see ur kamailio.cfg,if possible,i am also getting the same error
-- View this message in context: http://sip-router.1086192.n5.nabble.com/Missing-accounting-events-in-ACC-tab... Sent from the Users mailing list archive at Nabble.com.
-
Daniel-Constantin Mierla -
last_jesus -
Muhammad Shahzad