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 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. 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, 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 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. DIDWW queries the record that matches the selected Transport:

SIP transport	DNS SRV record
UDP	_sip._udp.<customer.domain>
TCP	_sip._tcp.<customer.domain>
TLS	_sip._tls.<customer.domain>

<customer.domain> is the Host configured under the trunk’s 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.

If delivery to the selected target does not complete, DIDWW can attempt another eligible SRV target. The following fields under 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 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 combines multiple SIP or PSTN trunks into one destination that can be assigned to DID numbers. 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.

        %%{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<br/>Primary"]
    B["Trunk B<br/>Primary"]
    C["Trunk C<br/>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, 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 and PSTN trunk General fields, 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 and PSTN trunk General fields, 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, 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 for field limits and default values.

Routing attempts and call detail records

DNS SRV failover is transparent to Inbound Call 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, the Attempt column shows the attempt number for each record.

Voice IN CDR Streaming 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 — Understand priority, weight, capacity, and re-routing across trunks.

• SIP routing methods — Compare Static Endpoint and Dynamic Registration routing.

• Configure Preferred Server routing — Configure the DIDWW Points of Presence available for inbound delivery.

• Number List load balancing — Route calls to different trunks according to the incoming caller ID.

• Inbound Call Logs — Review individual routing attempts and their SIP responses.

• CDR Streaming attributes — Review the complete event and Call Detail Record field reference.