kenmirrors/asterisk
1
0
Fork 0
mirror of https://github.com/asterisk/asterisk.git synced 2025-10-26 06:26:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option.

Browse Source 
Some telco switches occasionally ignore ISDN RESTART requests.  The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request.  If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco.  The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.

chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code.  Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards.  I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.

* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.

ASTERISK-25034 #close
Reported by: Richard Mudgett

Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65
This commit is contained in:
Richard Mudgett
2015-04-29 14:29:10 -05:00
committed by Joshua Colp
parent 37a193da18
commit d3c310a28c
5 changed files with 29 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
configs/samples/chan_dahdi.conf.sample
View File

@@ -196,6 +196,20 @@ context=public
;
;resetinterval = 3600
;
; Enable per span to force a RESTART on a channel that returns a cause
; code of PRI_CAUSE_REQUESTED_CHAN_UNAVAIL(44). If the cause is because
; of a stuck channel on the peer and the channel is always the next
; channel we pick for an outgoing call then this might help.
;
; NOTE: Sending a RESTART in response to a cause 44 is not required
; (nor prohibited) by the standards and is likely a primitive chan_dahdi
; response to call collisions (glare) and buggy peers. However, there
; are telco switches out there that ignore the RESTART and continue to
; send calls to the channel in the restarting state.
; Default yes in current release branches for backward compatibility.
;
;force_restart_unavailable_chans=yes
;
; Assume inband audio may be present when a SETUP ACK message is received.
; Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
; dialtone is sent from the network side, progress indicator 8 "Inband info