[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