SIP 408 Timeout on BYOC Trunk Registration with X-Correlation-ID Header Exceeding 255 Bytes in APAC Region

Observing persistent SIP 408 Request Timeout errors when attempting to register our BYOC trunks to the Genesys Cloud Edge in the UK South region. The issue appears to be specifically tied to the X-Correlation-ID header, which is currently exceeding the 255-byte limit imposed by intermediate proxies. Our current implementation generates a UUID for each SIP message, but the additional metadata appended for ServiceNow ticket correlation is pushing the total header size over the threshold.

The environment consists of 15 BYOC trunks distributed across APAC regions, primarily Asia/Singapore. The SIP registration process fails consistently when the X-Correlation-ID header is present, but succeeds when the header is omitted. This suggests that the issue is not related to network connectivity or SIP credentials, but rather to header size limitations. The analytics engine logs show a clear correlation between the presence of the oversized header and the 408 timeout errors.

Has anyone encountered a similar issue with header size limitations on BYOC trunks? Specifically, how do you manage the X-Correlation-ID header to stay within the 255-byte limit while still maintaining traceability for service desk integration? Are there any recommended best practices for truncating or encoding the correlation ID to ensure compatibility with Genesys Cloud Edge requirements?

Additional details:

  • Genesys Cloud Version: 2023-11
  • SIP User Agent: Asterisk 18.15.0
  • Carrier: Local APAC carrier with strict header inspection policies
  • Error Log: SIP/2.0 408 Request Timeout (via SIP/2.0/TCP 10.1.1.1:5060;branch=z9hG4bK-123456789)\r\nX-Correlation-ID: {uuid}-SNOW-TICKET-123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

Any insights or workarounds would be greatly appreciated. The current setup is impacting our ability to correlate SIP sessions with service desk tickets, which is critical for our analytics and reporting processes.