Intermittent Call Transfer Failures Due to E.164 Formatting Issue

Support Help
1

Hi team,

We occasionally encounter the following error when transferring calls:

"status":"Error transferring: Transfer destination number is not a valid e.164 number"}

Below is an example of the request that gets sent when this happens:


{
  "execution_message": "I will connect you to our implant team now. One moment please.",
  "transfer_destination_number": "410XXXXXXX"
}

This issue does not occur frequently, but it is recurring—approximately once every 20 transfer attempts, one will fail. This is the set up for the call transfer function with numbers hidden;

image
image757×731 54.7 KB

We currently have “Format to E.164” enabled, however, in these cases the destination number is still being sent without the +1 prefix. As a result, the number does not meet the E.164 standard and the transfer fails.

These are valid, active numbers, and transfers to them succeed most of the time. The failures appear to be intermittent and inconsistent.

Could you please advise on what might be causing this behavior and how we can ensure the transfer number is always properly formatted before being sent?

Any assistance would be appreciated.

Thank you.

2

Based on the error you’re experiencing, there’s a known issue with the E.164 formatting feature that other users have encountered. (1)

According to the official documentation, when setting up call transfers, the transfer number should be set to either a number in E.164 format or a SIP URI in the format of sip:username@domain. (2) (3)

A user reported receiving the exact same error message (“Error transferring: Transfer destination number is not a valid e.164 number”) even though their destination number was E.164 compliant (e.g., +12047778888), and they hadn’t changed anything in their agent configuration. (1) The issue was resolved when they used the “Dynamic Routing” feature. (1)

Recommended troubleshooting steps:

  1. Try using Dynamic Routing instead of static number configuration, as this resolved the issue for another user experiencing the same error. (1)

  2. Verify your transfer destination is configured as either:

    • A number in E.164 format (with the + prefix)
    • A dynamic variable that gets substituted at runtime
    • A SIP URI (2) (3)

  3. If you’re using custom telephony, check with your telephony provider to ensure they support the transfer configuration properly. (2) (3)

Since the intermittent nature of your issue (1 in 20 failures) suggests a potential race condition or formatting inconsistency in how the E.164 conversion is being applied, switching to Dynamic Routing may provide more reliable formatting.

If the issue persists after trying these steps, you can reach out for direct support:

**

3

As can be seen in the screenshot, we are using dynamic routing

4

@Omar_Ashraf Any guidance would be appreciated, as we’ve noticed a spike in these errors over the past two days and would like to address this promptly.

5

Hello @Hussain_Hammad

Can you share the call id?

6

Yes, here are multiple;

call_339e28bed1a5bad64432f0113e0

call_7800f7caac641ead15a3b400128

call_8f49da18464464eda54e7b036a8

7

@Omar_Ashraf Just following up to ask if you’d checked the calls

8

Hello @Hussain_Hammad

This is a hallucination from the AI not returning the number in the correct format. What you can do is to add to the prompt to always use E.164 format.

9

Understood, thank you Omar