Just noticed that our custom SIP header injection logic within the Architect IVR flows is consistently failing for outbound calls routed through specific BYOC trunks in the ap-southeast-1 region. We are attempting to pass carrier-specific metadata via the X-Carrier-ID header to optimize routing logic on the carrier side, but the headers are being stripped before reaching the trunk gateway. The issue appears isolated to trunks configured with strict SIP normalization rules enabled, despite the documentation at Genesys Docs explicitly stating that custom headers prefixed with X- should be preserved unless explicitly blocked by the carrier profile.
The environment involves 15 BYOC trunks, with four of them showing this behavior. When I inspect the SIP trace via the Architect diagnostic tools, the Set SIP Header block successfully assigns the value, but the subsequent Connect block shows a 403 Forbidden response from the carrier gateway, citing “Invalid SIP Message Format.” This suggests the platform might be sanitizing the headers during the final handshake, possibly due to a misconfiguration in the trunk’s SIP normalization settings or a regional edge behavior in ap-southeast-1. We have verified that the carrier allows custom headers on their end by testing direct SIP trunks without the Genesys platform, where the headers pass through correctly.
I have reviewed the recent release notes for the Architect platform, but there is no mention of changes to SIP header handling for BYOC trunks. The issue started appearing after the last major platform update in the Asia-Pacific region. I am wondering if there is a known limitation with SIP header injection when using specific carrier profiles or if the trunk configuration requires additional parameters to bypass the default sanitization. Any insights into how the SIP normalization engine handles custom headers in this region would be appreciated. We need to ensure that the X-Carrier-ID is preserved to maintain our failover logic and billing accuracy.