Keep progress, audio and answer as different states
A SIP 180 can indicate ringing without providing an early-media session. A 183 can carry session progress and may contain SDP, while RTP before the final answer is early media. None of those observations is the final 2xx answer, and a phone-generated local ringback is not the same evidence as audio received from the far side.
Asterisk documents inband_progress=no as sending 180 when told to indicate ringing, without sending ringing as audio. With inband_progress=yes, chan_pjsip sends 183 and immediately sends ringing as audio. Record the loaded endpoint value, dialplan action, actual provisional response, SDP and packet path rather than reducing the result to ‘ringback works’.
Read the complete 100rel policy
Asterisk 22 documents four endpoint values. no declines reliable provisional responses; an incoming required 100rel request can then receive 420. required requires reliable provisional responses and can reject a peer that did not advertise support with 421. peer_supported sends provisional responses reliably when the peer advertised support or requirement. The default yes advertises support and PRACKs a response when the peer requires it without forcing reliability merely because the peer advertised support.
Those modes govern one endpoint leg. A B2BUA call can have a different 100rel policy and separate PRACK exchange on its other leg. Preserve Supported, Require, RSeq, RAck, CSeq, tags and response retransmissions per dialog.
Use PRACK as reliability evidence, not audio proof
RFC 3262 makes non-100 provisional responses reliable with the 100rel option tag and a PRACK request. A reliable 18x includes an RSeq value; PRACK carries RAck to identify the acknowledged provisional response. A matching PRACK proves receipt of that provisional response. It does not prove that the SDP was accepted as intended, RTP arrived, ringback was decoded or the final call answered.
Keep the initial INVITE, reliable response, PRACK, PRACK response and any offer/answer body together. If a PRACK is rejected or does not match an outstanding response, diagnose the dialog identifiers and RAck tuple before changing codecs or firewall rules.
Treat early offer/answer and forking explicitly
A provisional response can carry an SDP offer or answer. RFC 6337 records the offer/answer constraints across INVITE, reliable provisional responses, PRACK and final responses. Preserve which message owned each offer and answer, then compare the selected media address, payloads and direction attributes. An SDP body seen on the wire is not enough without its role and accepted response.
Asterisk's follow_early_media_fork and accept_multiple_sdp_answers address different changes in outgoing-call early media. The former follows a subsequent branch when the To tag changes; the latter can process updated SDP on the same branch for non-100rel responses and also requires the system-level control. Neither is a safe universal repair for silent calls.
Bound 183 filtering, MOH and dialplan progress
Asterisk documents ignore_183_without_sdp for SS7-interworking cases where forwarding a bodyless 183 can suppress ringback. That specific flag does not authorize dropping every 183, inventing local ringback or ignoring an SDP-bearing progress response. Record the response body and the caller's resulting indication first.
The Progress() application requests in-band progress, and Asterisk's early-media guidance shows that applications sending audio before answer should establish progress or answer state deliberately. Also keep suppress_moh_on_sendonly scoped: it prevents MOH replacement for sendonly or inactive SDP, including during 183, but affects those attributes in other SDP messages too. No endpoint, PRACK exchange, early RTP path, announcement or call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 22 res_pjsip endpoint reference ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk early-media and Progress guidance ↗
- Asterisk 22 Progress application ↗
- RFC 3262: reliable provisional responses and PRACK ↗
- RFC 6337: SIP offer/answer usage ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.