9 Jul
2010
9 Jul
'10
3:03 p.m.
Dear ALL,
I have configured Kamailio 1.5 from svn with radius (radiusclient-ng)
support for acc.
All seem to work okay, except one thing.
From time to time I am receiving following radius error
(debug from
radius server on different ip)
Fri Jul 9 12:22:58 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:08 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:18 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
A few lines from radiusclient.conf
# time to wait for a reply from the RADIUS server
radius_timeout 10
# resend request this many times before trying the next server
radius_retries 3
After closer look at this, it turned out that there is one START
request and four STOPs with the same CallID (Acct-Session-Id).
START and first STOP are treated as a pair, the next ones are odd.
Taking about sip i do have following scenario:
MGW(1)---Kamailio(2)---SIP_Provider(SER based)(3)
The call flow that generate aforemtioned errors looks like below
(debug on kamailio)
1 - (2) is receiving INVITE from (3)
2 - (2) is sending Giving a Try to (3)
3 - (2) is sending INVITE to (1)
4 - (2) is receiving Trying from (1)
5 - (2) is receiving Ringing from (1)
6 - (2) is receiving OK from (1)
7 - (2) is sending OK to (3)
8 - (2) is receiving ACK from (3)
9 - (2) is sending ACK to (1)
---- call----
10 - (2) is receiving BYE from (1) (tearing down from (1) side, STOP
radius request is generated)
11 - (2) is sending BYE to (3)
12 - (2) is receiving BYE from (3) (second STOP is generated,
radius_retries 3, radius_timeout 10)
13 - (2) is sending BYE to (1)
14 - (2) is receiving OK from (1)
15 - (2) is sending OK to (3)
16 - (2) is receiving OK to (3)
17 - (2) is sending OK to (1)
For sure there is sth wrong with SIP_Provider but how Kamilio should
behave is such situation.
Should second BYE (p.12) with the same callid as in p.10 be continued with p.13?
Thanks in advance,
Maciej.
9 Jul
9 Jul
3:22 p.m.
If the BYEs are genuine retransmissions, they should be dampened using
t_check_trans() before they are processed by TM and therefore ACC.
On 07/09/2010 08:03 AM, Maciej Bylica wrote:
Dear ALL,
I have configured Kamailio 1.5 from svn with radius (radiusclient-ng)
support for acc.
All seem to work okay, except one thing.
From time to time I am receiving following radius error (debug from
radius server on different ip)
Fri Jul 9 12:22:58 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:08 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:18 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
A few lines from radiusclient.conf
# time to wait for a reply from the RADIUS server
radius_timeout 10
# resend request this many times before trying the next server
radius_retries 3
After closer look at this, it turned out that there is one START
request and four STOPs with the same CallID (Acct-Session-Id).
START and first STOP are treated as a pair, the next ones are odd.
Taking about sip i do have following scenario:
MGW(1)---Kamailio(2)---SIP_Provider(SER based)(3)
The call flow that generate aforemtioned errors looks like below
(debug on kamailio)
1 - (2) is receiving INVITE from (3)
2 - (2) is sending Giving a Try to (3)
3 - (2) is sending INVITE to (1)
4 - (2) is receiving Trying from (1)
5 - (2) is receiving Ringing from (1)
6 - (2) is receiving OK from (1)
7 - (2) is sending OK to (3)
8 - (2) is receiving ACK from (3)
9 - (2) is sending ACK to (1)
---- call----
10 - (2) is receiving BYE from (1) (tearing down from (1) side, STOP
radius request is generated)
11 - (2) is sending BYE to (3)
12 - (2) is receiving BYE from (3) (second STOP is generated,
radius_retries 3, radius_timeout 10)
13 - (2) is sending BYE to (1)
14 - (2) is receiving OK from (1)
15 - (2) is sending OK to (3)
16 - (2) is receiving OK to (3)
17 - (2) is sending OK to (1)
For sure there is sth wrong with SIP_Provider but how Kamilio should
behave is such situation.
Should second BYE (p.12) with the same callid as in p.10 be continued with p.13?
Thanks in advance,
Maciej.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
10 Jul
10 Jul
6:29 p.m.
Thanks
So does it mean that placing t_check_trans() inside loose_route() part
of the script should solve my issue?
Of course i do have record_route() for all non-REGISTER messages.
Thx,
Maciej.
2010/7/9 Alex Balashov <abalashov(a)evaristesys.com>om>:
If the BYEs are genuine retransmissions, they should
be dampened using
t_check_trans() before they are processed by TM and therefore ACC.
On 07/09/2010 08:03 AM, Maciej Bylica wrote:
Dear ALL,
I have configured Kamailio 1.5 from svn with radius (radiusclient-ng)
support for acc.
All seem to work okay, except one thing.
From time to time I am receiving following radius error (debug from
radius server on different ip)
Fri Jul 9 12:22:58 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:08 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:18 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
A few lines from radiusclient.conf
# time to wait for a reply from the RADIUS server
radius_timeout 10
# resend request this many times before trying the next server
radius_retries 3
After closer look at this, it turned out that there is one START
request and four STOPs with the same CallID (Acct-Session-Id).
START and first STOP are treated as a pair, the next ones are odd.
Taking about sip i do have following scenario:
MGW(1)---Kamailio(2)---SIP_Provider(SER based)(3)
The call flow that generate aforemtioned errors looks like below
(debug on kamailio)
1 - (2) is receiving INVITE from (3)
2 - (2) is sending Giving a Try to (3)
3 - (2) is sending INVITE to (1)
4 - (2) is receiving Trying from (1)
5 - (2) is receiving Ringing from (1)
6 - (2) is receiving OK from (1)
7 - (2) is sending OK to (3)
8 - (2) is receiving ACK from (3)
9 - (2) is sending ACK to (1)
---- call----
10 - (2) is receiving BYE from (1) (tearing down from (1) side, STOP
radius request is generated)
11 - (2) is sending BYE to (3)
12 - (2) is receiving BYE from (3) (second STOP is generated,
radius_retries 3, radius_timeout 10)
13 - (2) is sending BYE to (1)
14 - (2) is receiving OK from (1)
15 - (2) is sending OK to (3)
16 - (2) is receiving OK to (3)
17 - (2) is sending OK to (1)
For sure there is sth wrong with SIP_Provider but how Kamilio should
behave is such situation.
Should second BYE (p.12) with the same callid as in p.10 be continued with
p.13?
Thanks in advance,
Maciej.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11 Jul
11 Jul
8:08 p.m.
I think my script is pretty much standard one:
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
if (!method=="REGISTER")
record_route();
else {
sl_send_reply("488","Not Acceptable Here");
exit;
}
if (loose_route()) {
if (is_method("BYE"))
{
#Account BYE transaction
setflag(2);
}
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (is_method("INVITE")) {
if (allow_source_address("1")) {
if (from_uri=~"sip:112233@.*") {
$var(origin) = "from_sip1";
}
else if (from_uri=~"sip:44.*@.*") {
$var(origin) = "from_sip2";
}
else {
$var(origin) = "from_sip3";
}
}
else if (allow_source_address("2")) {
$var(origin) = "from_pstn1";
}
else {
sl_send_reply("403", "Forbidden");
exit;
};
if (!load_gws("$var(origin)")) {
sl_send_reply("503", "Unable to load
gateways");
exit;
}
if (!next_gw()) {
sl_send_reply("503", "Unable to find a
gateway");
exit;
}
setflag(2);
setflag(3);
route(1);
exit;
};
t_check_trans();
if (!uri==myself) {
sl_send_reply("488","Not Acceptable Here");
exit;
}
if (uri==myself) {
route(1);
exit;
};
# requests for my domain
if ($rU==NULL) {
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
};
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
};
t_release();
}
route[1] {
t_on_reply("1");
t_on_failure("11");
if (!t_relay()) {
sl_reply_error();
};
exit;
}
onreply_route[1] {
if(!t_check_trans()) {
drop;
}
setflag(2);
}
######################
# "default" failover #
######################
failure_route[11] {
# In case of failure, send it to an alternative route:
if (t_check_status("415|408|404|5[0-9][0-9]")) {
if (!next_gw()) {
t_reply("503", "Service not available, no more
gateways");
exit;
}
else {
t_on_failure("11");
setflag(2);
t_relay();
}
exit;
}
}
Could sb tell me where i made a mistake/how to modify the script to
drop BYEs I've mentioned.
Thanks in advance,
Maciej
2010/7/10 Maciej Bylica <mbsip(a)gazeta.pl>pl>:
Thanks
So does it mean that placing t_check_trans() inside loose_route() part
of the script should solve my issue?
Of course i do have record_route() for all non-REGISTER messages.
Thx,
Maciej.
2010/7/9 Alex Balashov <abalashov(a)evaristesys.com>om>:
If the BYEs are genuine retransmissions, they
should be dampened using
t_check_trans() before they are processed by TM and therefore ACC.
On 07/09/2010 08:03 AM, Maciej Bylica wrote:
Dear ALL,
I have configured Kamailio 1.5 from svn with radius (radiusclient-ng)
support for acc.
All seem to work okay, except one thing.
From time to time I am receiving following radius error (debug from
radius server on different ip)
Fri Jul 9 12:22:58 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:08 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
Fri Jul 9 12:23:18 2010 : Error: rlm_sql (sql): Couldn't update SQL
accounting STOP record - Column 'AcctStartTime' cannot be null
A few lines from radiusclient.conf
# time to wait for a reply from the RADIUS server
radius_timeout 10
# resend request this many times before trying the next server
radius_retries 3
After closer look at this, it turned out that there is one START
request and four STOPs with the same CallID (Acct-Session-Id).
START and first STOP are treated as a pair, the next ones are odd.
Taking about sip i do have following scenario:
MGW(1)---Kamailio(2)---SIP_Provider(SER based)(3)
The call flow that generate aforemtioned errors looks like below
(debug on kamailio)
1 - (2) is receiving INVITE from (3)
2 - (2) is sending Giving a Try to (3)
3 - (2) is sending INVITE to (1)
4 - (2) is receiving Trying from (1)
5 - (2) is receiving Ringing from (1)
6 - (2) is receiving OK from (1)
7 - (2) is sending OK to (3)
8 - (2) is receiving ACK from (3)
9 - (2) is sending ACK to (1)
---- call----
10 - (2) is receiving BYE from (1) (tearing down from (1) side, STOP
radius request is generated)
11 - (2) is sending BYE to (3)
12 - (2) is receiving BYE from (3) (second STOP is generated,
radius_retries 3, radius_timeout 10)
13 - (2) is sending BYE to (1)
14 - (2) is receiving OK from (1)
15 - (2) is sending OK to (3)
16 - (2) is receiving OK to (3)
17 - (2) is sending OK to (1)
For sure there is sth wrong with SIP_Provider but how Kamilio should
behave is such situation.
Should second BYE (p.12) with the same callid as in p.10 be continued with
p.13?
Thanks in advance,
Maciej.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5248
days inactive
5250
days old
3 comments
2 participants
participants (2)
-
Alex Balashov -
Maciej Bylica