Prior to this patch, res_musiconhold existed at the same module priority level
as the timing sources that it depends on. This would cause a problem when
music on hold was reloaded, as the timing source could be changed after
res_musiconhold was processed. This patch adds a new module priority level,
AST_MODPRI_TIMING, that the various timing modules are now loaded at. This
now occurs before loading other resource modules, such that the timing source
is guaranteed to be set prior to resolving the timing source dependencies.
(closes issue ASTERISK-17474)
Reporter: Luke H
Tested by: Luke H, Vladimir Mikhelson, zzsurf, Wes Van Tlghem, elguero, Thomas Arimont
Patches:
asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-1.8.diff uploaded by elguero (License #5026)
asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-10.diff uploaded by elguero (License #5026)
asterisk-17474-dahdi_timing-infinite-wait-fix_v3.diff uploaded by elguero (License #5026)
Review: https://reviewboard.asterisk.org/r/1578/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@349194 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_cdr_setcid() and ast_cdr_update() were shown in ASTERISK-18836 to
be called by different threads for the same channel. The channel driver
thread and the PBX thread running dialplan.
* Add lock protection around CDR API calls that access an ast_channel
pointer.
(closes issue ASTERISK-18836)
Reported by: gpluser
Review: https://reviewboard.asterisk.org/r/1628/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The function ast_srtp_protect used a common buffer for both SRTP and SRTCP
packets. Since this function can be called from multiple threads for the same
SRTP session (scheduler for SRTCP and channel for SRTP) it was possible for the
packets to become corrupted as the buffer was used by both threads
simultaneously.
This patch adds a separate buffer for SRTCP packets to avoid the problem.
(closes issue ASTERISK-18889, Reported/patch by Daniel Collins)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@347995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add missing symbol exports for ast_aji_client_destroy and ast_aji_buddy_destroy
for usage outside res_jabber. Testing of these changes focused on res_jabber
itself, so this problem was missed.
Reported-by: Michael Spiceland
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@346951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The STUN socket must remain open between polls or the external address
seen by the STUN server is likely to change. However, if the STUN request
poll fails then the STUN server address needs to be re-resolved and the
STUN socket needs to be closed and reopened.
* Re-resolve the STUN server address and create a new socket if the STUN
request poll fails.
* Fix ast_stun_request() return value consistency.
* Fix ast_stun_request() to check the received packet for expected message
type and transaction ID.
* Fix ast_stun_request() to read packets until timeout or an associated
response packet is found. The stun_purge_socket() hack is no longer
required.
* Reduce ast_stun_request() error messages to debug output.
* No longer pass in the destination address to ast_stun_request() if the
socket is already bound or connected to the destination.
(closes issue ASTERISK-18327)
Reported by: Wolfram Joost
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1595/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@346700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a result of the fix for ASTERISK-18039, realtime caching MOH no longer
properly resumes playing back a file between different holds in the same call.
This is because scanning for new files causes the existing file array to be
emptied and we were just comparing that the saved pointer to the filename
matched the pointer to the filename in a particular position in the array. An
easy fix is to save the filename instead of a pointer to it and then do a
strcmp instead of comparing the addresses.
(closes issue ASTERISK-18912)
Review: https://reviewboard.asterisk.org/r/1596/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@346030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Change from using send() to ast_agi_send() so the HANGUP shows up in the
AGI debug output.
(closes issue ASTERISK-18723)
Reported by: James Van Vleet
Patches:
jira_asterisk_18723_v1.8.patch (license #5621) patch uploaded by rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@345431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Realtime MOH class caching was implemented because without it, you would build
a completely new MOH class and would start the music over at the beginning each
time hold was pressed in a conversation. Unfortunately, this broke re-scanning
for file changes for realtime MOH classes. This patch corrects that issue.
(closes issue ASTERISK-18039)
Review: https://reviewboard.asterisk.org/r/1579/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@344899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Somewhere between 1.4 and 1.8 the sipusers family has become completely
unused. Before that, the sipfriends family had been obsoleted in favor
of separate sipusers and sippeers families. Apparently, they have been
merged back again into a single family which is now called "sippeers".
Reviewed by: irroot, oej, pabelanger
Review: https://reviewboard.asterisk.org/r/1523
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@342869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sequence number was handled as an unsigned integer (usually 32 bits I think, more
depending on the architecture) and was put into the rtp packet which is basically
just a bunch of bits using an or operation. Sequence number only has 16 bits
allocated to it in an RTP packet anyway, so it would add to the next field which
just happened to be the codec. This makes sure the sequence number is set to be
a 16 bit integer regardless of architecture (hopefully) and also makes it so the
incrementing of the sequence number does bitwise or at the peak of a 16 bit number
so that the value will be set back to 0 when going beyond 65535 anyway.
(closes issue ASTERISK-18291)
Reported by: Will Schick
Review: https://reviewboard.asterisk.org/r/1542/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@342602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The fix for ASTERISK-12715 and ASTERISK-12685 added a check for the Park
application because the channel needed to be masqueraded to prevent a
crash. Since the Park application now always masquerades the channel into
the parking lot, the special check is no longer needed. The fix also
resulted in AGI exec Park attempting to double park the call and not honor
the Park application parameters.
* Removed no longer necessary call to ast_masq_park_call() by AGI exec for
the Park application. (Reverts -r146923)
* Fix Park application to only return 0 or -1. The AGI exec Park was
causing broken pipe error messages because the Park application returned 1
on successful park.
(closes issue ASTERISK-18737)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@341717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RTCP is now disabled for "inactive" RTP audio streams during SIP T.38 sessions.
The ability to disable RTCP streams in res_rtp_asterisk was missing, so this
code was added to support the bug fix.
(closes issue ASTERISK-18400)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340970 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is no documented reason to not add the query field to the varlist
returned by a realtime multi query, despite the config category being
set to its value. Of course, there is no documentation that the category
should be set to the value either. There is lots of no documentation
when it comes to realtime. But, other engines do not skip this field so
I am forcing this backend to follow the convention, because not doing so
is very silly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds an optional "module" attribute to the XML documentation spec
that allows the documentation processor to match apps with identical names from
different modules to their documentation. This patch also fixes a number of
bugs with the documentation processor and should make it a little more
efficient. Support for multiple languages has also been properly implemented.
ASTERISK-18130
Review: https://reviewboard.asterisk.org/r/1485/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I'm going to attempt some generic res_jabber cleanup and come up with a new fix for this
problem, but first it seems prudent to remove this rather broad attempt to fix it and
instead approach this problem either from the same angle but looking only at canceling
(or possibly rescheduling) the send when we absolutely know it will cause a segfault
or, if that can't be easily accomplished, strictly from the devstate side of things.
Also, I'm pretty sure a lot of the code in res_jabber isn't thread safe.
(issue ASTERISK-18626)
(issue ASTERISK-18078)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@339297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The first 9 frames are not reported as some devices dont use srtp
from first frame these are suppresed.
the warning is then output only once every 100 frames.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses crashes related to RTCP handling. The backtraces just
show a crash in ast_rtcp_write() where it appears that the RTP instance is no
longer valid. There is a race condition with scheduled RTCP transmissions and
the destruction of the RTP instance. This patch utilizes the fact that
ast_rtp_instance is a reference counted object and ensures that it will not get
destroyed while a reference is still around due to scheduled RTCP
transmissions.
RTCP transmissions are scheduled and executed from the chan_sip scheduler
context. This scheduler context is processed in the SIP monitor thread. The
destruction of an RTP instance occurs when the associated sip_pvt gets
destroyed (which happens when the sip_pvt reference count reaches 0). However,
the SIP monitor thread is not the only thread that can cause a sip_pvt to get
destroyed. The sip_hangup function, executed from a channel thread, also
decrements the reference count on a sip_pvt and could cause it to get
destroyed.
While this is being changed anyway, the patch also removes calling
ast_sched_del() from within the RTCP scheduler callback. It's not helpful.
Simply returning 0 prevents the callback from being rescheduled.
(closes issue ASTERISK-18570)
Related issues that look like they are the same problem:
(issue ASTERISK-17560)
(issue ASTERISK-15406)
(issue ASTERISK-15257)
(issue ASTERISK-13334)
(issue ASTERISK-9977)
(issue ASTERISK-9716)
Review: https://reviewboard.asterisk.org/r/1444/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch resolves a crash observed in a load testing environment that
involved the use of the res_ais module. I observed some crashes where
the event delivery callback would get called, but the length parameter
incidcating how much data there was to read was 0. The code assumed
(with good reason I would think) that if this callback got called, there
was an event available to read. However, if the rare case that there's
nothing there, catch it and return instead of blowing up.
More specifically, the change always ensure that the size of the received
event in the cluster is always big enough to be a real ast_event.
Review: https://reviewboard.asterisk.org/r/1423/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@335497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem happens when a call is disconnected and you had started a MOH
class that does not use the files mode. If you define REF_DEBUG and
recreate the problem, it will announce itself with the following warning:
Attempt to unref mohclass 0xb70722e0 (default) when only 1 ref remained,
and class is still in a container!
* Fixed moh_alloc() and moh_release() functions not handling the
state->class reference consistently.
(closes issue ASTERISK-18346)
Reported by: Mark Murawski
Patches:
jira_asterisk_18346_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett, Mark Murawski
Review: https://reviewboard.asterisk.org/r/1404/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@334355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a function pointer, the reference has to be resolved at load time
irrespective of the RTLD_LAZY flag. Creating a local alias solves
this problem, because the structure is initialized with that local
function pointer, while the actual function can remain lazily linked
until runtime.
The reason why this is important is because we lazily load function
references during the module loading process, in order to obtain
priority values for each module, ensuring that modules are loaded in
the correct order. Previous to this change, when this module was
initially loaded, the module loader would emit a symbol resolution
error, because of the above requirement.
Closes ASTERISK-18399 (reported by Mikael Carlsson, fix suggested by
Walter Doekes, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@334229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reporter said autoregister flag was ignored for registering 'buddies' which
had a subscription to us. Verified that this was the case and observed how
the patch addressed this and made sure it didn't break anything.
(closes issue ASTERISK-14233)
Reported by: Simon Arlott
Patches:
asterisk-0015229.patch (license #5756) patch uploaded by Simon Arlott
Tested by: Jonathan Rose
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@333378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using publishing device state with res_jabber, Asterisk will attempt
to send a device state using the unconnected client using iks_send_raw
and crash. This patch checks the validity of the connection before
attempting to send the device state.
(closes issue ASTERISK-18078)
Reported by: Michael L. Young
Patches:
res_jabber-segfault-pubsub-not-connected2.patch (license #5026) patch uploaded by Michael L. Young
Tested by: Jonathan Rose
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@333265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix realtime_multi_pgsql() configuration memory leak when the database
access returns an error.
* Fix realtime_multi_odbc() configuration category use after free when the
database access returns an error.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Numerous isues have been reported for deadlocks that are caused by
a blocking read in res_timing_timerfd on a file descriptor that will
never be written to. This patch adds some checks to make sure that
the timerfd is both valid and armed before calling read().
Should fix: ASTERISK-18142, ASTERISK-18197, ASTERISK-18166, AST-486
AST-495, AST-507 and possibly others.
Review: https://reviewboard.asterisk.org/r/1361/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the seek value is past the end of file when resuming G.722 MOH, MOH will
cease to function for the duration of the MOH session through all starts and
stops until saved state is cleared. Adjusting the code to guarantee a single
valid read (which is already assumed) fixes the bug.
(closes issue ASTERISK-18077)
Review: https://reviewboard.asterisk.org/r/1328/
Tested-by: Jonathan Rose <jrose@digium.com>
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@331038 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When deciding whether Asterisk was allowed to bridge the call away from the
core, chan_sip did not take into account the usage of features on dialed
channels that require monitoring of DTMF on channels utilizing inband DTMF.
This would cause Asterisk to allow the call to be locally or remotely bridged,
preventing access to the data required to detect activations of such features.
(closes 17237)
Review: https://reviewboard.asterisk.org/r/1302/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@328823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Addresses some improper sql statements in res_odbc that would cause an update to fail on
realtime peers due to trying to set as "(NULL)" rather than an actual NULL.
(closes issue #1922STERISK-17791)
Reported by: marcelloceschia
Patches:
20110505__issue19223.diff.txt uploaded by tilghman (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@326689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
jrose discovered a performance issue with this
fix that prevents his analog phones from working
when using timerfd as a timing source. Until
it is understood what is causing this performance
problem, this patch is being reverted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@326484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This matters only when autoconf fails to detect that weak linking is supported.
External optional dependencies will become optional in both cases, as they are
removed at compile time when not detected. However, runtime-optional modules
are made mandatory when weak linking is not found. This change affects only
the external optional dependencies; previously, they were incorrectly required
when weak linking support was not detected.
Patches:
20110702__issue18062__asterisk_trunk.diff.txt by tilghman (License #5003)
Tested by: iasgoscouk
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@326411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bug occurs rather intermittently and I relied on the reporters to test the patch.
After a sanity check and some testing, I'm giving it an OK.
(closes issue ASTERISK-17875)
Reported by: David Cunningham
Patches:
res_musiconhold.c.mohrt17875_v1 uploaded by Igor Goncharovsky (license #5009)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@325821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bryonclark described the problem as occuring during this function because of multiple
simultaneous database operations causing corruption against a pgsqlConn object.
(closes issue ASTERISK-17811)
Reported by: byronclark
Patches:
pgsql_find_table_locking.patch uploaded by byronclark (license 1200)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@323730 65c4cc65-6c06-0410-ace0-fbb531ad65f3
