[Freeswitch-dev] mod_radius_cdr behavior and questions

Apostolos Pantsiopoulos regs at kinetix.gr
Fri Jan 30 03:14:07 PST 2009


    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 
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 
pair for each end to end call, depending on the configuration. Opensips 
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 :


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

More information about the Freeswitch-dev mailing list