This patch reverts r416150. When the comparison between mohclass->name and
state->class->name is made, you are not guaranteed that (a) state->class is
non-NULL or that state or state->class are in a safe state.
Crashes caught by the bridges/transfer_capabilities test.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@416251 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, music on hold will stop and then start again from the
beginning if ast_moh_start() is called multiple times. This can happen
if a call is put on hold repeatedly (the channel receives multiple
HOLD control frames) and can be triggered from ARI by starting MoH on a
channel multiple times. This is fairly jarring/annoying to users.
This change prevents MoH from being restarted if the requested music
class is the same as the one currently playing.
Review: https://reviewboard.asterisk.org/r/3615/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@416150 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ODBC realtime driver uses ^NN parameter encoding to cope with the
special meaning of the semi-colon. A semi-colon in a field is
interpreted as if the key was supplied twice, something which isn't
otherwise possible with fixed database columns. E.g. allow=alaw;ulaw
is parsed as allow=alaw and allow=ulaw. A literal semi-colon is
rewritten to ^3B when stored in the database.
The module uses a stringfield to efficiently store the encoded
parameters. However, this stringfield wasn't always freed in some
off-nominal cases.
Commit r413241 fixed initialization so the encoding for INSERT and
DELETE queries wouldn't crash. (Only SELECTs and UPDATEs worked
apparently.) But that commit forgot the frees. This change cleans
that up.
Review: https://reviewboard.asterisk.org/r/3555/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@414564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@413586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The realtime API specifies that the store callback is supposed to return the number
of rows affected. res_config_pgsql was instead returning an Oid cast as an int, which
during any nominal execution would be cast to 0. Returning 0 when more than 0 rows were
inserted causes problems to the function's callers.
To give an idea of how strange code can be, this is the necessary code change to fix
a device state issue reported against chan_pjsip in Asterisk 12+. The issue was that
the registrar would attempt to insert contacts into the database. Because of the 0
return from res_config_pgsql, the registrar would think that the contact was not successfully
inserted, even though it actually was. As such, even though the contact was query-able
and it was possible to call the endpoint, Asterisk would "think" the endpoint was unregistered,
meaning it would report the device state as UNAVAILABLE instead of NOT_INUSE.
The necessary fix applies to all versions of Asterisk, so even though the bug reported
only applies to Asterisk 12+, the code correction is being inserted into 1.8+.
Closes issue ASTERISK-23707
Reported by Mark Michelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@413224 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes setting nullable integer columns to NULL instead of an empty
string, which fails for PostgreSQL, for example. The current code is supposed
to do so, but the check is broken. The patch also allows the first column in
the list to be a nullable integer.
This patch also adds a compatibility setting in res_odbc.conf,
allow_empty_string_in_nontext. It is enabled by default. It should be disabled
for database backends (such as PostgreSQL) that require NULL instead of an
empty string for Integer columns.
Review: https://reviewboard.asterisk.org/r/3375
(issue ASTERISK-23459)
Reported by: zvision
patches:
res_config_odbc.diff uploaded by zvision (License 5755)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@411399 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I observed a crash in res_musiconhold on an Asterisk 11 system using realtime
MOH. Investigation of the backtrace showed a corrupt mohclass, implying that
it got destroyed before the code expected it to. I went looking for reference
counting errors that could have caused this crash and this patch this result.
It contains 2 changes.
1) Remove a usless block of code that was impossible to reach. There was even
a comment indicating that it was impossible to reach. The conditional includes
"!ast_test_flag(global_flags, MOH_CACHERTCLASSES)" and it's inside of an if
block with the opposite check "ast_test_flag(global_flags,
MOH_CACHERTCLASSES)". There's no good reason to keep it around.
2) A similar block to #1 contained a reference counting error. It stores
state->class in the local variable mohclass without increasing its reference
count. The reference count on mohclass is decremented at the end of the
function. This block of code probably very rarely runs, which would help
explain why this system was working fine for many months before experiencing a
crash.
Review: https://reviewboard.asterisk.org/r/3282/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@410043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change minrate from 2400 to 4800 on config reload in response to changes from
ASTERISK-22790 only. Any config with minrate of 2400 that would fail before
r405693 will still fail.
Comment out many settings in res_fax.conf.sample. The defaults are set in
res_fax.c, so setting the same value in sample config does nothing but make
the sample config more fragile.
(closes issue ASTERISK-23231)
Reported by: David Brillert
Review: https://reviewboard.asterisk.org/r/3261/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@409052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code assumed that unregistering the alias would always succeed while in
practice this is not actually true. A common case is the "reload" command itself.
If the cli_aliases.conf configuration file was changed and reload executed the
command would fail to unregister and ultimately point to freed memory.
The reload process now checks whether unregistering succeeded or not and if not
the old CLI alias is retained.
(closes issue ASTERISK-19773)
Reported by: Joel Vandal
(closes issue ASTERISK-22757)
Reported by: Gareth Blades
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@407205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_bind to a port reserved for another program by SELinux causes
errno == EACCES. This caused random failures when binding rtp or
udptl sockets. Treat EACCES as a non-fatal error, try next port.
(closes issue ASTERISK-23134)
Reported by: Corey Farrell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@406933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This restricts direct usage of global oseq so that all accesses are
locked and threads are not racing to get oseq values that they did not
claim.
This also fixes a build error in res_pktccops under dev mode.
(closes issue ASTERISK-23100)
Reported by: adomjan
Patch by: adomjan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@406037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
According to the new standard for V.27 and V.32 they are able to transmit
at a bit rate of 4,800 or 9,600. The check_mode_rate function needed to be
updated to reflect this. Also, because of this change the default 'minrate'
value was updated to be 4800.
(closes issue ASTERISK-22790)
Reported by: Paolo Compagnini
Patches:
res_fax.txt uploaded by looserouting (license 6548)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@405656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, res_fax_spandsp was conservative with how it initialized
the spandsp T.38 context. It would only initialize it if the driver thought
the current state was a T.38 fax. While this works fine in nominal situations,
in certain off nominal situations, res_fax_spandsp can believe that a T.38
fax will not occur when in fact one has started. In particular, this was
discovered when res_fax would fall back to audio after timing out on a T.38
upgrade. The SIP channel driver would continue to retry the re-INVITE and -
if the remote end responded after res_fax timed out with a 200 OK - a T.38
frame would be delivered to the res_fax stack when it no longer expected it.
As it turns out, there does not appear to be any downside to always
initializing the T.38 context, other than the actual memory allocation.
Since that avoids this off nominal situation (and others which are equally
likely hard to predict), this is the safest way to avoid this problem.
Much thanks to Torrey as well for providing a scenario that reproduces this
issue.
(closes issue ASTERISK-21242)
Reported by: Ashley Winters
Tested by: Torrey Searle
patches:
always-init-t38.patch uploaded by awinters (License 6477)
A_PARTY.xml uploaded by tsearle (License 5334)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@403449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r400089, a patch was put in to correct erroneous RTCP statistic resets.
Unfortunately, ast_rtp_read can be called on an RTP instance that does not
have RTCP information. This patch prevents that crash by only resetting
the statistics if we do actually have an RTCP instance.
(issue AST-1174)
(closes issue ASTERISK-22667)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Drop an error log message to debug level 1 since distributed device
state functions correctly when receiving this message and it spams the
logs.
(closes issue ASTERISK-22410)
Reported by: abelbeck
Patches:
asterisk-1.8-res_jabber-log-nonpubsub-error-to-debug.patch uploaded by abelbeck (License 5903)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a bug where the SSRC field on multicast RTP can be stuck at
0 which can cause problems for endpoints trying to make sense of
incoming streams.
(closes issue ASTERISK-22567)
Reported by: Simone Camporeale
Patches:
22567_res_mulitcast_ssrc.patch uploaded by Simone Camporeale (License 6536)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400393 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RTCP's calculation of the number of lost packets in an RTP stream is based on
that stream's sequence number count, the number of received packets, and how
many packets we expect to receive. When the SSRC for an RTP stream changes,
there can - and almost always will be - a large jump in the next packet's
timestamp and sequence number. If we don't reset the number of received
packets, sequence number count, and other metrics used by RTCP, the next RR/SR
report will use the previous SSRC's values to calculate the lost packet count
for the new SSRC - resulting in a very large number of lost packets.
This patch modifies res_rtp_asterisk such that, if it detects a SSRC change, it
will reset the various values used by the RTCP calculations. From the
perspective of RTCP, this appears as a new media stream - which is what it is.
Review: https://reviewboard.asterisk.org/r/2886/
(closes issue AST-1174)
Reported by: Thomas Arimont
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to a faulty function for debugging reference decrementing, it was possible
to reduce the refcount on the wrong object if two moh classes of the same name
were in the moh class container.
(closes issue ASTERISK-22252)
Reported by: Walter Doekes
Patches:
18_moh_debug_ref_patch.diff Uploaded by Jonathan Rose (license 6182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398937 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The mailbox and context are swapped on the receiving end for all users
of Jabber and XMPP distributed MWI in Asterisk 1.8 and all more recent
versions. This swaps those values to be correct when publishing to the
internal event system from Jabber/XMPP distributed MWI state.
(closes issue ASTERISK-22435)
Reported by: abelbeck
Tested by: Michael Keuter
Patches:
asterisk-1.8-res_jabber-aji_handle_pubsub_event.patch uploaded by abelbeck
asterisk-11-res_xmpp-xmpp_pubsub_handle_event.patch uploaded by abelbeck
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_xmldoc_printable returns an allocated block that must be freed by the
caller. Fixed manager.c and res_agi.c to stop leaking these results.
(closes issue ASTERISK-22395)
Reported by: Corey Farrell
Patches:
manager-leaks-1.8.patch uploaded by coreyfarrell (license 5909)
res_agi-xmldoc-leaks.patch uploaded by coreyfarrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If there is an error streaming an audio file, the current return status makes it
difficult for an AGI script to determine that there was an error with the audio
file.
This patches changes the result to return -1 and the function returns
RESULT_FAILURE instead of RESULT_SUCCESS. From looking at other parts of
res_agi, this would appear to be the proper way to handle an error.
(closes issue ASTERISK-21903)
Reported by: Ariel Wainer
Tested by: Ariel Wainer
Patches:
asterisk-21903-return-stream-res_1.8.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2625/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@394640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we send out a CN packet (for instance, in the case of using rtpkeepalives),
we are not setting the payload code properly. Also, we are setting the marker
bit when we shouldn't be according to RFC 3389, section 4.
AST_RTP_CN is not defined by AST_FORMAT codes. Therefore, we should be using
ast_rtp_codecs_payload_code() rather than ast_rtp_codecs_payload_lookup().
11 and trunk already use the appropriate function.
* In 1.8, use ast_rtp_codecs_payload_code()
* Remove the setting of the marker bit
* Fix the debug message by incrementing the seqno after the debug message is set
in order to display the correct seqno that was sent out
(closes issue ASTERISK-21246)
Reported by: Peter Katzmann
Tested by: Peter Katzmann, Michael L. Young
Patches:
asterisk-21246-rtp-cng-payload-error_1.8_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2500/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@388111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In certain situations, when the RTP engine goes to send a DTMF end digit
it may be in a situation where the remote address is no longer available,
or the digit that was supposed to be sent is invalid. In such cases, we
need to clear the RTP counters appropriately. Otherwise, when the RTP
source is set again, we'll continue to think that we're in the middle of
sending a DTMF digit, which can confuse the remote party (signficantly).
(closes issue ASTERISK-21522)
Reported by: Corey Farrell
patches:
rtp_dtmf_process_end.patch uploaded by Corey Farrell (License 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were several reports of deadlock when using
res_timing_pthread. Backtraces indicated that one thread was blocked
waiting for the write to the pipe to complete and this thread held
the container lock for the timers. Therefore any thread that wanted
to create a new timer or read an existing timer would block waiting
for either the timer lock or the container lock and deadlock ensued.
This patch changes the way the pipe is used to eliminate this source
of deadlocks:
1) The pipe is placed in non-blocking mode so that it would never
block even if the following changes someone fail...
2) Instead of writing bytes into the pipe for each "tick" that's
fired the pipe now has two states--signaled and unsignaled. If
signaled, the pipe is hot and any pollers of the read side
filedescriptor will be woken up. If unsigned the pipe is idle. This
eliminates even the chance of filling up the pipe and reduces the
potential overhead of calling unnecessary writes.
3) Since we're tracking the signaled / unsignaled state, we can
eliminate the exta poll system call for every firing because we know
that there is data to be read.
(closes issue ASTERISK-21389)
Reported by: Matt Jordan
Tested by: Shaun Ruffell, Matt Jordan, Tony Lewis
patches:
0001-res_timing_pthread-Reduce-probability-of-deadlocking.patch uploaded by sruffell (License 5417)
(closes issue ASTERISK-19754)
Reported by: Nikola Ciprich
(closes issue ASTERISK-20577)
Reported by: Kien Kennedy
(closes issue ASTERISK-17436)
Reported by: Henry Fernandes
(closes issue ASTERISK-17467)
Reported by: isrl
(closes issue ASTERISK-17458)
Reported by: isrl
Review: https://reviewboard.asterisk.org/r/2441/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@386109 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_jabber/res_xmpp were not adding AST_EVENT_IE_CACHABLE to the event as each message came in,
then devstate_change_collector_cb() was unable to find AST_EVENT_IE_CACHABLE in the event,
so defaulted incorrectly to AST_DEVSTATE_NOT_CACHABLE.
(issue ASTERISK-20175)
(closes issue ASTERISK-21429)
(closes issue ASTERISK-21069)
(closes issue ASTERISK-21164)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2452/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Normally I think keyword expansion is silly, but the one time it would have
been good, it didn't work because the property had quotes in it. This patch
fixes obviously busted svn:keywords properties.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch calculates the timestamp for outbound RTP when we don't have timing
information. This uses the same approach in res_rtp_asterisk. Thanks to both
Pietro and Tzafrir for providing patches.
(closes issue ASTERISK-19883)
Reported by: Giacomo Trovato
Tested by: Pietro Bertera, Tzafrir Cohen
patches:
rtp-timestamp-1.8.patch uploaded by tzafrir (License 5035)
rtp-timestamp.patch uploaded by pbertera (License 5943)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385636 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When MALLOC_DEBUG is enabled with res_config_ldap, issues (munmap_chunk:
invalid pointer errors) can occur as the memory is being allocated with
Asterisk's wrappers around malloc/calloc/free/strdup, as opposed to the
LDAP library's wrappers.
This patch uses the LDAP library's wrappers where appropriate, so that
compiling with MALLOC_DEBUG doesn't cause more problems than it solves.
Note that the patch listed below was modified slightly for this commit
to account for some additional memory allocation/deallocations.
(closes issue ASTERISK-17386)
Reported by: John Covert
Tested by: Andrew Latham
patches:
issue18789-1.8-r316873.patch uploaded by seanbright (License 5060)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When res_rtp_asterisk.c was altered to avoid attempting to apply
unprotect algorithms to non-audio RTP packets, the test used was
incorrect. This caused the audio packets to not be decrypted and
resulted in loud white noise on the other endpoint (or both endpoints
depending on the call legs involved). The test now properly checks the
version field in the RTP header to ensure that RTP and RTCP are
decrypted while other types of packets are not.
(closes issue ASTERISK-21323)
Reported by: andrea
Tested by: Kinsey Moore, andrea, John Bigelow
Patches:
whitenoise_fix.diff uploaded by Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ICalendar module had a systemic memory leak on each fetch of data from
the ICalendar source. The previous fetched data was not being properly
disposed. This patch makes it so that before each fetch of data, we dispose
of the previously fetched data.
(closes issue ASTERISK-21012)
Reported by: Joel Vandal
Tested by: Joel Vandal
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r370252 for ASTERISK-18404, Asterisk's handling of RTP was modified to
better account for out of order RTP packets. This was accomplished by using the
RTP timestamp and sequence number to check for out of order packets. However,
when a SSRC change occurs, the timestamp and sequence number will no longer
have any relation to the previously received packets. The variables tracking
the timestamp and sequence number therefore have to be reset.
(closes issue ASTERISK-20906)
Reported by: Eelco Brolman
patches:
dtmf_on_hold.patch uploaded by Eelco Brolman (license #6442)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Under some circumstances, libsrtp's srtp_create function deallocates memory that
it wasn't initially responsible for allocating. Because we weren't initially
aware of this behavior, this memory was still used in spite of being unallocated
during the course of the srtp_unprotect function. A while back I made a patch
which would set this value to NULL, but that exposed a possible condition where
we would then try to check a member of the struct which would cause a segfault.
In order to address these problems, ast_srtp_unprotect will now set an error value
when it ends without a valid SRTP session which will result in the caller of
srtp_unprotect observing this error and hanging up the relevant channel instead of
trying to keep using the invalid session address.
(closes issue ASTERISK-20499)
Reported by: Tootai
Review: https://reviewboard.asterisk.org/r/2228/diff/#index_header
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
