https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r315446 | russell | 2011-04-26 12:40:23 -0500 (Tue, 26 Apr 2011) | 14 lines
chan_local: resolve a deadlock.
This patch resolves a fairly complex deadlock that can occur with the
combination of chan_local and a dialplan switch, such as dynamic realtime
extensions, which pulls autoservice into the picture when doing a dialplan
lookup.
(closes issue #18818)
Reported by: nic
Patches:
issue18818.patch uploaded by jthurman (license 614)
18818.v1.txt uploaded by russell (license 2)
Tested by: nic, jthurman, kterzi, steve-howes, sysreq, IshMalik
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r306127 | twilson | 2011-02-03 13:03:26 -0800 (Thu, 03 Feb 2011) | 23 lines
Merged revisions 306126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r306126 | twilson | 2011-02-03 12:56:00 -0800 (Thu, 03 Feb 2011) | 16 lines
Merged revisions 306119 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r306119 | twilson | 2011-02-03 12:36:34 -0800 (Thu, 03 Feb 2011) | 9 lines
Set hangup cause in local_hangup
When a call involves a local channel (like SIP -> Local -> SIP), the hangup
cause was not being set. This resulted in SIP channels sometimes getting a
503 error instead of a 486 when the far side sent a busy. In Asterisk 1.8+
this also can cause issues with CCSS that involve a local channel. This patch
sets the hangupcause for one side of the local channel to the other in
local_hangup for outbound calls.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306128 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r302412 | seanbright | 2011-01-19 10:31:39 -0500 (Wed, 19 Jan 2011) | 10 lines
Use appropriate type for requested format in chan_local.
We were passing and storing the requested format as an int instead of format_t
resulting in truncation.
(closes issue #18238)
Reported by: whizemen
Patches:
0018238_speex16.patch uploaded by whizemen (license 1143)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292868 | dvossel | 2010-10-25 14:07:50 -0500 (Mon, 25 Oct 2010) | 39 lines
Merged revisions 292867 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r292867 | dvossel | 2010-10-25 14:06:21 -0500 (Mon, 25 Oct 2010) | 32 lines
Merged revisions 292866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r292866 | dvossel | 2010-10-25 14:05:07 -0500 (Mon, 25 Oct 2010) | 27 lines
This patch turns chan_local pvts into astobj2 objects.
chan_local does some dangerous things involving deadlock avoidance.
tech_pvt functions like hangup and queue_frame are provided with a
locked channel upon entry. Those functions are completely safe as
long as you don't attempt to give up that channel lock, but that is
impossible to guarantee due to the required deadlock avoidance necessary
to lock both the tech_pvt and both channels involved.
In the past, we have tried to account for this by doing things like
setting a "glare" flag that indicates what function should destroy the
pvt. This was used in local_hangup and local_queue_frame to decided
who should destroy the pvt if they collided in separate threads. I
have removed the need to do this by converting all chan_local tech_pvts
to astobj2. This means we can ref a pvt before deadlock avoidance
and not have to worry about that pvt possibly getting destroyed under
us. It also cleans up where we destroy the tech_pvt. The only unlink
from the tech_pvt container occurs in local_hangup now, which is where
it should occur.
Since there still may be thread collisions on some functions like
local_hangup after deadlock avoidance, I have added some checks to detect
those collisions and exit appropriately. I think this patch is going to
solve quite a bit of weirdness we have had with local channels in the past.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286189 | twilson | 2010-09-10 17:04:53 -0500 (Fri, 10 Sep 2010) | 30 lines
Merged revisions 286115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286115 | twilson | 2010-09-10 15:35:25 -0500 (Fri, 10 Sep 2010) | 23 lines
Merged revisions 286059 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286059 | twilson | 2010-09-10 14:25:08 -0500 (Fri, 10 Sep 2010) | 16 lines
Inherit CHANNEL() writes to both sides of a Local channel
Having Local (/n) channels as queue members and setting the language in the
extension with Set(CHANNEL(language)=fr) sets the language on the Local/...,2
channel. Hold time report playbacks happen on the Local/...,1 channel and
therefor do not play in the specified language.
This patch modifies func_channel_write to call the setoption callback and pass
the CHANNEL() write info to the callback. chan_local uses this information to
look up the other side of the channel and apply the same changes to it.
(closes issue #17673)
Reported by: Guggemand
Review: https://reviewboard.asterisk.org/r/903/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281429 | jpeeler | 2010-08-09 15:43:54 -0500 (Mon, 09 Aug 2010) | 27 lines
Merged revisions 281391 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r281391 | jpeeler | 2010-08-09 15:07:29 -0500 (Mon, 09 Aug 2010) | 20 lines
Merged revisions 281390 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281390 | jpeeler | 2010-08-09 15:04:30 -0500 (Mon, 09 Aug 2010) | 13 lines
Prevent loss of Caller ID information set on local channel after masquerade.
Caller ID set on the channel before a masquerade occurs when using a local
channel would cause the information to be lost. The problem was that the
information was set on a channel destined to be hung up. The somewhat confusing
fix is to detect if any Caller ID has been set on the channel and if so
preswap the Caller ID data so that basically the masquerade puts the data back.
(closes issue #17138)
Reported by: kobaz
Review: https://reviewboard.asterisk.org/r/847/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r280307 | mnicholson | 2010-07-29 08:56:35 -0500 (Thu, 29 Jul 2010) | 11 lines
Merged revisions 280306 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r280306 | mnicholson | 2010-07-29 08:45:11 -0500 (Thu, 29 Jul 2010) | 2 lines
Implement support for ast_channel_queryoption on local channels. Currently only AST_OPTION_T38_STATE is supported.
ABE-2229
Review: https://reviewboard.asterisk.org/r/813/
........
Additionally, pass AST_CONTROL_T38_PARAMETERS control frames through generic bridges. This change appears to have been unintentionally left out of rev 203699.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280308 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
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/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Call completion code tries to grab the call completion parameters
from the requesting channel during local_request. When originating
a call to a local channel, however, this channel is NULL. This
was causing an issue for me when trying to run a test script.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256646 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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r256014 | russell | 2010-04-02 18:45:56 -0500 (Fri, 02 Apr 2010) | 9 lines
Resolve a deadlock that occurs due to a pointless call to ast_bridged_channel()
(closes issue #16840)
Reported by: bzing2
Patches:
patch.txt uploaded by bzing2 (license 902)
issue_16840.rev1.diff uploaded by russell (license 2)
Tested by: bzing2, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256015 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
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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r249536 | jpeeler | 2010-03-01 11:02:03 -0600 (Mon, 01 Mar 2010) | 11 lines
Modify queued frames from local channels to not set the other side to up
In this case, attended transfers were broken due to ast_feature_request_and_dial
detecting the channel being set to up before the answer frame could be read and
therefore failing to mark the channel as ready. This fix is a regression fix for
244785, which should continue to work properly as well.
(closes issue #16816)
Reported by: jamhed
Tested by: jamhed, corruptor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@249538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously local channels channel state never changed. This became problematic
when the state of the other side of the local channel was lost, for example
during a masquerade. Changing the state of the local channel allows for the
scenario to be detected when the channel state is set to ringing, but the peer
isn't ringing. The specific problem scenario is described in 164201. Although
this was noted on one of the issues, here is the tested dialplan verified to
work:
exten => 9700,1,Dial(Local/*9700@default&Local/0009700@default)
exten => *9700,1,Set(GLOBAL(TESTCHAN)=${CHANNEL:0:${MATH(${LEN(${CHANNEL})}-1):0:2}}1)
exten => *9700,n,wait(3) ;3 works, 1 did not
exten => *9700,n,Dial(SIP/5001)
exten => 0009700,1,Wait(1) ;1 works, 3 did not
exten => 0009700,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1)
(closes issue #14992)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r230038 | file | 2009-11-13 13:44:07 -0600 (Fri, 13 Nov 2009) | 9 lines
Fix a crash caused by two threads thinking they should both free the
chan_local private structure when only one should.
(closes issue #15314)
Reported by: sroberts
Patches:
Issue15314_Move_Nulling_owner.patch uploaded by davidw (license 780)
Tested by: davidw, lottc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@230039 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
Jason Parker
Olle Johansson
Leif Madsen
Terry Wilson
David Vossel
Russell Bryant
Alec L Davis
Sean Bright
Tilghman Lesher
Jeff Peeler
Matthew Nicholson
Richard Mudgett
Tim Ringenbach
Mark Michelson
Joshua Colp