[Freeswitch-dev] mod_radius_cdr behavior and questions
Apostolos Pantsiopoulos
regs at kinetix.gr
Mon Feb 2 04:02:07 PST 2009
Anthony,
I need your help in clarifying something.
I my module load function I am using this to bind a handler to a
specific event (channel create) :
if (switch_event_bind(modname, SWITCH_EVENT_CHANNEL_CREATE,
SWITCH_EVENT_SUBCLASS_ANY, my_on_create_handler, NULL) !=
SWITCH_STATUS_SUCCESS) {
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR,
"Couldn't bind!\n");
return SWITCH_STATUS_GENERR;
}
Then in my my_on_create_handler routine I have :
static void my_on_create_handler(switch_event_t *event) {
char* uuid = switch_event_get_header(event, "Unique-ID");
switch_core_session_t *session;
session = switch_core_session_locate(uuid);
}
this is only for test purposes. My handler does nothing else than
creating a pointer to the session that
triggered the event. Everything compiles just fine. When I am running
freeswitch everything goes
as expected (my handling routine is called and a session is indeed
returned on my local session variable)
except from one thing : I can see doing a "ps -eLf" that the session
threads of my call get stuck and never get terminated.
I can also tell that they are stuck by that error message in my console :
switch_core_session_hupall() Giving up with 42 sessions remaining
which makes sense since I initiated 21 bridged calls.
Is the reference (pointer) to the session the cause of all these? Does
FS considers that
since there are still references to a session the session should not be
terminated? If yes,
how can I destroy this reference (after I have used it)?
Anthony Minessale wrote:
> 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 <mailto: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 <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
>> <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
>
>
> --
> -------------------------------------------
> 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/20090202/d0038f69/attachment-0001.html
More information about the Freeswitch-dev
mailing list