FXS lines normally connect to a telephone. However, when FXS lines are routed
to an external PBX or Key System to act as "external" or "CO" lines, it is
extremely difficult, if not impossible for the external PBX to know when
the call has been disconnected without receiving a polarity reversal on the line.
Now using answeronpolarityswitch and hanguponpolarityswitch keywords that
previously were used only for FXO ports, now applies like functionality for
an FXS port, but from the connected equipment's point of view.
(closes issue #17318)
Reported by: armeniki
Patches:
fxs_linepolarity.diff5.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/797/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "dahdi show channels" CLI command still reports the DNID of the
previous call even if the call is already hang up. The "dahdi show
channels" command of older releases clear the DNID once the channel is
hang up.
Regression from the sig_analog/sig_pri extraction from chan_dahdi.
(closes issue #17623)
Reported by: klaus3000
Patches:
issue17623.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes some cases of no outgoing calls on FXO before an incoming call.
Remove an unnecessary testing of an "off-hook" bit from DAHDI for FXO
(KS/GS) channels.In some cases the bit would not be initialized properly
before the first inbound call and thus prevent an outgoing call.
If those tests are actually required by anybody, they should define
DAHDI_CHECK_HOOKSTATE in channels/sig_analog.c .
(closes issue #14577)
Reported by: jkroon
Patches:
asterisk_chan_dahdi_hookstate_fix_trunk_new.diff uploaded by frawd (license 610)
Tested by: frawd
Review: https://reviewboard.asterisk.org/r/699/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue here is that passing an array to a function prohibits the ARRAY_LEN
macro from returning the real size. To avoid this the size is now defined and
use of ARRAY_LEN is avoided.
(closes issue #15718)
Reported by: alecdavis
Patches:
bug15718.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277419 | rmudgett | 2010-07-16 15:18:54 -0500 (Fri, 16 Jul 2010) | 15 lines
priexclusive in chan_dahdi.conf ignored when reloading dahdi module
During a reload, the priexclusive and outsignalling parameters are not
read in from the config file as intended. Unfortunately, they get set to
defaults as a result. This patch makes sure that they do not get set to
defaults during a reload.
(closes issue #17441)
Reported by: mtryfoss
Patches:
issue17441_v1.4.patch uploaded by rmudgett (license 664)
issue17441_v1.6.2.patch uploaded by rmudgett (license 664)
issue17441_trunk.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This small changes prevents destroy_all_channels() from accessing a lock on an
unused dahdi_pri struct, resolving a ton of ERRORs that get spewed out when
shutting Asterisk down gracefully.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling dahdi_indicate() within dahdi_fixup() while the owner pointers are
in a potentially inconsistent state is a potentially bad thing in
principle.
However, calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* chan_dahdi supports dialing configuring and dialing by device file name.
DAHDI/span-name!local!1 will use /dev/dahdi/span-name/local/1 . Likewise
it may appear in chan_dahdi.conf as 'channel => span-name!local!1'.
* A new options for chan_dahdi.conf: 'ignore_failed_channels'. Boolean.
False by default. If set, chan_dahdi will ignore failed 'channel' entries.
Handy for the above name-based syntax as it does not depend on
initialization order.
* have my_pri_make_cc_dialstring() only manupulate dial-strings of group
(gGrR) dialing, which make it lsightly more complicated.
https://reviewboard.asterisk.org/r/535/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Extract the SS7 specific code out of chan_dahdi like what was done to
ISDN/PRI and analog signaling. The new SS7 structures were modeled on
sig_pri.
The changes to sig_pri are an enhancement and a bug fix made possible
because SS7 was extracted.
1) The sig_pri TRANSFERCAPABILITY channel variable should have been set
unconditionally in sig_pri_new_ast_channel().
2) SS7/PRI transfer capability interaction in dahdi_new() fixed because of
SS7 extraction.
3) Module ref count error in dahdi_new() if startpbx failed to start the
PBX for some reason.
Review: https://reviewboard.asterisk.org/r/661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add the ability to announce a call to an endpoint when there are no B
channels available. A call waiting call is a SETUP message with no B
channel selected.
Relevant specification: EN 300 056, EN 300 057, EN 300 058
For DAHDI/ISDN channels, the CHANNEL() dialplan function now supports the
"no_media_path" option.
* Returns "0" if there is a B channel associated with the call.
* Returns "1" if no B channel is associated with the call. The call is
either on hold or is a call waiting call.
If you are going to allow incoming call waiting calls then you need to use
CHANNEL(no_media_path) do determine if you must drop a call to accept the
new call.
Review: https://reviewboard.asterisk.org/r/568/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added ability to send and receive ETSI Explicit Call Transfer (ECT)
messages to eliminate tromboned calls.
Note: Asterisk already supported initiating the transfer of calls to
eliminate tromboned calls to libpri so there was nothing to do for the
asterisk portion.
Review: https://reviewboard.asterisk.org/r/520/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Must do a deep copy of the cc_params in duplicate_pseudo(). Otherwise,
when the duplicate pseudo channel is destroyed, it frees the original
pseudo channel cc_params. The original pseudo channel is then left with a
dangling pointer for when the next duplicated pseudo channel is created.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262743 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CLI "dahdi show channel" command was not correctly reporting the
InAlarm status.
The inalarm flag is now consistently passed between chan_dahdi and
submodules.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260434 | jpeeler | 2010-04-30 17:22:46 -0500 (Fri, 30 Apr 2010) | 11 lines
Ensure channel state is not incorrectly set in the case of a very early answer.
The needringing bit was being read in dahdi_read after answering thereby
setting the state to ringing from up. This clears needringing upon answering
so that is no longer possible.
(closes issue #17067)
Reported by: tzafrir
Patches:
needringing.diff uploaded by tzafrir (license 46)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Created
SIG_PRI_MAX_CHANNELS, SIG_PRI_NUM_DCHANS
SIG_SS7_MAX_CHANNELS, SIG_SS7_NUM_DCHANS
SIG_MFCR2_MAX_CHANNELS
Also fixed the declaration of pollers[] in mfcr2_monitor(). It was
dimensioned to the number of bytes in struct dahdi_mfcr2.pvts[] and not to
the same dimension of the struct dahdi_mfcr2.pvts[].
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
DTMF CallerID detection problems.
The code handling DTMF CallerID drops digits on long CallerID numbers and
may timeout waiting for the first ring with shorter numbers.
The DTMF emulation mode was not turned off when processing DTMF CallerID.
When the emulation code gets behind in processing the DTMF digits it can
skip a digit.
For shorter numbers, the timeout may have been too short. I increased it
from 2 seconds to 4 seconds. Four seconds is a typical time between rings
for many countries.
(closes issue #16460)
Reported by: sum
Patches:
issue16460.patch uploaded by rmudgett (license 664)
issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
Tested by: sum, rmudgett
Review: https://reviewboard.asterisk.org/r/634/
JIRA SWP-562
JIRA AST-334
JIRA SWP-901
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260231 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259531 | rmudgett | 2010-04-27 16:53:07 -0500 (Tue, 27 Apr 2010) | 11 lines
DAHDI "WARNING" message is confusing and vague
"WARNING[28406]: chan_dahdi.c:6873 ss_thread: CallerID feed failed: Success"
Changed the warning to "Failed to decode CallerID on channel 'name'". The
message before it is likely more specific about why the CallerID decode
failed.
SWP-501
AST-283
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259270 | rmudgett | 2010-04-27 13:14:54 -0500 (Tue, 27 Apr 2010) | 14 lines
hidecalleridname parameter in chan_dahdi.conf
Issue #7321 implements a new chan_dahdi configuration option. However, a
change mentioned in the issue was never implemented. This is the change
that will allow the feature to work.
I added a note to chan_dahdi.conf.sample about the feature.
(closes issue #17143)
Reported by: djensen99
Patches:
diff.txt uploaded by djensen99 (license NA) (One line change)
Tested by: djensen99
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 1072 of libpri added SERVICE message support for the 'national'
switchtype. The attached patch enables the use of 'pri service' CLI commands
on dahdi channels that are configured for the 'national' switchtype.
(closes issue #17142)
Reported by: dhubbard
Patches:
dw-ni2.patch uploaded by dhubbard (license 733)
Tested by: elguero, dhubbard
Review: https://reviewboard.asterisk.org/r/612/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@257642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes some cases where the channel number for an ioctl was
passed as a member in a struct rather then through the file descriptor.
The gain setting functions passed around a channel which is always 0,
and thus this parameter is simply dropped.
Review: https://reviewboard.asterisk.org/r/584/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Rework HAVE_PRI_SERVICE_MESSAGES to not use the active values directly
from the database. Database access is likely expensive. Database access
now only happens on initialization, destruction, and when the B channel is
taken in or out of service.
This change is not related to call waiting but it would cause the search
for a call waiting interface to be very expensive and slow down D channel
message servicing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@251538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
Alec L Davis
Tzafrir Cohen
Jeff Peeler
Tilghman Lesher
Eliel C. Sardanons
Russell Bryant
Leif Madsen
Mark Michelson
Dwayne M. Hubbard
Moises Silva
David Vossel
Kevin P. Fleming
Matthew Nicholson