The VoNR stack — four gates, one failure map
VoNR troubleshooting feels chaotic until you realise a voice call is not one thing — it is a chain of four gates, and a call that fails always fails at exactly one of them. The art of fast root-cause is not knowing everything; it is knowing which gate the call died at, because each gate has its own short list of causes. A registration problem and a one-way-audio problem are universes apart, and the worst thing you can do is debug the wrong universe. So before any packet capture, locate the gate.
The four gates, in order: (1) Registration — the UE registers to 5G and brings up the IMS PDU session; (2) IMS registration — the UE registers to the IMS core over SIP; (3) Call setup — the SIP INVITE dialog that establishes the session and the voice QoS flow; (4) Media — the RTP audio actually flowing both ways. Signalling lives in gates 1–3; audio quality lives in gate 4. “Can't make calls” is a gate 1–3 problem; “call connects but no/one-way audio” is always gate 4.
Where this lives in 3GPP. IMS itself is TS 23.228; the 5G registration and PDU session procedures are TS 23.502; the QoS model and 5QI table are TS 23.501; EPS Fallback is in TS 23.502; the MMTEL voice service is TS 24.173/24.229; and SIP itself is IETF RFC 3261. For the full message-by-message picture, the companion VoLTE & VoNR call-flow article traces every packet; this guide is the fault-finding layer on top.
Gate 1 — 5G registration & the IMS PDU session
Before any SIP exists, the UE must be registered to 5G and have a working IMS PDU session. Voice does not ride the default internet PDU session — it needs a dedicated one to the IMS, on the right slice, with a P-CSCF to talk to. Three things have to be right:
- The IMS DNN/APN. The IMS PDU session must be established to the configured IMS DNN (the 5G equivalent of the IMS APN). Wrong or missing DNN → no IMS PDU session → no voice, full stop.
- The slice (S-NSSAI). The IMS PDU session uses a specific S-NSSAI; if the UE's allowed NSSAI or the URSP/subscription does not include it, the session is rejected.
- P-CSCF discovery. During PDU session establishment the network returns the P-CSCF address(es) (via the PCO/ePCO). No P-CSCF address → the UE has no IMS entry point → IMS registration can never start.
Gate-1 tell. If the UE never even sends a SIP REGISTER, you are almost always at gate 1: check that the IMS PDU session came up (correct DNN & S-NSSAI) and that P-CSCF discovery returned an address. No P-CSCF, no SIP — and no amount of IMS-core debugging will help, because nothing reached the IMS core.
Gate 2 — IMS registration & the 403/408 RCA
With a P-CSCF in hand, the UE registers to IMS over SIP. The healthy exchange is a two-step IMS-AKA challenge, and knowing what “normal” looks like is half the battle — a 401 is expected, not an error.
| What you see | Meaning | Root cause & fix |
|---|---|---|
| 401, then 200 OK | Normal IMS-AKA | Healthy — nothing to do |
| 403 Forbidden | Known, but not allowed | Provisioning: subscriber/IMPU not provisioned for IMS/MMTEL in HSS/UDM; wrong identity/profile |
| 401 loop (never 200) | Auth keeps failing | Credential/AKA mismatch; K/OPc or IMPI/realm wrong; clock/sequence issues |
| 408 / timer-F | No response at all | Transport: P-CSCF unreachable, signalling (5QI 5) flow down, NAT/firewall dropping SIP |
| 500 / 503 | IMS core error/overload | S-CSCF/HSS fault or congestion — escalate to core |
The two you will meet most are 403 and 408, and they could not be more different. A 403 Forbidden is a provisioning verdict — the subscriber reached the IMS and was refused, so the problem is in the subscriber data (HSS/UDM, IMPU/IMPI, MMTEL profile), never in the radio. A 408 / timer-F timeout means the SIP simply never got a reply — a transport problem: the P-CSCF is unreachable, the 5QI 5 signalling flow is down, or a firewall/SBC is eating the messages. One sends you to the provisioning team, the other to the transport/core-edge team.
See every VoNR packet at PCAP level
This guide finds the gate; the companion VoLTE/VoNR deep dive traces every SIP, NAS, NGAP and Diameter message that crosses it — the perfect pairing for serious RCA. Free to read.
Read the VoLTE/VoNR call-flow deep diveGate 3 — the SIP INVITE call flow
Registered UEs make calls with an INVITE dialog. Critically, the dedicated voice QoS flow (5QI 1) is set up during this dialog — around the 183 Session Progress — so a call can pass the SIP exchange and still fail for media reasons if that flow does not come up.
If the call dies in this ladder, the SIP response code tells you where: a 408 means signalling is not reaching the far side; 480 Temporarily Unavailable and 486 Busy Here are terminating-side states; 488 Not Acceptable Here is an SDP/codec mismatch (the two ends could not agree on a media format); and 5xx points at an IMS-core or application-server fault. We tabulate them all in Chapter 9.
The QoS side — 5QI/QCI & the voice flow
Voice is not best-effort. A VoNR call needs the right QoS flows on the IMS PDU session, and a surprising share of “voice” faults are really QoS-flow faults. The relevant 5QI values (TS 23.501) and their LTE QCI equivalents:
| 5QI | Type | Used for | LTE QCI |
|---|---|---|---|
| 1 | GBR | VoNR voice media (PDB ~100 ms) | QCI 1 |
| 2 | GBR | Conversational video | QCI 2 |
| 5 | Non-GBR | IMS signalling (SIP) — highest priority | QCI 5 |
| 7 | Non-GBR | Voice/video (buffered/interactive) | QCI 7 |
| 9 | Non-GBR | Default internet PDU session | QCI 9 |
A working VoNR call needs two flows on the IMS PDU session: the always-present 5QI 5 signalling flow (so SIP can even travel) and, at call setup, a dedicated 5QI 1 GBR voice flow. The failure modes are precise: if the 5QI 5 flow is broken, IMS registration or INVITE times out (gate 2/3, a 408); if the 5QI 1 flow fails to set up, the SIP can complete but media has nowhere to go — a connected call with no or one-way audio (gate 4). That single distinction routes half of all VoNR tickets correctly.
EPS Fallback — triggers & when it is wrong
Not every 5G voice call stays on 5G. EPS Fallback is the designed-in escape hatch: when the network or coverage cannot deliver VoNR at the moment of the call, the gNB hands the UE down to LTE and the call completes as VoLTE. It is normal, intended behaviour during early 5G — but a fallback rate that is too high, or fallback where VoNR should work, is a fault.
The trigger is specific: the gNB sees the request to set up the 5QI 1 voice flow and decides it cannot serve VoNR here and now — because VoNR is not deployed on this cell, NR coverage is too weak to sustain a GBR voice flow, or a policy directs voice to LTE. It then moves the UE to EPS by redirect (RRC release with redirect) or handover, and the call proceeds as VoLTE. When investigating “why did my 5G call go to 4G,” confirm whether VoNR is even enabled on that cell and whether the 5QI 1 flow could be supported — the fallback is usually a symptom, not the disease.
Gate 4 — media: one-way audio & RTP
The most frustrating VoNR fault is the one where everything “works”: the call connects, the phones show a timer counting up — and one side hears nothing, or neither does. The SIP dialog is healthy, so the fault is purely at the media layer, and you debug it completely differently from a signalling fault.
| Media symptom | Likely cause | Where to look |
|---|---|---|
| One-way audio | 5QI 1 flow up one direction; asymmetric path | QoS-flow filters both ways; NAT/firewall/SBC; SDP addresses |
| No audio at all | 5QI 1 flow not established; media not anchored | Voice QoS-flow setup; IMS-AGW/media gateway; SDP |
| Audio then drops | QoS flow released; radio/retention | 5QI 1 retention; handover/beam events mid-call |
| Robotic / choppy | Packet loss / jitter / wrong codec | RTP loss & jitter; AMR-WB vs AMR-NB; jitter buffer |
| No ringback | Early-media / 183 SDP issue | 183 Session Progress SDP; early-media handling |
The RCA decision tree
Put it together and VoNR triage becomes a two-minute routine. Ask the questions in order and the gate falls out.
SIP error-code quick reference
| Code | Name | In VoNR it usually means |
|---|---|---|
| 100 | Trying | Provisional — request received (normal) |
| 180 | Ringing | Far end alerting (normal) |
| 183 | Session Progress | Early media / SDP answer; 5QI 1 flow set up here |
| 200 | OK | Success (REGISTER or INVITE) |
| 401 | Unauthorized | IMS-AKA challenge on REGISTER (normal first step) |
| 403 | Forbidden | Provisioning/identity — not allowed for IMS/MMTEL |
| 404 | Not Found | Number/route unknown — routing/ENUM |
| 408 | Request Timeout | Transport — no response (P-CSCF/5QI 5/firewall) |
| 480 | Temporarily Unavailable | Terminating UE not reachable/registered |
| 486 | Busy Here | Called party busy |
| 488 | Not Acceptable Here | SDP/codec mismatch (AMR-WB/NB) |
| 500 / 503 | Server Error / Service Unavailable | IMS core/AS fault or overload |
| 504 | Server Time-out | Downstream element not responding |
| 603 | Decline | Call declined by user/policy |
VoNR KPIs that matter
The same four gates define the KPIs — each gate has a success rate, and a dip in one points straight at its causes.
VoNR call setup success rate (CSSR) = (INVITE 200 OK) / (INVITE attempts)
Voice QoS-flow (5QI 1) setup success = (flow established) / (flow requested)
EPS Fallback rate = (calls falling back to LTE) / (VoNR call attempts)
Call drop rate = (abnormal releases) / (established calls) · plus MOS for audio quality
The triage mindset. Don't ask “why is voice broken?” — ask “which gate, and what's its success rate?” Registration KPI down → gate 1/2. CSSR down → gate 3 (read the SIP code). 5QI 1 setup down or fallback up → QoS/coverage. Drops or poor MOS with good setup → gate 4 (media/radio retention). The KPI is the gate.
Frequently asked questions
What is the difference between VoNR and EPS Fallback?
VoNR carries voice natively on 5G NR using an IMS session and a 5QI 1 QoS flow. EPS Fallback moves the call to LTE (as VoLTE) when the cell/coverage can't support VoNR at setup. Fallback is normal early on; excessive or unexpected fallback signals missing VoNR support, weak NR coverage or a 5QI 1 problem.
What does SIP 403 Forbidden mean on REGISTER?
The subscriber reached IMS but is not allowed to register — a provisioning/identity problem (not provisioned for IMS/MMTEL in HSS/UDM, wrong IMPU/IMPI or profile). Fix it in subscriber data, not the radio.
What causes one-way audio?
Signalling succeeded but RTP flows one way: a 5QI 1 voice flow up in only one direction or with wrong filters, an asymmetric path through NAT/firewall/SBC, or an SDP address/port mismatch. Debug at the media layer — trace RTP both ways and check the voice flow and SDP.
Which 5QI values does VoNR use?
5QI 1 (GBR) for the voice media, 5QI 5 (non-GBR, highest priority) for IMS signalling; video uses 5QI 2 and the default internet session 5QI 9. A call needs both the 5QI 5 signalling flow and a dedicated 5QI 1 voice flow.
How do I troubleshoot an IMS registration failure?
Work the gates: confirm the IMS PDU session (DNN, S-NSSAI) and P-CSCF discovery; then read the REGISTER exchange — 401 then 200 is normal, 403 is provisioning, a 408/timer-F is transport (P-CSCF/5QI 5/firewall). Each symptom maps to one layer.
What is the VoNR call-setup SIP flow?
INVITE (SDP offer) → 100 Trying → 183 Session Progress (SDP answer, 5QI 1 set up) → PRACK → 180 Ringing → 200 OK → ACK, then RTP on the 5QI 1 flow. Failures map to SIP codes (408/480/486/488/5xx).
VoNR troubleshooting is not about memorising IMS — it is about locating the gate. Is there a REGISTER? A 200 OK? A 200 to the INVITE? Audio both ways? Four questions route you to four short cause-lists, and the SIP code or 5QI flow tells you the rest. For the full message-by-message reference behind this method, read the companion VoLTE & VoNR call-flow deep dive.