[Freeswitch-dev] mod_radius_cdr behavior and questions

Anthony Minessale anthony.minessale at gmail.com
Tue Feb 3 12:37:12 PST 2009 

I updated the core today in a way that you will not get that event handler
on both inbound and outbound legs.


On Tue, Feb 3, 2009 at 8:41 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  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>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 <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 <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> 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> 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> 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
>>>>>>> -------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anthony Minessale II
>>>>>>
>>>>>> FreeSWITCH http://www.freeswitch.org/
>>>>>> ClueCon http://www.cluecon.com/
>>>>>>
>>>>>> AIM: anthm
>>>>>> MSN:anthony_minessale at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>
>>>>>> FreeSWITCH Developer Conference
>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>> iax:guest at conference.freeswitch.org/888
>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>> pstn:213-799-1400
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Anthony Minessale II
>>>>>
>>>>> FreeSWITCH http://www.freeswitch.org/
>>>>> ClueCon http://www.cluecon.com/
>>>>>
>>>>> AIM: anthm
>>>>> MSN:anthony_minessale at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>> IRC: irc.freenode.net #freeswitch
>>>>>
>>>>> FreeSWITCH Developer Conference
>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>> iax:guest at conference.freeswitch.org/888
>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>> pstn:213-799-1400
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Anthony Minessale II
>>>>
>>>> FreeSWITCH http://www.freeswitch.org/
>>>> ClueCon http://www.cluecon.com/
>>>>
>>>> AIM: anthm
>>>> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> iax:guest at conference.freeswitch.org/888
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:213-799-1400
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Anthony Minessale II
>>>
>>> FreeSWITCH http://www.freeswitch.org/
>>> ClueCon http://www.cluecon.com/
>>>
>>> AIM: anthm
>>> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://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
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://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
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/f5988330/attachment-0001.html

More information about the Freeswitch-dev mailing list