ArchiveOrangemail archive

Cisco VoIP list


cisco-voip.puck.nether.net
(List home) (Recent threads) (17 other puck.nether.net lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Moderate traffic list: up to 30 messages per day
  • This list contains about 37,406 messages, beginning Apr 2009
  • 1 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

Cause 0x80AA Switching Equipment Congestion

Ad
Dave Wolgast 1331914495Fri, 16 Mar 2012 16:14:55 +0000 (UTC)
Has anyone seen this before? We are not able to send/receive calls via our
PRIs and get this cause code. Here is the full ISDN q931 output:

Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref =
0x0283
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Calling Party Number i = 0x2183, '8168779065'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '7777'
                Plan:Unknown, Type:Unknown
Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: Received SETUP  callref = 0x8283
callID = 0x240D switch = primary-ni interface = User
Mar 16 11:06:38.656: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8
 callref = 0x8283
        Cause i = 0x80AA - Switching equipment congestion
Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref =
0x0284
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Calling Party Number i = 0x2183, '8168779065'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '7777'
                Plan:Unknown, Type:Unknown
Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: Received SETUP  callref = 0x8284
callID = 0x240E switch = primary-ni interface = User
Mar 16 11:06:39.816: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8
 callref = 0x8284
        Cause i = 0x80AA - Switching equipment congestion

Some research shows a potential issue with bad DSPs, but that doesn't
appear to be the case here.

Any help is appreciated.
Andy 1331917994Fri, 16 Mar 2012 17:13:14 +0000 (UTC)
I've had something similar
on a new install the provider had installed 8 x E1 circuits but hadn't 
upgraded the infrastructure in their Exchange to cope with the 
additional traffic.

Rgds

AndyOn 16/03/2012 16:13, Dave Wolgast wrote:
> Has anyone seen this before? We are not able to send/receive calls via 
> our PRIs and get this cause code. Here is the full ISDN q931 output:
>
> Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref 
> = 0x0283
>         Bearer Capability i = 0x8090A2
>                 Standard = CCITT
>                 Transfer Capability = Speech
>                 Transfer Mode = Circuit
>                 Transfer Rate = 64 kbit/s
>         Channel ID i = 0xA98381
>                 Exclusive, Channel 1
>         Calling Party Number i = 0x2183, '8168779065'
>                 Plan:ISDN, Type:National
>         Called Party Number i = 0x80, '7777'
>                 Plan:Unknown, Type:Unknown
> Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: Received SETUP  callref = 
> 0x8283 callID = 0x240D switch = primary-ni interface = User
> Mar 16 11:06:38.656: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8 
>  callref = 0x8283
>         Cause i = 0x80AA - Switching equipment congestion
> Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref 
> = 0x0284
>         Bearer Capability i = 0x8090A2
>                 Standard = CCITT
>                 Transfer Capability = Speech
>                 Transfer Mode = Circuit
>                 Transfer Rate = 64 kbit/s
>         Channel ID i = 0xA98381
>                 Exclusive, Channel 1
>         Calling Party Number i = 0x2183, '8168779065'
>                 Plan:ISDN, Type:National
>         Called Party Number i = 0x80, '7777'
>                 Plan:Unknown, Type:Unknown
> Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: Received SETUP  callref = 
> 0x8284 callID = 0x240E switch = primary-ni interface = User
> Mar 16 11:06:39.816: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8 
>  callref = 0x8284
>         Cause i = 0x80AA - Switching equipment congestion
>
> Some research shows a potential issue with bad DSPs, but that doesn't 
> appear to be the case here.
>
> Any help is appreciated.
>
> -- 
> Dave Wolgast
> Livonia, NY
>
>
>
> _______________________________________________
> cisco-voip mailing list
> 
> https://puck.nether.net/mailman/listinfo/cisc...
Dave Wolgast 1331918197Fri, 16 Mar 2012 17:16:37 +0000 (UTC)
I haven't found a root cause for this, but a reload of the gateway seems to
have resolved the issue.On Fri, Mar 16, 2012 at 12:13 PM, Dave Wolgast wrote:

> Has anyone seen this before? We are not able to send/receive calls via our
> PRIs and get this cause code. Here is the full ISDN q931 output:
>
> Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref =
> 0x0283
>         Bearer Capability i = 0x8090A2
>                 Standard = CCITT
>                 Transfer Capability = Speech
>                 Transfer Mode = Circuit
>                 Transfer Rate = 64 kbit/s
>         Channel ID i = 0xA98381
>                 Exclusive, Channel 1
>         Calling Party Number i = 0x2183, '8168779065'
>                 Plan:ISDN, Type:National
>         Called Party Number i = 0x80, '7777'
>                 Plan:Unknown, Type:Unknown
> Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: Received SETUP  callref =
> 0x8283 callID = 0x240D switch = primary-ni interface = User
> Mar 16 11:06:38.656: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8
>  callref = 0x8283
>         Cause i = 0x80AA - Switching equipment congestion
> Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref =
> 0x0284
>         Bearer Capability i = 0x8090A2
>                 Standard = CCITT
>                 Transfer Capability = Speech
>                 Transfer Mode = Circuit
>                 Transfer Rate = 64 kbit/s
>         Channel ID i = 0xA98381
>                 Exclusive, Channel 1
>         Calling Party Number i = 0x2183, '8168779065'
>                 Plan:ISDN, Type:National
>         Called Party Number i = 0x80, '7777'
>                 Plan:Unknown, Type:Unknown
> Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: Received SETUP  callref =
> 0x8284 callID = 0x240E switch = primary-ni interface = User
> Mar 16 11:06:39.816: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8
>  callref = 0x8284
>         Cause i = 0x80AA - Switching equipment congestion
>
> Some research shows a potential issue with bad DSPs, but that doesn't
> appear to be the case here.
>
> Any help is appreciated.
>
> --
> Dave Wolgast
> Livonia, NY
>
> --
> Dave Wolgast
> Livonia, NY
>
>
Buchanan, James 1332017376Sat, 17 Mar 2012 20:49:36 +0000 (UTC)
I hit this. Bad DSPs and/or chassis was the culprit. What version of IOS? They also had us change that.

James Buchanan| UC Technology Manager | Presidio South | Presidio Networked Solutions
12 Cadillac Dr Ste 130 Brentwood, TN 37027 | <
D: 615-866-5729 | F:615-866-5781  www.presidio.com<http://www.presidio.com/>

From:   On Behalf Of Dave Wolgast
Sent: Friday, March 16, 2012 12:16 PM
To: Cisco VOIP Newsletter - puck.nether.net
Subject: Re: [cisco-voip] Cause 0x80AA Switching Equipment Congestion

I haven't found a root cause for this, but a reload of the gateway seems to have resolved the issue.

On Fri, Mar 16, 2012 at 12:13 PM, Dave Wolgast <> wrote:
Has anyone seen this before? We are not able to send/receive calls via our PRIs and get this cause code. Here is the full ISDN q931 output:

Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0283
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Calling Party Number i = 0x2183, '8168779065<tel:8168779065>'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '7777'
                Plan:Unknown, Type:Unknown
Mar 16 11:06:38.652: ISDN Se0/1/0:23 Q931: Received SETUP  callref = 0x8283 callID = 0x240D switch = primary-ni interface = User
Mar 16 11:06:38.656: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x8283
        Cause i = 0x80AA - Switching equipment congestion
Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0284
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Calling Party Number i = 0x2183, '8168779065<tel:8168779065>'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '7777'
                Plan:Unknown, Type:Unknown
Mar 16 11:06:39.812: ISDN Se0/1/0:23 Q931: Received SETUP  callref = 0x8284 callID = 0x240E switch = primary-ni interface = User
Mar 16 11:06:39.816: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x8284
        Cause i = 0x80AA - Switching equipment congestion

Some research shows a potential issue with bad DSPs, but that doesn't appear to be the case here.

Any help is appreciated.--
Dave Wolgast
Livonia, NY
Dave Wolgast 1332038564Sun, 18 Mar 2012 02:42:44 +0000 (UTC)
On Sat, Mar 17, 2012 at 3:22 PM, Buchanan, James wrote:

> I hit this. Bad DSPs and/or chassis was the culprit. What version of IOS?
> They also had us change that.****
>
> **
>Yeah, it was odd...all of the cases I could find online indicated bad DSPs,
with a telltale sign in the 'show voice dsp detailed' command or in one of
the show dspfarm commands, but I couldn't see any sign of DSP troubles.

IOS is 15.0(1)M6.
 --
Dave Wolgast
Livonia, NY
Home | About | Privacy