[Freeswitch-dev] mod_radius_cdr behavior and questions

Fri Jan 30 08:14:21 PST 2009

No problem, I have the advantage That I have implemented this technique all
over the place ;)
Your event handler is the recipient end of that same algorithm.

In fact the events are a very good thing to pass into queues.

You could clone the event and insert the clone into the queue and when you
pop it from the
backend thread you can just destroy it there then.

On Fri, Jan 30, 2009 at 8:27 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  Wow. I didn't expect so much detailing :)
>
> Thanks for the idea.
>
> My implementation is different though, but yours seems to be better.
>
> I will conclude what I started doing now and get back to you with the
> results.
>
> If something is wrong against my implementation I will try doing it your
> way.
>
> Thanks again!
>
> Anthony Minessale wrote:
>
> use a queue object to send the data in a dynamic struct to the other
> thread.
>
> 1) create a global queue.
> 2) create a struct with all the info you need to send.
>
> on the event handler.
>
> 1) malloc a new struct of that type.
> 2) memset it to all 0.
> 3) populate the struct.
> 4) write the data into the queue.
>
> launch a thread at startup that does a blocking wait on the same queue
>
> 1) pop the void pointer off the queue.
> 2) cast it into your struct.
> 3) extract the data from the struct and send it over radius.
> 4) destroy the struct with free and loop.
>
>
> On Fri, Jan 30, 2009 at 5:14 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
>
>> Hi,
>>
>>    I am tweaking the mod_radius_cdr module to archive the behavior
>> that most NASes have (i.e. accounting packets are sent in a separate
>> thread so that the submission does not interfere with the execution of
>> the call). While doing that, however, I bumped into another behavior of
>> the module that I think is not desirable (at least by me) :
>>
>>    While on a bridge, the module sends one acct start packet at the
>> beginning of the originating
>> leg (on_routing event handler) and two acct stop packets at the end of
>> each leg
>> (inbound and outbound). My opinion is that it should send one accounting
>> start
>> packet at the beginning of each call leg (inbound, outbound) resulting
>> to a total
>> number of two acct start packets. It is generally accepted that acct
>> start/stop packets
>> come in pairs so that billing applications can handle them accordingly.
>>
>>    Some NAS's radius radius implementations have some other
>> configuration modes
>> like the Cisco's RADIUS Packet Suppression. When in this mode the Cisco
>> NAS
>> sends only an accounting start/stop pair at the end of a final dialpeer
>> attempt (and suppresses
>> all the previous failed dialpeer attempts) thus resulting to less
>> network traffic. Other
>> NASes (such as MERA MVTS) can send a start/stop pair for each leg OR a
>> start/stop
>> pair for each end to end call, depending on the configuration. Opensips
>> follows
>> the star/stop pair by call leg paradigm. No matter what the
>> implementation, all of them
>> always send a acct start/stop pair. This is a common thing. And all the
>> billing platforms
>> can deal only with paired start/stops.
>>
>>    The current module behavior (one start two stops) can complicate
>> things since the
>> radius server would not know how to match the second stop packet with
>> its equivalent start.
>>
>>    Before I get the infamous answer "pathes welcomed" I would like to
>> state that I am
>> already involved in changing this behavior (through a patch). So my real
>> question is this :
>>
>> I noticed that the module uses the switch_core_add_state_handler
>> function to register
>> its handler table :
>>
>> switch_core_add_state_handler(&state_handlers);
>>
>> So the on_routing ( or the on_execute) event happens only when the
>> inbound call is started.
>> When the outbound call is initiated no handler is available to hook up a
>> function and
>> send the proper acct start packet.
>>
>>    Should the module register its handlers using the
>> switch_channel_add_state_handler() function instead?
>> And if yes, how could the module pass the channel as a parameter to the
>> function since channels
>> are created and destroyed dynamically (and the module when initialized
>> does not have that info).
>>
>>    I would greatly appreciate your help in pinpointing a proper way to
>> call my event handling
>> routines on a per call leg basis.
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> 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-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> 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-dev/attachments/20090130/271abf42/attachment.html 