The variable index used in this scenario for accessing the dahdi_pvts was
wrong and was most likely copied from the several other places it is used
correctly.
(closes issue #15998)
Reported by: tsearle
Patches:
dahdi_reset_crash.patch uploaded by tsearle (license 373)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@222393 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After talking to rmudgett about some of his recent iflist locking changes, it
was determined that the only place that would destroy a channel without being
explicitly to do so was in handle_init_event. The loop to walk the interface
list has been modified to wait to destroy the channel until the dahdi_pvt of
the channel to be destroyed is no longer needed.
(closes issue #15378)
Reported by: samy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Issue 15655: For the case where dialing is complete for an incoming
call, dahdi_new() was asked to start the PBX and then the code set more
channel variables. If the dialplan hungup before these channel variables
got set, asterisk would likely crash.
* Fixed potential for overlap incoming call to erroneously set channel
variables as global dialplan variables if the ast_channel structure failed
to get allocated.
* Added missing set of CALLINGSUBADDR in the dialing is complete case.
(closes issue #15655)
Reported by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@210575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, a wildcard extension in the dialplan (for example, _*.) would take
precedence over picking up a call in the channel's pickup group. This patch simply moves
the block of code handling pickup group matching to above the extension matching code.
(closes issue #14735)
Reported by: stevedavies
Review: https://reviewboard.asterisk.org/r/319/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@210067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was already code for other signaling types in dahdi_handle_event to
handle dialing if a dial operation dial string was present. Simply add
SIG_EMWINK to the list.
(closes issue #14434)
Reported by: araasch
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new dahdi_wait function to specifically wait for the wink
event. If the wink is not eventually received the channel is hung up.
(closes issue #14434)
Reported by: araasch
Patches:
emwinkmod uploaded by araasch (license 693)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously overlap dialing could only be turned on or off for both incoming and
outgoing calls. New parameters incoming, outgoing, and both have been added to
allow further control. There is no change in default behavior with these new
options and allows in band DTMF to be accepted in one direction if required.
(closes issue #14471)
Reported by: eboscani
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add missing clearing of the dialing flag when the ISDN call is CONNECTED.
(i.e. When libpri generates the event PRI_EVENT_ANSWER.)
(closes issue #15420)
Reported by: scottbmilne
Patches:
bug15420-1.4.25.1-diff2.txt uploaded by alecdavis (license 585)
Tested by: scottbmilne, alecdavis
(closes issue #15416)
Reported by: avinoash
(closes issue #15389)
Reported by: alecdavis
This patch should also fix the following issue:
(issue #15205)
Reported by: vinsik
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205728 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Before this patch, Asterisk unconditionally picked B channels exclusively
on the CPE side and normally allowed alternative B channels on the network
side. Now Asterisk does the opposite.
Reasons for the CPE side to normally not pick B channels exclusively:
* For CPE point-to-multipoint mode (i.e. phone side), the CPE side does
not have enough information to exclusively pick B channels. (There may be
other devices on the line.)
* Q.931 gives preference to the network side picking B channels.
* Some telcos require the CPE side to not pick B channels exclusively.
(closes issue #14383)
Reported by: mbrancaleoni
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@203908 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valid format is: pritimer=timer_name,timer_value
* Fixed segfault if the ',' is missing.
* Completely check the range returned by pri_timer2idx() to prevent
possible access outside array bounds.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@203036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the caller ID is restricted, the expected behavior is for the caller id to be blank. In chan_dahdi, the national prefix is placed onto the callers number even if its restricted (empty) causing the caller id to be the national prefix rather than blank.
(closes issue #13207)
Reported by: shawkris
Patches:
national_prefix.diff uploaded by dvossel (license 671)
Review: http://reviewboard.digium.com/r/220/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Don't offer AST_FORMAT_SLINEAR on DAHDI/Zaptel channels... while it could provide a slight performance benefit, the translation core in Asterisk has some flaws when a channel driver offers multiple raw formats. this fix is much simpler than fixing the translation core to solve that issue (although that will be done later).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added doxygen comments to the major dahdi structures.
* Fixed PRI using an incorrect string value if the extension
delimiter is not present in the Dial() function.
* Fixed some uninitialized string variables on FXS ports.
configs/chan_dahdi.conf.sample
* Updated some documentation.
These changes are already in trunk -r172400
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@172962 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It has been discovered that if a channel is locked prior
to a call to ast_autoservice_stop, then it is likely that
a deadlock will occur. The reason is that the call to
ast_autoservice_stop has a check built into it to be sure
that the thread running autoservice is not currently trying
to manipulate the channel we are about to pull out of
autoservice.
The autoservice thread, however, cannot advance beyond where
it currently is, though, because it is trying to acquire
the lock of the channel for which autoservice is attempting
to be stopped.
The gist of all this is that a channel MUST NOT be locked
when attempting to stop autoservice on the channel.
In this particular case, the channel was locked by a call
to ast_read. A call to ast_exists_extension led to autoservice
being started and stopped due to the existence of dialplan
switches.
It may be that there are future commits which handle the same
symptoms but in a different location, but based on my looks through
the code, it is very rare to see a construct such as this one.
(closes issue #14057)
Reported by: rtrauntvein
Patches:
14057v3.patch uploaded by putnopvut (license 60)
Tested by: rtrauntvein
Review: http://reviewboard.digium.com/r/107/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@166380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug:
#ifdef HAVE_ZAPTEL
fd = open("/dev/zap/pseudo", O_RDWR);
#else
fd = open("/dev/dahdi/pseudo", O_RDWR);
#endif
is replaced with:
fd = open(DAHDI_FILE_PSEUDO, O_RDRW);
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@165991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
When compiling against Zaptel dahdi_compat will now only define all the DAHDI defines if the Zaptel define is present. Also, there is no such thing as DAHDI_PRI.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Don't always define HAVE_ZAPTEL_CHANALARMS (since we check if it's defined..)
Minor cleanup to make things clear.
(closes issue #13726)
Reported by: tzafrir
Patches:
dahdi_def.diff uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
Patches:
dahdi_close.diff uploaded by tzafrir (license 46)
Tested by: tzafrir, jpeeler
This patch fixes closing open file descriptors in the case of an error.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
buffers=<num of buffers>,<policy>
Where the number of buffers is some non-negative integer and the policy is either "full", "half", or "immediate".
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
