IMS, VoLTE & VoWiFi

The big picture: why IMS exists

Before 4G, voice ran on the circuit-switched (CS) domain: the network reserved a dedicated circuit (a timeslot) end to end for the whole call. LTE has no CS domain at all; it is an all-IP packet network. So operators needed a way to carry voice as IP packets while keeping carrier-grade features: guaranteed quality, supplementary services (call forwarding, hold, conference), emergency calls, lawful intercept, charging and roaming. IMS is that system.

IMS is a standardised (3GPP) architecture built on SIP (Session Initiation Protocol) for signaling, SDP (Session Description Protocol) to negotiate media, and RTP/RTCP to carry the actual voice and video. Its key design choice is layering:

Because service control is independent of access, the same IMS core delivers:

• VoLTE (Voice over LTE): IMS voice over LTE radio with a QCI 1 dedicated bearer.
• VoNR (Voice over New Radio): the same SIP flow over 5G SA with a 5QI 1 QoS flow. See 5G NR for EPS fallback and the 5G core.
• VoWiFi (Wi-Fi Calling, WFC): the same SIP flow tunnelled over any Wi-Fi through an IPsec tunnel to the ePDG.
• ViLTE (video over LTE), RCS (rich messaging), SMS over IP, and IMS emergency calls.

          ACCESS                TRANSPORT (bearers)              SERVICE CONTROL
   ┌──────────────────┐   ┌──────────────────────────┐   ┌──────────────────────────┐
   │ LTE eNB          │──►│ EPC: MME, S-GW, P-GW     │──►│                          │
   │ NR gNB           │──►│ 5GC: AMF, SMF, UPF       │──►│ IMS core: P/I/S-CSCF,    │
   │ Wi-Fi (untrusted)│──►│ ePDG / N3IWF ──► P-GW/UPF│──►│ HSS/UDM, TAS, MRF, BGCF, │
   └──────────────────┘   └──────────────────────────┘   │ MGCF, IBCF, E-CSCF       │
                           PCRF / PCF (QoS policy) ◄─────┤                          │
                                                          └──────────────────────────┘
   SIP signaling: UE ◄═══► P-CSCF (on QCI 5 / 5QI 5)
   RTP media:     UE ◄═══► far end (on QCI 1 / 5QI 1, guaranteed bit rate)

IMS core architecture and network entities

The IMS core is a set of functions, each with a narrow job. In real deployments several functions are often combined in one product (for example, P-CSCF inside an SBC, or I-CSCF and S-CSCF on the same platform), but interviewers expect you to know the logical roles.

The three CSCFs (Call Session Control Functions)

Databases, application servers and media

Policy and non-3GPP access nodes

End-to-end picture

                                   HOME / SERVING IMS NETWORK
  UE ══SIP (IPsec, Gm)══► P-CSCF/SBC ──Mw──► I-CSCF ──Mw──► S-CSCF ══ISC══► TAS / SCC-AS
   │                        │                  │               │               │
   │                        │                  └─────Cx──────► HSS ◄────Sh─────┘
   │                        │                                  ▲
   │                        └──Rx / N5──► PCRF / PCF ──Gx/N7──► P-GW / SMF+UPF
   │                                                          (installs QCI 1 bearer)
   │                                        S-CSCF ──Mi──► BGCF ──Mj──► MGCF ──► PSTN
   │                                        S-CSCF ──Mx──► IBCF ──► other operator IMS
   │                                        S-CSCF ──Mr──► MRF (announcements, conference)
   └── RTP media on dedicated bearer ── eNB/gNB ── S-GW ── P-GW/UPF ── far end

Reference points you should recognise

IMS identities

• IMPI (IP Multimedia Private Identity): one per subscription, used only for authentication, in NAI form such as imsi@ims.mnc001.mcc001.3gppnetwork.org. Never used to route calls.
• IMPU (IP Multimedia Public Identity): one or more SIP or tel URIs others use to reach you, for example sip:+15551234567@ims.example.com and tel:+15551234567. IMPUs grouped in an implicit registration set are all registered together.
• ISIM: the SIM application holding IMPI, IMPU and the home domain (EF_IMPI, EF_IMPU, EF_DOMAIN). Without an ISIM, the UE derives temporary identities from the IMSI on the USIM.
• GRUU (Globally Routable User agent URI): identifies one specific device instance when several devices share an IMPU. +sip.instance (often built from the IMEI) is the stable device identifier.
• P-Associated-URI: returned in the 200 OK to REGISTER; lists the IMPUs the network has registered for you.

IMS connectivity: APN, PDN and bearers

Before any SIP can be sent, the UE needs an IP address on a network that can reach the P-CSCF. That is the IMS APN (Access Point Name), a separate packet data connection with the well-known name ims. In LTE it is an IMS PDN connection; in 5G it is an IMS PDU session towards the IMS DNN.

Why a separate APN?

• Isolation: IMS traffic is never mixed with internet traffic, so it can be given its own QoS, security policy and firewall rules.
• Reachability: the P-CSCF is only reachable from the IMS APN (a private operator network), which protects the core.
• Independence from data settings: VoLTE keeps working when the user turns off mobile data or runs out of data allowance, because the IMS APN is not the internet APN.
• Charging: voice is charged by the IMS core, not as data volume.
• IMS APNs are usually IPv6 (or IPv4v6), which avoids NAT problems for SIP and RTP.

Bearers on the IMS APN

1. Attach / registration to the packet core The UE attaches to LTE (or registers with the 5GC). Many operators make the IMS APN the initial attach APN, or the UE opens it right after attach.
2. IMS PDN connectivity request The UE requests a PDN connection to APN ims and includes a PCO (Protocol Configuration Options) request for the P-CSCF address (IPv6 and/or IPv4).
3. Default bearer with QCI 5 The network activates the default bearer and returns the UE's IP address and, in the PCO, the list of P-CSCF addresses.
4. Voice support indication In the attach or TAU accept, the network signals "IMS voice over PS session supported" (IMS VoPS). If this bit is not set, the UE must not use VoLTE in that cell and will use CSFB or other domains instead.

IMS registration and authentication

Voice cannot work until the UE is registered with the IMS core. Registration binds the UE's current IP address (its Contact) to its public identities, authenticates it, and sets up the IPsec protection used for every later SIP message. It is also the procedure that fails most often in the field.

Step by step

1. IMS PDN up The UE has an IP address on the IMS APN and a default QCI 5 bearer.
2. P-CSCF discovery The P-CSCF address comes from the PCO in the PDN (or PDU session) response. Alternatives: DHCPv6/DHCP with DNS lookup, or static configuration. Over VoWiFi it comes in the IKEv2 configuration payload.
3. Initial REGISTER (unprotected) Sent to the P-CSCF with the IMPI (in the Authorization header), the IMPU (in From/To), the Contact with feature tags (for example, MMTel ICSI, +g.3gpp.smsip, video), Expires, and a Security-Client header offering IPsec algorithms and SPIs/ports.
4. Routing to the S-CSCF The P-CSCF adds Path and P-Visited-Network-ID and forwards to the I-CSCF (found by DNS for the home domain). The I-CSCF sends a Diameter UAR to the HSS and learns which S-CSCF to use (or the capabilities needed to choose one).
5. Authentication challenge The S-CSCF sends MAR to the HSS and receives an authentication vector: RAND, AUTN, XRES, CK, IK. It answers 401 Unauthorized with WWW-Authenticate: Digest algorithm=AKAv1-MD5, nonce=base64(RAND+AUTN). It also passes CK and IK to the P-CSCF, which removes them before forwarding the 401 to the UE.
6. ISIM runs AKA The ISIM (or USIM) checks AUTN (this authenticates the network and checks the sequence number SQN), computes RES, and derives CK and IK.
7. IPsec SA setup The UE and P-CSCF now both hold CK and IK, so they set up a pair of IPsec ESP security associations (protected client and server ports) as agreed in Security-Client/Security-Server.
8. Second REGISTER (protected) Sent over the new IPsec SA, with the digest response computed using RES, and a Security-Verify header echoing the server's offer (protection against downgrade attacks).
9. 200 OK The S-CSCF compares RES with XRES, sends SAR to the HSS to download the user profile (including iFC), and returns 200 OK with Service-Route, P-Associated-URI, the granted Expires and (optionally) GRUUs.
10. Third-party registration The S-CSCF evaluates iFC and sends a REGISTER on the user's behalf to application servers such as the TAS, so they know the user is online.
11. Reg-event subscription The UE sends SUBSCRIBE (Event: reg) and gets a NOTIFY with its registration state. The P-CSCF also subscribes. Later NOTIFYs report network-initiated de-registration or re-authentication requests.
12. Re-registration Before the registration expires, the UE re-registers (typically at half the expiry for short timers, or 600 seconds before expiry for long ones). A new AKA challenge may be issued, creating new SAs.

  UE (ISIM)          P-CSCF             I-CSCF          HSS            S-CSCF         TAS
     │                  │                  │              │                │             │
     │ REGISTER ───────►│ (Security-Client)│              │                │             │
     │                  │ REGISTER ───────►│ UAR ────────►│                │             │
     │                  │                  │◄──────── UAA │                │             │
     │                  │                  │ REGISTER ─────────────────────►│             │
     │                  │                  │              │◄────── MAR ────│             │
     │                  │                  │              │ MAA (RAND,AUTN,XRES,CK,IK) ─►│
     │                  │◄──────────── 401 Unauthorized (nonce, CK, IK) ───│             │
     │◄─ 401 (nonce) ───│ (P-CSCF keeps CK/IK, adds Security-Server)       │             │
     │ AKA: verify AUTN, compute RES, derive CK/IK                         │             │
     │═══ IPsec SAs established between UE and P-CSCF ═══                  │             │
     │ REGISTER (RES) ─►│ (over IPsec, Security-Verify)                    │             │
     │                  │ REGISTER ───────►│ UAR/UAA ────►│                │             │
     │                  │                  │ REGISTER ─────────────────────►│             │
     │                  │                  │              │◄────── SAR ────│             │
     │                  │                  │              │ SAA (profile, iFC) ─────────►│
     │◄──────────────── 200 OK (Service-Route, P-Associated-URI, Expires) ─│             │
     │                  │                  │              │                │ REGISTER ──►│
     │                  │                  │              │                │◄──── 200 ───│
     │ SUBSCRIBE (reg) ────────────────────────────────────────────────────►│             │
     │◄──────────────── 200 OK, then NOTIFY (reg state: active) ───────────│             │

IMS-AKA in more detail

• Mutual authentication: AUTN proves the network knows the shared key K (the UE authenticates the network), and RES proves the UE knows K (the network authenticates the UE).
• Sequence number protection: AUTN contains SQN. If the SIM finds SQN out of range, it returns a synchronisation failure with an auts parameter in the next REGISTER; the S-CSCF passes AUTS to the HSS, which resynchronises and issues a fresh challenge.
• MAC failure: if AUTN does not verify, the UE sends a REGISTER with an empty response (or stops), meaning it does not trust the network. Often caused by a wrong key/profile on the SIM or HSS.
• Keys: CK (cipher key) and IK (integrity key) are used for the IPsec SAs. Integrity protection is mandatory; encryption on Gm is optional and operator-configured.
• Without ISIM: the UE uses the USIM and derives the IMPI/IMPU from the IMSI. Some operators use SIP Digest or GIBA (early IMS) instead of AKA, but VoLTE (GSMA IR.92) requires IMS-AKA with IPsec.

De-registration and network events

• UE-initiated de-registration: REGISTER with Expires: 0 (for example, on airplane mode or power off).
• Network-initiated: NOTIFY on the reg event with state terminated and an event such as deactivated (re-register now) or rejected (do not retry).
• Registration timers: the UE requests a long expiry (VoLTE profiles often request 600000 seconds) and the network grants a shorter one, commonly 3600 seconds.
• P-CSCF failure: if the P-CSCF stops responding, the UE tries the next P-CSCF address from the PCO list and performs a fresh initial registration.

Common registration failures

VoLTE and VoNR call setup: the SIP ladder

"Walk me through a VoLTE call" is the single most asked IMS question. The SIP flow is the same for VoNR and VoWiFi; only the radio and the QoS mechanism change. The key idea is preconditions: the network reserves the voice bearer on both sides before the callee's phone rings.

Mobile-originated (MO) call, end to end

  UE-A          P-CSCF-A     S-CSCF-A / TAS      S-CSCF-B / TAS     P-CSCF-B        UE-B
   │               │               │                    │                 │              │
 1 │─INVITE (SDP offer: AMR-WB/EVS, precondition curr=none, des=mandatory)─►              │
   │               │──INVITE──────►│ (iFC: TAS orig)    │                 │              │
 2 │◄─100 Trying───│               │──INVITE───────────►│ (via I-CSCF/LIR)│              │
   │               │               │                    │──INVITE────────►│──INVITE─────►│
   │               │               │                    │                 │  (paging if idle)
 3 │◄───────────── 183 Session Progress (SDP answer: one codec, Require: 100rel) ────────│
   │   P-CSCF-A and P-CSCF-B send Rx AAR ──► PCRF ──► P-GW: create QCI 1 bearer each side
 4 │─PRACK────────────────────────────────────────────────────────────────────────────►│
 5 │◄──────────────────────────────────────────────────────────────── 200 OK (PRACK) ──│
   │   == QCI 1 dedicated bearer active on A side ==      == on B side ==              │
 6 │─UPDATE (SDP: local precondition met, curr=sendrecv) ─────────────────────────────►│
 7 │◄──────────────────────────────────────────────────────────────── 200 OK (UPDATE) ─│
   │                                   (both sides' resources ready: UE-B now alerts)   │
 8 │◄──────────────────────────────────────────────────────────────── 180 Ringing ─────│
 9 │◄──────────────────────────────────────────────────────────────── 200 OK (INVITE) ─│
10 │─ACK──────────────────────────────────────────────────────────────────────────────►│
   │═════════════════ RTP/RTCP voice on QCI 1 (both directions) ════════════════════════│
11 │─BYE──────────────────────────────────────────────────────────────────────────────►│
12 │◄──────────────────────────────────────────────────────────────── 200 OK (BYE) ────│
   │   P-CSCFs send Rx STR ──► PCRF ──► dedicated bearers released                      │

1. INVITE with SDP offer UE-A lists its codecs (EVS, AMR-WB, AMR-NB, telephone-event for DTMF), its IP address and RTP port, bandwidth, and precondition attributes saying "local QoS is not yet reserved but is mandatory". It carries Supported: 100rel, precondition and the MMTel feature tag.
2. 100 Trying Hop-by-hop: the P-CSCF tells the UE it received the INVITE, so the UE stops retransmitting. It is not end to end.
3. Routing S-CSCF-A runs originating iFC (the TAS applies outgoing barring, CLIR and so on), then finds the terminating network. In the home network of UE-B, the I-CSCF sends LIR to the HSS to find S-CSCF-B, which runs terminating iFC (the TAS applies forwarding and call waiting) and forwards via P-CSCF-B to UE-B. If UE-B is idle, the MME pages it first.
4. 183 Session Progress with SDP answer UE-B picks one codec and returns its own media address. The 183 must be sent reliably (Require: 100rel, with an RSeq number). When each P-CSCF sees the offer/answer, it sends the media details over Rx to the PCRF, which asks the P-GW to create a QCI 1 dedicated bearer for that UE.
5. PRACK and 200 OK UE-A acknowledges the reliable 183 with PRACK (carrying RAck). Without PRACK the 183 would be retransmitted.
6. UPDATE When UE-A's bearer is up, it sends UPDATE with SDP saying its local precondition is now met. UE-B replies 200 OK.
7. 180 Ringing Once both sides have resources, UE-B alerts the user and sends 180. UE-A plays local ringback (or network early media if authorised).
8. 200 OK and ACK The callee answers; UE-A confirms with ACK, which completes the three-way handshake of the INVITE transaction. RTP flows.
9. BYE Either side hangs up with BYE; 200 OK confirms. The P-CSCFs end the Rx sessions and the dedicated bearers are released.

Why preconditions matter

Without preconditions, the callee's phone could ring and be answered before the network has granted the voice bearer. The user would pick up and hear silence, or the bearer request could fail after answer. The 183, PRACK and UPDATE sequence (RFC 3312 preconditions, RFC 3262 reliable provisional responses, RFC 3311 UPDATE) guarantees "no ringing until media can flow". If resources cannot be reserved, the call fails with 580 Precondition Failure instead of ringing and then going silent.

a=curr:qos local none          current status: local QoS not reserved yet
a=curr:qos remote none         remote QoS not reserved yet
a=des:qos mandatory local sendrecv    desired: local QoS is mandatory, both directions
a=des:qos mandatory remote sendrecv   desired: remote QoS is mandatory
a=conf:qos remote sendrecv     ask the peer to confirm when its QoS is ready

Mobile-terminated (MT) call: what differs

• The network first pages an idle UE on the default bearer path (the INVITE arrives at the P-GW and triggers downlink data notification), then delivers the INVITE.
• The UE sends 100 Trying (optional from a UA), then 183 with the SDP answer, and handles the incoming PRACK and UPDATE.
• Only when resources are ready does it alert the user and send 180 Ringing, then 200 OK when the user answers, and receives ACK.
• On the terminating side the S-CSCF runs terminating iFC, so forwarding (CFU, CFB, CFNRy) and call waiting happen before or during delivery.

A sample INVITE (trimmed)

INVITE tel:+15557654321 SIP/2.0
Via: SIP/2.0/UDP [2001:db8::10]:5064;branch=z9hG4bK-123;rport
Max-Forwards: 70
Route: <sip:[2001:db8::1]:5066;lr>, <sip:scscf.ims.example.com;lr>
From: <sip:+15551234567@ims.example.com>;tag=a1b2
To: <tel:+15557654321>
Call-ID: 8f3c21d7@2001:db8::10
CSeq: 1 INVITE
Contact: <sip:[2001:db8::10]:5064>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
P-Preferred-Identity: <sip:+15551234567@ims.example.com>
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=00101ABCD1234567
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Supported: 100rel, precondition, timer
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=1111; spi-s=2222; port-c=5064; port-s=5066
Session-Expires: 1800
Content-Type: application/sdp

v=0
o=- 1 1 IN IP6 2001:db8::10
s=-
c=IN IP6 2001:db8::10
t=0 0
m=audio 40000 RTP/AVP 116 107 97 118
b=AS:49
a=rtpmap:116 EVS/16000
a=fmtp:116 br=5.9-24.4; bw=nb-swb
a=rtpmap:107 AMR-WB/16000
a=fmtp:107 mode-change-capability=2; max-red=0
a=rtpmap:97 AMR/8000
a=rtpmap:118 telephone-event/16000
a=ptime:20
a=maxptime:240
a=sendrecv
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv

Voice codecs

• RTP carries 20 ms voice frames over UDP (so 50 packets per second). RTCP sends reception reports (loss, jitter, round-trip time) roughly every 5 seconds; some operators disable RTCP during active speech and rely on RTP inactivity timers.
• AMR payload format: "octet-aligned" and "bandwidth-efficient" modes are not compatible. If the offer and answer disagree (the octet-align=1 fmtp), the call connects but audio is garbled or silent.
• DTMF is sent as RTP telephone-event packets (RFC 4733), not as audio tones.
• ROHC (Robust Header Compression) in PDCP compresses the 40 to 60 byte IP/UDP/RTP header to a few bytes, which is essential for voice capacity and cell-edge coverage. SPS, TTI bundling, C-DRX and RLC UM are covered under voice quality and radio optimizations.

Early media, cancelling and ending calls

• Early media is media sent before answer, such as operator ringback tones or announcements ("the number you have dialled..."). It is signalled with SDP in a 18x response and authorised with the P-Early-Media header. If the UE plays local ringback while the network also sends early media, the user hears both, or hears nothing if the UE mutes the stream wrongly.
• CANCEL aborts an INVITE that has not yet received a final response (caller hangs up while ringing). The callee answers the INVITE with 487 Request Terminated.
• BYE ends an established dialog (after 200 OK and ACK). Using BYE before answer, or CANCEL after answer, is a classic bug.
• Session timers (RFC 4028, Session-Expires) make the endpoints refresh the dialog with re-INVITE or UPDATE periodically; if refresh fails, the call is torn down, so stuck calls do not hold resources forever.
• RTP inactivity timer: if no RTP or RTCP arrives for a configured period (often 10 to 20 seconds), the UE or network ends the call with a BYE carrying a Reason header such as "RTP timeout".

MMTel supplementary services and the Ut/XCAP interface

MMTel (Multimedia Telephony, 3GPP TS 24.173) is the IMS voice/video service. Its supplementary services run on the TAS, which the S-CSCF invokes through iFC. There are two control surfaces:

Ut / XCAP in practice

• The UE sends HTTP(S) requests to the XCAP server (the TAS or an XDMS) at an operator FQDN such as xcap.ims.mnc001.mcc001.pub.3gppnetwork.org.
• Authentication is usually GBA (Generic Bootstrapping Architecture: the UE bootstraps with a BSF using AKA, then gets a key for the application server, the NAF) or HTTP digest.
• Many operators route Ut over the internet APN or a dedicated xcap APN, not the IMS APN. So if mobile data is off, call forwarding settings can fail even though VoLTE calls work; operators fix this with carrier config options that allow Ut when data is disabled.

PUT /simservs.ngn.etsi.org/users/sip:+15551234567@ims.example.com/simservs.xml/~~/simservs/communication-diversion HTTP/1.1
Host: xcap.ims.example.com
Content-Type: application/xcap-el+xml

<communication-diversion active="true">
  <cp:ruleset>
    <cp:rule id="cfb">
      <cp:conditions><busy/></cp:conditions>
      <cp:actions><forward-to><target>tel:+15550001111</target></forward-to></cp:actions>
    </cp:rule>
  </cp:ruleset>
</communication-diversion>

SRVCC and its variants: keeping the call when LTE runs out

SRVCC (Single Radio Voice Call Continuity, TS 23.216) moves an active IMS voice call from LTE (packet-switched) to 2G/3G (circuit-switched) when the UE leaves LTE coverage and there is no VoLTE-capable target. "Single radio" means the UE cannot be connected to LTE and 2G/3G at the same time, so the network must coordinate the switch.

Prerequisites

• The UE indicates SRVCC capability in its attach (MS Network Capability) and the network supports it.
• The HSS gives the MME the STN-SR (Session Transfer Number for SRVCC, which routes to the SCC-AS or ATCF) and the C-MSISDN (correlation MSISDN).
• The MSC server is "enhanced for SRVCC" and connected to the MME over the Sv interface.
• The IMS session was anchored at the SCC-AS when it was set up.

Basic SRVCC flow (LTE to 2G/3G)

1. Trigger The UE's measurement reports show LTE is weak and a 2G/3G neighbour is good. The eNB, seeing an active QCI 1 bearer, sends Handover Required with an SRVCC indication to the MME.
2. Split voice from data The MME separates the voice bearer (QCI 1) from other bearers and sends a PS to CS Request over Sv to the MSC server, including STN-SR and C-MSISDN.
3. Prepare CS target The MSC server prepares radio resources in the target 2G/3G cell (relocation/handover request to the target MSC/BSC/RNC).
4. Session transfer in IMS The MSC server sends an INVITE to the STN-SR. The SCC-AS correlates it with the existing session (via C-MSISDN) and updates the remote leg with a re-INVITE so the far end now sends media to the CS media gateway. The far end sees only a media change, not a new call.
5. Handover command The MSC server answers the MME with PS to CS Response; the MME sends the handover command via the eNB; the UE retunes its single radio to 2G/3G.
6. Completion The call continues in CS. Non-voice bearers are handed over to 3G PS (if the target supports DTM/PS handover) or suspended. The old IMS access leg is released.

  UE        eNB         MME            MSC server         SCC-AS (IMS)        Far end
   │ meas rpt  │           │                 │                  │                  │
   │──────────►│ HO Req    │                 │                  │                  │
   │           │ (SRVCC) ─►│ PS to CS Req ──►│ (Sv)             │                  │
   │           │           │                 │ prepare 2G/3G target cell           │
   │           │           │                 │ INVITE STN-SR ──►│                  │
   │           │           │                 │                  │ re-INVITE ──────►│
   │           │           │                 │                  │ (media now to MGW)
   │           │           │◄─ PS to CS Resp │                  │◄──── 200 OK ─────│
   │◄── HO Command (to 2G/3G) ──│            │                  │                  │
   │═══ UE retunes to 2G/3G; voice continues over CS via MSC/MGW ═══════════════════│

The SRVCC family

How SRVCC compares with the other voice continuity procedures

VoWiFi (Wi-Fi Calling) and LTE to Wi-Fi handover

VoWiFi is the same IMS voice service reached over a Wi-Fi access leg instead of cellular. The IMS core, P-CSCF, SIP signaling and call ladder are identical; only the path from the UE to the IMS APN changes. Understanding that single fact makes both the architecture and the handover easy to explain.

Architecture

  UNTRUSTED Wi-Fi (home router, cafe, hotel: the common case)

  UE ──Wi-Fi AP──► Internet ──SWu──► ePDG ──S2b──► P-GW ──► P-CSCF / IMS core
        │                    (IKEv2/IPsec,         (GTPv2 or
        │                     EAP-AKA auth)         PMIPv6)
        │                         │
        │                         └──SWm──► 3GPP AAA ──SWx──► HSS
        └── all IMS SIP and RTP travel INSIDE the IPsec tunnel to the ePDG

  5G equivalent:   UE ──NWu (IPsec)──► N3IWF ──N2/N3──► AMF, UPF ──► IMS
  Trusted WLAN:    UE ──► TWAG ──S2a──► P-GW ──► IMS   (operator-controlled Wi-Fi, no ePDG)

Bringing up Wi-Fi calling

1. Wi-Fi connected and WFC enabled The user has Wi-Fi calling turned on, the operator has enabled it (carrier config and entitlement), and an emergency address may need to be registered first (in the US, E911 address provisioning via an entitlement server).
2. ePDG selection The UE resolves the ePDG FQDN by DNS (possibly choosing a visited-country ePDG when roaming, based on policy).
3. IKEv2 tunnel setup IKE_SA_INIT (Diffie-Hellman, nonces), then IKE_AUTH carrying the IMSI-based identity and the IMS APN. The ePDG runs EAP-AKA with the AAA/HSS, using the same SIM credentials. The IKEv2 configuration payload returns the UE's inner IP address and the P-CSCF address (instead of PCO).
4. S2b session The ePDG creates a GTP session to the P-GW for the IMS APN, which allocates the IP address.
5. IMS registration The same IMS-AKA REGISTER runs inside the IPsec tunnel, so there are two layers of IPsec: the outer SWu tunnel and the inner Gm SA to the P-CSCF.
6. Keep-alives IKEv2 dead-peer-detection and NAT-keepalive packets keep the tunnel open through home routers (NAT traversal uses UDP port 4500).

VoLTE versus VoWiFi

Handover 1: VoLTE to VoWiFi (walking indoors, Wi-Fi preferred)

  Active VoLTE call on QCI 1 over LTE
   1 │ UE sees usable Wi-Fi (RSSI, quality above threshold) and policy prefers Wi-Fi
   2 │ UE brings up the IKEv2/IPsec tunnel to the ePDG (EAP-AKA)
   3 │ IKE_AUTH carries the IMS APN plus the current IP address (handover indication)
   4 │ ePDG sends Create Session with the Handover Indication to the SAME P-GW
   5 │ P-GW keeps the SAME IMS IP ADDRESS and switches the downlink path to S2b
   6 │ Because the IP and SIP dialog survive, the call stays up
   7 │ UE sends re-REGISTER (new P-Access-Network-Info) and, if needed, re-INVITE/UPDATE
   8 │ LTE QCI 1 dedicated bearer is released; the IMS PDN now lives on Wi-Fi
     │═══════ call continues with no drop (ideally make-before-break) ═══════

Handover 2: VoWiFi to VoLTE (Wi-Fi fades, leaving the building)

  Active VoWiFi call through the ePDG IPsec tunnel
   1 │ UE sees Wi-Fi degrading (RSSI, packet loss, jitter) and LTE is good with IMS VoPS
   2 │ UE sends PDN Connectivity Request (Request Type = HANDOVER) for the IMS APN
   │   (or a Handover Attach if it was not attached to LTE)
   3 │ MME selects the SAME P-GW; P-GW keeps the SAME IMS IP ADDRESS
   4 │ P-GW/PCRF set up the QCI 1 dedicated bearer on LTE for the ongoing call
   5 │ UE re-REGISTERs / sends re-INVITE or UPDATE as needed; media now over LTE
   6 │ ePDG tunnel is torn down
     │═══════ call continues over cellular with no drop ═══════

What decides the handover

• WFC preference modes: Wi-Fi preferred, cellular preferred, Wi-Fi only (some operators also have "never use cellular while roaming").
• Thresholds: Wi-Fi RSSI, packet loss, jitter and round-trip time versus LTE RSRP/RSRQ, with hysteresis to avoid ping-pong.
• Operator policy: ANDSF in LTE, URSP in 5G, carrier config, plus roaming and emergency rules.
• Who decides: the UE (unlike SRVCC, which the network commands). On Android, the QualifiedNetworksService (QNS) decides whether the IMS APN should be on WWAN (cellular) or WLAN (Wi-Fi), and the IWLAN data service brings up the ePDG tunnel.

Why it is seamless, and what breaks it

• Make-before-break: the new access leg is built before the old one is released, so there is no media gap.
• IP preservation: the handover indication tells the P-GW to reuse the existing session and IP address.
• Breaks if: the new PDN is created as an initial request instead of a handover, so the UE gets a new IP address and the SIP dialog (bound to the old Contact) dies; the target P-GW is different; the IPsec tunnel is too slow to come up before LTE is lost; or the UE is not registered in time on the new access.
• Other VoWiFi issues: NAT timeouts on home routers killing the tunnel, MTU problems because of double IPsec overhead (fragmented SIP), captive portals, and Wi-Fi power save causing jitter.

ViLTE, RCS and IMS emergency calls

ViLTE (video over LTE) and video over NR

• Same SIP flow as VoLTE, but the SDP has a second m=video line (H.264, increasingly H.265/HEVC) alongside m=audio.
• Video uses its own dedicated bearer: QCI 2 (GBR, conversational video) in the standard model; some operators use non-GBR QCI 7 or 8 instead. Audio stays on QCI 1, so voice quality is protected even when video struggles.
• Upgrade and downgrade between voice and video are re-INVITEs that add or remove the video m-line (or set its port to 0). The other party can accept or decline the upgrade.
• RTCP feedback (AVPF) carries picture loss indications (PLI), full intra requests (FIR) and bit-rate adaptation (TMMBR), because video is sensitive to loss.
• CVO (Coordination of Video Orientation) sends the camera rotation in an RTP header extension so the receiver can rotate the picture.

RCS (Rich Communication Services)

• The GSMA standard for rich messaging over IMS, marketed as the SMS successor ("Universal Profile"): chat, group chat, file transfer, read receipts, typing indicators, business messaging (chatbots, also called MaaP).
• Chat sessions use MSRP (Message Session Relay Protocol) set up with a SIP INVITE; short messages can use pager-mode SIP MESSAGE.
• File transfer uses HTTP upload to a content server, with a link sent in the chat.
• Capability discovery uses SIP OPTIONS exchanges or presence (SUBSCRIBE/NOTIFY) with feature tags, so the client knows whether the other user supports RCS.
• Configuration comes from an HTTP auto-configuration server (ACS). The RCS client can share the IMS registration of the voice stack (single registration) or register separately.
• On Android, RCS is exposed through RcsFeature of the ImsService and APIs such as ImsRcsManager.

IMS emergency calls (E-911, 112)

1. Detection The UE recognises the dialled number as an emergency number (from the SIM, the network's emergency number list in NAS, carrier config, or the standard 112/911).
2. Emergency PDN / PDU session The UE sets up a separate emergency connection (PDN Connectivity Request with request type "emergency"; APN often sos). The network gives it high priority (high ARP) and, depending on country rules, allows it even without a valid SIM or subscription (emergency attach).
3. Emergency registration The UE performs an emergency REGISTER (Contact with the sos parameter). If the UE cannot register (for example, no SIM or roaming restriction), many networks accept an anonymous emergency call without registration.
4. Emergency INVITE The Request-URI is urn:service:sos (or a subtype such as urn:service:sos.police). The P-CSCF recognises it and routes it to the E-CSCF, not to the home S-CSCF, so it works when roaming.
5. Location and PSAP routing The E-CSCF asks the LRF for location and the correct PSAP (Public Safety Answering Point). Location comes from the P-Access-Network-Info cell ID, a Geolocation header with a PIDF-LO body, the GMLC (network positioning), or, over Wi-Fi, the registered civic address.
6. Network-detected emergency If the network recognises a number as emergency but the UE did not, it can answer 380 Alternative Service, telling the UE to redial as an emergency call.
7. Fallback If IMS emergency is not possible (no IMS emergency support in the cell, or the emergency PDN fails), the UE uses CS emergency (CSFB to 2G/3G) or tries another access. Over Wi-Fi, operators may require emergency calls to prefer cellular when available.
8. Callback The PSAP can call back; the UE enters an emergency callback mode for a period so the callback is not blocked by barring or Wi-Fi-only preferences.

SIP and SDP internals

SIP (RFC 3261) is a text-based, HTTP-like request/response protocol that sets up, modifies and ends sessions. It does not carry media itself. SDP (RFC 4566) is the body inside SIP that describes the media: IP address, ports, codecs and direction. SIP runs over UDP, TCP or TLS on port 5060 (5061 for TLS); in IMS the UE uses the protected ports negotiated for the IPsec SAs. Per RFC 3261, when a request is larger than about 1300 bytes (within 200 bytes of the path MTU) the UE should use TCP instead of UDP to avoid fragmentation.

SIP methods

SIP response codes

Core SIP headers

IMS-specific (P-) headers

Transactions versus dialogs

• A transaction is one request plus all its responses, matched by the top Via branch and the CSeq method. INVITE transactions end with ACK (for non-2xx the ACK is part of the transaction; for 2xx the ACK is a separate end-to-end request).
• A dialog is the long-lived peer relationship between two UAs, identified by Call-ID plus the From tag plus the To tag. It is created by a 2xx (or a reliable 18x creating an early dialog) to INVITE, spans many transactions (PRACK, UPDATE, re-INVITE) and ends with BYE.
• One INVITE can create several early dialogs if it forks to several devices (different To tags); only one becomes confirmed when answered.

SIP timers

• T1 is the round-trip estimate: 500 ms in RFC 3261, but 3GPP TS 24.229 recommends 2 s for the UE over radio (with T2 = 16 s, T4 = 17 s).
• Over UDP, requests are retransmitted at T1, 2xT1, 4xT1 and so on until a response arrives.
• Timer B (INVITE timeout) and Timer F (non-INVITE timeout) are 64 x T1: 32 s by default, 128 s with the IMS T1 of 2 s. When they fire, the UE treats the transaction as failed (like a 408).

SDP offer/answer

• RFC 3264: the offerer lists media streams, codecs (payload types), addresses and ports; the answerer accepts a subset (in VoLTE, one audio codec) and supplies its own address. In VoLTE the offer is in the INVITE and the answer in the 183. A UA may also send an INVITE with no SDP, in which case the offer comes in the response and the answer in the ACK (or PRACK).
• Only one offer/answer can be outstanding at a time; a new offer before the previous one is answered causes 491 or 500.
• Key SDP lines: c= connection address, m= media line with port and payload types, a=rtpmap codec mapping, a=fmtp codec parameters, a=ptime, b=AS bandwidth, direction attributes, precondition attributes.
• Direction attributes: sendrecv (normal), sendonly (I only send: I am holding), recvonly (I only receive: I am held), inactive (no media either way).
• Port 0 on an m-line means that stream is rejected or removed (for example, declining a video upgrade).

QoS, bearers and policy control (PCC)

Voice over IP sounds good only if packets arrive on time. In LTE and 5G the network guarantees this with bearers (LTE) or QoS flows (5G), set up on demand by the policy framework. This is what makes VoLTE deterministic compared with over-the-top VoIP apps.

EPS bearer concepts

• Default bearer: created with each PDN connection, always on while the PDN exists, always non-GBR. It catches all traffic not matched by a dedicated bearer. The IMS APN's default bearer uses QCI 5.
• Dedicated bearer: created on demand for specific flows; may be GBR. The voice RTP stream uses a QCI 1 GBR dedicated bearer.
• TFT (Traffic Flow Template): packet filters (source and destination IP, ports, protocol) that map flows onto a bearer, in both uplink (the UE applies them) and downlink (the P-GW applies them).
• GBR / MBR: guaranteed and maximum bit rate for GBR bearers (for AMR-WB 23.85 with overhead, roughly 40 to 50 kbit/s each way).
• ARP (Allocation and Retention Priority): decides who gets admitted, and who can be pre-empted, under congestion. Emergency and priority calls get high ARP. ARP does not affect packet scheduling; QCI does.
• AMBR (Aggregate Maximum Bit Rate) limits the total of all non-GBR bearers per APN or per UE.

Standardised QCI table (LTE, TS 23.203)

Do not invert the two IMS QCIs. QCI 1 is conversational voice: a GBR dedicated bearer with a 100 ms delay budget and 10^-2 loss. QCI 5 is IMS signalling on the default bearer of the IMS APN. Among the everyday QCI 1–9 set, QCI 5 has scheduling priority 1 (QCI 1 is priority 2) so SIP is not starved by other default or non-GBR traffic such as QCI 9 internet; that is high priority relative to other default bearers, not a claim that signalling is "more important than voice". Voice quality is protected by the GBR reservation. Mission-critical QCIs (65, 69) have even tighter priority numbers. In 5G the 5QI values 1, 2, 5 and 9 keep the same meaning (5QI 1 is still voice, 5QI 5 is still SIP), and 5G adds delay-critical GBR 5QIs (such as 82 to 86) for URLLC.

The PCC chain that creates the voice bearer

  UE-A ──SIP 183 (SDP answer)──► P-CSCF
                                    │  Rx AAR: media components (IPs, ports, codec, bandwidth)
                                    ▼
                              PCRF (LTE) / PCF (5G, via N5)
                                    │  derives PCC rule: QCI 1, GBR/MBR, ARP, TFT filters
                                    │  Gx RAR (LTE) / N7 (5G)
                                    ▼
                         P-GW (PCEF) / SMF ──► UPF
                                    │  Create Bearer Request (LTE) / PDU Session Modification (5G)
                                    ▼
                         MME ──► eNB: E-RAB setup   |   AMF ──► gNB: QoS flow + DRB
                                    │
                                    ▼
                    UE: Activate Dedicated EPS Bearer Context (with TFT)
                    eNB/gNB enforce GBR scheduling on the air interface

• The P-CSCF also asks the PCRF to notify it of events on the bearer (for example, bearer loss or access network change), so the IMS layer can react to a lost media path.
• At call end, the P-CSCF sends Rx STR (session termination), and the PCRF removes the rule; the dedicated bearer is deleted.
• Rx gating: the PCRF can open or close the media gate so RTP only flows after the call is authorised.

5G QoS model

• EPS bearers become QoS flows inside one PDU session, each marked with a QFI (QoS Flow Identifier) on the N3 GTP-U tunnel.
• The SDAP layer in the UE and gNB maps QoS flows onto data radio bearers (DRBs); several flows can share a DRB.
• The PCF (policy), SMF (session control) and UPF (packet marking and enforcement) replace the PCRF, P-GW control and P-GW user plane.
• VoNR uses 5QI 1 for voice and 5QI 5 for IMS signaling, mirroring LTE.

IMS on Android (brief)

On Android the SIP stack itself usually lives in the vendor's IMS implementation (in the modem or a vendor daemon); the framework talks to it through a stable API. The full class-by-class dial path, vendor splits and the IMS-to-CS fallback code are covered in Call flows.

  Dialer ─► Telecom ─► TelephonyConnectionService ─► GsmCdmaPhone.dial()
                                                        │ IMS registered and usable?
                                          yes ◄─────────┴─────────► no
                                           │                         │
                                  ImsPhone ─► ImsPhoneCallTracker     GsmCdmaCallTracker ─► RIL (CS)
                                           │
                                  ImsService / MmTelFeature (vendor) ─► SIP INVITE ... RTP

Debugging IMS: a practical playbook

Most IMS interview scenarios are debugging stories. The winning habit is to work layer by layer and align timestamps: radio (RRC), NAS (attach, PDN, bearers), IMS (SIP), media (RTP), and framework (Android telephony logs).

Tools and logs

• Modem logs: Qualcomm QXDM/QCAT/PCAT, MediaTek ELT; these include decoded NAS, RRC, SIP and RTP statistics.
• Wireshark or tshark on SIP, RTP, RTCP, Diameter (Rx, Cx, Gx), GTP and IKEv2 captures, from the device or the core.
• Android: adb logcat -b radio, dumpsys telephony.registry, dumpsys carrier_config, the IMS service's dumpsys.
• Network side: SBC/P-CSCF call traces, HSS and PCRF logs, operator KPI dashboards.

Symptom to root cause map

Voice quality and radio optimizations

Interviewers who have shipped VoLTE often skip SIP and ask how the call actually sounds. Quality is a delay-loss-rate triangle: the GBR bearer buys a delay budget, the codec hides remaining loss, and a handful of radio features keep the uplink alive at the cell edge.

Mouth-to-ear delay and G.114

ITU-T G.114 recommends one-way mouth-to-ear delay under about 150 ms for users not to notice; 150 to 400 ms is acceptable with growing annoyance; above 400 ms conversation becomes difficult (talker overlap). The budget is spent on codec framing (typically 20 ms plus look-ahead), packetization, uplink and downlink air interface (including HARQ), backhaul and core, far-end jitter buffer, and playout. QCI 1 / 5QI 1's 100 ms packet delay budget is the network slice of that path, not the whole mouth-to-ear number.

Jitter buffer, PLC and MOS

• Jitter buffer absorbs packet delay variation so frames can be played at a steady 20 ms cadence. A deeper buffer hides more jitter but adds delay (and can push the call past the G.114 target). Adaptive jitter buffers grow when RTCP or arrival statistics show variance, and shrink when the path is stable. EVS channel-aware mode needs extra depth so the redundant copy can arrive.
• PLC (Packet Loss Concealment) is the decoder inventing a plausible frame when a packet never arrives: repetition, pitch-based interpolation, or comfort noise. It hides isolated losses; a burst still sounds robotic. Combined with HARQ on the air and (for EVS) partial redundancy, PLC is why voice can use RLC UM instead of waiting for ARQ.
• MOS (Mean Opinion Score) is a 1-to-5 listening-quality scale. Lab tests use real listeners; operators predict MOS with the ITU-T E-model (G.107 / G.107.1 for wideband): an R-factor from delay, loss, jitter, codec impairment and echo, then mapped to MOS. A typical VoLTE KPI bar is MOS around 4.0 or better on AMR-WB or EVS in good radio.

Rate adaptation: CMR and ANBR

• CMR (Codec Mode Request) is an in-band bit in the AMR or EVS payload telling the sender to change mode (bit rate). Either end, or a transcoder, can send it when loss or congestion appears.
• ANBR (Access Network Bitrate Recommendation, TS 26.114 / TS 36.331 and the NR equivalents) is the RAN telling the UE a recommended uplink or downlink bit rate for the voice flow, typically after the gNB/eNB can no longer honour the GBR (notification control). The UE then issues a CMR or a bitrate recommendation toward the far end so the codec steps down before the air interface starts dropping frames.
• Without adaptation, a cell-edge UE keeps sending 23.85 kbit/s AMR-WB into a fading uplink and the far end hears chopping. With CMR/ANBR the call stays intelligible at a lower mode.

Radio features that make VoLTE work

On NR the same ideas appear with different names: ROHC and RLC UM stay; SPS becomes configured grant or SPS-like periodic grants; TTI bundling becomes PUSCH repetition or slot aggregation; C-DRX is still tuned to 20 ms frames. See 5G NR for VoNR radio and EPS fallback.

VoLTE versus VoNR

Voice-centric versus data-centric usage setting

This is a UE setting (TS 24.301 for EPS, TS 24.501 for 5GS), not the same thing as the network's IMS VoPS bit.

• Voice-centric UE: the user expects a phone. If the camped RAT cannot provide voice (IMS VoPS not indicated and CS fallback not usable), the UE disables that RAT for this PLMN and reselects to one that can (2G/3G from LTE, or EPS from 5GS). This is why a "good LTE" cell with no VoLTE and no CSFB still loses the UE to 3G.
• Data-centric UE: the user expects data. The UE stays on LTE or NR even when voice is unavailable; a dial may fail or leave the RAT only for that call.
• Voice domain preference (CS only, IMS PS only, CS preferred, IMS preferred) is a separate NAS parameter that chooses which voice domain to try first. Usage setting decides whether the UE is allowed to remain on a data-only RAT.

IMS roaming: S8HR versus local breakout

GSMA IR.65 and IR.92 describe two ways to keep IMS voice when the UE is in a visited PLMN. Do not call local breakout "the" standardised model. S8HR (S8 Home Routed) is the model most operators actually deploy, because the visited network only has to home-route the IMS APN over S8.

S8HR drawbacks you should name

• Emergency: the P-CSCF is in the home country, so routing urn:service:sos to the visited PSAP is awkward. Devices typically use CS emergency, an emergency APN with local breakout, or operator-specific S8HR emergency procedures. Interviewers treat "S8HR plus emergency" as a follow-up.
• Lawful intercept: the visited operator sees GTP on S8, not clear SIP or easily isolated RTP. Home-country LI works; visited-country LI of the IMS session needs extra architecture or is simply incomplete.
• No local ATCF: eSRVCC wants the ATCF/ATGW in the serving network, close to the UE. S8HR puts the P-CSCF at home, so a local ATCF is not inserted. Roaming eSRVCC is typically unavailable; a basic SRVCC transfer through the home SCC-AS has a long media path and a large voice gap, and many VPLMNs do not offer it.
• Trombone delay: RTP hairpins through the home P-GW. Intercontinental S8 can spend a large part of the G.114 150 ms budget before the far end is even reached.

LBO avoids those four problems and is why it looks attractive on a whiteboard. It loses on operational cost: every visited partner needs an IMS interconnect, not just an S8 tunnel. That is why S8HR won in the field.

Quick revision

• IMS is the SIP-based service core that separates access (LTE, NR, Wi-Fi), transport (EPC/5GC) and service control.
• P-CSCF: the UE's only SIP peer, IPsec endpoint, identity asserter, and the node that asks PCRF/PCF for the voice bearer.
• I-CSCF: home-network entry; uses Cx UAR (registration) and LIR (terminating calls) to find the S-CSCF.
• S-CSCF: registrar, authenticates with MAR, downloads the profile with SAR, runs iFC to invoke application servers.
• HSS (UDM in 5G) stores IMPI/IMPU, AKA vectors, iFC, S-CSCF name, STN-SR and C-MSISDN.
• TAS runs MMTel supplementary services; MRF handles announcements and conference mixing; BGCF/MGCF/IMS-MGW break out to the PSTN; IBCF guards interconnects.
• IMS runs on a separate APN (ims): default bearer QCI 5 for SIP, dedicated GBR QCI 1 for voice, QCI 2 for video.
• The P-CSCF address comes from the PCO (cellular) or the IKEv2 configuration payload (Wi-Fi).
• Registration: REGISTER, 401 with AKA challenge, IPsec SA, protected REGISTER, 200 OK, third-party REGISTER, SUBSCRIBE reg event.
• The IPsec SA is set up after the 401 using CK/IK; the P-CSCF strips CK/IK from the 401 before forwarding.
• SQN out of range leads to a sync failure with AUTS and a fresh challenge; a MAC failure means the UE rejected the network.
• MO ladder: INVITE, 100, 183 (SDP answer), PRACK, 200, bearer reserved, UPDATE, 200, 180, 200 OK, ACK, RTP, BYE, 200.
• Preconditions stop the phone ringing before both sides have a QCI 1 bearer; failure gives 580 Precondition Failure.
• PRACK makes a provisional response reliable (100rel, RSeq/RAck); UPDATE changes session state before answer.
• MT differs by paging first and by the UE sending 183, then 180 after resources are ready, then 200 on answer.
• Codecs: AMR-NB (narrowband), AMR-WB (HD Voice, mandatory for VoLTE), EVS (super-wideband/fullband, channel-aware mode).
• CANCEL aborts an unanswered INVITE (callee returns 487); BYE ends an established dialog.
• Hold is a re-INVITE with sendonly or inactive; resume uses sendrecv.
• Call forwarding and barring are configured over Ut using XCAP (HTTP), often authenticated with GBA; the TAS enforces them.
• Conference: INVITE to the conference factory URI, then REFER each party; transfer uses REFER.
• SRVCC moves an active IMS call to 2G/3G CS via MME, Sv, MSC server and SCC-AS using STN-SR and C-MSISDN.
• eSRVCC anchors media at the ATCF/ATGW in the serving network, cutting the voice gap to under about 300 ms.
• aSRVCC covers the alerting phase, bSRVCC the pre-alerting phase, vSRVCC video, rSRVCC CS back to LTE.
• VoWiFi: IKEv2/IPsec tunnel over SWu to the ePDG (EAP-AKA), S2b to the P-GW, then the same IMS; N3IWF in 5G.
• LTE to Wi-Fi handover keeps the call because the P-GW keeps the same IMS IP when the request is handover type.
• VoWiFi has no GBR bearer; it relies on DSCP EF and Wi-Fi WMM marking.
• Emergency: emergency PDN, emergency registration, urn:service:sos, E-CSCF, LRF location, PSAP; 380 tells the UE to redial as emergency.
• ViLTE adds an m=video line and a QCI 2 bearer; upgrade and downgrade are re-INVITEs.
• RCS chat uses MSRP set up by SIP INVITE; capability discovery uses OPTIONS or presence; file transfer uses HTTP.
• Transaction = request plus responses (Via branch + CSeq); dialog = Call-ID + From tag + To tag.
• IMS T1 is 2 s on the UE, so Timer B and F are 128 s; large SIP requests should go over TCP.
• PCC chain: P-CSCF Rx/N5 to PCRF/PCF, Gx/N7 to P-GW/SMF, dedicated bearer or QoS flow down to the eNB/gNB.
• QCI 1 is conversational voice (GBR, 100 ms, 10^-2 loss); QCI 5 is IMS signalling on the default bearer, with high scheduling priority relative to other default bearers such as QCI 9; ARP controls admission and pre-emption only.
• On Android, the vendor ImsService provides MmTelFeature and RcsFeature; ImsPhone handles IMS calls in the framework.
• G.114 mouth-to-ear target is about 150 ms; the QCI 1 PDB is only the network slice of that path.
• Jitter buffer trades delay for smoothness; PLC hides isolated loss; MOS/E-model scores listening quality.
• CMR (in-band) and ANBR (RAN bitrate recommendation) step the codec down at the cell edge.
• VoLTE radio: ROHC, SPS, TTI bundling, C-DRX aligned to 20 ms, RLC UM (no ARQ stall).
• VoNR keeps the same SIP ladder; QoS becomes a 5QI 1 flow, policy is N5/N7, coverage exit is EPS fallback or VoNR-to-VoLTE HO.
• Voice-centric UE leaves a RAT that cannot provide voice; data-centric stays. Usage setting is not the IMS VoPS bit.
• S8HR is the common IMS roaming model (home P-GW and P-CSCF). LBO is specified but not "the" GSMA model. S8HR costs: emergency, LI, no local ATCF, trombone delay.

Glossary

3GPP AAA server

Authenticates and authorises non-3GPP (Wi-Fi) access using EAP-AKA against the HSS.

AKA

Authentication and Key Agreement: SIM-based challenge-response that authenticates both sides and derives CK and IK.

AMR-WB

Adaptive Multi-Rate Wideband codec (50 to 7000 Hz), the baseline HD Voice codec for VoLTE.

ANBR

Access Network Bitrate Recommendation: the RAN tells the UE a recommended codec bit rate when the GBR cannot be honoured.

APN

Access Point Name: identifies a packet data network such as ims or internet.

ARP

Allocation and Retention Priority: decides bearer admission and pre-emption under congestion.

ATCF / ATGW

Access Transfer Control Function and Gateway: local anchors for signaling and media used by eSRVCC.

BGCF

Breakout Gateway Control Function: chooses where a call leaves IMS towards the PSTN.

C-MSISDN

Correlation MSISDN used by the SCC-AS to match the SRVCC transfer to the existing session.

CMR

Codec Mode Request: an in-band AMR/EVS signal asking the sender to change bit-rate mode.

CSFB

Circuit-Switched Fallback: an LTE UE without VoLTE moves to 2G/3G to make or receive a voice call.

Dedicated bearer

An on-demand EPS bearer, often GBR, with a TFT; voice uses a QCI 1 dedicated bearer.

Default bearer

The always-on non-GBR bearer created with each PDN connection; QCI 5 on the IMS APN.

Dialog

A long-lived SIP peer relationship identified by Call-ID, From tag and To tag.

DSCP

Differentiated Services Code Point: IP header marking for QoS; voice uses EF (46).

E-CSCF

Emergency CSCF: routes emergency sessions to the correct PSAP.

Early media

Media such as ringback tones or announcements sent before the call is answered.

ePDG

Evolved Packet Data Gateway: terminates the UE's IPsec tunnel over untrusted Wi-Fi and connects to the P-GW.

eSRVCC

Enhanced SRVCC with ATCF/ATGW anchoring for a shorter voice interruption.

EVS

Enhanced Voice Services codec: up to fullband audio, 5.9 to 128 kbit/s, robust channel-aware mode.

GBA

Generic Bootstrapping Architecture: reuses SIM AKA to create keys for HTTP services such as XCAP on Ut.

GBR

Guaranteed Bit Rate: a bearer or QoS flow with reserved capacity.

GRUU

Globally Routable User agent URI: addresses one specific device among several sharing an identity.

HSS

Home Subscriber Server: master subscriber database for identities, keys and service profiles.

I-CSCF

Interrogating CSCF: home-network entry point that finds the right S-CSCF using the HSS.

IBCF

Interconnection Border Control Function: border towards other IMS networks.

iFC

Initial Filter Criteria: rules in the user profile telling the S-CSCF which application servers to invoke.

IKEv2

Internet Key Exchange version 2: sets up the IPsec tunnel between the UE and ePDG.

IMPI

IP Multimedia Private Identity: the authentication identity, never used for routing.

IMPU

IP Multimedia Public Identity: SIP or tel URI used to reach the user.

IMS

IP Multimedia Subsystem: the 3GPP SIP-based core for voice, video and messaging over IP.

ISIM

IMS Subscriber Identity Module: SIM application holding IMS identities and the home domain.

Jitter buffer

Receiver buffer that absorbs packet delay variation so voice frames play at a steady cadence.

LBO

Local breakout IMS roaming: visited P-GW and P-CSCF, with IBCF interconnect to the home S-CSCF. Specified, not the usual live model.

LRF

Location Retrieval Function: provides location and PSAP routing for emergency calls.

MGCF

Media Gateway Control Function: converts SIP to ISUP/BICC and controls the IMS-MGW.

MMTel

Multimedia Telephony: the IMS voice and video service with its supplementary services.

MOS

Mean Opinion Score: 1-to-5 listening-quality rating, often predicted from the E-model (ITU-T G.107).

MRF

Media Resource Function: announcements, tones, conference mixing and transcoding.

MSRP

Message Session Relay Protocol: carries RCS chat and file content in sessions set up by SIP.

N3IWF

Non-3GPP Interworking Function: 5G equivalent of the ePDG.

P-CSCF

Proxy CSCF: the UE's first and only SIP contact point in IMS.

PCO

Protocol Configuration Options: NAS container that delivers the P-CSCF address and DNS during PDN setup.

PCRF / PCF

Policy and Charging Rules Function (LTE) / Policy Control Function (5G): turn session information into QoS rules.

PLC

Packet Loss Concealment: the decoder invents a plausible frame when an RTP packet is lost.

PRACK

Provisional Response Acknowledgement: makes a 1xx response such as 183 reliable.

Precondition

SDP mechanism that delays alerting until QoS resources are reserved on both sides.

PSAP

Public Safety Answering Point: the emergency call centre.

QCI / 5QI

QoS Class Identifier (LTE) / 5G QoS Identifier: a number standing for delay, loss and priority characteristics.

RCS

Rich Communication Services: GSMA rich messaging over IMS.

ROHC

Robust Header Compression: shrinks IP/UDP/RTP headers over the radio for voice efficiency.

RTP / RTCP

Real-time Transport Protocol carries media; its control protocol reports loss, jitter and delay.

S-CSCF

Serving CSCF: registrar and session controller that runs iFC.

S8HR

S8 Home Routed: the common IMS roaming model; P-GW and P-CSCF stay in the home network and the IMS APN is hauled over S8.

SBC

Session Border Controller: edge product providing security, NAT traversal and topology hiding, often hosting the P-CSCF.

SCC-AS

Service Centralization and Continuity Application Server: anchors sessions for access transfer and SRVCC.

SDP

Session Description Protocol: describes media addresses, ports, codecs and direction.

SIP

Session Initiation Protocol: text-based signaling that creates, modifies and ends sessions.

SPS

Semi-Persistent Scheduling: a periodic radio grant (usually every 20 ms) used for VoLTE instead of a fresh DCI every TTI.

SRVCC

Single Radio Voice Call Continuity: hands an active IMS call to the 2G/3G CS domain.

STN-SR

Session Transfer Number for SRVCC: routes the MSC server's transfer INVITE to the SCC-AS or ATCF.

TAS

Telephony Application Server: runs MMTel supplementary services.

TFT

Traffic Flow Template: packet filters mapping IP flows onto a bearer.

Transaction

One SIP request and all its responses, matched by the Via branch and CSeq.

Ut

Interface between the UE and the TAS/XCAP server for supplementary service settings.

Usage setting

UE policy, voice-centric or data-centric, that decides whether the UE may stay on a RAT that cannot provide voice. Not the same as the network IMS VoPS indication.

ViLTE

Video over LTE: IMS video calling with a dedicated video bearer.

VoLTE / VoNR / VoWiFi

IMS voice over LTE, over 5G NR, and over Wi-Fi.

XCAP

XML Configuration Access Protocol: HTTP-based reading and writing of XML settings documents.

Interview questions