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

[Robert Schuknecht]

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


 

 

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