[Freeswitch-dev] mod_radius_cdr behavior and questions
regs at kinetix.gr
regs at kinetix.gr
Mon Feb 2 14:52:32 PST 2009
I have not gone very deep in the event mechanisms.
I'll have a look at it.
Anthony Minessale wrote:
> also? what is in the session that is not already in the event?
>
> you should probably be looking for the channel_originate event not
> channel_create where you will have all the data about the channel that
> you need just in the event itself.
>
>
> On Mon, Feb 2, 2009 at 11:28 AM, Anthony Minessale
> <anthony.minessale at gmail.com <mailto:anthony.minessale at gmail.com>> 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
>
>
>
>
> --
> 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/20090203/f344c550/attachment-0001.html
More information about the Freeswitch-dev
mailing list