<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Please see in line comments.<br>
<br>
Anthony Minessale wrote:
<blockquote
cite="mid:191c3a030901270614i23a41bc2o1fbeaf576ab3811c@mail.gmail.com"
type="cite">Sounds like having cake and eating it too.<br>
<br>
The risk is obvious when using radius or some other additional protocol
for AAA that you will have trouble if the server is down.<br>
Radius was designed to be fast and redundant, so typically you would
have 5 radius servers not one.<br>
<br>
I did not make mod_radius_cdr but I do pose this question:<br>
<br>
Where should the burden lie to make sure the calls are not delayed when
choosing this option?<br>
</blockquote>
Within the module. A separate thread could deal with the Acct Packet
transmission without<br>
blocking the flow of the call. After a number of retries the thread
should quit trying.<br>
<blockquote
cite="mid:191c3a030901270614i23a41bc2o1fbeaf576ab3811c@mail.gmail.com"
type="cite"><br>
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. </blockquote>
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<br>
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 <br>
radius server.<br>
<blockquote
cite="mid:191c3a030901270614i23a41bc2o1fbeaf576ab3811c@mail.gmail.com"
type="cite">
<br>
</blockquote>
<blockquote
cite="mid:191c3a030901270614i23a41bc2o1fbeaf576ab3811c@mail.gmail.com"
type="cite">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.<br>
</blockquote>
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<br>
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<br>
fact. I for one use a x-checking mechanism (comparing CDRs with radius
created CDRs) to verify the integrity of my calls.<br>
<blockquote
cite="mid:191c3a030901270614i23a41bc2o1fbeaf576ab3811c@mail.gmail.com"
type="cite"><br>
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.<br>
</blockquote>
I always use multiple radius servers (using different routes to my
NASes). But sometimes there are other issues that could interfere with
the <br>
NAS-Radius connectivity.<br>
<blockquote
cite="mid:191c3a030901270614i23a41bc2o1fbeaf576ab3811c@mail.gmail.com"
type="cite"><br>
<br>
<br>
<div class="gmail_quote">On Tue, Jan 27, 2009 at 7:05 AM, Apostolos
Pantsiopoulos <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Hi,<br>
<br>
After some testing I came to the following conclusions :<br>
<br>
1) The problem (timeouts and retries) I describe below only happens
when there is no radius server responding on the other side.<br>
<br>
2) It only happens when using the latest cvs version of radiusclient.
If you use version 1.1.6 it works fine.<br>
<br>
I also read in the wiki (and found out myself by testing) that :<br>
<br>
"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."<br>
<br>
which I think is not desirable. Was this kind of behavior, been
followed intentionally?<br>
I think that the NAS in most (if not all) implementations uses a
non-blocking operation<br>
in order to proceed with the call. In that way there is not any
significant delay (up to 15 seconds if radius is down)<br>
in the beginning of the call.<br>
Also, I noticed that if the radius acct packet fails, FS does not
proceed with the call<br>
which is again -in my opinion - wrong. I think that the NAS should be
able to continue with<br>
the call even if the Acct start or stop failed.<br>
<br>
For those directly involved in the maintenance of the mod_radius_cdr
code :<br>
<br>
Is it relatively easy to change the blocking behavior of the module?
<div>
<div class="Wj3C7c"><br>
<br>
Apostolos Pantsiopoulos wrote:
<blockquote type="cite"> Chris Parker wrote:
<blockquote type="cite">On Thu, Jan 22, 2009 at 10:45 AM,
Apostolos Pantsiopoulos <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
am trying to implement a radius based solution<br>
using FS. I have seen that the mod_radius_cdr module<br>
is actively maintained. so I have a few questions/remarks :<br>
<br>
1) When I place a call and my radius server is down, the<br>
call blocks forever instead of just radius_timeout * radius_retries<br>
seconds (I have declared only one server). I would expect that<br>
FS would stop trying to send an Acc Start packet after some<br>
time and get on with the call.</blockquote>
<div><br>
I have not seen this behavior. If you can duplicate this, and propose
a patch, it would be gladly welcomed. <br>
</div>
</div>
</blockquote>
I rebuilt and retried and the behavior persists.<br>
<br>
The call progress freezes and I get the following in the log :<br>
<br>
2009-01-22 20:48:32 [DEBUG] switch_core_state_machine.c:435
switch_core_session_run() (<a moz-do-not-send="true"
href="mailto:sofia/internal/9333@xxx.xxx.xxx.xxx" target="_blank">sofia/internal/9333@xxx.xxx.xxx.xxx</a>)
State
ROUTING<br>
2009-01-22 20:48:32 [DEBUG] mod_sofia.c:130 sofia_on_routing() <a
moz-do-not-send="true" href="mailto:sofia/internal/9333@xx.xxx.xxx.xxx"
target="_blank">sofia/internal/9333@xx.xxx.xxx.xxx</a>
SOFIA ROUTING<br>
2009-01-22 20:48:32 [DEBUG] mod_radius_cdr.c:152 my_on_routing()
[mod_radius_cdr] Entering my_on_routing<br>
<br>
After I hangup the client and issue a shutdown in FS I get the
following :<br>
<br>
2009-01-22 20:50:50 [CRIT] sofia.c:794 sofia_profile_thread_run()
Waiting for 1 session(s)<br>
<br>
repeatedly and FS never exits.<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
2) I have also noticed that FS sends only 1 packet (I waited for a
minute)<br>
instead of 3 (default in the config) since the first (and second)<br>
attempt failed.<br>
If my server was up (the port was responding) but it returned a req.
failed<br>
answer would the above time-out be valid?</blockquote>
<div><br>
I have not seen this behavior.<br>
</div>
</div>
</blockquote>
The same here after the rebuild.<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
3) When I tried to load the dictionary.freeswitch to my freeradius<br>
server, it complained :</blockquote>
<div><br>
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 ).<br>
</div>
</div>
</blockquote>
I cannot find any reference to Freeswitch in the freeradius integrated
dictionaries (in the share folder). Can you pinpoint the<br>
directory that a dictionary.freeswitch (or other FS related dictionary)
resides?<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4)
The radius attributes included in the current requests are<br>
a) hard-coded, b) limited in number. I think many of us would like to<br>
use more attributes. Or even better define what to include (and what to<br>
put in them) using a<br>
config file (the same maybe?)</blockquote>
<div><br>
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. <br>
</div>
</div>
</blockquote>
A general purpose VSA that holds only one value or many? Or a mix
(array like)?<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">5)
Does the module send accounting packets only for the a-leg<br>
of a call or for both legs? (Maybe that could be configurable too).<br>
<br>
If anyone is interested in the above questions/remarks please post<br>
a reply. I would really like to know how many of the mailing list users<br>
are also interested in FS radius support and your opinions on the
matter.<br>
</blockquote>
<div><br>
Again, patches are welcome. :) <br>
</div>
</div>
</blockquote>
<blockquote type="cite"><br>
-Chris<br>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-users mailing list
<a moz-do-not-send="true"
href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a>
<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/options/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a moz-do-not-send="true" href="http://www.freeswitch.org"
target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a moz-do-not-send="true" href="mailto:regs@kinetix.gr"
target="_blank">regs@kinetix.gr</a>
------------------------------------------- </pre>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-users mailing list
<a moz-do-not-send="true"
href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a>
<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/options/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a moz-do-not-send="true" href="http://www.freeswitch.org"
target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a moz-do-not-send="true" href="mailto:regs@kinetix.gr"
target="_blank">regs@kinetix.gr</a>
------------------------------------------- </pre>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/options/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a moz-do-not-send="true" href="http://www.freeswitch.org"
target="_blank">http://www.freeswitch.org</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a moz-do-not-send="true" href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>
ClueCon <a moz-do-not-send="true" href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>
AIM: anthm<br>
<a moz-do-not-send="true"
href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a moz-do-not-send="true"
href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a moz-do-not-send="true" href="http://irc.freenode.net">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a moz-do-not-send="true"
href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br>
<a moz-do-not-send="true"
href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a moz-do-not-send="true"
href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Freeswitch-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a class="moz-txt-link-abbreviated" href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>
------------------------------------------- </pre>
</body>
</html>