Architect IVR Hangup with 487 Request Terminated during BYOC Failover

Architect & Flows
1

I’m curious as to why the Architect flow is triggering a 487 Request Terminated response specifically when the primary BYOC trunk fails over to the secondary carrier? We are managing 15 BYOC trunks across APAC and US regions, and this issue is isolated to the Singapore tenant environment. The primary trunk uses a standard SIP trunking configuration with mutual TLS, while the secondary is a legacy carrier with slightly different codec negotiation behavior. When we simulate a failure on the primary trunk by blocking the IP in the firewall, the call successfully routes to the secondary trunk, but the IVR menu does not play. Instead, the caller hears a brief dial tone followed by immediate disconnection.

The Architect flow is configured with a standard ‘Play Prompt’ action followed by ‘Collect Input’. We have enabled detailed logging for the IVR engine and SIP signaling. The logs show that the INVITE is accepted by the secondary carrier, and the 200 OK is received. However, immediately after the 200 OK, Genesys sends a BYE message, and the carrier responds with 487 Request Terminated. This happens within 200ms of the media path establishment. We have verified that the SDP negotiation is successful and that the codecs (G.711u, G.729) match between the tenant and the secondary carrier.

We have tested this with multiple numbers and different carriers in the failover group. The issue persists across all secondary trunks that do not have the exact same SIP timing characteristics as the primary. It seems that the Architect engine is not waiting for the media stream to stabilize before attempting to play the prompt, or there is a race condition in the RTP negotiation phase. We have tried adjusting the ‘Wait for Media’ settings in the trunk configuration, but this has not resolved the premature hangup.

Is there a specific configuration in the Architect flow or the BYOC trunk settings that controls the delay between call answer and IVR initiation? We need to ensure that the secondary carriers, which have higher latency from Singapore, have enough time to establish the media path before the IVR engine attempts to send audio. Any insights into how to handle this failover scenario without dropping the call would be appreciated.

2

You need to align the SIP session handling logic within the Architect flow to explicitly manage the 487 Request Terminated scenario during BYOC failover events. The discrepancy often stems from the secondary carrier’s slower codec negotiation or differing SIP timer values, which causes the primary session to terminate before the failover logic completes its handshake.

In a ServiceNow integration context, this usually manifests as a “stale” ticket status if the webhook payload is not updated with the correct disposition code upon disconnection. Ensure that your Data Action for ServiceNow ticket creation includes a robust error-handling block that catches the 487 status and maps it to a specific “Network Failover” reason code. This prevents the ServiceNow instance from marking the interaction as “Abandoned” prematurely.

Review the BYOC trunk configuration in the Singapore tenant. Specifically, check the Invite Timeout and Re-Invite Timeout settings. If the secondary carrier uses a legacy codec suite, consider enabling Codec Fallback in the Media Region settings. This allows Genesys Cloud to negotiate a common codec faster, reducing the window where the 487 can trigger.

Additionally, verify that the Webhook payload sent to ServiceNow includes the disposition_code field. If this field is missing or null during a rapid failover, ServiceNow may default to an incorrect status. Use the following JSON structure in your Data Action to ensure clarity:

{
 "short_description": "IVR Failover - 487 Terminated",
 "state": 3,
 "business_state": "In Progress",
 "u_disposition_code": "NETWORK_FAILOVER"
}

This approach ensures that the ticket lifecycle in ServiceNow remains accurate despite the underlying SIP instability. Cross-reference the Genesys Cloud documentation on BYOC trunk failover behaviors to confirm that your Media Region settings support the specific codec requirements of the legacy carrier.

3

Have you tried inspecting the raw SIP trace to verify if the 487 is being generated by Genesys Cloud due to a timeout or by the secondary carrier rejecting the re-INVITE?

  • BYOC failover timeout thresholds
  • SIP timer alignment (T1/T2)
  • Codec negotiation compatibility