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

Ryan Ratliff rratliff at cisco.com
Thu Apr 29 20:49:05 EDT 2010


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/20100429/df5bfe9d/attachment-0001.html>


More information about the cisco-voip mailing list