VoIP Mailing List Archives

[regs at kinetix.gr]

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.

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?

3) When I tried to load the dictionary.freeswitch to my freeradius
server, it complained :

"Errors reading dictionary: dict_init:
/usr/local/etc/raddb/dictionary.freeswitch[33]: dict_addattr: Duplicate
attribute name NAS-Port-Id"

How can I overcome this?

When I "instructed" my freeradius to only load the freesitch dictionary
I got this :

"Errors reading dictionary: dict_init:
/usr/local/etc/raddb/dictionary.freeswitch[257]: unknown option
"Freeswitch""

How can I use the dictionary with the freeradius? (or other radius
servers?)

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?)

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.

Regards,

--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs@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

[cparker at segv.org]

On Thu, Jan 22, 2009 at 10:45 AM, Apostolos Pantsiopoulos <regs@kinetix.gr (regs@kinetix.gr)> wrote:

[regs at kinetix.gr]

Chris Parker wrote:

[regs at kinetix.gr]

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.

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?

3) When I tried to load the dictionary.freeswitch to my freeradius
server, it complained :

"Errors reading dictionary: dict_init:
/usr/local/etc/raddb/dictionary.freeswitch[33]: dict_addattr: Duplicate
attribute name NAS-Port-Id"

How can I overcome this?

When I "instructed" my freeradius to only load the freesitch dictionary
I got this :

"Errors reading dictionary: dict_init:
/usr/local/etc/raddb/dictionary.freeswitch[257]: unknown option
"Freeswitch""

How can I use the dictionary with the freeradius? (or other radius servers?)

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?)

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.

Regards,

--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs@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

[brian at freeswitch.org]

Did you mean to send this twice?

/b

On Jan 22, 2009, at 8:52 AM, Apostolos Pantsiopoulos wrote:

[regs at kinetix.gr]

the first one would not appear in the mailing list
2 hours after I had sent it so I figured there was something wrong
and I resent it

Brian West wrote:

[regs at kinetix.gr]

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:

[anthony.minessale at g...]

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?

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. 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.

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.



On Tue, Jan 27, 2009 at 7:05 AM, Apostolos Pantsiopoulos <regs@kinetix.gr (regs@kinetix.gr)> wrote:

[regs at kinetix.gr]

Please see in line comments.

Anthony Minessale wrote:

[anthony.minessale at g...]

We have a saying here in open source.....
Patches Welcome!


On Tue, Jan 27, 2009 at 8:32 AM, Apostolos Pantsiopoulos <regs@kinetix.gr (regs@kinetix.gr)> wrote: