Please see in line comments.
Anthony Minessale wrote:
Sounds like having cake and eating it too.
The risk is obvious when using radius or some other additional
protocol for AAA that you will have trouble if the server is down.
Radius was designed to be fast and redundant, so typically you would
have 5 radius servers not one.
I did not make mod_radius_cdr but I do pose this question:
Where should the burden lie to make sure the calls are not delayed
when choosing this option?
Within the module. A separate thread could deal with the Acct Packet
transmission without
blocking the flow of the call. After a number of retries the thread
should quit trying.
If you make FS cache all the radius requests it could not complete in
a timely manner, the whole point of keeping track of the exact time
they occurred is lost and you could have calls that ended before the
start packet ever was transmitted because they are cached in some
process that will begin to swell with memory remembering all the
requests it could not send.
The acct start and stop packets contain the time info needed for billing
purposes Even if the radius packets reaches the server 10 secs after
the end of the call there is little harm done. The "real" start and stop
times don't have to correspond to the times the packets arrived at the
radius server.
Then somehow it needs to gracefully catch up again when the radius
server comes back.... This is the same reason I think that direct
database CDR is a bad idea.
If the retries*timeout time has passed the NAS should give up trying to
send the packet. So there is not much catching up to do. The radius packets
that failed while the radius server was down don't have to be
retransmitted later. All the applications and users that use radius are
comfortable with that
fact. I for one use a x-checking mechanism (comparing CDRs with radius
created CDRs) to verify the integrity of my calls.
The real answer is that you are not allowed to have your radius server
down at all, so you need more than one. I used to be in the dialup
business and we had to have backup radius servers for the backup
radius servers on a completely different network just in case not only
the server was down but the network link to the server and it's backup
server. It's like DNS, I can't ever be down or nothing works.
I always use multiple radius servers (using different routes to my
NASes). But sometimes there are other issues that could interfere with the
NAS-Radius connectivity.
On Tue, Jan 27, 2009 at 7:05 AM, Apostolos Pantsiopoulos
<[email protected] <mailto:[email protected]>> wrote:
Hi,
After some testing I came to the following conclusions :
1) The problem (timeouts and retries) I describe below only
happens when there is no radius server responding on the other side.
2) It only happens when using the latest cvs version of
radiusclient. If you use version 1.1.6 it works fine.
I also read in the wiki (and found out myself by testing) that :
"Currently, the module blocks the thread while it is sending the
requests. This may cause threads to hang around longer than
expected after a call, if your RADIUS servers are not
reachable/responding."
which I think is not desirable. Was this kind of behavior, been
followed intentionally?
I think that the NAS in most (if not all) implementations uses a
non-blocking operation
in order to proceed with the call. In that way there is not any
significant delay (up to 15 seconds if radius is down)
in the beginning of the call.
Also, I noticed that if the radius acct packet fails, FS does not
proceed with the call
which is again -in my opinion - wrong. I think that the NAS should
be able to continue with
the call even if the Acct start or stop failed.
For those directly involved in the maintenance of the
mod_radius_cdr code :
Is it relatively easy to change the blocking behavior of the module?
Apostolos Pantsiopoulos wrote:
Chris Parker wrote:
On Thu, Jan 22, 2009 at 10:45 AM, Apostolos Pantsiopoulos
<[email protected] <mailto:[email protected]>> wrote:
I am trying to implement a radius based solution
using FS. I have seen that the mod_radius_cdr module
is actively maintained. so I have a few questions/remarks :
1) When I place a call and my radius server is down, the
call blocks forever instead of just radius_timeout *
radius_retries
seconds (I have declared only one server). I would expect that
FS would stop trying to send an Acc Start packet after some
time and get on with the call.
I have not seen this behavior. If you can duplicate this, and
propose a patch, it would be gladly welcomed.
I rebuilt and retried and the behavior persists.
The call progress freezes and I get the following in the log :
2009-01-22 20:48:32 [DEBUG] switch_core_state_machine.c:435
switch_core_session_run() (sofia/internal/[email protected]
<mailto:sofia/internal/[email protected]>) State ROUTING
2009-01-22 20:48:32 [DEBUG] mod_sofia.c:130 sofia_on_routing()
sofia/internal/[email protected]
<mailto:sofia/internal/[email protected]> SOFIA ROUTING
2009-01-22 20:48:32 [DEBUG] mod_radius_cdr.c:152 my_on_routing()
[mod_radius_cdr] Entering my_on_routing
After I hangup the client and issue a shutdown in FS I get the
following :
2009-01-22 20:50:50 [CRIT] sofia.c:794 sofia_profile_thread_run()
Waiting for 1 session(s)
repeatedly and FS never exits.
2) I have also noticed that FS sends only 1 packet (I waited
for a minute)
instead of 3 (default in the config) since the first (and
second)
attempt failed.
If my server was up (the port was responding) but it
returned a req. failed
answer would the above time-out be valid?
I have not seen this behavior.
The same here after the rebuild.
3) When I tried to load the dictionary.freeswitch to my
freeradius
server, it complained :
Don't do that. The dictionary is for use with the radiusclient
library. FreeRADIUS already includes a dictionary for
FreeSWITCH VSAs ( you may need to uncomment it to have it loaded
into FreeRADIUS ).
I cannot find any reference to Freeswitch in the freeradius
integrated dictionaries (in the share folder). Can you pinpoint the
directory that a dictionary.freeswitch (or other FS related
dictionary) resides?
4) The radius attributes included in the current requests are
a) hard-coded, b) limited in number. I think many of us
would like to
use more attributes. Or even better define what to include
(and what to
put in them) using a
config file (the same maybe?)
This has been proposed. There isn't yet a mechanism, though the
intent is to use a general purpose FS VSA for this. The code
needs to be added to the mod_radius_cdr module to allow that to
be a run_time configuration option.
A general purpose VSA that holds only one value or many? Or a mix
(array like)?
5) Does the module send accounting packets only for the a-leg
of a call or for both legs? (Maybe that could be
configurable too).
If anyone is interested in the above questions/remarks
please post
a reply. I would really like to know how many of the mailing
list users
are also interested in FS radius support and your opinions
on the matter.
Again, patches are welcome. :)
-Chris
------------------------------------------------------------------------
_______________________________________________
Freeswitch-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: [email protected] <mailto:[email protected]>
-------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Freeswitch-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: [email protected] <mailto:[email protected]>
-------------------------------------------
_______________________________________________
Freeswitch-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
AIM: anthm
MSN:[email protected]
<mailto:msn%[email protected]>
GTALK/JABBER/PAYPAL:[email protected]
<mailto:paypal%[email protected]>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
sip:[email protected]
<mailto:sip%[email protected]>
iax:[email protected]/888
<http://iax:[email protected]/888>
googletalk:[email protected]
<mailto:googletalk%3aconf%[email protected]>
pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________
Freeswitch-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: [email protected]
-------------------------------------------
_______________________________________________
Freeswitch-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
