1.0 Problem Summary

This document outlines the analysis and a comprehensive troubleshooting plan for an issue where inbound calls to a Cisco Unified Communications Manager (CUCM) Hunt Pilot ring the members of the associated Line Group for a short duration (approximately two rings) and then disconnect abruptly. The expected behavior is for the call to be forwarded to a designated voicemail pilot if no member of the Line Group answers the call within the configured timer.

2.0 Initial Analysis and Configuration Verification

The initial investigation focused on the core Hunt Pilot and Line Group configuration. The reported setup is as follows:

• Hunt Pilot (DN 2000): Configured to route calls to a Hunt List named HL_Example.
• Hunt List (HL_Example): Contains a single Line Group, LG_Example.
• Line Group (LG_Example): Configured with a “Top Down” distribution algorithm and contains two member DNs (2001, 2002).
• Forwarding Configuration:
  • The Forward Hunt No Answer setting on the Hunt Pilot is correctly configured to send calls to the voicemail pilot (DN 8999).
  • The Use Personal Preferences checkbox for Call Forward No Coverage (CFNC) is unchecked, correctly instructing the system to use the Hunt Pilot’s forwarding settings rather than the line members’ settings.
  • The Ring No Answer Timer on the Hunt Pilot is set to 10 seconds.

Based on this initial review, the fundamental Hunt Pilot forwarding logic appears to be configured correctly. The issue is therefore not a simple misconfiguration of the primary forwarding fields but likely stems from a more nuanced interaction within the CUCM call routing and forwarding architecture. The initial steps were sound but insufficient to isolate the root cause.

3.0 Comprehensive Troubleshooting Path and Feasible Solution

To resolve this issue, we must expand our investigation beyond the Hunt Pilot page itself and analyze the end-to-end call flow. The following steps provide a robust and systematic approach to isolate and remediate the fault.

3.1 Timer Hierarchy and Interaction

While the Hunt Pilot’s Ring No Answer Timer is set to 10 seconds, it is critical to also check the Maximum Hunt Timer. This parameter, found on the same Hunt Pilot configuration page, acts as a final backstop. If this timer is set too low (e.g., 5-8 seconds), it can expire before the Ring No Answer timer, causing the call to drop if no final forwarding destination is set at that level or if the call cannot be completed for other reasons.

Action: Verify that the Maximum Hunt Timer on the Hunt Pilot (DN 2000) is set to a value greater than the Ring No Answer Timer. A typical best practice is to set it to 20 seconds or higher to provide an adequate window for the primary logic to complete.

3.2 Calling Search Space (CSS) and Partition Analysis

This is the most common point of failure for call forwarding issues in CUCM. When the Hunt Pilot attempts to forward the call to the voicemail pilot (8999), the call routing logic may not have the necessary permissions. The CSS used for the forwarding attempt is critical.

• Hunt Pilot CSS: The CSS assigned to the Hunt Pilot itself must contain the partition where the voicemail pilot (8999) resides.
• Forwarding CSS: The system’s behavior for which CSS to use upon forwarding is governed by service parameters. However, best practice is to explicitly control this. Check the device (trunk or gateway) that routes the call to the Hunt Pilot. The CSS assigned to this device is often what is used for the forwarding leg of the call.

Action:

1. Identify the partition assigned to the voicemail pilot (DN 8999).
2. Analyze the Calling Search Space assigned to the Hunt Pilot (DN 2000). Ensure this CSS includes the voicemail pilot’s partition.
3. If the call originates from a gateway or trunk, verify that the CSS assigned to that device also contains the voicemail pilot’s partition. This ensures the forward attempt is not blocked by a permissions mismatch.

3.3 Ingress Trunk and Service Parameter Validation

The call disconnect could be triggered by the originating entity (e.g., a SIP Trunk provider) if it does not receive a final answer (200 OK) within a specific timeframe. The provisional “180 Ringing” messages do not typically reset this timer.

Action:

1. If the call arrives via a SIP Trunk, review the SIP Trunk configuration for session timers. Check the Session Expires (seconds) value. If it is unusually low (e.g., 10 seconds), the carrier may be tearing down the call.
2. Validate the Stop Forwarding after N Hops service parameter under CUCM Admin > System > Service Parameters. If this is set to a low value, it could prematurely terminate a call flow involving multiple forwards. The default is typically sufficient, but it should be verified.

3.4 Definitive Analysis via Trace Collection

If the steps above do not reveal the root cause, the final and most definitive method is to analyze CUCM traces.

Action:

1. Use the Real-Time Monitoring Tool (RTMT) to identify the “Reason Code” for the call termination. This provides a quick, high-level indicator of the failure type (e.g., “Destination out of order,” “No route to destination”).
2. Enable detailed Cisco CallManager (SDL) traces on the primary CUCM node processing the call. Recreate the call failure.
3. In the collected traces, search for the Hunt Pilot DN (2000). Analyze the DigitAnalysis and CallRouting sections to observe the forwarding attempt to the voicemail pilot (8999). The traces will explicitly state the reason for failure, such as cause=1 (Unallocated Number) or cause=21 (Call Rejected), and will show which CSS was used in the routing attempt.

4.0 Recommended Action Plan

1. Verify Timers: Set the Maximum Hunt Timer on Hunt Pilot 2000 to 20 seconds.
2. Analyze CSS: Confirm the CSS of Hunt Pilot 2000 and the ingress gateway/trunk can see the partition of the voicemail pilot 8999.
3. Check Trunk Configuration: If applicable, review the SIP Trunk’s session timer settings.
4. Collect Traces: If the issue persists, capture SDL traces from the primary CUCM node, replicate the call, and analyze the call flow for the specific failure code.

By following this structured methodology, we can move beyond the initial configuration checks to perform a comprehensive analysis that will definitively identify and resolve the root cause of the premature call disconnection.