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
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r262660 | rmudgett | 2010-05-12 11:46:47 -0500 (Wed, 12 May 2010) | 4 lines
Forgot some conditionals around the callrerouting facility help text.
JIRA ABE-2223
..........
r262657 | rmudgett | 2010-05-12 11:26:49 -0500 (Wed, 12 May 2010) | 22 lines
Add mISDN Call rerouting facility for point-to-point ISDN lines (exchange line)
In the case of ISDN point-to-multipoint (multidevice) you can use the
mISDN "facility calldeflect" application for call diversions from external
(PSTN) to external (PSTN). In that case this is the only way to get rid
of the two call legs to the PBX and let the calling number at the C party
become the number of the A party. In the case of ISDN point-to-point
(exchange line) the call deflection facility may not be used. Instead a
call rerouting facility has to be used.
This patch for chan_misdn.c is an extension to realize this service
(facility rerouting application). It can accept either spelling:
"callrerouting" or "callrerouteing".
The patch is tested towards Deutsche Telekom and requires a modified
version of mISDN from Digium, Inc.
Patches:
misdn_rerouteing_corrected.patch (Slightly modified.)
JIRA ABE-2223
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r247910 | rmudgett | 2010-02-19 11:18:49 -0600 (Fri, 19 Feb 2010) | 55 lines
Merged revision 247904 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
r247904 | rmudgett | 2010-02-19 10:49:44 -0600 (Fri, 19 Feb 2010) | 49 lines
Make chan_misdn DTMF processing consistent with other channel technologies.
The processing of DTMF tones on the receiving side of an ISDN channel is
inconsistent with the way it is handled in other channels, especially
DAHDI analog. This causes DTMF tones sent from an ISDN phone to be
doubled at the connected party.
We are using the following 2 options of misdn.conf
1) astdtmf=yes
2) senddtmf=yes
Option one is necessary because the asterisk DSP DTMF detection is better
than mISDN's internal DSP. Not as many false positives.
Option two is necessary to transmit DTMF tones end to end when mISDN
channels are connected to SIP channels with out of band DTMF for example.
The symptom is that DTMF tones sent by an ISDN phone are doubled on the
way through asterisk when two mISDN channels are connected with a Local
channel in between or if it is bridged to an analog channel.
The doubling of DTMF tones is because DTMF is passed inband to asterisk by
the mISDN channel and passed out of band once again after the release of
the DTMF tone. Passing it inband is wrong. Neither an analog channel nor
SIP channel passes DTMF inband if configured to inband DTMF. Analog and
SIP channels filter out the DTMF tones because they use the voice frames
returned by ast_dsp_process. But chan_misdn passes the unfiltered input
voice frames instead.
To overcome one aspect of the problem, the doubling of DTMF tones when two
mISDN channels are directly bridged, someone made an 'optimization', where
in that case the DTMF tone passed out-of-band to the peer channel is not
translated to an inband tone at the transmit side. This optimization is
bad because it does not work in general. For example, analog channels or
mISDN channels when bridged through an intermediary local channel will
generate DTMF tones from out-of-band information. Also, of course, it
must not be done when there is no inband DTMF available.
This patch fixes the issue. Now chan_misdn will filter the received
inband DTMF signal the same as other channel types.
Another change included: No need to build an extra translation path
because ast_process_dsp does it if required.
Patches:
misdn-dtmf.patch
JIRA ABE-2080
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r228078 | dbrooks | 2009-11-05 12:59:41 -0600 (Thu, 05 Nov 2009) | 9 lines
chan_misdn Asterisk 1.4.27-rc2 crash
Crash related to chan_misdn connection. Patch submitted by gknispel_proformatique, tested
by francesco_r. "I have many crash since i have upgraded to Asterisk 1.4.27-rc2. Attached
a full bt." This patch zeros out an ast_frame.
(closes issue #16041)
Reported by: francesco_r
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@228145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channels are stored in an ao2_container. When accessing an item within
an ao2_container the proper locking order is to first lock the container,
and then the items within it.
In ast_do_masquerade both the clone and original channel must be locked
for the entire duration of the function. The problem with this is that
it attemptes to unlink and link these channels back into the ao2_container
when one of the channel's name changes. This is invalid locking order as
the process of unlinking and linking will lock the ao2_container while
the channels are locked!!! Now, both the channels in do_masquerade are
unlinked from the ao2_container and then locked for the entire function.
At the end of the function both channels are unlocked and linked back
into the container with their new names as hash values.
This new method of requiring all channels and tech pvts to be unlocked
before ast_do_masquerade() or ast_change_name() required several
changes throughout the code base.
(closes issue #15911)
Reported by: russell
Patches:
masq_deadlock_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel, atis
(closes issue #15618)
Reported by: lmsteffan
Patches:
deadlock_local_attended_transfers_trunk.diff uploaded by dvossel (license 671)
Tested by: lmsteffan, dvossel
Review: https://reviewboard.asterisk.org/r/387/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222691 | rmudgett | 2009-10-07 16:51:24 -0500 (Wed, 07 Oct 2009) | 14 lines
chan_misdn.c:process_ast_dsp() memory leak
misdn.conf: astdtmf must be set to "yes". With "no", buffer loss does not
occur.
The translated frame "f2" when passing through ast_dsp_process() is not
freed whenever it is not used further in process_ast_dsp(). Then in the
end it is never ever freed.
Patches:
translate.patch
JIRA ABE-1993
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ETSI 300-196 implies that a facility return result without arguments does
not have the operation-value. This fact implies for ETSI that you can
only use the invoke-id to match requests with responses.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209759 | kpfleming | 2009-07-31 19:52:00 -0500 (Fri, 31 Jul 2009) | 7 lines
Minor changes inspired by testing with latest GCC.
The latest GCC (what will become 4.5.x) has a few new warnings, that in these
cases found some either downright buggy code, or at least seriously poorly
designed code that could be improved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
r207316 | rmudgett | 2009-07-17 23:05:05 -0500 (Fri, 17 Jul 2009) | 20 lines
Fixed incoming calls being matched to MSNs without type-of-number prefix added.
For an incoming ISDN call the dialed.number is incorrectly matched against
the configured MSNs in misdn.conf. The numbers passed to the dialplan
include the configured prefix for the dialed.number_type, whereas the
check against the configured MSNs (to decide if the call is accepted at
all), is executed without the configured prefix.
e.g., dialed.number = 241168020, TON = national, configured national
prefix is "0". (This is the TON which is used by ISDN providers in the
Netherlands.)
In chan_misdn.c:cb_events() in case EVENT_SETUP the call to
misdn_cfg_is_msn_valid() uses the unnormalized number 241168020, but 57
lines later the call to read_config() adds the prefix, and the
dialed.number is now 0241168020, which is then used in the dialplan.
misdn_cfg_is_msn_valid() must use the normalized number, too.
JIRA ABE-1912
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206487 | rmudgett | 2009-07-14 11:44:47 -0500 (Tue, 14 Jul 2009) | 28 lines
Fixes several call transfer issues with chan_misdn.
* issue #14355 - Crash if attempt to transfer a call to an application.
Masquerade the other pair of the four asterisk channels involved in the
two calls. The held call already must be a bridged call (not an
applicaton) or it would have been rejected.
* issue #14692 - Held calls are not automatically cleared after transfer.
Allow the core to initate disconnect of held calls to the ISDN port. This
also fixes a similar case where the party on hold hangs up before being
transferred or taken off hold.
* JIRA ABE-1903 - Orphaned held calls left in music-on-hold.
Do not simply block passing the hangup event on held calls to asterisk
core.
* Fixed to allow held calls to be transferred to ringing calls.
Previously, held calls could only be transferred to connected calls.
* Eliminated unused call states to simplify hangup code.
* Eliminated most uses of "holded" because it is not a word.
(closes issue #14355)
(closes issue #14692)
Reported by: sodom
Patches:
misdn_xfer_v14_r205839.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204834 | rmudgett | 2009-07-02 16:59:43 -0500 (Thu, 02 Jul 2009) | 10 lines
Removed confusing warning message "Got Busy in Connected State"
If an incoming mISDN call is answered with the Answer application and a
subsequent Dial gets a busy endpoint then it is valid for that already
connected channel to get the busy indication. Asterisk will play the busy
tones until the dialplan plays something else or hangs up the call.
(closes issue #11974)
Reported by: fvdb
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the outgoing_colp parameter is set to not send COLP information, then
it does not make sense to send redirecting or transfer messages announcing
new COLP information that is blocked. The service provider may supply the
listed number for that line when it passes the messages to the next hop.
Why tell the switch that these events happened when the information is
otherwise suppressed?
Also blocked the number of previous redirects that may have occurred to
calls going out the port when outgoing_colp is 2.
Follow on to JIRA ABE-1853.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These modules all contained variables that are module-global but not system-global,
but were not marked 'static'.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes:
- CLI command handlers
- CLI command handler arguments
- AGI command handlers
- AGI command handler arguments
- Dialplan application handler arguments
- Speech engine API function arguments
In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing.
Review: https://reviewboard.asterisk.org/r/251/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Select what to do with outgoing COLP information on this port.
0 - Send out COLP information unaltered. (default)
1 - Force COLP to restricted on all outgoing COLP information.
2 - Do not send COLP information.
outgoing_colp=0
Also fixed sending the EctInform message so it always has the
required redirectionNumber parameter when the status is active.
JIRA ABE-1853
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193613 | rmudgett | 2009-05-11 14:09:00 -0500 (Mon, 11 May 2009) | 12 lines
Sent wrong message to clear a call we started if the other end has not responed yet.
In the state MISDN_CALLING (i.e. SETUP was sent but no answer has arrived yet),
it is not allowed to clear the call with RELEASE_COMPLETE. It must be
cleared with DISCONNECT. A RELEASE_COMPLETE is only allowed as an answer
to a SETUP. (See Q.931 ch. 5.3.2, 5.3.2.a, 5.3.2.b)
Patches:
chan-misdn-ccstate7.patch uploaded by customer.
JIRA ABE-1862
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@193614 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193050 | rmudgett | 2009-05-07 17:17:06 -0500 (Thu, 07 May 2009) | 5 lines
Give a more helpful message when an incoming call's dialed extension does not match.
Added the dialed extension and context to the chan_misdn messages warning
that the dialed number cannot be matched in the dialplan.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@193077 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For outgoing PTP redirected calls, you now need to use the inhibit(i)
option on all of the REDIRECTING statements before dialing the redirected-to
party. You still have to set the REDIRECTING(to-xxx,i) and the
REDIRECTING(from-xxx,i) values. The PTP call will update the redirecting-to
presentation when it becomes available and queue the redirecting update to
the calling channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Wait for a DivertingLegInformation3 message after receiving a
DivertingLegInformation1 message to complete the redirecting-to information
before queuing a redirecting update to the other channel.
* A DivertingLegInformation2 message should be responded to with a
DivertingLegInformation3 when the COLR is determined. If the call
could or does experience another redirection, you should manually
determine the COLR to send to the switch by setting REDIRECTING(to-pres)
to the COLR and setting REDIRECTING(to-num) = ${EXTEN}.
* A DivertingLegInformation2 message must have an original called number
if the redirection count is greater than one. Since Asterisk does
not keep track of this information, we can only indicate that the
number is not available due to interworking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The messages sent by a technology when a connected line update is received
are best determined by the current call state of the channel. The struct
ast_party_connected_line.source value is really only useful as a possible
tracing aid.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The channel drivers which have been most heavily tested with these enhancements are
chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
introduced in a later commit. chan_skinny has code added to it here, but according
to user pj, the support on chan_skinny is not working as of now. This will be fixed in
a later commit.
A special thanks goes out to bugtracker user gareth for getting the ball rolling and
providing the initial support for this work. Without his initial work on this, this would
not have been nearly as painless as it was.
This functionality has been tested by Digium's product quality department, as well as a
customer site running thousands of calls every day. In addition, many many many many bugtracker
users have tested this, too.
(closes issue #8824)
Reported by: gareth
Review: http://reviewboard.digium.com/r/201
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes a number of changes to the indications API. The primary
motivation for this work was to improve stability. The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.
The changes included are:
1) Remove the module res_indications. This included the critical functionality
that actually loaded the indications configuration. I have seen many people
have Asterisk problems because they accidentally did not have an
indications.conf present and loaded. Now, this code is in the core,
and Asterisk will fail to start without indications configuration.
There was one part of res_indications, the dialplan applications, which did
belong in a module, and have been moved to a new module, app_playtones.
2) Object management has been significantly changed. Tone zones are now
managed using astobj2, and it is no longer possible to crash Asterisk by
issuing a reload that destroys tone zones while they are in use.
3) The API documentation has been filled out.
4) The API has been updated to follow our naming conventions.
5) Various bits of code throughout the tree have been updated to account
for the API update.
6) Configuration parsing has been mostly re-written.
7) "Code cleanup"
The code is from svn/asterisk/team/russell/indications/.
Review: http://reviewboard.digium.com/r/149/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
------------------------------------------------------------------------
r159808 | kpfleming | 2008-11-29 10:58:29 -0600 (Sat, 29 Nov 2008) | 7 lines
update dev-mode compiler flags to match the ones used by default on Ubuntu Intrepid, so all developers will see the same warnings and errors
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
------------------------------------------------------------------------
in addition:
move some format attributes from main/utils.c to the header files they belong in, and fix up references to the relevant functions based on new compiler warnings
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
