Genesys BYOC Edge Node Dropping SBC Registrations with SIP 408

The Genesys BYOC edge node keeps dropping registrations against our Cisco VCS SBC, and the Teams admin center shows the PSTN usage records as unassigned. We’re running edge version 24.3.1 with the PowerShell provisioning script pulled straight from the admin console. The routing policy looks fine on paper, but SIP 408 timeouts start rolling in about ten minutes after a fresh deployment. Console logs just spit out a generic “SIP transport failure” without pointing to a specific hop. The trace only catches the initial INVITE before it cuts off. 2024-05-12 14:22:01 [ERROR] EdgeNodeSvc: Reg timeout exceeded for trunk pool tp-us-east-1. Next retry in 30s... That’s the whole block. PowerShell returns a 401 when I try to force a presence sync, which makes zero sense since the credentials haven’t changed.

Tried flushing the DNS cache on the jump box and rebuilt the TLS certificates in the Teams admin center. The SBC config shows the media port ranges are open, but the call quality dashboard is just blank. You’ll notice the edge health check keeps bouncing between degraded and healthy every few minutes. Running Get-CsOnlineUser shows the dial plan is attached, yet the BYOC tenant won’t acknowledge the new trunk. The latency metrics are doing jack all to explain why the audio cuts out on the first ring. The firewall rules on the Azure VNet are wide open for 5060 and 5061, so NAT isn’t the culprit here. Switched to the fallback routing group yesterday and the problem followed it right over. Just need to figure out why the edge node refuses to hold the registration past the initial handshake.

curl -X GET "https://org.mygenesyscloud.com/api/v2/edge/nodes?status=active" \
 -H "Authorization: Bearer $TOKEN" \
 -H "Content-Type: application/json"

SIP 408 usually means the SIP_TIMEOUT is too short on the EDGE_NODE. run that health check first. I prefer WEM metrics anyway, but routing failures wreck the adherence reports. don’t blame the SBC until the EDGE_NODE shows registered. weird timing. check the ROUTING_POLICY hop limits next.