Resolving SIP 408 Request Timeout Errors During High-Concurrency Genesys Cloud Trunk Failover

How-To-Articles
1

Resolving SIP 408 Request Timeout Errors During High-Concurrency Genesys Cloud Trunk Failover

What This Guide Covers

Configure Genesys Cloud trunk routing rules, partner SBC transaction timers, and DNS edge resolution to eliminate SIP 408 Request Timeout errors when primary telephony paths degrade and traffic shifts to secondary trunks under high-concurrency conditions. The end result is a deterministic failover path with aligned SIP transport settings, optimized DNS TTL values, and explicit edge routing parameters that maintain call setup success rates above 99.9 percent during trunk switchover events.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 1, 2, 3, or 4 with Telephony (SIP Trunk or Cloud Calling add-on)
  • Permissions: Telephony > Trunk > Edit, Telephony > Trunk > View, Telephony > Routing Rule > Edit, Telephony > SBC > Edit (if managing Genesys-provided SBCs)
  • OAuth Scopes: telephony:trunk:write, telephony:trunk:read, telephony:routingrule:write, telephony:routingrule:read
  • External Dependencies: Partner SBC platform (Audiocodes MP116/125, Ribbon C100/C200, Cisco VCS, or Genesys Edge), DNS provider supporting SRV/AAAA records with health-aware load balancing, carrier PSTN circuits with published concurrency limits and rate control thresholds

The Implementation Deep-Dive

1. Align SIP Transaction Timers on the Partner SBC with Genesys Cloud Edge Expectations

Genesys Cloud Edge processes SIP INVITE transactions asynchronously during high-concurrency routing events. When a primary trunk experiences packet loss or carrier congestion, the SBC must maintain the SIP transaction state long enough for the Genesys Edge to evaluate routing rules, query the secondary trunk pool, and return a 100 Trying or 180 Ringing response. Default SBC timer configurations (T1=500ms, T2=4000ms, max retries=3) cause premature SIP 408 generation because the SBC abandons the transaction before the Genesys Edge completes its failover evaluation cycle.

Configure the SBC SIP timer parameters to match the following values:

  • T1 (Round Trip Time estimate): 1000ms
  • T2 (Maximum retransmission interval): 4000ms
  • T4 (Timer for non-SIP message delivery): 5000ms
  • SIP Transaction Timeout: 32000ms
  • Maximum SIP Retries: 4
  • INVITE Session Timer: 1800s (with refresh interval 60s)

Apply these settings at the SBC SIP signaling interface level, not per-trunk. Genesys Cloud Edge expects consistent timer behavior across all concurrent INVITEs. Inconsistent timer scopes cause the SBC to fragment transaction handling, which increases CPU utilization and delays routing decisions.

The Trap: Increasing T2 beyond 4000ms without implementing SBC dialog table limits causes memory exhaustion during failover. When the primary trunk degrades, all concurrent calls enter retry mode simultaneously. If T2 is set to 64000ms, the SBC retains thousands of half-open dialog states. The SBC eventually returns SIP 503 Service Unavailable instead of 408, which masks the original routing failure and prevents Genesys Cloud from triggering its built-in trunk health evaluation. Always pair timer increases with explicit dialog limits and call admission control thresholds.

Architectural Reasoning: Genesys Cloud Edge evaluates trunk health at the regional level. The Edge maintains a rolling window of SIP response codes, latency metrics, and packet loss percentages. When the primary trunk crosses the failure threshold, the Edge redirects subsequent INVITEs to the secondary trunk pool. This evaluation takes 1.2 to 2.5 seconds under normal load and up to 4 seconds during congestion. The SBC must wait within that window. Aligning T1 and T2 to RFC 3261 defaults with extended transaction timeouts ensures the SBC does not abandon the INVITE before the Edge completes routing. The SBC receives a 100 Trying response, which resets the retransmission timer and keeps the transaction alive until the secondary trunk answers.

Update trunk routing parameters via the Genesys Cloud API to enforce consistent timer expectations across all managed trunks:

PUT /api/v2/telephony/providers/edge/trunks/{trunkId}
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "name": "Primary-PSTN-Region-NA",
  "description": "Primary carrier trunk with aligned SIP timers",
  "trunk_type": "SIP_TRUNK",
  "status": "ACTIVE",
  "sip_settings": {
    "transport_protocol": "TCP",
    "sip_domain": "mypurecloud.com",
    "allow_external_ips": false,
    "keepalive_interval": 15,
    "transaction_timeout": 32
  },
  "failover_settings": {
    "failover_enabled": true,
    "failover_trunk_ids": ["secondary-trunk-id-1", "secondary-trunk-id-2"],
    "failover_threshold": 3,
    "failover_interval_seconds": 10
  }
}

The transaction_timeout field must match the SBC SIP Transaction Timeout value. Mismatched values cause the Genesys Edge to drop INVITEs that the SBC considers active, generating 408 responses at the application layer instead of the signaling layer.

2. Configure Deterministic Trunk Routing Rules with Explicit Failover Logic

Genesys Cloud trunk routing rules dictate how INVITEs traverse the telephony provider network. When a primary trunk degrades, the routing rule must immediately shift traffic to the secondary trunk without retrying the failed path. Retry logic on the Genesys Cloud side combined with SBC retransmission logic creates duplicate INVITE streams. Duplicate streams overwhelm the secondary trunk, trigger carrier rate limiting, and cause the SBC to return 408 when the secondary trunk cannot accept the burst.

Create a trunk routing rule with the following configuration:

  • Rule Name: High-Concurrency-Failover-Primary-to-Secondary
  • Match Condition: DID Range or Caller ID Prefix (select the exact traffic pattern)
  • Action: Route to Trunk
  • Primary Trunk: Primary-PSTN-Region-NA
  • Failover Trunk: Secondary-PSTN-Region-NA
  • Failover Trigger: SIP 408/404/403 on Primary
  • Retry Enabled: false
  • Concurrency Limit: 80% of carrier published capacity

Disable retry logic at the routing rule level. Genesys Cloud evaluates trunk health continuously. Enabling retry forces the platform to send additional INVITEs to a trunk that has already failed, which increases latency and delays failover. The secondary trunk should receive the call on the first routing evaluation after the primary trunk crosses the failure threshold.

The Trap: Setting the failover threshold to 1 failed attempt causes premature trunk switching during transient packet loss. A single SIP 408 or SIP 404 during routine network jitter triggers full failover, which routes all concurrent calls to the secondary trunk. The secondary trunk hits carrier concurrency limits, returns 408, and the SBC enters a retry loop. The system oscillates between trunks, generating repeated 408 errors and degrading call quality across the entire telephony fabric. Always use a threshold of 3 or more, combined with a 10-second evaluation interval.

Architectural Reasoning: Genesys Cloud Edge maintains per-trunk health scores based on SIP response codes, media path latency, and packet loss percentages. The health score decays exponentially when failures occur. A threshold of 3 ensures that transient network events do not trigger unnecessary failover. The 10-second interval allows the Edge to observe sustained degradation before shifting traffic. Disabling retry prevents duplicate INVITE generation. The SBC receives a single routing decision, which aligns with the SBC dialog state machine and prevents transaction table fragmentation.

Update routing rules via the Genesys Cloud API to enforce deterministic failover:

PUT /api/v2/telephony/routingrules/{routingRuleId}
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "name": "High-Concurrency-Failover-Primary-to-Secondary",
  "description": "Deterministic failover without retry to prevent thundering herd",
  "status": "ACTIVE",
  "priority": 1,
  "match_conditions": [
    {
      "field": "CALLER_ID",
      "operator": "STARTS_WITH",
      "value": "+1"
    }
  ],
  "action": {
    "type": "ROUTE_TO_TRUNK",
    "trunk_id": "primary-trunk-id",
    "failover_trunk_ids": ["secondary-trunk-id"],
    "retry_enabled": false,
    "failover_on_status_codes": [408, 404, 403, 503],
    "max_concurrency": 800
  }
}

The retry_enabled: false parameter is critical. It forces Genesys Cloud to evaluate trunk health once and route to the secondary trunk immediately upon failure. This eliminates duplicate INVITE generation and aligns with SBC transaction state expectations.

3. Optimize DNS SRV Resolution and Edge Path Selection for Failover

Genesys Cloud uses DNS SRV records to route SIP signaling to regional edge clusters. During trunk failover, DNS cache staleness causes the SBC to continue resolving degraded edge endpoints. The SBC sends INVITEs to an edge that has already marked the primary trunk as unhealthy. The edge returns 408 because it cannot process the routing request within the SBC timer window. DNS resolution delays compound the problem, as the SBC waits for DNS queries to complete before sending the INVITE, which consumes transaction timeout budget.

Configure the SBC DNS resolver with the following parameters:

  • DNS TTL Override: 60 seconds maximum
  • DNS Query Timeout: 2 seconds
  • DNS Retry Count: 2
  • SRV Record Load Balancing: Weighted by Genesys Cloud edge capacity
  • DNS Cache Pre-warming: Enabled for secondary edge IPs

Force the SBC to use explicit DNS resolvers that support health-aware load balancing. Standard round-robin DNS distributors ignore Genesys Cloud edge capacity limits. Weighted distribution ensures that the SBC resolves to the edge with available concurrency headroom during failover events.

The Trap: Setting DNS TTL to 300 seconds or higher causes the SBC to cache degraded edge IP addresses during trunk failover. When the primary trunk degrades, the SBC continues routing to the cached edge IP. The edge returns 408 because it cannot route to the primary trunk. The SBC waits for the DNS cache to expire, which extends the 408 window from seconds to minutes. High-concurrency environments experience cascading 408 errors across all active calls until the cache refreshes. Always enforce a 60-second maximum TTL for Genesys Cloud SIP domains.

Architectural Reasoning: Genesys Cloud Edge clusters operate independently per region. Each cluster maintains its own trunk health database and routing cache. DNS SRV records point to regional edge load balancers. When a trunk fails, the edge cluster updates its health database and shifts traffic to the secondary trunk. DNS cache staleness prevents the SBC from reaching the updated edge cluster. Short TTL values ensure rapid DNS convergence to healthy edge endpoints. DNS pre-warming maintains cached records for secondary edges, which eliminates resolution latency during failover. The SBC sends INVITEs immediately, preserving transaction timeout budget for actual routing evaluation.

Validate DNS resolution behavior using the Genesys Cloud Edge routing API:

GET /api/v2/telephony/providers/edge/routing/health
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "edge_cluster_id": "us-east-1-edge",
  "trunk_id": "primary-trunk-id",
  "health_status": "DEGRADED",
  "last_failure_code": 408,
  "failover_triggered": true,
  "secondary_edge_id": "us-west-2-edge",
  "dns_resolution_latency_ms": 45
}

The dns_resolution_latency_ms field indicates how long the edge waited for DNS resolution. Values above 200ms during failover correlate with increased 408 generation. Adjust DNS TTL and resolver settings to keep latency below 100ms.

4. Enforce Consistent SIP Transport Protocols and Keepalive Alignment

Genesys Cloud requires consistent SIP transport protocols across primary and secondary trunks. Mixing UDP and TCP during failover causes SBC state machine mismatches. The SBC tracks SIP transactions per transport session. When the primary trunk uses TCP and the secondary trunk uses UDP, the SBC creates separate transaction tables. During failover, the SBC must migrate transaction state between tables, which increases processing latency and triggers 408 responses before the secondary trunk answers.

Configure all trunks with identical transport settings:

  • Transport Protocol: TCP or TLS (select one platform-wide)
  • SIP Keepalive Interval: 15 seconds
  • Keepalive Method: OPTIONS
  • TCP Window Size: 65535
  • TCP Retransmission Timeout: 300ms
  • TLS Certificate Validation: Enabled with Genesys Cloud CA chain

Disable UDP for high-concurrency trunk configurations. UDP lacks reliable delivery guarantees. Packet loss during failover causes the SBC to drop INVITEs without generating proper SIP responses. The Genesys Edge never receives the INVITE, which generates silent drops and delayed 408 responses. TCP provides guaranteed delivery, sequence validation, and congestion control. The SBC maintains transaction state reliably during trunk switchover.

The Trap: Enabling SIP keepalives on UDP while the primary trunk uses TCP causes transport mismatch during failover. The SBC sends OPTIONS keepalives to the secondary trunk using UDP. The secondary trunk expects TCP keepalives. The SBC marks the secondary trunk as unhealthy because it receives no keepalive responses. The routing rule shifts traffic back to the primary trunk, creating a failover loop. The system generates continuous 408 errors as trunks oscillate. Always align keepalive transport with INVITE transport across all trunks in the routing rule.

Architectural Reasoning: Genesys Cloud Edge processes TCP SIP streams with connection pooling. The Edge maintains persistent TCP connections to the SBC, which reduces handshake latency during concurrent call setup. Keepalive OPTIONS messages preserve TCP state and verify trunk health without generating full INVITE transactions. Consistent transport alignment ensures the SBC uses a single transaction table for all trunk paths. Failover becomes a routing decision, not a state migration event. The SBC redirects the INVITE to the secondary trunk IP using the existing TCP connection pool, which preserves transaction timers and eliminates 408 generation.

Update trunk transport settings via the Genesys Cloud API:

PATCH /api/v2/telephony/providers/edge/trunks/{trunkId}
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "sip_settings": {
    "transport_protocol": "TCP",
    "keepalive_interval": 15,
    "keepalive_method": "OPTIONS",
    "tcp_settings": {
      "window_size": 65535,
      "retransmission_timeout_ms": 300,
      "connection_pool_size": 50
    }
  }
}

The connection_pool_size parameter determines how many persistent TCP connections the Genesys Edge maintains to the SBC. Under high concurrency, insufficient pool size causes connection queuing, which delays INVITE delivery and triggers 408 responses. Set the pool size to match 1.5x your peak concurrent call volume.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Thundering Herd on Secondary Trunk During Partial Primary Degradation

  • The failure condition: The primary trunk experiences intermittent SIP 408 responses. Genesys Cloud triggers failover. All concurrent calls shift to the secondary trunk simultaneously. The secondary trunk hits carrier rate limits and returns SIP 408 for all calls.
  • The root cause: Aggressive failover threshold combined with carrier congestion control. Genesys Cloud evaluates trunk health at the edge level. When the primary trunk crosses the failure threshold, the edge routes all subsequent INVITEs to the secondary trunk. Carrier circuits enforce concurrency caps. Exceeding the cap triggers rate limiting, which manifests as 408 responses.
  • The solution: Implement exponential backoff routing on the SBC. Configure the Genesys Cloud routing rule to stagger failover traffic using weighted trunk distribution. Set the secondary trunk concurrency limit to 70% of carrier capacity. Enable SBC call admission control to queue excess calls instead of routing them immediately. Monitor carrier rate limit headers in SIP responses and adjust routing weights dynamically.

Edge Case 2: DNS SRV Record Concurrency Mismatch During Regional Edge Failover

  • The failure condition: The SBC resolves multiple Genesys Cloud edge IPs simultaneously during failover. INVITEs split across edges. Some edges return 408 while others succeed. Call setup success rate drops below 85%.
  • The root cause: Round-robin DNS distribution without capacity weighting. Genesys Cloud edges maintain independent concurrency limits. Standard DNS distributors ignore edge capacity and distribute queries evenly. Under high concurrency, smaller edges reach capacity and return 408. The SBC receives mixed responses, which fragments transaction state.
  • The solution: Configure DNS provider to use health-aware weighted load balancing. Assign weights proportional to Genesys Cloud edge capacity. Enable DNS cache pre-warming for secondary edges. Configure the SBC to prefer primary edge IP and only resolve secondary IPs when the primary returns DNS NXDOMAIN or timeout. Validate edge capacity using the Genesys Cloud Edge health API and adjust DNS weights monthly.

Edge Case 3: SIP Dialog Table Exhaustion on SBC During Prolonged 408 Retry Loop

  • The failure condition: The SBC returns SIP 408 for all new calls. Existing calls drop. SBC CPU utilization reaches 100%. Dialog table memory shows 99% utilization.
  • The root cause: Aggressive SIP retry timers combined with incomplete BYE/CANCEL handling. When the secondary trunk fails, the SBC retries INVITEs continuously. Each retry creates a new dialog state. Incomplete teardown leaves orphaned dialog entries. The SBC exhausts memory and drops all signaling.
  • The solution: Implement dialog timeout limits on the SBC. Set maximum dialog lifetime to 30 seconds for failed transactions. Enable automatic dialog cleanup on SIP 408/404/403 responses. Configure the SBC to drop INVITEs after 3 consecutive 408 responses without retry. Implement call admission control to reject new calls when dialog table utilization exceeds 80%. Monitor SBC dialog metrics using SNMP or vendor-specific telemetry and alert on memory thresholds.

Official References