[Freeswitch-dev] mod_radius_cdr behavior and questions
Apostolos Pantsiopoulos
regs at kinetix.gr
Fri Jan 30 06:27:49 PST 2009
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 <mailto: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 <mailto:regs at kinetix.gr>
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> <mailto: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
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> <http://iax:guest@conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs at kinetix.gr
-------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090130/818dd696/attachment-0001.html
More information about the Freeswitch-dev
mailing list