How does the SIP registration cache actually flush when a BYOC pool flips during peak Eastern hours? We’ve got fifteen trunks spread across AWS regions, and the Ohio failover path keeps dropping registrations right after the transfer node kicks in. Architect v2024.3.1 handles the inbound routing fine until the custom Data Action tries to pull the new carrier credentials. The primary pool stays registered, but the secondary trunk’s throwing a 401 Unauthorized on the REGISTER request.
Console shows the flow node hitting the trunk health API, but the response payload comes back with "status": "degrading" instead of "active". Swapped the outbound routing logic to bypass the internal table, yet the SIP proxy still rejects the auth. Carrier docs say the challenge response window closes after three seconds, and the failover handshake is taking closer to five.
Logs are messy. The softphone handshake drops, then the routing table refreshes, but the trunk stays stuck in a half-registered state. Tried bumping the retry interval to 10s, didn’t help. Bandwidth’s edge nodes are definitely throttling the auth sequence when the pool swaps. Doing jack all on the monitoring dashboard while the queue backs up. It’s supposed to auto-flush, but the cache just sits there. The POST request to /v2/trunking/pools/ohio-failover/registration returns a 202 but never completes the three-way handshake.
2024-05-14T14:32:11Z [WARN] SIP_REG_FAIL: 401 Unauthorized (proxy=edge-us-east-2.nice-incontact.com)
2024-05-14T14:32:14Z [ERROR] TRUNK_POOL_SWAP: Ohio_BYPool_02 registration timeout exceeded
2024-05-14T14:32:15Z [INFO] FLOW_NODE_RETRY: DataAction_CredentialFetch failed (attempt 3/3)
Mic stays hot while the queue backs up.