Skip to main content

Overview

This guide shows how to integrate Retell agents with your telephony provider and use your own numbers. This works with any agent type. There are two ways to integrate:
  1. Elastic SIP trunking: The recommended option if your telephony provider supports elastic SIP trunking. You set up a SIP trunk, configure your number to point to it, and import that number to Retell.
  2. Dial to SIP URI: If your provider does not support elastic SIP trunking, or you have a more complex telephony setup, you can dial the call to a specific SIP URI.
  • Retell SIP server uri: sip:sip.retellai.com
  • IP block for traffic: 18.98.16.120/30 (All regions), 3.42.144.0/23 (All regions), 153.57.128.0/18 (All regions), 143.223.88.0/21 (certain United States traffic), 161.115.160.0/19 (certain United States traffic)
Use these IP blocks to whitelist traffic to Retell’s SIP server. Many telephony providers require this.
Transport method supported: To use a different transport for inbound calls, append the transport method to the SIP server URL:
  • For TCP, the SIP server URL needs to be sip:sip.retellai.com;transport=tcp
  • For UDP, the SIP server URL needs to be sip:sip.retellai.com;transport=udp
  • For TLS, the SIP server URL needs to be sip:sip.retellai.com;transport=tls
Media encryption supported:
  • SRTP (Transport should be set to TLS to use SRTP)
Audio Codecs supported:
  • PCMU
  • PCMA
  • G.722(HD)
Elastic SIP trunking is a service offered by cloud communications platforms that lets organizations connect their existing PBX (Private Branch Exchange) or VoIP (Voice over IP) infrastructure to the Public Switched Telephone Network (PSTN) over the internet using SIP (Session Initiation Protocol). Here, elastic SIP trunking connects Retell’s VoIP with PSTN so your agents can make outbound calls and receive inbound calls. All telephony features supported by Retell numbers work here too, as long as your provider supports them. Many telephony providers offer SIP trunking, so yours most likely supports it. Here are detailed guides for some telephony providers: Other telephony providers that support SIP trunks work too; use these guides as a reference. Using a contact center platform instead? See the dedicated guides for Avaya, Genesys Cloud, Five9, and Amazon Connect.

FAQ

No, Retell will not be able to know if the setup you provide works or not until a call is made.
Please check your origination setting in your SIP trunking provider. Also check the logs in your telephony provider, and perhaps open a ticket with them.
Please check your termination setting in your SIP trunking provider, and make sure you provide the right termination URL to Retell. Also check the logs in your telephony provider, and perhaps open a ticket with them. See Debug outbound call for common SIP failures, and Debug SIP calls with PCAP files to inspect the signaling in Wireshark.
Yes you can use the transfer call feature with SIP trunking. Please note that if you intend to use SIP REFER (cold transfer with the transferee’s number), you will need to configure that in your SIP trunking provider to allow SIP REFER and PSTN transfer, with the transferee’s number showing as caller id. To pass call metadata over the trunk, see custom SIP headers.
Yes, you can. See Capture DTMF input to read digits the caller presses.
Yes, you can.
Right now you’d need to delete and re-import the number.

Method 2: Dial to SIP URI

If your telephony provider does not support elastic SIP trunking, or you have a more complicated telephony setup that cannot use elastic SIP trunking, you can use this method. When using this method, Retell does not directly make or receive calls, but instead relies on your system to dial the call to the respective SIP URI. This would require you to have some code to handle integration with your telephony provider. All traffic looks like inbound to Retell in this case, so it’s up to you to specify the call direction.
When using this method, you will not be able to use Retell’s transfer call feature, as we do not have access and control over the telephony provider and number, and cannot initiate transfer for you. You can however implement your own transfer logic and use a custom function to trigger a call transfer.
Here we assume you already have your call handling setup. For Retell to know what agent to use to handle the call, and for you to obtain SIP URI to use for this call, you would call the Register Phone Call API. You will get a call_id back from this API, and you would use it to piece together the SIP URI.
SIP URI: sip:{call_id}@sip.retellai.com
You must dial the call to the SIP URI within 5 minutes of calling Register Phone Call. If the call is not connected within that window, it disconnects with registered_call_timeout. See Debug call disconnection for disconnection reasons.

Example code

Here’s a simplified example that handles the inbound call webhook from Twilio and dials the call to the SIP URI.
Node

FAQ

You will need to handle the transfer call/end call logic yourself, meaning that you will need to write a custom function which internally interacts with your telephony provider to transfer the call/end the call.
Yes.
Check your code that interacts with the telephony provider. Some providers like Twilio can call the webhook multiple times for a single call. In those cases, you will need to dedupe the call.
Yes, using this method basically gives you full control over telephony functionalities, so you should be able to use telephony provider’s other features. Retell also has built-in voicemail and IVR detection if you’d rather handle it on our side.

Security center

Retell secures your voice communications. We recommend using TLS 1.2 or higher to secure all SIP signaling channels between your infrastructure and Retell’s SIP servers. To establish a secure TLS connection with Retell’s SIP server, you may need to add Retell’s server-side root CA to your trust store. You can download it here.

Mutual TLS (mTLS)

Mutual TLS (mTLS) is an extension of the standard TLS protocol that provides two-way authentication between a client and a server. Unlike standard TLS — where only the server presents a certificate to prove its identity to the client — mTLS requires both sides to present and verify certificates. This ensures that only trusted, authenticated parties can establish a connection, significantly reducing the risk of man-in-the-middle attacks and unauthorized access. In a typical TLS handshake:
  1. The server presents its certificate to the client.
  2. The client verifies the server’s certificate and the connection is established.
With mTLS, an additional step is added:
  1. The server presents its certificate to the client.
  2. The client also presents its certificate to the server.
  3. Both parties verify each other’s certificates before the connection is established.
This mutual verification makes mTLS particularly valuable for SIP-based voice infrastructure, where securing signaling and media traffic between trusted systems is critical. Retell supports Mutual TLS (mTLS) for SIP connections. If you require mTLS for your setup, reach out to us via the Customer Support Portal or at support@retellai.com to get it configured for your account. Retell uses a client certificate issued by AWS Private Certificate Authority (PCA). To validate Retell’s TLS client certificate, you must add the root certificate to your SIP server’s trusted certificate store — without this, your server will reject incoming connections from Retell.

Video tutorials

Elastic SIP trunking

Twilio
Telnyx
Vonage

Dial to SIP URI

Telephony partners

If you need to manipulate the SIP call flow or have custom needs Retell doesn’t directly support, check our telephony partners to see if they can help.
  • Jambonz: Jambonz is a SIP server that supports static IP address and can be used to connect to Retell’s SIP server to manipulate the SIP call flow. A dedicated Slack support channel is available for Retell users.
  • Cloudonix: Cloudonix is a CPaaS that can be connected to Retell’s SIP server to manipulate the SIP call flow.