[Freeswitch-dev] mod_radius_cdr behavior and questions
regs at kinetix.gr
regs at kinetix.gr
Mon Feb 2 09:18:10 PST 2009
Correct me if I am wrong, but wouldn't a fifo queue (along with its
processing thread)
process the radius packets to be sent in a sequential manner? And If a
packet submission
got stuck for retries*timeout secs wouldn't that affect the packets that
wait in the queue?
What I am trying to implement is different. I want the transmission of
the radius packets
to be independent of any sequence or order... That's why I am creating a
new thread
for each one, then detaching the thread, stalling the session with a
lock until I get all the
info I want from it and in the end notifying the calling function that
it is free to continue (even to destroy the session).
Also, does the event message contain all the possible info for a
session/channel/profile of a
call leg?
Anthony Minessale wrote:
> 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 <mailto: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 <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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/0f8ba5f9/attachment-0001.html
More information about the Freeswitch-dev
mailing list