Summary

  • PRACK acknowledges one identified reliable provisional response. A 2xx response to PRACK is not the final 2xx response to the original INVITE.
  • RSeq and RAck preserve transaction identity and ordering even when offer/answer advances before final disposition; neither signaling receipt nor negotiated parameters prove that media reached a person.

The missing receipt in the middle of a call

RFC 3261 gives an INVITE a deliberately extended life. Before a user agent accepts with a final 2xx, redirects, or rejects, it may send one or more 1xx responses to report progress. A response from 101 through 199 can create an early dialog. Under the base specification, however, these provisional responses are not delivered reliably.

That limitation matters when a provisional response carries more than a cosmetic ringing indication. In interworking with the public telephone network, an early response can establish dialog state, support an announcement, or carry a session description needed before the final decision. Losing it does not necessarily determine whether the call will ultimately succeed. It can still remove a state on which the next exchange depends.

RFC 3262 introduced the 100rel option tag and the PRACK method for this narrower problem. If an INVITE advertises Supported: 100rel, a UAS may send a non-100 provisional response reliably. If the INVITE carries Require: 100rel, the UAS must do so or reject the extension requirement. The mechanism does not apply to 100 Trying: that response is hop-by-hop, while reliable provisional responses operate end-to-end.

A coordinate, not a general sign of life

A reliable provisional response carries Require: 100rel and an RSeq number. The first number is selected from the range specified by RFC 3262, and its sequence space belongs to one transaction. The same RSeq value in an unrelated INVITE does not identify the same response.

The UAS retransmits the response with exponential backoff beginning at T1. A PRACK stops those transmissions only when it matches. The request must be in the same dialog, and its RAck carries three coordinates copied from the response: the RSeq value, the original CSeq number, and the CSeq method. The receipt therefore means “this provisional response in this transaction,” not merely “something happened during this call.”

When a PRACK matches an outstanding reliable provisional response, the UAS returns a 2xx to PRACK and removes the response from its unacknowledged list. When no response matches, it returns 481. The entity of the verb is essential. The 2xx says that the PRACK transaction succeeded. It does not answer the INVITE, whose final acceptance, redirection, or rejection remains a separate act.

PRACK plays an ACK-like role, but it is not a provisional form of ACK. It is an ordinary in-dialog non-INVITE request, with its own CSeq, its own response, and hop-by-hop transaction reliability through stateful proxies. That independence is how SIP makes an intermediate receipt testable without granting it final meaning.

Reliability included sequence discipline

PRACK acknowledgments are not cumulative. For congestion control, RFC 3262 recommends leaving only one reliable provisional response outstanding and requires the first to be acknowledged before a second is sent. Subsequent RSeq values increase by exactly one and do not wrap.

The UAC identifies a retransmission by dialog ID, CSeq, and RSeq, then discards the duplicate instead of processing the content twice. If a later RSeq arrives before the expected value, it must not be acknowledged or processed. The implementation may cache it while waiting for the gap. Reliability here means the right item in the right order, not simply eventual appearance in a trace.

If the matching PRACK does not arrive for 64*T1, the UAS should reject the original request with a 5xx response. The extension replaces a silent loss with observable state, but that state has a cost. Timers, dialog routes, sequence memory, unacknowledged lists, and authentication can now fail independently. The standard specifies behavior; it does not measure how widely or correctly present networks implement it.

An offer can be answered while the invitation remains unanswered

PRACK may contain a body. If the INVITE contained an offer, a reliable provisional response may carry the answer. If the INVITE contained no offer, a reliable provisional response can supply one and the PRACK must carry the answer. PRACK may also carry a further offer, with its answer in the 2xx to PRACK.

Session parameters can therefore become usable before the original INVITE has a final response. That is not a contradiction because offer/answer completion and invitation disposition are different state machines. RFC 3262 makes the dependency explicit: if an unacknowledged reliable provisional response contained a session description, the UAS must delay the final 2xx acceptance of the INVITE until that response is acknowledged. The rule protects the integrity of the offer/answer exchange. It does not appoint PRACK as the call's final answer.

RFC 6337 later documented the resulting combinations. Even when both user agents support 100rel, not every provisional response must be sent reliably. When an INVITE already contains an offer, the first SDP in a reliable non-failure response is the real answer; SDP in an earlier unreliable provisional response can only be treated as a preview.

RFC 3311 added UPDATE so session parameters can change in early or confirmed dialogs. That adds another route for offer/answer without merging the methods. INVITE, PRACK, and UPDATE retain separate requests, CSeq values, responses, and outstanding state. An implementation must know which exchange has completed and which one still waits.

The audio path cannot sign the signaling receipt

RFC 3960 describes early media such as ringback, announcements, and interactive tones before a final response. SIP signaling and media are loosely coupled. They may follow different paths and become observable in a different order; media can even appear before the signaling that would explain it.

PRACK consequently does not prove that RTP packets arrived, that an announcement was audible, or that the called party answered. Hearing an announcement does not prove that the correct RSeq received the correct RAck. Operations teams may correlate the two timelines, but neither is authorized to stand in for the other.

The IANA Session Initiation Protocol Parameters registry lists PRACK, RAck, RSeq, and 100rel with RFC 3262 as their reference. It establishes formal assignment and source authority. It does not establish deployment share, vendor conformance, or successful handling of a particular call.

Nor does a sequence match authenticate a sender. RFC 3262 warns that an attacker could inject a PRACK and prematurely stop retransmission of important provisional information. PRACK should be authenticated like other requests. Correct state coordinates and a trusted identity are separate checks.

The extension's durable achievement was not making ringing more like answer. It was allowing a system to say something narrower with confidence: this provisional state arrived, perhaps carrying information that let another exchange advance, while the invitation itself remained undecided.

Sources