Summary

  • RFC 3261 defines 180 Ringing as a provisional response: the receiving user agent is trying to alert the user, and the response may be used to initiate local ringback at the caller.
  • A 180 response does not prove that the far-end user heard an alert, that early media arrived, or that the call was accepted. Reliable provisional delivery through RFC 3262 and PRACK strengthens message handling without turning provisional state into a final answer.
  • Operational systems should preserve the branch, source and time of alerting evidence, then keep it separate from final response, media, human-answer and application-outcome records.

The ring that may be made near the caller

The familiar sound in a handset encourages a simple story: the remote telephone must be ringing. SIP deliberately permits a more complicated one. RFC 3261 says a user agent client may use a 180 response to initiate local ringback. The sound can therefore be generated on the caller’s side because a signalling message arrived. It is not necessarily audio sent across the network from the called party’s environment.

That distinction is not semantic hair-splitting. The 180 response says the user agent receiving the invitation is trying to alert the user. “Trying” matters. A desktop client may display a banner; a mobile device may suppress sound; a registered endpoint may be offline by the time a fork is cancelled; an intermediary may have produced the response while downstream branches continue. The protocol event is observable. The human event remains contingent.

RFC 3261 places 180 among 1xx provisional responses. Provisional means that processing continues and the result is not definitive. A final 2xx response to the invitation establishes acceptance; a final failure response reports a different outcome. A monitor that paints 180 as “answered” collapses two levels of the state machine and discards the very uncertainty the response class was designed to retain.

Henning Schulzrinne is one of eight named authors of RFC 3261, alongside Jonathan Rosenberg, Gonzalo Camarillo, Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley and Eve Schooler. Treating the specification as collective work is important: this is not a story in which one person invented every signalling choice. Schulzrinne’s broader contribution lies in helping define the architecture in which signalling, media and user experience can be related without being mistaken for one another.

Signalling can arrive while media does something else

RFC 3960, written by Gonzalo Camarillo and Schulzrinne, focuses on early media and ringback-tone generation. It explains why the caller’s experience cannot be inferred from a single status code. Before a session is accepted, media may flow from the network or a remote endpoint. Alternatively, a caller’s device may generate a local tone based on signalling. These are distinct mechanisms with different trust and failure properties.

If a gateway sends an in-band announcement—congestion, queue information or a special tone—locally generated ringback can mask it. If an endpoint waits for early media that never arrives, the caller may hear silence even though a 180 response exists in a trace. Forking makes the choice harder because more than one early dialog may supply signalling or media. RFC 3960 therefore describes policy trade-offs rather than blessing a universal rule that equates a status code with an audible fact.

The useful model has at least three clocks. The signalling clock records when a provisional response was received. The media clock records when packets became usable and from which source. The human clock concerns when a person noticed or acted. A fourth clock—the final dialog outcome—records acceptance or failure. They often advance in a familiar order, but the protocol does not warrant merging them into one timestamp called “answer.”

This is the analytical value of the specification boundary. A trace may prove that a message was received by a particular SIP element at a particular time. It cannot prove what a user’s speaker emitted, whether an operating system suppressed the alert, or whether a person was present. Those questions need evidence from their own control surfaces.

PRACK acknowledges a provisional message, not the call

Unreliable provisional delivery creates a practical problem. A status update can be lost, duplicated or reordered while the invitation is still pending. RFC 3262, by Jonathan Rosenberg and Schulzrinne, adds reliable provisional responses. A reliable 1xx response carries sequence information, and the user agent client acknowledges it with PRACK.

The mechanism deserves its name: it can establish that the provisional response was received in order. But the thing acknowledged remains provisional. A PRACK is not an ACK for a final 2xx response, not evidence of media receipt and not a declaration that a user answered. RFC 3262 even permits a final response to be sent before the PRACK arrives. Reliability improves custody of the status message; it does not enlarge the status message’s meaning.

This is a recurring engineering trap. Once an event has retransmission rules, correlation fields and a matching acknowledgement, dashboards tend to treat it as a durable milestone. Yet protocol reliability answers “did the peer receive this item?” rather than “did the world reach the business state we associate with it?” The more robust PRACK exchange is valuable precisely because it lets a system distinguish those questions.

Forking turns one call into several provisional stories

A SIP invitation can reach several contacts. One branch can return 180 while another supplies early media, rejects the request or eventually answers. A single call-level label such as “ringing” hides which branch spoke and whether its state still matters.

RFC 6228 adds the 199 response so a proxy can tell an upstream user agent that one early dialog has been terminated. The response is another provisional message. It does not end other early dialogs, and it does not replace the final response to the original invitation. Its value is selective: it lets the recipient discard state and media associated with a branch that will not become the final dialog.

RFC 6228 was authored by Christer Holmberg, not Schulzrinne. It belongs here as later evidence of the architecture’s consequences, not as another Schulzrinne credit. The document makes a crucial operational point visible: provisional state has provenance. “A 180 happened” is incomplete unless the record also knows which early dialog produced it and whether a later event superseded that branch.

This does not make 180 useless. A branch-scoped alerting-started event can be both honest and operationally valuable. It can measure routing progress, expose devices that never advance, and help compare the interval between invitation and final disposition. The condition is that the data model retain source, branch, time and superseding state instead of promoting the event into an answer receipt.

A careful attribution is part of careful evidence

Schulzrinne’s current Columbia profile lists him as Julian Clarence Levi Professor of Mathematical Methods and Computer Science and Professor of Electrical Engineering. The IETF Datatracker associates him with a large body of RFC work; its current snapshot lists 90 RFCs. Those facts establish the scale of his standards participation, but they do not justify turning this article into a lone-inventor biography.

The narrower attribution is more useful. RFC 3261 is collective. RFC 3262 is a Rosenberg–Schulzrinne document. RFC 3960 is an Informational RFC by Camarillo and Schulzrinne, not an Internet Standard. RFC 6228 is Holmberg’s later extension. Keeping those roles straight models the same discipline demanded of signalling evidence: name the source, preserve the scope and do not let a convenient label claim more than its provenance supports.

Sources