Context:
Managing 15 BYOC trunks across the Asia/Singapore region. We recently updated our outbound routing logic to prioritize a secondary carrier for high-volume SMS traffic. The primary trunk registers cleanly with 200 OK responses, but the secondary trunk consistently fails to maintain a stable registration state during peak load windows. The SIP stack logs show a recurring 403 Forbidden error immediately after the initial 200 OK registration response. This occurs specifically when the Architect flow attempts to switch the active trunk based on our custom failover criteria. We have verified that the SIP credentials and IP allow-lists are identical for both carriers. The issue seems tied to the registration refresh interval, which is currently set to 60 seconds. We are using the standard Genesys Cloud BYOC integration without any custom SIP proxies.
Question:
Does anyone know why the secondary trunk would drop to a 403 Forbidden state right after successful registration? We suspect a race condition in the SIP stack or a carrier-specific quirk with the refresh token. Has anyone encountered similar behavior with specific carriers in the APAC region? We need to stabilize this before our next major campaign launch.