12-01-2011 01:09 AM - edited 03-16-2019 08:19 AM
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
Solved! Go to Solution.
01-04-2012 10:03 AM
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
12-01-2011 05:22 AM
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
More
Less
Status:
Fixed
Last Modified:
Nov 17,2011
More
Less
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
Cheers!
Rob
12-01-2011 05:47 AM
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
12-01-2011 06:50 AM
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)
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
01-04-2012 10:03 AM
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
05-24-2013 02:01 AM
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
05-27-2013 05:01 AM
Hi Bernhard
No, MRGL/MRG without Annunciator for the GW in CUCM should fix the issue.
Try restarting the CallManager Service.
Regards
Stefan
06-04-2013 07:44 AM
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
06-04-2013 11:06 PM
Hi Bernhard
It's the same for H.323 gateways (see my original posting).
Regards
Stefan
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide