cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1338
Views
10
Helpful
9
Replies

Outbound calling not working on MGCP gateway

Hi - hoping someone can help.

 

I have inherited a call manager system and an MGCP gateway that has a PRI connected to it. There have been no configuration changes to the call manager or the MGCP gateway but outbound calling has stopped without any reason.

 

Running debug isdn q931 shows successful incoming calls but nothing displayed for outgoing calls. Phones trying to call outbound just get a busy tone and cannot make a call and the call isn't shown on the MGCP gateway.

 

Have ran a isdn test call and get the same output as below if I use a leading 9 or not.

isdn test call interface serial 0/0/0:15 08081639549
Jan 8 08:31:21.679: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x0085 callID = 0x8006 switch = primary-net5 interface = User
Jan 8 08:31:21.679: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0085
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98394
Exclusive, Channel 20
Called Party Number i = 0x81, '08081639549'
Plan:ISDN, Type:Unknown
Jan 8 08:31:21.839: ISDN Se0/0/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0x8085
Channel ID i = 0xA98394
Exclusive, Channel 20
Jan 8 08:31:21.843: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0085
Cause i = 0x80D1 - Invalid call reference value
Jan 8 08:31:25.679: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0085
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98394
Exclusive, Channel 20
Called Party Number i = 0x81, '08081639549'
Plan:ISDN, Type:Unknown
Jan 8 08:31:25.823: ISDN Se0/0/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0x8085
Channel ID i = 0xA98394
Exclusive, Channel 20
Jan 8 08:31:25.827: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0085
Cause i = 0x80D1 - Invalid call reference value
Jan 8 08:31:29.679: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0085
Cause i = 0x80E6 - Recovery on timer expiry
Jan 8 08:31:29.679: ISDN Se0/0/0:15 **ERROR**: CCPCC_CallOrigination: SETUP timed-out (2nd T303) to NETWORK. The SETUP failed.

9 Replies 9

Chris Deren
Hall of Fame
Hall of Fame

Have you tried debug mgcp?

What does Dialed Number Analyzer show, perhaps something was changed on CUCM and routing is incorrect to the GW?

With that being said MGCP is notorious for misbehaving and lots of times simple GW reboot or "no mgcp/mgcp" resolves "unknown" issues, have you tried either?

Looks like the provider issue was not the problem. I am going to reboot the gateway.

 

Can I also please check, is the command simply; no mgcp then right afterwards mgcp?

Jaime Valencia
Cisco Employee
Cisco Employee

Your test call probably didn't work because it was trying to be a video call

Transfer Capability = Unrestricted Digital

 

add "bearer-cap speech" under your voice port and try again, that on top of what Chris has already mentioned. If the call is not showing on GW debugs, it's not even making it out of CUCM.

HTH

java

if this helps, please rate

I'm assuming that would be under this section?

 

voice-port 0/0/0:15
cptone GB

 

Thanks!

Added bearer-cap speech but unfortunately did not resolve issue. 

 

voice-port 0/0/0:15
cptone GB
bearer-cap Speech

 

Thanks in advance for any more support.

Hi, 

 

Thanks for your suggestions. I had reported this to our provider as a secondary as the calls just randomly stopped. I was about to restart the gateway until the provider found a fault at the exchange. They cleared the error and an outbound call showed correctly, but then the error returned. They're continuing to see a line fault, however should their fix not resolve the issues my next step tomorrow will be to carry out your suggestions. Thank you for the responses, it's appreciated!

Just an update, it appears that calls from devices registered to one of our analogue gateways (VG224), for analogue phones, seem to go outbound correctly, see below but anyone else that rings from a Cisco handset of IP Communicator gets a busy tone and I don't see the call hitting the gateway, strange thing is that no config has changed.

Jan 9 09:54:07.043: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0001
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98394
Exclusive, Channel 20
Calling Party Number i = 0x0081, '1553'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '0186*******' --- starred out rest of number
Plan:Unknown, Type:Unknown
Jan 9 09:54:07.207: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8001
Channel ID i = 0xA98394
Exclusive, Channel 20
Jan 9 09:54:10.451: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8001
Progress Ind i = 0x8488 - In-band info or appropriate now available
Progress Ind i = 0x8482 - Destination address is non-ISDN
Jan 9 09:54:14.219: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x8001
Jan 9 09:54:14.259: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0001
Jan 9 09:58:06.867: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x8001
Jan 9 09:58:06.895: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0001

And another update. One of the buildings on-site can make calls outbound no problem and they hit the gateway, but any other building on-site can't make outbound calls - they don't hit the gateway.

 

I have set myself up with a test registering to the same call manager with the exact same settings as a known working person in one of the building that can make an outbound but mine fail with the same issue of the busy tone and nothing appearing on the gateway.

Couple of things to check if you eliminated routing issues (confirmed above with DNA), make sure Call Admission Control is not blocking the calls (Location and links configuration), but your best option at this time would be to pull CUCM SDL traces and review them for reasons of the failure.