[Home]

Summary:ASTERISK-06334: CONGESTION gallore in the afternoon
Reporter:Edwin Groothuis (mavetju)Labels:
Date Opened:2006-02-16 09:06:47.000-0600Date Closed:2011-06-07 14:03:27
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) congestion-channel-data.txt
( 1) pri-debug.txt
Description:In the last two days, in the afternoons, we suddenly get smacked with constant rejected calls due to congestion. This is strange, since only say 24 of the 2x31 channels are in use.

The channel to dialout via is choosen via ChanIsAvail because I have two PRIs to choose from:

 TRUNK_SJH_AAPT1=Zap/g4
 TRUNK_SJH_AAPT2=Zap/g6
 TRUNK_SJH_AAPT=${TRUNK_SJH_AAPT1}&${TRUNK_SJH_AAPT2}


 exten => s,n,ChanIsAvail(${TRUNK_SJH_AAPT})
 exten => s,n,CUT(C=AVAILCHAN,,1)
 exten => s,n,NoOp(${C}/${ARG1})
 exten => s,n,Macro(call-ext-XXX,${C}/${ARG1})

 and where macro-call-ext-XXX is:
 [macro-call-ext-XXX]
 exten => s,1,NoOp(Number:${ARG1})
 exten => s,n,Dial(${ARG1})


So in the logfiles it shows up as:

 Feb 16 16:54:03 logger.c:     -- Executing ChanIsAvail("Zap/28-1", "Zap/g6&Zap/g4") in new stack
 Feb 16 16:54:03 chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/172-1
 Feb 16 16:54:03 chan_zap.c: Hangup: channel: 172 index = 0, normal = 180, callwait = -1, thirdcall = -1
 Feb 16 16:54:03 chan_zap.c: disabled echo cancellation on channel 172
 Feb 16 16:54:03 chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/172-1
 Feb 16 16:54:03 chan_zap.c: Updated conferencing on 172, with 0 conference users
 Feb 16 16:54:03 chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/172-1
 Feb 16 16:54:03 chan_zap.c: disabled echo cancellation on channel 172
 Feb 16 16:54:03 logger.c:     -- Hungup 'Zap/172-1'
 Feb 16 16:54:03 logger.c:     -- Executing Cut("Zap/28-1", "C=AVAILCHAN||1") in new stack
 Feb 16 16:54:03 logger.c:     -- Executing NoOp("Zap/28-1", "Zap/172/96762664") in new stack
 Feb 16 16:54:03 logger.c:     -- Executing Macro("Zap/28-1", "call-ext-XXX|Zap/172/96762664") in new stack
 Feb 16 16:54:03 logger.c:     -- Executing NoOp("Zap/28-1", "Number:Zap/172/96762664") in new stack
 Feb 16 16:54:03 logger.c:     -- Executing NoOp("Zap/28-1", "CallerID:0293353038") in new stack
 Feb 16 16:54:03 logger.c:     -- Executing Dial("Zap/28-1", "Zap/172/96762664") in new stack
 Feb 16 16:54:03 logger.c:     -- Requested transfer capability: 0x00 - SPEECH
 Feb 16 16:54:03 channel.c: Avoiding initial deadlock for 'Zap/172-1'
 Feb 16 16:54:03 logger.c:     -- Called 172/96762664
 Feb 16 16:54:03 logger.c:     -- Channel 0/17, span 6 got hangup
 Feb 16 16:54:03 logger.c:     -- Zap/172-1 is circuit-busy
 Feb 16 16:54:03 chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/172-1
 Feb 16 16:54:03 chan_zap.c: Hangup: channel: 172 index = 0, normal = 180, callwait = -1, thirdcall = -1
 Feb 16 16:54:03 chan_zap.c: Already hungup...  Calling hangup once, and clearing call
 Feb 16 16:54:03 chan_zap.c: disabled echo cancellation on channel 172
 Feb 16 16:54:03 chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/172-1
 Feb 16 16:54:03 chan_zap.c: Updated conferencing on 172, with 0 conference users
 Feb 16 16:54:03 chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/172-1
 Feb 16 16:54:03 chan_zap.c: disabled echo cancellation on channel 172
 Feb 16 16:54:03 logger.c:     -- Hungup 'Zap/172-1'
 Feb 16 16:54:03 logger.c:   == Everyone is busy/congested at this time (1:0/1/0)
 Feb 16 16:54:03 app_dial.c: Exiting with DIALSTATUS=CONGESTION.

Channel Zap/172 is choosen by ChanIsAvail(), it's clear but then it's suddenly circuit-busy?

Comments:By: Edwin Groothuis (mavetju) 2006-02-16 21:09:21.000-0600

I have captured the "show channel" and "show zap" from a channel which is throwing this behaviour.
By: Tilghman Lesher (tilghman) 2006-02-16 22:19:37.000-0600

Have you checked with your provider and ensured the problem is not with them?  I know it seems strange, but from time to time providers also have network problems.
By: Edwin Groothuis (mavetju) 2006-02-16 22:32:28.000-0600

AAPT swears with the hand on their heart, on their mothers grave and with boyscouts honour that they don't see this behaviour on their exchange.

I admit that I've done a PRI debug on it, and see the cause coming back, but I don't know it this is from zaptel to asterisk, or libpri to zaptel, or libpri to asterisk, or from the other PRI to zaptel.

Sometimes I wish there is was something like tcpdump but then for PRIs.

See attached file.
By: Mark Spencer (markster) 2006-02-19 23:22:14.000-0600

Please pursue through Digium technical support (support@digium.com).  Feel free to contact me off the bug tracker if they are unable to resolve your issues for any reason.