[Freeswitch-dev] mod_radius_cdr behavior and questions
Anthony Minessale
anthony.minessale at gmail.com
Tue Feb 3 13:18:07 PST 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/c4da767a/attachment-0001.html
More information about the Freeswitch-dev
mailing list