The philosophy underlying FS architecture lends itself perfectly to interface legacy, commercial, and proprietary hardware/software: FS output is very, very strict in its adherence to the letter of the standards (SIP and related RFCs), so it's able to make itself understood by whatever it's trying to communicate with, but it is also very, very flexible for what it accepts as an input, for example, core developers embedded into FS, all the quirks, and the workarounds, to let it accept the often non-standard (or plain wrong) "interpretation" and "extensions" of SIP standards that have been pushed on the market by the various generations of VoIP software and hardware providers (often with the "unintended" side effect of locking in their customers).

FS is built around mainstays of modern technology: XML, message queues, JSON, RPC, and standard libraries. Developers don't have to learn new ad hoc "languages" to fully exploit the power of FS: All of its configuration, dialplan, upstream and downstream endpoints and gateways — all of its features and behaviors are completely defined by XML standard documents that can also be created in real time dynamically by tried and true XML generating applications and languages. Given a basic knowledge of communication fundamentals, a wealth of pre-existing, in-house knowledge of structured information management can be reused.

All kinds of programming languages can be used to interact with FS. This is due to the fact that we're dealing with two main paradigms, XML and message queues (and also XML exchanged back and forth via message queues). All computer languages, both scripted and compiled ones, have very efficient, stable and performing ways to interact with XML structured information, from C to Basic, from Perl to PHP, Python to Lua, Erlang to C# to .NET, Java and all the others in between. Interacting with the message queues governing and reporting FS behavior is done through a simple API that is the same for all languages covered by SWIG: In each language you'll find the same "objects" with the same "methods" (or "functions") and "attributes" to interact with.

Different tasks are best performed by different devices, with different price points, power consumption, sets of hardware interfaces: From WRTG routers to Raspberry PIs (for example, for residential CPE, or as WiFi VoIP, or as a portable communication gizmo), from desktop PCs (as a personal or callcenter softphone) to multisocket multicore massive servers (capable of delivering high call per second origination and termination) and powerful DSP blades (for high capacity call transcoding, Text To Speech generation, Automatic Speech Recognition and media management). For all of those roles we can use the same FreeSWITCH software, that behaves and is managed in the same way.

Using the same foundation system library as the ubiquitous Apache Web Server, FS runs at full efficiency on Linux, Windows, FreeBSD and Solaris, on Xen, AWS, KVM, and VMWare. DevOps people often prefer to use their own deployed, stable, and known operating systems and managing tools.

Telcos, telecommunication companies, both the old Bells and the new CLECs or VMOs, are a fascinating patchwork of legacy, proprietary, in-house developed, partner-provided, stakeholder-imposed hardware and software. With all kinds of database engines (Oracle, DB2, SQL Server, SAP, MySQL, PostgreSQL, and so on), directory systems (LDAP, Active Directory), AAA mechanisms (Radius, Diameter, and so on), SIP and SS7 equipment (some of which nobody knows how to operate anymore, "so please don't touch it"), and many different functions and departments barely interacting with each other, there can be huge return time for even the smallest feature request or bug turnaround.

In a complex environment like this, FS can be introduced as universal filter and glue, allowing incompatible systems to communicate (as protocol translator and adapter), transcoding to and from all audio formats (ulaw to mp3 to High Definition Opus, Siren, Silk, etc), manipulating signaling and log generation for billing, accounting, tracking, charting, debugging purposes (additional and optional SIP packet headers injection and parsing, CDR generation, mediation, reconciliation, and so on), and database interfacing (native, odbc, REST, SQL, NoSQL, and so on).

FreeSWITCH is accepted into telco environments because of its known stability and "industrial grade" structure, and because it does not carry any "hobbyist" or "hackerish" fame.

Starting from resolving specific problems with "ad hoc", Swiss army knife solutions, FreeSWITCH can then expand its internal reach to prototype new features and services, substitute unwieldy legacy systems (for example, IVRs, fax servers, and so on), and quickly become the poster boy of Sales and Marketing departments for quick implementation and flexibility, while gaining the Operations respect and love for its stability, performances, and manageability.

Standard, real programming languages give FreeSWITCH a fast pace of implementation for any kind of features and services: What is simple stays simple, and what is complex becomes possible, without crashes, instabilities, or performance bottlenecks.

Programming languages bring with them all their wealth of libraries, both standard, open source, commercial, and in-house developed. So, all kinds of objects, systems, procedures are within reach, both bleeding edge external services and internal, legacy, proprietary, prehistoric leftovers.

Real business logic can be crafted without compromises, accessing each call in real time, at the desired abstraction level, from the most abstracted down to the detail of the single SIP packet.

WebRTC will allow entire new classes of applications and services, using the ubiquitous web browser as a communication endpoint, while FS modules exist for managing any kind of content, from real-time broadcast to video, from conferencing to queuing calls and managing call center operators.

Click-to-Call, database interaction, SMS sending and receiving, website complementing and synergy, full CMR integration, marketing campaigns, media redemption analysis, dynamic real-time events, horizontal scalability via tried and true load-balancing, cloud leveraging—all that and much more is what FreeSWITCH can be used for to speed up the time to market and implement convergent media multi-pronged strategies.

A debugging session, seen from FreeSWITCH's remote console