[Freeswitch-dev] mod_radius_cdr behavior and questions
Apostolos Pantsiopoulos
regs at kinetix.gr
Tue Feb 3 02:59:42 PST 2009
I came to the following conclusions :
In the case of the acct start I cannot use the CHANNEL_ORIGINATE event
since
it is fired only once (I want to send one acct start for each leg)
If I use the CHANNEL_CREATE event for the acct start I am a little sort
on info
since the event does not contain much. So I need to get the info from
the session.
On the acct stop it is better to use the info from the event (lots of
info - easy to duplicate).
I was hoping to implement a uniform way to get data for both start and
stop but it seems
that this is not the case.
Apostolos Pantsiopoulos wrote:
> 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
> -------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/cc6ea1e6/attachment-0001.html
More information about the Freeswitch-dev
mailing list