Outbound Calling and the Fast Busy

[b-krull]

Hello,

I'm having issues with the outbound calling between our ISR 4331 and a SL-100 phone switch.  Whenever we try to dial a seven digit number from our Cisco phones, we get a busy tone; however, phones attached to the SL-100 can call us.  The legacy phone tech wiped his hands of it and told me good luck.  We are using a MGCP gateway over a T1 (PRI) with CUCM 12.5.  Q931 says I'm getting a "No Circuit\Channel Available" error when dialing outbound.  I've tried numerous route patterns - seven digits, 10 digits, with a 9 or 99, but still fast busy.  I've wiped the ISR and started over, rebuilt the route list and groups, to no avail.  I've attached my configs and some debugs.  I appreciate your help.

[Steven L]

isdn bind-l3 ccm-manager

and try again

[Steven L]

actually its in there....sorry I missed it the first time

[Steven L]

I used to be an "expert" in both MGCP and PRIs. I will need to do some research to refresh my memories.

any specific reason why you are using MGCP vs SIP for this?

[b-krull]

Thanks Steven.  We operate very small locations that are offshoots from a legacy switch.  MGCP has worked fine for our other locations; not sure why this one is any different.  

To me, I'm thinking something is off with our controller channels but I'm not showing anything wrong.  

[Elliot Dierksen]

Are you sure you have the right ISDN switch type? You could also ask the SL100 tech to busy out all the PRI B channels, and then clear that. I had a customer that had interconnections between CUCM and an SL100, and the SL100 would occasionally decide that a particular B channel wasn't available when it wasn't actually in use. I would be interested in seeing the Q.931 debug for both a successful call and a failed called. Does CUCM try the same channel more that once? You could also change the channel selection criteria between the choices of "top down" or "bottom up".

[b-krull]

Hi Elliott,

We have the b channels turned down except for 0/1/0:1. I know the calls are hitting the channel but dropping. I'm getting a 0x80C1 Bearer capability not implemented on the q931 debug.

I've been trying different codecs but nothing has been helping.

[Elliot Dierksen]

This rings a vague bell. Would you post the Q.931 debug? I am looking through my notes, but I think it might have something to do with the calling party name or something else wonky. Seeing the whole conversation (a success and a fail) might help jog my memory.

[Elliot Dierksen]

Here is some stuff from another thread on how to set the CUCM side of the PRI.

Called party IE Number Type unknown - Subscriber
Calling party IE Number Type unknown - Subscriber
Called Numbering Plan - Private
Calling Numbering Plan - Private

 Here is the link.

https://community.cisco.com/t5/ip-telephony-and-phones/cisco-to-nortel-callpilot-vm/td-p/1176245 

It has probably been 10 years or more since I saw this, but this sounds familiar. I do remember it was something dumb like this.

[b-krull]

I spent part of yesterday working with Cisco after creating a tac.  Cisco stated the SL-100 is looping the call back to the ISR where I guess it dies.  They told me to reach out to the Nortel side to identify why they are looping it back.

032052: Mar 14 14:39:25.062: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0413

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA9838D

                Exclusive, Channel 13

        Calling Party Number i = 0x0080, '4399915'

                Plan:Unknown, Type:Unknown

        Called Party Number i = 0xC1, '4396667'

                Plan:ISDN, Type:Subscriber(local)

[Elliot Dierksen]

What does the Q.931 look like in a successful call from the SL-100? If you are sending a call, where is the debug portion of the call where your gateway is doing the TX -> SETUP?

[b-krull]

Thanks Elliot, I will post my q931 tomorrow after I try your recommendations.  I've found today that my call will roll through all the channels, with each one erroring out with "Bearer capability not implemented".  I know its hitting the channels on his end, but I dont know why its not pushing through short of something on the Nortel end either blocking the number or a wrong route pattern.  What makes it tough is that the other tech states "everything is good on my side".  Ugh.