Voice over NR (VoNR) Call Flow

Introduction

A VoNR call flow is the end-to-end sequence that turns "the user pressed dial" into RTP voice packets riding a guaranteed-bit-rate radio bearer. It is fundamentally a two-layer procedure: a SIP/SDP dialog in the IMS application layer negotiates the codec, and that negotiation triggers the 5G core and RAN to build a dedicated 5QI=1 QoS flow underneath it. Neither layer works without the other, and the interesting failures happen precisely where they meet.

This flow sits at the top of the 5G stack, after everything else is already in place: the UE must be 5G-registered with a VoNR verdict (IMS VoPS set), IMS-registered with the S-CSCF, and holding an established IMS PDU session carrying the default 5QI=5 signalling flow. Only then can this MO call proceed. It runs every time a subscriber originates or receives a voice call on a VoNR-capable network.

It matters because voice is unforgiving. The call must not ring until a media path exists (the SIP precondition mechanism enforces this), and the media path is a real GBR reservation that the gNB must admit. Because the flow crosses SIP, NGAP, RRC, PCF/SMF policy, and SDAP mapping, a "one-way audio" or "call fails to connect" ticket almost always localises to one specific step — which is why following the sequence message by message is the fastest route to the root cause.

Why the VoNR call flow works this way

Concretely, three design choices shape the whole flow. First, signalling and media are separated: all SIP rides the always-on 5QI=5 non-GBR flow (QFI 9), while voice media gets its own 5QI=1 GBR flow (QFI 1) built on demand — so signalling is never starved by media admission and vice versa. Second, the bearer is created mid-dialog, not up front: the network waits until the SDP answer fixes the codec so it reserves exactly the right guaranteed bit rate, no more. Third, alerting is gated on the bearer via SIP preconditions, so a call can never ring without a media path — eliminating the "answered but dead air" failure. The flow below is the concrete realisation of those three choices.

Call flow — SIP setup

Zooming out from the packet-level detail above, this is the end-to-end SIP message sequence for the VoNR MO call — INVITE through ACK — carried on the IMS PDU session, with the dedicated 5QI 1 QoS flow built mid-dialog once the SDP answer fixes the media QoS.

1. UE sends INVITE with the SDP offer to the P-CSCF over the IMS PDU session (5QI 5 signalling flow).
2. P-CSCF forwards the INVITE to the S-CSCF.
3. S-CSCF routes the INVITE on toward the remote end.
4. Remote returns 100 Trying to stop retransmissions.
5. Remote returns 183 Session Progress carrying the SDP answer — the media QoS is now fixed.
6. Dedicated QoS flow: the P-CSCF passes the media QoS to the PCF over N5, the SMF runs a PDU Session Modification, and a 5QI 1 QoS flow is mapped to a dedicated DRB.
7. UE sends PRACK to reliably acknowledge the 183.
8. Remote returns 200 OK (PRACK).
9. With the flow ready, UE sends UPDATE signalling that preconditions are met.
10. Remote returns 200 OK (UPDATE).
11. Remote returns 180 Ringing; the callee is alerted and the UE plays ringback.
12. Remote returns 200 OK (INVITE) when the callee answers.
13. UE sends ACK, confirming the dialog. RTP voice then flows on the 5QI 1 QoS flow.

If VoNR isn't available here, EPS fallback moves the call to VoLTE — with EPS↔5GS interworking (N26).

Call flow at a glance

Phase A — SIP Session on the 5QI=5 Signalling Flow (Steps 1–3)

The call begins entirely in the application layer. Every message in this phase is a SIP request or response carried on the existing default QoS Flow of the IMS PDU Session — 5QI=5 (QFI 9), the standardised non-GBR flow for IMS signalling — and reaches the IMS core through the P-CSCF, the UE's first contact point. No 5G bearer changes happen yet: the UE offers its codecs, the far end answers with the agreed codec, and reliable provisional responses are acknowledged. Critically, the SDP offer/answer completed here is exactly what tells the network what QoS the media will need, arming Phase B.

The originating UE sends a SIP INVITE toward the callee, addressed via the P-CSCF whose address it learned in the PCO during IMS PDU Session establishment. The INVITE carries an SDP offer describing the media the UE proposes: for voice this is typically AMR-WB (Adaptive Multi-Rate Wideband) at 16 kHz, an RTP port, and bandwidth hints. It also uses the precondition framework — the SDP marks current QoS as not yet met and desired QoS as mandatory — so the far end will not alert the user until both sides confirm their bearers are ready. This request rides the 5QI=5 signalling flow on the IMS PDU Session.

Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:+13115550777@ims.mnc480.mcc311.3gppnetwork.org SIP/2.0
    Via: SIP/2.0/UDP [2001:db8:ca11::a1]:5060;branch=z9hG4bK7a2f
    From: sip:+13115550123@ims.mnc480.mcc311.3gppnetwork.org;tag=9c1e
    Call-ID: 8f2a4b6c1d@2001:db8:ca11::a1
    CSeq: 1 INVITE
    Content-Type: application/sdp
Session Description Protocol
    Media Description: audio 49152 RTP/AVP 97
    Media Attribute (a): rtpmap:97 AMR-WB/16000/1
    Media Attribute (a): fmtp:97 mode-change-capability=2; max-red=0
    Media Attribute (a): curr:qos local none
    Media Attribute (a): des:qos mandatory local sendrecv

The P-CSCF immediately returns a 100 Trying to stop INVITE retransmissions, and forwards the INVITE onward through the S-CSCF to the terminating side. Once the far end selects a codec from the offer it returns a 183 Session Progress carrying the SDP answer — the single agreed codec (AMR-WB), the far-end RTP port, and its own precondition state. The 183 is sent reliably (it requires a PRACK) so the SDP answer cannot be lost. At the moment this SDP answer is known, the media QoS is fully determined and the IMS core can begin authorizing resources.

Session Initiation Protocol (183 Session Progress)
    Status-Line: SIP/2.0 183 Session Progress
    Via: SIP/2.0/UDP [2001:db8:ca11::a1]:5060;branch=z9hG4bK7a2f
    Call-ID: 8f2a4b6c1d@2001:db8:ca11::a1
    CSeq: 1 INVITE
    Require: 100rel
    RSeq: 1
    Content-Type: application/sdp
Session Description Protocol
    Media Description: audio 50004 RTP/AVP 97
    Media Attribute (a): rtpmap:97 AMR-WB/16000/1
    Media Attribute (a): curr:qos local none
    Media Attribute (a): des:qos mandatory local sendrecv

Because the 183 was marked reliable (Require: 100rel, RSeq 1), the UE acknowledges it with a PRACK request whose RAck header echoes the RSeq and CSeq of the response being confirmed. The far end (via the P-CSCF) replies 200 OK for the PRACK. This closes the reliable-provisional handshake so both sides are certain the SDP answer has been delivered. With the codec firmly agreed, the network moves to reserve the actual media resources in Phase B before the UE will send UPDATE and the callee is alerted.

Session Initiation Protocol (PRACK)
    Request-Line: PRACK sip:+13115550777@ims.mnc480.mcc311.3gppnetwork.org SIP/2.0
    Via: SIP/2.0/UDP [2001:db8:ca11::a1]:5060;branch=z9hG4bK9d3c
    From: sip:+13115550123@ims.mnc480.mcc311.3gppnetwork.org;tag=9c1e
    To: sip:+13115550777@ims.mnc480.mcc311.3gppnetwork.org;tag=ab77
    Call-ID: 8f2a4b6c1d@2001:db8:ca11::a1
    CSeq: 2 PRACK
    RAck: 1 1 INVITE
    Max-Forwards: 70
    Content-Length: 0
    [Reply: SIP/2.0 200 OK  CSeq: 2 PRACK]

Phase B — Dedicated GBR Flow Creation (Steps 4–9)

This is the heart of VoNR: the negotiated media parameters are turned into a real, guaranteed-bit-rate bearer. The P-CSCF hands the media QoS to the PCF (Rx/N5), the PCF derives a PCC rule and installs it on the SMF (N7), and the SMF drives a PDU Session modification down through the AMF (N2) to the gNB. The gNB admits the GBR flow, builds a dedicated voice DRB, and reconfigures the UE over the air. When the gNB reports success back to the core, the 5QI=1 conversational-voice bearer is live end-to-end — all before the phone is allowed to ring.

Acting as an Application Function, the P-CSCF passes the agreed media description to the PCF so policy can authorize it. In an SBA deployment this is the Npcf_PolicyAuthorization service over N5 (HTTP/2 SBI); in a Diameter deployment it is an AA-Request over the Rx interface. Either way the P-CSCF describes the media component: type audio, the AMR-WB bandwidth requirement, and the flow description (IP 5-tuple for the RTP flow). The PCF authorizes it and prepares to translate it into a PCC rule targeting a 5QI=1 GBR flow.

HyperText Transfer Protocol 2
    Stream: HEADERS, Stream ID: 3
        :method: POST
        :path: /npcf-policyauthorization/v1/app-sessions
        :authority: pcf.5gc.mnc480.mcc311.3gppnetwork.org
        content-type: application/json
    Stream: DATA, Stream ID: 3
        JavaScript Object Notation (application/json)
            "medComponents": { "mediaType": "AUDIO",
                "marBwUl": "41 Kbps", "marBwDl": "41 Kbps",
                "fDescs": "permit out 17 to 2001:db8:ca11::a1 49152" }
            "resPrio": "PRIO_2"
    [Response] :status: 201 Created  Location: .../app-sessions/vonr-9c1e

The PCF turns the authorized media into a PCC rule and pushes it to the SMF over N7 using the Npcf_SMPolicyControl_UpdateNotify service. The rule names the 5QI=1 standardised characteristics (GBR, conversational voice), the Guaranteed and Maximum Flow Bit Rates for uplink and downlink (GFBR/MFBR), and the Allocation and Retention Priority (ARP). On receiving it the SMF binds the rule to a new QoS Flow on the IMS PDU Session, allocates the QFI, and prepares an N1N2 message transfer to update the RAN via the AMF. The SMF also updates the UPF over N4 with the packet-detection and QoS-enforcement rules for the new flow.

HyperText Transfer Protocol 2
    Stream: HEADERS, Stream ID: 7
        :method: POST
        :path: /npcf-smpolicycontrol/v1/sm-policies/ims-5/update
        content-type: application/json
    Stream: DATA, Stream ID: 7
        JavaScript Object Notation (application/json)
            "pccRules": { "voice-9c1e": {
                "flowInfos": "permit out 17 to 2001:db8:ca11::a1 49152",
                "refQosData": "qos-voice" } }
            "qosDecs": { "qos-voice": { "5qi": 1,
                "gbrUl": "24400", "gbrDl": "24400",
                "maxbrUl": "41000", "maxbrDl": "41000",
                "arp": { "priorityLevel": 2 } } }
    [Response] :status: 200 OK  (SMF binds QFI 1 on PDU Session 5)

The SMF's N1N2 message transfer reaches the AMF, which sends an NGAP PDU Session Resource Modify Request to the serving gNB over N2. The message carries, for PDU Session 5, a QoS Flow Add/Modify Request Item List containing the new voice flow: QFI 1, its 5QI=1 GBR characteristics, the GFBR/MFBR for uplink and downlink, and the ARP. This is the precise instruction that tells the RAN to build guaranteed-bit-rate resources for conversational voice. (If the cell cannot serve NR GBR voice, this same message is what triggers EPS Fallback instead.)

Stream Control Transmission Protocol
    Payload protocol identifier: NGAP (60)
NG Application Protocol (NGAP)
    NGAP-PDU: initiatingMessage (0)
        procedureCode: id-PDUSessionResourceModify (26)
        AMF-UE-NGAP-ID: 1
        RAN-UE-NGAP-ID: 1
        PDUSessionResourceModifyListModReq: 1 item
            PDUSessionID: 5
            qosFlowAddOrModifyRequestList: 1 item
                qosFlowIdentifier: 1
                fiveQI: 1
                gBR-QosInformation: GFBR 24400/24400, MFBR 41000/41000
                allocationAndRetentionPriority: priorityLevel 2

The gNB runs admission control for the GBR flow: it checks it can guarantee the GFBR under the ARP priority. On success it creates a dedicated Data Radio Bearer for the voice and installs a QoS-flow-to-DRB mapping so packets marked QFI 1 (5QI=1) traverse the new DRB rather than the default 5QI=5 DRB. It then sends an RRCReconfiguration on SRB1 adding the DRB with its PDCP, RLC, and logical-channel configuration and the SDAP mapping rule. Voice DRBs are typically configured with RLC-UM (unacknowledged mode, low latency) and often SPS / configured-grant scheduling to carry the small periodic AMR frames efficiently.

NR Radio Resource Control (RRC) protocol
    DL-DCCH-Message
        message: c1 (0)
            c1: rrcReconfiguration (2)
                rrc-TransactionIdentifier: 1
                radioBearerConfig
                    drb-ToAddModList: 1 item
                        drb-Identity: 2
                        cnAssociation: sdap-Config
                            mappedQoS-FlowsToAdd: qfi 1
                        pdcp-Config: drb (pdcp-SN-SizeUL 12, rlc-UM)
                    rlc-BearerConfig: logicalChannelIdentity 5 (um-Bi)
                masterCellGroup: [MAC/PHY for DRB2, SPS voice]

The UE applies the new configuration — it instantiates the dedicated voice DRB (PDCP/RLC/MAC entities), installs the SDAP mapping so its own uplink QFI 1 packets go on DRB2, and readies the logical channel — then confirms with RRCReconfigurationComplete on SRB1. From this instant the radio side of the GBR bearer exists in both directions; the UE can send and receive AMR-WB RTP on DRB2 as soon as media starts. The gNB now reports success back to the core.

MAC-NR
    Radio Network Temporary Identifier (RNTI): 0x4602 (C-RNTI)
    LCID: 1 (SRB1)
NR Radio Resource Control (RRC) protocol
    UL-DCCH-Message
        message: c1 (0)
            c1: rrcReconfigurationComplete (1)
                rrcReconfigurationComplete
                    rrc-TransactionIdentifier: 1
                    criticalExtensions: rrcReconfigurationComplete (0)
                        rrcReconfigurationComplete
    [DRB2 established: SDAP QFI 1 → DRB2, PDCP SN 0]

The gNB confirms the modification to the AMF with an NGAP PDU Session Resource Modify Response. It lists the admitted QoS Flow (QFI 1) and, in the N2 SM information for PDU Session 5, the downlink NG-U tunnel endpoint (gNB IP + TEID) so the UPF/SMF can steer the voice packets to the right DRB. The AMF relays this to the SMF (Nsmf_PDUSession_UpdateSMContext), which finalises the N4 rules at the UPF. At this point the 5QI=1 GBR bearer is live end-to-end — radio, transport, and core all know about the voice flow.

Stream Control Transmission Protocol
    Payload protocol identifier: NGAP (60)
NG Application Protocol (NGAP)
    NGAP-PDU: successfulOutcome (1)
        procedureCode: id-PDUSessionResourceModify (26)
        AMF-UE-NGAP-ID: 1
        RAN-UE-NGAP-ID: 1
        PDUSessionResourceModifyListModRes: 1 item
            PDUSessionID: 5
            qosFlowAddOrModifyResponseList: qosFlowIdentifier 1
            DL-NGU-UP-TNL-Information: 10.10.9.4, TEID 0x00B2D5E6
        [SMF finalises N4: UPF steers QFI 1 to DRB2]

Phase C — Answer & Media (Steps 10–12)

With the GBR bearer live, the precondition is satisfied and the SIP dialog can complete. The UE signals that its resources are reserved with an UPDATE, the far end alerts and then answers, and the dialog is confirmed with ACK. Immediately, AMR-WB voice packets flow as RTP on the dedicated 5QI=1 GBR DRB while SIP continues to ride the 5QI=5 signalling flow for any in-call events.

Now that the dedicated voice bearer exists, the UE sends a SIP UPDATE carrying an SDP whose precondition attribute flips from unmet to met (a=curr:qos local sendrecv). This tells the far end that the originating side's media path is ready. The far end replies 200 OK for the UPDATE with its own current-status SDP. This precondition mechanism is exactly why the callee's phone has not rung yet — alerting is deliberately deferred until both sides confirm their bearers, so a call never rings without a media path.

Session Initiation Protocol (UPDATE)
    Request-Line: UPDATE sip:+13115550777@ims.mnc480.mcc311.3gppnetwork.org SIP/2.0
    Via: SIP/2.0/UDP [2001:db8:ca11::a1]:5060;branch=z9hG4bKc4e1
    Call-ID: 8f2a4b6c1d@2001:db8:ca11::a1
    CSeq: 3 UPDATE
    Content-Type: application/sdp
Session Description Protocol
    Media Description: audio 49152 RTP/AVP 97
    Media Attribute (a): curr:qos local sendrecv
    Media Attribute (a): des:qos mandatory local sendrecv
    [Reply: SIP/2.0 200 OK  CSeq: 3 UPDATE (far-end qos met)]

With both preconditions met, the terminating side finally alerts the user and sends 180 Ringing back to the originating UE, which plays ringback. When the callee answers, a 200 OK for the original INVITE is returned, confirming the session and the negotiated media. The originating UE completes the three-way INVITE handshake with an ACK. The SIP dialog is now fully established (confirmed dialog), and both endpoints are cleared to exchange media on the reserved GBR bearer.

Session Initiation Protocol (200 OK)
    Status-Line: SIP/2.0 200 OK
    Via: SIP/2.0/UDP [2001:db8:ca11::a1]:5060;branch=z9hG4bK7a2f
    From: sip:+13115550123@ims.mnc480.mcc311.3gppnetwork.org;tag=9c1e
    To: sip:+13115550777@ims.mnc480.mcc311.3gppnetwork.org;tag=ab77
    Call-ID: 8f2a4b6c1d@2001:db8:ca11::a1
    CSeq: 1 INVITE
    Contact: sip:+13115550777@2001:db8:ca11::b2
    [Preceded by: SIP/2.0 180 Ringing at t=0.190]
    [UE replies: ACK sip:...@2001:db8:ca11::b2  CSeq: 1 ACK]

The call is up and media flows. AMR-WB voice frames are packetised into RTP, carried over UDP/IP, and — because the UE's SDAP maps QFI 1 to DRB2 — transmitted on the dedicated 5QI=1 GBR Data Radio Bearer in both directions. The gNB scheduler protects this bearer: the guaranteed flow bit rate and the tight packet delay budget of conversational voice are honoured even under cell load, and the small, regular 20 ms AMR frames are typically served with SPS / configured-grant allocations to cut PDCCH overhead. Meanwhile SIP keeps riding the 5QI=5 flow, ready for in-call events (re-INVITE for codec/hold changes, and finally BYE to release the call and tear down the 5QI=1 flow).

Internet Protocol Version 6
    Source: 2001:db8:ca11::a1   Destination: 2001:db8:ca11::b2
    Next header: UDP (17)   Traffic Class: 0x2e (EF)
User Datagram Protocol
    Source Port: 49152   Destination Port: 50004
Real-Time Transport Protocol
    Payload type: DynamicRTP-Type-97 (AMR-WB)
    Sequence number: 12841   Timestamp: 4106880
    Synchronization Source (SSRC): 0x0A1B2C3D
    Payload: AMR-WB octet-aligned, FT=8 (23.85 kbps), 1 frame
    [Air-interface mapping: SDAP QFI 1 → DRB2, 5QI=1 GBR]

Summary

A VoNR call is best debugged by phase. If setup never gets past Phase A, the problem is in SIP/SDP: check the INVITE egresses on 5QI=5, the 183 carries a compatible SDP answer, and the PRACK closes reliably. If the codec is agreed but no dedicated bearer appears, the problem is in Phase B: walk P-CSCF→PCF (N5/Rx) → PCF→SMF PCC rule (N7) → AMF→gNB modify (N2) → gNB admission + RRCReconfiguration → modify response, and the first hop that fails is your cause. If the call rings but audio is bad or one-way, the problem is in Phase C or the mapping: confirm RTP rides DRB2 via SDAP QFI 1→5QI=1, and that both DL and UL N3 tunnels are set.

Two ideas tie it together. First, signalling (5QI=5) and media (5QI=1) are separate flows in the same PDU session — symptoms on one rarely touch the other, which localises faults fast. Second, the SIP precondition framework gates alerting on the bearer, so "rings then dead air" almost always means alerting fired before the GBR flow was truly up. Follow the trace INVITE→183→PCC→N2 modify→RRC→UPDATE→200/ACK→RTP and the broken step names the owner of the fix.