VoIP.info Troubleshooting

No ringback or early announcement before a SIP call is answered

Trace local ringback, 180 or 183 signaling, early SDP, RTP and reliable provisional responses without confusing pre-answer media with an answered call.

Reviewed 2026-10-07RFC 3960, RFC 3262 and current Asterisk 22 Progress, Ringing and res_pjsip documentation reviewed October 1, 2026; no endpoint, carrier, PBX, provisional response, packet, announcement or call was testedIntermediateDocumentation based · not lab tested

Name the missing pre-answer experience and exact leg

Identify whether the caller expected locally generated ringback, in-band ringback, a carrier intercept, a queue message, an IVR prompt or another announcement. Note the calling and called endpoints, route, trunk, timestamp and whether normal audio begins after the final 200 response. A silent pre-answer interval followed by good conversation is a different failure from no audio after answer.

Capture from the initial INVITE through the final response or cancellation on both sides of the PBX. Preserve Call-ID, CSeq, provisional responses, SDP bodies, To tags, RTP endpoints and the first media packet. Do not begin with codec or firewall changes before naming which leg was expected to create and render the sound.

Signaling and media answer different questions
SIP signaling passes from caller through call control to the other endpoint. RTP media can pass directly between endpoints or through a media relay.

Illustrative topology: direct RTP is shown below. Many PBXs and session border controllers anchor media instead.

Separate 180, 183, SDP and arriving media

RFC 3960 keeps local ringing policy separate from arriving early media. A 180 Ringing response can tell the caller that the destination is being alerted, while usable pre-answer audio still depends on offer and answer state plus media packets that reach the negotiated receiver. A 183 response does not itself prove that SDP was present or that RTP followed.

Build a timeline for each PBX leg: provisional status, To tag, SDP offer or answer, negotiated payloads, media address, first RTP packet and what the user actually heard. SIP signaling and media can follow different paths. A packet capture proves the packets at its observation point, not that the endpoint decoded or played them.

Distinguish generated ringback from forwarded early media

Asterisk's Ringing() asks a channel to indicate ringing. Progress() asks for in-band progress and supports pre-answer audio; Asterisk's application guidance also requires noanswer where Playback must not answer the call. Those are application-state choices, not interchangeable ways to make silence disappear.

For chan_pjsip, inband_progress=no documents 180 Ringing without audio generated by Asterisk, while inband_progress=yes documents 183 plus immediate ringback audio. ignore_183_without_sdp exists for interworking cases where forwarding an SDP-less 183 can suppress ringback. Read the loaded endpoint and actual message exchange before changing either control.

Follow early-dialog and forking changes

A call can fork to more than one destination. RFC 3960 notes that one branch may send 180 while another later supplies early media. Different provisional or final responses can also carry different To tags and SDP. Treat each early dialog as its own source; do not merge media evidence from one branch with the final answer from another.

Asterisk's follow_early_media_fork is a versioned control for subsequent 18x or 2xx responses whose different To tag and SDP describe another fork. It also requires the corresponding system-level enablement. Do not enable it generically: first prove that the captured branch change is the missing transition and retain the final answered path.

Verify reliable provisional responses without blaming RTP

When 100rel is negotiated, a reliable 101–199 response carries Require: 100rel and an RSeq value. PRACK acknowledges that specific response through RAck, and the PRACK transaction receives its own final response. RFC 3262 says provisional retransmission stops after the matching PRACK. A repeated reliable response therefore calls for dialog, RSeq, CSeq and RAck correlation before any wider media rule.

Keep reliability separate from audibility. A valid PRACK proves receipt of the provisional response, not that SDP negotiation completed, RTP arrived or the caller heard an announcement. Conversely, media packets in a capture do not prove the reliable provisional transaction completed correctly.

Prove both pre-answer and answered behavior

Make the narrow correction supported by the failed state: application progress, local ringing policy, SDP forwarding, early-dialog selection, PRACK exchange, media addressing or endpoint rendering. Do not answer every call early solely to create ringback; answer state can affect billing, queue behavior, announcements, CDRs and abandonment.

Retest a locally ringing call, an expected carrier announcement, an unanswered or cancelled call and a normally answered call. Verify the intended pre-answer sound, final response, ACK, bidirectional RTP and decoded conversation separately. Remove bounded protocol logging and retain only redacted evidence. No endpoint, carrier, PBX, provisional response, early dialog, packet, announcement, billing result or live call was inspected or tested for this guide.

Use the Asterisk-specific PRACK path when applicable

For chan_pjsip, the focused Asterisk diagnostic keeps each endpoint leg's 100rel policy, RSeq and RAck, SDP role, ringback source and early RTP path together.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.