[Freeswitch-dev] mod_radius_cdr behavior and questions

Anthony Minessale anthony.minessale at gmail.com
Mon Feb 2 07:44:23 PST 2009 

when you call session = switch_core_session_locate(uuid);

if session is not NULL you MUST switch_core_session_rwunlock(session) before
you exit your function.

I have already pointed out 2 times now that you should not try to
session_locate the session, you should be using the data for the event for
this, and dup the event and hand the info to a backend thread over a fifo
queue?

On Mon, Feb 2, 2009 at 6:02 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  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>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
>
> ------------------------------
>
> _______________________________________________
> 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/20090202/17884082/attachment-0001.html

More information about the Freeswitch-dev mailing list