https://origsvn.digium.com/svn/asterisk/trunk
........
r141998 | mmichelson | 2008-09-09 07:32:38 -0500 (Tue, 09 Sep 2008) | 7 lines
Use ast_debug for debug messages. I was wondering why debug
messages weren't showing up when I had set the debug level
high for just app_queue.c. It's because we were only checking
the global option_debug variable instead of using the awesome
macro which checks both the global and file-specific value
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@142001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r140489 | mmichelson | 2008-08-29 12:47:17 -0500 (Fri, 29 Aug 2008) | 30 lines
Merged revisions 140488 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140488 | mmichelson | 2008-08-29 12:34:17 -0500 (Fri, 29 Aug 2008) | 22 lines
After working on the ao2_containers branch, I noticed
something a bit strange. In all cases where we provide
a callback function to ao2_container_alloc, the callback
function would only return 0 or CMP_MATCH. After inspecting
the ao2_callback() code carefully, I found that if you're
only looking for one specific item, then you should return
CMP_MATCH | CMP_STOP. Otherwise, astobj2 will continue
traversing the current bucket until the end searching for
more matches.
In cases like chan_iax2 where in 1.4, all the peers are
shoved into a single bucket, this makes for potentially
terrible performance since the entire bucket will be
traversed even if the peer is one of the first ones come
across in the bucket.
All the changes I have made were for cases where the
callback function defined was passed to ao2_container_alloc
so that calls to ao2_find could find a unique instance
of whatever object was being stored in the container.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@140490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r140422 | mmichelson | 2008-08-29 11:06:09 -0500 (Fri, 29 Aug 2008) | 20 lines
Merged revisions 140421 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140421 | mmichelson | 2008-08-29 11:01:07 -0500 (Fri, 29 Aug 2008) | 12 lines
Add context checking when retrieving a vm_state.
This was causing a problem for people who had identically
named mailboxes in separate voicemail contexts.
This commit affects IMAP storage only.
(closes issue #13194)
Reported by: moliveras
Patches:
13194.patch uploaded by putnopvut (license 60)
Tested by: putnopvut, moliveras
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@140425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r139627 | murf | 2008-08-22 16:03:13 -0600 (Fri, 22 Aug 2008) | 59 lines
Merged revisions 139347 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines
(closes issue #13251)
Reported by: sergee
Tested by: murf
THis is a bold move for a static release fix, but I wouldn't have
made it if I didn't feel confident (at least a *bit* confident)
that it wouldn't mess everyone up.
The reasoning goes something like this:
1. We simply cannot do anything with CDR's at the current point
(in pbx.c, after the __ast_pbx_run loop). It's way too late to
have any affect on the CDRs. The CDR is already posted and gone,
and the remnants have been cleared.
2. I was very much afraid that moving the running of the 'h'
extension down into the bridge code (where it would be now
practical to do it), would result in a lot more calls to the
'h' exten, so I implemented it as another exten under another
name, but found, to my pleasant surprise, that there was a
1:1 correspondence to the running of the 'h' exten in the
pbx_run loop, and the new spot at the end of the bridge.
So, I ifdef'd out the current 'h' loop, and moved it into
the bridge code. The only difference I can see is the stuff
about the AST_PBX_KEEPALIVE, and hopefully, if this
is still an important decision point, I can replicate it
if there are complaints. To be perfectly honest,
the KEEPALIVE situation is not totally clear to me,
and how it relates to a post-bridge situation is less
clear. I suspect the users will point out everything
in total clarity if this steps on anyone's toes!
3. I temporarily swap the bridge_cdr into the channel
before running the 'h' exten, which makes it possible
for users to edit the cdr before it goes out the door.
And, of course, with the endbeforehexten config var set,
the users can also get at the billsec/duration vals.
After the h exten finishes, the cdr is swapped back
and processing continues as normal.
Please, all who deal with CDR's, please test this version
of Asterisk, and file bug reports as appropriate!
........
I also made a little fix to the app_dial's 'e' option,
that is related to my updates.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r139215 | russell | 2008-08-20 17:16:36 -0500 (Wed, 20 Aug 2008) | 19 lines
Merged revisions 139213 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139213 | russell | 2008-08-20 17:14:35 -0500 (Wed, 20 Aug 2008) | 11 lines
Fix a crash in the ChanSpy application. The issue here is that if you call
ChanSpy and specify a spy group, and sit in the application long enough looping
through the channel list, you will eventually run out of stack space and the
application with exit with a seg fault. The backtrace was always inside of
a harmless snprintf() call, so it was tricky to track down. However, it turned
out that the call to snprintf() was just the biggest stack consumer in this
code path, so it would always be the first one to hit the boundary.
(closes issue #13338)
Reported by: ruddy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r138887 | mmichelson | 2008-08-19 13:52:04 -0500 (Tue, 19 Aug 2008) | 31 lines
Merged revisions 138886 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138886 | mmichelson | 2008-08-19 13:50:53 -0500 (Tue, 19 Aug 2008) | 23 lines
Add a lock and unlock prior to the destruction of the chanspy_ds
lock to ensure that no other threads still have it locked. While
this should not happen under normal circumstances, it appears that
if the spyer and spyee hang up at nearly the same time, the following
may occur.
1. ast_channel_free is called on the spyee's channel.
2. The chanspy datastore is removed from the spyee's channel in
ast_channel_free.
3. In the spyer's thread, the spyer attempts to remove and destroy the datastore
from the spyee channel, but the datastore has already been removed in step 2,
so the spyer continues in the code.
4. The spyee's thread continues and calls the datastore's destroy callback,
chanspy_ds_destroy. This involves locking the chanspy_ds.
5. Now the spyer attempts to destroy the chanspy_ds lock. The problem is that in step 4,
the spyee has locked this lock, meaning that the spyer is attempting to destroy a lock
which is currently locked by another thread.
The backtrace provided in issue #12969 supports the idea that this is possible
(and has even occurred). This commit does not close the issue, but should help
in preventing one type of crash associated with the use of app_chanspy.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@138888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r138687 | mmichelson | 2008-08-18 15:04:10 -0500 (Mon, 18 Aug 2008) | 18 lines
Merged revisions 138685 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138685 | mmichelson | 2008-08-18 15:01:14 -0500 (Mon, 18 Aug 2008) | 10 lines
Change the inequalities used in app_queue with regards
to timeouts from being strict to non-strict for more
accuracy.
(closes issue #13239)
Reported by: atis
Patches:
app_queue_timeouts_v2.patch uploaded by atis (license 242)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@138689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
trunk.
For an explanation of what "imap_consistency" is,
please see svn revision 134223 to the 1.4 branch.
Coincidentally, this also fixes a recent bug report
regarding the inability to save messages to the new
folder when using IMAP storage since they will would
be flagged as "seen" and not be recognized as new
messages.
(closes issue #13234)
Reported by: jaroth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
such as "Work" and "Family" would be subfolders of the
INBOX. This is an invalid assumption to make, but it could
be desirable to set up folders in this manner, so a new
option for voicemail.conf, "imapparentfolder" has been
added to allow for this.
(closes issue #13142)
Reported by: jaroth
Patches:
parentfolder.patch uploaded by jaroth (license 50)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134758 | mmichelson | 2008-07-31 10:56:18 -0500 (Thu, 31 Jul 2008) | 16 lines
Add more timeout checks into app_queue, specifically
targeting areas where an unknown and potentially
long time has just elapsed. Also added a check
to try_calling() to return early if the timeout
has elapsed instead of potentially setting a negative
timeout for the call (thus making it have *no* timeout
at all).
(closes issue #13186)
Reported by: miquel_cabrespina
Patches:
13186.diff uploaded by putnopvut (license 60)
Tested by: miquel_cabrespina
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133169 | mmichelson | 2008-07-23 14:39:47 -0500 (Wed, 23 Jul 2008) | 12 lines
As suggested by seanbright, the PSEUDO_CHAN_LEN in
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
own repository, and must be installed like any other library for Asterisk to
use. The two modules that require it are codec_resample and app_jack.
To install libresample:
$ svn co http://svn.digium.com/svn/libresample/trunk libresample
$ cd libresample
$ ./configure
$ make
$ sudo make install
This code is currently in our own repository because the build system did not
include the appropriate targets for building a dynamic library or for installing
the library.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r131369 | mmichelson | 2008-07-16 15:23:02 -0500 (Wed, 16 Jul 2008) | 14 lines
Move the init_queue call back to where it used to be (changed
Sept 12 last year). It was moved then to prevent a memory leak.
Since then, the same memory leak recurred and was fixed in a
better way.
Now it has been found that the placement of this init_queue
call can cause problems if a realtime queue has values changed
to an empty string. The problem is that the default value
for that queue parameter would not be set.
(closes issue #13084)
Reported by: elbriga
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@131375 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r131299 | mmichelson | 2008-07-16 13:57:34 -0500 (Wed, 16 Jul 2008) | 13 lines
Make absolutely certain that the transfer datastore
is removed from the calling channel once the caller
is finished in the queue. This could have weird con-
sequences when dialing local queue members when multiple
transfers occur on a single call.
Also fixed a memory leak that would occur when an
attended transfer occurred from a queue member.
(closes issue #13047)
Reported by: festr
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@131300 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130959 | tilghman | 2008-07-15 12:19:13 -0500 (Tue, 15 Jul 2008) | 8 lines
astman_send_error does not need a newline appended -- the API takes care of
that for us.
(closes issue #13068)
Reported by: gknispel_proformatique
Patches:
asterisk_1_4_astman_send.patch uploaded by gknispel (license 261)
asterisk_trunk_astman_send.patch uploaded by gknispel (license 261)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@131044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130792 | mmichelson | 2008-07-14 12:50:21 -0500 (Mon, 14 Jul 2008) | 8 lines
Add a check to the CAN_EARLY_BRIDGE macro in app_dial to
be sure there are no audiohooks present on the channels
involved. This fixed a one-way audio situation I had in
my test setup. I couldn't find any open issues that suggested
one-way audio with regards to mixmonitor (or other audiohook)
usage, though.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
fn2 was used in three functions. In every case, it was initialized
in the function it was used in. This meant there was no need
to have it in a malloc'd structure just taking up space. Furthermore
two of the functions it was used in were completely unnecessary since
fn2 was set to exactly the same value as the vm_state's fn string.
fn2 was a char array sized at PATH_MAX. On my system, PATH_MAX is
4096. This equates to a 4K memory savings per vm_state allocated.
Since there is a vm_state malloc'd for every voicemail user on
the system, this could potentially add up nicely if there are lots
of users. In addition, a vm_state is allocated on the stack each
time a caller calls the VoiceMailMain application, meaning that
there is a significant stack savings with this patch too.
Of course, a single vm_state struct still takes up approximately
20K on my system (when using IMAP storage. Without IMAP storage,
there would be about another 300 bytes fewer usage), even with
this removal. Further optimizations are probably possible,
but most likely not as easy as this one.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r129149 | tilghman | 2008-07-08 15:27:47 -0500 (Tue, 08 Jul 2008) | 8 lines
Cause SIP to return a 480 instead of a 404 when a sip peer exists, but is not
registered.
(closes issue #12885)
Reported by: ibc
Patches:
20080701__bug12885__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: ibc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129152 65c4cc65-6c06-0410-ace0-fbb531ad65f3
t38_terminal_release, and make sure that the phase E handler gets called
with proper status.
(closes issue #13020)
Reported by: dimas
Patches:
v1-appfax.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_voicemail would attempt to play a file called vm-foo instead of playing
vm-INBOX to play the "new" sound file. This commit fixes that issue.
This may fix one of the problems reported in issue #12987
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@128731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
MixMonitor to mix audio. However, it was pointed out to me that because
of this, the command set for the MONITOR_EXEC variable is ignored as well.
This means that people can't do their own custom mixing commands at the end
of recordings in order to make, for instance, stereo recordings of calls.
With this patch, app_queue will set the "joinfiles" variable for the channel's
monitor if MONITOR_EXEC is not zero-length. This means that for normal audio
mixing, MixMonitor is still the preferred choice, but we allow custom
mixing to be done with the two Monitor streams if desired.
(closes issue #12923)
Reported by: snyfer
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to how language is handled between two channels whose native
language is different. Prior to this patch, app_dial would have
the callee inherit the caller's language, and app_queue would not.
After this patch, app_dial no longer has the language inheritance
capability. This seems to make the most sense since it seems more
natural for a person to hear files played back in his/her native
language instead of the language of the person on the far end of
the call. See the CHANGES file for hints on how to keep the
previous behavior of app_dial if desired.
(closes issue #12489)
Reported by: bcnit
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125585 | mmichelson | 2008-06-26 17:52:39 -0500 (Thu, 26 Jun 2008) | 11 lines
Add the interface of a queue member to the output of the "queue show" command
so that it can easily be associated with a queue member's name. This helps
so that the appropriate queue member can be removed or paused since the
interface is required, not the member's name.
(closes issue #12783)
Reported by: davevg
Patches:
app_queue.diff uploaded by davevg (license 209) with small mod from me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125476 | mmichelson | 2008-06-26 15:56:01 -0500 (Thu, 26 Jun 2008) | 11 lines
Prior to this patch, the "queue show" command used cached
information for realtime queues instead of giving up-to-date
info. Now realtime is queried for the latest and greatest in
queue info.
(closes issue #12858)
Reported by: bcnit
Patches:
queue_show.patch uploaded by putnopvut (license 60)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125132 | kpfleming | 2008-06-25 17:21:30 -0500 (Wed, 25 Jun 2008) | 10 lines
allow tonezone to live in a different place than DAHDI/Zaptel, since dahdi-tools and dahdi-linux are now separate packages and can be installed in different places
don't include tonezone.h in dahdi_compat.h, because only a couple of modules need it
get app_rpt building again after the DAHDI changes
(closes issue #12911)
Reported by: tzafrir
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r124910 | tilghman | 2008-06-24 16:08:52 -0500 (Tue, 24 Jun 2008) | 8 lines
Occasionally control characters find their way into CallerID. These need to
be stripped prior to placing CallerID in the headers of an email.
(closes issue #12759)
Reported by: RobH
Patches:
20080602__bug12759__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: RobH
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r124540 | murf | 2008-06-21 20:54:52 -0600 (Sat, 21 Jun 2008) | 9 lines
(closes issue #12910)
Reported by: chris-mac
Sorry, my testing did not contain the simple case of forkCDR(v),
I am much embarrassed to admit. If I had, I would have
more solidly initialized the opts element for varset.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. Filenames had an extra "msg" in the attachment name
2. The attachment was being saved twice
(closes issue #12894)
Reported by: jaroth
Patches:
imap_attach.patch uploaded by jaroth (license 50)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
They want (char *)NULL as sentinel.
An example is OpenBSD (confirmed on 4.3) that ships with gcc 3.3.4
This commit introduces a contstant SENTINEL which is declared as:
#define SENTINEL ((char *)NULL)
All places I could test compile on my openbsd system are converted.
Update CODING-GUIDELINES to tell about this constant.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be marked urgent. This fixes that issue.
(closes issue #12895)
Reported by: jaroth
Patches:
urgent_forwarding.patch uploaded by jaroth (license 50)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
removed. No telling when it happened. Anyway, it's back in now
and works properly.
(Based on issue reported on mailing list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
them, and memory does not get free'd causing strange issues with SIP.
This code was originally written by russellb in the team/group/issue_11972/ branch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r123274 | mmichelson | 2008-06-17 10:56:55 -0500 (Tue, 17 Jun 2008) | 12 lines
davidw pointed out that the holdtime calculation used by
app_queue does not use "boxcar" filtering as the comments
say. The term "boxcar" means that the number of samples used
to calculate stays constant, with new samples replacing the
oldest ones. The queue holdtime calculation uses all holdtime
samples collected since the queue was loaded, so the comment
has been changed to be accurate.
(closes issue #12781)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123275 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: ys
Many thanks to ys for doing the research on this problem.
I didn't think it would be best to unlock the contexts
and then relock them after the remove_extension2() call,
so I added an extra arg to remove_extension2() and set it
appropriately in each call. There were not that many.
I considered forcing the code to lock the contexts before
the call to remove_extension2(), but that would require
a slightly greater degree of changes, especially since
the find_context_locked is local to pbx.c
I did a simple sanity test to make sure the code doesn't
mess things up in general.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
long-term use. Instead use the heap. I can't believe this
never happened *once* in my developer branch when I was testing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122461 65c4cc65-6c06-0410-ace0-fbb531ad65f3
net result of this work is that attended transfers made
by queue members will now show up in the queue_log as a
TRANSFER message instead of COMPLETECALLER as it had been.
As far as the details go, I created a datastore which is
attached to the calling channel just prior to when the caller
is bridged with the queue member. If the calling channel
is masqueraded, then during the "fixup" portion, the TRANSFER
will be logged and the datastore will be removed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122228 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122127 | murf | 2008-06-12 08:51:44 -0600 (Thu, 12 Jun 2008) | 1 line
Arkadia tried to warn me, but the code added to ast_cdr_busy, _failed, and _noanswer was redundant. Didn't spot it until I was resolving conflicts in trunk. Ugh. Redundant code removed. It wasn't harmful. Just dumb.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122128 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122046 | murf | 2008-06-12 07:47:34 -0600 (Thu, 12 Jun 2008) | 37 lines
(closes issue #10668)
Reported by: arkadia
Tested by: murf, arkadia
Options added to forkCDR() app and the CDR() func to
remove some roadblocks for CDR applications.
The "show application ForkCDR" output was upgraded
to more fully explain the inner workings of forkCDR.
The A option was added to forkCDR to force the
CDR system to NOT change the disposition on the
original CDR, after the fork. This involves
ast_cdr_answer, _busy, _failed, and so on.
The T option was added to forkCDR to force
obedience of the cdr LOCKED flag in the
ast_cdr_end, all the disposition changing
funcs (ast_cdr_answer, etc), and in the
ast_cdr_setvar func.
The CHANGES file was updated to explain ALL
the new options added to satisfy this bug report
(and some requests made verbally and via
email, irc, etc, over the past months/year)
The 's' option was added to the CDR() func,
to force it to skip LOCKED cdr's in the
chain.
Again, the new options should be totally transparent
to existing apps! Current behavior of CDR,
forkCDR, and the rest of the CDR system should
not change one little bit. Until you add the
new options, at least!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit merges in the rest of the code needed to support distributed device
state. There are two main parts to this commit.
Core changes:
- The device state handling in the core has been updated to understand device
state across a cluster of Asterisk servers. Every time the state of a device
changes, it looks at all of the device states on each node, and determines the
aggregate device state. That resulting device state is what is provided to
modules in Asterisk that take actions based on the state of a device.
New module, res_ais:
- A module has been written to facilitate the communication of events between
nodes in a cluster of Asterisk servers. This module uses the SAForum AIS
(Service Availability Forum Application Interface Specification) CLM and EVT
services (Cluster Management and Event) to handle this task. This module
currently supports sharing Voicemail MWI (Message Waiting Indication) and
device state events between servers. It has been tested with openais, though
other implementations of the spec do exist.
For more information on testing distributed device state, see the following doc:
- doc/distributed_devstate.txt
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
where the entered phone number is checked.
You can now define a set of extensions/exten patterns that describe
valid phone numbers. PrivacyManager will check that context for a match
with the given phone number.
This way you get better control. For example people blindly hitting
10 digits just to get past privacymanager
Example line in extensions.conf:
exten => incoming,n,PrivacyManager(3,10,,route-outgoing)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
has been loaded, fix a return value in the loader, and ensure that the help
workhorse header does not print on load.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a dynamic realtime queue member is added to the queue, and the
REMOVEMEMBER event is logged when a dynamic realtime member is
removed. Since no calling channel is associated with these events
the string "REALTIME" is placed where the channel's unique id is
normally placed.
(closes issue #12774)
Reported by: atis
Patches:
queue_log_rt_members.patch uploaded by atis (license 242)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
warnings, as well as update to the APIs in spandsp 0.0.5. Spandsp 0.0.5 is being
distributed under the LGPL, so we can move this module into the main tree.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@119801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r119404 | tilghman | 2008-05-30 16:17:45 -0500 (Fri, 30 May 2008) | 6 lines
When joinempty=strict, it only failed on join if there were busy members. If
all members were logged out OR paused, then it (incorrectly) let callers join
the queue.
(closes issue #12451)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@119419 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118858 | murf | 2008-05-28 18:25:28 -0600 (Wed, 28 May 2008) | 46 lines
(closes issue #10668)
(closes issue #11721)
(closes issue #12726)
Reported by: arkadia
Tested by: murf
These changes:
1. revert the changes made via bug 10668;
I should have known that such changes,
even tho they made sense at the time,
seemed like an omission, etc, were actually
integral to the CDR system via forkCDR.
It makes sense to me now that forkCDR didn't
natively end any CDR's, but rather depended
on natively closing them all at hangup time
via traversing and closing them all, whether
locked or not. I still don't completely
understand the benefits of setvar and answer
operating on locked cdrs, but I've seen
enough to revert those changes also, and
stop messing up users who depended on that
behavior. bug 12726 found reverting the changes
fixed his changes, and after a long review
and working on forkCDR, I can see why.
2. Apply the suggested enhancements proposed
in 10668, but in a completely compatible
way. ForkCDR will behave exactly as before,
but now has new options that will allow some
actions to be taken that will slightly
modify the outcome and side-effects of
forkCDR. Based on conversations I've had
with various people, these small tweaks
will allow some users to get the behavior
they need. For instance, users executing
forkCDR in an AGI script will find the
answer time set, and DISPOSITION set,
a situation not covered when the routines
were first written.
3. A small problem in the cdr serializer
would output answer and end times even
when they were not set. This is now
fixed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
retrieving the value of a channel variable. This covers app_queue.
This commit also incorporates a logical change. Previously, if MixMonitor
is to be used to record the call, all the arguments were parsed first. Then
the MixMonitor app would be located. Now the order of these operations has
been swapped. Now the app is located first so that we only go through the
work of parsing the arguments if the app was found.
(closes issue #12742)
Reported by: snuffy
Patches:
bug_12742.diff uploaded by snuffy (license 35)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118509 | mmichelson | 2008-05-27 14:07:26 -0500 (Tue, 27 May 2008) | 11 lines
Russell noted to me that in the case that separate threads use their
own addressing system, the fix I made for issue 12376 does not guarantee
uniqueness to the datastores' uids. Though I know of no system that works
this way, I am going to change this right now to prevent trying to track
down some future bug that may occur and cause untold hours of debugging
time to track down.
The change involves using a global counter which increases with each new
chanspy_ds which is created. This guarantees uniqueness.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118365 | mmichelson | 2008-05-27 11:38:38 -0500 (Tue, 27 May 2008) | 14 lines
Add a unique id to the datastore allocated in app_chanspy since
it is possible that multiple spies may be listening to the same
channel.
(closes issue #12376)
Reported by: DougUDI
Patches:
12376_chanspy_uid.diff uploaded by putnopvut (license 60)
Tested by: destiny6628
(closes issue #12243)
Reported by: atis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118371 65c4cc65-6c06-0410-ace0-fbb531ad65f3
likely that after the event is freed, we no longer refer to valid memory.
(closes issue #12712)
Reported by: tomo1657
Patches:
12712.patch uploaded by putnopvut (license 60)
Tested by: tomo1657
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you give chanisavail a list of channels, it will only
return the first available channel.
When this option is set, it will return all the available
channels from the given list.
(closes issue #12248)
Reported by: dagmoller
Patches:
app_chanisavail-snv.patch-v2.txt uploaded by dagmoller (license 436)
- major changes by me because russellb pointed out some buffer overflows
and codeguideline issues.
Converted it all to the ast_str_* api
Tested by: dagmoller, mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- make data member of the ast_frame struct a named union instead of a void
Recently the ast_queue_hangup function got a new parameter, the hangupcause
Feedback came in that this is no good and that instead a new function should be created.
This I did.
The hangupcause was stored in the seqno member of the ast_frame struct. This is not very
elegant, and since there's already a data member that one should be used.
Problem is, this member was a void *.
Now it's a named union so it can hold a pointer, an uint32 and there's a padding in case someone
wants to store another type in there in the future.
This commit is so massive, because all ast_frame.data uses have to be
altered to ast_frame.data.data
Thanks russellb and kpfleming for the feedback.
(closes issue #12674)
Reported by: mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Russell Bryant
Steve Murphy
Jason Parker
Sean Bright
Kevin P. Fleming
Tilghman Lesher
Michiel van Baak
Brett Bryant
Luigi Rizzo
Chris Tooley
Jeff Peeler