SIP Profiles & Trunking
In FreeSWITCH, a SIP Profile defines a listening entity. It tells FreeSWITCH which IP addresses and ports to bind to, what network settings to apply, and how to handle SIP signaling and RTP media for the connections it receives.
The configuration for these profiles is located in the conf/sip_profiles/ directory.
Internal vs. External Profiles
By default, FreeSWITCH uses a dual-profile architecture to maintain a strict security boundary between internal and external traffic.
1. The Internal Profile (internal.xml)
- Default Port:
5060 - Purpose: Handles traffic within your network.
- Usage in rdv.ai: We primarily use this profile for registering internal softphones during local testing or for WebRTC connections. It requires devices to authenticate using a username and password (defined in
conf/directory/).
2. The External Profile (external.xml & external/)
- Default Port:
5080 - Purpose: Handles public, outbound traffic and incoming calls from your SIP Trunk providers.
- Usage in rdv.ai: This is the most critical profile for production. It does not challenge incoming calls for a password, but instead relies on Access Control Lists (ACLs) to ensure traffic is only accepted from trusted provider IPs.
Configuring SIP Trunks (Gateways)
To connect Rendez-vous.ai to the public telephone network (PSTN), we configure “Gateways” within the external SIP profile. A gateway tells FreeSWITCH how to route outbound calls to a provider and how to register to receive inbound calls.
Our repository includes pre-configured XML files for our supported providers inside conf/sip_profiles/external/.
Twilio (twilio.xml)
Twilio is our primary provider for scalable enterprise deployments.
- Authentication: Instead of using a traditional username/password registration, we utilize Twilio’s IP Access Control Lists.
- Inbound Routing: In the Twilio Console, you configure your SIP Trunk’s Origination URI to point directly to your public FreeSWITCH IP (e.g.,
sip:your-ip-address:5080). - Security: We use FreeSWITCH ACLs (
conf/autoload_configs/acl.conf.xml) to explicitly whitelist Twilio’s signaling IPs, dropping any unauthorized SIP traffic immediately.
VoIP.ms (voipms.xml)
VoIP.ms is an excellent, cost-effective alternative, often preferred by smaller clients or for localized numbers.
- Authentication: VoIP.ms requires active SIP Registration.
- Configuration: The
voipms.xmlgateway file is configured to send aREGISTERpacket to the VoIP.ms servers. When a call comes to your VoIP.ms DID, they route it down that registered tunnel.
Securing with Environment Variables
Hardcoding credentials in XML files is a massive security risk, especially in open-source or shared repositories.
Just like the API_HOST variable in our dialplans, all SIP credentials and IP addresses are injected via environment variables when the Docker container boots up.
<include>
<gateway name="voipms">
<param name="username" value="$${voipms_username}"/>
<param name="password" value="$${voipms_password}"/>
<param name="proxy" value="$${voipms_server}"/>
<param name="register" value="true"/>
<param name="context" value="public"/>
</gateway>
</include>By modifying your deployment environment variables, you can seamlessly switch between Twilio, VoIP.ms, or any other SIP provider without ever touching the FreeSWITCH XML source code.