[cisco-voip] MGCP PRI: Cause i = 0x80AC - Requested circuit/channel not available on Incoming Calls
Ryan Ratliff
rratliff at cisco.com
Fri Apr 30 13:16:39 EDT 2010
The RTMT counter explanation will have the basic idle, busy, out of service ones. Anything not there is a type of internal oos state that is only useful to DEs.
-Ryan
On Apr 30, 2010, at 11:37 AM, Robert Schuknecht wrote:
> 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/3febcf7f/attachment.html>
More information about the cisco-voip
mailing list