CFNR

Communication Forwarding No Reply

Services →
Introduced in Rel-2 Also in: Core Network

CFNR is a supplementary service that redirects an unanswered voice or multimedia call to a predefined alternative number to improve call completion in mobile networks.

Category
Services
Introduced
Rel-2
Where
Services › IMS
Also touches
1 segments
Specifications
20 specs
CFNR Description Purpose Related Classification Detected Changes Specifications

Description

Communication Forwarding No Reply (CFNR) is a standardized supplementary service within the 3GPP framework that operates within the IP Multimedia Subsystem (IMS) or the Circuit-Switched (CS) domain. When a call is placed to a subscriber who has activated CFNR, the network attempts to establish the call normally. If the called party's device rings but the call is not answered within a configurable timer period (typically 15-30 seconds), the network intercepts the call attempt. It then automatically re-routes the signaling and media to a different destination number, known as the forward-to number, which the subscriber has provisioned in their service profile. This forwarding decision and execution are performed by network elements like the Serving Call Session Control Function (S-CSCF) in IMS or the Mobile Switching Center (MSC) in CS, which consult the subscriber's service data stored in the Home Subscriber Server (HSS) or Home Location Register (HLR).

The service is provisioned, activated, deactivated, and interrogated by the subscriber using specific procedures, often via Unstructured Supplementary Service Data (USSD) codes or through a service management interface. The network maintains the subscriber's CFNR status (active/inactive) and the associated forward-to number as part of their subscriber data. A key operational aspect is the interaction with other call forwarding services, such as Communication Forwarding Busy (CFB) and Communication Forwarding Unconditional (CFU). These services are typically evaluated in a specific order of precedence defined by the network operator (e.g., CFU first, then CFB, then CFNR) to determine the final forwarding action for an incoming call.

From a signaling perspective, when CFNR is triggered, the network generates new call setup signaling (e.g., a SIP INVITE in IMS or an ISUP IAM in CS) towards the forward-to number. To the original calling party, this process is generally transparent; they simply experience the call being connected to the forwarded destination after the no-answer timeout. The service is integral to providing users with control over their communication availability, ensuring important calls are not missed even when they are temporarily unavailable to answer their primary device. Its implementation must handle various scenarios, including forwarding to international numbers (subject to operator policy), interactions with call barring services, and maintaining correct charging records for both the forwarded leg and the original call attempt.

Purpose & Motivation

CFNR was created to solve the fundamental problem of missed calls and inefficient communication in telephony networks. Before such features, if a called party did not answer, the call simply failed, potentially requiring repeated attempts and causing delays. This was particularly problematic in mobile environments where users might be away from their phone, in a meeting, or otherwise unable to answer immediately. CFNR provides a mechanism to ensure call completion by redirecting the communication attempt to an alternative point of contact, such as a voicemail system, a secretary, or another personal device.

The service addresses limitations in basic call setup by adding intelligence and user-configurable logic to the network. It empowers subscribers by giving them direct control over how their inbound communications are handled during periods of non-availability, moving beyond a simple binary answered/not-answered model. Historically, such forwarding services were first defined in fixed-line networks and were crucial for business communications. Their standardization in 3GPP from the earliest releases ensured seamless service continuity and a consistent user experience as telephony evolved from circuit-switched GSM to packet-switched IMS-based Voice over LTE (VoLTE) and 5G Voice.

Furthermore, CFNR supports operational efficiency for network operators. By standardizing the behavior, it enables interoperability between different vendors' network equipment and across different operator networks. It also creates a foundation for more advanced, revenue-generating services, such as centralized voicemail or intelligent call routing solutions. The service solves the user experience problem of missed connections while providing a building block for complex call handling workflows.

Classification

Part ofIMS
Specific typesORLCF
Related approachesCFBCFU

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-19 1 change

In Release 19, the interaction of Diversion Counter (DC) with the Communication Forwarding No Reply (CFNR) function was updated to support the requirement. This ensures the service operates correctly within the defined limits for the maximum number of permitted diversions for a communication.

  • Update the interaction of DC with CFNR and support the requirement TS 24.186CR0074

Explore further

Broader topics and technologies where CFNR plays a role.

Defining Specifications

3GPP specifications that define or reference CFNR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 22.173 vk00 IMS Multimedia Telephony Service Definition Rel-20
TS 22.273 v1700 IMS Multimedia Telephony with PSTN/ISDN Simulation Rel-7
TR 22.976 v1200 Release 2000 Services Overview Rel-2
TS 24.173 vj00 Multimedia Telephony Service and Supplementary Services in IMS Rel-19
TS 24.186 vj60 IMS Data Channel applications Rel-19
TS 24.292 vj00 IMS Centralized Services (ICS) Protocol Rel-19
TS 24.404 v1700 Communication Diversion Services (CDIV) Rel-7
TS 24.406 v810 Message Waiting Indication (MWI) Protocol Rel-8
TS 24.416 v1700 Malicious Call Identification Service Rel-7
TS 24.504 v8m0 Communication Diversion Services Stage 3 Rel-8
TS 24.516 v830 MCID Protocol Specification for NGN Rel-8
TS 24.604 vj00 Communications Diversion (CDIV) Protocol Spec Rel-19
TS 24.606 vj00 MWI Service Protocol Description Rel-19
TS 24.615 vj00 Communication Waiting (CW) Service Protocol Rel-19
TS 24.616 vj00 Malicious Call Identification (MCID) Protocol Rel-19
TS 29.163 vj00 Interworking between 3GPP IM CN and CS networks Rel-19
TS 29.292 vj00 IMS Centralized Services (ICS) Interworking Rel-19
TS 29.364 vj10 IMS AS Service Data Descriptions Rel-19
TS 29.864 v801 Application Server Service Data Definition for IMS Telephony Rel-8
TS 32.275 vj00 MMTel Charging Specification Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.