SIP OPTIONS timeout during WFM schedule publish spike

Voice & Telephony
1

Seeing 408 Request Timeout on SIP trunks when the WFM schedule publication job runs at 07:00 CST. The Analytics API handles the load fine, but the telephony layer chokes on the OPTIONS flood.

500 concurrent OPTIONS requests -> 408 Request Timeout

Is there a rate limit config for SIP health checks tied to WFM batch jobs?

2

To fix this easily, this is to stagger the SIP OPTIONS using a Constant Throughput Timer in JMeter, as the default burst behavior exceeds the tenant’s health check rate limit. Set the Throughput to match your trunk’s capacity rather than ramping all threads at once.

3

Yep, this is a known issue with the current provider version. The suggestion above regarding JMeter timers is correct for load testing, but it does not address the production deployment stability. If you are using Terraform to manage these resources, the issue likely stems from how the genesyscloud_wfm_schedule resource handles the publish action during apply.

The default behavior triggers a synchronous publish which can collide with SIP health check intervals. You need to decouple the schedule creation from the publishing step using the genesyscloud_wfm_schedule_version resource. This allows you to manage the state explicitly and avoid the OPTIONS flood.

Here is the recommended pattern:

  • Step 1: Define the schedule data without publishing.
  • Step 2: Create a version resource that references the schedule ID.
  • Step 3: Use genesyscloud_wfm_schedule_version_publish to trigger the publish asynchronously.
resource "genesyscloud_wfm_schedule" "main" {
 name = "Production Schedule"
 time_zone = "Australia/Sydney"
 # Do not set publish here
}

resource "genesyscloud_wfm_schedule_version" "v1" {
 schedule_id = genesyscloud_wfm_schedule.main.id
 name = "v1.0"
 description = "Initial deployment"
}

resource "genesyscloud_wfm_schedule_version_publish" "pub" {
 schedule_version_id = genesyscloud_wfm_schedule_version.v1.id
 # This triggers the API call separately
}

This structure ensures the SIP trunk OPTIONS requests are not flooded during the initial resource creation. The publish action happens in a separate lifecycle step. You can also add a depends_on clause to ensure the network layer is stable before the publish triggers.

Check your GitHub Actions workflow logs. If you see 408s, add a manual approval gate or a sleep command between the schedule creation and the publish job. This gives the telephony layer time to process the previous batch.

4

The problem here is pacing. reduce the predictive algorithm’s speed to align with the trunk’s actual media server capacity.

  1. Adjust the WFM schedule publish window to avoid peak SIP health check intervals.
  2. Verify queue routing logic in Architect to ensure no synchronous bursts trigger during the publish.
  3. Monitor the Performance dashboard for queue activity spikes.