[cisco-voip] MGCP to PSTN - 0x80A9 - Temporary failure?

[Stephen Greszczyszyn]

Thanks for the tip Ryan.  I tried the decoder, but it didn't seem to
work.  The first time it told me to paste in the sh version header,
and after I added that it just timed out.

I left the MGCP debugs on for a while to
see if I could find any reset messages, but no luck.  It seems that
the MGCP is stable when there are no calls, and once a call is up,
after a while the IOS gateway initiates a disconnect and sends the
message to CUCM:

MGCP GW:
Feb  3 15:48:03.988: MGCP Packet sent to 10.10.210.11:2427--->
DLCX 81355940 S0/SU1/DS1-0/1 at br1.proctorlabs.com MGCP 0.1
C: D000000002a512cd000000F500000001
I: 2
P: PS=5000, OS=800000, PR=4981, OR=796960, PL=18, JI=7, LA=0
E: 502
<---

CUCM:
02/03/2010 15:46:24.640 CCM|MGCPHandler received msg from: 10.10.110.2
DLCX 81355940 S0/SU1/DS1-0/1 at br1.proctorlabs.com MGCP 0.1
C: D000000002a512cd000000F500000001
I: 2
P: PS=5000, OS=800000, PR=4981, OR=796960, PL=18, JI=7, LA=0
E: 502

And the CUCM drops the calls:

02/03/2010 15:46:24.642
CCM|AgenaInterface(33)::closeRecvForAllAudioChannels,
mAudioIncomingLC2AGIDMap size =
1|<CLID::StandAloneCluster><NID::10.10.210.11><CT::2,100,132,1.1203><IP::10.10.110.2><DEV::S0/SU1 at br1.proctorlabs.com><LVL::Detailed><MASK::0800>

I can't figure out what the MGCP gateway doesn't like about the call.
I rolled back to 12.4.22T, but that didn't fix the problem.

The config on the MGCP controller/serial/mgcp is:

controller E1 0/1/0
 pri-group timeslots 1-4,16 service mgcp

interface Serial0/1/0:15
 no ip address
 encapsulation hdlc
 isdn switch-type primary-net5
 isdn incoming-voice voice
 isdn bind-l3 ccm-manager
 no cdp enable

ccm-manager switchback immediate
ccm-manager redundant-host 10.10.210.10
ccm-manager mgcp
ccm-manager fax protocol cisco

mgcp
mgcp call-agent 10.10.210.11 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode out-of-band
mgcp bind control source-interface Loopback0
mgcp bind media source-interface Loopback0

On the PSTN it is:

controller E1 0/3/0
 clock source internal
 pri-group timeslots 1-4,16
 description ** PSTN to BR1 **

interface Serial0/3/0:15
 no ip address
 encapsulation hdlc
 isdn switch-type primary-net5
 isdn protocol-emulate network
 isdn incoming-voice voice
 no cdp enable

I've placed a mask in the CUCM service parameters for only using 4 of the
PRI channels.
S0/SU1/DS1-0 at br1.proctorlabs.com = 0000 1111 1111 1111 1111 1111 1111 1111

I think the rest of my MGCP CUCM setting is OK.

q921/q931 doesn't really show much to me either:

MGCP
Feb  3 18:08:00.873: ISDN Se0/1/0:15 Q921: User TX -> INFO sapi=0
tei=0, ns=10 nr=11
Feb  3 18:08:00.873: ISDN Se0/1/0:15 Q931: DISCONNECT pd = 8  callref = 0x0002
	Cause i = 0x80A9 - Temporary failure

PSTN
*Feb  3 18:14:24.587: ISDN Se0/3/0:15 Q921: Net RX <- INFO sapi=0
tei=0, ns=10 nr=11
*Feb  3 18:14:24.587: ISDN Se0/3/0:15 Q931: DISCONNECT pd = 8  callref = 0x0002
	Cause i = 0x80A9 - Temporary failure
*Feb  3 18:14:24.587: ISDN Se0/3/0:15 Q921: Net TX -> RR sapi=0 tei=0 nr=11
*Feb  3 18:14:24.591: %ISDN-6-DISCONNECT: Interface Serial0/3/0:0
disconnected from +16178631002 , call lasted 73 seconds

Puzzled.

On Wed, Feb 3, 2010 at 2:51 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> Normally a temp failure coming from CUCM means a device involved in the call unregistered.  With MGCP gateways this is most common when you have MGCP messages getting lost between CUCM and the router.  CUCM will retransmit a message 3 times before unregistering the gateway.
>
> In this case you have a traceback followed by the gateway sending a DLCX (delete connection) message to the CUCM, which ends up with CUCM tearing down the call.
>
> I'd recommend putting your traceback (and the other required info) into the output interpreter at https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl.
>
> -Ryan
>