The previous fix still would look in the static_RTP_PT table, which
is inappropriate since we specifically want to find a codec that has
been negotiated.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
Patches:
codec_negotiation.patch Uploaded by NITESH BANSAL (License #6418)
........
Merged revisions 372311 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This work comes courtesy of Pedro Kiefer (License #6407)
The work was posted to review board by Kaloyan Kovachev (License #5506)
(closes issue ASTERISK-16668)
Reported by Grant Crawshay
(closes issue ASTERISK-16694)
Reported by Fred van Lieshout
(closes issue ASTERISK-18417)
Reported by Kostas Liakakis
(closes issue ASTERISK-19435)
Reported by Deon George
(closes issue ASTERISK-20157)
Reported by Pedro Kiefer
(closes issue ASTERISK-20158)
Reported by Pedro Kiefer
(closes issue ASTERISK-20224)
Reported by Pedro Kiefer
Review: https://reviewboard.asterisk.org/r/2075
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two memory leaks:
1. When find_user is called with NULL as its first parameter, the voicemail
user returned is allocated on the heap. The inboxcount2 function uses
find_user in such a fashion when counting new messages, and fails to free
the resulting voicemail user object.
2. When populate_defaults is called on a voicemail user, it wipes whatever
flags have been set on the object by copying over the global flags object.
If the VM_ALLOCED flag was ste on the voicemail user prior to doing so,
that flag is removed. This leaks the voicemail user when free_user is later
called.
(closes issue ASTERISK-19155)
Reported by: Filip Jenicek
patches:
asterisk.patch2 uploaded by Filip Jenicek (license 6277)
Patch slightly modified for this commit.
Review: https://reviewboard.asterisk.org/r/2096
........
Merged revisions 372268 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372288 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372289 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to 1.8, it was not necessary for an explicit "type" to be set for an
asterisk LDAP realtime peer. Now the routine find_peer actually checks the
type field during registration and fails to find the peer if it is not set.
The attached patch makes the realtime type equal whatever type is being
searched for if the type is 0 upon return from routine build_peer.
(closes issue ASTERISK-17222)
Reported by: John Covert
Patch by: David Vossel
Tested by: Darren Sessions
Review: https://reviewboard.asterisk.org/r/2095/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 1.4+, a fix was put in place to increment the sequence number for
retransmitted DTMF end packets. With the introduction of the RTP engine API in
1.8, the sequence number was no longer being incremented. This patch fixes this
regression as well as cleans up a few lines that were not doing anything.
(closes issue ASTERISK-20295)
Reported by: Nitesh Bansal
Tested by: Michael L. Young
Patches:
01_rtp_event_seq_num.patch uploaded by Nitesh Bansal (license 6418)
asterisk-20295-dtmf-fix-cleanup.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2083/
........
Merged revisions 372185 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372198 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372199 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
PQClear is not called when the result object of a call to PQExec has a
status of PGRES_COMMAND_OK. Interestingly enough, the off nominal case was
handled properly, so this memory leak only occurred when CEL records were
successfully written.
This patch properly clears the result in the nominal code path.
(closes issue ASTERISK-19991)
Reported by: Etienne Lessard
Tested by: Etienne Lessard
patches:
mem_leak_cel_pgsql.patch uploaded by Etienne Lessard (license #6394)
........
Merged revisions 372158 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372165 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372175 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, if pause or unpause was issued on an interface
without specifying a specific queue, a PAUSEALL or UNPAUSEALL event
would be logged in the queue log even if that interface wasn't a
member of any queues. This patch changes it so that these events are
only logged when at least one member of any queue exists for that
interface.
(closes issue AST-946)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2079/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372148 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem had to do with logic used when checking for what the oldest ringing channel
was. The problem was that if no channel was found, then no notification would be sent.
For custom device states, there is no associated channel, so no notification would get
sent. This fixes the issue by still sending the notification even if no associated
channel can be found for a ringing device state change.
(closes issue ASTERISK-20297)
Reported by Noah Engelberth
........
Merged revisions 372137 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A change for Asterisk 11 caused a check for failure to incorrectly check the return
value. This resulted in the possibility of transmitting media that a party had not
negotiated. If this media happened to be G.729, then this could potentially result
in one-way audio if no G.729 translators are installed.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
........
Merged revisions 372118 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When app_queue is unloaded, the queues container has its refcount
decremented, potentially to 0. Then the taskprocessor responsible
for handling device state changes is unreferenced. If the
taskprocessor happens to be just about to run its task, then it
will create and destroy an iterator on the queues container.
This can cause the refcount on the queues container to increase to
1 and then back to 0. Going back to 0 a second time results in
double frees.
This failure was seen periodically in the testsuite when Asterisk
would shut down.
........
Merged revisions 372089 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372090 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372091 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Queue member status would not always get updated properly when the member
was called, thus resulting in the member getting multiple calls. With this
change, we update the member's status at the time of calling, and we also
check to make sure the member is still available to take the call before
placing an outbound call.
(closes issue ASTERISK-16115)
reported by nik600
Patches:
app_queue.c-svn-r370418.patch uploaded by Italo Rossi (license #6409)
........
Merged revisions 372048 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372049 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372050 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an IAX2 call is made using the credentials of a peer defined in a dynamic
Asterisk Realtime Architecture (ARA) backend, the ACL rules for that peer are
not applied to the call attempt. This allows for a remote attacker who is aware
of a peer's credentials to bypass the ACL rules set for that peer.
This patch ensures that the ACLs are applied for all peers, regardless of their
storage mechanism.
(closes issue ASTERISK-20186)
Reported by: Alan Frisch
Tested by: mjordan, Alan Frisch
........
Merged revisions 372028 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI Originate action can allow a remote user to specify information that can
be used to execute shell commands on the system hosting Asterisk. This can
result in an unwanted escalation of permissions, as the Originate action, which
requires the "originate" class authorization, can be used to perform actions
that would typically require the "system" class authorization. Previous attempts
to prevent this permission escalation (AST-2011-006, AST-2012-004) have sought
to do so by inspecting the names of applications and functions passed in with
the Originate action and, if those applications/functions matched a predefined
set of values, rejecting the command if the user lacked the "system" class
authorization. As noted by IBM X-Force Research, the "ExternalIVR"
application is not listed in the predefined set of values. The solution for
this particular vulnerability is to include the "ExternalIVR" application in the
set of defined applications/functions that require "system" class authorization.
Unfortunately, the approach of inspecting fields in the Originate action against
known applications/functions has a significant flaw. The predefined set of
values can be bypassed by creative use of the Originate action or by certain
dialplan configurations, which is beyond the ability of Asterisk to analyze at
run-time. Attempting to work around these scenarios would result in severely
restricting the applications or functions and prevent their usage for legitimate
means. As such, any additional security vulnerabilities, where an
application/function that would normally require the "system" class
authorization can be executed by users with the "originate" class authorization,
will not be addressed. Instead, the README-SERIOUSLY.bestpractices.txt file has
been updated to reflect that the AMI Originate action can result in commands
requiring the "system" class authorization to be executed. Proper system
configuration can limit the impact of such scenarios.
(closes issue ASTERISK-20132)
Reported by: Zubair Ashraf of IBM X-Force Research
........
Merged revisions 371998 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 371999 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372000 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes numerous doxygen warnings across Asterisk. It also updates
the makefile to regenerate the doxygen configuration on the local system
before running doxygen to help prevent warnings/errors on the local system.
Much thanks to Andrew for tackling one of the Asterisk janitor projects!
(issue ASTERISK-20259)
Reported by: Andrew Latham
Patches:
doxygen_partial.diff uploaded by Andrew Latham (license 5985)
make_progdocs.diff uploaded by Andrew Latham (license 5985)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r294740, the CODING-GUIDELINES was removed from the doc folder in favor
of the content on the Asterisk wiki. Some folks still look in the doc folder
initially for coding guideline suggestions; as such, this patch adds a
CODING-GUIDELINES file back into the doc folder. The content of the file
merely points to the correct page on the Asterisk wiki where the coding
guidelines currently live.
(closes issue ASTERISK-20279)
Reported by: Andrew Latham
Patches:
CODING-GUIDELINES.diff uploaded by Andrew Latham (license 5985)
........
Merged revisions 371961 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 371962 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 371963 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The struct MD5Context character buffer is cast to an int32_t* without
making sure that said buffer is aligned.
Since the buffer follows two uint32_t's, the chance of 'in' being (32
bits) unaligned is nil in practice. But adding code to ensure that 'in'
stays aligned costs nothing and removes all doubts about the casts being
safe.
(closes issue ASTERISK-20241)
Reported by: Walter Doekes
Patches:
tmp.diff (license #5674) patch uploaded by Walter Doekes
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371952 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matt Jordan informed me that it was more appropriate to use an
astman_send_ack here instead of making an event response. I've also
used this opportunity to update UPGRADE.txt to mention this change
in behavior.
(issue AST-969)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, Issuing SIPqualifypeer either resulted in an
error or if it succeeded, a few \r\ns. This patch adds a
SIPqualifypeerComplete event issued as a response when the command
is successfully executed.
(closes issue AST-969)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original implementations simply wrap pthread functions, which take
absolute time as an argument. The spinlock version for systems without
those functions treated the argument as a delta. This patch fixes the
spinlock version to be consistent with the pthread version.
(closes issue ASTERISK-20240)
Reported by: Egor Gorlin
Patches:
lock.c.patch uploaded by Egor Gorlin (license 6416)
........
Merged revisions 371718 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 371720 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371721 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the SCOPED_LOCK macro, you can create a variable
that locks a specific lock and unlocks the lock when the
variable goes out of scope. This is useful for situations
where many breaks, continues, returns, or other interruptions
would require separate unlock statements. With a scoped lock,
these aren't necessary.
There are specializations for mutexes, read locks, write locks,
ao2 locks, ao2 read locks, ao2 write locks, and channel locks.
Each of these is a SCOPED_LOCK at heart though.
Review: https://reviewboard.asterisk.org/r/2060
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pj_thread_register() takes a parameter of type pj_thread_desc.
It was assumed that pj_thread_register either used this item
temporarily or made a copy of it. Unfortunately, all it does is
keep a pointer to the structure in thread-local storage. This
means that if our pj_thread_desc goes out of scope, then pjlib
will be referencing bogus data quite often, most commonly on
operations involving a pj_mutex_t.
In our case, our pj_thread_desc was on the stack and went out
of scope very shortly after registering our thread with pjlib.
With this change, the pj_thread_desc is stored in thread-local
storage so the pointer that pjlib keeps in thread-local storage
will reference legitimate memory.
(closes issue ASTERISK-20237)
reported by Jeremy Pepper
Patches:
ASTERISK-20237.patch uploaded by Mark Michelson (license #5049)
Tested by Jeremy Pepper
........
Merged revisions 371571 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371572 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When compiling with BETTER_BACKTRACES enabled, Asterisk will sometimes
crash when "core show locks" is run. This happens regularly in the
testsuite since several tests run "core show locks" to help with
debugging. This seems to be a fault with libraries on certain operating
systems (notably CentOS 6.2/6.3) running on virtual machines and
utilizing gcc 4.4.6.
(issue ASTERISK-20090)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Kinsey Moore
Alec L Davis
Mark Michelson
Matthew Jordan
Darren Sessions
Michael L. Young
Jonathan Rose
David M. Lee
Joshua Colp