SIP trunk registration fails with 408 when WFM status flips to 'Not Ready'

My configuration keeps failing…

We are seeing a weird interaction between our WFM state changes and SIP trunk registration stability. When an agent’s status flips from ‘Available’ to ‘Not Ready’ (often due to a scheduled break or shift swap), the associated SIP endpoint occasionally drops its registration with our PSTN provider. The provider logs show a 408 Request Timeout, but the agent’s softphone shows ‘Registered’.

This happens specifically during our peak shift-change window in Chicago (6:00 AM CST). It seems like the Genesys Cloud WFM service is sending a rapid succession of presence updates that might be conflicting with the SIP keep-alives.

Here is the relevant snippet from our WFM schedule template and the SIP trunk config:

schedule_template:
 shift_duration: 480
 break_policy: "auto_adhere"
 status_mapping:
 - break_type: "paid_break"
 target_status: "Not Ready"
 reason_code: "Break"

sip_trunk:
 provider: "Twilio"
 keep_alive_interval: 30
 registration_timeout: 60

Is there a known latency in the WFM-to-SIP state propagation? Should we adjust the keep-alive interval or disable auto-adherence for breaks to prevent this registration churn?

Yep, this is a known issue… The 408 usually stems from the BYOC Edge dropping keep-alive packets during the WFM state transition. Ensure your Data Action webhook for ServiceNow isn’t blocking the signaling thread. Check the SIP trunk’s registration timer in Architect; if it’s too aggressive during ‘Not Ready’ flips, the edge might timeout before the softphone re-registers.