Showing results for 
Search instead for 
Did you mean: 

Cause i = 0x8081 - Unallocated/unassigned number

Level 1
Level 1


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


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.


18 Replies 18

Level 1
Level 1

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".


Hello Mike,

See the attachment.

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.



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.



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?



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.



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?






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.



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?




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?



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.



Level 1
Level 1


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


- DDI:



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.


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