We have a saying here in open source..... Patches Welcome!
On Tue, Jan 27, 2009 at 8:32 AM, Apostolos Pantsiopoulos <[email protected]>wrote: > 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]>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]> 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]) State >> ROUTING >> 2009-01-22 20:48:32 [DEBUG] mod_sofia.c:130 sofia_on_routing() >> 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 >> [email protected]http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org >> >> >> >> -- >> ------------------------------------------- >> Apostolos Pantsiopoulos >> Kinetix Tele.com R & D >> email: [email protected] >> ------------------------------------------- >> >> ------------------------------ >> >> _______________________________________________ >> Freeswitch-users mailing >> [email protected]http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://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 >> >> > > > -- > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > > AIM: anthm > MSN:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > iax:[email protected]/888 > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:213-799-1400 > > ------------------------------ > > _______________________________________________ > Freeswitch-users mailing > [email protected]http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://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 > > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:[email protected] <msn%[email protected]> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[email protected] <sip%[email protected]> iax:[email protected]/888 googletalk:[email protected]<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
