VoIP.info Guide

FreeSWITCH SIP profiles and gateways

Separate listener policy, user identity and provider registration in the Sofia configuration model.

Reviewed 2026-09-07FreeSWITCH 1.11.3 release reference; verify installed modules and package supportIntermediateDocumentation based · not lab tested

A profile is a SIP boundary

mod_sofia uses SIP profiles with their own listener and behavior settings. The familiar internal and external profile names come from supplied configurations; the names alone do not enforce a security boundary. Inspect bind addresses, ports, authentication, context and media address settings. A user in the directory supplies identity and related properties. A gateway represents a named external SIP relationship, optionally including registration. Neither creating a user nor defining a gateway automatically creates the correct dialplan permissions.

FreeSWITCH configuration has distinct responsibilities
A SIP profile defines a listener and transport behavior, the directory supplies user identity, and the dialplan selects actions. Media modules execute the application path. FusionPBX manages configuration above FreeSWITCH.

Conceptual responsibilities, not a file-loading sequence. FusionPBX is an administration layer; edits to generated configuration can be replaced by its management workflow.

Build one provider relationship

Use the provider's actual proxy, realm, identity and registration requirements. An IP-authenticated relationship may not register at all. Keep authentication identity, From identity and called destination separate; providers can apply different rules to each. Confirm the gateway belongs to the intended active profile. Then inspect its state and make a controlled outbound call using a restricted route. Validate inbound trust and routing separately. A registration success is not evidence that inbound calls have been assigned to the right destination.

Apply changes with awareness of state

Different settings require different reload or profile operations. Do not assume reloading XML changes every live listener or existing call. Read the installed version's command help and document whether a planned operation disrupts registrations or active sessions. For a NAT problem, compare configured advertised signaling and media addresses with the actual trace. For an authentication problem, inspect the challenge and identity. Keep each diagnosis at its own boundary before changing profile-wide settings that affect many tenants or trunks.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.