Both FreeSWITCH and Asterisk are open-source telephony frameworks for SIP calling, IVR, call routing, and media processing. Asterisk uses a thread-per-call model, while FreeSWITCH Solutions use an event-driven architecture that efficiently handles thousands of concurrent sessions. For smaller deployments, either platform works well, but businesses needing high scalability often choose a FreeSWITCH Telecom Solution.

ESL (Event Socket Library) is FreeSWITCH's primary interface for external application control — a TCP socket protocol that allows programs written in Python, Node.js, Go, PHP or any other language to connect to a running FreeSWITCH instance and control calls in real time. In inbound mode, FreeSWITCH connects to your application when a call arrives and your application tells FreeSWITCH what to do with it — play this audio, capture DTMF, bridge to this number, transfer to this queue. In outbound mode, your application connects to FreeSWITCH to initiate calls, manage campaigns and process events. ESL is significantly more powerful than Asterisk's AGI because it gives your application full event visibility into every call event in real time across the entire FreeSWITCH instance, not just the calls your application is handling. For Indian CPaaS builders and contact centre platform developers, ESL is what makes FreeSWITCH a programmable media platform rather than just a PBX.

FreeSWITCH has two primary WebRTC gateway mechanisms. The first is mod_sofia with WebRTC support: standard SIP over WebSocket (WSS) transport with DTLS-SRTP media, which allows browser-based SIP clients to connect using standard SIP signalling over a WebSocket connection. The second is mod_verto: FreeSWITCH's own JSON-RPC over WebSocket protocol, with a dedicated JavaScript client library that handles the WebRTC signalling from the browser. When a WebRTC user initiates a call, FreeSWITCH terminates the WSS connection, performs the media codec translation (WebRTC mandates Opus; PSTN trunks typically use G.711), and bridges the call to the appropriate Indian SIP trunk (Airtel, Jio, TATA Comm). The Indian carrier receives a standard SIP INVITE; the WebRTC participant hears the PSTN audio through the browser. For Indian CPaaS builders using FreeSWITCH as a WebRTC gateway, the critical configuration is the media IP reachability from Indian mobile networks and the DTLS certificate management for WSS termination.

FreeSWITCH connects to Indian SIP trunk providers (Airtel Business SIP, Jio Business, TATA Communications, Exotel, Ozonetel) through mod_sofia — specifically through Sofia SIP gateway definitions in the conf/sip_profiles directory. Each Indian carrier has specific configuration requirements: Airtel requires G.711 alaw codec preference and specific SIP header handling for CLI presentation; Jio Business requires SIP REGISTER with a 60-second interval and specific NAT traversal settings (Jio's NAT behaviour differs from Airtel's); TATA Communications supports both G.711 and G.729 but requires specific DTMF mode (RFC 2833); Exotel and Ozonetel support standard SIP but have specific registration and keepalive requirements. ACL (Access Control List) configuration in FreeSWITCH must whitelist carrier IP ranges to prevent SIP scanning attacks, which are a primary toll fraud vector on publicly accessible FreeSWITCH instances. We verify that every listed provider has successfully integrated with the specific Indian carriers you plan to use, as carrier-specific configuration knowledge is not transferable from US or EU carrier experience.

Running FreeSWITCH at 5,000+ concurrent sessions in production requires specific Linux kernel and server tuning that goes beyond the default installation. Key tuning areas include: increasing the system file descriptor limit (ulimit -n should be set to 999999 or higher); tuning kernel network buffer sizes (net.core.rmem_max, net.core.wmem_max) for high UDP media throughput; disabling CPU power management to prevent frequency scaling under load; configuring NUMA awareness if using multi-socket servers; tuning the FreeSWITCH thread pool (core-db-pre-fork threads) for the expected session concurrency; and configuring RTP port ranges adequately for concurrent media streams. On cloud infrastructure (AWS Mumbai, Azure Central India), instance type selection is critical — network-optimised instance types (AWS c-series, Azure Fsv2) outperform general-purpose instances for high-concurrency media workloads. We ask providers to document their tuning configuration for production deployments at comparable session volumes as part of vetting.

For CPaaS platforms and high-concurrency deployments in India, the choice between cloud and bare-metal involves a trade-off between elasticity and raw performance. Cloud (AWS Mumbai, Azure Central India) offers rapid capacity scaling — spin up additional FreeSWITCH nodes during peak load and terminate them afterwards — but virtual machine networking adds latency and CPU overhead that becomes significant above 10,000 concurrent sessions. Bare-metal (physical servers in Indian datacentres such as Nxtra/Airtel, NTT India, CtrlS Hyderabad or Web Werks Mumbai) gives maximum media performance because the CPU is not shared with other tenants and NIC hardware can be used for media offloading — but capacity scaling requires advance provisioning. For platforms below 5,000 concurrent sessions, AWS Mumbai c6i.xlarge or c6i.2xlarge instances provide excellent price-performance. Above 10,000 sessions, bare-metal in Indian datacentres with high-speed uplinks to Indian carrier PoPs typically delivers better media quality and lower per-session cost. Hybrid architectures (bare-metal core with cloud burst capacity) are increasingly common for Indian CPaaS deployments above 20,000 sessions.