<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You make it however you want. Marshal.StructureToPtr, AllocCoTaskMem;
GCHandle.Alloc/GetAddrOfPinnedObject; stackalloc (C#); Ref.pin (F#). You can get
it from unmanaged code (you could just P/Invoke malloc if you want). And I
think the SWIGTYPEs expose a GCHandle so you can get their pointer if you need
to convert their type.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If it’s a complex structure that swig hasn’t created,
and you really want nice typed access to it, you may want to create a nice struct
in C# for marshalling.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-Michael<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
freeswitch-users-bounces@lists.freeswitch.org
[mailto:freeswitch-users-bounces@lists.freeswitch.org] <b>On Behalf Of </b>Josh
Rivers<br>
<b>Sent:</b> Sunday, September 27, 2009 9:36 PM<br>
<b>To:</b> freeswitch-users@lists.freeswitch.org<br>
<b>Subject:</b> Re: [Freeswitch-users] Subscribing to events in managed C# /
.NET<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>Where does 'somePtr' come from?<o:p></o:p></p>
<div>
<p class=MsoNormal>On Sun, Sep 27, 2009 at 4:06 PM, Michael Giagnocavo <<a
href="mailto:mgg@giagnocavo.net">mgg@giagnocavo.net</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>It’s in the
“FSUtil” class (no I’m not happy with the name). I also made
it an extension method on IntPtr (I’m not a big fan of extension methods,
but the code is sorta messy anyways, so it’s not relatively bad.)</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>var x =
CreateSwigTypePointer<SWIGTYPE_p_int>(somePtr);</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>Moving stuff out of the SWIG
DLL removes the ability to use partial classes to extend the generated
swigtypes. This is used a bit, and will be used a lot more as the managed
plugin is cleaned up. For example, most of the FS APIs return string, when they
should return a better representation. Also, the constructors for some of the
types are internal only, and I don’t really enjoy using reflection to
create them. </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>-Michael</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:
10.0pt'> <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org"
target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a> [mailto:<a
href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>]
<b>On Behalf Of </b>Josh Rivers<br>
<b>Sent:</b> Saturday, September 26, 2009 11:29 PM</span><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal><br>
<b>To:</b> <a href="mailto:freeswitch-users@lists.freeswitch.org"
target="_blank">freeswitch-users@lists.freeswitch.org</a><br>
<b>Subject:</b> Re: [Freeswitch-users] Subscribing to events in managed C# /
.NET<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
<div>
<p>The ability to directly create swigtypes...that's huge! I'd love to see some
examples of how to use that.<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<p>I've update my refactoring to include the changes to the trunk up through
r14981. I've also checked in updated binaries that should work with the latest
trunk builds(I hope?)<o:p></o:p></p>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>A question occurred to me: would it make any sense to push the plugin loader
into a separate DLL? That way we could keep the P/Invoke layer very cleanly
separated from the loader/process host/abstraction layer structures.<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p style='margin-bottom:12.0pt'>Josh<o:p></o:p></p>
<div>
<p>On Fri, Sep 25, 2009 at 1:13 PM, Michael Giagnocavo <<a
href="mailto:mgg@giagnocavo.net" target="_blank">mgg@giagnocavo.net</a>>
wrote:<o:p></o:p></p>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>There is a new function I
checked in a little bit ago that lets you create any of the SWIGTYPE_p_xxx
types – all you need is a pointer to the memory to represent whatever it
is in native land. So with that, it’s actually possible to call most or
all of the functions. (Yes DRK, you can now go do XML binding.) But sure,
it’d be nice to make a real .NET-ish layer. </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>Async events seems like it
wouldn’t be hard, assuming FreeSWITCH delivers them that way?</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'>-Michael</span><o:p></o:p></p>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:
10.0pt'> <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org"
target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a> [mailto:<a
href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>]
<b>On Behalf Of </b>Michael Jerris<br>
<b>Sent:</b> Thursday, September 24, 2009 10:26 PM</span><o:p></o:p></p>
<div>
<div>
<p><br>
<b>To:</b> <a href="mailto:freeswitch-users@lists.freeswitch.org"
target="_blank">freeswitch-users@lists.freeswitch.org</a><br>
<b>Subject:</b> Re: [Freeswitch-users] Subscribing to events in managed C# /
.NET<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
<p>There are a few other things I can think would be nice additions to
mod_managed. Maybe an event handler that does not require a thread to be sitting
and waiting for events trying in a loop would be nice, instead something that
is triggered each time there is a certain event class triggered. Also,
there has been some interest in doing full endpoint modules in mod_managed.
exposing all the state handlers in .net like ways and having that all
work would be quite interesting, but probably requires someone specific
actually ready to write a module like that to be worthwhile.<o:p></o:p></p>
<div>
<p> <o:p></o:p></p>
</div>
<div>
<p>Mike<o:p></o:p></p>
</div>
<div>
<p> <o:p></o:p></p>
<div>
<div>
<p>On Sep 24, 2009, at 4:01 AM, Michael Giagnocavo wrote:<o:p></o:p></p>
</div>
<p style='margin-bottom:12.0pt'> <o:p></o:p></p>
<div>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>Great – hopefully
we’ll meet on IRC or the conference sometime on Friday. Email me when
you’re on.</span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>A few questions I have:</span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>Clarity – I agree with
you there, and thanks!</span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>Testability – is this
even remotely practical? Looking at our FS code plugins, there’s simply
no way any amount of test environment code would get us to anything testable.
We make tons of direct P/Invoke calls, and the whole model for what variables
are set when, the state machine progression, etc. does not seem like something
that we can hope to possibly model right. And it’s subject to many
external influences (all the modules you have loaded in FS). Logging is a
pretty simple case, sure, we can make it not call FS for testing. But in a real
app, it just seems that there are way too many dependencies, no? Maybe others
who have apps written can chime in?</span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>Modularity – I agree
there are two parts. But, I think they are pretty tightly coupled. The FS
interface into unmanaged code is done via unmanaged code and is really clear:
App, Api, ApiBackground. The other ways I can think of are FS-specific, such as
XML binding interface and so on. But those are things we should just add to the
mod_managed core and be done with. I’m thinking maybe we are talking
about different things? Can you provide some user stories that we want to cover
with a pluggable loader/executor/etc.? Thanks for putting up with me!</span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>-Michael</span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial'>
<div>
<p><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:
10.0pt'> <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org"
target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a> [mailto:<a
href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>] <b>On
Behalf Of </b>Josh Rivers<br>
<b>Sent:</b> Thursday, September 24, 2009 12:32 AM<br>
<b>To:</b> <a href="mailto:freeswitch-users@lists.freeswitch.org"
target="_blank">freeswitch-users@lists.freeswitch.org</a><br>
<b>Subject:</b> Re: [Freeswitch-users] Subscribing to events in managed C#
/ .NET</span><o:p></o:p></p>
</div>
</div>
<div>
<p> <o:p></o:p></p>
</div>
<p style='margin-bottom:12.0pt'> <o:p></o:p></p>
<div>
<div>
<p>On Wed, Sep 23, 2009 at 7:31 PM, Michael Giagnocavo <<a
href="mailto:mgg@giagnocavo.net" target="_blank">mgg@giagnocavo.net</a>>
wrote:<o:p></o:p></p>
</div>
<div>
<div>
<p><span style='font-size:11.5pt;color:#1F497D'>Right off the bat: there can be
tons of cleanup and refactoring, no doubt about that. Much of the current code
is to satisfy my needs in production, which it does very well.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>The current base doesn't have anything wrong with it for sure, in fact, I
learned a good bit about PInvoke. AppDomains, and In-Process Remoting in the
last week.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>My refactoring had the following goals (in no particular order)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> - Testability - I'd really like to see a decent unit test suite
on the more module so that we can change it with confidence. Also, it's been
drilled into me that a testable design is a good design.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> - Clarity - Where possible, I extracted blocks of code that served a
particular purpose so that purpose could be self-documenting in the method
calls rather than mixed in.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> - Modularity - I wanted to make it easy to remove or add alternative
behavior to the managed.dll.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span style='font-size:11.5pt;color:#1F497D'>I’m a bit hesitant to go
too far from the FreeSWITCH core as far as architecture goes. For instance,
I’m not quite sure why’d we have our own managed logging subsystem
that allows them to plug in other things that aren’t part of FS. Either
they should use the FS logging system, or use their own such as log4net. Or
perhaps I don’t see why we’d want this behavior.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p>I completely agree, with the following caveats:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>1) I'd like to see things testable. It's very hard to do isolation testing
with classes making direct calls out to a static Log class that in turn
pinvokes out to unmanaged code.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>2) I'd like to allow folk to make changes to the default behavior
(optimally) without recompiling managed.dll.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>One thing at issue here is that there are two principal purposes for
managed.dll. The first is to provide an interface into unmanaged code. The
second is a module/plugin extensibility framework. The first purpose should
absolutely provide the thinnest layer possible. The second purpose is very
likely to need a lot of change and adaptation as people come up with
development models that they would like to follow in using freeswitch. The
extensibility framework should be mostly managed code, coded to interfaces for
mock-ability and testabiliy. It should also be able to just push it out of the
way and hook your own extensibilty framework in instead.<o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'> Going away from the core
as far as adding .NET specific features (like look at the static
ManagedSession.Originate that takes hangup delegates, or the “nice”
wrapper for Log (Write and WeiteLine, with an enum instead of a string) are
keeping close to the core, just adding a tiny bit of API cleanup. FreeSWITCH
exposes a lot of strings, and while maybe that’s important for some
languages, .NET users are going to expect stronger typing. But I don’t
think these types of things get people away from FreeSWITCH much.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p>No disagreement here. I would like to see these things made available by
interface rather than concrete implementation. It's currently not possible to
test a plugin without loading it into FS. That precludes automated testing, and
leaves a pretty big round-trip to test a tweak. I'm a sloppy coder too, so I'm
always introducing interesting regressions, and that's why I like doing my
testing without having to bring up a full process :)<o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>Things like making a published
SOAP interface for FS seem not really related to mod_managed. They can easily
be done as 3<sup>rd</sup> party plugins, or convince the core FS team that
exposing via SOAP via mod_managed is the way to go. Also keep in mind that the
majority of users are on Linux, so that rules out WCF and some other fun stuff
that only works on the CLR – I’d say it all has to work on Mono.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p>This kind of stuff is definitely beyond the scope of mod_managed. Although
there is a slippery slope since we're building in an extensibility model.
I don't think a WCF host, or a winforms host, or any of that should be baked
in. Rather, I think we should provide the hooks for adding such a thing. If
somebody wants to build ESL via WCF, why should they need to leave managed
code? If the module system is general enough, then such a thing should just be
a module.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>(BTW, I think WCF-Mono is getting there <a
href="http://www.mono-project.com/WCF_Development" target="_blank">http://www.mono-project.com/WCF_Development</a>)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>Absolutely, everything in mod_managed and managed.dll should run on mono and
the CLR. However, there shouldn't be any reason that a Win-only developer can't
build a complete FS application framework that plugs in and only runs on
Windows.<o:p></o:p></p>
</div>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;
border-width:initial;border-color:initial'>
<div>
<div>
<p><span style='font-size:11.0pt;color:#1F497D'>As for all the rest of it, can
we talk interactively, perhaps with other users interested in mod_managed?
Reading over your email, I think I’m not understanding many of the use
cases that are being fixed.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p>I'd be very glad to get a discussion going. I definitely haven't covered all
of the issues here.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p>-Josh<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p><span style='font-size:13.5pt'>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a
href="http://lists.freeswitch.org/mailman/options/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a></span><o:p></o:p></p>
</div>
</div>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a
href="http://lists.freeswitch.org/mailman/options/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><o:p></o:p></p>
</div>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a
href="http://lists.freeswitch.org/mailman/options/freeswitch-users"
target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>