A Mechanism From Another Era
If you have ever captured a VoLTE call setup, you have seen them: SDP bodies full of a=des:qos and a=curr:qos attributes, a 183 Session Progress carrying an answer, a PRACK, then an UPDATE, another 200 OK – all before the phone even starts ringing.
This is the preconditions framework, defined in RFC 3312 (with RFC 4032 refinements) and woven deeply into the IMS signaling in 3GPP TS 24.229. The idea is elegant and comes from a real problem: in a mobile network, the media path is not free. Before a VoLTE call can carry audio, the network has to establish a dedicated bearer (QCI 1 in LTE) for the voice packets. If the called phone starts alerting before that bearer exists, two bad things can happen: the callee answers and the first words are clipped, or – worse – the bearer setup fails entirely and the callee picks up a dead call.
The failure mode this prevents: ghost ringing
A phone that alerts before its voice bearer is ready produces a call that rings but cannot be answered, or a “connected” call with dead air. The industry calls it ghost ringing, and it is exactly the experience preconditions were invented to eliminate.
Preconditions solve this by making resource reservation part of the SIP offer/answer exchange. Both ends declare their desired QoS, report their current status, and the call is only allowed to progress to alerting once both sides confirm that resources are in place. End-to-end, symmetric, standards-pure. And in a world where every endpoint is a 3GPP-compliant UE talking to another 3GPP-compliant UE, it works beautifully.
The Real World Has Asterisk in It
Our platform exists for a different world. The whole point of volte.io is that a Tier-3 operator, an MVNO, or a private network can connect any SIP application to a carrier-grade IMS core: an Asterisk-based PBX, a FreeSWITCH conferencing platform, a contact center, an enterprise SBC, a voicebot.
And that is where preconditions stop being elegant and start being a compatibility minefield:
- Many SIP applications and enterprise SBCs do not implement the preconditions framework at all. They see
a=des:qos mandatoryattributes they don’t understand, or they reject the call outright. - Even implementations that tolerate the attributes often stumble over the procedures: UPDATE requests mid-dialog, reliable provisional responses (100rel/PRACK), and an SDP answer arriving in a 183 rather than the 200 OK. UPDATE support in particular is patchy – some stacks handle it without SDP but not with, some renegotiate media when they shouldn’t, some simply drop it.
- Debugging these failures is miserable, because the call doesn’t fail cleanly. It fails as one-way audio, as a call that rings but can’t be answered, or as an interop ticket that bounces between three vendors.
The textbook answer is: fix the applications. Make every PBX, every media server, every SBC precondition-aware. But that answer inverts our value proposition. We don’t want to hand every customer a 3GPP reading list before they can connect a PBX. We want IMS to meet the applications where they are.
The other textbook answer is: disable preconditions network-wide. Some live VoLTE networks do exactly that. But whether a UE uses preconditions is governed by carrier configuration baked into the device – and if you are an MVNO riding on a host network, or a platform serving many operators, you don’t control those settings. The phones will send preconditions whether you like it or not. Somebody in the network has to speak the language competently.
The Element That Actually Knows
So we asked a different question: what is the precondition mechanism actually for, and where in the network does that purpose live?
Strip away the syntax, and the purpose is a single guarantee: don’t alert the callee until the access-side resources exist. That guarantee is entirely about the radio access side. An Asterisk box in a data center has no concept of a dedicated bearer; for it, “resources” were reserved the moment it allocated an RTP port. The precondition attributes carry no information it can act on.
Now look at who does know about the bearer. In the IMS architecture, exactly one SIP element has that knowledge: the P-CSCF. Through the Rx interface toward the PCRF, the P-CSCF requests the dedicated bearer when the SDP answer is known (AAR), and – crucially – it can subscribe to the outcome. When the PCRF signals INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION, the P-CSCF knows, authoritatively, that the QCI-1 bearer is up. No other SIP hop in the call path has this information. Not the S-CSCF, not the application server, and certainly not the PBX at the far end.
The insight in one sentence
Terminate the preconditions at the P-CSCF. Toward the UE, it speaks fluent RFC 3312 – it participates in the offer/answer, absorbs the UPDATE exchange, and gates call progress on the actual Rx confirmation of the bearer. Toward the core and the application, it presents clean, ordinary SIP with plain SDP. The semantics are preserved exactly where they matter; the syntax is hidden exactly where it only causes harm.
Terminating Preconditions in Practice
The diagram below traces a mobile-terminated VoLTE call – a SIP application calling a subscriber on our network. Watch the boundary at the P-CSCF: to the left, the application exchanges ordinary SIP; to the right, the handset runs the full RFC 3312 dance while the Rx interface drives the real bearer. The handset does not ring until the PCRF confirms the QCI-1 bearer is actually up.
Isn’t That Against the Standard?
Purists will note that preconditions are specified as an end-to-end mechanism, with a segmented status model (local and remote) that assumes both endpoints participate. Terminating them mid-path means our P-CSCF asserts the remote precondition status on behalf of a far end that has never heard of RFC 3312.
Fair point – but 3GPP itself blessed this pattern long ago, just at different network borders:
MGCF at the CS border
When an IMS call breaks out to the circuit-switched world, the MGCF performs precisely this precondition interworking. TS 29.163 describes it in detail.
IBCF at the NNI
At the network-to-network interface, IBCF profiles per TS 29.165 routinely strip or terminate preconditions toward peers that don’t support them.
IR.92 puts the mandate on the UE
GSMA IR.92 mandates precondition support in the UE. Whether and how the network uses them is explicitly operator policy.
In other words: the standard has always accepted that preconditions end where the bearer-managed domain ends. We simply draw that boundary at the P-CSCF – the first hop, and the only hop that holds the bearer state the mechanism was invented to protect. One could argue this is more faithful to the intent of RFC 3312 than an “end-to-end” exchange that a mid-path B2BUA mangles into one-way audio.
What It Takes to Get Right
None of this is free. Terminating preconditions makes the P-CSCF a genuine back-to-back user agent with its own offer/answer state – which suits our architecture, since our P-CSCF and access SBC are one integrated element anyway. But a few things deserve engineering respect:
UPDATE disambiguation
An UPDATE that merely refreshes precondition status must be absorbed locally; an UPDATE that carries a real media change – a codec switch, call hold, an added video stream – must be passed through faithfully. Getting this distinction wrong is the classic way to break mid-call features while “just” handling preconditions.
Gating on Rx, not on optimism
The easy shortcut is to declare local preconditions met the moment the AAR is sent. The correct behavior is to wait for the PCRF’s confirmation that the bearer was actually installed – and to tear the call down cleanly if setup fails or times out, rather than letting it die in silence.
Race conditions
The Rx confirmation and the SIP state machine (183, PRACK, UPDATE) advance independently and in whatever order the network feels like today. This is exactly the class of timing-sensitive behavior that no manual test catches twice in a row.
That last point is why we run automated end-to-end acceptance tests with real devices against every release – because the only way to trust precondition handling is to prove it, continuously, on the hardware your subscribers actually carry.
Simple for Everyone Else
The result, from our customers’ perspective, is refreshingly boring – which is exactly the point. Both sides of the call get precisely what they expect:
The VoLTE handset
Sees a fully standards-compliant IMS that honors preconditions, doesn’t ring before the bearer is ready, and delivers clip-free audio from the first syllable.
Your SIP application
An Asterisk, a FreeSWITCH, an enterprise SBC, a voicebot – each sees a well-behaved SIP peer sending SDP it has understood for twenty years. No des:qos, no surprise UPDATE.
Nobody has to read TS 24.229 to connect an application
That was the goal all along. The hard, timing-sensitive, standards-heavy part lives in one place – the P-CSCF – so integrating your application is a plain-SIP exercise, not a 3GPP research project.