Retell appears to be randomlly adding a "+" in front of caller IDs which is causing downstream problems when the call is transferred out with "User's Number"

Support Help
1

Retell appears to be randomlly adding a “+” in front of caller IDs which is causing downstream problems when the call is transferred out with “User’s Number”. I am sending calls from the same IP to the same Retell number via SIP with NANP format (10 digits, no country code) for the FROM, but on some calls Retell shows the number with a + in front BUT not 1. As such the number will be formatted as “+5558675309” instead of “5558675309” or “+15558675309”. This is causing problems downstream as the caller IDs cannot properly be matched.

2

Based on the available documentation, when using the “User’s Number” caller ID setting for call transfers, Retell AI sets the from and P-Asserted-Identity headers to the user’s number for warm transfers using SIP DIAL(1)(2). The documentation indicates that for this feature to work properly, the telephony provider must support caller ID override(1)(2).

The issue you’re experiencing with inconsistent number formatting (adding “+” without the country code “1”) appears to be a caller ID normalization problem when Retell processes inbound SIP calls. The documentation shows that Retell expects numbers in E.164 format, which includes the country code (e.g., “+15558675309”)(3)(4)(5).

When you send 10-digit NANP numbers without a country code via SIP, Retell may be inconsistently attempting to normalize these to E.164 format, resulting in the malformed “+5558675309” format you’re seeing.

To resolve this issue, I recommend:

  1. Send caller IDs in proper E.164 format from your SIP trunk (“+15558675309” for US numbers) to ensure consistent handling(3)(4)

  2. If you need to use non-E.164 formats, you can set ignore_e164_validation to true when creating phone calls, though this only applies when using custom telephony and does not apply when using Retell Telephony(3)

  3. Verify that your telephony provider supports caller ID override for SIP DIAL (warm transfer) or SIP REFER (cold transfer)(1)(2)

The documentation notes that Retell Twilio numbers support showing the user’s number on both warm and cold transfer, while Retell Telnyx numbers only support this when using SIP REFER via cold transfer(1)(2).

For additional support with this caller ID formatting issue, you can:

3

Hello @micahld

So, currently, retell only accepts E.164 format

But can you share the call id so I can check it?

5

Surely! Here are several:

  • call_39156b265c1487de2c4189d1d2b
  • call_c978b41e54150b03a7f68764a75
  • call_b19e9c7d7c497abf5556a48cb29
  • call_3ac6c1177f97af6720ebd1bb625
  • call_a453db7c8ccb7bf5f8fe69a0c85
6

Thank you for providing those call IDs. Unfortunately, the available documentation doesn’t describe how to retrieve or analyze specific call details using call IDs to investigate caller ID formatting issues(1)(2).

However, based on the documentation, you can retrieve call information using the call ID through the API(1)(2). The call object includes fields like from_number and to_number which would show how Retell formatted the numbers(1)(2).

To investigate these specific calls, you would need to:

  1. Use the Retell API to retrieve each call’s details using the call IDs you provided(1)(2)
  2. Check the from_number field in the response to see the exact formatting Retell stored(1)(2)
  3. Review the custom_sip_headers field if you’re using custom SIP headers to pass caller information(1)(2)

The documentation shows that phone numbers in call responses are typically in E.164 format (e.g., “+12137771234”)(1)(2), but doesn’t specifically address how Retell handles incoming SIP calls with 10-digit NANP format numbers.

Since this appears to be a caller ID normalization bug affecting your production calls, I recommend contacting Retell support directly with these call IDs so they can investigate the inconsistent formatting:

The support team will be able to access the call logs and determine why some calls are being formatted as “+5558675309” instead of the proper E.164 format “+15558675309” or your original 10-digit format.

7

As a means of eliminating any potential SIP configuration issues on my end, I updated my switch to simply send the call direct to the DID. While this did improve the occurrence rate of the issue (and now the majority of calls have a “+1” where before they were NANP), there are still instances where the + is added without the 1: call_39156b265c1487de2c4189d1d2b

8

Just following up here: does Retell have a ticket for patching this issue?

9

Hello @micahld

We don’t support the NANP format; we only support E.164 format

10

Please see my last message: this issue is occurring even when sending calls via PSTN: call_39156b265c1487de2c4189d1d2b

11

The same problem with a Twilio Argentina line: Retell add a plus sign to the caller ID, breaking the number.

I understand that outgoing calls are in international format, but it’s crazy that the caller ID of an incoming call is manipulated unilaterally by Retell.