Summary

  • RFC 3960 treated 180 Ringing as evidence that the callee was being alerted, not as proof that an in-band tone or announcement had reached the caller.
  • A POTS-like client could play local ringback while no media packets arrived, switch to received media when packets appeared, and still keep negotiation, authentication, rendering and final call outcome as separate verdicts.

The most revealing sound in a SIP call could be the one the network never sent. A caller heard a familiar ring, yet the tone might have been manufactured by the caller's own terminal. The remote endpoint had reported progress; the local endpoint had filled the acoustic gap. When packets later arrived, the terminal could stop its tone and render the network stream instead. To the listener, it was one continuous wait. To the system, it was a change of evidence source.

RFC 3960 was published in December 2004 to explain early media and ringing-tone generation. Early media means media exchanged after an initial INVITE but before the final response. It includes ordinary ringback, announcements, queue messages and interactive prompts. The document's decisive move was to refuse a convenient equation: SIP progress signalling was not the same thing as observed media.

Its example policy begins with 180 Ringing. Before that response, a POTS-like user agent does not generate local ringing. After 180, if no incoming media packets are present, it generates ringback locally. If packets are present, it plays them and does not generate local ringback. The 180 means the callee is being alerted. The RFC says a server should send it for that condition regardless of the state of the early-media session.

That distinction mattered because signalling could not settle the media question. A simple server might send early media without reliable provisional responses. Another server might place an answer in a reliable provisional response only to satisfy preconditions, with no intention of sending early media then. RFC 3262 made provisional responses reliable through RSeq, RAck and PRACK; it did not turn a reliable signalling exchange into proof that RTP arrived. RFC 3312 could delay session progress until resource conditions were satisfied; an answer used in that process was still not an audio packet.

The separation was physical as well as logical. Signalling commonly crossed proxies, while media followed a path optimized for delay. Packets could reach the caller before the SIP response that might have described them. Conversely, signalling could arrive while connectivity work held media back. Waiting for a perfect “early media present” flag would not solve both orderings. RFC 3960 therefore preferred an observable local rule: provide progress feedback, then yield to actual incoming media.

Even packet arrival was not the end of the ladder. The RFC notes that a client might inspect content because packets could carry silence or comfort noise. RFC 3711 supplied authentication, integrity, replay protection and optional confidentiality for secure real-time media, but cryptographic acceptance still did not prove intelligible audio, successful decoding, speaker output or human understanding. 180, negotiated tuple, first packet, authenticated stream and heard announcement belonged in different receipts.

The offer/answer machinery supplied another independent layer. RFC 3264 defined how endpoints negotiate media parameters. RFC 3261 defined the SIP messages that carry those descriptions. Completing an offer and answer meant that parties had selected compatible parameters; it did not prove traffic. RFC 3960 also reminded clients to be ready to play packets before 200 OK, because waiting for the final signalling response could clip the first words.

Forking made the evidence problem harder. One INVITE could reach several user agents, each creating an early dialog and potentially an early stream. Mixing several audio streams would confuse the caller, and bandwidth might prevent receiving all of them. Under the gateway model, a client often selected one early dialog and muted the rest. The branch later accepted by a 2xx might be one of the muted branches. Unmuting it after acceptance created a new clipping window. The stream chosen for presentation was not necessarily the branch that would become the regular session.

RFC 3960 contrasted that gateway model with an application-server model. RFC 3959 defined the early-session disposition and option tag so early and regular media could use separate offer/answer exchanges. A client could reject or mute an early offer without muting the session intended to survive acceptance. Separation improved control over forking and transition, but did not abolish the need to choose which early stream to render.

Nor did Alert-Info close the gap. It could tell a client which alternative tone to use if the client decided to generate ringing locally. It did not tell the client when to begin. Tone selection and ringing authority were different decisions.

The security section exposed the stakes. An SDP transport address was not self-authenticating. An attacker who learned or guessed it might inject packets; a malicious offer could direct traffic at a victim. RFC 3960 discussed protected descriptions, media authentication and a willingness-to-receive handshake before large transfers. It also described a charging incentive: where early media was free and regular media billable, a rogue endpoint could keep a bidirectional early session open and never send 200 OK. Yet globally blocking bidirectional early media would also break legitimate IVR systems that collected input before answer. The remedy had to be policy-aware, not a single status-code rule.

The RFC's historical lesson is modest but durable. “Ringing” was not one fact. It could name remote alerting, a locally synthesized tone, an in-band stream, or the caller's perception. RFC 3960 preserved those layers precisely because a pleasant user experience depended on crossing them without pretending they were identical.

The RFC Editor's metadata record and errata search anchor the publication record. The supporting standards are RFC 3261, RFC 3262, RFC 3264, RFC 3959, RFC 3312 and RFC 3711.