Deploy

SIP Trunking (BYOSIP)

View as Markdown

What is SIP Trunking?

SIP Trunking lets you connect phone numbers you already own to Smallest AI. Instead of renting numbers through us, you keep them at your provider (or your own PBX / SBC) and route calls to our SIP infrastructure. Two flows:

  • Inbound: your provider receives the PSTN call and forwards the SIP INVITE to Smallest’s ingress.
  • Outbound: your Atoms agent originates a call, Smallest sends the INVITE to your provider’s termination host, and your provider completes the call to the PSTN.

We handle the conversation and media. Your provider handles the PSTN side.

Before you start

You need:

  1. A telephony provider that supports SIP trunking. Twilio, Telnyx, Vonage, Bandwidth, Plivo, an Asterisk / FreeSWITCH / Kamailio SBC of your own, and most enterprise carriers all work. If it can send and receive SIP over TCP or TLS, it will work here.
  2. Phone numbers configured to route to a SIP trunk in your provider’s settings.
  3. From your provider, know:
    • the outbound (termination) SIP host you will send outbound calls to (a hostname or IP, optional port)
    • which transports it accepts for inbound INVITEs from us (UDP, TCP, TLS)
    • whether it wants credential auth or IP-based auth
  4. Numbers in E.164 format with the leading + (+91XXXXXXXXXX, not 91XXXXXXXXXX). Our ingress requires the + on the request URI. Without it, the call routes as if the destination were unmapped.

Transport contract

Our SIP ingress accepts SIP signalling on TCP and TLS only. UDP INVITEs are dropped without a response and every retransmission times out.

TransportPortStatus
TLS5061Preferred. Signalling is encrypted end to end.
TCP5060Supported. Use this if your build lacks a TLS module.
UDP5060Not accepted. INVITEs are dropped with no response.

Media is separate and stays RTP over UDP regardless of signalling transport. Nothing about audio quality or jitter changes when you move signalling to TCP or TLS.

Origination URL: what to send

The URL your dashboard shows is a bare SIP URI:

sip:5rdbhjuwtlk.sip.livekit.cloud

Append a transport parameter and a +-prefixed number when your provider sends INVITEs. Two shapes work:

sip:+91XXXXXXXXXX@5rdbhjuwtlk.sip.livekit.cloud;transport=tls   ← preferred, port 5061
sip:+91XXXXXXXXXX@5rdbhjuwtlk.sip.livekit.cloud;transport=tcp   ← fallback, port 5060

If your provider only lets you paste the hostname, configure the transport in the trunk’s SIP settings instead of in the URI.

Origination URL: how it appears in your dashboard

The Import SIP Number dialog shows the bare origination URL for copy-paste convenience. Adding the transport parameter and the + prefix is on your side, because those depend on where you paste it (some provider UIs have a separate transport field, others accept the URI parameter).

Setting up SIP Trunking

Step 1: Configure your provider (outbound to us)

Point inbound calls to your number at Smallest’s SIP ingress using TLS on 5061 (or TCP on 5060 as a fallback).

At a minimum:

  • Destination URI: sip:+E164@5rdbhjuwtlk.sip.livekit.cloud;transport=tls
  • Transport: TLS (or TCP)
  • Codecs: G.711 (PCMU / PCMA) and Opus are both accepted. Send whichever your provider prefers.
  • DTMF: RFC 2833 or SIP INFO. Both are read.
  • Media encryption: SRTP is accepted; not required.

If you run a Kamailio SBC, see the Kamailio configuration accordion below for the specific listen= and tls module lines.

Step 2: Import the number on Smallest AI

  1. Open the Phone Numbers tab in your dashboard.
  2. Click Buy Numbers in the top-right, then the Import SIP Number tab.
  3. Fill in:
    • Phone Number. E.164 with the +, e.g. +12025551234.
    • SIP Termination URL. Where we send outbound calls (your provider’s SIP host). Just the host, or host with port. Not a full URI.
      • sip.yourprovider.com
      • sip.yourprovider.com:5060
      • 203.0.113.10:5081 If you paste a full URI, only the host is kept (scheme, ;transport= parameter, and any userinfo are stripped). Values that cannot be normalised to a valid host are refused with a clear error.
    • Display Name. Free-text label (optional).
    • Username / Password. For credential auth. Leave blank if your provider does IP-based auth.
  4. Copy the SIP Origination URL shown in the dialog. That is the host your provider sends inbound INVITEs to; remember to append ;transport=tls (or ;transport=tcp) and the +-prefixed E.164 number when you configure your provider.
  5. Click Add Custom Number.

The phone number you type here must match the number your provider is sending in the To: header, including the country code and the +.

Step 3: Test

Once the number is imported and the agent is assigned:

  1. Make an inbound test call from a real phone. If the agent picks up and audio flows both ways, you are done. If you hear silence or the call never connects, jump to Troubleshooting.
  2. Make an outbound test call from the agent (via the dashboard, or POST /conversation/outbound) to your own phone. Check that your provider bills the call to your termination trunk.
  3. On both directions, check call quality and audio symmetry.

Technical details

Supported features

FeatureSupport
Signalling transport (inbound to us)TLS on 5061 (preferred), TCP on 5060. UDP is not accepted.
MediaRTP over UDP. SRTP optional.
CodecsG.711 (PCMU / PCMA), Opus
DTMFRFC 2833, SIP INFO
Authentication (inbound to us)Credential or IP-based, whichever your provider prefers
E.164 formattingRequired, with the leading + on the request URI

SIP Origination URL (inbound to us)

The host your provider sends INVITEs to for calls arriving on your numbers. The URL from your dashboard (sip:5rdbhjuwtlk.sip.livekit.cloud) needs ;transport=tls or ;transport=tcp and the +-prefixed number:

sip:+E164@5rdbhjuwtlk.sip.livekit.cloud;transport=tls

SIP Termination URL (outbound from us)

The host we send INVITEs to for outbound calls your agent originates. You paste this at Step 2 above. It is your provider’s SIP host, optionally with a port. Not a full URI.

If you paste a full SIP URI (for example sip:sip.yourprovider.com:5060;transport=udp), the scheme, parameters, and any userinfo are stripped and only the bare host is stored. Values that cannot be normalised to a valid host are refused at import time.

IP allowlisting

Smallest does not require you to allowlist a specific inbound IP range on your provider side; use credential or IP-based auth at the SIP layer instead. If your setup does need our egress IPs (for example, a restrictive corporate firewall on your termination host), contact support.

Troubleshooting

Silence, no SIP response

The single most common cause: your INVITE is going over UDP. Our ingress accepts TCP and TLS only; UDP INVITEs are dropped with no reply, no ICMP, no rejection. Symptoms:

  • Your SBC sends INVITE, retransmits per RFC 3261 (T1 backoff), all time out.
  • Packet capture on your side shows outbound INVITE frames with no reply frames of any kind.
  • An OPTIONS request to the ingress over UDP also gets nothing back.

Fix: add ;transport=tcp (port 5060) or ;transport=tls (port 5061) to the request URI, or configure the transport in your trunk’s SIP settings.

Confirm with a sipsak OPTIONS ping after the change. Quote the URI, otherwise the shell splits at ; and sipsak falls back to UDP on port 5060.

$# TCP
$sipsak -vv -s 'sip:5rdbhjuwtlk.sip.livekit.cloud;transport=tcp'
$
$# TLS
$sipsak -vv -s 'sips:5rdbhjuwtlk.sip.livekit.cloud'

You should see SIP/2.0 200 OK from the ingress. If OPTIONS times out on both TCP and TLS, the reachability problem is between your egress and our ingress (firewall, security group, routing), not on our side.

Call rings but the agent never picks up (or vice versa)

Check the To: header on the INVITE against the number you imported. Two common mismatches:

  • Missing + prefix. Our ingress requires the leading + on the request URI. A To: sip:91XXXXXXXXXX@... INVITE reaches us but does not match a mapped number, so the ingress does not route it to an agent. Rewrite your SBC to always send sip:+91XXXXXXXXXX@....
  • Wrong country code. The number you typed at import time must match the number in the INVITE exactly, digit for digit, including the country code.

One-way audio

  • Confirm the 200 OK on the answered INVITE carries an SDP body with an m=audio line for RTP. In a tcpdump capture: tcpdump -i any -s0 -w /tmp/sip.pcap port 5060 or port 5061, then open in Wireshark and inspect the 200 OK SDP.
  • If RTP is present in the SDP but no audio flows, media (RTP over UDP) is blocked at your firewall or NAT. SIP signalling and media traverse separately.
  • If SRTP is required on your side, verify the SDP negotiates RTP/SAVP rather than RTP/AVP.

Retransmission or duplicate INVITEs

TCP and TLS carry SIP signalling reliably; there is no need for the RFC 3261 UDP-style retransmit ladder. If you see duplicate INVITEs from your SBC, check that your transport is actually TCP or TLS on the wire, not falling back to UDP because of a config typo.

Kamailio

In your kamailio.cfg:

listen=tcp:YOUR_IP:5060

Open port 5060 TCP inbound in your security group. Reload Kamailio and re-send INVITEs to sip:+E164@5rdbhjuwtlk.sip.livekit.cloud;transport=tcp.

Requires the tls module compiled in and configured with certificates. Check whether TLS is compiled in:

$kamailio -V | grep -i tls

If absent, rebuild Kamailio with --with-tls or install the kamailio-tls-modules package (Debian / Ubuntu). Then in kamailio.cfg:

listen=tls:YOUR_IP:5061

Configure tls.cfg with your certificate chain and re-send INVITEs to sip:+E164@5rdbhjuwtlk.sip.livekit.cloud;transport=tls.

Still stuck

Capture a call attempt on your side:

$tcpdump -i any -s0 -w /tmp/sip.pcap 'port 5060 or port 5061 or portrange 10000-60000'

Reproduce the failing call, then stop the capture. Email support@smallest.ai with:

  • the pcap
  • the exact To: and Request-URI from one failing INVITE (sanitise any secrets first)
  • the number you imported, and the phone number you dialled
  • the transport you configured (;transport=tcp or ;transport=tls)

Common provider examples

Twilio supports SIP trunking through Elastic SIP Trunking. Both inbound and outbound flow through their trunk.

Quick setup:

  1. Create an Elastic SIP Trunk in Twilio Console.
  2. On the trunk’s Origination tab, add the SIP URI sip:5rdbhjuwtlk.sip.livekit.cloud;transport=tls. Twilio uses TLS on 5061 by default when you specify transport=tls.
  3. On the Termination tab, note the termination URI (a hostname ending .pstn.twilio.com). That is your SIP Termination URL at Step 2 above.
  4. Assign your numbers to the trunk.
  5. Import the number on Smallest AI with the Twilio termination host.
  6. Test both directions.
Complete Twilio Setup Guide

Detailed step-by-step with authentication, IP whitelisting, and DID configuration.

Telnyx SIP Connections support both credential and IP-based auth. Both work here.

Quick setup:

  1. Create a SIP Connection in the Telnyx Portal.
  2. On Inbound, add the Smallest destination as an inbound SIP URI: sip:5rdbhjuwtlk.sip.livekit.cloud;transport=tls.
  3. On Outbound, note the outbound SIP URI Telnyx assigns. That is your SIP Termination URL for Step 2.
  4. Assign numbers to the connection.
  5. Import each number on Smallest AI with the Telnyx termination host.
Complete Telnyx Setup Guide

Authentication options, DID routing, and monitoring.

Vonage Voice API supports SIP endpoints via the sip.connect NCCO action.

Quick setup:

  1. Create a Voice API application in Vonage Dashboard.
  2. In the answer URL webhook, use the connect NCCO to send the call to sip:5rdbhjuwtlk.sip.livekit.cloud;transport=tls.
  3. Note the outbound SIP endpoint Vonage assigns to your app. That is your SIP Termination URL for Step 2.
  4. Link your numbers to the application.
  5. Import each number on Smallest AI with the Vonage termination host.
Complete Vonage Setup Guide

NCCO configuration, webhook setup, and SIP endpoint details.

Configure your outbound trunk to 5rdbhjuwtlk.sip.livekit.cloud with transport=tls on 5061 (or transport=tcp on 5060 as a fallback). Do not use UDP. Set the request URI to sip:+E164@5rdbhjuwtlk.sip.livekit.cloud;transport=tls.

For Kamailio-specific listen= / TLS module setup, see the Kamailio accordion under Troubleshooting.

For your termination host (what we send outbound to), open the port you configure Smallest to send to. Both TCP and TLS are recommended; UDP is fine on your termination side but not required.

Best practices

  1. Use TLS in production. Signalling in the clear over TCP is fine for staging; TLS is the norm on production trunks.
  2. Test both directions and both transports. If TLS is your primary, confirm TCP fallback works before you need it.
  3. Store SIP credentials in a secrets manager. Not in your provider’s plaintext trunk config where possible.
  4. Keep numbers in E.164 with the +. Both when importing and in every INVITE To: header.

Limitations

  • Signalling over UDP is not accepted. TCP or TLS only.
  • SRTP is optional, not required. If you require SRTP end to end, negotiate it in your SDP.
  • No fixed inbound IP range is published for provider allowlisting. Contact support if your setup needs it.

Pricing

Imported numbers via SIP trunking:

  • No monthly rental fee charged by Smallest AI
  • You pay your telephony provider directly for number hosting
  • Standard Smallest AI per-minute call rates apply
  • No additional fees for SIP trunk configuration

See the Pricing page for current per-minute rates.

Need help?