ringback instead of busy when calling busy subscriber from remote destination

Endorsed Question
Dec 1st, 2011

Hi

We are facing a problem with CUCM 8.0(3) and 8.6(2a) when a remote destination calls in from an H.323 gateway to a busy IP phone. The mobile phone with the remote destination number just gets a ringback tone (Q.931 Alerting) as if the IP phone would not be busy. If the same mobile phone is not configured as a remote destination and calls in to the busy IP phone, it will get a busy tone (Q931 Disconnect with reason "user busy").

I have a found the following similar bug in the bug tool:
CSCts24630 - CUCM does not forward busy tone when RD in PSTN returns busy across MGCP DescriptionSymptom:

CAllManager does not provide busy tone to caller when remote destination in PSTN is busy. Remote destination sends disconnect message to CUCM with cause code 'user busy', however, CUCM does not forward this signal to caller and caller continues hearing ringback.

Conditions:
When MGCP gateway is involved, and remote destination in PSTN is busy.

Fixed-in: (8)
8.6(2.99000.92), 8.6(2.98000.56), 8.6(2.98000.24)
8.6(2.11001.1), 8.6(1.21013.1), 8.5(1.13900.4)
8.5(1.13038.1), 8.0(3.23040.1)


Has anyone faced CSCts24630 and upgraded to a fixed version? If so could you please check if you get a busy tone when calling from a remote destination?
By the way, does anyone if CSCts24630 should be fixed in 8.6.2.20000-2?

Any feedback is appreciated and many thanks in advance

Regards
Stefan

I have this problem too.
0 votes
Endorsed by Paolo Bevilacqua
STEFAN CHRISTEN about 2 years 3 months ago

Hi

I have opened a TAC service request for the problem and we have found a solution for the problem.

The problem is caused by CUCM because it tries to provide the busy tone with the Annunciator which results in an ISDN Alerting message with Inband Info instead of a Disconnect message with cause "user busy".

If you configure a Media Resource Group List/Media Resource Group that does not contain an Annunciator and assign it to the Gateway config in CUCM, the Disconnect message with "user busy" will be sent out immediately and you should hear the busy tone on your mobile.

Extract of the mail from TAC:

"I have checked the logs, and I could see the call coming in from the PSTN and the calling number is recognized as a Remote Destination.

Once the CallManager finds the destination device is busy it will tell the CellProxy about that and then try to invoke annunciator to play the busy tone :
11:35:06.496 |CellProxy(    298): ccDisconnReq.cv = 17 set MobilityEvent = MOBILITY_EVENT_PLAY_ANNOUNCEMENT - active_CcDisconnReq |1,100,13,13587.4^10.1.10.8^*

The Annunciator is allocated to play busy tone for Remote Destination parties and when CUCM detects that the calling party is part of Remote Destination Profile, it does consider as an "internal" calling party and play the busy tone through the Annunciator. If you try to call the same busy phone from the internal IP Phone extension, the Annunciator will here play the busy tone directly to the IP Phone.
This is why we see different behavior as compared to other calls from PSTN.

Can you please configure the MRGL associated with the H.323 Gateway so that it does not contain any Annunciator resource and see if it fixes the issue?
By doing this, we will play directly Busy Tone through the H.323 gateway and the Disconnect (User Busy) message."

Regards

Stefan

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.3 (3 ratings)
Rob Huffman Thu, 12/01/2011 - 05:22

Hi Stefan,

Here are the "fixed-in" versions from the Beta Bug Search Tool

CSCts24630 - CUCM does not forward busy tone when RD in PSTN returns busy across MGCP

Details

1st Found-in:                          (1)

8.0

More

Less

Status:

Fixed

Last Modified:

Nov 17,2011

Known Affected Versions:

More

Less

Fixed-in:                          (8)

8.6(2.99000.92), 8.6(2.98000.56), 8.6(2.98000.24)

8.6(2.11001.1), 8.6(1.21013.1), 8.5(1.13900.4)

8.5(1.13038.1), 8.0(3.23040.1)

More

Product:

Cisco Unified Communications Manager (CallManager)

Platform:

Dependent

Severity:

3 - moderate

Customer Reported:                          (1)

Cheers!

Rob

STEFAN CHRISTEN Thu, 12/01/2011 - 05:47

Hi Rob

Thanks for the reply but I have already pasted the bug tool output including fixed version in my question above ;-)

I'm not sure if fixed in 8.6(2.11001.1) (which seems to be an ES/SR of 8.6(2)) means that it is fixed in 8.6.2.20000-2 (which is the latest official 8.6(2a) release).

I have once seen in a PVT a presentation that explains how and when the ES/SR fixes will be included in the official releases, but unfortunately I can't find it anymore :-(

Regards

Stefan

Rob Huffman Thu, 12/01/2011 - 06:50

Hi Stefan

WOW! Sorry man, I missed the "fixed-in" notes you linked completely my friend

My BAD!

CSCts24630 - is not identified as open in the caveats for 8.6(2a) and according to this note

the fix should be rolled into 8.6.2.20000-2

Understanding the Fixed-in Version Field in the Online Defect Record

When you open the online record for a defect, you will see data in the "First Fixed-in Version" field. The information that displays in this field identifies the list of Unified CM interim versions in which the defect was fixed. These interim versions then get integrated into Unified CM releases.

Some more clearly defined versions include identification for Engineering Specials (ES) or Service Releases (SR); for example 03.3(04)ES29 and 04.0(02a)SR1. However, the version information that displays for the Unified CM maintenance releases may not be as clearly identified.

The following examples show how you can decode the maintenance release interim version information. These examples show you the format of the interim version along with the corresponding Unified CM release that includes that interim version. You can use these examples as guidance to better understand the presentation of information in these fields.

8.0(2.40000-x) = Cisco Unified Communications Manager 8.0(2c)

7.1(5.10000-x) = Cisco Unified Communications Manager 7.1(5)

7.1(3.30000-x) = Cisco Unified Communications Manager 7.1(3b)

7.1(3.20000-x) = Cisco Unified Communications Manager 7.1(3a)

7.1(3.10000-x) = Cisco Unified Communications Manager 7.1(3)

7.1(2.30000-x) = Cisco Unified Communications Manager 7.1(2b)

7.1(2.20000-x) = Cisco Unified Communications Manager 7.1(2a)

7.1(2.10000-x) = Cisco Unified Communications Manager 7.1(2)

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/8_6_2/cucm-rel_notes-862a.html#wp1945571

But I've been bitten by bugs before when I thought that the version contained the bug fix so your

best bet to be sure is to open a TAC case.

Again my apologies!

Cheers!

Rob

STEFAN CHRISTEN Wed, 01/04/2012 - 10:03

Hi

I have opened a TAC service request for the problem and we have found a solution for the problem.

The problem is caused by CUCM because it tries to provide the busy tone with the Annunciator which results in an ISDN Alerting message with Inband Info instead of a Disconnect message with cause "user busy".

If you configure a Media Resource Group List/Media Resource Group that does not contain an Annunciator and assign it to the Gateway config in CUCM, the Disconnect message with "user busy" will be sent out immediately and you should hear the busy tone on your mobile.

Extract of the mail from TAC:

"I have checked the logs, and I could see the call coming in from the PSTN and the calling number is recognized as a Remote Destination.

Once the CallManager finds the destination device is busy it will tell the CellProxy about that and then try to invoke annunciator to play the busy tone :
11:35:06.496 |CellProxy(    298): ccDisconnReq.cv = 17 set MobilityEvent = MOBILITY_EVENT_PLAY_ANNOUNCEMENT - active_CcDisconnReq |1,100,13,13587.4^10.1.10.8^*

The Annunciator is allocated to play busy tone for Remote Destination parties and when CUCM detects that the calling party is part of Remote Destination Profile, it does consider as an "internal" calling party and play the busy tone through the Annunciator. If you try to call the same busy phone from the internal IP Phone extension, the Annunciator will here play the busy tone directly to the IP Phone.
This is why we see different behavior as compared to other calls from PSTN.

Can you please configure the MRGL associated with the H.323 Gateway so that it does not contain any Annunciator resource and see if it fixes the issue?
By doing this, we will play directly Busy Tone through the H.323 gateway and the Disconnect (User Busy) message."

Regards

Stefan

Bernardo34 Fri, 05/24/2013 - 02:01

Hi Stefan,

We are facing the same issue. I configured an MRGL without any Annunciator Recources in it and applied it to the gateway in question. Then resetted the gateway but the problem still persists. Anything else you need to configure?

regards,

Bernhard

STEFAN CHRISTEN Mon, 05/27/2013 - 05:01

Hi Bernhard

No, MRGL/MRG without Annunciator for the GW in CUCM should fix the issue.

Try restarting the CallManager Service.

Regards

Stefan

Bernardo34 Tue, 06/04/2013 - 07:44

Hi Stefan,

This doesn't helped either. In the meantime i've setup a lab with a CUCM 9.1.1.20000-5.

BTW i've configured the gateway with H.323 not MGCP.

Maybe this only workes with mgcp configured gateways?

regards,

Bernhard

STEFAN CHRISTEN Tue, 06/04/2013 - 23:06

Hi Bernhard

It's the same for H.323 gateways (see my original posting).

Regards

Stefan

Actions

Login or Register to take actions

This Discussion

Posted December 1, 2011 at 1:09 AM
Stats:
Replies:8 Avg. Rating:4.33333
Views:1657 Votes:0
Shares:0

Related Content

Discussions Leaderboard

Rank Username Points
1 21,026
2 15,047
3 10,314
4 7,999
5 4,856
Rank Username Points
135
90
72
66
55