Dealing with a very strange bug here with our outbound routing logic where custom attributes populated via the BYOC trunk metadata are not persisting when the call fails over to a secondary carrier in the Asia/Singapore region.
We have a complex Architect flow handling inbound calls from our 15 BYOC trunks. The initial SIP INVITE contains specific headers that we parse using the ‘Set Custom Attributes’ block to track carrier-specific billing codes and region tags. This works perfectly for the primary carrier (Carrier A). However, when we simulate a trunk failure by blocking the primary SIP trunk in the Genesys Cloud Admin console, the failover logic triggers correctly and routes the call to Carrier B. The issue arises immediately after the failover. The Architect flow logs show that the ‘Set Custom Attributes’ block is executed, but the values are null or default to empty strings. Upon inspection of the SIP trace for the failed-over call, the original INVITE headers from Carrier A are obviously absent, but Carrier B’s INVITE does not contain the equivalent headers we expect. We are using the ‘Get Call Data’ block to attempt to retrieve the trunk ID, which returns the correct secondary trunk ID, but the associated metadata mapping seems to break. We are running Genesys Cloud version 2023-12-Q4 and using the latest SDK for any API integrations. The environment is strictly Asia/Singapore. We have verified that the secondary trunks are configured with identical header parsing rules in the carrier profile. Is there a known limitation where custom attributes set by initial trunk metadata do not survive a carrier failover event, or is this a configuration gap in our outbound routing policy? The error manifests as a silent failure in the flow, leading to incorrect reporting in our analytics dashboard for these specific failover instances.