Early media is audio the far end sends before your call is answered: a carrier announcement, a disconnected-number recording, or a switchboard talking while the phone rings. SIP carries it in a 183 Session Progress with an SDP body, per RFC 3261 section 21.1.5. LiveKit discards it on outbound calls; livekit/sip issue 813 is open as at 16 September 2026.
What is early media, and does my voice agent need it?
RFC 3960, the IETF document that exists for this, defines it in one sentence: early media is “media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user”, occurring “from the moment the initial INVITE is sent until the User Agent Server (UAS) generates a final response”. The same section names what usually lives in that window: “Typical examples of early media generated by the callee are ringing tone and announcements (e.g., queuing status).”
So whether your agent needs it is conditional, and the condition is about the destination rather than your platform. Your agent needs early media only when the network you dial into puts something in that window it must act on. A ringback tone is not information. A recorded “the number you have called is not connected” is. A mailbox greeting that plays before the 200 OK is, because it is the only audio the call will ever produce. Everything below concerns what RFC 5009 calls backward early media — audio flowing from the callee to your agent.
What is not early media: 180 Ringing, local ringback and the 200 OK
A bare 180 Ringing is not early media. RFC 3261 section 21.1.2 gives it two sentences in total: “The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback.” It is an alerting signal, and without an SDP body it carries no media at all. Section 21.1.5 is the one that matters for audio: a 183 Session Progress “is used to convey information about the progress of the call that is not otherwise classified”, and the message body is where that information may sit.
The ringback your agent hears is very often your own stack’s. LiveKit’s SIP API exposes a play_dialtone flag on outbound calls, documented as “Optionally play dial tone in the room as an audible indicator for existing participants”. The implementation plays tones.ETSIRinging, which livekit/media-sdk defines as a single 425 Hz tone, one second on and four seconds off — synthesised locally, identical whether you are dialling Sydney or São Paulo. Trunks do the same one hop out: Telnyx documents a Generate Ringback Tone (183) setting where “Telnyx will reply with an instant 183 message with SDP and start sending early media carrying a US ringback tone”. Neither is the callee’s network talking to you. Both are the local policy RFC 3960 section 3.2 describes, where a user agent “is supposed to generate ringing tones locally for its user as long as no early media is received”.
Early media is not an answered call. RFC 3960 section 3 draws the line precisely: “Early media sessions terminate when a final response for the INVITE is sent. If the final response is a 200 (OK), the early media session transitions to a regular media session.” Same RTP, different commercial status, and every timer and meter downstream keys off that transition rather than off the audio.
And you cannot settle any of this from the signalling. RFC 3960 section 3.3 states flatly that “SIP, as opposed to other signalling protocols, does not provide an early media indicator”, and section 3.2 gives the consequence: “The UAC needs to check if media packets are arriving at a given moment.” You have to look at the media.
What my agent can actually hear before the call is answered
Each row is a real pre-answer event, what the network emits for it, and whether a mainstream agent stack surfaces it as at 16 September 2026.
| Pre-answer event | What the network sends | Does the agent hear it | What it costs you when it does not |
|---|---|---|---|
| Callee is being alerted, nothing else | 180 Ringing, no SDP body | There is nothing to hear | Nothing. Generate local ringback per RFC 3960 section 3.2 |
| Carrier ringback or a personalised caller tune | 183 Session Progress with SDP, or 180 with SDP | No on livekit/sip: issue 813, opened 26 August 2026, open with no maintainer reply on 16 September 2026 | Nothing of value. A tone carries no decision |
| Network announcement, such as number disconnected or service barred | 183 with SDP, often followed by a 4xx or 5xx | No, same gap | The reason never reaches the transcript, so a dead number is retried next pass |
| Voicemail greeting that plays before the final response | 183 with SDP; the 200 OK arrives late or never | No: livekit/agents issue 6895, opened 18 August 2026, open on 16 September 2026, requests an opt-in because detection defers until the SIP call status is active | The classifier settles as uncertain rather than a mailbox, so the agent talks to a greeting |
| Auto-attendant that answers the call and then plays a menu | 200 OK, then normal media | Yes. A post-answer problem, not an early media one | Nothing here; the cost is classification time |
| Your own stack ringing in the room | Nothing on the wire; audio synthesised locally | Yes, when play_dialtone is set |
A synthetic 425 Hz tone can be mistaken in a recording for the far end |
Row four is the one with money attached, and it is deliberately not this page’s subject: how a classifier decides human, mailbox or menu, and the five ways that decision misfires, is worked through in AI voice agent voicemail detection, diagnosed. What follows is the layer underneath it.
The three-gate early media test
Early media reaches your agent only if three independent gates are open, and they are owned by three different parties. Call it the three-gate test, and check them in order, because a shut gate upstream makes everything downstream unreadable.
| Gate | Who owns it | What to check | What you see when it is shut |
|---|---|---|---|
| 1. The network sends it | The terminating carrier | Whether any 18x response in your signalling capture carries an SDP body at all | Only 180 Ringing with no body, then a 200 OK or a failure code |
| 2. The trunk relays it | Your SIP provider | The ringback setting on the connection. Telnyx documents three: relay whatever arrives, generate a 183 with a US ringback tone, or send an instant 180 and let your side make the noise | A perfectly clean ringback on every call to every country, which is the tell that it is synthesised |
| 3. The stack passes the provisional SDP to the media path | Your agent framework | Whether the 1xx handler reads the message body or only the status line and headers | Silence in the room, or your own dial tone, until the moment of answer |
Gate 3 is checkable in source rather than by argument. Reading livekit/sip pkg/sip/outbound.go on main on 16 September 2026, the outbound provisional-response callback is declared func(code sip.StatusCode, hdrs Headers) — a status code and headers, no body parameter — and is used only to stamp a ringing timestamp and set call state. The media side is configured by c.media.ProcessAnswer(sdpResp), which runs after the INVITE transaction returns its final response. A 183 body has nowhere to go, which is the conclusion the reporter of issue 813 reached from the other end of the code.
Gate 1 is the one nobody expects to be deliberate. RFC 5009 defines the P-Early-Media header field for networks whose “early media policy prohibits the exchange of early media between end users” and that have “the capability to gate (enable/disable) the flow of early media to/from user equipment”. Where that gate is shut at the network boundary, no integration work will make your agent hear anything, because the audio is not being delivered.
Everything downstream keys off the 200 OK, not off the audio
- Detection. LiveKit’s answering machine detection documentation states of its
no_speech_thresholdthat “The clock starts when the call is answered, so ringback and early media don’t count against it.” Correct for the common case, and exactly what issue 6895 asks to be able to switch off per trunk. - Call state. Twilio’s Call resource reference defines the
answeredstatus callback event as “The call is answered. If this event is specified, Twilio will send an in-progress status.” There is no pre-answer media event in that status set; a call goesringingtoin-progress. - Billing. The same page states that a completed call “indicates that a connection was established, and audio data was transferred” and that “completed calls, regardless of the outcome, are charged”. Listening to an announcement before a final response is not that. Which meters run on a call nobody answered is in our matrix of what unanswered AI calls actually cost.
- Your ceilings. The LiveKit SIP API reference caps
ringing_timeoutat 80 seconds and documentswait_until_answeredas returning “after the call is answered — including if it goes to voicemail”. Telnyx applies two five-second defaults to calls it delivers to your connection: one waiting for your 180 or 183, one waiting for your 200 OK.
So a call can produce forty seconds of intelligible speech, tell you the number is dead, and still terminate as a no-answer with an empty transcript. That is not a bug in anyone’s product. It is the protocol boundary doing what it says.
When early media is worth chasing, and when it is not
The method is cheap and needs no vendor. Take a signalling capture of a few hundred outbound attempts on the route you actually dial, and answer two questions: what fraction of attempts carried an SDP body on a 1xx response, and what was the gap between that provisional response and the final one. Section 3.3 is why this must be measured rather than configured — there is no indicator to read.
| What your capture shows | Verdict | Why that threshold |
|---|---|---|
| No 1xx response carries an SDP body | Do nothing. Local ringback is correct behaviour | RFC 3960 section 3.2 makes local generation the default policy when no early media arrives |
| SDP on the 1xx, but the gap to the final response is under about 2.5 seconds | Do nothing | 2.5 seconds is LiveKit’s documented human_speech_threshold, the length of a short greeting. Below it there is nothing a classifier could act on |
| SDP on the 1xx and a gap of roughly ten seconds or more, repeatedly, on one route | Worth engineering. Open a per-trunk flag, never a global one | Ten seconds is LiveKit’s default no_speech_threshold; a window that long can hold an entire announcement or mailbox greeting |
| Behaviour differs sharply between two carriers on the same destination | Route selection is cheaper than code | Gates 1 and 2 are carrier-owned. Changing the route changes the answer without touching your agent |
| Inbound calls only | Not your problem | On an inbound call your agent is the called party. The pre-answer window is yours to send into, not to listen to |
Then the cost of running it, which is what decides it. The capture is an afternoon. The rest is not: a per-trunk flag needs a labelled set of calls per carrier to know which trunks to set it on, it must be re-checked whenever a carrier changes route, and it interacts with the classifier rather than sitting beside it — issue 6895 is explicit that this “can’t be auto-detected safely” because trunk knowledge lives with the integrator, not the SDK. One country through one carrier: do it yourself and stop reading. Several markets: the work is per destination and it recurs, which is the same shape as everything else at this layer, where connecting an AI agent to a SIP trunk is a day and keeping it correct across carriers is a standing job. Zian AI runs live phone, SMS, email and WhatsApp outreach across 30+ languages with private model deployment available on customer infrastructure, and per-destination configuration sits in the platform rather than in a prompt because 28x more contact attempts multiplies every routing difference you have not measured.
What happens after the 200 OK, when the thing that answered turns out to be a phone tree, is a separate sequence with its own timers: see what happens when an AI agent lands in an IVR mid-call. Broader questions about how Zian AI builds and runs agents are answered on the Zian AI FAQ.
Frequently asked questions
Does my AI voice agent hear the ringback tone?
Usually it hears a tone your own stack made, not the one the network sent. LiveKit documents a play_dialtone option that plays a dial tone into the room, and the implementation synthesises a 425 Hz ETSI cadence locally regardless of which country you dialled. Carrier ringback delivered as early media is discarded before it reaches the room, which is what livekit/sip issue 813 asks to change.
What is the difference between 180 Ringing and 183 Session Progress?
180 Ringing means the callee is being alerted and nothing more. RFC 3261 section 21.1.2 says it MAY be used to initiate local ringback, so the sound is made at your end. 183 Session Progress, in section 21.1.5, conveys call progress that is not otherwise classified, and when it carries an SDP body it can bring real audio from the far end before the call is answered.
Is early media the same as the call being answered?
No, and the difference is what your platform bills and times from. RFC 3960 section 3 states that early media sessions end when a final response is sent, and that a 200 OK is what turns an early media session into a regular one. Audio flowing is not an answer event.
Why does my agent miss a voicemail greeting that plays during ringing?
Because detection waits for the answer event by design. LiveKit documents that the no speech clock starts when the call is answered, so ringback and early media do not count against it. On carriers that deliver the greeting itself before the final response, that rule discards the only audio the call produces, which is the request in livekit/agents issue 6895, still open on 16 September 2026.
Can my carrier stop early media reaching me at all?
Yes, and some do it as policy rather than by accident. RFC 5009 defines a header field for networks whose early media policy prohibits the exchange of early media between end users and that can gate the flow on or off at the network boundary. Where that gate is shut, no change to your agent will make the audio appear.
Do inbound AI agents need early media?
No. On an inbound call your agent is the party being called, so the pre-answer window is one it could send into rather than one it needs to listen to. Early media is an outbound concern, and only a real one on routes where the destination puts information in that window.
Build outbound agents that know what they are listening to
Zian AI builds autonomous AI sales agents for live phone, SMS, email and WhatsApp outreach, including an Outbound Appointment Setter and a Sales Call Closer, with SmartReach AI™ orchestrating message, channel and timing and PrecisionPitch AI™ continuously split-testing approaches. Zian AI is currently in partnership-application beta. Apply For Partnership.