When using realtime queues, queues have to be fetched from the database
every now and then to see if any info has been changed or to see if the
queue has been removed. When fetching info for an individual queue, the
pruning of other queues is unnecessarily costly.
Review: https://reviewboard.asterisk.org/r/2907/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 200 OK for an initial INVITE is received, we were doing
the right thing by ACKing and sending an immediate BYE. However,
we also were doing the wrong thing and queuing an answer frame,
thus causing the call to be answered. This would cause the call
to be hung up by the channel thread, thus resulting in a second
BYE being sent out.
In this fix, I also have set the hangupcause to be correct since
the initial BYE being sent by Asterisk had an unknown hangup
cause. I have changed to using "Bearer capabilty not available"
since the call was hung up due to an SDP offer/answer error.
(closes issue ASTERISK-22621)
reported by Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400970 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remember the swgain setting from CLI "dahdi set swgain" command so the
CLI "dahdi show channel" output will reflect the current setting.
* Updated CLI "dahdi set hwgain" and "dahdi set swgain" documentation.
(issue ASTERISK-22429)
Reported by: Jaco Kroon
Patches:
jira_asterisk_22429_v1.8_v2.patch (license #5621) patch uploaded by rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bumping the SDP version number can cause interoperability problems
since receivers of the responses will expect that a 200 SDP will
be identical to a previous 183 SDP.
(closes issue ASTERISK-21204)
reported by NITESH BANSAL
Patches:
dont-increment-session-version-in-2xx-after-183.patch uploaded by NITESH BANSAL (License #6418)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When running configure, libiodbc2 development headers will fulfill the
requirement for ODBC development headers, but will not function
properly. This adds a warning when libiodbc2 development headers are
detected instead of unixodbc development headers.
(closes issue ASTERISK-22459)
Reported by: Patrick Maille
Tested by: Walter Doekes
Patches:
issueA22459_warn_when_using_iodbc.patch uploaded by Walter Doekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AST_CONFIG dialplan function defined in func_config.c allocates its
config file list entries using ast_malloc. List entry allocations
destined for use with Asterisk's linked list API must be ast_calloc()d
or otherwise initialized so that list pointers are set to NULL. These
uses of ast_malloc have been replaced by ast_calloc to prevent
dereferencing of uninitialized pointer values when traversing the list.
(closes issue ASTERISK-22483)
Reported by: Brian Scott
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Commit r62462 added two extra fields for logging "the original position the
caller entered the queue at, and the amount of time the caller was waiting in
the queue." But when r75969 was merged from 1.4 into trunk (r75977), these two
fields disappeared. Those two extra fields were not logged in 1.4 and when the
patch was merged, those fields went away.
Therefore, this is a regression and was caught by the reporter because he was
reading the awesome "Asterisk: The Definitive Guide" book.
(closes issue ASTERISK-22197)
Reported by: Dalius M.
Tested by: Dalius M.
Patches:
asterisk-22197-q-log-exitwithkey.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2901/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400622 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
The member reg in the peercnt structure is an unsigned char and peercnt_modify()
is expecting an unsigned char argument which gets assigned to peercnt->reg.
This patch fixes that by casting the integer argument being passed to
peercnt_modify to unsigned char.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a global option in chan_sip to allow it to continue
attempting registration if a 403 is received, clearing the cached nonce
and treating it as a non-fatal response. Normally, this would cause
registration attempts to that endpoint to stop.
(closes issue ASTERISK-17138)
Review: https://reviewboard.asterisk.org/r/2874/
Reported by: Rudi
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400137 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
In ASTERISK-17842, some additional library checks were added to the configure
script so that the bfd library could be found on CentOS and Fedora systems.
As it turns out, openSUSE requires an additional library. This patch adds
another check to the configure script for openSUSE that will add that library.
Review: https://reviewboard.asterisk.org/r/2885/
(closes issue AST-1169)
Reported by: Guenther Kelleter
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400073 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk receives a 200 OK in response to an invite, that peer should have
sent an SDP at some point by then. If the channel has never received an SDP,
media won't have been set and the remote address won't be known. Endpoints in
general should not be doing this. This patch makes it so that Asterisk will
simply hang up a call if it sends a 200 OK at this point. So far this odd
behavior for endpoints has only been observed in tests which involved manually
created SIP transactions in SIPp.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PRI and SS7 link control threads are not stopped correctly when the
chan_dahdi.so module is unloaded. The link control threads pri_dchannel()
and ss7_linkset() are not awakened from a poll() to cancel the thread.
* Added a SIGURG signal after requesting the thread cancel to break the
link control thread poll() immediately.
For SS7 it was slightly worse, the link poll() timeout would always be
whatever was the last libss7 scheduled event time used. If no libss7
scheduled event was pending, the thread could run more often than
necessary.
* Set nextms to 60 seconds for the ss7_linkset() poll() if there is no
other libss7 scheduled event.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1st Issue
When a realtime peer sends an un-REGISTER request, Asterisk
un-registers the peer but the database table record still has regseconds and
fullcontact for the peer. This results in calls attempting to be routed to the
peer which is no longer registered. The expected behavior is to get
busy/congested when attempting to call an un-registered peer through the
dialplan.
What was discovered is that we are clearing out the peer's registration in the
database in parse_register_contact() when calling expire_register() but then
upon returning from parse_register_contact(), update_peer() is run which stores
back in the database table regseconds and fullcontact.
2nd Issue
The reporter pointed out that the 200 ok being returned by Asterisk
after un-registering a peer contains a Contact header with ;expires= and the
Expires header is not set to 0. This is actually a regression.
Tests were created for this second issue (ASTERISK-22548). The tests have been
reviewed and a Ship It! was received on those tests.
This patch does the following:
* Do not ignore the Expires header value even when it is set to 0. The patch
sets the pvt->expiry earlier on in the function so that it is set properly and
used.
* If pvt->expiry is 0, do not call update_peer since that means the peer has
already been un-registered and there is no need to update the database record
again since nothing has changed.
(closes issue ASTERISK-22428)
Reported by: Ben Smithurst
Tested by: Ben Smithurst, Michael L. Young
Patches:
asterisk-22428-rt-peer-update-and-expires-header.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2869/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Clean up some twisted code in the iax2_bridge() loop.
* Add AST_CONTROL_VIDUPDATE and AST_CONTROL_SRCCHANGE to a list of frames
to prevent the native bridge loop from breaking.
* Passing the AST_CONTROL_T38_PARAMETERS frame should also allow FAX over
a native IAX2 bridge.
(issue ABE-2912)
Review: https://reviewboard.asterisk.org/r/2870/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, Asterisk would incorrectly use the previous endpoint
addresses in SDP in spite of providing its own port. T38 is never meant to
be done through directmedia and Asterisk should always be in the media path
for these streams.
(closes issue ASTERISK-17273)
Reported by: Kevin Stewart
(closes issue ASTERISK-18706)
Reported by: Jeremy Kister
Review: https://reviewboard.asterisk.org/r/2853/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adjusts '/'-to-'#' replacement to replace all instances of '/'
instead of just the first to ensure that the jitter buffer log file
gets the correct name as per Richard Kenner's suggestion.
(closes issue ASTERISK-21036)
Reported by: Richard Kenner
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399402 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This will now pull both a command reference for the version being prepared,
as well as an Admin Guide that applies to all versions of Asterisk.
(issue ASTERISK-22439)
Reported by: Olle Johansson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When processing the lines under the [applicationmap] context in features.conf, a
segfault occurs from attempting to process a line with an invalid syntax
(basically missing most of the arguments).
Example:
[applicationmap]
automon=*6
* This patch moves the checking for empty arguments to before they are accessed.
* Also, checked the "todo" comment and removed it. Some applications do not
require arguments.
(closes issue ASTERISK-22416)
Reported by: CGI.NET
Tested by: CGI.NET
Patches:
asterisk-22416-check-syntax-first_v2.diff by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2803
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a new IAX2 client registers, the astdb database is updated with the
value of minregexpire defined in iax.conf instead of using the expiry time
that is provided by the client. The provided expiry time of the client is
updated after inserting the astdb entry. As a consequence, restarting or
reloading asterisk creates clients whose registration may expire before
they reregister. The clients are therefore unavailable after minregexpire
seconds until they reregister.
* Move updating of the expiry time to before inserting into the astdb.
(closes issue ASTERISK-22504)
Reported by: Stefan Wachtler
Patches:
chan_iax2.c.patch (license #6533) patch uploaded by Stefan Wachtler
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If MALLOC_DEBUG is enabled, then the debug destructor for the container
is used, which would erroneously write to /tmp/refs. This patch only
uses the debug destructor if ref_debug is used.
(closes issue ASTERISK-22536)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change ensures that MeetMeAdmin commands requiring a user actually
get a user and fixes another issue where an extra dereference could
occur for a last-entered user being ejected if a user identifier was
also provided.
(closes issue ASTERISK-21907)
Reported by: Alex Epshteyn
Review: https://reviewboard.asterisk.org/r/2844/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399033 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
You are adding dial strings to the queue, not channels. An aribitrary string
could be used, but you are typically referencing a channel. Correcting the
command help text.
(issue ASTERISK-22263)
(closes issue ASTERISK-22263)
Reported By: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changing text in chan_dahdi.conf sample to be accurate.
(issue ASTERISK-22308)
(closes issue ASTERISK-22308)
Reported By: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we receive a 200 OK without SDP, we will now check to see if
the remote address has been established for that channel's RTP
session and if the to tag for that channel has changed from
the most recent to tag in a response less than 200.
If either a change has been made since the last to-tag was
received or the remote address is unset, then we will drop
the call.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/diff/#index_header
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Race conditions between freeing a nul terminated string and
ast_strdup()'ing it are more likely to be detected if the fence and freed
magic numbers are completely different.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some long-standing bugs in debug threads that were
exacerbated with recent Optional API work in Asterisk 12.
With debug threads enabled, on some systems, there's a lock ordering
problem between our mutex and glibc's mutex protecting its module list
(Ubuntu Lucid, glibc 2.11.1 in this instance). In one thread, the module
list will be locked before acquiring our mutex. In another thread, our
mutex will be locked before locking the module list (which happens in
the depths of calling backtrace()).
This patch fixes this issue by moving backtrace() calls outside of
critical sections that have the mutex acquired. The bigger change was to
reentrancy tracking for ast_cond_{timed,}wait, which wrongly assumed
that waiting on the mutex was equivalent to a single unlock (it actually
suspends all recursive locks on the mutex).
(closes issue ASTERISK-22455)
Review: https://reviewboard.asterisk.org/r/2824/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398648 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
* Reduce indentation in __attempt_transmit().
* Don't update the static last error time variable every time in
__schedule_action() and socket_read().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix stray reference to idle_list in cleanup_thread_list(). This may be
the reason for the note in iax2_process_thread() about threads not being
removed from the task lists.
* Move cleanup_thread_list(&idle_list) to after the other lists are
cleaned up.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix bridgecallno deadlock avoidance. When doing deadlock avoidance, you
need to retest the status of values for each loop to see if you still need
the lock for bridgecallno.
* As a safety check, after acquiring the bridgecallno lock you should
check if iaxs[bridgecallno] is NULL just like the current callno checks.
* Move setting thread->iostate to IAX_IOSTATE_IDLE to after processing any
deferred frames to ensure that the iostate is IDLE when it is placed back
into the idle list. defer_full_frame() tries to ensure
iax2_process_thread() wakes up to process the frame.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix the misdn debug output to remote consoles. chan_misdn uses
ast_console_puts() which doesn't know about verbose levels. Better to use
ast_verbose() instead. Without this patch the misdn debug messages are
appended to the verbose level which ever was set by the message sent to
the console before, i.e. any undefined level.
(closes issue AST-1218)
Reported by: Guenther Kelleter
Patches:
misdnlog.patch (license #6372) patch uploaded by Guenther Kelleter
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398235 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
Fixed a features.c test that leaked a reference to a parked call. This caused
chancount to never reach 0, so graceful shutdown stops. Also added an
unregister test.
(closes issue ASTERISK-22413)
Reported by: Corey Farrell
Patches:
features-TEST_FRAMEWORK.patch uploaded by coreyfarrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
You cannot put the "Testing <blah> pass/fail" on a single line before
actually performing the test. Now any additional failure information is
logged before the test pass/fail announcement.
* Added an additional CDR(answer,u) test.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the SIP channel driver processes an invalid SDP that defines media
descriptions before connection information, it may attempt to reference
the socket address information even though that information has not yet
been set. This will cause a crash.
This patch adds checks when handling the various media descriptions that
ensures the media descriptions are handled only if we have connection
information suitable for that media.
Thanks to Walter Doekes, OSSO B.V., for reporting, testing, and providing
the solution to this problem.
(closes issue ASTERISK-22007)
Reported by: wdoekes
Tested by: wdoekes
patches:
issueA22007_sdp_without_c_death.patch uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A remote exploitable crash vulnerability exists in the SIP channel driver if an
ACK with SDP is received after the channel has been terminated. The handling
code incorrectly assumed that the channel would always be present.
This patch adds a check such that the SDP will only be parsed and applied if
Asterisk has a channel present that is associated with the dialog.
Note that the patch being applied was modified only slightly from the patch
provided by Walter Doekes of OSSO B.V.
(closes issue ASTERISK-21064)
Reported by: Colin Cuthbertson
Tested by: wdoekes, Colin Cutherbertson
patches:
issueA21064_fix.patch uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
