Skip to main content

Inbound SIP

Inbound SIP lets a SIP client, such as a softphone or a SIP trunk, call one of your Turn.io numbers. Turn answers these calls the same way it answers that number's WhatsApp calls: with the AI agent, the waiting room or an operator in the inbox.

This page is for people who configure SIP clients. It covers the server, credentials, TLS, SRTP and codecs Turn expects, and how a call behaves once it connects.

Alpha Release

Inbound SIP is in alpha and subject to change. Requirements, limits and behaviour may change in future releases.

info

Inbound SIP is behind a feature flag. To use it on your numbers, ask for access at support@turn.io.

At a glance​

SettingValue
Serversip.turn.io, port 5061
TransportTLS 1.2 or later, with an ECDHE cipher suite. No UDP or plain TCP
AuthenticationSIP digest, MD5, qop=auth, realm turn.io
UsernameThe number's address, such as +15551230000
Address to dialsip:+15551230000@sip.turn.io;transport=tls
MediaSRTP keyed with SDES (a=crypto), profile RTP/SAVP
CodecsG.711 μ-law (PCMU, payload type 0) or A-law (PCMA, payload type 8)
DTMFRFC 4733 telephone-event, payload type 101
Media portsUDP 30000 to 30096, at the address in Turn's SDP answer
DirectionInbound only

Turning it on​

  1. In Turn, open the number's Settings, then Calls, and find the Inbound SIP section. Only admins can change it.
  2. Switch on Enable inbound SIP.
  3. Under SIP password, click Generate and copy the password. It is shown only once: Turn keeps only a digest hash of it, so it can't show it again. You can type your own password instead. A new password replaces the old one straight away.
  4. Copy the SIP username. It is the number's address, including the leading +.

The Inbound SIP section switched on, with the SIP username and a newly generated SIP password

Until the number has a SIP password, Turn refuses its calls with 403 Forbidden.

The rest of the Calls page decides who answers: AI answering, the waiting room, appointments and operators. SIP calls follow the same settings as the number's WhatsApp calls.

Signalling​

Server and TLS​

Connect to sip.turn.io on port 5061 over TLS. Turn doesn't accept SIP over UDP or unencrypted TCP.

  • Turn accepts TLS 1.2 and later, with forward-secret (ECDHE) cipher suites only.
  • The certificate is publicly trusted and issued for sip.turn.io. Verify it as you would any other. It's served whether or not your client sends SNI.
  • Turn doesn't ask for a client certificate.
  • Keep the TLS connection open for the whole call. Turn sends its requests within the call, such as the BYE when the AI agent ends the call, over the connection your INVITE came in on. It never opens a connection to you, so your client doesn't need to be reachable from the internet.
  • A connection that carries no signalling for an hour is closed. If your calls may last longer, send OPTIONS keep-alives. Turn answers OPTIONS with 200 OK without asking for credentials.

Authentication​

Turn challenges every INVITE with 401 Unauthorized:

WWW-Authenticate: Digest realm="turn.io", nonce="…", qop="auth"

Answer the challenge with these credentials:

FieldValue
UsernameThe SIP username from Turn, such as +15551230000
PasswordThe SIP password you generated or set
Realmturn.io

Turn doesn't authenticate by IP address, so it doesn't need to know where your calls come from. On a SIP trunk, set Turn up as a peer that you authenticate to with these credentials.

Registration is optional. Turn accepts a REGISTER for the number's address (the SIP username as the address of record) with the same credentials and answers 200 OK. It never places calls to a registered client, so register only if your client insists on it.

Addressing​

Two parts of the INVITE matter:

  • The Request-URI user part chooses the Turn number. It must match the number's SIP username exactly, including the +: sip:+15551230000@sip.turn.io;transport=tls. An address that matches no number gets 404 Not Found. A number with inbound SIP switched off gets 403 Forbidden.
  • The From user part is the caller. It must be a phone number: digits with an optional leading +, ideally in E.164 format. Turn files the call under the contact with that number, and creates the contact if it doesn't exist, as it does for a WhatsApp call. Anything else, such as alice, gets 400 Bad Request.

A SIP trunk normally puts the caller ID in From, which is what Turn expects. A softphone normally puts its account username there. With the Turn SIP username as the account username, calls are filed under the number's own address. To call in as a different phone number, set the softphone's account username to that number and its authentication username (often called "auth ID" or "auth user") to the Turn SIP username. Leave registration off, because only the number's own address can register.

Media​

SRTP​

SRTP is required. Offer RTP/SAVP (or RTP/SAVPF) with SDES keys in a=crypto lines (RFC 4568). The keys travel inside the TLS-protected signalling.

Turn takes the first a=crypto line in your offer that it supports and answers with one line, carrying the same tag and suite and a key of its own. It supports these suites:

  • AES_CM_128_HMAC_SHA1_80
  • AES_CM_128_HMAC_SHA1_32
  • AEAD_AES_128_GCM
  • AEAD_AES_256_GCM

Turn skips lines it can't honour exactly: an unknown suite, a key with an MKI (|1:4) or more than one key, or session parameters such as KDR or UNENCRYPTED_SRTP. A key lifetime is fine. Offer at least one plain line, such as:

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<base64 key and salt>

Turn refuses these offers with 488 Not Acceptable Here:

  • Plain RTP (RTP/AVP), even with a=crypto lines. SRTP is negotiated by the profile on the m= line.
  • DTLS-SRTP (UDP/TLS/RTP/SAVP with a fingerprint).
  • RTP/SAVP with no a=crypto line Turn can use.

Turn doesn't send or read RTCP.

Codecs​

Turn speaks G.711 only. It answers with the first of PCMU (payload type 0) and PCMA (payload type 8) in your offer's order, plus telephone-event (payload type 101). Other codecs in the offer are fine, but Turn won't pick them. An offer with neither G.711 law, such as Opus or G.722 only, gets 488 Not Acceptable Here.

  • Send 20 ms packets. Turn sends 20 ms packets.
  • The INVITE must carry the SDP offer. An INVITE without one (a late offer) gets 488 Not Acceptable Here.
  • Turn accepts RFC 4733 DTMF but doesn't act on keypresses.

Here is an offer Turn accepts, and its answer:

m=audio 40000 RTP/SAVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<your key>
a=ptime:20
a=sendrecv
c=IN IP4 203.0.113.11
m=audio 30012 RTP/SAVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<Turn's key>
a=sendrecv

Ports, NAT and firewalls​

  • Send your audio to the address and port in Turn's SDP answer. The media address isn't the address sip.turn.io resolves to, so allow outbound UDP to the answer's c= address on ports 30000 to 30096. Each call gets one port in that range.
  • Turn uses symmetric RTP: it sends its audio to the address and port your audio comes from, not to the one in your SDP. A client behind NAT works without STUN or ICE, as long as it sends and receives on the same port. Turn doesn't use ICE.
  • Send RTP continuously from the moment the call is answered, including during silence. Turn hangs up a call when it receives no audio for 30 seconds. Switch off silence suppression (VAD), and don't put the call on hold in a way that stops your RTP, such as a=inactive.

Call flow​

Client Turn
|------ INVITE (SDP offer) ---------------->|
|<----- 401 Unauthorized -------------------|
|------ ACK ------------------------------->|
|------ INVITE (SDP offer, credentials) --->|
|<----- 100 Trying -------------------------|
|<----- 180 Ringing ------------------------|
| … ringing … |
|<----- 200 OK (SDP answer) ----------------|
|------ ACK ------------------------------->|
|<========== SRTP, both directions ========>|
|------ BYE (or Turn sends BYE) ----------->|
|<----- 200 OK -----------------------------|
  • Ringing. After authenticating the call, Turn sends 180 Ringing without SDP, so play ringback locally. There is no early media.
  • Answering. Turn sends 200 OK with its SDP answer as soon as something picks up: the AI agent, an operator accepting the call in the inbox, or the waiting room. In the waiting room the caller hears the welcome message and then hold music until an operator joins.
  • Nobody answers. Turn ends a call that nobody picks up 30 to 40 seconds after the INVITE, with 503 Service Unavailable.
  • Cancelling. A CANCEL while the call rings gets 487 Request Terminated for the INVITE.
  • Hanging up. Either side can send BYE. Turn sends one when the AI agent or operator ends the call, or when your audio stops for 30 seconds.
  • Re-INVITE. Turn accepts re-INVITEs that refresh the session, move your media address or re-key SRTP. The codec stays the same. If Turn can't accept a re-offer, it answers 488 Not Acceptable Here and the call carries on unchanged.

Who answers​

SIP calls are routed exactly like the number's WhatsApp calls, using the settings on the Calls page:

  • AI answering: the AI agent picks up straight away, or when no operators are available. AI agents on OpenAI or ElevenLabs can answer SIP calls. A number whose AI answers with a Gemini model refuses SIP calls with 503 Service Unavailable.
  • Waiting room: the caller waits, with the welcome message and hold music, until an operator joins.
  • Appointments: a caller with an appointment at the time of the call waits in the waiting room until the appointment's host joins.
  • Operators: the call rings in the inbox like a WhatsApp call, in the caller's chat. If calls go to the chat's assigned operator, only that operator is rung.

The call appears in the caller's chat as it would for a WhatsApp call.

Response codes​

CodeMeaning
100 TryingTurn received the INVITE.
180 RingingThe call is authenticated and ringing. No SDP.
200 OKThe call was answered. Carries Turn's SDP answer. Also the answer to a successful REGISTER.
400 Bad RequestThe From user part isn't a phone number.
401 UnauthorizedDigest challenge. Send the request again with credentials.
403 ForbiddenInbound SIP is off for the number, or the number has no SIP password.
404 Not FoundNo Turn number has the dialled address.
487 Request TerminatedYou cancelled the INVITE while it rang.
488 Not Acceptable HereTurn can't use your SDP offer: it's missing, has no G.711 codec, isn't SRTP, is DTLS-SRTP or has no usable a=crypto line. In answer to a re-INVITE, Turn refused the change and the call continues.
500 Server Internal ErrorTurn couldn't set the call up.
503 Service UnavailableNobody answered in time, the call couldn't be connected, or the number answers with an AI model that can't take SIP calls.
603 DeclineAn operator declined the call.

Client checklist​

Most failed calls come down to one of these settings:

SettingValue
SIP server or proxysip.turn.io:5061
TransportTLS
Username, or authentication usernameThe Turn SIP username, such as +15551230000
PasswordThe Turn SIP password
Realmturn.io, or leave it empty to take it from the challenge
Number to dialThe Turn SIP username
Caller ID (From user)The caller's phone number
Media encryptionSRTP with SDES, mandatory. Not DTLS-SRTP or ZRTP
CodecsPCMU and/or PCMA enabled
Packetisation20 ms
DTMFRFC 4733
Silence suppression (VAD)Off
RegistrationOptional

Limitations​

  • Inbound only: Turn doesn't place SIP calls.
  • G.711 only. No wideband codecs such as Opus or G.722.
  • SDES-keyed SRTP only. No plain RTP and no DTLS-SRTP.
  • Keypresses are received but not acted on.
  • No early media, and no setting for how long a call rings before Turn ends it.
  • A number whose AI answers with a Gemini model can't take SIP calls.
  • Capacity is limited during the alpha. Tell support@turn.io your expected peak of simultaneous calls before you send production traffic.