Re: MGCP Gateway Pri can not get inbound calls

gwenzit · ‎09-22-2004

We are having a very weird error message in the log file when "debug isdn standard interface serial1/0:23"

is done.

Our pri will not accept inbound calls but will make outbound no problem.

our gateway config is

dial-peer voice 10 voip

description FOR INCOMING CALLS TO Publisher

destination-pattern 516420....

progress_ind setup enable 3

voice-class h323 1

session target ipv4:10.32.240.100

dtmf-relay h245-alphanumeric

codec g711ulaw

ip qos dscp cs5 media

no vad

The Error message we are getting is :

.Sep 22 16:39:09.578: ISDN Se1/0:23 **ERROR**: cdapi_process_connect_resp: cdapi sez to reject the call (appl rejected?)

.Sep 22 16:39:09.574: ISDN Se1/0:23 BACKHAUL: L3IF_rx_L2_pak: received data 0x0802019F0504038090A21803A983816C

.Sep 22 16:39:09.574: 0C218338353632323230363433700BA1

.Sep 22 16:39:09.574: 35313634323036353031

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENT: process_rxstate: ces/callid 1/0x612 calltype 2 CALL_INCOMING

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: isdn_get_guid: Got Guid C2FE6D5185BC

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENT: call_incoming: call_id 0x0612, Guid = C2FE6D5185BC

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: calltrkr_incoming_call: call_id=0x612

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: calltrkr_setup_received: isdn_info=1696545016l, call_id=0x612 ANSWER

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: calltrkr_setup_received: calltracker disabled

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: calltrkr_setup_received: isdn_info=1672222156l, call_id=0x612 ANSWER

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: call_incoming: b channel 0, call type is VOICE ULAW

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: call_incoming: Received a VOICE call from 8562220643 on b channel 0 at 64 Kb/s

.Sep 22 16:39:09.578: ISDN Se1/0:23 **ERROR**: cdapi_process_connect_resp: cdapi sez to reject the call (appl rejected?)

.Sep 22 16:39:09.578: ISDN Se1/0:23 EVENTd: calltrkr_call_cleared: isdn_info=0x63AC15CC, call_id=0x612

.Sep 22 16:39:09.582: ISDN Se1/0:23 EVENTd: calltrkr_call_cleared: isdn_info=0x651F38F8, call_id=0x612

.Sep 22 16:39:09.582: ISDN Se1/0:23 EVENT: process_rxstate: ces/callid 1/0x612 calltype 2 CALL_CLEARED

.Sep 22 16:39:09.582: ISDN Se1/0:23 EVENTd: calltrkr_call_cleared: isdn_info=0x651F38F8, call_id=0x612

.Sep 22 16:39:09.582: ISDN Se1/0:23 EVENTd: calltrkr_call_cleared: isdn_info=0x63AC15CC, call_id=0x612

.Sep 22 16:39:09.582: ISDN Se1/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x819F

Cause i = 0x80AF - Resource unavailable, unspecified

ios ver is i believe 12.3 ip plus

irisrios · ‎09-29-2004

I suspect some misconfiguration of inbound dial-peers. Also may be the problem with the ISDN link, not being setup due to some reasons. You may check with "debug ISDN Q931" command.

For reference:

Understanding Inbound and Outbound Dial Peers on Cisco IOS Platforms

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080147524.shtml:

nz-ipv6 · ‎09-30-2004

Hi there,

Well as far as I know,while using MGCP there is no need for confiuring Dial-peers unless you are using SRST or H323.

In MGCP mode,the isdn bind-l3 ccm-manager command on the interface sends all the signalling information back to call manager and doesn't use dial-peer.

Since the outbound calls are working fine,I would make sure that there are correct translation patterns configured on the call-manager.

Thanks

Trib

gwenzit · ‎10-02-2004

Thank you very much I will look into your suggestions

jlzfeeney · ‎07-11-2005

I know this an old post but I am going to repsond to this. Basically, when you see these ISDN messages, it is indeed true that no resource is available. I am running 12.3(8)T5 and have been experiencing strange MGCP issues where the isdn bind-l3 ccm-manager commands under the PRI serial interfaces magically disappear. Usually I have to add the commands back, and stop and restart mgcp to correct this problem. I know I am not the only one who has seen this issue and if someone on this forum has seen this and has a credible fix, it would be greatly appreciated. This problem has manifested itself on several platforms but the IOS versions are consistent.

jlewissystem · ‎07-11-2005

We have experienced this issue on 2 of our gateways, 12.3(8)T6 and 12.3(8)T3. Our current version of CM is 3.3(4) We haven't had a good answer with concrete evidence. Could someone please shed a little more light on this situation???

jlzfeeney · ‎07-11-2005

I have been on the phone with our VAR and Cisco on several occasions with this. Once I go through the sequence of events as recommended and see that they work I will post it out to the forum. I did hear however that this problem is more prevalent with 3.3(4) which is what I have also.

John Safarik · ‎02-12-2014

Late to the party here, but I have experienced the same issue for inbound DID calls on a PRI to an MGCP Gateway.

When you reset the Gateway via CM and then made a test call, you could see it hit (via debug q931) the gateway and then after 4 rings, the call would just disconnect. After looking at the logs, I found:

ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x 83B0

Cause i = 0x80AF - Resource unavailable, unspecified

ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x 83B0
Cause i = 0x80AF - Resource unavailable, unspecified

After subsequent calls, I was getting a "all channels busy" announcement from the carrier, which I believe is typical when our equipment rejects the calls. In order to get my calls working inbound, I had to remove mgcp fax t38 inhibit from the config and replace it with no mgcp fax t38 inhibit

Calls started working normal after this. If anyone has insight as to why this solution works, please let me know.

Thanks

Kevin Monteiro · ‎02-20-2014

Hi John,

This is bug, if your MGCP messages exchanged the CRCX fxr/pkg enabled which tries to maintain it a s FAX call rather than a Voice call. Below is the bug description:

Description

Symptom:

Voice, Cisco Fax Relay and Fax Passthrough type of calls will fail when

mgcp fax t38 inhibit command is configured

Conditions:

This problem is noticed on Unified CM 6.0(1) and above.

Workaround:

When you disable T.38 fax relay, you also need to disable the default enabled

fxr-package, in addition to mgcp fax t38 inhibit, and reset the mgcp service.

Otherwise, you enable T.38 fax relay with default enabled fxr-package.

Further Problem Description:

Unified CM began to support T38 fax relay (CallAgent-controlled mode) based

on if fxr-package is enabled since 4.2 in Windows release and 6.0 in Linux

release.

The current design states if GW and Call Agent (CUCM) fail on the fax

protocol negotiation, all types of calls will be rejected including voice

calls.

https://tools.cisco.com/bugsearch/bug/CSCsj24114

Rate the post accordingly.

Regards,

Kevin

iziks · ‎11-13-2005

Hi,

I have same problem.

Did You find how resolve this issue??????

Please let us know.

Thanks.