Diversion SIP header stripped/missing from custom_sip_headers webhook payload

Support Help
1

Hi everyone,

I am testing inbound call routing workflows using custom SIP headers. According to the official documentation for the Inbound Call Webhook request payload:

“custom_sip_headers (inbound call only): an object containing custom SIP headers extracted from the inbound INVITE. Only headers whose name starts with X- (case-insensitive), plus the allowlisted headers User-to-User, Diversion, History-Info, and P-Asserted-Identity, are forwarded. Header names are emitted in lowercase.”

However, during active testing via raw SIP INVITE packets there seems to be an issue where these standard allowlisted routing headers are completely dropped before the webhook object is built.

Steps to Reproduce / Test Results:

  1. Custom X- Headers (Success): If I pass a custom header like X-Contractor-Number: +1234567890, it behaves exactly as documented. It maps cleanly and shows up in the webhook payload normalized to lowercase under "custom_sip_headers": { "x-contractor-number": "+1234567890" }.

  2. Standard Allowlisted Headers (Failure): If I pass a completely valid, RFC-compliant Diversion header targeting a local loopback IP domain to bypass synchronous DNS routing lookup delays (e.g., Diversion: <``sip:+1234567890@127.0.0.1``>;reason=unconditional), the call executes cleanly and trips the webhook. However, the diversion key is completely missing from the custom_sip_headers object.

  3. Further Testing: I ran a test sending User-to-User, History-Info, and P-Asserted-Identity simultaneously. Just like Diversion, the call is accepted, but all three standard headers are completely omitted/filtered out of the final JSON payload.

It looks like the ingress proxy layer (Kamailio) handles and parses custom X- strings perfectly, but either drops or strips the standard telecom headers entirely rather than forwarding them down to the application-layer webhook payload as the documentation guarantees.

Has anyone else run into this, or is there a specific URI syntax required to prevent the ingress engine from cleaning out these standard headers?

Thanks!
Tony

2

Hey @ai_magician Can you share relevant Call ID and Agent ID ?

Regards

3

Hey,

Call_Id: call_635f4bc2ac48933c02575267943
Agent Id: call_635f4bc2ac48933c02575267943

The PCAP files I can download from the Call ID shows the correcly shows I’m passing a Diversion header, yet being ignored by your stack.

Thanks

4

@ai_magician Checking with the team.

5

Ouaw BRAVO !! vous pouvez donc récupérer le numero de l’appelant ET le numéro qui transfere l’appel ? comment vous avez fait ça ???

6

“Glad” I’m not the only one: this issue drove me crazy for a whole day.

As a temporary workaround for this, I created a small middleware that sits between the DID provider and RetellAI. It catches the Diversion header and transposed it into a new header X-Diversion-Number.

This way RetellAI catches it in custom_sip_headers and I can use it in my Agent logic as a dynamic variable {{diversion-number}} or for orchestration via Inbound Webhook.

7

Ouaw BRAVO ! Vous pouvez donc recupérer le numero de l’appelant ET le numéro qui a fait le transfert ? comment avez vous fait ??