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
When you have lots of SIP peers (according to the issue reporter, around 3500),
the 'sip show peers' CLI command or AMI action can crash due to a poorly placed
string duplication that occurs on the stack. This patch refactors the command
to not allocate the string on the stack, and handles the formatting of a single
peer in a separate function call.
(closes issue ASTERISK-21466)
Reported by: Guillaume Knispel
patches:
fix_sip_show_peers_stack_overflow_asterisk_11.3.0-v2.patch uploaded by gknispel (License 6492)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Way back when in the dark days of Asterisk 1.8.9, blind transferring a call
in a context that included the 'h' extension would inadvertently execute the
hangup code logic on the transferred channel. This was a "bad thing". The fix
was to properly check for the softhangup flags on the channel and only execute
the 'h' extension logic (and, in later versions, hangup handler logic) if the
channel was well and truly dead (Jim).
Unfortunately, CDRs are fickle. Setting the softhangup flag when we detected
that the channel was leaving the bridge (but not to die) caused some crucial
snippet of CDR code, lying in ambush in the middle of the bridging code, to
not get executed. This had the effect of blowing away one of the CDRs that is
typically created during a blind transfer.
While we live and die by the adage "don't touch CDRs in release branches", this
was our bad. The attached patch restores the CDR behavior, and still manages to
not run the 'h' extension during a blind transfer (at least not when it's
supposed to).
Thanks to Steve Davies for diagnosing this and providing a fix.
Review: https://reviewboard.asterisk.org/r/2476
(closes issue ASTERISK-21394)
Reported by: Ishfaq Malik
Tested by: Ishfaq Malik, mjordan
patches:
fix_missing_blindXfer_cdr2 uploaded by one47 (License 5012)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@387036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1.4.24 core sounds includes a full set of Italian prompts for core sounds and a fix for the missing voicemail prompts in the Russian language.
(closes issue ASTERISK-19431)
(closes issue ASTERISK-19721)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@386877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a system allows for its usage, Asterisk will use glob to help parse
Asterisk .conf files. The config file loading routine was leaking the memory
allocated by the glob() routine when the config file was in an unmodified
or invalid state.
This patch properly calls globfree in those off nominal paths.
(closes issue ASTERISK-21412)
Reported by: Corey Farrell
patches:
config_glob_leak.patch uploaded by Corey Farrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@386672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch cleans up two things features:
* It properly unregisters the CLI commands that features registered
* It cancels and performs a pthread_join on the created parking thread. This
not only properly joins a non-detached thread, but also prevents disposing
of the parking lots prior to the parking thread completely exiting.
(closes issue ASTERISK-21407)
Reported by: Corey Farrell
patches:
features_shutdown-r2.patch uploaded by Corey Farrell (License 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@386641 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The two party bridging loops were changing the bridge peer pointers
without the channel locks held. Thus when ast_channel_massquerade()
tested and used the pointer there is a small window of opportunity for the
pointers to become NULL even though the masquerade code has the channels
locked.
(closes issue ASTERISK-21356)
Reported by: William luke
Patches:
jira_asterisk_21356_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: William luke
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@386256 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
Prior to this patch, a read error in snd_pcm_readi would still be treated as a
nominal result when constructing a voice frame from the expected data. Since
the value returned is negative, as opposed to the number of samples read,
this could result in a crash. With this patch, we now return a null frame
when a read error is detected.
Note that the patch on ASTERISK-21329 was modified slightly for this commit,
in that we bail immediately on detecting the read error, rather than bypassing
the construction of the voice frame.
(closes issue ASTERISK-21329)
Reported by: Keiichiro Kawasaki
patches:
chan_alsa.diff uploaded by kawasaki (License 6489)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When app_queue is unloaded, some manager commands are not being unregistered
which result in a segfault. This patch corrects this.
(closes issue ASTERISK-21397)
Reported by: Peter Katzmann, Corey Farrell
Tested by: Corey Farrell
Patches:
asterisk-21397-missing-unreg-manager-cmd_1.8.diff
Michael L. Young (license 5026)
asterisk-21397-missing-unreg-manager-cmd_11.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2444/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original report was that app_voicemail would crash. This was caused by
ast_config_load() returning CONFIG_STATUS_FILEINVALID but no checks being
performed for that return status. After adding the initial patch to fix this
issue, Jaco Kroon (jkroon) added some fixes to memory leaks he had discovered.
During review, Walter Doekes (wdoekes) suggested adding a helper function in
order to determine if we had a valid configuration or not.
This patch does the following:
* Creates a helper function to check if the configuration is valid
* Adds calls to the new helper function where appropiate
* Fixes memory leaks where the code returned without running
ast_config_destroy() on the configuration that was loaded
(closes issue ASTERISK-21302)
Reported by: Jaco Kroon
Tested by: Jaco Kroon, Michael L. Young
Patches:
asterisk-11.3.0-app_voicemail-ast_config-fixes.patch
Jaco Kroon (license 5671)
asterisk-21302-valid_cfg_and_mem_leaks_v3-1.8.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2443/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On startup, it's possible for a frame to arrive before the processing threads were ready.
In iax2_process_thread() the first pass through falls into ast_cond_wait, should a frame arrive
before we are at ast_cond_wait, the signal will be ignored.
The result iax2_process_thread stays at ast_cond_wait forever, with deferred frames being queued.
Fix: When creating initial idle iax2_process_threads, wait for init_cond to be signalled
after each thread is started.
(issue ASTERISK-18827)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2427/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385402 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 a BYE request is processed in chan_sip, the current SIP dialog is detached
from its associated Asterisk channel structure. The tech_pvt pointer in the
channel object is set to NULL, and the dialog persists for an RFC mandated
period of time to handle re-transmits.
While this process occurs, the channel is locked (which is good).
Unfortunately, operations that are initiated externally have no way of knowing
that the channel they've just obtained (which is still valid) and that they are
attempting to lock is about to have its tech_pvt pointer removed. By the time
they obtain the channel lock and call the channel technology callback, the
tech_pvt is NULL.
This patch adds a few checks to some channel callbacks that make sure the
tech_pvt isn't NULL before using it. Prime offenders were the DTMF digit
callbacks, which would crash if AMI initiated a DTMF on the channel at the
same time as a BYE was received from the UA. This patch also adds checks on
sip_transfer (as AMI can also cause a callback into this function), as well
as sip_indicate (as lots of things can queue an indication onto a channel).
Review: https://reviewboard.asterisk.org/r/2434/
(closes issue ASTERISK-20225)
Reported by: Jeff Hoppe
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385170 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a line showing the mapping of "mysql" to res_config_mysql available in add-ons. We used "mysql" as an example driver key in the sample, but didn't show what module it mapped too. Also added a subtitle above the list of keys for driver backends.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The initial report was that the "nat" setting in the [general] section was not
having any effect in overriding the default setting. Upon confirming that this
was happening and looking into what was causing this, it was discovered that
other default settings would not be overriden as well.
This patch works similar to what occurs in build_peer(). We create a temporary
ast_flags structure and using a mask, we override the default settings with
whatever is set in the [general] section.
In the bug report, the reporter who helped to test this patch noted that the
directmedia settings were being overriden properly as well as the nat settings.
(closes issue ASTERISK-21225)
Reported by: Alexandre Vezina
Tested by: Alexandre Vezina, Michael L. Young
Patches:
asterisk-21225-handle-options-default-prob_1.8_v4.diff.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2386/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@385008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-20904, the focus was around the changes to NAT that took place in
Asterisk 11. Since the report stated that 1.8 was fine, we didn't take a look
at 1.8 at the time.
While working on ASTERISK-21225, I could see that 1.8 would benefit from having
some of those changes applied to it.
This patch does the following:
* The important part of this patch is that it sets the peer's flags earlier in
build_peer so that the code properly uses the peer's flags based on the peer's
configuration.
* constify req parameter in check_via()
* update realtime schemas under the contrib directory to handle properly the NAT
settings available in 1.8 as well as to handle the changes made in 11 to make
upgrading easier when installing newer versions of Asterisk
(closes issue ASTERISK-21243)
Reported by: Michael L. Young
Patches:
asterisk-20904-changes_for_1.8.diff Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2422/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new inband_on_proceeding option causes Asterisk to assume inband audio
may be present when a PROCEEDING message is received.
Q.931 Section 5.1.2 says the network cannot assume that the CPE side has
attached to the B channel at this time without explicitly sending the
progress indicator ie informing the CPE side to attach to the B channel
for audio. However, some non-compliant ISDN switches send a PROCEEDING
without the progress indicator ie indicating inband audio is available and
assume that the CPE device has connected the media path for listening to
ringback and other messages.
ASTERISK-17834 which causes this issue was dealing with a non-compliant
network switch.
(closes issue ASTERISK-21151)
Reported by: Gianluca Merlo
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
func_version.so was being rebuilt every time, because build.h was
changing every build, because of the cleantest dependency that was
added in r384410 to fix parallel make bugs.
Now build.h will only be created if it does not exist, which was the
original behavior of the Makefile.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384544 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Occasionally, make -j would fail due to missing includes, or other
unusual errors.
This was due to the 'cleantest' target, which was designed to force a
make clean when some change in the code would cause the typical
depedency checking to fail. Several targets in the main Makefile did
not depend upon cleantest, hence would run in parallel to it. By
adding the dependency, make -j runs happily now.
Review: https://reviewboard.asterisk.org/r/2418/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
At least one call to run_externnotify provides a NULL context parameter and
because the snprintf statement doesn't account for a NULL context parameter,
it simply writes '(null)' to the arguments string instead. This patch makes
it write two quotes back to back for that argument instead in the event of
a NULL context.
(closes issue ASTERISK-18207)
Reported by: Barry L. Kline
Patches:
modified from patch-20130306 uploaded by Karsten Wemheuer (License 5930)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384325 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at the security vulnerability in ASTERISK-20967, Walter noticed
a file descriptor leak and some other issues in off nominal code paths. This
patch corrects them.
Note that this patch is not related to the vulnerability in ASTERISK-20967,
but the patch was placed on that issue.
(closes issue ASTERISK-20967)
Reported by: wdoekes
patches:
issueA20967_file_leak_and_unused_wkspace.patch uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384118 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
When authenticating a SIP request with alwaysauthreject enabled, allowguest
disabled, and autocreatepeer disabled, Asterisk discloses whether a user
exists for INVITE, SUBSCRIBE, and REGISTER transactions in multiple ways. The
information is disclosed when:
* A "407 Proxy Authentication Required" response is sent instead of a
"401 Unauthorized" response
* The presence or absence of additional tags occurs at the end of "403
Forbidden" (such as "(Bad Auth)")
* A "401 Unauthorized" response is sent instead of "403 Forbidden" response
after a retransmission
* Retransmission are sent when a matching peer did not exist, but not when a
matching peer did exist.
This patch resolves these various vectors by ensuring that the responses sent
in all scenarios is the same, regardless of the presence of a matching peer.
This issue was reported by Walter Doekes, OSSO B.V. A substantial portion of
the testing and the solution to this problem was done by Walter as well - a
huge thanks to his tireless efforts in finding all the ways in which this
setting didn't work, providing automated tests, and working with Kinsey on
getting this fixed.
(closes issue ASTERISK-21013)
Reported by: wdoekes
Tested by: wdoekes, kmoore
patches:
AST-2013-003-1.8 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-10 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-11 uploaded by kmoore, wdoekes (License 6273, 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST-2012-014, fixed in January of this year, contained a fix for Asterisk's
HTTP server for a remotely-triggered crash. While the fix put in place fixed
the possibility for the crash to be triggered, a denial of service vector still
exists with that solution if an attacker sends one or more HTTP POST requests
with very large Content-Length values. This patch resolves this by capping
the Content-Length at 1024 bytes. Any attempt to send an HTTP POST with
Content-Length greater than this cap will not result in any memory allocation.
The POST will be responded to with an HTTP 413 "Request Entity Too Large"
response.
This issue was reported by Christoph Hebeisen of TELUS Security Labs
(closes issue ASTERISK-20967)
Reported by: Christoph Hebeisen
patches:
AST-2013-002-1.8.diff uploaded by mmichelson (License 5049)
AST-2013-002-10.diff uploaded by mmichelson (License 5049)
AST-2013-002-11.diff uploaded by mmichelson (License 5049)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r373424, several reentrancy problems in chan_sip were addressed. As a
result, the SIP channel driver is now properly locking the channel driver
private information in certain operations that it wasn't previously. This
exposed two latent problems either in register_verify or by functions called
by register_verify. This includes:
* Holding the private lock while calling sip_send_mwi_to_peer. This can create
a new sip_pvt via sip_alloc, which will obtain the channel container lock.
This is a locking inversion, as any channel related lock must be obtained
prior to obtaining the SIP channel technology private lock.
* Holding the privat elock while calling sip_poke_peer. In the same vein as
sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing
the same locking inversion.
Note that this locking inversion typically occured when CLI commands were run
while a SIP REGISTER request was being processed, as many CLI commands (such
as 'sip show channels', 'core show channels', etc.) have to obtain the channel
container lock.
(issue ASTERISK-21068)
Reported by: Nicolas Bouliane
(issue ASTERISK-20550)
Reported by: David Brillert
(issue ASTERISK-21314)
Reported by: Badalian Vyacheslav
(issue ASTERISK-21296)
Reported by: Gabriel Birke
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
r375757 attempted to resolve a race condition between multiple submissions of
CDRs while in batch mode from attempting to destroy the scheduled batch
submission by extending the batch CDR lock. Unfortunately, this causes a
deadlock between the pending CDR lock and the batch CDR lock. This patch
resolves the intent of r375757 by simply providing a new lock that protects
the scheduling of the batches. The original batch CDR lock is kept to protect
manipulation of the batch CDR settings, but has been placed such that it
is not held when the pending lock is held.
Thanks to Chase Venters for providing lock analysis on the issue.
(issue ASTERISK-21162)
Reported by: Chase Venters
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383839 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an SLA trunk is ringing (inbound call on the trunk) Asterisk will
make outbound calls to the stations that have that trunk. If more than
one station answers the call at the same time, all channels other than
the first one to answer are left in a bad state. The channel gets
leaked, is not connected to anything, and there's no way to get rid of
it.
We now properly clean up these losing channels by hanging up on them.
Since they lost the race, as we process their answer, there is no
ringing trunk for them to answer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CALLEDTON channel variable is set for incoming ISDN calls to the lower
7 bits of the Q.931 type-of-number/numbering-plan octet. The
CALLERID(dnid-num-plan) should have the same value.
(closes issue ASTERISK-21248)
Reported by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI, HTTP, and chan_sip all support TLS in some way, but none of them
support all the options that Asterisk's TLS core is capable of
interpreting. This prevents consumers of the TLS/SSL layer from setting
TLS/SSL options that they do not support.
This also gets tlsverifyclient closer to a working state by requesting
the client certificate when tlsverifyclient is set. Currently, there is
no consumer of main/tcptls.c in Asterisk that supports this feature and
so it can not be properly tested.
Review: https://reviewboard.asterisk.org/r/2370/
Reported-by: John Bigelow
Patch-by: Kinsey Moore
(closes issue AST-1093)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a session timer expires during a dialog that has re-negotiated to T.38
and Asterisk is the refresher, Asterisk will send a re-INVITE with an SDP
containing audio media only. This causes some hilarity with the poor fax
session under weigh.
This patch corrects that by sending T.38 parameters if we are in the middle of
a T.38 session.
(closes issue ASTERISK-21232)
Reported by: Nitesh Bansal
patches:
dont-send-audio-reinvite-for-sess-timer-in-t38-call.patch uploaded by nbansal (License 6418)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In certain situations, call files are not processed when using KQueue with
pbx_spool. Asterisk was sending an invalid timeout value when the spool
directory is empty, causing the call to kevent to error immediately. This
can create a tight loop, increasing the CPU load on the system.
(closes issue ASTERISK-21176)
Reported by: Carlton O'Riley
patches:
kqueue_osx.patch uploaded by coriley (License 6473)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When retrieving the parking lots from a MySQL database table, the current order
is "filename, cat_metric desc, var_metric asc, category". If there are multiple
parking lots with the same cat_metric but different categories, everything is
being sorted on cat_metric first resulting in errors when loading the parking
lots.
This patch fixes the problem by sorting on the category field first, then the
cat_metric field.
(closes issue ASTERISK-21035)
Reported by: Alex Epshteyn
Patches:
asterisk-21035-orderby.diff Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit updates some fields in the contributed realtime schema files to
handle IPv6 addresses.
(closes issue ASTERISK-21173)
Reported by: Torrey Searle
Patches:
realtime_sql.patch Torrey Searle (license 5334)
asterisk-21173-update-ip-fields.diff Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
