Why Intercom Call Routing Breaks at the Third Site
An intercom system that works flawlessly at one site keeps working when you add the second site. Most of the time. The pattern that emerges across a hundred multi-site integrators is that the third site is where the wheels come off — calls ring at the wrong console, hold transfers vanish, after-hours routing skips the assigned answering station and lands at the front desk that's been closed for four hours. The diagnostic noise that follows blames everything from the SIP server to the WAN router to the building IT team, and a senior specialist usually shows up three weeks in to find that the underlying architecture made an assumption that broke the moment the third site went live.
The Two-Site Trap
Two-site deployments hide architectural sins because SIP routing between exactly two points is symmetric. If A calls B, the call works. If B calls A, the call works. The routing table needs exactly one rule per direction, and the failover logic — if one site goes down, which site picks up the call — can be hardcoded. Most intercom platforms ship with default configurations that work fine for the two-site case and are subtly broken for three or more.
The first failure mode shows up when a call originates at site C and needs to ring at site A's primary console with site B as backup. The default routing logic assumes the originator and the destination are on the same SIP domain, which works for sites that share a head-end server but breaks when each site has its own local SIP gateway. The third-site call hits a routing table that doesn't have an explicit entry for cross-site routing and falls through to the default, which is usually "route to the nearest available console" — which is the originating site's own console, which is not where the call is supposed to go.
WAN Latency and SIP Timer Drift
The second failure mode is WAN latency. Two-site deployments on the same metro area network usually run sub-20ms round-trip between sites. A three-site deployment that adds a remote location 800 miles away introduces 60-90ms of WAN latency on the cross-site SIP signaling. SIP timers — particularly the T1 retransmission timer (default 500ms) and the timeout for INVITE responses (default 64 × T1, or 32 seconds) — assume LAN-class latency. They tolerate metro WAN. They start to drift at continental WAN.
The symptom is calls that ring at the destination station and the originator's display says "connecting..." for several seconds longer than the prior two-site deployment. Worse, hold-and-transfer operations that ride on the same SIP signaling path experience visible delays — a transfer that worked instantly in the two-site config takes 4-7 seconds in the three-site config. Users perceive the system as broken even when the call is technically completing successfully.
Quick Call Path Validation Worksheet
Walk this worksheet before adding any site to an existing multi-site intercom deployment. Each item maps to a configuration value or measurement.
| Step | What to Verify |
|---|---|
| 1. List all current call origination sites | Includes lobby stations, gate stations, parking stations, emergency call stations. |
| 2. List all current call destination consoles | Includes front desk, security operations center, after-hours answering service, mobile devices. |
| 3. Map originator-to-destination routing rules | For each origination point, every destination it could reach, plus the failover sequence. |
| 4. Measure round-trip latency to each remote site | Test from the local SIP gateway to each remote SIP gateway. Document the worst case. |
| 5. Verify SIP timer configuration matches WAN latency | T1 should be at least 2x the worst-case RTT. T2 should be at least 4x. |
| 6. Confirm presence/availability signaling works across sites | If a console is marked unavailable at site A, does site C see it within 30 seconds? |
| 7. Test failover under simulated WAN partition | Cut the WAN link to one site for 90 seconds. Does the call route to the configured backup? |
The Presence Signaling Gap
The third architectural assumption that breaks at the third site is presence signaling — how each site knows whether the destination consoles at the other sites are available, busy, or offline. In a two-site deployment, presence is often a manual configuration: site A's console list is hardcoded in site B's routing table, and updates happen on a schedule.
That works for two static sites. It fails when sites can swap their on-call answering station mid-shift, when a console goes offline for maintenance, or when after-hours routing rules need to know which site's overnight team is actually present. The fix is dynamic presence signaling — usually via the SIP REGISTER and SUBSCRIBE methods — which works fine inside a single SIP domain but requires explicit federation when each site is its own domain.
Working integrators handle this by either consolidating all sites under one SIP server (centralized model) or by configuring presence federation between site-local SIP servers (federated model). The centralized model is simpler but creates a single point of failure; the federated model is more resilient but more complex to configure. The right choice depends on the site's WAN reliability profile and the criticality of the intercom service. For deployments where the intercom is part of an emergency response chain — most healthcare, education, and high-security industrial sites — federation is the only acceptable answer.
Codec Mismatch Across Sites
The third silent failure is codec mismatch. Multi-site deployments often acquire site-specific codecs based on what was available at the time of each site's installation. Site A is on G.711, site B is on G.722, site C is on Opus. The SIP signaling can negotiate a common codec, but only if all sites' SIP gateways are configured to advertise the full codec list. If one site's gateway is locked to a single codec for security or compliance reasons, cross-site calls to that site fail to negotiate and either drop or fall back to a poor-quality codec.
The diagnostic for codec mismatch is the call audit log. Most SIP platforms log the negotiated codec for every completed call. Pull a week of call logs, count calls by codec, and look for the long-tail entries — a few calls a day completing on G.711 when the rest are on G.722 indicates either a codec mismatch with a remote site or a misconfigured local endpoint.
Designing for Multi-Site Resilience
The pattern that works for deployments past three sites is the hub-and-spoke architecture with explicit failover paths. One site — usually the security operations center — hosts the primary SIP server. The other sites host local SIP gateways that register with the primary and route locally when the primary is unreachable. Each site has at least two configured destination consoles: the local console (for direct in-building calls) and the remote console at the primary site (for routed calls).
Deployment takeaway: A multi-site intercom architecture that works at three sites will scale to ten. An architecture that works at two sites usually breaks at three. Validate against the worst-case three-site scenario before standing up the third site, not after.
Where This Fits in a Deployment Program
Multi-site intercom is one of the engineering disciplines where the design phase determines the failure modes of the entire deployment life. Two-site shortcuts written into the SIP routing tables get inherited as sites get added, and each subsequent addition tests an assumption that was never validated. By site six or seven, the cumulative drift between intended routing and actual routing is large enough that the platform's behavior surprises even the senior specialists who installed it.
The hardware choices in this space — emergency call stations, lobby intercoms, gate stations, and the back-end answering consoles — need to fit the federated routing model from the start. Code Blue emergency stations and Aiphone systems both support SIP federation in their current product lines, but the configuration is buried in advanced settings and is not enabled by default. The intercom and paging catalog filters by federation-capable models.
Monday morning, generate a call audit report for the past 30 days and group by route — originator site to destination console. Look for routes that completed at less than 95% success. Those are the routes where the architectural assumption broke; investigate each one with the validation worksheet above. The cumulative cost of unfixed multi-site routing problems is a system that's technically deployed but practically unreliable, and that's a deeper problem than any single config fix can solve.