Last Routing Option

Description

The Last Routing Option (LRO) is a functional component within the IMS service layer, specifically part of the Serving-Call Session Control Function (S-CSCF) and its associated Application Server (AS) logic. It is not a standalone network element but a configurable rule set or a designated application trigger that executes as the final step in a complex service invocation chain. When an IMS terminal initiates a session (e.g., a voice or video call), the S-CSCF processes the initial SIP INVITE request through a series of filter criteria (iFCs) defined in the subscriber's profile. These iFCs sequentially invoke various Application Servers to provide services like call forwarding, number translation, or voicemail.

The LRO comes into play after all initial filter criteria have been processed and no definitive session termination or successful routing has been achieved. This typically occurs in scenarios such as an unregistered user, an invalid destination address, or when all invoked services decline to handle the session further. At this point, the S-CSCF's service logic activates the pre-configured Last Routing Option. The LRO itself is essentially a final, unconditional iFC or a built-in S-CSCF behavior that points to a specific Application Server designed to handle these 'last resort' cases.

This final Application Server, often a Media Resource Function (MRF) or a specialized announcement server, then takes control of the session. Its primary function is to provide a controlled termination to the call attempt. This usually involves playing an appropriate announcement to the calling party (e.g., "The number you have dialed is not in service" or "The subscriber is unavailable") and then releasing the session resources. Alternatively, the LRO could be configured to route the call to a default destination like an operator or a customer care center. By providing this deterministic final step, the LRO prevents sessions from being left in an ambiguous state within the network, ensures a consistent user experience for failed calls, and aids in network resource cleanup.

Purpose & Motivation

The Last Routing Option was introduced to address a critical gap in the early IMS service execution model. IMS was designed with a high degree of flexibility, allowing multiple, chained Application Servers to manipulate a session via initial Filter Criteria. However, this chained execution model lacked a guaranteed, definitive endpoint. If the chain of service logic completed without a final decision (e.g., no AS accepted the call for final handling), the S-CSCF would be left with a session request it could not process further, potentially leading to a SIP protocol error (like a 480 Temporarily Unavailable or a 404 Not Found) being sent back without a user-friendly context.

This situation was problematic for both network operators and end-users. For operators, it led to inconsistent error handling, made troubleshooting difficult, and wasted network resources on sessions that ultimately failed without proper logging or announcement. For end-users, it resulted in generic or confusing failure tones/messages instead of informative announcements. The LRO was created to solve this by mandating a deterministic, configurable final action for every session that traverses the S-CSCF's service layer. It ensures that no session request 'falls through the cracks' of the service logic.

Furthermore, the LRO provides a crucial mechanism for service continuity and graceful degradation. It allows operators to define a fallback behavior, such as routing to a basic announcement service or a backup AS, in case primary application servers are unreachable or malfunction. This improves network robustness and customer experience. Its specification in 3GPP TS 23.167, which covers IMS emergency sessions, also highlights its role in ensuring that emergency call attempts receive a definitive final treatment, even if normal routing logic fails, thereby supporting regulatory compliance for emergency services.

Key Features

• Executes as the final step in S-CSCF service logic after all initial Filter Criteria are processed
• Provides a deterministic, configurable endpoint for unresolved session requests
• Typically triggers a final Application Server, often an MRF for announcements
• Prevents ambiguous session states and ensures resource cleanup
• Enables consistent user experience for failed call scenarios
• Supports service robustness by acting as a fallback mechanism

Evolution Across Releases

Defining Specifications