[asterisk-bugs] [JIRA] (ASTERISK-19608) Asterisk-1.8.x starts rejecting calls with cause code 44 after some time.

Wed Jan 16 15:40:46 CST 2013

     [ https://issues.asterisk.org/jira/browse/ASTERISK-19608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan closed ASTERISK-19608.
----------------------------------

    Resolution: Fixed

This issue is nice to have in the issue tracker as it documents clearly the symptoms of a particular problem, but at this point in time this issue should be resolved in all supported versions of Asterisk.

As such, I'm going to go ahead and close this out.

> Asterisk-1.8.x  starts rejecting calls with cause code 44 after some time.
> --------------------------------------------------------------------------
>
>                 Key: ASTERISK-19608
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19608
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>         Environment: Asterisk-1.8.x
> LibPRI-1.4.12
> DAHDI-2.6.X
>            Reporter: Denis Alberto Martinez
>
> h3.*Symptoms observed by the user*
> - After some time on production, Asterisk start rejecting calls on specific channels with ISDN cause code 44. 
> h3.Problem Description
> In certain situations, such as extremely high call volume on crowded channels, there is a possibility of a call collision, in which the telco rejects an outgoing call (from Asterisk) because it's expecting to use the same channel for another call (to Asterisk).  When this occurs, Asterisk will invoke the Q.931 restart procedure,  but the telco does not always respond to all RESTART messages with a RESTART ACKNOWLEDGE. 
>  
> Under this circutances Asterisk will lock the channel and it won't accept any new calls until the channel restart is completed.  Our interpretation of the Q.931 Specification (section 5.5.1) tell us that the (incoming) call rejection made by Asterisk can be considered expected behavior 
> {quote}
> h5. 5.5.1 Sending RESTART message
> ...
> _If a RESTART ACKNOWLEDGE message is not received prior to the expiry of timer T316, one or more subsequent RESTART messages may be sent until a RESTART ACKNOWLEDGE message is returned. *Meanwhile, no calls shall be placed or accepted over the channel or interface by the originator of the RESTART message*. A network shall limit the number of consecutive unsuccessful restart attempts to a default limit of two. When this limit is reached, the network shall make no further restart attempts. An indication will be provided to the appropriate maintenance entity. The channel or interface is considered to be in an out-of-service condition until maintenance action has been taken._
> ...
> {quote}
> In previous version of software (such as Asterisk-1.4.X) Asterisk used to tolerate this behavior, but recent changes and code improvement made it unacceptable.  
> h3. How to Determine if this issue is affecting your system
> *1. Make sure that logging in Asterisk is enable.* 
> Edit /etc/asterisk/logger.conf, uncomment the line beginning with "_;messages => ..._" (To uncomment, means to remove the ";" character). Edit the same line, to include the following information, then save the file 
> "_messages => notice,warning,error,verbose_"
> Example:
> {noformat}
> ;debug => debug
> console => notice,warning,error
> ;console => notice,warning,error,debug
> messages => notice,warning,error,verbose
> ;full => notice,warning,error,debug,verbose,dtmf,fax
> {noformat}
> *2. Rotate the logs* 
> Execute the command: _logger rotate_ in the Asterisk CLI
> {noformat}
> *CLI> logger rotate
> {noformat}
> *3. Restart Asterisk and DAHDI.*
> This is to ensure that every channel on Asterisk is on a working state.
> *4. Make sure that messages output is enable on Asterisk*
> Log into the Asterisk CLI and run the command _logger show channels_ and make sure that _messages_ is shown
> {noformat}
> *CLI> logger show channels
> Channel                             Type     Status    Configuration
> -------                             ----     ------    -------------
> /var/log/asterisk/messages          File     Enabled    - NOTICE WARNING ERROR VERBOSE 
>                                     Console  Enabled    - NOTICE WARNING ERROR  
> {noformat}
> *5. Enable PRI Debug* 
> In order to enable PRI on a specific span please run the CLI command: _pri set debug on span <SPAN NUMBER>_
> Example
> {noformat}
> *CLI> pri set debug on span 1
> Enabled debugging on span 1
> {noformat}
> *6. Start normal operation and watch if a channels get lock*
> By using the following the Linux command, you should be able to see which B channels are in non-idle state and the number of active channels in Asterisk.  
> _#watch -n1 'asterisk -rx"pri show channels" | grep -i "PRI\|Span\|Yes  No" && asterisk -rx"core show channels" | grep -i "active channels"'_
> Example
> {noformat}
> Every 1.0s: asterisk -rx"pri show channels" | grep -i "PRI\|Span\|Yes  No" && asterisk -rx"core show channels" | grep -i "active...  Fri Mar 30 03:21:02 2012
> PRI	  B    Chan Call       PRI  Channel
> Span Chan Chan Idle Level      Call Name
>    1   19 Yes  No   Idle       No
> 0 active channels
> {noformat}
> *7. Debugging the data.*  
> If Asterisk shows 0 active channels and one of the B channels is in non-idle state, it means that Asterisk is unable to receive calls on that channel. 
> 7.1 Get a copy of the Asterisk logs (/var/log/asterisk/messages) 
> 7.2 Look for the last time that Asterisk sent a SETUP message to the telco
> 7.3 Using the call reference in the SETUP message track the PRI messages between the telco and Asterisk 
> 7.4 Determine if telco rejected the call and if Asterisk sent a RESTART (after the call rejection)
> 7.5 Check if the telco responded the restart request. 
> h3. Working around this issue / Solving the issue 
> We believe that the problem is caused by a bad behavior on the telco's switches, therefore users experiencing this issue should contact their telco and show the data. The telco should be able to determinate why their switches ignored the restart request. 
> In order to workaround or alleviate this issue we suggest:
> 1- Contact your telco and find out in which order their switches send the calls to Asteirsk. Call collisions should be minimized by allocating channels opposite from how the network allocates channels. If the network picks lower channels first for incoming calls then outgoing calls should pick higher channels first.
> 2- Increase the number of channels on your system. 
> 3- Restart Asterisk on specific intervals (once a day)
> {color:red} 
> *If you are Digium's customer with in-warranty card, please contact Digium Tech Support or Open a case using our web portal. We will do our best to provide assistance* 
> {color}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira