Only chan_dahdi set a value in cdrflags. Everyone else just copied it
around the system. Noone cared about any value it may have contained.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@250481 65c4cc65-6c06-0410-ace0-fbb531ad65f3
New config parameter "reportalarms" added in chan_dahdi.conf which supports the
following possible values:
"channels": report each channel alarms (current behavior, default for backward compatibility)
"spans": report an "SpanAlarm" event when the span of any configured channel is alarmed
"all": report channel and span alarms (aggregated behavior)
"none": do not report any alarms
(closes issue #16709)
Reported by: nahuelgreco
Patches:
chan_dahdi.c.reportalarms.patch uploaded by nahuelgreco (license 162)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@249893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ooops. Failed to note that we were inside a for loop and
pri_channel_bridge() needs to be executed only once.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the limit was set past MAX_INT upon answering, the call was immediately
hung up due to overflow from the return of ast_tvdiff_ms (in ast_check_hangup).
The time calculation functions ast_tvdiff_sec and ast_tvdiff_ms have been
changed to return an int64_t to prevent overflow. Also the reporter suggested
adding a message indicating the reason for the call hanging up. Given that the
new limit is so much higher, the message (which would only really be useful in
the overflow scenario) has been made a debug message only.
(closes issue #16006)
Reported by: viraptor
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@232091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the process of swapping ULAW to a place in the extended codec space, we
found several unhandled cases, where a 32-bit integer was still being used to
handle a codec field. Most of these have been fixed with this commit, although
there is at least one case (codec_dahdi) which depends upon outside headers to
be altered before a conversion can be made.
(Fixes AST-278, SWP-459)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changed areas in sig_pri to set the digital flag using a callback that will
also set the corresponding flag in chan_dahdi. Modified dahdi_request slightly
so that if a bearer is marked as digital, that information is available when
creating the new channel.
(closes issue #16151)
Reported by: alecdavis
Patch based on bug_16151.diff.txt uploaded by alecdavis (license 585)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Dial(DAHDI/g1[/extension[/options]])
Current options:
K(<keypad_digits>)
R Reverse charging indication (Collect calls)
The earlier Dial(DAHDI/g1[/K<keypad_digits>][/extension] format was
variable and did not allow for the easy addition of more options.
The earlier 'C' prefix character for reverse charge indiation would
conflict with the a-d DTMF digits if ISDN uses them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since ISDN works like SIP and not analog ports in regard to devices, the
device state based on the ISDN channel number could not work. This has
not been an issue until the advent of PTMP NT mode. Previously, ISDN
lines were used as trunks and did not have to keep track of specific
devices.
As an interim solution until device states are properly implemented, the
channel name is being changed to the following format to use the generic
device state support:
DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
Dialplan hints would thus be:
exten => xxx,hint,DAHDI/i2/5551212
This will work with the following restrictions:
* The number of devices/phones cannot exceed the number of B channels.
(i.e., BRI has 2)
* Each device/phone can only have one number. No shared MSN's.
* The phones/devices probably should not use subaddressing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Cleanup some flags on DAHDI PRI channel hangup. (sig_pri split)
* Make sure the outgoing flag is cleared if a new channel fails to get
created for outgoing calls.
* Remove some unused flags since sig_pri was split.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prefix PRI trace messages with the span number. This makes the trace
readable even when you have a multi-port device.
(closes issue #15054)
Reported by: tzafrir
Patches:
dahdi_pri_debug_spannum.diff uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added handling of received HOLD/RETRIEVE messages and the optional ability
to transfer a held call on disconnect similar to an analog phone.
* Added CallRerouting/CallDeflection support for Q.SIG, ETSI PTP, ETSI PTMP.
Will reroute/deflect an outgoing call when receive the message.
Can use the DAHDISendCallreroutingFacility to send the message for the
supported switches.
* Added ability to send/receive keypad digits in the SETUP message.
Send keypad digits in SETUP message: Dial(DAHDI/g1[/K<keypad_digits>][/extension])
Access any received keypad digits in SETUP message by: ${CHANNEL(keypad_digits)}
* Added support for BRI PTMP NT mode.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@224331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@222351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@222298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dahdievent_to_analogevent used a simple switch statement to convert DAHDI
event numbers to "ANALOG_*" event numbers. However "digit" events
(DAHDI_EVENT_PULSEDIGIT, DAHDI_EVENT_DTMFDOWN, DAHDI_EVENT_DTMFUP)
are accompannied by the digit in the low word of the event number.
This fix makes dahdievent_to_analogevent() return the event number as-is
for such an event.
This is also required to fix#15924 (in addition to r222108).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reported bug was actually only for pulsedigit, dtmfup, and dtmfdown
handling. Also added recognition for fax events (just some verbose output) and
fixed handling for the ec_disabled_event. In order to make comparing the analog
version of events to the DAHDI events easier, the ordering has been changed to
follow that of the DAHDI events.
(closes issue #15924)
Reported by: tzafrir
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PRI channels can no longer change the channel name if a different B
channel is selected during call negotiation. To prevent using the channel
name to infer what B channel a call is using and to avoid name collisions,
the channel name format is changed.
The new channel naming for PRI channels is:
DAHDI/ISDN-<span>-<sequence-number>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remove thread_spawned in handle_init_event since it was never used
* Always check handle_init_event in case a channel is destroyed
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218583 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@218430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed walking the iflist so it is always done with the iflock locked.
* Simplified iflist walking routines.
* Created chan_dahdi iflist insertion and extraction routines.
* Fixed duplicate_pseudo() malloc fail handling.
* Fixed infinite loop in action_dahdishowchannels() when showing a single channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes the problem that would occur if an analog phone was picked up while
the caller id was being sent. The caller id before sent the whole spill even
after pickup and is now corrected.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Jeff Peeler
David Vossel
Alec L Davis
Moises Silva
Tilghman Lesher
Kevin P. Fleming
Tzafrir Cohen
Matthew Nicholson