[Freeswitch-users] mod_radius_cdr questions and thoughts

Wed Jan 28 07:50:15 PST 2009

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

On Tue, Jan 27, 2009 at 8:32 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>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 <regs at kinetix.gr>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 <
>> regs at 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/9333 at xxx.xxx.xxx.xxx) State
>> ROUTING
>> 2009-01-22 20:48:32 [DEBUG] mod_sofia.c:130 sofia_on_routing()
>> sofia/internal/9333 at 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 listFreeswitch-users at lists.freeswitch.orghttp://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: regs at kinetix.gr
>> -------------------------------------------
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-users mailing listFreeswitch-users at lists.freeswitch.orghttp://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: regs at kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-users mailing list
>> Freeswitch-users at lists.freeswitch.org
>> 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:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-users mailing listFreeswitch-users at lists.freeswitch.orghttp://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: regs at kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> 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:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090128/77e49971/attachment-0002.html 