Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.22-rc3@140896 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.22-rc3@140895 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.22-rc3@140894 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13387)
Reported by: moliveras
Patches:
13387.patch uploaded by putnopvut (license 60)
Tested by: putnopvut, moliveras
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140850 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13307)
Reported by: jcovert
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140816 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.22-rc3@140812 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.22-rc3@140811 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.22-rc3@140810 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
for IMAP storage, I left out a crucial place to
copy the context to the vm_state structure. This
is the correction.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140751 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
verbose level 2 messages. Really, they matter little to end users. You either get the CDR's you wanted, or you don't, and it is a bug.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140747 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
better in fact, than ast_cdr_free, which generates lots of useless warnings that will undoubtably generate complaints.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140690 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: tomaso
Patches:
asterisk-1.6.0-rc2-cdrmemleak.patch uploaded by tomaso (license 564)
I basically spent the day, verifying that this patch
solves the problem, and doesn't hurt in non-problem
cases. Why valgrind did not plainly reveal this leak
absolutely mystifies and stuns me.
Many, many thanks to tomaso for finding and providing the fix.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140670 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
buffers when copying configuration values.
(closes issue #13336)
Reported by: decryptus_proformatique
Patches:
chan_iax2_mohinterpret_mohsuggest_general_settings.patch uploaded by decryptus (license 555)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140605 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@140488 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@140421 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
in a string to Dial(), it is not ignored.
(closes issue #13355)
Reported by: acunningham
Patches:
13355v2.patch uploaded by putnopvut (license 60)
Tested by: acunningham
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140417 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
in pedantic mode. The problem was that the wrong
tags would be compared depending on the direction
of the call.
(closes issue #13353)
Reported by: flefoll
Patches:
chan_sip.c.br14.139015.patch-refer-pedantic uploaded by flefoll (license 244)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140299 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140115 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
of a completely unrelated function to determine whether the scheduler should
be run or not. This would have caused the scheduler to not run in cases where
it should have. Also, leave a note about another scheduler issue that needs
to be addressed at some point.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140060 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: tzafrir
Patches:
dahdi_close.diff uploaded by tzafrir (license 46)
Tested by: tzafrir, jpeeler
This patch fixes closing open file descriptors in the case of an error.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140056 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
used here to allow newly scheduled tasks to wake up the scheduler just in case
the new task needs to run sooner than the current wakeup time when the thread
is sleeping. However, there was a race condition such that a newly scheduled
task would not properly wake up the scheduler or affect the wake up period.
The order of execution would have been:
1) Scheduler thread determines wake up time of N ms.
2) Another thread schedules a task and signals the condition, with an
execution time of < N ms.
3) Scheduler thread locks and goes to sleep for N ms.
By moving the sleep time determination to inside the critical section, this
possibility is avoided.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140051 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
structure, but languageprefix needs to be set = yes for sounds in subdirectories (digits/1, etc.) to play as the correct language.
Fix the generation of asterisk.conf to include languageprefix=yes
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140050 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139927 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
so be slightly more verbose.
(closes issue #13374)
Reported by: dougm
Patches:
13374.diff uploaded by seanbright (license 71)
Tested by: dougm
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139909 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139869 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
UpdateConfig manager action is issued and the
file specified in DstFileName does not yet exist,
an error is not returned.
(closes issue #13341)
Reported by: vadim
Patches:
13341.patch uploaded by putnopvut (license 60)
(with small modification from seanbright)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139769 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
are seeing adverse difference.
I will un-close 13251.
Back to the drawing board/ concept/ beginning/ whatever!
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139764 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I merged them into trunk, so I'm coming back to clean up.
And, in the process, I found an error in the code I added
to trunk and 1.6.x, that I'll fix using this patch also.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139635 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: Laureano
Patches:
originate_channel_check.patch uploaded by Laureano (license 265)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139621 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13298)
Reported by: snuffy
Patches:
bug13298_20080822.diff uploaded by snuffy (license 35)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139553 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
used anywhere and causes build errors if building under
dev-mode with TRACE_FRAMES selected in menuselect.
(closes issue #13362)
Reported by: snuffy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139521 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139466 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
incorrect locking order between iax2_pvt and
ast_channel structures.
AST-13
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139456 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
being able to be opened or specify after a restart.
(closes issue #11017)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139387 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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!
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139347 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139283 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@139213 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
cause the timestamp field of the RTP header to be invalid.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139151 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
because not doing so just makes it difficult for people with channels that are in alarm when Asterisk starts up to get them going once the alarm is cleared
(closes issue #12160)
Reported by: tzafrir
Patches:
asterisk-chanalarms_14.patch uploaded by tzafrir (license 46)
Tested by: tzafrir
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139145 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: brainy
Tested by: murf
The specialized reset routine is tromping on the
flags field of the CDR. I made a change to not
reset the DISABLED bit. This should get rid of this
problem.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139074 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13257)
Reported by: travishein
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139015 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138949 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(from what the corresponding channel variables were set to)
when the agent logs out.
(closes issue #13098)
Reported by: davidw
Patches:
20080731__issue13098_agent_ackcall_not_reset.diff uploaded by bbryant (license 36)
Tested by: davidw
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138942 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
number of buffers to be configured per channel. Syntax:
buffers=<num of buffers>,<policy>
Where the number of buffers is some non-negative integer and the policy is either "full", "half", or "immediate".
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138938 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@138886 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@138685 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138663 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138569 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138516 f38db490-d61c-443f-a65b-d21fe96a405b
|