[Freeswitch-dev] mod_radius_cdr behavior and questions

Anthony Minessale anthony.minessale at gmail.com
Tue Feb 3 14:32:10 PST 2009 

the same one that is already in there now the my_on_routing will now get
called for both legs.


On Tue, Feb 3, 2009 at 3:33 PM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  Cheers!
>
> One clarification though :
>
> Would that be a state handler? Or an event handler?
> And what is its name?
>
>
> Anthony Minessale wrote:
>
> yes,
>
> you will *now* get the event handler on both legs.
>
>
> On Tue, Feb 3, 2009 at 3:13 PM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
>
>>  "you will not get that event handler"
>>
>>  please tell me that this "not" meant to be a "now"
>>
>> Anthony Minessale wrote:
>>
>> 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
>>
>> ------------------------------
>>
>> _______________________________________________
>> 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/01d6c549/attachment-0001.html

More information about the Freeswitch-dev mailing list