[Freeswitch-dev] mod_radius_cdr behavior and questions
Apostolos Pantsiopoulos
regs at kinetix.gr
Mon Feb 2 23:31:30 PST 2009
You are right about the stop packet.
But what about the acct start packet?
If I put that on the session's thread that holds
the call from continuing.
Maybe a mixed solution (the acct start uses an event handler
and the acct stop uses a state handler) will be my last resort.
Anthony Minessale wrote:
> What other flow of the call are you waiting for?
> The hangup state handler is close to the last thing executed by the
> session thread before it's destroyed.
> The session thread has nothing better to do while it's waiting for the
> reply.
>
>
> On Mon, Feb 2, 2009 at 4:49 PM, regs at kinetix.gr
> <mailto:regs at kinetix.gr> <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>
> If the session thread makes the radius connection (and waits for
> it to complete)
> the flow of the call will be interrupted until the the radius code
> finishes (current implementation).
> this is why I figured that I need another thread in order to let
> the session continue
> whatever steps it needs until the completion of the call. this
> parallel thread (radius thread)
> could continue trying to send the radius packet even after the end
> of the call/session (desired
> implementation).
>
> I undesrtand now that the session_locate function stands in the
> way of I am trying to accomplish
> but I am afraid that using the session's thread (instead of a
> parallel one) would not meet my needs.
> I examined the code of the function and saw that it locks the
> session and that I need to unlock it myself.
> Although it works on the creation of a channel it does not work on
> the hangup (I get a core dump).
> I'll continue with it tomorrow.
>
> The state event handler is not suitable because I need to get an
> acct start on both call legs of a bridge
> and none of the state handlers in the state handler table does
> that for the b-leg.
>
>
> Anthony Minessale wrote:
>> The session runs in it's own thread when you use session_locate
>> to find a pointer to the session you stop that session from
>> exiting until you release it from the same thread you called
>> session_locate from.
>>
>> So the session could have just done the radius connection itself
>> in it's perfectly good existing thread.
>> now you are detaining the session and creating a new thread thus
>> wasting the session thread.
>>
>> instead of an event handler you may want to use a state handler
>> so you can run the stuff in the session thread.
>>
>>
>>
>> On Mon, Feb 2, 2009 at 11:18 AM, regs at kinetix.gr
>> <mailto:regs at kinetix.gr> <regs at kinetix.gr
>> <mailto:regs at kinetix.gr>> wrote:
>>
>> 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 <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
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20090203/dff56075/attachment-0001.html
More information about the Freeswitch-dev
mailing list