Could someone explain the exact precedence logic when Architect attempts to parse SIP headers for outbound routing during a trunk failover event?
We are managing 15 BYOC trunks across the APAC region, specifically handling high-volume outbound campaigns. The environment is configured with a primary carrier (Carrier A) and a secondary failover carrier (Carrier B). The issue arises when we inject custom metadata via SIP headers (e.g., X-Campaign-ID) in the Architect IVR flow before the dial action.
Under normal load, Carrier A accepts these headers without issue. However, when we manually trigger a failover to Carrier B for testing, or when Carrier A experiences intermittent SIP 503 Service Unavailable errors, the calls drop immediately upon handoff to the secondary trunk. The Analytics API shows the call state transitioning from connected to failed within 200ms.
The specific error observed in the Genesys Cloud logs is:
“Outbound call failed: SIP 488 Not Acceptable Here. Reason: Unsupported Header. Trunk: BYOC-APAC-SEC-01. Flow: Outbound_Campaign_V2.”
Carrier B’s technical support insists they do not strip headers, yet they reject any SIP INVITE containing our custom X-Campaign-ID or X-Priority headers during failover scenarios. We suspect the Architect flow might be re-parsing or re-attaching these headers differently when the primary trunk registration fails, causing a mismatch with Carrier B’s stricter SIP compliance checks.
Has anyone successfully configured dynamic header stripping or conditional header injection in Architect based on the active trunk status? We are currently using the latest Architect version and SDK v2. We need a way to sanitize the SIP INVITE payload specifically for the failover trunk without duplicating the entire IVR flow. Any insights into the internal header handling during trunk failover would be appreciated.
My usual workaround is to ensuring custom SIP headers are appended at the trunk level rather than within the IVR flow logic. This prevents conflicts with the failover routing engine, which prioritizes standard signaling elements during carrier switches.
The Architect flow should focus on call control, leaving header injection to the telephony integration. Verify the trunk configuration supports custom headers in the failover path to maintain metadata integrity across both carriers.
Yep, this is a known issue…
Cause:
The core conflict stems from how the Architect runtime handles state persistence during SIP trunk failover events. When a call transfers from Carrier A to Carrier B, the platform initiates a re-invite sequence. Custom SIP headers injected via the ‘Set SIP Header’ block in the IVR flow are often treated as ephemeral session data rather than persistent call attributes. During the failover handshake, the signaling layer prioritizes standard RFC-compliant headers (like P-Asserted-Identity or From) to maintain call continuity. Non-standard headers like X-Campaign-ID are frequently stripped or overridden by the carrier gateway’s normalization logic to prevent header bloat or security violations. This results in metadata loss exactly when it is needed for downstream routing or analytics.
Solution:
Move header injection out of the IVR flow and into the Data Action layer or the Trunk configuration itself, as suggested above. However, for dynamic outbound campaigns, a more robust approach is to utilize the Genesys Cloud Webhook integration to push metadata to ServiceNow before the call connects.
- Configure a Data Action to trigger on
Call Start or Outbound Call Attempted.
- Map the
Campaign ID from the Architect context to the ServiceNow incident or task record.
- Use the ServiceNow record ID as a correlation key in the outbound call payload.
Alternatively, if the carrier supports it, define the custom header in the BYOC Trunk configuration under “Advanced Settings” > “SIP Headers”. This ensures the header is part of the static trunk profile and survives failover re-invites. Verify that both Carrier A and Carrier B gateways explicitly allow X-Campaign-ID in their SIP normalization rules. If the secondary carrier strips unknown headers, you must rely on the ServiceNow correlation method to maintain data integrity across the failover boundary.