SIP Early Media and Codecs: Ringback Tone Audio Paths in VoIP

You dial a number. You wait. Silence. Is the call going through? Did it fail? Or is someone on the other end just slow to pick up? In traditional phone networks, you hear that familiar ringing sound almost instantly. It tells you the system is working. In Voice over IP (VoIP), getting that feedback right is surprisingly complex. The silence you experience often isn't a broken line; it's a breakdown in how SIP early media handles audio before the call connects.

This guide breaks down why your callers might be hearing nothing, how ringback tones actually travel across digital networks, and what you can do about codec mismatches that kill audio paths. We will look at the signaling rules defined in RFC 3960, the role of provisional responses like 183 Session Progress, and practical fixes for PBX and softphone configurations.

What Is SIP Early Media?

In the world of telephony, "early media" refers to any audio exchanged between two parties before the session is fully established. In standard SIP signaling, a call isn't officially "connected" until the receiver sends a 200 OK response. Before that moment, the caller and callee are technically strangers in the eyes of the protocol.

However, users expect immediate feedback. They want to hear ringing, busy signals, or Interactive Voice Response (IVR) prompts like "Your call is important to us." To deliver this, network elements-such as gateways, application servers, or Session Border Controllers (SBCs)-send RTP audio streams during the setup phase. This is early media.

The concept was formalized in RFC 3261 (the base SIP spec from 2002) but clarified significantly by RFC 3960 in 2004. RFC 3960 exists specifically to solve the chaos of early media, defining how ringing tones should be generated when multiple devices might try to send audio at once. Without these rules, you could hear three different ringback tones overlapping each other if your call forks to several extensions simultaneously.

The Two Models of Ringback Generation

To understand why your audio path fails, you need to know where the ringback tone comes from. There are two primary architectures defined in the standards:

1. The Gateway Model: Here, the ringback tone originates from the Public Switched Telephone Network (PSTN). When you call a landline, the legacy switch generates the ringing sound. A VoIP gateway connected to the PSTN captures this analog signal, digitizes it into RTP packets, and sends it back to the caller via early media. This preserves the exact feel of a traditional phone call.
2. The Application Server Model: In this scenario, a server within the SIP network generates the audio digitally. This is common for IVR menus, queue announcements in contact centers, or custom ringback tones. The server sends a 183 Session Progress message with an SDP offer, opening an RTP stream to play the file.

The problem arises when these models clash. If your endpoint expects the network to provide audio (Gateway Model) but the network assumes the phone should generate its own local tone (Application Server logic missing), you get silence. The key is knowing which model your infrastructure uses and configuring the endpoints accordingly.

Signaling the Path: 180 vs. 183 Responses

The difference between hearing a ringback and hearing silence usually boils down to two specific SIP status codes: 180 Ringing and 183 Session Progress. Confusing these is the most common cause of early media failures.

Here is the rule of thumb derived from RFC 3960 best practices:

• If you want the caller to hear a tone generated by the network (like a busy signal or IVR), you must send a 183 Session Progress containing an SDP body. This tells the caller's phone, "Open your RTP port, I am sending audio."
• If you want the caller's phone to generate its own generic ringing sound, you send a 180 Ringing without SDP. The phone sees no incoming audio stream, so it plays its internal beep-beep sound.

A major pitfall occurs when a network sends a 183 without SDP, or a 180 with SDP. These combinations are technically ambiguous and often lead to interoperability issues. Some phones will ignore the audio entirely, while others may crash or drop the call. Stick to the clear patterns: 183 + SDP for network audio, 180 alone for local audio.

Codec Mismatches in Early Media

Even if your signaling is perfect, your ringback tone can still fail due to codec incompatibility. This is a subtle but frequent issue in multi-vendor environments.

When a 183 Session Progress arrives, it carries an SDP offer proposing specific codecs for the early media stream. For example, the network might propose G.729 because it saves bandwidth. However, many modern softphones and mobile apps prioritize wideband codecs like Opus or even stick strictly to G.711 (PCMU/PCMA) for compatibility.

If the caller's device does not support G.729, it cannot decode the incoming RTP packets. The result? The SIP signaling shows the call is progressing, the RTP port is open, but the user hears nothing-or worse, static noise. This happens specifically in the pre-answer phase. Interestingly, the actual conversation after the 200 OK might work perfectly if the final SDP negotiation settles on a mutually supported codec like G.711.

To fix this, ensure that your SBCs or PBXs include a universal fallback codec, typically G.711 µ-law (PCMU) or G.711 A-law (PCMA), in every early media SDP offer. Most endpoints support G.711 natively. If you force a proprietary or less common codec in the 183 response, you risk breaking the audio path for a significant portion of your users.

The Role of PRACK and Reliable Provisional Responses

In robust VoIP deployments, especially those involving mobile networks (IMS) or long-distance trunks, you will encounter PRACK. Defined in RFC 3262, PRACK stands for Provisional Acknowledgement. It works in tandem with the 100rel extension.

Why does this matter for ringback tones? Because early media requires a negotiated state. When a UAS (User Agent Server) sends a 183 with SDP, it is making an offer. The UAC (User Agent Client) needs to acknowledge this offer before stable media flow begins. PRACK serves as that acknowledgment.

Without reliable provisional responses (100rel/PRACK), there is a race condition. The caller might start playing audio before the network has finished setting up the media path, or the network might stop sending audio because it never received confirmation that the caller is ready. In complex scenarios involving forking or load balancing, missing PRACK messages can cause the early media stream to terminate prematurely, cutting off the ringback tone halfway through.

If you are troubleshooting intermittent ringback drops, check your SIP traces. Look for the INVITE, followed by 183, then PRACK. If the PRACK is missing or rejected, your early media session is unstable.

Troubleshooting Silent Calls: A Practical Checklist

When users complain about "no ringback," follow this logical path to isolate the issue:

1. Capture the Trace: Use Wireshark or a vendor-specific debugger to capture the SIP dialog. Filter for the specific Call-ID.
2. Check for 183 vs. 180: Does the network send a 183 Session Progress? If it only sends 180 Ringing, the expectation is that the *client* generates the tone. If the client is configured to wait for network audio, it will stay silent.
3. Inspect the SDP: If a 183 is present, does it contain an SDP body? If not, the client won't open its RTP port. Look at the `m=audio` line. Are the codecs compatible with the client?
4. Verify RTP Flow: Are RTP packets actually flowing from the server to the client? If yes, but there is no sound, it is likely a codec mismatch or a firewall blocking the UDP ports.
5. Review Timeouts: Many platforms, such as PortaSwitch or Grandstream UCM, have settings like `early_media_timeout`. If the network takes too long to start sending RTP after the 183, the platform might give up and stop trying, resulting in silence. Adjust these timeouts if your network latency is high.
6. Disable SIP ALG: Check intermediate routers. SIP Application Layer Gateways (ALG) often mangle SDP bodies in provisional responses, stripping out necessary attributes or altering IP addresses. Disabling SIP ALG on edge routers is a standard best practice for VoIP reliability.

Conclusion

SIP early media is not magic; it is a carefully choreographed exchange of signaling and media. By respecting the distinction between 180 and 183 responses, ensuring codec compatibility in SDP offers, and validating PRACK flows, you can eliminate the frustrating silence that plagues many VoIP deployments. The standards are clear, but implementation varies. Your job is to align your configuration with the RFC expectations, ensuring that the audio path opens reliably the moment the call begins.