or everything is already in the right place the way it already is.....?<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br><br><br><div class="gmail_quote">On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos <span dir="ltr"><<a href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
I came to the following conclusions :<br>
<br>
In the case of the acct start I cannot use the CHANNEL_ORIGINATE event
since <br>
it is fired only once (I want to send one acct start for each leg)<br>
<br>
If I use the CHANNEL_CREATE event for the acct start I am a little sort
on info<br>
since the event does not contain much. So I need to get the info from
the session.<br>
<br>
On the acct stop it is better to use the info from the event (lots of
info - easy to duplicate).<br>
<br>
I was hoping to implement a uniform way to get data for both start and
stop but it seems<br>
that this is not the case.<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
Apostolos Pantsiopoulos wrote:
<blockquote type="cite">
You are right about the stop packet.<br>
But what about the acct start packet?<br>
If I put that on the session's thread that holds<br>
the call from continuing.<br>
Maybe a mixed solution (the acct start uses an event handler <br>
and the acct stop uses a state handler) will be my last resort.<br>
<br>
Anthony Minessale wrote:
<blockquote type="cite">What other flow of the call are you waiting for?<br>
The hangup state handler is close to the last thing executed by the
session thread before it's destroyed.<br>
The session thread has nothing better to do while it's waiting for the
reply.<br>
<br>
<br>
<div class="gmail_quote">On Mon, Feb 2, 2009 at 4:49 PM, <a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>
<span dir="ltr"><<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">If the session thread makes
the radius connection (and waits for it to
complete)<br>
the flow of the call will be interrupted until the the radius code
finishes (current implementation).<br>
this is why I figured that I need another thread in order to let the
session continue<br>
whatever steps it needs until the completion of the call. this parallel
thread (radius thread)<br>
could continue trying to send the radius packet even after the end of
the call/session (desired<br>
implementation).<br>
<br>
I undesrtand now that the session_locate function stands in the way of
I am trying to accomplish<br>
but I am afraid that using the session's thread (instead of a parallel
one) would not meet my needs.<br>
I examined the code of the function and saw that it locks the session
and that I need to unlock it myself.<br>
Although it works on the creation of a channel it does not work on the
hangup (I get a core dump).<br>
I'll continue with it tomorrow. <br>
<br>
The state event handler is not suitable because I need to get an acct
start on both call legs of a bridge<br>
and none of the state handlers in the state handler table does that for
the b-leg.<br>
<br>
<br>
Anthony Minessale wrote:
<blockquote type="cite">
<div>
<div>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.<br>
<br>
So the session could have just done the radius connection itself in
it's perfectly good existing thread.<br>
now you are detaining the session and creating a new thread thus
wasting the session thread.<br>
<br>
instead of an event handler you may want to use a state handler so you
can run the stuff in the session thread.<br>
<br>
<br>
<br>
<div class="gmail_quote">On Mon, Feb 2, 2009 at 11:18 AM, <a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>
<span dir="ltr"><<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Correct me if I am
wrong,
but
wouldn't a fifo queue (along with its
processing thread)<br>
process the radius packets to be sent in a sequential manner? And If a
packet submission<br>
got stuck for retries*timeout secs wouldn't that affect the packets
that wait in the queue?<br>
What I am trying to implement is different. I want the transmission of
the radius packets <br>
to be independent of any sequence or order... That's why I am creating
a new thread<br>
for each one, then detaching the thread, stalling the session with a
lock until I get all the<br>
info I want from it and in the end notifying the calling function that
it is free to continue (even to destroy the session).<br>
Also, does the event message contain all the possible info for a
session/channel/profile of a<br>
call leg?<br>
<br>
Anthony Minessale wrote:
<blockquote type="cite">when you call session =
switch_core_session_locate(uuid);<br>
<br>
if session is not NULL you MUST switch_core_session_rwunlock(session)
before you exit your function.<br>
<br>
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?<br>
<br>
<div class="gmail_quote">On Mon, Feb 2, 2009 at 6:02 AM,
Apostolos
Pantsiopoulos <span dir="ltr"><<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Anthony,<br>
<br>
I need your help in clarifying something.<br>
<br>
I my module load function I am using this to bind a handler to a
specific event (channel create) :<br>
<br>
if (switch_event_bind(modname, SWITCH_EVENT_CHANNEL_CREATE,
SWITCH_EVENT_SUBCLASS_ANY, my_on_create_handler, NULL) !=
SWITCH_STATUS_SUCCESS) {<br>
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR,
"Couldn't bind!\n");<br>
return SWITCH_STATUS_GENERR;<br>
}<br>
<br>
Then in my my_on_create_handler routine I have :<br>
<br>
static void my_on_create_handler(switch_event_t *event) {<br>
<br>
char* uuid = switch_event_get_header(event, "Unique-ID");<br>
<br>
switch_core_session_t *session;<br>
<br>
session = switch_core_session_locate(uuid);<br>
}<br>
<br>
this is only for test purposes. My handler does nothing else than
creating a pointer to the session that<br>
triggered the event. Everything compiles just fine. When I am running
freeswitch everything goes<br>
as expected (my handling routine is called and a session is indeed
returned on my local session variable) <br>
except from one thing : I can see doing a "ps -eLf" that the session
threads of my call get stuck and never get terminated.<br>
<br>
I can also tell that they are stuck by that error message in my console
:<br>
<br>
switch_core_session_hupall() Giving up with 42 sessions remaining<br>
<br>
which makes sense since I initiated 21 bridged calls.<br>
<br>
Is the reference (pointer) to the session the cause of all these? Does
FS considers that<br>
since there are still references to a session the session should not be
terminated? If yes,<br>
how can I destroy this reference (after I have used it)?
<div>
<div><br>
<br>
Anthony Minessale wrote:
<blockquote type="cite">No problem, I have the advantage
That I
have implemented
this technique all over the place ;)<br>
Your event handler is the recipient end of that same algorithm.<br>
<br>
In fact the events are a very good thing to pass into queues.<br>
<br>
You could clone the event and insert the clone into the queue and when
you pop it from the <br>
backend thread you can just destroy it there then.<br>
<br>
<br>
<br>
<div class="gmail_quote">On Fri, Jan 30, 2009 at 8:27
AM,
Apostolos
Pantsiopoulos <span dir="ltr"><<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Wow. I didn't
expect
so
much detailing :)<br>
<br>
Thanks for the idea.<br>
<br>
My implementation is different though, but yours seems to be better.<br>
<br>
I will conclude what I started doing now and get back to you with the
results.<br>
<br>
If something is wrong against my implementation I will try doing it
your way.<br>
<br>
Thanks again!<br>
<br>
Anthony Minessale wrote:
<blockquote type="cite">
<div>
<div>use a queue object to send the data in a
dynamic struct to
the other thread.<br>
<br>
1) create a global queue.<br>
2) create a struct with all the info you need to send.<br>
<br>
on the event handler.<br>
<br>
1) malloc a new struct of that type.<br>
2) memset it to all 0.<br>
3) populate the struct.<br>
4) write the data into the queue.<br>
<br>
launch a thread at startup that does a blocking wait on the same queue<br>
<br>
1) pop the void pointer off the queue.<br>
2) cast it into your struct.<br>
3) extract the data from the struct and send it over radius.<br>
4) destroy the struct with free and loop.<br>
<br>
<br>
<div class="gmail_quote">On Fri, Jan 30, 2009 at
5:14
AM,
Apostolos
Pantsiopoulos <span dir="ltr"><<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
I am tweaking the mod_radius_cdr module to archive the behavior<br>
that most NASes have (i.e. accounting packets are sent in a separate<br>
thread so that the submission does not interfere with the execution of<br>
the call). While doing that, however, I bumped into another behavior of<br>
the module that I think is not desirable (at least by me) :<br>
<br>
While on a bridge, the module sends one acct start packet at the<br>
beginning of the originating<br>
leg (on_routing event handler) and two acct stop packets at the end of<br>
each leg<br>
(inbound and outbound). My opinion is that it should send one accounting<br>
start<br>
packet at the beginning of each call leg (inbound, outbound) resulting<br>
to a total<br>
number of two acct start packets. It is generally accepted that acct<br>
start/stop packets<br>
come in pairs so that billing applications can handle them accordingly.<br>
<br>
Some NAS's radius radius implementations have some other<br>
configuration modes<br>
like the Cisco's RADIUS Packet Suppression. When in this mode the Cisco
NAS<br>
sends only an accounting start/stop pair at the end of a final dialpeer<br>
attempt (and suppresses<br>
all the previous failed dialpeer attempts) thus resulting to less<br>
network traffic. Other<br>
NASes (such as MERA MVTS) can send a start/stop pair for each leg OR a<br>
start/stop<br>
pair for each end to end call, depending on the configuration. Opensips<br>
follows<br>
the star/stop pair by call leg paradigm. No matter what the<br>
implementation, all of them<br>
always send a acct start/stop pair. This is a common thing. And all the<br>
billing platforms<br>
can deal only with paired start/stops.<br>
<br>
The current module behavior (one start two stops) can complicate<br>
things since the<br>
radius server would not know how to match the second stop packet with<br>
its equivalent start.<br>
<br>
Before I get the infamous answer "pathes welcomed" I would like to<br>
state that I am<br>
already involved in changing this behavior (through a patch). So my real<br>
question is this :<br>
<br>
I noticed that the module uses the switch_core_add_state_handler<br>
function to register<br>
its handler table :<br>
<br>
switch_core_add_state_handler(&state_handlers);<br>
<br>
So the on_routing ( or the on_execute) event happens only when the<br>
inbound call is started.<br>
When the outbound call is initiated no handler is available to hook up a<br>
function and<br>
send the proper acct start packet.<br>
<br>
Should the module register its handlers using the<br>
switch_channel_add_state_handler() function instead?<br>
And if yes, how could the module pass the channel as a parameter to the<br>
function since channels<br>
are created and destroyed dynamically (and the module when initialized<br>
does not have that info).<br>
<br>
I would greatly appreciate your help in pinpointing a proper way to<br>
call my event handling<br>
routines on a per call leg basis.<br>
<br>
<br>
--<br>
-------------------------------------------<br>
Apostolos Pantsiopoulos<br>
Kinetix Tele.com R & D<br>
email: <a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a><br>
-------------------------------------------<br>
<br>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="http://iax:guest@conference.freeswitch.org/888" target="_blank">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br>
</div>
</div>
<pre><hr size="4" width="90%"><div>
_______________________________________________
Freeswitch-dev mailing list
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</div></pre>
</blockquote>
<div><br>
<br>
<pre cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>
------------------------------------------- </pre>
</div>
</div>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="http://iax:guest@conference.freeswitch.org/888" target="_blank">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-dev mailing list
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>
------------------------------------------- </pre>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="http://iax:guest@conference.freeswitch.org/888" target="_blank">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-dev mailing list
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="http://iax:guest@conference.freeswitch.org/888" target="_blank">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br>
</div>
</div>
<pre><hr size="4" width="90%"><div>
_______________________________________________
Freeswitch-dev mailing list
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</div></pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="http://iax:guest@conference.freeswitch.org/888" target="_blank">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-dev mailing list
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>
------------------------------------------- </pre>
<pre><hr size="4" width="90%">
_______________________________________________
Freeswitch-dev mailing list
<a href="mailto:Freeswitch-dev@lists.freeswitch.org" target="_blank">Freeswitch-dev@lists.freeswitch.org</a>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>
------------------------------------------- </pre>
</div></div></div>
<br>_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>