VoNR Mobile Originated Call Procedure
VoNR Mobile Originated Call is the native 5G voice setup flow that begins when a user places a call from a VoNR-ready UE.
It starts with SIP INVITE, continues through IMS routing and answer signaling, and succeeds only when voice media actually becomes stable.
Introduction
This procedure assumes the UE is already registered and IMS-ready for voice service.
That means the main troubleshooting job is no longer basic registration. It is understanding how the INVITE moves through IMS, how the far end answers, and whether the media path truly follows.
What Is VoNR Mobile Originated Call in Simple Terms?
- What starts the procedure: The user places a voice call on a VoNR-ready UE.
- What the UE and network want to achieve: Set up a native 5G voice session through IMS and RTP media continuity.
- What success looks like: The far end answers, ACK completes, and media flows cleanly.
- What failure means: The call fails during routing, signaling negotiation, or post-answer media setup.
Why this procedure matters
MO call setup is one of the clearest real-service proofs that VoNR registration and IMS readiness were actually useful. It turns preparation into a user-visible voice session.
Quick Fact Sheet
| Procedure name | VoNR Mobile Originated Call |
|---|---|
| Domain | Native 5G voice call setup initiated by the calling UE |
| Main trigger | A user starts a voice call while the UE is already voice-ready on 5G SA |
| Start state | UE is registered in IMS and ready for VoNR service |
| End state | The SIP dialog is established and bidirectional voice media flows |
| Main nodes | Calling UE, gNB, UPF, P-CSCF, S-CSCF, remote IMS side, called UE |
| Main protocols | SIP INVITE, SDP offer and answer, RTP, QoS flow handling |
| Main success outcome | INVITE reaches the far end, the called side answers, ACK completes, and media starts |
| Main failure outcome | Call setup fails because of IMS routing, SDP negotiation, policy, or access-side continuity issues |
| Most important messages | INVITE, 100 Trying, 180 Ringing, 200 OK, ACK |
| Main specs | TS 24.229, TS 23.228, TS 23.501, TS 23.502 |
Preconditions
- The calling UE is already VoNR-ready and registered in IMS.
- The network allows native VoNR service for the subscriber and scenario.
- The called party is routable through the relevant IMS and interworking path.
- Voice media QoS and user-plane continuity are available.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| Calling UE | Starts the SIP dialog and offers the media profile for the new voice session. |
| gNB and UPF | Carry the signaling and later media path over the active 5G service context. |
| P-CSCF and S-CSCF | Route and control the SIP call setup through IMS. |
| Remote IMS side and called UE | Receive the INVITE, ring the user, and complete answer signaling. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries radio access and QoS support for the ongoing voice setup and media continuity. |
| IMS SIP path | UE <-> IMS core <-> called side | Carries the SIP INVITE, provisional responses, final answer, and ACK. |
| User-plane RTP path | UE <-> UPF <-> remote side | Carries the actual voice media after the SIP dialog is established. |
End-to-End Call Flow
Calling UE IMS core Called side
|-- INVITE ----------->|--------------------->|
|<-- 100 Trying -------|<---------------------|
|<-- 180 Ringing ------|<---------------------|
|<-- 200 OK -----------|<---------------------|
|-- ACK -------------->|--------------------->|
|=========== RTP voice media ==================|Major Phases
| Phase | What happens |
|---|---|
| 1. Call intent | The user dials and the UE decides to start a native VoNR call using the active IMS registration. |
| 2. SIP offer and routing | The UE sends INVITE with SDP and IMS routes it toward the destination side. |
| 3. Provisional progress | The network returns Trying and Ringing while the remote side processes the call. |
| 4. Answer and media establishment | The called side answers with 200 OK, ACK completes, and RTP media begins. |
Step-by-Step Breakdown
Calling UE creates the new voice session
Sender -> receiver: Calling UE -> IMS core
Message(s): SIP INVITE with SDP offer
Purpose: Start the VoNR call by describing the intended media session and destination.
State or context change: The call moves from idle voice readiness into active session setup.
Note: This is the best place to inspect caller identity, Request-URI, and codec offer together.
IMS routes the call toward the destination
Sender -> receiver: P-CSCF -> S-CSCF -> remote IMS side
Message(s): INVITE routing and policy handling
Purpose: Find the called party and decide how the call should be handled inside IMS.
State or context change: The session is now under IMS call-control routing rather than only local UE intent.
Note: Many MO failures are really destination-routing or service-policy failures, not access failures.
Calling side receives provisional progress
Sender -> receiver: Remote side -> calling UE
Message(s): 100 Trying and 180 Ringing
Purpose: Show that the far side is being reached and processed.
State or context change: The call is progressing but not yet answered.
Note: If you get Trying but never Ringing, routing and remote-service processing become prime suspects.
Call is answered and media starts
Sender -> receiver: Called side -> calling UE
Message(s): 200 OK, ACK, RTP media
Purpose: Complete the SIP dialog and start actual voice transport.
State or context change: The session transitions from setup to active in-call media.
Note: Final success is not only 200 OK. Media must also start with a stable negotiated codec and QoS path.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| INVITE | SIP | Calling UE -> IMS | Starts the mobile-originated voice session. | Inspect Request-URI, SDP offer, and whether the right IMS profile is in use. |
| 100 Trying | SIP | IMS -> calling UE | Shows the INVITE is being processed. | Useful first checkpoint that the request entered the IMS path. |
| 180 Ringing | SIP | Called side -> calling UE | Shows the far end is alerting. | If absent, inspect remote routing and called-user treatment. |
| 200 OK | SIP | Called side -> calling UE | Confirms the far side accepted the call. | Inspect SDP answer and negotiated media profile. |
| ACK | SIP | Calling UE -> called side | Completes the SIP dialog setup. | A missing ACK can make a trace look answered while the session still collapses. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Request-URI and called number | The destination identity of the call. | INVITE | Shows whether IMS is routing the call to the intended destination. | Wrong destination formatting causes routing or policy problems quickly. |
| SDP codec offer | The media profile proposed by the calling UE. | INVITE | Determines whether the remote side can accept and create usable voice media. | Codec mismatch or malformed SDP is a classic call-setup blocker. |
| IMS routing result | How the call is handled inside the IMS core. | INVITE progression | Separates access-side success from service-layer routing success. | A healthy NR bearer does not guarantee healthy IMS routing. |
| QoS readiness for media | Whether the media path and voice treatment are appropriate once the call is answered. | Post-answer media phase | A clean SIP setup can still hide poor voice treatment if media QoS is weak. | Poor QoS leads to silence, delay, or one-way audio after setup. |
| ACK continuity | Whether the final handshake is really completed. | After 200 OK | Needed to confirm the dialog is operationally established. | Missing ACK can produce odd half-open call symptoms. |
Success Criteria
- The INVITE reaches the correct destination path inside IMS.
- The called side returns meaningful provisional progress.
- The final 200 OK and ACK complete successfully.
- RTP media starts with the negotiated codec and usable voice quality.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| INVITE is sent but no meaningful progress returns | The call failed early in IMS routing or service policy handling. | Request-URI, subscriber policy, and IMS route selection. | INVITE, lack of Trying or Ringing | IMS SIP path | This is usually not a radio problem. |
| Ringing appears but answer never stabilizes | The far end was reached, but final negotiation or answer handling failed. | Remote policy, SDP compatibility, and 200 OK handling. | 180 Ringing, 200 OK | IMS SIP path | Progress before failure narrows the search dramatically. |
| 200 OK arrives but media is broken | The call was accepted, but RTP, codec negotiation, or QoS continuity failed. | SDP answer, RTP path, QoS treatment, and packet flow. | 200 OK, RTP start | User plane and IMS | Treat this as a post-signaling media problem, not a pure setup failure. |
| Call setup is slow or intermittent | IMS routing, DNS, policy, or remote-side treatment is inconsistent. | Repeated setup timing across sessions. | INVITE, provisional responses | IMS SIP path | Timing patterns often reveal control-path bottlenecks. |
What to Check in Logs and Traces
- Start with the INVITE request and SDP offer.
- Track whether the call reached Trying, Ringing, or 200 OK before failing.
- If answer succeeds, switch immediately to RTP and QoS inspection.
- Use the last successful SIP checkpoint to narrow the failure domain quickly.
Related Pages
Related sub-procedures
- VoNR Registration
- VoNR Mobile Terminated Call
- VoNR Call Termination
- IMS PDU Session Establishment for Voice
Related message reference pages
Related troubleshooting pages
FAQ
What is a VoNR Mobile Originated Call?
It is the native 5G voice call setup flow started by the calling UE after VoNR readiness already exists.
Does the UE need IMS registration first?
Yes. The UE must already be voice-ready inside IMS before starting a normal VoNR MO call.
What proves the call really succeeded?
A successful 200 OK plus ACK and stable bidirectional RTP media.
What should I inspect first in a failure?
Start with INVITE routing, SDP offer, and whether the trace progressed to Trying, Ringing, or 200 OK.
Why can signaling succeed but voice still fail?
Because media path, codec negotiation, or QoS continuity can still break after the SIP dialog is accepted.