SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP 10.0.4.22:5060;rport;branch=z9hG4bK-5238
From: <sip:[email protected]>;tag=12345
To: <sip:[email protected]>;tag=67890
Call-ID: abc-123-def-456
CSeq: 1 REGISTER
Contact: sip:10.0.4.22:5060;transport=tcp
Content-Length: 0
seeing this specific 403 response when the secondary carrier attempts to re-register the trunk in the ap-se-2 region after a forced failover event. we manage fifteen byoc trunks across multiple regions, and this issue is isolated to the three trunks connected to carrier x in singapore. the primary registration works fine, and the failover logic triggers correctly within the architect flow, but the subsequent registration attempt from the backup sip proxy hits a 403 forbidden error immediately.
the error occurs only after the failover timeout of 30 seconds has elapsed. we have verified that the sip credentials are correct and match the configuration in the genesys cloud admin portal. the carrier support team claims their firewall is not blocking the traffic, but the genesys cloud edge logs show the request reaching the edge before being rejected with the 403 status. this suggests an authentication or authorization mismatch specific to the failover state.
we are using the latest version of the genesys cloud platform, and the trunk configuration has not changed in the last six months. the issue started appearing after the last major platform update in the ap-se-2 region. we have tried resetting the sip credentials and re-creating the trunk configuration, but the problem persists. the inbound calls work fine on the primary carrier, but outbound calls fail with a 408 timeout when the secondary carrier is active.
any insights on why the genesys cloud edge would reject the registration with a 403 forbidden during a failover scenario? we need to resolve this quickly as it impacts our call volume during peak hours in the singapore timezone. the architect flow is configured to retry the registration, but it keeps failing with the same error code. we are also seeing increased latency in the analytics reporting dashboard for these trunks, which might be related to the registration state.