05-11-2011 02:09 AM - edited 03-16-2019 04:54 AM
hi,
we have an CUCM 7.1.3 with configured mobile connect. If someone calls the company number the mobile phone rings also. So it works fine.
Now the employee with the mobile phone calls someone in the company at the work phone. But the work phone is already in a call. So we expect, that the mobile user gets a busy tone, but he's got a ringtone instead. The Busy Trigger at all lines in the company is set to 1. It works, because if someone in the company calls someone other in the company from work phone to work phone and the called party is busy, the caller gets the busy tone.
how can I set, that the mobile caller gets also an busy tone?
05-16-2011 11:42 PM
Hi,
May I ask if the actual internal IP Phone rings on its display screen when called tru mobile connect? How about when normal caller came from your PSTN trunk line?
05-16-2011 11:50 PM
Hi,
You mentioned that all phones are configured in "busy trigger" to 1. How about the DN lines associated in their remote destination profiles? Could you check it and test?
please let us know how it goes.
- Paul
05-20-2011 02:21 AM
Sorry for late answer:
> May I ask if the actual internal IP Phone rings on its display screen when called tru mobile connect? How about when normal caller came from your PSTN trunk line?
will try answer. If I call with my mobile phone , which is my Remote Destination, to a company work phone and there is busy, I dont get a busy, I get a ring tone. If some other calls from PSTN he gets a busy tone as expected.
> You mentioned that all phones are configured in "busy trigger" to 1. How about the DN lines associated in their remote destination profiles? Could you check it and test?
Already all DN are set "busy trigger" to 1.
11-30-2011 12:48 PM
Hi
Have you been able to solve the issue?
We are facing the same issue with CUCM 8.0.3 and 8.6.2 when the 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 ring 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").
Many thanks for your reply
Regards
Stefan
01-04-2012 09:55 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 the 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.
HTH
Stefan
01-12-2012 07:05 AM
Hi Stefan, we are facing "nearly" the same issue. A mobile connect user get silent whe they call a busy IP Phone and after 29 seconds first a disconnect. A non mobile connect user get immediately a busy tone. The difference is, when a mobile connect user call a busy phone, CUCM send a progress with user busy, and with a non mobile connect user the CUCM send a immediately a disconnect. Please see below.
In our case your description not solve the issue. Have you any Idea?
Best Regards Armin
mobile connect user---------------------------------------------
000822: Jan 12 15:36:14.285: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x54D7
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18396
Preferred, Channel 22
Calling Party Number i = 0x2183, 'XXXXXXXXXXXXXX'
Plan:ISDN, Type:National
Called Party Number i = 0xC1, 'XXXXXX'
Plan:ISDN, Type:Subscriber(local)
High Layer Compat i = 0x9181
000823: Jan 12 15:36:14.289: ISDN Se0/0/0:15 Q931: Received SETUP callref = 0xD4D7 callID = 0x0029 switch = primary-net5 interface = User
tkvgw#
000824: Jan 12 15:36:14.313: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xD4D7
Channel ID i = 0xA98396
Exclusive, Channel 22
000825: Jan 12 15:36:14.337: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8 callref = 0xD4D7
Cause i = 0x8191 - User busy
Progress Ind i = 0x8188 - In-band info or appropriate now available
tkvgw#
000826: Jan 12 15:36:43.458: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x54D7
Cause i = 0x80E6 - Recovery on timer expiry
000827: Jan 12 15:36:43.466: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0xD4D7
000828: Jan 12 15:36:43.482: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x54D7
000829: Jan 12 15:36:43.686: %ISDN-6-DISCONNECT: Interface Serial0/0/0:18 disconnected from 3641456911 , call lasted 127 seconds
tkvgw#
000830: Jan 12 15:36:43.686: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xD4D3
Cause i = 0x8090 - Normal call clearing
000831: Jan 12 15:36:43.734: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x54D3
000832: Jan 12 15:36:43.738: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xD4D3
non mobile connect user -----------------------------------------------------------
Jan 12 15:40:49.489: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x54DA
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18398
Preferred, Channel 24
Calling Party Number i = 0x2183, 'XXXXXXXXXXXXX'
Plan:ISDN, Type:National
Called Party Number i = 0xC1, 'XXXXXX'
Plan:ISDN, Type:Subscriber(local)
High Layer Compat i = 0x9181
000864: Jan 12 15:40:49.489: ISDN Se0/0/0:15 Q931: Received SETUP callref = 0xD4DA callID = 0x002C switch = primary-net5 interface = User
tkvgw#
000865: Jan 12 15:40:49.513: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xD4DA
Channel ID i = 0xA98398
Exclusive, Channel 24
000866: Jan 12 15:40:49.537: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xD4DA
Cause i = 0x8091 - User busy
000867: Jan 12 15:40:49.553: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x54DA
000868: Jan 12 15:40:49.557: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xD4DA
tkvgw#
01-12-2012 09:35 AM
Hi Armin
I guess there is still an "Annunciator" available for the gateway. Can you please verify your config again?
That you have a slightly different issue is probably dependent on your gateway config. Our gateway config converts the progress message from CUCM to an ISDN Alerting with In-Band Info.
Please check the other discussion I have started for this problem:
https://supportforums.cisco.com/message/3503284#3503284
If there is really no Annunciator configured for the gateway in CUCM, you should trace the problem on CUCM. Maybe you'll find some Mobility messages like "CellProxy( 298): ccDisconnReq.cv = 17 set MobilityEvent = MOBILITY_EVENT_PLAY_ANNOUNCEMENT - active_CcDisconnReq" in the traces that could help you to find the cause.
That the call is disconnected after 30 seconds is caused by a T3XX timer expiry because the call did not get a Connect.
HTH
Stefan
01-13-2012 01:07 AM
01-13-2012 03:26 AM
Hi Armin
Sorry, but I don't see any screenshots above.
You need to configure an explicit MRGL/MRG without an Annunciator in it. If you just unconfigure the MRGL in the gateway config then the gateway is using the default MRGL/MRG which most likely contains an Annunciator.
HTH
Stefan
08-30-2016 04:39 AM
Hi guys,
we are experiencing a similar problem with a newer release of CUCM.
One question to this workarround.
What is the consequence of removing the Annunciator? Is this a solution for a productive environment?
Best Regards
Mohamed
08-30-2016 05:24 AM
Hi Mohamed
We have seen that the issue with SNR no longer exists with SIP gateways and newer CUCM versions.
We have seen issues with no-ringback when the external calls are routed to Unity Connetion and then transfered to an internal subscriber. Otherwise there shouldn't be any bigger issues when you remove the annunciator from the gateway.
HTH
Stefan
08-30-2016 05:30 AM
Hi Stefan,
thank you very much for your fast reply.
The strange thing is that we experience it with a 10.5.2.12901-1 release on h323 gateways.
We will try to remove the annunciator from the MRGL and MRG - maybe it helps.
Regars
Mohamed
08-31-2016 02:11 AM
It helped - strange that it seems not to be fixed in our CUCM 10.5 Version.
08-31-2016 03:12 AM
Maybe it's SIP to the gateway that fixes the issue
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