FusionPBX calls the connection to a SIP service a gateway. An extension is a different object for an internal phone. This guide follows the official FusionPBX Gateways and Dialplan documentation; menus may vary with your installed release. It assumes an existing working FusionPBX installation, not a fresh server installation or a replacement of its security configuration.
Before you begin
This walkthrough uses an IllyVoIP line with password authentication. In SIP Lines, obtain the SIP username, SIP password, server, destination port and transport for your connection. Do not use your Portal email or login password. If the existing line uses IP authentication, do not switch it without checking the devices that depend on it.
You need administrator access to the PBX, a private configuration backup and a working internal extension for testing. An IllyVoIP SIP line connects the PBX to IllyVoIP; an extension connects a staff phone to the PBX. They are not the same account.
Start with one test extension and a destination you control. Do not move the whole office to the new trunk immediately. If the PBX already carries calls, keep the existing route available until the test is complete.
1. Select the correct domain before adding the gateway
On a multi-tenant PBX, first check the domain you are administering. A working gateway in the wrong domain is still the wrong setup. Decide which account should own it, which extensions may use it and whether any existing routes already match your test number. Do not make the gateway global just to avoid a domain-selection problem.
Open Accounts → Gateways and add a gateway with a recognizable name. Enter the SIP details and enable registration for this password-based connection.
| Field | Value to use |
|---|---|
| Gateway | A unique local name, such as illyvoip-office |
| Username / Password | SIP username and SIP password |
| Proxy | IllyVoIP SIP server, with required port where applicable |
| Register / Enabled | true for this registration-based setup |
| Register Transport | The transport required for the connection |
| Domain / Profile | The intended tenant and enabled SIP profile; not arbitrary defaults |
2. Understand the profile and context
The gateway runs within a SIP profile. Use the correct enabled profile for your installation and keep external incoming traffic in the intended public/incoming context, not an internal dial-out context. The advanced Hostname field can pin a gateway to one PBX node; it is not another name for the SIP Proxy field. Leave it unset unless your cluster design deliberately uses it.
Save the gateway and inspect its registration state in the SIP status tools. Do not restart a whole SIP profile with active calls merely to refresh one gateway. Use the administrator’s supported gateway-management procedure and confirm the result before moving to routing.
3. Create the outgoing route
Open Dialplan → Outbound Routes, choose the intended gateway and define the number expression that should match. Start with a narrow test destination. Check route order and any transformation of the captured number before the gateway receives it. A gateway can be registered while the dialplan sends every call somewhere else.
Write down both the number the extension dials and the number that should leave the PBX. If the expression captures only part of the number, ensure that the bridge action uses the correct captured value. Do not paste a North American example into a worldwide route and assume every country will match.
4. Add an incoming destination
Use Dialplan → Destinations to add the intended incoming number/identifier, domain and destination action. This tool can create the corresponding inbound route. Start with one known extension or ring group. Confirm the identifier delivered by your connection before choosing the match; do not assume an incoming number always arrives with the same plus-sign formatting as the Portal display.
Keep tenant ownership and inbound source controls intact. A destination match tells the PBX where to send a call; it does not prove that the source is authorized. Avoid broad access-control entries and a global destination as quick fixes for one tenant’s problem.
5. Follow the call through the PBX
For outgoing failures, check the extension’s domain, route expression and selected gateway. For incoming failures, check whether the call reaches the PBX, whether it enters the expected context, and which destination matches. If one extension works and another does not, compare permissions and domain membership before changing the shared gateway.
When a call uses an unexpected gateway, examine the call details with an administrator and compare the selected bridge/gateway with the intended route. Do not add another duplicate gateway to solve a route-order error. Keep the working first test as a baseline, then expand the dial patterns one deliberate change at a time.
Audio, caller ID and security
SIP transport and media encryption are separate settings. Match the Portal line’s audio mode to the PBX; Standard RTP, SDES-SRTP and DTLS-SRTP are not interchangeable. Avoid changing transport, codecs and network settings together, because you then lose track of which change fixed or broke the connection.
Use only an outgoing caller ID permitted by your account. Typing a number into the PBX does not verify it. Do not allow anonymous inbound traffic to reach public outbound routes, and do not disable your firewall. If source-IP restrictions are needed, obtain the current permitted addresses for your connection from Support rather than guessing an allowlist.
Acceptance checklist before staff use
- Check trunk registration separately from the test phone’s extension registration.
- Place a call from the chosen extension and confirm which trunk the PBX used. Check balance and rates first; this may be a chargeable test.
- Check two-way audio and the number presented to the recipient. Test keypad digits against a telephone menu you are authorized to use.
- For incoming calls, route an active IllyVoIP number to the PBX SIP line, call it externally and verify the destination inside the PBX.
- Confirm an extension without permission cannot use the test route. Expand staff access only after these checks.
Record the time, timezone, test extension, selected route and public call reference. If something fails, send these details and the PBX model/version to Support. The SIP response-code guide helps describe the failure. Do not post passwords or unredacted logs in public forums.
This guide is based on official documentation and the Portal workflow, not a claim that every PBX version has been tested through a real call. Emergency services and specialist equipment require separate configuration and verification.