Skip to main content
If your organization runs its own PBX or a contact-center platform, you can connect it the same way you’d connect any SIP trunk — no number porting required. Start with SIP provider guides for the shared mechanism (the platform SIP FQDN, the exact DID, and inbound authentication); this page covers what’s specific to six PBX and contact-center platforms, including a few things that look broken but are expected.
3CX’s Generic SIP Trunk (IP Based) connection type is only available on StartUP PRO and self-managed/Dedicated instances — the entry StartUP tier doesn’t expose it.
  1. Create a Generic SIP Trunk in 3CX with IP-based authentication, not SIP registration.
  2. Point it at the platform SIP FQDN, set the trunk transport to TCP (UDP fragments large INVITEs), and restrict codecs to PCMA/PCMU with RFC2833 DTMF — disable Opus and G.722.
  3. Set the trunk’s From: Display-Name and Remote-Party-ID to OriginatorCallerID so the assistant sees the real caller, not 3CX’s own system number.
  4. Configure inbound in two parts: an outbound rule with a distinct prefix (for example 999) routed to the trunk, and an inbound rule that dials 999<number> back through that same outbound rule.
  5. Assign the DID on the platform side and test.
3CX trunk Options tab with Transport Protocol set to TCP and SRTP Mode disabled

Set the trunk's transport protocol to TCP

3CX trunk Caller ID Options with From: Display Name and Remote Party ID - Calling Party: Display Name both set to OriginatorCallerID

Pass through the real caller ID with OriginatorCallerID

The outbound rule alone delivers nothing on its own. The pairing in step 4 — an outbound rule plus a matching inbound rule dialing through it — is what actually routes an inbound call to the assistant. Skipping it is the most common cause of “trunk configured, calls never arrive.”
Configure a static, non-registering trunk in both directions — Asterisk never sends the platform a SIP REGISTER, and the platform never expects one.

​
FreePBX (GUI)

Add a generic SIP trunk pointed at the platform SIP FQDN and disable registration. Restrict codecs to PCMA/PCMU. If Asterisk sits behind NAT, set the external media and signaling addresses and the local network range so RTP negotiates correctly, and forward the RTP port range at the firewall.

​
Raw config (pjsip.conf)

The sample uses whatever transport your Asterisk install already defines. If you name your transports explicitly, add a matching transport= line to the endpoint — the platform SIP URI advertises TCP by default.If calls connect but drop at exactly 30 seconds, the endpoint is missing a re-INVITE across NAT. direct_media=no and rewrite_contact=yes (already in the sample above) fix it.
Connect Starface with a host/IP-based SIP line, not SIP REGISTER — the line will show not registered in Starface’s status view afterward. That’s expected, not a fault.
  1. Create the SIP line as host/IP-based, pointed at the platform SIP FQDN, and assign the number.
  2. Enable CLIP No Screening so the real caller ID passes through instead of the trunk’s own number.
  3. For time-based routing to the assistant, use a line-prefix dial string such as **<line-digit>*<number>.
  4. If audio is one-way or missing, set Behind NAT? yes on both the Starface server and the line.
Never use ordinary PSTN call forwarding from the assistant to transfer a call on Starface — it creates a call loop between Starface and the platform. Configure every assistant transfer on a Starface trunk as a SIP transfer instead.
Connect the platform as an external trunk under BYOC Carrier.
  1. Create the trunk with inbound (the FQDN Genesys Cloud generates) and outbound (pointed at the platform SIP FQDN) configured as separate legs.
  2. Open the non-standard ports at your firewall — TCP/UDP 32681 and TLS 32682 — instead of the usual 5060/5061. A firewall that only opens the standard ports fails silently.
  3. Order codecs PCMU then PCMA, and remove G.722.
  4. Restrict SIP Access Control to only the platform’s current signaling addresses.
Never set SIP Access Control to Allow All. An open trunk is typically found and used for toll fraud within hours.
Provisioning the platform as an external SIP destination on a Five9 SBC is an enterprise-only integration.
  1. Open a support ticket with Five9 — there’s no self-service path.
  2. Set codecs to G.711 only (no Opus/G.722).
  3. Configure human transfers with SIP REFER — Five9 doesn’t honor SIP 302 redirects.
  4. Target a fully-qualified URI for every REFER (sip:queue@sbc-{region}.five9.com); a bare extension is silently dropped.
Five9 hard-drops any call at exactly 12 hours, regardless of activity. Account for this ceiling in long-running flows and unattended campaign calls — there is no way to extend it from the platform side.
Aircall has no wholesale SIP trunk. SIP Forwarding (Enterprise plan only) covers inbound only — it delivers calls to the platform, but Aircall has no SIP path for sending a call back out with an Aircall number as caller ID. To use one number in both directions, port it to a SIP-capable carrier for outbound (see SIP provider guides) while keeping Aircall for inbound. Aircall also doesn’t support SIP REFER — a transfer should place a fresh outbound call rather than attempt a cold SIP transfer.

​
Validate the setup

Call the DID from an external phone and confirm a new inbound record in History, the assigned assistant, and two-way audio. For platforms with a distinct outbound leg (3CX, Asterisk, Genesys Cloud), place one outbound test call too — an inbound success doesn’t confirm outbound is configured correctly, and vice versa. See also SIP provider guides, BYO SIP trunk, and Other and custom SIP providers. Sources: 3CX SIP trunks, Asterisk documentation, Starface knowledge base, Genesys BYOC Cloud, Five9 documentation, Aircall support. Accessed 22 August 2026.