CM 10.2.1.x calls covering to the coverage path doesn't follow the number of rings configured (for no answer scenario) on the coverage path.

Doc ID    SOLN387013
Version:    1.0
Status:    Published
Published date:    15 Sep 2026
Author:   
anand113
 

Details

When a call covers to the coverage points it doesn't follow the number of rings configured (for no answer scenario) on the coverage path.
Number of rings works fine if Direct IP-IP media is disabled on the stations. External calls are fine.

Issue started after CM was patched with Custom Patch 28395

Operating system: Linux 4.18.0-553.74.1.el8_10.x86_64 x86_64 x86_64
Built: Sep 7 09:23 2025
Contains: 02.0.229.0
CM Reports as: R020x.02.0.229.0
CM Release String: vcm-020-02.0.229.0
RTS Version: CM 10.2.1.2.1.229.28395
Publication Date: 18 October 2023
VMwaretools version: 12.2.5.43614 (build-21855600)
App Deployment: Virtual Machine
VM Environment: VMware

UPDATES:
Update ID Status Type Update description
--------------------------------- ------------ ----- ---------------------------
02.0.229.0-28352 unpacked cold 10.2.1 28268 C58131 C58960
02.0.229.0-28376 unpacked cold 10.2.1.2.1-FP1SP2P1
02.0.229.0-28395 activated cold 10.2.1.2.1 28376 + CM59248
 

Problem Clarification

When a call covers to the coverage points it doesn't follow the number of rings configured (for no answer scenario) on the coverage path.
Number of rings works fine if Direct IP-IP media is disabled on the stations. External calls are fine. Users hear more rings than what is configured in coverage path.

TEST 1 - Here the issue is when we see the IP to IP audio is DISABLED on Called number - 12232028923 and Enabled on calling number 17175314674” it was following the correct number of rings pattern which assigned to it, In this case the expected RINGs are 8 but we are getting 8 rings and hitting VM as expected. This call is actually initiated from 12232028910. 
  • Working scenario #1 1223-202-8923 with (Direct IP to IP - No) calls 1717-531-4674 (CP 7629, Direct IP to IP - Yes). 4 rings  RP #1, then 4 rings RP #2 then to voicemail.

TEST 2 - Here the issue is when we see the IP to IP audio is ENABLED on both the number From and to “12232028923 to 17175314674” it was not following the number of rings pattern which assigned to it, In this case the expected RINGs are 8 but we are getting more then 8+.
  • Nonworking scenario #2 1223-287-7101 with (Direct IP to IP - Yes) calls 1717-531-4674 (CP 7629, Direct IP to IP - Yes). 5 rings to RP #1, then 5.5 rings to RP #2 then to voicemail.

TEST 3 - Here the issue is when we see the IP to IP audio is ENABLED on Called number - 12232028923 and DISABLED on calling number 17175314674” it was not following the number of rings pattern which assigned to it, In this case the expected RINGs are 8 but we are getting more then 8+.
  • Nonworking scenario #3 1223-287-7101with (Direct IP to IP - Yes) calls 1717-531-4674 (CP 7629, Direct IP to IP - No). 5 rings to RP #1, then 5.5 rings to RP #2 then to voicemail.

 

Cause

The OPTIM SIP trunk had both Direct IP-IP and Initial IP-IP set to Y along with Direct IP-IP enabled on Station form.
This was causing issue with DSP resource allocation resulting in number of rings being heard more against the number of rings configured in Coverage Path page.

Solution

Once Initial IP-IP was disabled on OPTIM trunk signalling group the issue was fixed and number of rings were heard as configured.
This caused the DSP resource to get engaged and the ring was then controlled by CM.

 

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy