Making a Windows only version of Freeswitch doesn't make sense, especially a .NET only version. Freeswitch already provides great Windows and .NET support running either on or off Windows which is something that most other open source telephony applications do not have. And having the freedom to build it on Windows or Linux is a huge advantage and convenience. Having said that it would be interesting to see what you have done source code wise. but I'm afraid that you are dismissing the importance of one of Freeswitch's best features and I cringe at the direction you are taking. Being a Windows developer 90% of the time myself I do get embarrassed by Windows developer's OS arrogance sometimes and I see why so many Linux people only produce Linux based open source software. John From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Chad Vogel Subject: [Freeswitch-users] Feedback Hello, I wanted to reach out and get some feedback from everyone because my company started a project using FS as base several weeks ago, our goal was to optimize and integrate FS more directly into Windows environments. Here is my question, we would like to share our changes and where should we host our project? Because we understand our build breaks compatibility with the UNIX environments and fails to meet the objectives cross platform compatibility, however it could contribute greatly and be beneficial to other windows users. Here are some of the changes we have made: * We converted FS core to C++ and having it compiling to .NET 4.0 CLI * FS now runs inside its own namespace * We replace FS_CLI with a PowerShell shell app * Supports SQL Server support via the Native SQL Server Client API * Support for windows clustering (up to 32 node active/active cluster) * Ties more directly into the Win32 API and has less reliance on open source Libs * Replaces OpenSSL sockets with Windows encrypted sockets * Added windows performance monitoring * No longer need to use mod_managed for managed modules * Memory management relies on .Net garbage collection * Added support for Microsoft Speech * VoiceXML 3.0 and SCXML support * No longer supports JS, LUA, PHP development - Modules can be only developed in .NET, C or C++( we feel support for other languages can be added back in but falls outside the scope of our objectives at this time, support for SCXML should make limit the need for other scripting languages) * Fixed RTP clock timing issues in virtualized environments * New configuration file format using .Net App Configuration files (kind of looks like an IIS config file)