Cannot place calls outbound on PRI, inbound calls work fine

[olighec]

Hello all,

I have a remote gateway with a single PRI that can receive calls just fine, but has never been able to place one successfully.

The error I get is 0x80B2 - Requested facility not subscribed

I have had a service call with the telco and after placing a couple of test calls, was told it's a misconfiguration of my equipment.  Before I go back to them again, I figured I'd ask here:

Details:

CUCM 7.1

Gateway is a 2821 router running 12.4(11)T2 running MGCP

T1 is on a VWIC2-1MFT-T1, circuit is ISDN PRI

Here's the ISDN Q931 debug output from a successful inbound call:

_________________________

May 12 22:59:12.883: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0D61

        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

        Calling Party Number i = 0x2183, '5095701234'
                Plan:ISDN, Type:National
        Called Party Number i = 0xA1, '9163676972'
                Plan:ISDN, Type:National
May 12 22:59:12.975: ISDN Se0/1/0:23 Q931: RX <- FACILITY pd = 8  callref = 0x0D
61
        Facility i = 0x9F8B0100A117020101020100800F574952454C4553532043414C4C455
2
                Protocol Profile =  Networking Extensions
                0xA117020101020100800F574952454C4553532043414C4C4552
                Component = Invoke component
                        Invoke Id = 1
                        Operation = CallingName
                                Name presentation allowed
                                Name = WIRELESS CALLER
May 12 22:59:13.023: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x8
D61
        Channel ID i = 0xA98381
                Exclusive, Channel 1
May 12 22:59:13.023: ISDN Se0/1/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x8D
61
        Progress Ind i = 0x8088 - In-band info or appropriate now available
May 12 22:59:13.039: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x8D6
1
May 12 22:59:13.059: ISDN Se0/1/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0
x0D61
May 12 22:59:18.819: ISDN Se0/1/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x
0D61
        Cause i = 0x8090 - Normal call clearing

________________________

Now here's the output from an outbound call attempt:

May 12 23:01:13.390: ISDN Se0/1/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
        Net Specific Fac i = 0x00F3
        Calling Party Number i = 0x2181, '9162186531'
                Plan:ISDN, Type:National
        Called Party Number i = 0xA1, '9167870201'
                Plan:ISDN, Type:National
May 12 23:01:13.454: ISDN Se0/1/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref =
0x8003
        Cause i = 0x80B2 - Requested facility not subscribed

_____________________________

When the circuit was set up, I was only told three things.  Use NI2 for the protocol, incoming calls get top down channels\outgoing gets bottom up, and send the billing DN as outbound caller ID.  That's all it took to get the other circuits up, but this one continues to block outgoing calls.  Is there still a possibility that my gateway is misconfigured?  I have my numbering plans exactly the same as we are receiving, am sending the billing DN as outbound CID, and everything else is the same as the other PRI circuits that I have which are working fine.

Just wanted to make sure there wasn't something else I had wrong before going back to the telco with another service request.

Thanks,

Chris

[Roman Rodichev]

Did you try this?

https://supportforums.cisco.com/docs/DOC-3831

[Adrian Saavedra]

Hi Chris,

Try this:

1.- Uncheck Sending calling name in Facility IE and Display IE on the gateway configuration in CUCM Administration page.

2.- Next, no mgcp and then mgcp in global configuration mode on the MGCP router.

Hope it helps, please rate if it does.

Kind regards,

- Adrian.

[olighec]

Roman and Adrian,

Unfortunately, I've had those boxes unchecked the whole time.  We have never attempted to deliver calling name ID since the telco adds it on their end.

[Roman Rodichev]

Try setting all plan types to Unknown in MGCP configuration on CM

[Mike Lydick]

Assuming that show isdn status show multframe established, show isdn service show that channels are available. This appears that the B-channels cannot be seized for outbound calls. if you can get inbound not outbound this may indicate not all the Bchannels are up. So the provider is seizing the available ones. Your CM is set for select the other direction so those are the ones that are down. If you want to troubleshoot this reverse the direction to see if that changes the behavior.

I think you are going to have to engage the provider for interactive verification and troubleshooting.

[olighec]

When I change the plan to anything other than National, ISDN, I get back 0x82E470 - Invalid information element contents from the remote switch.

I switched the channel ordering which causes some D-channel jumping when calls are coming in and I am trying outbound test calls, but that didn't change the 0x80B2 errors.  When I sh voice port, all the D-channels show as available.

I will go back to the telco.

Thanks for all the suggestions!

[jfackrell]

Just ran into this problem on a site in Chicago and unchecking those boxes fixed the issue. Very helpful, thanks!