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
<r...@kinetix.gr <mailto:r...@kinetix.gr>> 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/9...@xxx.xxx.xxx.xxx) State
ROUTING
2009-01-22 20:48:32 [DEBUG] mod_sofia.c:130 sofia_on_routing()
sofia/internal/9...@xx.xxx.xxx.xxx 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
Freeswitch-users@lists.freeswitch.org
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: r...@kinetix.gr
-------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
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: r...@kinetix.gr
-------------------------------------------
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
