Cause i = 0x8081 - Unallocated/unassigned number

Unanswered Question
Nov 21st, 2007
User Badges:

Hello,


We are running CCM 4.2(1) and all outbound calls fail over PRI. We have a few DID's and incoming calls are successful. The gateway is a 2821 with MGCP. The Telco did put a analyzer on their switch and the returned messaged is indicating that the numbering plan is unknown.


The image on the 2821 is


c2800nm-advipservicesk9-mz.124-17.bin


The numbering plan used is CCM is NANP. I have attached debug messages for outbound calls and incoming calls as well as the running config.


Thanks, any info would be great.


Marlon





  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
mikecotrone Wed, 11/21/2007 - 04:06
User Badges:

It appears from your config that you are running T.38 since you do not have the T.38 inhibit command, but you do not have the

"mgcp package-capability fxr-package" configured. I have had similar results with 4.2(3) until I had enabled this package.


Also can you post a "sh mgcp".


Thanks!

allan.thomas Wed, 11/21/2007 - 07:42
User Badges:
  • Blue, 1500 points or more

I have noticed that the calling party on your outgoing call setup message the calling party is only four digits, is this correct? Does the telco accept this?


The disconnect cause code indicates that the number is not recognised or does not belong to the destination switch.


Regards

Allan.

marlon-chung Wed, 11/21/2007 - 08:42
User Badges:

Allan, I enabled the phone to use external phone mask with the full 10 digits and still the same message.


Also, I tried using a FXO card and analog and it works fine for outgoing and incoming calls.


So, the problem is either in the gateway or the telco.


Thanks.

Marlon

allan.thomas Wed, 11/21/2007 - 09:31
User Badges:
  • Blue, 1500 points or more

Have you specifically changed any of the Call Routing fields for outbound calls on the MGCP endpoint from the defaults, such as the called numberng plan? The default is CallManager, if it has changed are you aware of why it was changed?


Regards

Allan.

marlon-chung Wed, 11/21/2007 - 10:03
User Badges:

I just checked and the defaults are all Call Manager for the endpoints. I have rebuilt the CCM a few times from scratch and still the same issue. It works well using a FXO/analog.


Thanks

Marlon

allan.thomas Wed, 11/21/2007 - 14:52
User Badges:
  • Blue, 1500 points or more

Is it possible to temporariliy configure the voice gateway for H323? This would establish whether the problem is specifically attributed to the Telco or the MGCP application controlling the ISDN PRI at fault?


If the situation is still the same for either H323 or MGCP then this would suggest a problem with Telco.


Could you post a 'show ccm-manager' and 'show isdn status' and can you confirm that the MGCP endpoint is infact register within CallManager. I want to establish that the PRI backhaul is OPEN, and that the ISDN status is established.


Incidentally, is this a new voice-gateway or an existing gateway which has developed these issues. The reason is that you are running a recent version of IOS. Was this upgraded? When did the problems occur?


Regards

Allan


Regards

Allan.

marlon-chung Thu, 11/22/2007 - 11:35
User Badges:

Allan,


I haven't tried H323 yet, however, we have a second PRI line and i am still getting the same message. I am attaching the isdn, ccm-manager and the telco messages they are seeing on their side. We had an earlier IOS code on their and it wasnt working either, so we upgraded to the current code.


Thanks,

Marlon



allan.thomas Fri, 11/23/2007 - 04:25
User Badges:
  • Blue, 1500 points or more

The telco debug unfortunately is not very helpful. What we can establish from both the previous incoming and outgoing traces is that only incoming calls are successful, as you have already indicated.


Within the incoming trace we can see that when the called party answers a CONNECT message is sent to the Telco and the gateway subsequently receives a CONNECT_ACK from the Telco and the call is established.


However, this is not the case for outgoing calls, the trace does not indicate that the gateway received a CONNECT message when the called party answered. Can the Telco confirm that they are sending CONNECT?


Regards

Allan.

marlon-chung Fri, 11/23/2007 - 09:10
User Badges:

Allan,


I will run another trace with the Telco. Just a point to note is that outgoing calls work with a FXO card, so I am thinking that MGCP or the the 2821 is the issue here, do you agree?


Marlon

Thanks.

allan.thomas Fri, 11/23/2007 - 10:29
User Badges:
  • Blue, 1500 points or more

Essentially there is no comparision between the two, the FXO is an analogue trunk and the T1 is digital.


There doesn't appear to be any issues concerning MGCP as you are able to receive incoming voice calls.


You could try forcing the PRI to re-sync by doing a 'shut' , 'no shut' on the controller. Or issue a 'no mgcp' and then 'mgcp' to restart the application.


Regards

Allan.

vmilanov Fri, 11/23/2007 - 13:30
User Badges:

Hi,


I don't think you have problems with the MGCP protocol. The fact that you have a captured conversations between the CCM and the Telco switch means you have made a successful backhaul of the signaling channel. Also, you can utilise bearier channel, in both directions, but have a successful conversation only inward. So, in a words, I think the MGCP has been configured just fine for making and receiving calls.


That, what the Telco switch does not like is the signaling information that is carried in the signaling channel when you call outbound.


So, I have two suggestions, but I might be wrong because I'm outside US and we have different dialing rules:


1) Wasn't the 10-digit dialing a national call, and if it is, may be you are missing the '1' prefix.

2) The fact, that there are two Progress Indicator messages before the Release message makes me think that your Telco thinks your number is incomplete and awaits more digits from the CCM, and therefore it might be capable of overlap digit receiving. So try to force the overlap sending checkbox on the route pattern configuration page.


Also, for a successful National call pay attention to the combination of the route pattern and the Discard Digit instructions on the bottom of the page. A simple national route pattern might look like this:

- Route Pattern: 9.1[2-9]XXXXXXXXX, for enblock dialing, or

- Route Pattern: 9.1[2-9]!, for overlap dialing

AND

- DDI:



HTH,

Vasil

Erick Bergquist Fri, 11/23/2007 - 21:45
User Badges:
  • Silver, 250 points or more

In the latest telco debug you attached, the calling party number they receive is 12 digits long if I read the debug correctly. Does your calling party number include a 1 on front of it or something else? If in the US, it should be 10 digits.


16 01101100 Var-len Info Element, Type=1101100, Calling Party Number

17 00001100 Length=12


The telco debug shows 11 digits for the called party number which is right, since 1+areacode+prefix+4 is 11 digits.


Do they want the ISDN plan and type set for the calling party number to something other then the default?


How about if you try to set the ISDN plan/type to ISDN and National on the gateway endpoint configuration and set the CallerID on the gateway itself briefly to a valid 10 digit number for the PRI.


marlon-chung Mon, 11/26/2007 - 10:56
User Badges:

Vasil,


No, that didnt work either, I tried using the two route patterns and no go.


Marlon

marlon-chung Wed, 11/28/2007 - 13:58
User Badges:

All inbound and outbound calls are working perfectly as it turned out, it was a telco issue with translation on the telco DMS-100. So to sum this up, it was never a CCM or 2821 gateway issue.


Thanks for all that help and provided their advice.


Blue Skies Forever!!


Marlon

allan.thomas Wed, 11/28/2007 - 15:50
User Badges:
  • Blue, 1500 points or more

Thanks for the update Marlon, although it was suspected it is always difficult to prove this to the Telco.


I take it that you were unable to test using H323 in the end.


Regards

Allan.



e.hawkins Fri, 11/04/2011 - 13:59
User Badges:

I had this problem and it turned out.  That I was stripping the 1 off long distance calls on my route patterns.  The telco was expect a 1.


Hope this helps someone.

Actions

This Discussion