# Service failover and load balancing The DIDWW network is redundant by design, with multiple Points of Presence (PoPs), redundant SBCs, and multi-homed IP transit. DIDWW also provides two mechanisms that improve resilience against failures on the customer side, such as an unreachable SIP endpoint, a PBX outage, or a network issue between DIDWW and your infrastructure. **DNS SRV** provides multiple SIP destinations behind one Static Endpoint trunk. A **Trunk Group** distributes calls between separate SIP or PSTN trunks and can move a call to another trunk when the configured re-routing conditions apply. Use either mechanism independently or combine them. For example, a Trunk Group can contain a SIP trunk whose host resolves to multiple DNS SRV targets. Both mechanisms apply while DIDWW is establishing the call. They do not move an already established call to another destination. ## DIDWW network redundancy Service stability starts inside the DIDWW network. The platform is a globally distributed, multi-layered system engineered for high availability, so that no single device, link, carrier, or facility can take the service offline. The customer-side mechanisms described below, DNS SRV and Trunk Groups, complement this foundation by extending resilience to your endpoint. ### Geographically distributed Points of Presence DIDWW operates multiple [Points of Presence](../../../../presence/index.html#presence) across different continents. Each PoP is housed in a carrier-grade data center with redundant power, cooling, and network connectivity. Inbound traffic can be received and delivered from any PoP, so the loss of a single site does not interrupt service for the rest of the network. PSTN interconnections terminate at more than one PoP. If a PoP or interconnection becomes unreachable, traffic for the affected number ranges is automatically diverted to a healthy PoP without operator intervention. ``` %%{init: { "theme": "base", "themeVariables": { "fontSize": "14px", "primaryColor": "#e0f2fe", "primaryBorderColor": "#38bdf8", "primaryTextColor": "#1f2d3d", "secondaryColor": "#ccfbf1", "secondaryBorderColor": "#2dd4bf", "secondaryTextColor": "#1f2d3d", "tertiaryColor": "#fef3c7", "tertiaryBorderColor": "#facc15", "tertiaryTextColor": "#1f2d3d", "lineColor": "#0066cc", "textColor": "#1f2d3d", "nodeTextColor": "#1f2d3d", "titleColor": "#1f2d3d", "clusterBkg": "#f8fafc", "clusterBorder": "#cbd5e1", "edgeLabelBackground": "#ffffff" } }}%% flowchart LR subgraph CARRIERS ["PSTN"] C1["Carrier A"] C2["Carrier B"] end subgraph DIDWW ["DIDWW network"] FRA["PoP Frankfurt"] HK["PoP Hong Kong"] LAX["PoP Los Angeles"] end EP["Customer endpoint"] C1 ==> |"primary"| FRA C1 -. "failover" .-> HK C1 -. "failover" .-> LAX C2 ==> |"primary"| HK C2 -. "failover" .-> FRA C2 -. "failover" .-> LAX FRA --> EP HK --> EP LAX --> EP classDef endpoint fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px classDef process fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px class C1,C2,EP endpoint class FRA,HK,LAX process linkStyle default stroke:#0066cc,stroke-width:1.5px ``` ### Redundant SBCs at every PoP Inside each PoP, inbound traffic first reaches a redundant pair of SIP load balancers. They distribute calls across a pool of Session Border Controllers (SBCs) in active-active mode. Each SBC is reachable on its own signaling and RTP IP addresses. See [SIP connectivity reference](../sip-connectivity-reference.html#inbound-sip-connectivity-reference). A failed load balancer or SBC is automatically removed from rotation while its peers continue to handle calls. ``` %%{init: { "theme": "base", "themeVariables": { "fontSize": "14px", "primaryColor": "#e0f2fe", "primaryBorderColor": "#38bdf8", "primaryTextColor": "#1f2d3d", "secondaryColor": "#ccfbf1", "secondaryBorderColor": "#2dd4bf", "secondaryTextColor": "#1f2d3d", "tertiaryColor": "#fef3c7", "tertiaryBorderColor": "#facc15", "tertiaryTextColor": "#1f2d3d", "lineColor": "#0066cc", "textColor": "#1f2d3d", "nodeTextColor": "#1f2d3d", "titleColor": "#1f2d3d", "clusterBkg": "#f8fafc", "clusterBorder": "#cbd5e1", "edgeLabelBackground": "#ffffff" } }}%% flowchart LR PSTN["PSTN"] subgraph POP ["DIDWW PoP"] LB1["SIP load balancer 1"] LB2["SIP load balancer 2"] SBC1["SBC node 1"] SBC2["SBC node 2"] SBC3["SBC node 3"] LB1 --> SBC1 LB1 --> SBC2 LB1 --> SBC3 LB2 --> SBC1 LB2 --> SBC2 LB2 --> SBC3 end EP["Customer endpoint"] PSTN --> LB1 PSTN --> LB2 SBC1 --> EP SBC2 --> EP SBC3 --> EP classDef endpoint fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px classDef process fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px class PSTN,EP endpoint class LB1,LB2,SBC1,SBC2,SBC3 process linkStyle default stroke:#0066cc,stroke-width:1.5px ``` This architecture also enables zero-downtime upgrades. SBC and load balancer nodes are drained and updated one at a time, while the remaining nodes continue to carry production traffic. ### Resilient IP transit Each PoP is multi-homed across several IP transit providers with BGP-based failover, so the loss of any single upstream link does not affect signaling or media. In addition to commodity transit, DIDWW maintains [private interconnections and peering at major public Internet Exchanges](../../../../presence/index.html#network-interconnection), such as DE-CIX, AMS-IX, and Equinix IX. These shorter, dedicated paths reduce latency and jitter for SIP signaling and RTP, and provide an independent fallback path when commodity transit degrades. ### Continuous monitoring and 24/7 NOC Every platform component, including load balancers, SBCs, registrars, routing engines, and network devices, exposes detailed internal metrics and counters. DIDWW monitoring systems correlate these signals across the stack to detect anomalies and degradations early, often before they become visible to customers. Signaling reachability, call quality, registration state, and platform health are tracked in real time. A 24/7 Network Operations Center responds to alerts and coordinates with carrier partners on any upstream incident. Tip To take full advantage of this redundancy, set **Preferred Server** to **Auto** on your SIP trunks, allow all [DIDWW SIP signaling and RTP addresses](../sip-connectivity-reference.html#inbound-sip-connectivity-reference) on your firewall or SBC, and combine this with DNS SRV or Trunk Groups. ## DNS SRV failover and load balancing DNS SRV allows a Static Endpoint trunk to discover multiple SIP servers from one configured **Host**. The customer publishes the targets, ports, priorities, and weights in DNS. DIDWW uses those records when delivering the call. To use DNS SRV, leave **Port** empty under [Static Endpoint fields](../sip-trunk-settings-reference.html#inbound-sip-static-endpoint-fields). DIDWW queries the record that matches the selected [Transport](../sip-trunk-settings-reference.html#inbound-sip-transport-values): | SIP transport | DNS SRV record | | --- | --- | | UDP | `_sip._udp.` | | TCP | `_sip._tcp.` | | TLS | `_sip._tls.` | `` is the **Host** configured under the trunk's [Static Endpoint fields](../sip-trunk-settings-reference.html#inbound-sip-static-endpoint-fields). If DIDWW does not find an SRV record, it falls back to resolving the `A` and `AAAA` records and uses the default port `5060`. ### DNS SRV selection DIDWW prefers targets with lower SRV priority values. When multiple targets have the same priority, their weights control the relative likelihood of selection. This follows the priority and weight model defined by [**RFC 2782**](https://datatracker.ietf.org/doc/html/rfc2782.html). If delivery to the selected target does not complete, DIDWW can attempt another eligible SRV target. The following fields under [Signalling](../sip-trunk-settings-reference.html#inbound-sip-trunks-settings-signalling) affect the timing: - **DNS SRV Failover Timer** controls how long DIDWW waits before attempting the next SRV target. - **SIP Timer B** controls the overall `INVITE` transaction timeout. Align these timers with the response behavior of the receiving systems. Short values can end a slow but valid attempt, while long values increase caller wait time. See [Signalling](../sip-trunk-settings-reference.html#inbound-sip-trunks-settings-signalling) for the supported ranges and other SIP transaction settings. Important DNS SRV supplies routing information. It does not make an unavailable SIP service reachable. Keep every published target operational, maintain the DNS records, and allow DIDWW signaling and media traffic at each target. ## Trunk Group failover and load balancing An inbound [Trunk Group](../../trunk-groups/index.html) combines multiple SIP or PSTN trunks into one destination that can be [assigned to DID numbers](../../../../phone-numbers/my-numbers/how-to-guides/assign-voice-trunk.html#user-panel-assign-trunk). DIDWW evaluates member trunks by **Priority**. Lower values are preferred. When multiple eligible trunks have the same priority, **Weight** controls their relative likelihood of selection. Both fields are described under [Member trunk settings](../../trunk-groups/trunk-group-settings-reference.html#inbound-trunk-groups-settings-members). ``` %%{init: { "theme": "base", "themeVariables": { "fontSize": "14px", "primaryColor": "#e0f2fe", "primaryBorderColor": "#38bdf8", "primaryTextColor": "#1f2d3d", "secondaryColor": "#ccfbf1", "secondaryBorderColor": "#2dd4bf", "secondaryTextColor": "#1f2d3d", "tertiaryColor": "#fef3c7", "tertiaryBorderColor": "#facc15", "tertiaryTextColor": "#1f2d3d", "lineColor": "#0066cc", "textColor": "#1f2d3d", "nodeTextColor": "#1f2d3d", "edgeLabelBackground": "#ffffff" } }}%% flowchart LR CALLER["Incoming call"] GROUP["Trunk Group"] A["Trunk A
Primary"] B["Trunk B
Primary"] C["Trunk C
Backup"] CALLER --> GROUP GROUP --> |"Priority 1, Weight 60"| A GROUP --> |"Priority 1, Weight 40"| B A -. "re-route" .-> GROUP B -. "re-route" .-> GROUP GROUP --> |"Priority 2 (failover)"| C classDef endpoint fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px classDef process fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px classDef backup fill:#fef3c7,stroke:#facc15,color:#1f2d3d,stroke-width:1.5px class CALLER endpoint class GROUP,A,B process class C backup linkStyle default stroke:#0066cc,stroke-width:1.5px ``` | Objective | Member configuration | Result | | --- | --- | --- | | Primary and backup routing | Assign the primary trunk a lower **Priority** than the backup trunk. | DIDWW prefers the primary trunk and can use the backup when the call is eligible for re-routing. | | Load balancing | Assign the same **Priority** to multiple trunks and configure their **Weight** values. | DIDWW distributes selection among those trunks. Higher weights increase relative selection likelihood. | | Load balancing with failover | Create multiple priority tiers and place equal-priority trunks within each tier. | DIDWW distributes calls within the preferred tier and can continue to a later tier when re-routing applies. | ### Endpoint availability and retry logic The presence of another member trunk does not cause every unsuccessful call to be retried automatically. DIDWW sends a new `INVITE` to another eligible trunk only after the current attempt ends with an outcome that permits re-routing. The following settings determine whether another destination is eligible: - **Re-routing Disconnect Codes**, described under [Member trunk settings](../../trunk-groups/trunk-group-settings-reference.html#inbound-trunk-groups-settings-members), define the SIP failure responses that allow DIDWW to attempt another eligible trunk in the group. A response that is not selected does not trigger another member. - **Ringing Timeout**, described in the [SIP trunk Signalling fields](../sip-trunk-settings-reference.html#inbound-sip-trunks-settings-signalling) and [PSTN trunk General fields](../../pstn-trunks/pstn-trunk-settings-reference.html#inbound-pstn-trunks-settings-general), ends an attempt when the destination sends an `18x` response but does not answer with `200 OK` within the configured time. - A member trunk's **Capacity Limit**, described in the [SIP trunk General fields](../sip-trunk-settings-reference.html#inbound-sip-trunks-settings-general) and [PSTN trunk General fields](../../pstn-trunks/pstn-trunk-settings-reference.html#inbound-pstn-trunks-settings-general), restricts simultaneous calls on that trunk. When the limit is reached, another eligible member can be selected. - The Trunk Group **Capacity Limit**, described under [General](../../trunk-groups/trunk-group-settings-reference.html#inbound-trunk-groups-settings-general), restricts simultaneous calls across the entire group. Calls exceeding the group limit are rejected rather than sent to another member. The exact behavior therefore depends on the received SIP response, the member trunk settings, and the remaining eligible destinations. See the [Trunk Group settings reference](../../trunk-groups/trunk-group-settings-reference.html) for field limits and default values. ## Routing attempts and call detail records DNS SRV failover is transparent to [Inbound Call Logs](../../../../logs-analytics/call-logs/inbound-logs.html#inbound-cdr-logs). DIDWW produces one Call Detail Record regardless of how many SRV targets it tries. Trunk Group re-routing works differently. DIDWW generates a separate Call Detail Record for each attempt to deliver the call to a member trunk. Review all records when investigating the final outcome of a re-routed call. In [Inbound Call Logs](../../../../logs-analytics/call-logs/inbound-logs.html#inbound-cdr-logs), the **Attempt** column shows the attempt number for each record. [Voice IN CDR Streaming](../../../../call-events/did-cdr.html#voice-in-cdr-streaming-attributes) includes the following attributes for correlating Trunk Group attempts: | Attribute | Type | Example | Description | | --- | --- | --- | --- | | `routing_attempt` | Integer | `1` | Sequential attempt number. The first attempt is `1`, and each later attempt increments the value. | | `is_last_cdr` | Boolean | `true` | Indicates whether the record represents the final routing attempt. When the value is `true`, DIDWW made no later attempt. | ## Related resources - [Trunk Groups](../../trunk-groups/index.html) - Understand priority, weight, capacity, and re-routing across trunks. - [SIP routing methods](../sip-routing-methods.html) - Compare Static Endpoint and Dynamic Registration routing. - [Configure Preferred Server routing](../how-to-guides/configure-preferred-server-routing.html) - Configure the DIDWW Points of Presence available for inbound delivery. - [Number List load balancing](../../number-lists/use-cases/use-number-lists-for-load-balancing.html#inbound-number-lists-load-balancing) - Route calls to different trunks according to the incoming caller ID. - [Inbound Call Logs](../../../../logs-analytics/call-logs/inbound-logs.html#inbound-cdr-logs) - Review individual routing attempts and their SIP responses. - [CDR Streaming attributes](../../../../call-events/did-cdr.html#voice-in-cdr-streaming-attributes) - Review the complete event and Call Detail Record field reference. On this page