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