I manage about 15 BYOC trunks globally and we’re trying to pass some complex routing metadata via the SIP UUI (User-to-User Information) header to our external BPO partners.
Our SIP trunk provider supports UUI headers up to 256 bytes. However, when I use the ‘Set UUI Data’ action in Architect and supply a Base64 encoded string that is 180 bytes long, Genesys Cloud silently truncates it at exactly 128 bytes before sending the INVITE out the trunk. I can see the truncated header in the Edge PCAP logs.
Is there a hard limit of 128 bytes in the Architect UUI engine, and if so, is there a workaround to pass larger payloads via SIP headers on a transfer?
We hit this exact issue during a massive load test. The 128-byte limit isn’t technically Architect’s fault; it’s a legacy constraint from the ISDN/Q.931 specifications that many SIP stacks still default to for the User-to-User header.
To get around this, we stopped using the native ‘Set UUI Data’ block. Instead, we use the ‘Call Call Route’ or ‘Transfer to Number’ blocks, which allow you to set custom ‘UUI Data’ as a variable, BUT we found it’s actually better to use a custom SIP header. If your BPO can read X-Genesys-Metadata instead of the standard User-to-User header, you can use the ‘Set Participant Data’ block to append custom headers to the trunk. Custom headers don’t have that strict 128-byte ISDN legacy limit.
I’ve been evaluating Agent Assist integrations and we pass huge JSON payloads.
If you MUST use standard UUI because of the BPO’s rigid PBX, you’ll need to compress the payload. We built a Data Action that takes our metadata, stores it in a lightweight DynamoDB table, and returns a short, 10-character ‘Lookup Key’. We then put that 10-character key into the Architect UUI block. The BPO’s IVR reads the short key from the SIP header and makes a quick API call back to our DynamoDB to retrieve the full 2KB payload. It’s much more scalable than cramming data into SIP headers!