FreeSWITCH Endpoint Modules: SIP, WebRTC, and More

Endpoint modules are the protocol drivers of FreeSWITCH. Each endpoint module is responsible for a specific signaling protocol — establishing, managing, and tearing down calls according to that protocol’s rules. When a call arrives over SIP, WebRTC, SCCP, or any other supported protocol, it is the corresponding endpoint module that translates the protocol-level events into FreeSWITCH’s internal call model, where the dialplan and application modules take over. Without at least one endpoint module loaded, FreeSWITCH cannot send or receive external calls.

mod_sofia is the most widely deployed endpoint module and is required for all SIP-based telephony. The vast majority of FreeSWITCH deployments use mod_sofia as their primary — or only — endpoint.

Available Endpoint Modules

mod_sofia

The primary SIP endpoint, built on the Sofia-SIP stack. Handles SIP/SDP, registration, gateways, presence, and SRTP.

mod_verto

WebRTC endpoint using a JSON-RPC-over-WebSocket protocol. Enables browser-based real-time communication without plugins.

mod_loopback

A virtual endpoint that routes calls back through the FreeSWITCH dialplan. Used for IVR chaining, park orbits, and context bridging.

mod_skinny

Implements Cisco’s SCCP (Skinny Client Control Protocol) for connecting Cisco IP phones and gateways directly to FreeSWITCH.

mod_rtmp

RTMP (Real-Time Messaging Protocol) endpoint for media exchange with Flash/RTMP-compatible streaming media clients.

mod_rtc

Internal RTC endpoint module used for real-time communication bridging within FreeSWITCH. Located at src/mod/endpoints/mod_rtc/.

mod_h323

H.323 protocol support via the OpenH323/OPAL library. Enables interoperability with legacy H.323 endpoints and gatekeepers.

mod_opal

Multi-protocol endpoint via the OPAL library (H.323, IAX2, and others). An alternative to mod_h323 for broader OPAL-based protocol support.

mod_reference

A skeleton/reference endpoint module for developers. Demonstrates the minimum structure required to build a new endpoint.

mod_alsa

ALSA (Advanced Linux Sound Architecture) endpoint for local sound card access. Used for softphone-style direct audio I/O.

mod_sofia

mod_sofia is the SIP endpoint for FreeSWITCH and is the most critical module in nearly every deployment. It is built on top of the Sofia-SIP library — a production-grade, RFC-compliant SIP stack — and handles all aspects of SIP call signaling: INVITE/BYE/OPTIONS/REGISTER transactions, SDP negotiation, DTMF (RFC 2833 and INFO), presence/NOTIFY, and outbound gateway registration.

SIP Profiles

The core organizational unit in mod_sofia is the SIP profile. Each profile is an independent SIP User Agent (UA) bound to a specific IP address and port. The vanilla configuration ships with three profiles defined under conf/sip_profiles/:

Profile	Port	Purpose
`internal`	5060	Authenticated SIP clients (phones, softphones) on trusted networks
`external`	5080	Unauthenticated SIP trunks, carriers, and peering
`internal-ipv6`	5060	Same as `internal` but bound to an IPv6 address

Each profile XML file is included by sofia.conf.xml via a pre-processor directive:

<!-- conf/autoload_configs/sofia.conf.xml -->
<configuration name="sofia.conf" description="sofia Endpoint">
  <global_settings>
    <param name="log-level" value="0"/>
    <param name="debug-presence" value="0"/>
  </global_settings>
  <profiles>
    <X-PRE-PROCESS cmd="include" data="../sip_profiles/*.xml"/>
  </profiles>
</configuration>

SIP Profile Configuration

A typical internal SIP profile binds to the local IPv4 address on port 5060, uses the public dialplan context for unauthenticated inbound calls, and references the global codec preference list:

<!-- conf/sip_profiles/internal.xml (excerpt) -->
<profile name="internal">
  <gateways>
    <!-- Outbound SIP trunk registrations go here -->
  </gateways>

  <domains>
    <domain name="all" alias="true" parse="false"/>
  </domains>

  <settings>
    <param name="context" value="public"/>
    <param name="sip-port" value="$${internal_sip_port}"/>
    <param name="dialplan" value="XML"/>
    <param name="sip-ip" value="$${local_ip_v4}"/>
    <param name="rtp-ip" value="$${local_ip_v4}"/>
    <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/>
    <param name="outbound-codec-prefs" value="$${global_codec_prefs}"/>
    <param name="apply-nat-acl" value="nat.auto"/>
    <param name="rfc2833-pt" value="101"/>
  </settings>
</profile>

Key Features

Registration — End-user SIP phones register to mod_sofia just as they would to any SIP registrar. Registrations are stored in FreeSWITCH’s internal database and can be queried with sofia status profile internal reg.
Outbound Gateways — A <gateway> block within a profile configures FreeSWITCH to register as a SIP client to an upstream carrier or PBX, enabling outbound PSTN calls.
Presence & BLF — sofia_presence.c implements SIP SUBSCRIBE/NOTIFY for busy lamp field (BLF) and message waiting indication (MWI).
SRTP / TLS — mod_sofia supports SIP over TLS and encrypted RTP (SRTP) via SDES or DTLS-SRTP for secure calls.
NAT Traversal — Built-in NAT handling via apply-nat-acl, aggressive NAT detection, and support for STUN.

Managing mod_sofia at Runtime

# List all profiles and their status
sofia status

# Reload a profile without restarting FreeSWITCH
sofia profile internal rescan

# Flush all registrations on a profile
sofia profile internal flush_inbound_reg

# Show active registrations
sofia status profile internal reg

mod_verto

mod_verto is FreeSWITCH’s native WebRTC endpoint. Instead of SIP, it uses a custom JSON-RPC protocol over a persistent WebSocket connection, making it straightforward to integrate into browser-based applications using the verto.js JavaScript client library.

How It Works

When a browser client loads verto.js and calls $.verto.connect(), it opens a WebSocket connection to the FreeSWITCH server on port 8081 (by default). All call signaling is exchanged as JSON objects over this socket. Media is handled via standard WebRTC (DTLS-SRTP, ICE, and BUNDLE), meaning the browser and FreeSWITCH negotiate and exchange audio/video tracks directly.

Configuration

mod_verto is configured in conf/autoload_configs/verto.conf.xml:

<configuration name="verto.conf" description="HTML5 Verto Endpoint">
  <profiles>
    <profile name="default">
      <param name="bind-local" value="$${local_ip_v4}:8081"/>
      <!-- ... TLS, STUN, and codec settings ... -->
    </profile>
  </profiles>
</configuration>

Key Features

No SIP required — Verto clients bypass SIP entirely; signaling is pure JSON over WebSocket.
Full WebRTC support — ICE candidate exchange, DTLS-SRTP, and VP8/H.264 video are all supported.
Authentication — Verto uses a login/password scheme tied to the FreeSWITCH user directory.
Conferencing integration — mod_verto pairs tightly with mod_conference for browser-based multi-party video conferencing.

mod_loopback

mod_loopback provides a virtual endpoint that routes a call back through the FreeSWITCH dialplan. Unlike real endpoints (which communicate with external devices), loopback calls stay entirely inside FreeSWITCH — the A-leg enters the dialplan in one context and re-emerges in another.

Common Use Cases

Voicemail via bridge — Bridging to loopback/app=voicemail:default ${domain} ${ext} lets the dialplan cleanly hand off to voicemail without a separate transfer.
IVR chaining — Route a call through multiple dialplan contexts in sequence by bridging each context as a loopback leg.
Park orbits — Park a call on a loopback extension so it can be retrieved from any context.

Dialplan Example

<!-- Bridge to a loopback that re-enters the dialplan in the 'features' context -->
<action application="bridge" data="loopback/1000/features"/>

<!-- Loopback to the voicemail application -->
<action application="bridge"
  data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>

The loopback dial string format is loopback/<destination>/<context> or loopback/app=<application>:<args>.

mod_skinny

mod_skinny implements Cisco’s SCCP (Skinny Client Control Protocol), which is used by a large installed base of Cisco IP phones (7900 series and similar). FreeSWITCH acts as a Cisco Unified Communications Manager (CUCM) replacement for these devices, registering phones, handling button presses, and providing dial tone.

Configuration

Skinny is configured in conf/autoload_configs/skinny.conf.xml with a server profile that sets the listening IP and port (default TCP 2000):

<configuration name="skinny.conf" description="Skinny Endpoint">
  <profiles>
    <profile name="internal">
      <param name="ip" value="$${local_ip_v4}"/>
      <param name="port" value="2000"/>
      <param name="dialplan" value="XML"/>
      <param name="context" value="default"/>
    </profile>
  </profiles>
</configuration>

Dialplan calls to Skinny endpoints use the skinny/ prefix:

<action application="bridge" data="skinny/internal/${destination_number}"/>

mod_h323

mod_h323 provides H.323 protocol support through the OPAL/OpenH323 library. It allows FreeSWITCH to interoperate with legacy H.323 endpoints such as older video conferencing systems, H.323 gatekeepers, and VoIP equipment that predates SIP’s dominance.

mod_h323 requires the OPAL library at compile time. It is not built by default in most binary distributions. For new deployments requiring H.323 interoperability, consider using a SIP-H.323 gateway instead.

mod_reference

mod_reference is a developer-facing skeleton endpoint module located at src/mod/endpoints/mod_reference/. It implements the minimum required callbacks (switch_io_routines) and module lifecycle hooks without any real protocol logic. It serves as a starting template when writing a new custom endpoint for FreeSWITCH.

mod_rtc

mod_rtc is an internal RTC endpoint located at src/mod/endpoints/mod_rtc/mod_rtc.c. It provides a real-time communication endpoint interface within FreeSWITCH for use cases that require low-level RTC channel handling outside of the full mod_verto or mod_sofia stacks.

mod_opal

mod_opal provides multi-protocol endpoint support via the OPAL library, located at src/mod/endpoints/mod_opal/. OPAL supports H.323, IAX2, and other VoIP protocols, making mod_opal an alternative to mod_h323 for deployments that need broader OPAL-based protocol interoperability.

mod_opal requires the OPAL library at compile time and is not built by default in most binary distributions. For new H.323 deployments, evaluate both mod_opal and mod_h323 — or consider using a SIP-H.323 gateway instead.

Getting Started

Core Concepts

Configuration

Modules

Event Socket Layer

Operations

FreeSWITCH Endpoint Modules: SIP, WebRTC, and More

Available Endpoint Modules

mod_sofia

mod_verto

mod_loopback

mod_skinny

mod_rtmp

mod_rtc

mod_h323

mod_opal

mod_reference

mod_alsa

mod_sofia

SIP Profiles

SIP Profile Configuration

Key Features

Managing mod_sofia at Runtime

mod_verto

How It Works

Configuration

Key Features

mod_loopback

Common Use Cases

Dialplan Example

mod_skinny

Configuration

mod_h323

mod_reference

mod_rtc

mod_opal

Build docs developers (and LLMs) love

Getting Started

Core Concepts

Configuration

Modules

Event Socket Layer

Operations

Documentation Index

​Available Endpoint Modules

mod_sofia

mod_verto

mod_loopback

mod_skinny

mod_rtmp

mod_rtc

mod_h323

mod_opal

mod_reference

mod_alsa

​mod_sofia

​SIP Profiles

​SIP Profile Configuration

​Key Features

​Managing mod_sofia at Runtime

​mod_verto

​How It Works

​Configuration

​Key Features

​mod_loopback

​Common Use Cases

​Dialplan Example

​mod_skinny

​Configuration

​mod_h323

​mod_reference

​mod_rtc

​mod_opal

Build docs developers (and LLMs) love

Available Endpoint Modules

mod_sofia

SIP Profiles

SIP Profile Configuration

Key Features

Managing mod_sofia at Runtime

mod_verto

How It Works

Configuration

Key Features

mod_loopback

Common Use Cases

Dialplan Example

mod_skinny

Configuration

mod_h323

mod_reference

mod_rtc

mod_opal