Re: Call FWD and SNR not working - CallManager (MGCP gateway)

Phillip Harding · ‎06-12-2012

All,

I have a strange issue that just started as of last Thursday with one of my remote sites. No one at this remote site is able to CFWDAll to an external number or use SNR. All inbound and outbound calls otherwise are functioning without issues. One unique difference is we are using an IP converged voice/data circuit at this remote location as oppose to a traditional PRI although the converged IP voice/data circuit is considered a PRI by our teleco. This was necessary due to the remote site being out of market for our teleco. All other sites are configured in the same manner using an MGCP gateway. We have CallManager supporting all sites. I have been back and forth with Cisco TAC and our teleco regarding this issue and here are the only options I was given.

Reconfigure the MGCP gateway to an H.323 gateway. This does not seem like a logic answer to the issue since all other sites are using MGCP gateways and function without issues. Also CFWDALL and SNR were functioning at this site prior to last Thursday. I've asked the teleco what has changed that might be causing their switch to reject forwarded calls. We are sending the ISDN redirect message however the teleco has advised we are only sending five digits which would be the internal extension of the phone FWD'ing the call. I've pulled debug logs from another MGCP gateway at another site and the debug logs are the same sending the same ISDN redirect message.
Upgrade to UCM 8.6 which will allow changes at the MGCP gateway level in order to pass the required ten digits to the teleco. This to is a major change which would affect all sites and require unplanned downtime when the issue is only affecting one site. I've been told there is no way to manipulate the number of digits being sent via an MGCP gateway. All sites are using an international CSS search space by site. Route groups and and lists have been reviewed by Cisco TAC for inconsistencies by site no descrepencies were found.
Change our internal five digit extensions to ten digit extensions. This would require us to change our entire dial plan and affect call routing accross all offices. I rejected this opinion as it is not feasible.

Has anyone else with an MGCP gateway environment with CallManager (not express) experienced this issue? Any assistance is appreciated! Thanks!

Debug log: (MGCP Cisco 2951 router) CFWDALL and SNR fails to teleco with "You've reached a non working number". Call is rejected by our teleco:

Jun 12 2012 08:36:57.208 EDT: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x2890

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA18386

Preferred, Channel 6

Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100

Protocol Profile = Networking Extensions

0xA10F02010106072A8648CE1500040A0100

Component = Invoke component

Invoke Id = 1

Operation = InformationFollowing (calling_name)

Name information in subsequent FACILITY message

Calling Party Number i = 0x0080, '3174167588'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '7063596'

Plan:Unknown, Type:Unknown

Jun 12 2012 08:36:57.240 EDT: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0xA890

Channel ID i = 0xA98386

Exclusive, Channel 6

Jun 12 2012 08:36:57.248 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x035B

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98387

Exclusive, Channel 7

Calling Party Number i = 0x0083, '3174167588'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '13178949281'

Plan:Unknown, Type:Unknown

Redirecting Number i = 0x00008F, '73596'

Plan:Unknown, Type:Unknown

Jun 12 2012 08:36:57.260 EDT: ISDN Se0/0/0:23 Q931: RX <- FACILITY pd = 8 callref = 0x2890

Facility i = 0x9F8B0100A117020101020100800F574952454C4553532043414C4C4552

Protocol Profile = Networking Extensions

0xA117020101020100800F574952454C4553532043414C4C4552

Component = Invoke component

Invoke Id = 1

Operation = CallingName

Name Presentation Allowed Extended

Name = WIRELESS CALLER

Jun 12 2012 08:36:57.280 EDT: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x835B

Channel ID i = 0xA98387

Exclusive, Channel 7

Jun 12 2012 08:36:57.336 EDT: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x835B

Cause i = 0x8281 - Unallocated/unassigned number

Jun 12 2012 08:36:57.356 EDT: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0xA890

Cause i = 0x8281 - Unallocated/unassigned number

Jun 12 2012 08:36:57.376 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x2890

Jun 12 2012 08:36:57.388 EDT: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x035B

Jun 12 2012 08:36:57.396 EDT: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x835B

Jun 12 2012 08:36:57.416 EDT: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xA890

Jun 12 2012 08:37:05.272 EDT: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x2891

THIS LOG IS FROM A WORKING MGCP GATEWAY IN OUR ENVIRONMENT USING THE SAME CALLMANAGER:

Jun 8 01:35:18.864 EDT: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x03EB

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100

Protocol Profile = Networking Extensions

0xA10F02010106072A8648CE1500040A0100

Component = Invoke component

Invoke Id = 1

Operation = InformationFollowing (calling_name)

Name information in subsequent FACILITY message

Progress Ind i = 0x8283 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '3174167588'

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '3578794'

Plan:ISDN, Type:Subscriber(local)

Jun 8 01:35:18.892 EDT: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x83EB

Channel ID i = 0xA98381

Exclusive, Channel 1

Jun 8 01:35:18.896 EDT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0003

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98397

Exclusive, Channel 23

Progress Ind i = 0x8283 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '3174167588'

Plan:ISDN, Type:National

Called Party Number i = 0x80, '13178949281'

Plan:Unknown, Type:Unknown

Redirecting Number i = 0x00008F, '58794'

Plan:Unknown, Type:Unknown

Jun 8 01:35:18.932 EDT: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8003

Channel ID i = 0xA98397

Exclusive, Channel 23

Jun 8 01:35:19.272 EDT: ISDN Se0/0/0:23 Q931: RX <- FACILITY pd = 8 callref = 0x03EB

Facility i = 0x9F8B0100A117020101020100800F574952454C4553532043414C4C4552

Protocol Profile = Networking Extensions

0xA117020101020100800F574952454C4553532043414C4C4552

Component = Invoke component

Invoke Id = 1

Operation = CallingName

Name Presentation Allowed Extended

Name = WIRELESS CALLER

Jun 8 01:35:19.852 EDT: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x8003

Progress Ind i = 0x8488 - In-band info or appropriate now available

Jun 8 01:35:19.852 EDT: ISDN Se0/0/0:23 Q931: TX -> PROGRESS pd = 8 callref = 0x83EB

Progress Ind i = 0x8488 - In-band info or appropriate now available

Jun 8 01:35:20.536 EDT: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8003

Progress Ind i = 0x8482 - Destination address is non-ISDN

Jun 8 01:35:20.548 EDT: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x83EB

Progress Ind i = 0x8482 - Destination address is non-ISDN

Jun 8 01:35:20.548 EDT: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0003

Jun 8 01:35:20.576 EDT: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x03EB

Aaron Harrison · ‎06-12-2012

Hi

It's pretty normal to send out 5 digits in calling/redirected fields - as you have demonstrated on your other/working MGCP gateway you are sending the same info.

If the telco are saying this circuit should behave like a normal one, this is clear evidence that it isn't behaving as they say and you should push them further.

Otherwise you would need some method for modifying the numbers... as you say, this involves change/effort and is seems to me that your SP is letting you down. Maybe change them out... or just tell them you are considering it.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Phillip Harding · ‎06-18-2012

Hi Aaron,

I agree and I have pushed the issue back to my telecom as Cisco TAC has advised I have the following options only which again are not feasible:

§ Change the DN to 10 digit.

§ Convert the gateway to h323

§ Upgrade to CM 8.6.2.

Thanks Phillip

Taft /

Phillip S. Harding, MBA / Manager, Voice/Data Communications

Taft Stettinius & Hollister LLP

One Indiana Square, Suite 3500

Indianapolis, Indiana 46204-2023

Tel: 317.713.3500 • Fax: 317.713.3699

Direct: 317.713.3401

www.taftlaw.com<> / PHARDING@taftlaw.com / LinkedIn<>

TaftSignature

Internal Revenue Service Circular 230 Disclosure: As provided for in Treasury regulations, advice (if any) relating to federal taxes that is contained in this communication (including attachments) is not intended or written to be used, and cannot be used, for the purpose of (1) avoiding penalties under the Internal Revenue Code or (2) promoting, marketing or recommending to another party any transaction or matter addressed herein.

This message may contain information that is attorney-client privileged, attorney work product or otherwise confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments.

TaftDisclaimer### ### ###

Gordon Ross · ‎06-12-2012

Couple of random thoughts:

- TAC's suggestion to move from MGCP to H323 may be related to you saying that it's a mixed Voice/Data circuit. MGCP can only work when it has full control of the PRI. It can't share it, or only use a certain amount of channels. H323 can be set to use only a specific number of channels. I'm not sure from your description if this is necessary, but it could explain TAC's suggestion.

- Device Outdials, CallForwards & SNR calls all use separate CSSs. You need to check each individual CSS configuration to make sure they are correct. It could be that a CSS has inadvettedly changed somewhere.

GTG

Please rate all helpful posts.