[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