9 Mar
2009
9 Mar
'09
4:02 p.m.
Hi all,
I see a very strange behaviour using accounting on RADIUS.
If RADIUS server is up and running, all is OK. If it is down dialog
module (in db mode) can't work properly:
In the log I see:
after 200 OK to INVITE
CRITICAL:dialog:log_next_state_dlg: bogus event 6 in state 2 for dlg
0xb61c0918 [360:515907930] with clid
'B8108B3CEBD9B8E3E1CC23DE8361D35F@sipsvr' and tags
'C319BA6F3E777E04867202774CE6443B' ''
after BYE
CRITICAL:dialog:log_next_state_dlg: bogus event 7 in state 2 for dlg
0xb61c0918 [360:515907930] with clid
'B8108B3CEBD9B8E3E1CC23DE8361D35F@sipsvr' and tags
'C319BA6F3E777E04867202774CE6443B' ''
and no record is written in the dialog table.
All come back to work after starting RADIUS server.
This is not the main problem...
In some circumstance kamailio fails to route properly the calls, due
retransmissions; for instance after the client answers I see a lot of
200 OK sent to kamailio because it doesn't send the ACK immediately.
In the log I see for each 200 OK:
...
Mar 9 11:34:01 [27466] DBG:tm:timer_routine: timer
routine:3,tl=0xb61a8ecc next=(nil), timeout=75
Mar 9 11:34:01 [27466] DBG:tm:delete_handler: removing 0xb61a8e68
Mar 9 11:34:01 [27466] DBG:tm:delete_cell: delete_cell 0xb61a8e68:
can't delete -- still reffed (1)
Mar 9 11:34:01 [27466] DBG:tm:set_timer: relative timeout is 2
Mar 9 11:34:01 [27466] DBG:tm:insert_timer_unsafe: [3]: 0xb61a8ecc (77)
Mar 9 11:34:01 [27466] DBG:tm:delete_handler: done
...
I was not able to replicate this problem. Solved after starting RADIUS
server, but the problem doesn't occur if I stop it.
I'm using kamailio 1.4.3, but the last problem occurred also on a
production system with openser 1.2.3. After customer's RADIUS server
went down, openser wasn't able to route all calls.
Thank you very much for support.
Regards,
Antonio.
9 Mar
9 Mar
7:33 p.m.
New subject: [Kamailio-Users] Strange behaviour when RADIUS server is down
Antonio Reale writes:
I see a very strange behaviour using accounting on
RADIUS.
If RADIUS server is up and running, all is OK. If it is down dialog
module (in db mode) can't work properly:
is dialog module really using radius? if not, perhaps it is accounting
or something else that you have which uses radius.
if you want your proxy to work fine without having radius server
running, i don't see any other way than stop using any radius based
modules.
-- juha
10 Mar
10 Mar
9:32 a.m.
2009/3/9 Juha Heinanen <jh(a)tutpro.com>om>:
is dialog module really using radius? if not, perhaps
it is accounting
or something else that you have which uses radius.
Hi Juha,
RADIUS is used only for accounting. I don't see direct relationship
between RADIUS and dialog modules.
I think that it is due to the state of slowness caused by the absence
of the RADIUS server.
About this error Bogdan wrote on OpenSIPS ML:
"bogus event 6 in state 2 for" means ACK was received while still in
in EARLY state (no 200 OK received). This is a know bug...".
if you want your proxy to work fine without having
radius server
running, i don't see any other way than stop using any radius based
modules.
Sure.. I configured RADIUS in the kamailio script only in scenarios
that really need it. The problem here is:
what happen if the RADIUS server goes down for a fault? I expect that
calls are not accounted, but correctly routed.
Insted for two times I had a loss of service and I had to temporarly
disable RADIUS module to put it in service.
Is there any timer for the kamailio to wait responses by the RADIUS server?
-- juha
Regards.
Antonio.
9:54 a.m.
Antonio Reale writes:
Sure.. I configured RADIUS in the kamailio script only
in scenarios
that really need it. The problem here is:
what happen if the RADIUS server goes down for a fault? I expect that
calls are not accounted, but correctly routed.
Insted for two times I had a loss of service and I had to temporarly
disable RADIUS module to put it in service.
Is there any timer for the kamailio to wait responses by the RADIUS
server?
radiusclient-ng lib has radius_timeout config variable. i would imagine
that if there is no response from the server by that time, radius
request will fail. i don't know what accounting module does if
accounting request fails.
-- juha
10:11 a.m.
Antonio Reale writes:
Thanks. I'll try if this can help.
Waiting for someone that can confirme the issue.
radius accounting is different from other radius modules, because in acc
module, accounting is triggered by tm module. in other radius modules,
if radius request fails, the corresponding script function fails too.
if sending of radius accounting request fails, it should not fail the
transaction. i have not tested if it does.
-- juha
10:49 a.m.
2009/3/10 Juha Heinanen <jh(a)tutpro.com>om>:
radius accounting is different from other radius
modules, because in acc
module, accounting is triggered by tm module.
[CUT]
OK. So this can be the relationship between the accounting and the
delay relaying SIP messages. Is that so?
if sending of radius accounting request fails, it
should not fail the
transaction. i have not tested if it does.
I think that it doesn't fail the transaction but it affect the
signaling. Attached the short wireshark trace when reproduced the
issue in lab with RADIUS server down.
In the trace I see about 10 seconds between the reception and the
relay of the ACK by kamailio (maybe "radius_timeout 10" in
radiusclient.conf ?)
P.S.: in the trace you see only two IP addresses because both clients
are on 10.10.45.86...
-- juha
Thank you for your help.
Regards.
Antonio.
1:18 p.m.
AFAIR, if radius server is down, ACK will not be relayed.
The call cannot be accounted and therefor the call is dropped.
So, the radius server is a single point of failure.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 6:49 AM, Antonio Reale <ant.reale(a)gmail.com> wrote:
2009/3/10 Juha Heinanen <jh(a)tutpro.com>om>:
radius accounting is different from other radius
modules, because in acc
module, accounting is triggered by tm module.
[CUT]
OK. So this can be the relationship between the accounting and the
delay relaying SIP messages. Is that so?
if sending of radius accounting request fails, it
should not fail the
transaction. i have not tested if it does.
I think that it doesn't fail the transaction but it affect the
signaling. Attached the short wireshark trace when reproduced the
issue in lab with RADIUS server down.
In the trace I see about 10 seconds between the reception and the
relay of the ACK by kamailio (maybe "radius_timeout 10" in
radiusclient.conf ?)
P.S.: in the trace you see only two IP addresses because both clients
are on 10.10.45.86...
-- juha
Thank you for your help.
Regards.
Antonio.
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
7:47 p.m.
Ovidiu Sas writes:
AFAIR, if radius server is down, ACK will not be
relayed.
The call cannot be accounted and therefor the call is dropped.
So, the radius server is a single point of failure.
not necessarily a SINGLE point of failure, i.e., there can be more than
one radius server. my suggestion is have more than one radius server
and set radius_timeout and radius_retries to small values.
-- juha
/etc/radiusclient-ng/radiusclient.conf
# RADIUS server to use for authentication requests. this config
# item can appear more then one time. if multiple servers are
# defined they are tried in a round robin fashion if one
# server is not answering.
# optionally you can specify a the port number on which is remote
# RADIUS listens separated by a colon from the hostname. if
# no port is specified /etc/services is consulted of the radius
# service. if this fails also a compiled in default is used.
authserver 127.0.0.1
# RADIUS server to use for accouting requests. All that I
# said for authserver applies, too.
#
acctserver 127.0.0.1
11 Mar
11 Mar
11:38 a.m.
2009/3/10 Juha Heinanen <jh(a)tutpro.com>om>:
Ovidiu Sas writes:
OK. Probably this is a good solution.
Anyway I thing that there is a strange behaviour because in the
majority of tests the loss of RADIUS server affect the accounting but
not the signaling, only sometimes it affect the signaling.
Thanks to all for the attention and support.
AFAIR, if radius server is down, ACK will not be
relayed.
The call cannot be accounted and therefor the call is dropped.
So, the radius server is a single point of failure.
not necessarily a SINGLE point of failure, i.e., there can be more than
one radius server. my suggestion is have more than one radius server
and set radius_timeout and radius_retries to small values. -- juha
Regards,
Antonio
10 Mar
10 Mar
9:57 p.m.
Would using a local radius-proxy help in this case?
Kamailio configured to communicate with the local proxy which can queue the request for
the remote radius server when it becomes unavailable.
--
Zahid
-----Original Message-----
From: users-bounces(a)lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] On Behalf
Of Ovidiu Sas
Sent: Tuesday, March 10, 2009 9:19 AM
To: Antonio Reale
Cc: Users(a)lists.kamailio.org
Subject: Re: [Kamailio-Users] Strange behaviour when RADIUS server is down
AFAIR, if radius server is down, ACK will not be relayed.
The call cannot be accounted and therefor the call is dropped.
So, the radius server is a single point of failure.
Regards,
Ovidiu Sas
On Tue, Mar 10, 2009 at 6:49 AM, Antonio Reale <ant.reale(a)gmail.com> wrote:
2009/3/10 Juha Heinanen <jh(a)tutpro.com>om>:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
radius accounting is different from other radius
modules, because in acc
module, accounting is triggered by tm module.
[CUT]
OK. So this can be the relationship between the accounting and the
delay relaying SIP messages. Is that so?
if sending of radius accounting request fails, it
should not fail the
transaction. i have not tested if it does.
I think that it doesn't fail the transaction but it affect the
signaling. Attached the short wireshark trace when reproduced the
issue in lab with RADIUS server down.
In the trace I see about 10 seconds between the reception and the
relay of the ACK by kamailio (maybe "radius_timeout 10" in
radiusclient.conf ?)
P.S.: in the trace you see only two IP addresses because both clients
are on 10.10.45.86...
-- juha
Thank you for your help.
Regards.
Antonio.
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
5606
days inactive
5608
days old
10 comments
4 participants
participants (4)
-
Antonio Reale -
jh＠tutpro.com -
Ovidiu Sas -
Zahid Mehmood