https://origsvn.digium.com/svn/asterisk/trunk
........
r153181 | twilson | 2008-10-31 13:55:33 -0500 (Fri, 31 Oct 2008) | 5 lines
Recent CDR fixes moved execution of the 'h' exten into the bridging code, so variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call
(closes issue #13793)
Reported by: greenfieldtech
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@153266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152605 | murf | 2008-10-28 23:47:13 -0600 (Tue, 28 Oct 2008) | 22 lines
Merged revisions 152538 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152538 | murf | 2008-10-28 23:19:04 -0600 (Tue, 28 Oct 2008) | 14 lines
A little documentation cross-ref between features and
dial and queue... I wasted some time (stupidly) trying
to get the one-touch parking stuff working, because it
didn't occur to me that I had to also have the corresponding
options in the dial command! Duh! (In all this time, I never
set this up before!)
So, to keep some poor fool from suffering the same fate,
I made the features.conf.sample file mention the corresponding
opts in dial/queue; and the docs for dial/app specifically
mention the corresponding decls in the feature.conf file.
I hope this doesn't spoil some vast, eternal plan...
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152536 | murf | 2008-10-28 23:01:00 -0600 (Tue, 28 Oct 2008) | 57 lines
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r149201 | mmichelson | 2008-10-14 17:41:13 -0500 (Tue, 14 Oct 2008) | 20 lines
Merged revisions 149200 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149200 | mmichelson | 2008-10-14 17:40:42 -0500 (Tue, 14 Oct 2008) | 12 lines
Update the queue with the correct number of calls and
whether the call was completed within the service level
when a transfer takes place. This way, we do not "break"
the leastrecent and fewestcalls strategies by not logging
a call until after the transferred call has ended.
(closes issue #13395)
Reported by: Marquis
Patches:
app_queue.c.transfer.patch uploaded by Marquis (license 32)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@149203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142676 | murf | 2008-09-11 22:50:48 -0600 (Thu, 11 Sep 2008) | 40 lines
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@142678 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
................
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
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
........
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
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
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
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
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
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
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
