https://origsvn.digium.com/svn/asterisk/trunk
................
r250481 | jpeeler | 2010-03-03 13:06:06 -0600 (Wed, 03 Mar 2010) | 22 lines
Merged revisions 250480 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
Make sure to clear red alarm after polarity reversal.
From the issue:
The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
a red alarm on a dahdi / TDM400P connected channel. This is because the line
uses voltage tests (battery loss) and polarity reversal. The polarity reversal
causes chan_dahdi to initiate v23 CallerID processing but during this the event
DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
(closes issue #14163)
Reported by: jedi98
Patches:
chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
Tested by: mattbrown, Chainsaw, mikeeccleston
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@250483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines
fixes adaptive jitterbuffer configuration
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@249896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.
Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.
Verified that our local TELCO also does the same.
(issue #16789)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@249363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r244505 | tilghman | 2010-02-03 12:34:29 -0600 (Wed, 03 Feb 2010) | 8 lines
The chanvar= setting should inherit the entire list of variables, not just the first one.
(closes issue #16359)
Reported by: raarts
Patches:
dahdi-setvars.diff uploaded by raarts (license 937)
Tested by: raarts
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@244507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r232091 | jpeeler | 2009-12-01 18:45:18 -0600 (Tue, 01 Dec 2009) | 17 lines
Merged revisions 232090 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r232090 | jpeeler | 2009-12-01 18:42:58 -0600 (Tue, 01 Dec 2009) | 10 lines
Do not modify the gain settings on data calls.
(The digital flag actually represents a data call.)
(closes issue #15972)
Reported by: udosw
Patches:
transcap_digital_fix.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@232093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r224331 | jpeeler | 2009-10-16 20:36:08 -0500 (Fri, 16 Oct 2009) | 20 lines
Merged revisions 224330 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224330 | jpeeler | 2009-10-16 20:32:47 -0500 (Fri, 16 Oct 2009) | 13 lines
Fix stale caller id data from being reported in AMI NewChannel event
The problem here is that chan_dahdi is designed in such a way to set
certain values in the dahdi_pvt only once. One of those such values
is the configured caller id data in chan_dahdi.conf. For PRI, the
configured caller id data could be overwritten during a call. Instead
of saving the data and restoring, it was decided that for all non-analog
channels it was simply best to not set the configured caller id in the
first place and also clear it at the end of the call.
(closes issue #15883)
Reported by: jsmith
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@224333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r224261 | rmudgett | 2009-10-16 15:40:57 -0500 (Fri, 16 Oct 2009) | 25 lines
Merged revisions 224260 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224260 | rmudgett | 2009-10-16 15:25:23 -0500 (Fri, 16 Oct 2009) | 18 lines
Never released PRI channels when using Busy() or Congestion() dialplan apps.
When the Busy() or Congestion() application is used towards ISDN (an ISDN
progress is sent), the responding ISDN Disconnect or Release may contain
the ISDN cause user busy or one of the congestion causes. In chan_dahdi.c
these causes will only set the needbusy or needcongestion flags and not
activate the softhangup procedure. Unfortunately only the latter can
interrupt the endless wait loop of Busy()/Congestion().
Result: PRI channels staying in state busy for the rest of asterisk life
or until the other end times out and forces the call to clear.
(in issue 0014292)
Reported by: tomaso
Patches:
disc_rel_userbusy.patch uploaded by tomaso (license 564)
(This patch is unrelated to the issue.)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@224263 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is the simplest way to solve a problem that has already been solved
in trunk with the "COLP/CONP and Redirecting party information into Asterisk"
commit. In trunk the redirection reason is translated into a generic redirect
reason. I would have had to do the same fix except chan_sip never reads
PRIREDIRECTREASON. So both chan_dahdi and chan_h323 have been modified to
interpret the one different redirect reason of "no-answer" properly and set the
ISDN reason code 2 of "no reply".
(closes issue #15033)
Reported by: steinwej
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@223405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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)
Modified:
branches/1.4/channels/chan_dahdi.c
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@222396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222351 | jpeeler | 2009-10-06 15:35:19 -0500 (Tue, 06 Oct 2009) | 9 lines
Fix 222298 (crash during destruction of second channel when variable set with
setvar).
I mistakenly reasoned that setvar would be used on all channels. Since it can
be set per channel, give each dahdi channel a copy of the variable.
(related to #15899)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@222353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222298 | jpeeler | 2009-10-06 14:24:59 -0500 (Tue, 06 Oct 2009) | 9 lines
Fix crash during destruction of second channel when variable set with setvar.
The setvar line in chan_dahdi.conf is shared among all the channels, so make
sure to only free the resources only when the last channel is destroyed.
(closes issue #15899)
Reported by: tzafrir
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@222303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r218430 | jpeeler | 2009-09-14 17:38:25 -0500 (Mon, 14 Sep 2009) | 18 lines
Merged revisions 218401 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218401 | jpeeler | 2009-09-14 16:47:11 -0500 (Mon, 14 Sep 2009) | 11 lines
Fix handling of DAHDI_EVENT_REMOVED event to prevent crash in do_monitor.
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.6.1@218569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r210640 | rmudgett | 2009-08-05 14:40:03 -0500 (Wed, 05 Aug 2009) | 21 lines
Merged revisions 210575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210575 | rmudgett | 2009-08-05 14:18:56 -0500 (Wed, 05 Aug 2009) | 14 lines
Dialplan starts execution before the channel setup is complete.
* 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.6.1@210681 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.6.1@207637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205728 | rmudgett | 2009-07-09 18:37:53 -0500 (Thu, 09 Jul 2009) | 21 lines
No audio on calls from Asterisk to various ISDN devices until DTMF sent by caller.
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.6.1@205730 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r203909 | rmudgett | 2009-06-26 20:07:52 -0500 (Fri, 26 Jun 2009) | 23 lines
Merged revisions 203908 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203908 | rmudgett | 2009-06-26 19:55:12 -0500 (Fri, 26 Jun 2009) | 16 lines
The ISDN CPE side should not exclusively pick B channels normally.
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.6.1@203918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r203672 | jpeeler | 2009-06-26 14:03:25 -0500 (Fri, 26 Jun 2009) | 16 lines
Check if polarityonanswerdelay has elapsed before setting a channel as answered
after a polarity reversal.
Previously on a polarity switch event chan_dahdi would set the channel
immediately as answered. This would cause problems if a polarity reversal
occurred when the line was picked up as the dial would not have yet occurred.
Now if the polarity reversal occurs before delay has elapsed after coming off
hook or an answer, it is ignored. Also, some refactoring was done in
_handle_event.
(closes issue #13917)
Reported by: alecdavis
Patches:
chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@203700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r203258 | qwell | 2009-06-25 14:22:46 -0500 (Thu, 25 Jun 2009) | 10 lines
Unmute when we get a dtmfup (we muted on dtmfdown) event.
This would occasionally cause one-way audio when using hardware DTMF detection.
(closes issue #14761)
Reported by: tzafrir
Patches:
v1-14761.patch uploaded by dimas (license 88)
Tested by: tzafrir, dimas
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@203274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r203037 | rmudgett | 2009-06-24 16:08:55 -0500 (Wed, 24 Jun 2009) | 15 lines
Merged revisions 203036 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203036 | rmudgett | 2009-06-24 16:01:43 -0500 (Wed, 24 Jun 2009) | 8 lines
Improved chan_dahdi.conf pritimer error checking.
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.6.1@203057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r199227 | mmichelson | 2009-06-05 08:51:08 -0500 (Fri, 05 Jun 2009) | 14 lines
Correct "dahdi show channels" output when specifying a group.
Since a DAHDI channel may belong to multiple groups, we need to use
a bitwise and instead of equivalence to determine whether to display
the channel information.
(closes issue #15248)
Reported by: gentian
Patches:
15248.patch uploaded by mmichelson (license 60)
Tested by: gentian
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@199229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r188647 | dvossel | 2009-04-15 17:10:04 -0500 (Wed, 15 Apr 2009) | 18 lines
Merged revisions 188646 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r188646 | dvossel | 2009-04-15 17:08:40 -0500 (Wed, 15 Apr 2009) | 12 lines
National prefix inserted even when caller ID not available
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.6.1@188649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r186461 | kpfleming | 2009-04-03 15:20:01 -0500 (Fri, 03 Apr 2009) | 11 lines
Merged revisions 186458 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186458 | kpfleming | 2009-04-03 15:19:20 -0500 (Fri, 03 Apr 2009) | 5 lines
Fix a bug where DAHDI/Zaptel channels would not properly switch formats when requested
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.6.1@186466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185953 | kpfleming | 2009-04-02 08:51:44 -0500 (Thu, 02 Apr 2009) | 11 lines
Merged revisions 185952 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185952 | kpfleming | 2009-04-02 08:43:43 -0500 (Thu, 02 Apr 2009) | 5 lines
the DAHDI_GETCONF, DAHDI_SETCONF and DAHDI_GET_PARAMS ioctls were recently corrected to show that they do, in fact, read data from userspace as part of their work. due to this fix, valgrind now reports a number of cases where chan_dahdi passed an uninitialized (or partially) buffer to these ioctls, which could lead to unexpected behavior.
this patch corrects chan_dahdi to ensure that buffers passed to these ioctls are always fully initialized.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@185956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184339 | russell | 2009-03-25 16:57:19 -0500 (Wed, 25 Mar 2009) | 35 lines
Improve performance of the ast_event cache functionality.
This code comes from svn/asterisk/team/russell/event_performance/.
Here is a summary of the changes that have been made, in order of both
invasiveness and performance impact, from smallest to largest.
1) Asterisk 1.6.1 introduces some additional logic to be able to handle
distributed device state. This functionality comes at a cost.
One relatively minor change in this patch is that the extra processing
required for distributed device state is now completely bypassed if
it's not needed.
2) One of the things that I noticed when profiling this code was that a
_lot_ of time was spent doing string comparisons. I changed the way
strings are represented in an event to include a hash value at the front.
So, before doing a string comparison, we do an integer comparison on the
hash.
3) Finally, the code that handles the event cache has been re-written.
I tried to do this in a such a way that it had minimal impact on the API.
I did have to change one API call, though - ast_event_queue_and_cache().
However, the way it works now is nicer, IMO. Each type of event that
can be cached (MWI, device state) has its own hash table and rules for
hashing and comparing objects. This by far made the biggest impact on
performance.
For additional details regarding this code and how it was tested, please see the
review request.
(closes issue #14738)
Reported by: russell
Review: http://reviewboard.digium.com/r/205/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@184342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r174041 | file | 2009-02-06 15:28:53 -0400 (Fri, 06 Feb 2009) | 4 lines
Don't subscribe to a mailbox on pseudo channels. It is futile. This solves an issue where duplicated pseudo channels would cause a crash because the first one would unsubscribe and the next one would also try to unsubscribe the same subscription.
(closes issue #14322)
Reported by: amessina
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
