Connect two Dromlik systems
Last updated: 2026-08-22
If your organisation runs two Dromlik systems — for example one at headquarters and one at a branch office, or two systems that must stay separate for billing or organisational reasons — you can interconnect them so they behave like one phone network. Once connected, users dial each other by extension number across both systems, and either system can optionally place outbound calls through the other system's trunks.
How it works
The interconnection uses a dedicated site-to-site trunk between the two systems. One system takes the headquarters (HQ) role and generates a connection; the other takes the branch role and joins using the details HQ provides. After the trunk is up:
- Extension-to-extension calling — a user on system A dials a short prefix plus the extension number to reach a user on system B, free of charge.
- Shared outbound routes — the branch can send its external calls out through HQ's trunks (useful when only HQ has SIP trunks), or vice versa.
- Presence and directory — each system keeps its own users and settings; nothing is merged. The interconnection only carries calls.
Before you begin
- Administrator access to both Dromlik systems.
- Both systems must be reachable over the network. If one system is behind NAT without a public address, configure port forwarding or an SBC — see the network tools guides for diagnosing connectivity.
- Non-overlapping extension numbers. The two systems must use different extension ranges (for example 1xx at HQ and 2xx at the branch). Overlapping numbers make routing ambiguous.
- Decide which system is HQ and which is the branch. HQ initiates the connection.
Step 1 — Create the interconnection on the HQ system
- 1
Open the interconnection settings
Sign in to the HQ system's admin console and go to Integrations → Connect two Dromlik systems (under Extensions and Trunks → Site interconnection on some versions).
- 2
Choose the Headquarters role
Select Headquarters and click Add interconnection.
- 3
Name the connection and set the dial plan
Give the connection a name (e.g. Stockholm office) and choose the dial prefix users on this system will dial to reach the branch — for example
8, so dialling8201rings extension 201 at the branch. - 4
Note the connection details
Save. The HQ system displays the interconnection address, port, and authentication credentials the branch needs. Keep these somewhere safe — you'll enter them on the branch system next.
Step 2 — Join from the branch system
- 1
Open the same settings page on the branch
Sign in to the branch system's admin console and open the interconnection settings.
- 2
Choose the Branch role
Select Branch, then enter the HQ system's interconnection address, port, and credentials from step 1.
- 3
Set the return dial plan
Choose the prefix branch users dial to reach HQ extensions — for example
7, so7101rings extension 101 at HQ. - 4
Save and check the status
Save. Within a few seconds the trunk status should show Connected / Registered on both systems.
Step 3 — (Optional) Share outbound trunks
To let branch users place external calls through HQ's trunks, create an outbound route on the branch system whose destination is the interconnection trunk, and a matching inbound route on HQ that sends those calls out through the chosen SIP trunk. Restrict by dial pattern so only intended number ranges are allowed.
Network requirements
| Traffic | Default port | Direction |
|---|---|---|
| SIP signalling | 5060 (UDP/TCP) or 5061 (TLS) | Branch → HQ |
| RTP audio | 10000–12000 (UDP) | Both directions |
If HQ has a dynamic public IP, use a DDNS hostname as the interconnection address. For tighter security, restrict the interconnection port on HQ's firewall to the branch's public IP, and prefer TLS with SRTP so signalling and audio are encrypted.
Troubleshooting
Status stays "Unreachable" or "Register failed". Check the credentials and address first, then verify the branch can reach HQ's SIP port — see the IP Ping tool and packet capture guides.
Calls connect but audio is missing or one-way. Almost always a NAT or RTP port issue — confirm the RTP range is forwarded/open on both sides.
Dialling the prefix reaches the wrong extension. The two systems have overlapping extension numbers — renumber one system's range.