[Freeswitch-dev] mod_radius_cdr behavior and questions

Apostolos Pantsiopoulos regs at kinetix.gr
Tue Feb 3 06:41:13 PST 2009


Even if my intention was not to send the acct start in a separate thread
we are still missing an acct start at the setup of the b-leg of a bridge.
The on_routing handler cannot do that (it is called only for the a-leg).
I tried on_init (which I thought was called at the setup of a channel) but
it didn't invoke my handler even for the a-leg. An event on the other hand
(create_channel) which is triggered correctly does not carry all the info
needed for an acct start packet to be filled (not even at a min level). The
event originate_channel is also called only once during a bridge, so it 
cannot
be used either.

So it is not only a matter of thread vs non threaded (or multiple 
threads vs one thread).
It is also a matter of when and how many times (2 for a simple bridge) 
to call an
acct start routine.

So we either need to create one more state handler that gets called in 
such a
manner that can be used for b-legs too. Or an event of the same kind 
that carries all the info
needed by radius acct start.
Both ways (adding a state-handler or adding a new event) I think require
changes to the FS core architecture. I must admit, however, that my
understanding of the FS source code is still on a newbie level so the above
conclusions might be wrong.


Anthony Minessale wrote:
> or everything is already in the right place the way it already is.....?
>
> If all you want to do is background the start packet, then just take 
> the info in the place where the existing code gets it (routing state 
> change) and create your own switch_event or private struct, add the 
> data to it and launch a thread to run the radius in it's own thread.
>
> I still think making the radius not be down or have short timeouts 
> across a list of servers is a better place to fix it than making FS 
> launch a bonus thread per established call to run the radius start 
> packets in the bg.
>
> I also still think that if you insist on not listing to my previous 
> point, pushing all the packets to a fifo queue is better than 
> launching a new thread per call because if the server is down and 
> timing out why would you want to have 250 threads up at once all 
> blocking on the dead radius instead of a queue of them that could 
> withstand a bit of downtime by stacking up the start packet requests 
> and unloading them in order when it returned.
>
>
>
> On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos 
> <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>
>     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 <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
>>       
>
>
>     -- 
>     -------------------------------------------
>     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
>   


-- 
-------------------------------------------
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/7059ad39/attachment-0001.html 


More information about the Freeswitch-dev mailing list