Telephony & FreeSWITCH Overview

The rdv.ai-FreeSWITCH repository contains the configuration and containerization logic for our custom VoIP PBX (Private Branch Exchange). It is the backbone of the voice AI offering, bridging traditional telephone networks with our modern Node.js AI backend.

Why FreeSWITCH?

In our earlier architecture, Rendez-vous.ai relied primarily on Twilio Media Streams to handle audio. While functional, it locked the platform into a single vendor.

To achieve provider agnosticism, we migrated the media handling layer to FreeSWITCH. By owning the SIP (Session Initiation Protocol) and RTP (Real-time Transport Protocol) engine, Rendez-vous.ai can now securely plug into any provider that offers standard SIP Trunking.

Currently, we maintain native support and profiles for two primary providers:

• Twilio
• VoIP.ms

Role in the Ecosystem

FreeSWITCH acts as a highly optimized traffic controller and media server:

1. SIP Termination: It registers with our SIP providers and receives incoming calls from the public telephone network.
2. Dialplan Execution: It evaluates the incoming number (caller ID and destination) and executes a set of XML-based instructions.
3. Webhook Triggering: It makes HTTP requests to the Core API (rdv.ai-API), asking for instructions on what to do with the call (e.g., answer, reject, transfer).
4. Media Bridging: Once the API instructs FreeSWITCH to answer, FreeSWITCH strips the SIP signaling and streams the raw RTP audio data directly to the Core API’s WebSockets for the LLM to process.
5. Recording: FreeSWITCH handles the lossless recording of the entire interaction, which is later uploaded to S3 by the Core API.

Directory Structure

If you are exploring the rdv.ai-FreeSWITCH repository, the most critical modifications happen within the conf/ directory. This is where the XML configuration files live.

• conf/sip_profiles/: Defines how FreeSWITCH communicates over the network.
  • external/: Contains the specific authentication and routing configurations for our SIP providers (twilio.xml, voipms.xml).
  • internal.xml: Configures internal routing (often used for WebRTC or local testing).
• conf/dialplan/: The routing logic. Think of dialplans as the “Express.js routers” of the telephony world.
  • public/: Handles inbound calls coming from the outside world (via the external SIP profile). This is where calls hit before triggering the API webhooks.
  • default/: Handles internal extensions and routing.
• conf/autoload_configs/: The modules that FreeSWITCH loads on startup. We disable unnecessary modules here to keep the container lightweight and secure.
• Dockerfile & entrypoint.sh: We use a custom Debian-based image to compile and run FreeSWITCH, injecting our configurations via volume mounts or copy commands during the build phase.

The API_HOST Bridge

Because FreeSWITCH needs to know exactly where the Core API is located to send webhooks and audio streams, it relies heavily on environment variables injected at runtime.

As mentioned in the Getting Started guide, the API_HOST variable tells FreeSWITCH where to route calls. In production, this points to the internal Kubernetes service DNS (http://service.api.svc.cluster.local:3000). During local development, you modify the Kubernetes secret to point to your public ngrok tunnel.