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&#39;s destroyed.<br>The session thread has nothing better to do while it&#39;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">regs@kinetix.gr</a> <span dir="ltr">&lt;<a href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>&gt;</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&#39;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&#39;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>
&nbsp;<br>
<br>
Anthony Minessale wrote:
<blockquote type="cite"><div><div></div><div class="Wj3C7c">The session runs in it&#39;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&#39;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">&lt;<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>&gt;</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&#39;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&#39;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&#39;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">&lt;<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>&gt;</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>
&nbsp;&nbsp;&nbsp; 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,&nbsp; SWITCH_EVENT_CHANNEL_CREATE,
SWITCH_EVENT_SUBCLASS_ANY, my_on_create_handler, NULL) !=
SWITCH_STATUS_SUCCESS) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR,
&quot;Couldn&#39;t bind!\n&quot;);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return SWITCH_STATUS_GENERR;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
        <br>
Then in my my_on_create_handler routine&nbsp; I have :<br>
        <br>
static void my_on_create_handler(switch_event_t *event) {<br>
        <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; char* uuid = switch_event_get_header(event, &quot;Unique-ID&quot;);<br>
        <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; switch_core_session_t *session;<br>
        <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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 &quot;ps -eLf&quot; 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">&lt;<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>&gt;</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&#39;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">&lt;<a href="mailto:regs@kinetix.gr" target="_blank">regs@kinetix.gr</a>&gt;</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>
&nbsp; &nbsp;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>
&nbsp; &nbsp;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>
&nbsp; &nbsp;Some NAS&#39;s radius radius implementations have some other<br>
configuration modes<br>
like the Cisco&#39;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>
&nbsp; &nbsp;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>
&nbsp; &nbsp;Before I get the infamous answer &quot;pathes welcomed&quot; 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(&amp;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>
&nbsp; &nbsp;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>
&nbsp; &nbsp;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 &amp; 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 &amp; 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 &amp; 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 class="Ih2E3d">
_______________________________________________
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">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>