[cisco-voip] MGCP PRI: Cause i = 0x80AC - Requested circuit/channel not available on Incoming Calls

Robert Schuknecht rschuknecht at gmx.de
Fri Apr 30 11:37:04 EDT 2010


Ryan,

 

where can i find a document which describes the different status indicator
meanings?

 

I had no chance to find the right trace file to track down what caused the
issue. 

 

@all: Thanks for your help!

 

/Robert

 

Von: Ryan Ratliff [mailto:rratliff at cisco.com] 
Gesendet: Freitag, 30. April 2010 02:49
An: Jason Aarons (US)
Cc: Robert Schuknecht; 'cisco-voip voyp list'
Betreff: Re: [cisco-voip] MGCP PRI: Cause i = 0x80AC - Requested
circuit/channel not available on Incoming Calls

 

The earlier CCM trace snippet shows it is a PriEuro, which is an E1. 

The Status Poll also confirms this (32 channels).

Port Status for S0/SU0/DS1-1 at ostbogw01.XXXXXX.local  1-8=11111111
9-16=12211619  17-24=11100000  25-32=0000000a

 

Channel 14 showing status 6 is not good.  You either had an MGCP failure on
that b-chan at some point that resulted in CUCM taking it out of service or
some CUCM bug has locked it OOS.

 

I would get all the CCM traces you can on this node, grep through them all
for that status poll and see if you can see port 14 in any status other than
6.  If you can catch where it got locked up you can find out how.

 

If you can't find it (or don't care to) just reset the endpoint in CCMAdmin
(or no mgcp/mgcp on the router) and that should clear it up.

 

-Ryan

 

On Apr 29, 2010, at 4:54 PM, Jason Aarons (US) wrote:





Channel 15 is your D Channel on a E1, it's used for signaling, not bearer
traffic.  Sounds like in CCMAdmin or the gateway T1 was selected vs E1.

  _____  

From: Robert Schuknecht [rschuknecht at gmx.de]
Sent: Thursday, April 29, 2010 3:19 PM
To: Jason Aarons (US); 'cisco-voip voyp list'
Subject: AW: [cisco-voip] MGCP PRI: Cause i = 0x80AC - Requested
circuit/channel not available on Incoming Calls

Jason,

 

yes ist an E1, but show isdn service is not useful because its an MGCP GW.
Right now, its not possible to do a loopback test.

 

/Robert

 

Von: Jason Aarons (US) [mailto:jason.aarons at us.didata.com] 
Gesendet: Donnerstag, 29. April 2010 17:31
An: Robert Schuknecht; 'cisco-voip voyp list'
Betreff: RE: [cisco-voip] MGCP PRI: Cause i = 0x80AC - Requested
circuit/channel not available on Incoming Calls

 

Since it's channel 15 is it a E1 ?

 

show isdn service

 

Put a loopback plug toward you is that channel good/in service ?

 

 

  _____  

From: cisco-voip-bounces at puck.nether.net
[cisco-voip-bounces at puck.nether.net] On Behalf Of Robert Schuknecht
[rschuknecht at gmx.de]
Sent: Thursday, April 29, 2010 11:27 AM
To: 'cisco-voip voyp list'
Subject: [cisco-voip] MGCP PRI: Cause i = 0x80AC - Requested circuit/channel
not available on Incoming Calls

Hi,

 

i am facing problems with incoming calls on a MGCP PRI Gateway. Some of the
incoming calls get disconnected with cause code: Cause i = 0x80AC -
Requested circuit/channel not available. I noticed that this happens only on
one specific port and B-Channel.

 

Sample output of debug isdn q931:

 

Apr 29 14:45:25.870 cest: ISDN Se0/0/1:15 Q931: RX <- SETUP pd = 8  callref
= 0x0071

                Sending Complete

                Bearer Capability i = 0x8090A3

                               Standard = CCITT

                               Transfer Capability = Speech 

                               Transfer Mode = Circuit

                               Transfer Rate = 64 kbit/s

                Channel ID i = 0xA9838E

                               Exclusive, Channel 14

                Calling Party Number i = 0x2183, '160XXXXXXX'

                               Plan:ISDN, Type:National

                Called Party Number i = 0xC1, '25XXXXXX'

                               Plan:ISDN, Type:Subscriber(local)

                High Layer Compat i = 0x9181

Apr 29 14:45:25.870 cest: ISDN Se0/0/1:15 Q931: TX -> RELEASE_COMP pd = 8
callref = 0x8071

                Cause i = 0x80AC - Requested circuit/channel not available

 

At nearly the same time I see the following output in CCM Trace:

 

CCM|In  Message -- PriEuroSetupMsg -- Protocol=
PriEuroProtocol|<CLID::StandAloneCluster><NID::10.236.3.51><LVL::Significant
><MASK::0040>


CCM|Ie - Ni2BearerCapabilityIe -- IEData= 04 03 80 90 A3
|<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|Ie - Q931ChannelIdIe -- IEData= 18 03 A9 83 8E
|<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|Ie - Q931CallingPartyIe -- IEData= 6C 0C 21 83 31 36 30 3X 3X 3X 3X 3X
3X 3X |<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|Ie - Q931CalledPartyIe -- IEData= 70 09 C1 32 35 3X 3X 3X 3X 3X 3X
|<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|Ie - Q931HighLayerCompatibilityIe -- IEData= 7D 02 91 81
|<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|MMan_Id= 0. (iep=  0 dsl= 8001 sapi=  0 ces= 0 IpAddr=403ec0a
IpPort=2427)|<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|IsdnMsgData1= 08 02 00 71 05 A1 04 03 80 90 A3 18 03 A9 83 8E 6C 0C 21
83 31 36 30 38 34 39 33 32 36 31 70 09 C1 32 35 35 30 31 34 30 31 7D 02 91
81 |<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|MGCPpn9d - S0/SU0/DS1-1 at ostbogw01.XXXXXXXXX.local - Collision Detected
On PriEuro Interface callphase=
9|<CLID::StandAloneCluster><NID::10.236.3.51><CT::2,100,133,1.358133><IP::10
.236.3.4><DEV::><LVL::State Transition><MASK::2000>


CCM|Entering default,restarting
channel|<CLID::StandAloneCluster><NID::10.236.3.51><CT::2,100,133,1.358133><
IP::10.236.3.4><DEV::><LVL::State Transition><MASK::2000>


CCM|MGCPpn9d::conflictingChannelHandler - Don't Restart this channel since
it is marked OOS_NE under service parameter:S0/SU0/DS1-1 at ostbogw01.
XXXXXXXXX.local=00000000000000000000000000000000 or due to MGCP gateway
hardware
failure|<CLID::StandAloneCluster><NID::10.236.3.51><CT::2,100,133,1.358133><
IP::10.236.3.4><DEV::><LVL::State Transition><MASK::2000>

CCM| |<CLID::StandAloneCluster><NID::10.236.3.51><LVL::State
Transition><MASK::0040>


CCM|Out Message -- PriReleaseCompleteMsg -- Protocol=
PriEuroProtocol|<CLID::StandAloneCluster><NID::10.236.3.51><LVL::Significant
><MASK::0040>    

 

I checked the above mentioned CCM Service Parameter and It is not checked.

 

Does anybody know how to track down the root cause of this issue?

 

Callmanager is running 7.0.2-20000-5

Gateway is running 12.4(22)T4


 

 

  _____  

Disclaimer: This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the designated
addressee(s) named above only. If you are not the intended addressee, you
are hereby notified that you have received this communication in error and
that any use or reproduction of this email or its contents is strictly
prohibited and may be unlawful. If you have received this communication in
error, please notify us immediately by replying to this message and deleting
it from your computer. Thank you.

  _____  

Disclaimer: This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the designated
addressee(s) named above only. If you are not the intended addressee, you
are hereby notified that you have received this communication in error and
that any use or reproduction of this email or its contents is strictly
prohibited and may be unlawful. If you have received this communication in
error, please notify us immediately by replying to this message and deleting
it from your computer. Thank you.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100430/08dfd8c7/attachment.html>


More information about the cisco-voip mailing list