[Freeswitch-dev] mod_radius_cdr behavior and questions
Apostolos Pantsiopoulos
regs at kinetix.gr
Tue Feb 3 13:13:17 PST 2009
"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 <mailto: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 <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 <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/612bcf74/attachment-0001.html
More information about the Freeswitch-dev
mailing list