7 Jan
2015
7 Jan
'15
12:43 p.m.
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(a)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(a)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(a)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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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(a)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(a)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(a)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(a)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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
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(a)kamailio.org
<mailto:you@kamailio.org>' to
'you(a)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-244…
<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(a)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(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users