VoLTE Call Flow

Introduction

Voice over LTE (VoLTE) is a packet-switched voice call carried as RTP over a dedicated LTE bearer, set up by SIP/IMS signalling. This page traces a complete mobile-originating (MO) leg — from the first SIP INVITE to steady-state voice packets flowing on a dedicated Guaranteed-Bit-Rate EPS bearer. It is where the application layer (SIP/SDP over IMS, TS 23.228) and the LTE bearer layer (the EPS QoS model, TS 23.401) are stitched together: the SDP codec negotiation is the exact trigger that makes the network build a dedicated QCI=1 GBR EPS bearer for the voice media, mapped onto a dedicated Data Radio Bearer.

The flow assumes the starting point most real VoLTE calls begin from: the UE is already attached to LTE through the MME and holds a NAS security context; a separate IMS PDN connection (APN "ims") is already up, carrying a default non-GBR EPS bearer at QCI=5 (EPS bearer id 5) on which all SIP signalling rides; and the UE is already IMS-registered (the SIP REGISTER/IMS-AKA exchange with the S-CSCF has completed, kept alive by periodic REGISTER refreshes). So the user's public identity is bound to its contact and the UE can originate calls.

The page moves through three phases: the SIP offer/answer on the QCI=5 signalling bearer (A), on-demand creation of the dedicated GBR bearer through PCRF/P-GW/S-GW/MME/eNB (B), and answer plus media where RTP flows on the new GBR DRB (C). Each step lists the exact message, the interface it crosses, key Information Elements with realistic example values, a representative packet capture, and per-step debugging notes — because in a VoLTE failure the hard question is usually "did the dedicated bearer actually come up, and does its TFT match the media?", and that is answered message by message.

Why VoLTE needs a dedicated bearer

Voice is unforgiving: it needs a low, bounded delay and a rate the network will honour even under load. A best-effort bearer cannot promise that, so VoLTE relies on a GBR bearer at QCI=1 (conversational voice, 100 ms packet delay budget) reserved specifically for the media. But the network cannot reserve it in advance, because it does not know the codec or the RTP ports until SIP/SDP has negotiated them. So the sequence is: SIP negotiates the media, the IMS core hands that media description to policy (PCRF over Rx), policy installs a rule (Gx), and only then does the P-GW trigger a dedicated bearer whose TFT steers exactly that RTP flow onto the guaranteed pipe. The SIP precondition framework holds back alerting until this bearer exists.

Call flow — SIP setup

Zooming out from the packet-level detail above, this is the end-to-end SIP message sequence for the VoLTE MO call — INVITE through ACK — with the dedicated QCI 1 EPS bearer being built mid-dialog, after the SDP answer fixes the media QoS and before the callee is alerted.

1. UE sends INVITE with the SDP offer to the P-CSCF over the QCI 5 signalling bearer.
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 bearer: the P-CSCF passes the media QoS to the PCRF over Rx, and the P-GW activates a QCI 1 GBR voice bearer.
7. UE sends PRACK to reliably acknowledge the 183.
8. Remote returns 200 OK (PRACK).
9. With the bearer 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 QCI 1 dedicated bearer.

Call flow at a glance

Phase A — SIP Session on the QCI=5 Signalling Bearer (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 EPS bearer of the IMS PDN connection — QCI=5 (EPS bearer id 5), the standardised non-GBR bearer for IMS signalling — and reaches the IMS core through the P-CSCF, the UE's first contact point (whose address the UE learned in the PCO during IMS PDN connectivity). No LTE 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. 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 QCI=5 signalling bearer on the IMS PDN connection, the same bearer that carried IMS registration.

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 over Rx.

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 QCI=1 GBR Bearer Creation (Steps 4–10)

This is the heart of VoLTE: the negotiated media parameters are turned into a real, guaranteed-bit-rate EPS bearer. The P-CSCF hands the media QoS to the PCRF (Rx), the PCRF derives a PCC rule and installs it on the P-GW (Gx), and the P-GW drives a dedicated-bearer activation down through the S-GW and MME (GTPv2-C) to the eNB (S1AP). The eNB admits the GBR bearer, builds a dedicated voice DRB, and reconfigures the UE over the air. When the eNB reports success back to the core, the QCI=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 PCRF so policy can authorize it. Over the Rx interface this is a Diameter AA-Request (AAR). 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 PCRF authorizes it, replies AA-Answer (AAA) with DIAMETER_SUCCESS, and prepares to translate it into a PCC rule targeting a QCI=1 GBR bearer on the P-GW.

Diameter Protocol
    Version: 0x01   Flags: Request, Proxyable
    Command Code: 265 (AA-Request)
    ApplicationId: 3GPP Rx (16777236)
    AVP: Media-Component-Description
        AVP: Media-Component-Number: 1
        AVP: Media-Type: AUDIO (0)
        AVP: Max-Requested-Bandwidth-UL: 41000
        AVP: Max-Requested-Bandwidth-DL: 41000
        AVP: Media-Sub-Component
            AVP: Flow-Description: permit out 17 to 2001:db8:ca11::a1 49152
    AVP: Reservation-Priority: PRIORITY_TWO (2)
    [Response] Command 265 AA-Answer, Result-Code 2001 (DIAMETER_SUCCESS)

The PCRF turns the authorized media into a PCC rule and pushes it to the P-GW (acting as PCEF) over the Gx interface with a Diameter Re-Auth-Request (RAR). The rule carries a Charging-Rule-Definition naming the QCI=1 standardised characteristics (GBR, conversational voice), the Guaranteed and Maximum Bit Rates for uplink and downlink (GBR/MBR), the Allocation and Retention Priority (ARP), and the flow information (the RTP 5-tuple). On receiving it the P-GW answers RAA with DIAMETER_SUCCESS and triggers activation of a new dedicated EPS bearer on the IMS PDN connection.

Diameter Protocol
    Version: 0x01   Flags: Request, Proxyable
    Command Code: 258 (Re-Auth-Request)
    ApplicationId: 3GPP Gx (16777238)
    AVP: Charging-Rule-Install
        AVP: Charging-Rule-Definition
            AVP: Charging-Rule-Name: voice-9c1e
            AVP: QoS-Information
                AVP: QoS-Class-Identifier: 1
                AVP: Guaranteed-Bitrate-UL: 24400   DL: 24400
                AVP: Max-Requested-Bandwidth-UL: 41000   DL: 41000
                AVP: Allocation-Retention-Priority: PL 2, PCI 1, PVI 0
            AVP: Flow-Information: permit out 17 to 2001:db8:ca11::a1 49152
    [Response] Re-Auth-Answer, Result-Code 2001 (DIAMETER_SUCCESS)

The P-GW maps the PCC rule to a new dedicated EPS bearer and issues a GTPv2-C Create Bearer Request to the S-GW over S5, which relays it to the MME over S11. The message references the Linked EPS Bearer Identity (LBI=5, the QCI=5 default bearer of the IMS PDN) and carries a Bearer Context with the new EPS Bearer Identity (EBI=6), the Bearer Level QoS (QCI=1, ARP, GBR/MBR uplink and downlink), a Traffic Flow Template (TFT) with the uplink packet filters that steer the voice RTP flow onto this bearer, and the S5/S8 and S1-U tunnel endpoints. This is the core-network instruction that begins building the GBR pipe.

GPRS Tunneling Protocol V2 (GTPv2-C)
    Version: 2   Message Type: Create Bearer Request (95)
    TEID: 0x00a1f3c4   Sequence Number: 0x000012
    IE: Linked EPS Bearer Identity (LBI): 5
    IE: Bearer Context
        IE: EPS Bearer ID (EBI): 6
        IE: Bearer Level QoS
            QCI: 1
            ARP: Priority-Level 2, PCI 1, PVI 0
            Guaranteed Bit Rate: UL 24400, DL 24400
            Maximum Bit Rate: UL 41000, DL 41000
        IE: Bearer TFT: create new, 1 packet filter (UDP dst 50004)
        IE: S5/S8-U SGW F-TEID: 10.10.5.8, TEID 0x00b2d5e6

The MME converts the Create Bearer Request into an S1AP E-RAB Setup Request to the serving eNB over S1-MME. It carries, for this UE, an E-RAB to be set up: E-RAB ID 6, the E-RAB Level QoS Parameters (QCI=1, ARP, and the GBR QoS information GBR/MBR), and the S1-U uplink transport endpoint at the S-GW. Embedded in the same message as the NAS-PDU is the NAS Activate Dedicated EPS Bearer Context Request, which the eNB will deliver transparently to the UE. This is the precise instruction that tells the E-UTRAN to build guaranteed-bit-rate radio resources for conversational voice.

Stream Control Transmission Protocol
    Payload protocol identifier: S1 Application Protocol (18)
S1 Application Protocol (S1AP)
    initiatingMessage: id-E-RABSetup
        MME-UE-S1AP-ID: 1
        eNB-UE-S1AP-ID: 1
        E-RABToBeSetupListBearerSUReq: 1 item
            E-RAB-ID: 6
            E-RABLevelQoSParameters: qCI 1, ARP priorityLevel 2
                gbrQosInformation: GBR 24400/24400, MBR 41000/41000
            transportLayerAddress: 10.10.5.8   gTP-TEID: 0x00b2d5e6
            NAS-PDU: Activate Dedicated EPS Bearer Context Request
                linkedEPSBearerIdentity: 5   ePSBearerIdentity: 6

The eNB runs admission control for the GBR bearer: it checks it can guarantee the GBR under the ARP priority. On success it creates a dedicated Data Radio Bearer for the voice and associates EPS Bearer 6 with it so packets on this bearer traverse the new DRB rather than the default QCI=5 DRB. It then sends an RRCConnectionReconfiguration on SRB1 adding the DRB with its PDCP, RLC, and logical-channel configuration, and includes the NAS Activate Dedicated EPS Bearer Context Request in dedicatedInfoNASList. Voice DRBs are typically configured with RLC-UM (unacknowledged mode, low latency) and often semi-persistent scheduling (SPS) to carry the small periodic AMR frames efficiently.

LTE Radio Resource Control (RRC) protocol
    DL-DCCH-Message
        message: c1
            c1: rrcConnectionReconfiguration
                rrc-TransactionIdentifier: 1
                criticalExtensions: rrcConnectionReconfiguration-r8
                    radioResourceConfigDedicated
                        drb-ToAddModList: 1 item
                            eps-BearerIdentity: 6
                            drb-Identity: 2
                            rlc-Config: um-Bi-Directional
                            logicalChannelIdentity: 4
                    dedicatedInfoNASList: 1 item
                        Activate Dedicated EPS Bearer Context Request

The UE applies the new configuration — it instantiates the dedicated voice DRB (PDCP/RLC/MAC entities), binds EPS Bearer 6 and its TFT so its own uplink voice packets go on the new DRB, and readies the logical channel — then confirms with RRCConnectionReconfigurationComplete 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 the voice DRB as soon as media starts. The UE also generates the NAS Activate Dedicated EPS Bearer Context Accept, which the eNB will forward to the MME in the next step.

MAC-LTE
    Radio Network Temporary Identifier (RNTI): 0x4a2b (C-RNTI)
    LCID: 1 (SRB1)
LTE Radio Resource Control (RRC) protocol
    UL-DCCH-Message
        message: c1
            c1: rrcConnectionReconfigurationComplete
                rrc-TransactionIdentifier: 1
                criticalExtensions: rrcConnectionReconfigurationComplete-r8
    [DRB2 established: EPS bearer 6, QCI 1 voice, TFT bound]

The eNB confirms the radio setup to the MME with an S1AP E-RAB Setup Response, listing the admitted E-RAB (ID 6) and the downlink S1-U transport endpoint (eNB IP + TEID) so the S-GW can steer the voice packets to the right DRB. Separately, the UE's NAS Activate Dedicated EPS Bearer Context Accept (EBI 6) is carried up to the MME (in an S1AP Uplink NAS Transport). The MME then completes the procedure toward the core with a GTPv2-C Create Bearer Response over S11 to the S-GW and on to the P-GW over S5. At this point the QCI=1 GBR bearer is live end-to-end — radio, transport, and core all know about the voice bearer.

S1 Application Protocol (S1AP)
    successfulOutcome: id-E-RABSetup
        MME-UE-S1AP-ID: 1
        eNB-UE-S1AP-ID: 1
        E-RABSetupListBearerSURes: 1 item
            E-RAB-ID: 6
            transportLayerAddress: 10.10.9.4   gTP-TEID: 0x00c3e7f8
    [Uplink NAS Transport]
        NAS-PDU: Activate Dedicated EPS Bearer Context Accept (EBI 6)
    [MME → S-GW/P-GW: GTPv2-C Create Bearer Response]
        EBI: 6   Cause: Request accepted (16)

Phase C — Answer & Media (Steps 11–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 QCI=1 GBR DRB while SIP continues to ride the QCI=5 signalling bearer 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), telling the far end that the originating side's media path is ready; the far end replies 200 OK for the UPDATE. This precondition mechanism is exactly why the callee's phone has not rung yet — alerting is deliberately deferred until both sides confirm their bearers. With both preconditions met, the terminating side alerts the user and sends 180 Ringing (the UE plays ringback); when the callee answers, a 200 OK for the original INVITE confirms the session, and the UE completes the three-way handshake with ACK. The dialog is now confirmed and both endpoints are cleared to exchange media on the reserved GBR bearer.

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 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)]
    [t=0.190 SIP/2.0 180 Ringing  CSeq: 1 INVITE]
    [t=3.540 SIP/2.0 200 OK  CSeq: 1 INVITE  Contact: sip:...@2001:db8:ca11::b2]
    [t=3.545 ACK sip:...@2001:db8:ca11::b2  CSeq: 1 ACK  dialog confirmed]

The call is up and media flows. AMR-WB voice frames are packetised into RTP, carried over UDP/IP, and — because the UE's TFT binds the RTP flow to EPS Bearer 6 — transmitted on the dedicated QCI=1 GBR Data Radio Bearer in both directions. The eNB scheduler protects this bearer: the guaranteed 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 to cut PDCCH overhead. Meanwhile SIP keeps riding the QCI=5 signalling bearer, ready for in-call events (re-INVITE for codec/hold changes, and finally BYE to release the call and tear down the QCI=1 bearer via a NAS Deactivate EPS Bearer Context).

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: TFT → EPS bearer 6 → DRB2, QCI=1 GBR]

Summary

VoLTE is the clean example of SIP/IMS driving the EPS QoS model. Phase A negotiates the media on the always-on QCI=5 signalling bearer — INVITE with an SDP offer, a reliable 183 with the SDP answer, and a PRACK to lock it in. Phase B turns that agreed media into a real guaranteed pipe: P-CSCF→PCRF over Rx, PCRF→P-GW PCC rule over Gx, Create Bearer down through the S-GW/MME, and E-RAB Setup + NAS Activate Dedicated EPS Bearer Context to build the QCI=1 GBR voice DRB. Phase C lets the call complete once preconditions are met, and RTP flows on the dedicated bearer while SIP keeps riding QCI=5.

To debug a VoLTE call, walk it in that order and ask three questions: did SDP negotiate a codec (Phase A)? did the dedicated QCI=1 bearer actually activate end to end — policy, core, radio, NAS accept (Phase B)? and does the TFT steer the real RTP 5-tuple onto that bearer (Phase B/C)? A "call connects but audio is bad" symptom almost always means the media ended up on the default bearer because the dedicated bearer failed admission or the TFT did not match — the first mismatched IE tells you which.