The NAPTR and SRV branches were worked on independently and
resulted in some code being duplicated in each. Since both
have been merged into trunk now, this patch reduces the
duplication by factoring out common code into its own
source files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes autological comparison warnings in the following:
* chan_skinny: letohl may return a signed or unsigned value, depending on the
macro chosen
* func_curl: Provide a specific cast to CURLoption to prevent mismatch
* cel: Fix enum comparisons where the enum can never be negative
* enum: Fix comparison of return result of dn_expand, which returns a signed
int value
* event: Fix enum comparisons where the enum can never be negative
* indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
negative
* presencestate: Use the actual enum value for INVALID state
* security_events: Fix enum comparisons where the enum can never be negative
* udptl: Don't bother to check if the return value from encode_length is less
than 0, as it returns an unsigned int
* translate: Since the parameters are unsigned int, don't bother checking
to see if they are negative. The cast to unsigned int would already blow
past the matrix bounds.
* res_pjsip_exten_state: Use a temporary value to cache the return of
ast_hint_presence_state
* res_stasis_playback: Fix enum comparisons where the enum can never be
negative
* res_stasis_recording: Add an enum value for the case where the recording
operation is in error; fix enum comparisons
* resource_bridges: Use enum value as opposed to -1
* resource_channels: Use enum value as opposed to -1
Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4533.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel enters the bridging system it is first made compatible with
the bridge and then the bridge technology makes the channel compatible
with the technology. For all but the DAHDI native and softmix bridge
technologies the make channel compatible with the bridge step is an
effective noop because the other technologies allow all audio formats.
For the DAHDI native bridge technology it doesn't matter because it is not
an initial bridge technology and chan_dahdi allows only one native format
per channel. For the softmix bridge technology, it is a noop at best and
harmful at worst because the wrong translation path could be setup if the
channel's native formats allow more than one audio format.
This is an intermediate patch for a series of patches aimed at improving
translation path choices.
* Removed code dealing with the unnecessary step of making the channel
compatible with the bridge.
ASTERISK-24841
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4600/
........
Merged revisions 434424 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When registering to a SIP server with TLS, Asterisk will accept CA signed
certificates with a common name that was signed for a domain other than the
one requested if it contains a null character in the common name portion of
the cert. This patch fixes that by checking that the common name length
matches the the length of the content we actually read from the common name
segment. Some certificate authorities automatically sign CA requests when
the requesting CN isn't already taken, so an attacker could potentially
register a CN with something like www.google.com\x00www.secretlyevil.net
and have their certificate signed and Asterisk would accept that certificate
as though it had been for www.google.com - this is a security fix and is
noted in AST-2015-003.
ASTERISK-24847 #close
Reported by: Maciej Szmigiero
Patches:
asterisk-null-in-cn.patch submitted by mhej (license 6085)
........
Merged revisions 434337 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 434338 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434384 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After completing an attended transfer the transfer target channel (the one that
gets swapped out) was not being hung up after leaving the bridge. This resulted
in a channel possibly being left around. Added an explicit softhangup for the
channel in question after the transfer is successfully completed in order to
make sure the channel is hung up.
ASTERISK-24782 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4575/
........
Merged revisions 434240 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.
One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.
In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.
Review: https://reviewboard.asterisk.org/r/4549/
ASTERISK-24922 #close
........
Merged revisions 434216 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These are fixes for compilation under gcc 5.0...
chan_sip.c: In parse_request needed to make 'lim' unsigned.
inline_api.h: Needed to add a check for '__GNUC_STDC_INLINE__' to detect C99
inline semantics (same as clang).
ccss.c: In ast_cc_set_parm, needed to fix weird comparison.
dsp.c: Needed to work around a possible compiler bug. It was throwing
an array-bounds error but neither
sgriepentrog, rmudgett nor I could figure out why.
manager.c: In action_atxfer, needed to correct an array allocation.
This patch will go to 11, 13, trunk.
Review: https://reviewboard.asterisk.org/r/4581/
Reported-by: Jeffrey Ollie
Tested-by: George Joseph
ASTERISK-24932 #close
........
Merged revisions 434113 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434114 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Versions of Asterisk prior to 12 defaulted to 8000 as a sample rate
if one was not provided by a format. In Asterisk 13, this was removed.
The result was that some calculations which involve dividing by the
sample rate resulted in dividing by 0. The fix being put in place
here is to have the same default fallback that was present in previous
versions of Asterisk.
Asterisk-24914 #close
Reported by Marcello Ceschia
........
Merged revisions 434046 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds support for parsing SRV records and consuming their values
in an easy fashion. It also adds automatic sorting of SRV records according
to RFC 2782.
Tests have also been included which cover parsing, sorting, and off-nominal
cases where the record is corrupted.
ASTERISK-24931 #close
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/4528/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some invalid enum conversion warnings caught by clang. In
particular:
* chan_sip: Several functions mixed usage of the st_refresher_param
enum and st_refresher enum. This patch corrects the functions to use the
right enum.
* chan_pjsip: Fixed mixed usage of ast_sip_session_t38state and ast_t38_state.
* strings: Fixed incorrect usage of AO2 flags with strings container.
* res_stasis: Change a return enumeration to stasis_app_user_event_res.
Review: https://reviewboard.asterisk.org/r/4535
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4535.patch submitted by dkdegroot (License 6600)
........
Merged revisions 433746 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433747 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The patch in r433720 caused a warning to be kicked back by gcc. It occurred
due to this check in unistd.h:
if (__nbytes > __bos0 (__buf))
return __read_chk_warn (__fd, __buf, __nbytes, __bos0 (__buf));
That is, if __nbytes is greater than the result of GCC's built-in object size
for the struct, we'll kick back a warning.
As it turns out, this is because there is an error in the code in the patch.
We are passing the address of the pointer to the struct, not iev, which is a
pointer to the struct. Hence, the number of bytes is probably going to be lot
larger than the number of bytes that make up a pointer! This patch changes
the code just read from the pointer to the struct - which fixes the warning.
ASTERISK-24917
........
Merged revisions 433743 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433744 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433745 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces a new logger routine ast_log_safe. This routine should be
used for all error messages in code that can be run as a result of ast_log.
ast_log_safe does nothing if run recursively. All error logging in
astobj2.c, strings.c and utils.h have been switched to ast_log_safe.
This required adding support for raw threadstorage. This provides direct
access to the void* pointer in threadstorage. In ast_log_safe, NULL is used
to signify that this thread is not already running ast_log_safe, (void*)1 when
it is already running. This was done since it's critical that ast_log_safe
do nothing that could log during recursion checking.
ASTERISK-24155 #close
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/4502/
........
Merged revisions 433522 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433523 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since 'core stop now' and 'core restart now' do not stop modules,
it is unsafe for most of the core to run cleanups. Originally all
cleanups used ast_register_atexit, and were only changed when it
was shown to be unsafe. ast_register_atexit is now used only when
absolutely required to prevent corruption and close child processes.
Exceptions that need to use ast_register_atexit:
* CDR: Flush records.
* res_musiconhold: Kill external applications.
* AstDB: Close the DB.
* canary_exit: Kill canary process.
ASTERISK-24142 #close
Reported by: David Brillert
ASTERISK-24683 #close
Reported by: Peter Katzmann
ASTERISK-24805 #close
Reported by: Badalian Vyacheslav
ASTERISK-24881 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4500/
Review: https://reviewboard.asterisk.org/r/4501/
........
Merged revisions 433495 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433497 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Attempting to execute DTMF in a confbridge while file playback (prompt,
announcement, etc) is occurring is not allowed. You have to wait until
the sound file has completed before entering DTMF. This patch fixes it
so that app_confbridge now monitors for dtmf key presses during menu
driven file playback. If a key is pressed playback stops and it executes
the matched menu option.
ASTERISK-24864 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4510/
........
Merged revisions 433445 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433446 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* In res/res_sorcery_realtime.c: Broke long line.
* In main/bucket.c: Eliminated unnecessary NULL check as
ast_sorcery_unref() is NULL tolerant and set the global object to NULL
after unref in the system shutdown bucket_cleanup().
........
Merged revisions 433420 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433421 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an abstracted core DNS API which resembles the API described
here[1]. The API provides a pluggable mechanism for resolvers and also a
consistent view for records. Both synchronous and asynchronous queries are
supported.
This change also adds a res_resolver_unbound module which uses the libunbound
library to provide resolution.
Unit tests have also been written for all of the above to confirm the API and
functionality.
ASTERISK-24834 #close
Reported by: Matt Jordan
ASTERISK-24836 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4474/
Review: https://reviewboard.asterisk.org/r/4512/
[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+DNS+API
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found a memory leak and invalid access.
* Fix invalid access by sscanf() being fed a non-nul terminated string of
digits in res/res_pjsip_sdp_rtp.c:get_codecs().
* Fix memory leak in main/sorcery.c:sorcery_object_field_destructor().
* Fix potential NULL pointer dereference in
main/xmldoc.c:xmldoc_get_syntax_config_option().
Review: https://reviewboard.asterisk.org/r/4513/
........
Merged revisions 433199 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found some memory leaks associated with ast_sockaddr_resolve().
Most of the leaks had already been fixed by earlier memory leak hunt
patches. This patch performs an audit of ast_sockaddr_resolve() and found
one more.
* Fix ast_sockaddr_resolve() memory leak in
apps/app_externalivr.c:app_exec().
* Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs
parameter for safety so the pointer will never be uninitialized on return.
The same goes for res/res_pjsip_acl.c:extract_contact_addr().
* Made functions that call ast_sockaddr_resolve() with RAII_VAR()
controlling the addrs variable use ast_free instead of ast_free_ptr to
provide better MALLOC_DEBUG information.
Review: https://reviewboard.asterisk.org/r/4509/
........
Merged revisions 433056 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433057 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In realtime, it is normal to have a database with both 'allow' and 'disallow'
columns in the schema. It is perfectly valid to have an 'allow' value of
'!all,g722,ulaw,alaw' and no 'disallow' value. Unlike in static conf files,
you can't *not* provide the disallow value. Thus, the empty disallow value
causes a spurious WARNING message, which is kind of annoying.
This patch makes it so that a 'disallow' value with no ... value ... is
ignored. Granted, you can still screw this up as well, as technically
specifying 'disallow=all,!ulaw' allows only ulaw, and then you would have no
'allow' value in your database. But really, why would you do that? WHY?
ASTERISK-16779 #close
Reported by: Atis Lezdins
........
Merged revisions 432970 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432971 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 432834 introduced a build error when MALLOC_DEBUG
is used. Switch callid threadstorage to simple
AST_THREADSTORAGE since we no longer need custom cleanup.
Reported by: Corey Farrell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432851 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Switch logger callid's from AO2 objects to simple integers.
This helps in two ways. Copying integers is faster than
referencing AO2 objects, so this will result in a small
reduction in logger overhead. This also erases the possibility
of an infinate loop caused by an invalid callid in
threadstorage.
ASTERISK-24833 #comment Committed callid conversion to trunk.
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4466/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an audiohook is created (which is used by the various Spy applications
and Snoop channel in Asterisk 13+), it initially is given a sample rate of
8kHz. It is expected, however, that this rate may change based on the media
that passes through the audiohook. However, the read/write operations on the
audiohook behave very differently.
When a frame is written to the audiohook, the format of the frame is checked
against the internal sample rate. If the rate of the format does not match
the internal sample rate, the internal sample rate is updated and a new SLIN
format is chosen based on that sample rate. This works just fine.
When a frame is read, however, we do something quite different. If the format
rate matches the internal sample rate, all is fine. However, if the rates
don't match, the audiohook attempts to "fix up" the number of samples that
were requested. This can result in some seriously large number of samples
being requested from the read/write factories.
Consider the worst case - 192kHz SLIN. If we attempt to read 20ms worth of
audio produced at that rate, we'd request 3840 samples (192000 / (1000 / 20)).
However, if the audiohook is still expecting an internal sample rate of 8000,
we'll attempt to "fix up" the requested samples to:
samples_converted = samples * (ast_format_get_sample_rate(format) /
(float) audiohook->hook_internal_samp_rate);
which is:
92160 = 3840 * (192000 / 8000)
This results in us attempting to read 92160 samples from our factories, as
opposed to the 3840 that we actually wanted. On a 64-bit machine, this
miraculously survives - despite allocating up to two buffers of length 92160
on the stack. The 32-bit machines aren't quite so lucky. Even in the case where
this works, we will either (a) get way more samples than we wanted; or (b) get
about 3840 samples, assuming the timing is pretty good on the machine.
Either way, the calculation being performed is wrong, based on the API users
expectations.
My first inclination was to allocate the buffers on the heap. As it is,
however, there's at least two drawbacks with doing this:
(1) It's a bit complicated, as the size of the buffers may change during the
lifetime of the audiohook (ew).
(2) The stack is faster (yay); the heap is slower (boo).
Since our calculation is flat out wrong in the first place, this patch fixes
this issue by instead updating the internal sample rate based on the format
passed into the read operation. This causes us to read the correct number of
samples, and has the added benefit of setting the audihook with the right
SLIN format.
Note that this issue was caught by the Asterisk Test Suite as a result of
r432195 in the 13 branch. Because this issue is also theoretically possible
in Asterisk 11, the change is being made here as well.
Review: https://reviewboard.asterisk.org/r/4475/
........
Merged revisions 432810 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432811 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RAII_VAR, which is used extensively in Asterisk to manage reference counted
resources, uses a GCC extension to automatically invoke a cleanup function
when a variable loses scope. While this functionality is incredibly useful
and has prevented a large number of memory leaks, it also prevents Asterisk
from being compiled with clang.
This patch updates the RAII_VAR macro such that it can be compiled with clang.
It makes use of the BlocksRuntime, which allows for a closure to be created
that performs the actual cleanup.
Note that this does not attempt to address the numerous warnings that the clang
compiler catches in Asterisk.
Much thanks for this patch goes to:
* The folks on StackOverflow who asked this question and Leushenko for
providing the answer that formed the basis of this code:
http://stackoverflow.com/questions/24959440/rewrite-gcc-cleanup-macro-with-nested-function-for-clang
* Diederik de Groot, who has been extremely patient in working on getting this
patch into Asterisk.
Review: https://reviewboard.asterisk.org/r/4370/
ASTERISK-24133
ASTERISK-23666
ASTERISK-20399
ASTERISK-20850 #close
Reported by: Diederik de Groot
patches:
RAII_CLANG.patch uploaded by Diederik de Groot (License 6600)
........
Merged revisions 432807 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432808 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The localtime management in the Asterisk core contains a thread that watches
for changes in the local timezone. On systems where the directory containing
/etc/localtime is modified frequently, the thread monitoring the changes will
be woken up to determine if any changes in timezone have occurred. When using
kqueue(2), this can cause a leak of file descriptors due to some improper
management of resources.
This patch updates the kqueue(2) handling in localtime, such that is no longer
leaks resources.
Review: https://reviewboard.asterisk.org/r/4450/
ASTERISK-24739 #close
Reported by: Ed Hynan
patches:
11.15.0-u.diff uploaded by Ed Hynan (Licnese 6680)
11.7.0-u.diff uploaded by Ed Hynan (License 6680)
svn-trunk-Jan-26-2015-u.diff uploaded by Ed Hynan (License 6680)
........
Merged revisions 432691 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432693 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 'core restart now' or 'core stop now' is executed and a channel is
currently in a media operation, the translator matrix can be destroyed while a
channel is currently blocked on getting the best translation choice
(see ast_translator_best_choice). When the channel gets the mutex, the
translation matrix now has invalid memory, and Asterisk crashes.
This patch does two things:
(1) We now only clean up the translation matrix on a graceful shutdown. In that
case, there are no channels, and so there is no risk of this occurring.
(2) We also now set the __matrix and __indextable to NULL. In some initial
backtraces when this occurred, it looked as if there was a memory corruption
occurring, and it wasn't until we determined that something had restarted
Asterisk that the issue became clear. By setting these to NULL on shutdown,
it becomes a bit easier to determine why a crash is occurring.
Note that we could litter the code with NULL checks on the __matrix, but the
act of making the translation matrix cleaned up on shutdown should preclude
this issue from occurring in the first place, and this part of the code needs
to be as fast as possible.
Review: https://reviewboard.asterisk.org/r/4457/
........
Merged revisions 432453 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432455 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sending the following ARI commands caused Asterisk to crash if the JSON
body 'variables' object passes values of types other than strings.
POST /ari/channels
POST /ari/channels/{channelid}
PUT /ari/endpoints/sendMessage
PUT /ari/endpoints/{tech}/{resource}/sendMessage
* Eliminated RAII_VAR usage in ast_ari_channels_originate_with_id(),
ast_ari_channels_originate(), ast_ari_endpoints_send_message(), and
ast_ari_endpoints_send_message_to_endpoint().
ASTERISK-24751 #close
Reported by: jeffrey putnam
Review: https://reviewboard.asterisk.org/r/4447/
........
Merged revisions 432404 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a self-destruction option to the
dial api. The usefulness of this is mostly when
using async mode to spawn a separate thread used
to handle the new call, while the calling thread
is allowed to go on about other business.
The only alternative to this option would be the
calling thread spawning a new thread, or hanging
around itself waiting to destroy the dial struct
after completion.
Example of use (minus error checking):
struct ast_dial *dial = ast_dial_create();
ast_dial_append(dial, "PJSIP", "200", NULL);
ast_dial_option_global_enable(dial, AST_DIAL_OPTION_ANSWER_EXEC, "Echo");
ast_dial_option_global_enable(dial, AST_DIAL_OPTION_SELF_DESTROY, NULL);
ast_dial_run(dial, NULL, 1);
The dial_run call will return almost immediately
after spawning the new thread to run and monitor
the dial. If the call is answered, it is placed
into the echo app. When completed, it will call
ast_dial_destroy() on the dial structure.
Note that any allocations made to pass values to
ast_dial_set_user_data() or dial options must be
free'd in a state callback function on any of:
AST_DIAL_RESULT_UNASWERED,
AST_DIAL_RESULT_ANSWERED,
AST_DIAL_RESULT_HANGUP, or
AST_DIAL_RESULT_TIMEOUT.
Review: https://reviewboard.asterisk.org/r/4443/
........
Merged revisions 432385 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432386 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, SDP offers negotiating SDES-SRTP crypto attributes would
be rejected if those crypto attributes contained either a key lifetime or a
MKI parameter. While from a theoretical point of view this was defensible -
Asterisk does not support key lifetimes or multiple crypto keys - from a
practical point of view, this is quite a problem. A large number of endpoints
offer lifetimes/MKI, which Asterisk can tolerate so long as it doesn't actually
have to support anything more than a single key or refresh the key.
In reality, this is (so far as we've seen) always the case.
This patch is a forward port of Olle's work in the lingon-srtp-key-lifetime-1.8
branch. To quote Olle from ASTERISK-17721, it handles lifetime/MKI parameters
in the following fashion:
> The Lingon branch now handle lifetime and MKI parameters.
>
> We only accept lifetimes up to max for the crypto and higher than 10 hours
> for packetization of 20 ms (50 pps).
>
> We only handle MKI with index 1.
>
> We do not really bother with counting packets and reinviting at end of
> lifetime, so the min of 10 hours kind of takes care of most calls. If there
> are longer ones, we rely on the other side for re-invites.
>
> It's still not perfect, but I personally think this is an improvement. A
> configuration option for minimum lifetime accepted could be added.
When the patch was ported forward, I decided against adding a configuration
option as Olle's handling was more than sufficient for every case I've seen
come through the issue tracker or through interoperability testing. We can
revisit that decision if it proves to be false.
A few small other tweaks were made to the surrounding code to reduce
indentation and provide better type safety for the 'tag' parameter.
Review: https://reviewboard.asterisk.org/r/4419/
Review: https://reviewboard.asterisk.org/r/4418/
ASTERISK-17721 #close
Reported by: Terry Wilson
ASTERISK-17899 #close
Reported by: Dwayne Hubbard
patches:
lingon-srtp-key-lifetime-1.8.diff uploaded by oej (License 5267)
ASTERISK-20233
Reported by: tootai
ASTERISK-22748
Reported by: Alejandro Mejia
........
Merged revisions 432239 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432258 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432259 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
listener() opens the same code block in two places (#if and #else). This
confuses some folding editors causing it to think that an extra code block
was opened. Folding in 'geany' causes all code after listener() to be
folded as if it were part of that procedure.
ASTERISK-24813 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4435/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Processing an AOC-E event that does not or no longer has a channel
association causes a crash.
The problem with posting AOC events to the channel topic is that AOC-E
events don't always have a channel association and posting the event to
the all channels topic is just wrong. AOC-E events do however have their
own charging association method to refer to the agreement with the
charging entity.
* Changed the AOC events to post to the AMI manager topic instead of the
channel topics. If a channel is associated with the event then channel
snapshot information is supplied with the AMI event.
* Eliminated RAII_VAR() usage in aoc_to_ami() and ast_aoc_manager_event().
This patch supercedes the patch on Review: https://reviewboard.asterisk.org/r/4427/
ASTERISK-22670 #close
Reported by: klaus3000
ASTERISK-24689 #close
Reported by: Marcel Manz
ASTERISK-24740 #close
Reported by: Panos Gkikakis
Review: https://reviewboard.asterisk.org/r/4430/
........
Merged revisions 431974 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some distributions are going to disable SSLv3 at compile time. This option can
be checked using the directive OPENSSL_NO_SSL3_METHOD. This patch updates the
TCP/TLS handling in Asterisk to look for that directive before attempting to
use the SSLv3 specific methods.
ASTERISK-24799 #close
Reported by: Alexander Traud
patches:
no-ssl3-method.patch uploaded by Alexander Traud (License 6520)
........
Merged revisions 431936 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431937 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
........
Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The act of defining wizards for an object type in sorcery.conf will
create a minimal object type. This can cause a problem when a module
has multiple sorcery instances (which all get the wizards from sorcery.conf
applied) but the sorcery instances do not all contain full information
about the object types. Upon loading errors will occur stating that
the objects can not be created. This is confusing and is actually
perfectly fine.
This change makes it so that only object types which have been fully
defined will be loaded.
ASTERISK-24748 #close
Reported by: Joshua Colp
........
Merged revisions 431538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a new config property [servername] to the http.conf file; updated the http server to use the new property when sending responses, for showing http status through the CLI and when reporting status through the 'httpstatus' webpage. In this version, [servername] is uncommented by default.
ASTERISK-24316 #close
Reported By: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4374/
........
Merged revisions 431471 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread. This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.
To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer. Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.
ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
........
Merged revisions 431450 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a CLI "module reload" command when there are new pjsip.conf
registration objects defined frequently failed to load them correctly.
What happens is a race condition between res_pjsip pushing its reload into
an asynchronous task processor task and the thread that does the rest of
the reloads when it gets to reloading the res_pjsip_outbound_registration
module. A similar race condition happens between a reload and the CLI/AMI
show registrations commands. The reload updates the current_states
container and the CLI/AMI commands call get_registrations() which builds a
new current_states container.
* Made res_pjsip.c reload_module() use ast_sip_push_task_synchronous()
instead of ast_sip_push_task() to eliminate two threads processing config
reloads at the same time.
* Made get_registrations() not replace the global current_states container
so the CLI/AMI show registrations command cannot interfere with reloading.
You could never add/remove objects in the container without the
possibility of the container being replaced out from under you by
get_registrations().
* Added a registration loaded sorcery instance observer to purge any dead
registration objects since get_registrations() cannot do this job anymore.
The struct ast_sorcery_instance_observer callbacks must be used because
the callback happens inline with the load process. The struct
ast_sorcery_observer callbacks are pushed to a different thread.
* Added some global current_states NULL pointer checks in case the
container disappears because of unload_module().
* Made sorcery's struct ast_sorcery_instance_observer.object_type_loaded
callbacks guaranteed to be called before any struct
ast_sorcery_observer.loaded callbacks will be called.
* Moved the check for non-reloadable objects to before the sorcery
instance loading callbacks happen to short circuit unnecessary work.
Previously with non-reloadable objects, the sorcery instance
loading/loaded callbacks would always happen, the individual wizard
loading/loaded would be prevented, and the non-reloadable type logging
message would be logged for each associated wizard.
ASTERISK-24729 #close
Review: https://reviewboard.asterisk.org/r/4381/
........
Merged revisions 431243 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431251 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While running through some scenarios using chan_sip and tcp a problem would
occur that resulted in a flood of bad file descriptor messages on the cli:
tcptls.c:712 ast_tcptls_server_root: Accept failed: Bad file descriptor
The message is received because the underlying socket has been closed, so is
valid. This is probably happening because unloading of chan_sip is not atomic.
That however is outside the scope of this patch. This patch simply stops the
logging of multiple occurrences of that message.
ASTERISK-24728 #close
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4380/
........
Merged revisions 431218 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431219 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the original patch causing memory corruptions it was removed until the
problem could be resolved. This patch is the original patch plus some added
locking around stasis router subcription that was needed to avoid the memory
corruption.
Description of the original problem and patch (still applicable):
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4363/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........
Merged revisions 431179 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes two issues:
1. During a swap operation bridging added the new channel before having the swap channel
leave. This was not handled in bridge_native_rtp and could result in a channel not getting
reinvited back to Asterisk. After this change the swap channel will leave first and the
new channel will then join.
2. If a re-invite was received after a session had been established any upstream elements
(such as bridge_native_rtp) were not notified that they may want to re-evaluate things.
After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs
and upstream can react.
AST-1524 #close
Review: https://reviewboard.asterisk.org/r/4378/
........
Merged revisions 431157 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.
* Fixed __attribute__ decls in route.h to be portable.
* Fixed htonll and ntohll to work when they are defined as macros.
* Replaced sem_t usage with our ast_sem wrapper.
* Added ast_sem_timedwait to our ast_sem wrapper.
* Fixed some GCC 4.9 warnings using sig*set() functions.
* Fixed some format strings for portability.
* Fixed compilation issues with res_timing_kqueue (although tests still fail
on OS X).
* Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
on OS X).
ASTERISK-24539 #close
Reported by: George Joseph
ASTERISK-24544 #close
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/4327/
........
Merged revisions 431092 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a crash was fixed due to usage of the REALTIME function in r423003, a
regression was introduced into ast_update2_realtime where the update fields
passed to the function would be skipped and the lookup field processed twice.
The use of this function is a bit interesting: A variable argument list is
used with two sentinel values - the first marks the end of the lookup
fields/values; the second marks the end of the update fields/values.
Unfortunately, ast_update2_realtime parses over the lookup fields twice, as
opposed to parsing over the update fields. This causes the lookups to succeed,
but the updates itself to have no effect.
Note that the most common instance of this problem occurred in app_voicemail
during the updating of a mailbox password.
Thanks to the issue reporter, Paddy Grice, for pointing out the problem.
Review: https://reviewboard.asterisk.org/r/4356/
ASTERISK-24231
ASTERISK-24626 #close
Reported by: Paddy Grice
........
Merged revisions 431072 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431073 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When code imparts a channel into a bridge to swap with another channel, a
ref needs to be held on the swap channel to ensure that it cannot
dissapear before finding it in the bridge.
* The ast_bridge_join() swap channel parameter now always steals a ref for
the swap channel. This is the only change to the bridge framework's
public API semantics.
* bridge_channel_internal_join() now requires the bridge_channel->swap
channel to pass in a ref.
ASTERISK-24649
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4354/
........
Merged revisions 430975 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the RTCP reports are created, the NTP timestamps are stored as strings,
as JSON does not have an integer type long enough to store the value. However,
on 32-bit systems, a signed long may overflow for some portion of the
timestamp.
This patch corrects the overflow by formatting the timestamps as unsigned
longs.
........
Merged revisions 430840 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a hint gets created, any subsequent device or presence
state changes result in extension status events getting sent
out to interested parties. However, at the time of hint creation,
no such event gets sent out, so watchers of extension state are
potentially left in the dark until the first state change after
hint creation.
Patch contributed by John Hardin (License #6512)
........
Merged revisions 430776 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4311/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........
Merged revisions 430628 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Reverted the change to astman_send_listack() to not use the listflag
parameter and always set the value to "Start" so the start capitalization
is consistent. Unfortunately changing the case of a returned value is not
a backward compatible change so for now FAXSessions is going to have to
remain inconsistent with all of the other AMI list actions.
* Reverted the minor protocol error fix in action_getconfig() when no
requested categories are found. Each line needs to be formatted as
"Header: text".
Caught by the testsuite.
ASTERISK-24049
........
Merged revisions 430528 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The security event log uses a dynamic log level (SECURITY) that is registered
with the Asterisk logging core. Unfortunately, the syslog would ignore log
statements that had a dynamic log level associated with them. Because the
syslog cannot handle ad hoc dynamic log levels, this patch treats any dynamic
log entries sent to the syslog as logs with a level of NOTICE.
ASTERISK-20744 #close
Reported by: Michael Keuter
Tested by: Michael L. Young, Jacek Konieczny
patches:
asterisk-20744-syslog-dynamic-logging_trunk.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 430506 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 430507 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When app_bridge grabs a channel and puts it into
a bridge, the channel should then continue where
it left off in the dialplan after the bridge has
ended. Although it stores the current dialplan
location as an after bridge goto on the channel,
it was executing the same priority again instead
of going to the next priority. By swapping the
"specific" version of bridge_set_after_goto with
bridge_set_after_go_on, the next priority in the
dialplan is executed instead.
ASTERISK-24637 #close
Review: https://reviewboard.asterisk.org/r/4322/
Reported by: John Bigelow
........
Merged revisions 430467 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430468 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList
* Incremented the AMI version to 2.7.0.
* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start". The corresponding complete event always used "Complete".
* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.
* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots(). Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.
* Fixed minor protocol error in action_getconfig() when no requested
categories are found. Each line needs to be formatted as "Header: text".
* Fixed off-nominal memory leak in manager_build_parked_call_string().
* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().
ASTERISK-24049 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4315/
........
Merged revisions 430434 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Let's say you have a template T with variable VAR1 = ON and you have a
context C(T) that doesn't specify VAR1. If you read C, the effective value
of VAR1 is ON. Now you change T VAR1 to OFF and call
ast_config_text_file_save. The current behavior is that the file gets
re-written with T/VAR1=OFF but C/VAR1=ON is added. Personally, I think this
is a bug. It's preserving the effective state of C even though I didn't
specify C/VAR1 in th first place. I believe the behavior should be that if
I didn't specify C/VAR1 originally, then the effective value of C/VAR1 should
continue to follow the inherited state. Now, if I DID explicitly specify
C/VAR1, the it should be preserved even if the template changes.
Even though I think the existing behavior is a bug, it's been that way forever
so I'm not changing it. Instead, I've created ast_config_text_file_save2()
that takes a bitmask of flags, one of which is to preserve the effective context
(the current behavior). The original ast_config_text_file_save calls *2 with
the preserve flag. If you want the new behavior, call *2 directly without a
flag.
I've also updated Manager UpdateConfig with a new parameter
'PreserveEffectiveContext' whose default is 'yes'. If you want the new behavior
with UpdateConfig, set 'PreserveEffectiveContext: no'.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4297/
........
Merged revisions 430295 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r428708 additional codecs were added including
a payload type of 128 which is outside of nominal
range of 0-127. This change moves changes 128 to
96 to avoid causing a pjsip assertion when making
a call to an endpoint configured with allow=all.
ASTERISK-24367 #close
Review: https://reviewboard.asterisk.org/r/4286/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We only need to hold the context_merge_lock once. Locking it twice will make
many other parts of Asterisk very sad.
ASTERISK-24641 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the initial DTMF atxfer call attempt to the transfer target fails to
answer during a blonde transfer, the recall callback channels do not get
setup with information from the initial transferrer channel. As a result,
the recall callback to the transferrer does not have callid, channel
variables, datastores, accountcode, peeraccount, COLP, and CLID setup. A
similar situation happens with the recall callback to the transfer target
but it is less visible. The recall callback to the transfer target does
not have callid, channel variables, datastores, accountcode, peeraccount,
and COLP setup.
* Added missing information to the recall callback channels before
initiating the call. callid, channel variables, datastores, accountcode,
peeraccount, COLP, and CLID
* Set callid of the transferrer channel on the DTMF atxfer controller
thread attended_transfer_monitor_thread().
* Added missing channel unlocks and props unref to off nominal paths in
attended_transfer_properties_alloc().
ASTERISK-23841 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4259/
........
Merged revisions 430034 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the ability for channel drivers to supply presence information
in a similar manner to device state. The patch does not provide any channel
driver implementations, but it does provide the core infrastructure necessary
for channel drivers to provide such information.
The core handles multiple providers of presence state information. Ordering
of presence state is as follows:
INVALID < NOT_SET < AVAILABLE < UNAVAILABLE < CHAT < AWAY < XA < DND
Each provider can trump the previous if it provides a presence state that
supercedes a previous one.
Review: https://reviewboard.asterisk.org/r/4050
ASTERISK-24363 #close
Reported by: Gareth Palmer
patches:
chan_presencestate-428146.patch uploaded by Gareth Palmer (License 5169)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After a blond transfer (start attended and hang up)
to a destination that also hangs up without answer,
the Local;1 channel was leaked and would show up on
core show channels. This was happening because the
attended state blond_nonfinal_enter() resetting the
props->transfer_target to null while releasing it's
own reference, which would later prevent props from
releasing another reference during destruction. The
change made here is simply to not assign the target
to NULL.
ASTERISK-24513 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4262/
........
Merged revisions 429826 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429827 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AST_FLAG_BRIDGE_DUAL_REDIRECT_WAIT flag was created to prevent bridges from
prematurely acting on orphaned channels in bridges. The problem with the AMI
redirect action was that it was setting this flag on channels based on the presence
of a PBX, not whether the channel was in a bridge. Whether a channel has a PBX
is irrelevant, so the condition has been altered to check if the channel is in a
bridge.
ASTERISK-24536 #close
Reported by Niklas Larsson
Review: https://reviewboard.asterisk.org/r/4268
........
Merged revisions 429741 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429745 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
........
Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch started with David Lee's patch at
https://reviewboard.asterisk.org/r/2826/ and includes a regression fix
introduced by the ASTERISK-22455 patch.
The initialization of a mutex's lock tracking structure was not protected
in a critical section. This is fine for any mutex that is explicitly
initialized, but a static mutex may have its lock tracking double
initialized if multiple threads attempt the first lock simultaneously.
* Added a global mutex to properly serialize initialization of the lock
tracking structure. The painful global lock can be mitigated by adding a
double checked lock flag as discussed on the original review request.
* Defer lock tracking initialization until first use.
* Don't be "helpful" and initialize an uninitialized lock when
DEBUG_THREADS is enabled. Debug code is not supposed to fix or change
normal code behavior. We don't need a lock initialization race that would
force a re-setup of lock tracking. Lock tracking already handles
initialization on first use.
* Properly handle allocation failures of the lock tracking structure.
* No need to initialize tracking data in __ast_pthread_mutex_destroy()
just to turn around and destroy it.
The regression introduced by ASTERISK-22455 is the result of manipulating
a pthread_mutex_t struct outside of the pthread library code. The
pthread_mutex_t struct seems to have a global linked list pointer member
that can get changed by other threads. Therefore, saving and restoring
the contents of a pthread_mutex_t struct is a bad thing.
Thanks to Thomas Airmont for finding this obscure regression.
* Don't overwrite the struct ast_lock_track.reentr_mutex member to restore
tracking data in __ast_cond_wait() and __ast_cond_timedwait(). The
pthread_mutex_t struct must be treated as a read-only opaque variable.
Miscellaneous other items fixed by this patch:
* Match ast_suspend_lock_info() with ast_restore_lock_info() in
__ast_cond_timedwait().
* Made some uninitialized lock sanity checks return EINVAL and try a
DO_THREAD_CRASH.
* Fix bad canlog initialization expressions.
ASTERISK-24614 #close
Reported by: Thomas Airmont
Review: https://reviewboard.asterisk.org/r/4247/
Review: https://reviewboard.asterisk.org/r/2826/
........
Merged revisions 429539 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When shutting down Asterisk the codecs are cleaned up. As a result anything
attempting to get a codec based on ID or details will find that no codec
exists. This currently occurs when determining the sample count of a frame.
This code did not take this situation into account.
This change fixes this by getting the codec directly from the format and
eliminates the lookup. This is both faster and also provides a guarantee
that the codec will exist and will be valid.
ASTERISK-24604 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4260/
........
Merged revisions 429497 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When endpoints with direct_media enabled, behind a firewall (Asterisk on a
separate network) and were bridged sometimes Asterisk would send the ip
address of the firewall in the sdp to one of the phones in the reinvite
resulting in one way audio. When sending the reinvite Asterisk will retrieve
the media address from the associated rtp instance, but if frames were being
read this can be overwritten with another address (in this case the
firewall's). This patch ensures that Asterisk uses the original device
address when using direct media.
ASTERISK-24563
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4216/
........
Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects several bugs that currently exist in the stasis
application code.
* After a masquerade, the resulting channels have channel topics that
do not match their uniqueids
** Masquerades now swap channel topics appropriately
* StasisStart and StasisEnd messages are leaked to observer
applications due to being published on channel topics
** StasisStart and StasisEnd publishing is now properly restricted
to controlling apps via app topics
* Race conditions exist where StasisStart and StasisEnd messages due to
a masquerade may be received out of order due to being published on
different topics
** These messages are now published directly on the app topic so this
is now a non-issue
* StasisEnds are sometimes missing when sent due to masquerades and
bridge swaps into and out of Stasis()
** This was due to StasisEnd processing adjusting message-sent flags
after Stasis() had already exited and Stasis() had been re-entered
** This was corrected by adjusting these flags prior to sending the
message while the initial Stasis() application was still shutting
down
Review: https://reviewboard.asterisk.org/r/4213/
ASTERISK-24537 #close
Reported by: Matt DiMeo
........
Merged revisions 429061 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429062 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a race condition between the raising of test AMI events (which
drive many tests in the Asterisk Test Suite) and other AMI events. Prior to
this patch, the Stasis messages published to the test topic were not forwarded
to the AMI topic. Instead, the code in manager had a dedicated handler for test
messages that was independent of the topics forwarded to the AMI topic. This
results in no synchronization between the test messages and the rest of the
Stasis messages published out over AMI. In some test with very tight timing
constraints, this can result in out of order messages and spurious test
failures. Properly forwarding the Test Suite topic to the AMI topic ensures
that the messages are synchronized properly.
This patch does that, and moves the message handling to the Stasis definition
of the Test Suite message in test.c as well.
Review: https://reviewboard.asterisk.org/r/4221/
........
Merged revisions 428945 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428946 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When shutting down Asterisk that has an active AMI connection, you get
several "failed to extend from %d to %d" messages because use of the
EVENT_FLAG_SHUTDOWN attempts to add all AMI permission strings to the
event.
* Created MAX_AUTH_PERM_STRING to use when creating stack based struct
ast_str variables used with the authority_to_str() and
user_authority_to_str() functions instead of a variety of magic numbers
that could be too small.
* Added a special check for EVENT_FLAG_SHUTDOWN to authority_to_str() so
it will not attempt to add all permission level strings.
Review: https://reviewboard.asterisk.org/r/4200/
........
Merged revisions 428570 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428571 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428572 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a result of https://reviewboard.asterisk.org/r/3305, res_sorcery_realtime
was tossing database fields that didn't have an exact match to a sorcery
registered field. This broke the ability to use regexes as field names which
manifested itself as a failure of res_pjsip_phoneprov_provider which uses
this capability. It also broke handling of fields that start with '@' in
realtime but I don't think anyone noticed.
This patch does the following...
* Modifies ast_sorcery_fields_register to pre-compile the name regex.
* Modifies ast_sorcery_is_object_field_registered to test the regex if it
exists instead of doing an exact strcmp.
* Modifies res_pjsip_phoneprov_provider with a few tweaks to get it to work
with realtime.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4185/
........
Merged revisions 428543 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428544 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r428165, two bugs were introduced:
* Prior to entering the features retry loop, the buffer that holds the
collected digits is wiped. However, this inadvertently wipes out the
first collected digit on the first pass through, which is obtained
in ast_stream_and_wait. This caused all of the features tests to fail.
* If ast_app_dtget returns a hangup (-1), the loop would retry incorrectly.
If we detect a hangup, we have to stop trying the feature.
This patch fixes both issues.
Review: https://reviewboard.asterisk.org/r/4196/
........
Merged revisions 428505 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk - in res_rtp_asterisk - only understands a single RTCP report info
block. When the RTCP information was refactored in the RTP Engine to be pushed
over the Stasis message bus, I put in the hooks into the engine to handle
multiple RTCP report info blocks, in the hope that a future RTP implementation
would be able to provide that data. Unfortunately, res_rtp_asterisk has a
tendency to "lie":
(1) It will send RTCP reports with a reception_report_count greater than 1
(which is pulled directly from the RTCP packet itself, so that part is
correct)
(2) It will only provide a single report block
When the rtp_engine goes to convert this to a JSON blob, hilarity ensues as it
looks for a report block that doesn't exist.
This patch updates the rtp_engine to be a bit more skeptical about what it is
presented with. While this could also be fixed in res_rtp_asterisk, this patch
prefers to fix it in the engine for two reasons:
(1) The engine is designed to work with multiple RTP implementation, and hence
having it be more robust is a good thing (tm)
(2) res_rtp_asterisk's handling of RTCP information is "fun". It should report
the correct reception_report_count; ideally it should also be giving us all
of the blocks - but it is *definitely* not designed to do that. Going down
that road is a non-trivial effort.
Review: https://reviewboard.asterisk.org/r/4158/
ASTERISK-24489 #close
Reported by: Gregory Malsack
Tested by: Gregory Malsack
ASTERISK-24498 #close
Reported by: Beppo Mazzucato
Tested by: Beppo Maazucato
........
Merged revisions 427762 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427763 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a config file is read, an unescaped semicolon signals comments which are
stripped from the value before it's stored. Escaped semicolons are then
unescaped and become part of the value. Both of these behaviors are normal
and expected. When the config is serialized either by 'dialplan save' or
AMI/UpdateConfig however, the now unescaped semicolons are written as-is.
If you actually reload the file just saved, the unescaped semicolons are
now treated as start of comments.
Since true comments are stripped on read, any semicolons in
ast_variable.value must have been escaped originally. This patch
re-escapes semicolons in ast_variable.values before they're written to
file either by 'dialplan save' or config/ast_config_text_file_save which
is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting
issues nearby in pbx_config.c
Tested-by: George Joseph
ASTERISK-20127 #close
Review: https://reviewboard.asterisk.org/r/4132/
........
Merged revisions 427275 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427276 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel is imparted to a bridge, the invocation of the function may
provide an ast_bridge_features struct. Upon passing this to ast_bridge_impart,
the caller must assume that ownership has passed to the function, as in all
paths the function destroys the struct prior to returning (as its purpose is
to configure the behavior of the channel while in the bridge). On one off
nominal path - where the channel already has a PBX thread - the struct was not
being destroyed.
This patch fixes that glitch.
ASTERISK-24437 #close
Reported by: Scott Griepentrog
........
Merged revisions 426431 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 426432 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix the AMI Status action read and write translation path strings from
growing for each channel in the status event list by reseting the ast
string given to ast_translate_path_to_str() to fill in the given
translation path.
........
Merged revisions 426079 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two aspects to the vulnerability:
(1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use
TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the
TCP/TLS core, which should be done as an improvement at a latter date.
(2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified,
will default to the OpenSSL SSLv23_method. This method allows for all
ecnryption methods, including SSLv2/SSLv3. A MITM can exploit this by
forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE.
This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration,
and explicitly disables SSLv2/SSLv3 if using SSLv23_method.
For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is
explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or
SSLv3.
Much thanks to abelbeck for reporting the vulnerability and providing a patch
for the res_jabber/res_xmpp modules.
Review: https://reviewboard.asterisk.org/r/4096/
ASTERISK-24425 #close
Reported by: abelbeck
Tested by: abelbeck, opsmonitor, gtjoseph
patches:
asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903)
asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903)
AST-2014-011-1.8.diff uploaded by mjordan (License 6283)
AST-2014-011-11.diff uploaded by mjordan (License 6283)
........
Merged revisions 425987 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425991 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tasks that were marked for pending deletion in the scheduler would be moved to
the cache for later reuse, but after being recycled the deleted mark wouldn't
be removed resulting in fresh tasks being deleted without reason... and
immediately moved back into the cache where they could be reused again. This
could cause horrendous things to happen in just about anything that used a
scheduler.
ASTERISK-24321 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4071/
........
Merged revisions 425503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Masquerades into and out of channels that are involved in a dial operation
don't create the expected dial end event. The missing dial end event goes
against the model for things like CDRs and generating Dial end manager
actions and such.
There are four cases:
1) A channel masquerades into the caller channel. The case happens when
performing a blonde transfer using the channel driver's protocol.
2) A channel masquerades into a callee channel. The case happens when
performing a directed call pickup.
3) The caller channel masquerades out of dial. The case happens when
using the Bridge application on the caller channel.
4) A callee channel masquerades out of dial. The case happens when using
the Bridge application on a peer channel.
As it turned out, all four cases need to be handled instead of just the
first one.
ASTERISK-24237
Reported by: Richard Mudgett
ASTERISK-24394 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4066/
........
Merged revisions 425430 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425455 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides the capability to manipulate templates and categories
with non-unique names via AMI.
Summary of changes:
GetConfig and GetConfigJSON: Added "Filter" parameter: A comma separated list
of name_regex=value_regex expressions which will cause only categories whose
variables match all expressions to be considered. The special variable name
TEMPLATES can be used to control whether templates are included. Passing
'include' as the value will include templates along with normal categories.
Passing 'restrict' as the value will restrict the operation to ONLY templates.
Not specifying a TEMPLATES expression results in the current default behavior
which is to not include templates.
UpdateConfig: NewCat now includes options for allowing duplicate category
names, indicating if the category should be created as a template, and
specifying templates the category should inherit from. The rest of the
actions now accept a filter string as defined above. If there are non-unique
category names, you can now update specific ones based on variable values.
To facilitate the new capabilities in manager, corresponding changes had to be
made to config, most notably the addition of filter criteria to many of the
APIs. In some cases it was easy to change the references to use the new
prototype but others would have required touching too many files for this
patch so a wrapper with the original prototype was created. Macros couldn't
be used in this case because it would break binary compatibility with modules
such as res_digium_phone that are linked to real symbols.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4033/
........
Merged revisions 425383 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425384 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a smart bridge operation occurs and a bridge transitions from one
technology to another the old technology is provided the channels formerly
in it and told that they are leaving. Unfortunately the bridge provided
along with them is incomplete. The bridge, despite there being channels in it,
contains none. This forces technology implementations to have additional
logic when channels are leaving or to store their own duplicated
state.
This change makes the bridge more complete so it contains the expected
channels. Now that the bridge is complete special logic within
bridge_native_rtp is no longer needed and has been removed.
Review: https://reviewboard.asterisk.org/r/4057/
........
Merged revisions 425242 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425243 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes res_phoneprov more modular so other modules (like pjsip)
can provide configuration information instead of res_phoneprov relying solely
on users.conf and sip.conf. To accomplish this a new ast_phoneprov public API
is now exposed which allows config providers to register themselves, set
defaults (server profile, etc) and add user extensions.
* ast_phoneprov_provider_register registers the provider and provides callbacks
for loading default settings and loading users.
* ast_phoneprov_provider_unregister clears the defaults and users.
* ast_phoneprov_add_extension should be called once for each user/extension
by the provider's load_users callback to add them.
* ast_phoneprov_delete_extension deletes one extension.
* ast_phoneprov_delete_extensions deletes all extensions for the provider.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/3970/
........
Merged revisions 424963 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424964 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424965 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 13+, any given message type is not guaranteed to exist even
if Asterisk comes up correctly since creation of the message type could
be declined. The indexer should not prevent Asterisk from starting
under these conditions.
........
Merged revisions 424833 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When message type creation is declined via stasis.conf, certain
operations log errors assuming that the declined type is being used
before initialization or after destruction. These error messages get
quite spammy for oft used message types and should not be logged in the
first place since the message type is validly NULL.
Reported by: Matt DiMeo
........
Merged revisions 424769 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adding a mixmonitor to a channel causes the bridge to change technologies
from native to simple_bridge so the call can be recorded. However, when
the mixmonitor is stopped the bridge does not switch back to the native
technology.
* Added unbridge requests to reevaluate the bridge when a channel
audiohook is removed.
* Moved the unbridge request into ast_audiohook_attach() ensure that the
bridge reevaluates whenever an audiohook is attached. This simplified the
mixmonitor and chan_spy start code as well.
* Added defensive code to stop_mixmonitor_full() in case additional
arguments are ever added to the StopMixMonitor application.
* Made ast_framehook_detach() not do an unbridge request if the framehook
does not exist.
* Made ast_framehook_list_fixup() do an unbridge request if there are any
framehooks. Also simplified the loop.
ASTERISK-24195 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4046/
........
Merged revisions 424506 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424507 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r423414 (13) / r423415 (trunk), an API call that determines if a format
capability structure is empty was added. This returns true if the format
capability structure is completely empty or "none". A check for this was added
in channel.c's set_format call. Unfortunately, when this check was true, it
returned from the function while still holding the channel lock. This caused
the CDR unit tests - which have a tendency to create channels with no formats -
to deadlock. Whoops.
This patch unlocks the channel on the off-nominal path.
........
Merged revisions 423641 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change gives framehooks a reverse-direction masquerade callback in
addition to chan_fixup_cb similar to the callback added to datastores
to handle the same situation. The new callback provides the same
parameters as the fixup callback, but is called on the new channel's
framehooks before moving framehooks from the old channel to the new
channel. This gives the framehooks an oppurtunity to decide whether
they should remain on the new channel or be removed.
This new callback is used to prevent the PJSIP T.38 framehook from
remaining on a masqueraded channel if the new channel is not also a
PJSIP channel. This was causing a crash when a local channel was
masqueraded into a PJSIP channel and the framehook was executed on the
local channel since the channel's tech private data was not structured
as expected.
Review: https://reviewboard.asterisk.org/r/4001/
........
Merged revisions 423503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function acts like strsep with three exceptions...
* The separator is a single character instead of a string.
* Separators inside quotes are treated literally instead of like separators.
* You can elect to have leading and trailing whitespace and quotes
stripped from the result and have '\' sequences unescaped.
Like strsep, ast_strsep maintains no internal state and you can call it
recursively using different separators on the same storage.
Also like strsep, for consistent results, consecutive separators are not
collapsed so you may get an empty string as a valid result.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3989/
........
Merged revisions 423476 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423478 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423480 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Empty here means that there are no formats in the format_cap structure
or the only format in it is the "none" format.
I've added calls to check the emptiness of a format_cap in a few places
in order to short-circuit operations that would otherwise be pointless
as well as to prevent some assertions from being triggered in cases
where channels with no formats are used.
........
Merged revisions 423414 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes made during format improvements resulted in the
recording to voicemail option 'm' of the MixMonitor app
writing a zero length duration in the msgXXXX.txt file.
This change introduces a new function ast_ratestream(),
which provides the sample rate of the format associated
with the stream, and updates the app_voicemail function
for ast_app_copy_recording_to_vm to calculate the right
duration.
Review: https://reviewboard.asterisk.org/r/3996/
ASTERISK-24328 #close
........
Merged revisions 423192 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_play_and_record_full() has a parameter called "acceptdtmf" that is a
string of acceptable DTMF digits that may be pressed by a caller to end
and accept the recording.
ARI uses this function in order to perform recording, and it provides
options for what is passed as acceptdtmf to ast_play_and_record_full().
By default, ARI passes an empty string, with the intention that no DTMF
can be used to end the recording.
The problem is that ast_play_and_record_full() attempts to be "helpful"
by setting "#" as the acceptdtmf if an empty string or NULL pointer
has been passed in. With ARI, this results in unexpected behavior
occurring if you have attempted to intercept "#" yourself in order
to perform some other manipulation of the live recording.
This change removes the "helpful" behavior by no longer accepting
"#" as a default acceptdtmf if none is specified by the caller of
ast_play_and_record_full(). This makes the ARI scenario work as
expected.
The other callers of ast_play_and_record_full() are app_voicemail
and app_minivm, and in both cases, they pass an explicit "#" to
ast_play_and_record_full() as acceptdtmf, so they are unaffected
by this change.
........
Merged revisions 422964 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422965 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a CDR is forked, a new CDR is created and appended to the CDR chain for
the Party A. The forked CDR starts life off as a clone of the last
non-finalized for the particular Party A. In the past, merely copying over
the snapshots for Party A/Party B would be sufficient. However, as the CDRs
now contain cached information from Party A - specifically application/data,
context, and extension - we need to copy that over during a fork as well.
Huzzah for unit tests catching this when the context/extension were derived
from a cached value on the CDR instead of on Party A.
........
Merged revisions 422769 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422770 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On some systems, a timeval's tv_sec/tv_usec will be unsigned lont ints, as
opposed to long ints. When the RTP engine formats these as strings, it was
previously formatting them as signed integers, which can result in some
odd negative timestamp values (particularly on 32-bit systems). This patch
formats the values as unsigned long integers.
........
Merged revisions 422766 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422767 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The context/extension in a CDR is generally considered the destination of a
call. When looking at a 2-party call CDR, users will typically be presented
with the following:
context exten channel dest_channel app data
default 1000 SIP/8675309 SIP/1000 Dial SIP/1000,,20
However, if the Dial actually takes place in a Macro, the current behaviour
in 12 will result in the following CDR:
context exten channel dest_channel app data
macro-dial s SIP/8675309 SIP/1000 Dial SIP/1000,,20
The same is true of a GoSub:
context exten channel dest_channel app data
subs dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20
This generally makes the context/exten fields less than useful.
It isn't hard to preserve these values in the CDR state machine; however, we
need to have something that informs us when a channel is executing a
subroutine. Prior to this patch, there isn't anything that does this.
This patch solves this problem by adding a new channel flag,
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
Macro or a GoSub. The CDR engine looks for this value when updating a Party A
snapshot; if the flag is present, we don't override the context/exten on the
main CDR object. In a funny quirk, executing a hangup handler must *not* abide
by this logic, as the endbeforehexten logic assumes that the user wants to see
data that occurs in hangup logic, which includes those subroutines. Since
those execute outside of a typical Dial operation (and will typically have
their own dedicated CDR anyway), this is unlikely to cause any heartburn.
Review: https://reviewboard.asterisk.org/r/3962/
ASTERISK-24254 #close
Reported by: tm1000, Tony Lewis
Tested by: Tony Lewis
........
Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes an issue where CDRs would get stuck generating an infinite
number of CDRs, eventually crashing Asterisk (and consuming a lot of memory
along the way).
When a channel enters into a multi-party bridge, the CDR engine creates
mappings of each participant to each other participant, picking the 'A' party
as it goes. So, if we have four channels in a multi-party bridge (Alice, Bob,
Charlie, Denise), we would have something like:
Alice => Bob
Alice => Charlie
Alice => Denise
Bob => Charlie
Bob => Denise
Charlie => Denise
This works fine when participants enter the bridge a single time.
When a participant leaves a bridge, the CDRs for that channel are transitioned
to a finalized state.
The bug occurs if Bob rejoins. When the CDR engine creates mappings between the
channels, it walks through all the participants currently in the bridge, and
realizes that no one in the bridge can create a CDR with the channel (Bob).
As such it creates a new CDR for the candidate and appends it to that
candidate's chain. Unfortunately, on this particular code path, it doesn't
stop traversing the candidate's chain. Since we just added ourselves to the
chain, this causes the loop to keep going, constantly adding new CDRs.
This patch makes it so the engine bails when it creates a CDR match in this
case.
Review: https://reviewboard.asterisk.org/r/3964/
ASTERISK-24241 #close
Reported by: Deepak Singh Rawat
Tested by: Deepak Singh Rawat
ASTERISK-24208
Reported by: Frankie Chin
........
Merged revisions 422715 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422716 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds an option to the dial API that marks an outgoing dial as replacing the dialing channel for the purpose of propagating accountcode. When it is used, AST_CHANNEL_REQUESTOR_REPLACEMENT is used instead of AST_CHANNEL_REQUESTOR_BRIDGE_PEER when setting accountcodes on the involved channels with ast_channel_req_accountcodes.
Review: https://reviewboard.asterisk.org/r/3968/
........
Merged revisions 422684 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When scheduled tasks run, they are removed from the heap (or hashtab).
When a scheduled task is deleted, if the task can't be found in the
heap (or hashtab), an assertion is triggered. If DO_CRASH is enabled,
this assertion causes a crash.
The problem is, sometimes it just so happens that someone attempts
to delete a scheduled task at the time that it is running, leading
to a crash. This change corrects the issue by tracking which task
is currently running. If that task is attempted to be deleted,
then we mark the task, and then wait for the task to complete.
This way, we can be sure to coordinate task deletion and memory
freeing.
ASTERISK-24212
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/3927
........
Merged revisions 422070 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422071 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When issuing a POST /channels/{channel_id}/play on a channel that is not
yet answered, ARI is supposed to:
* Queue up an AST_CONTROL_PROGRESS on the channel
* Start up the playback of the media
Instead, we sneak an answer on the channel right before starting playing media.
This is due to ARI's usage of control_streamfile. This function implicitly
answers the channel (and doesn't give ARI the option to stop it). The answering
of the channel here is probably unnecessary:
* app_voicemail, by far the biggest consumer of this function, always answers
the channels anyway
* control stream file (in res_agi) and ControlPlayback probably shouldn't be
implicitly answering the channel. Answering should not be tied directly to
playing back media.
As it turns out, the answering of the channel here is pretty old:
356042 twilson if (ast_channel_state(chan) != AST_STATE_UP) {
3087 anthm res = ast_answer(chan);
180259 tilghman }
(As in, ancient?)
Note that others ran into this problem and commented about it on various
mailing lists.
Review: https://reviewboard.asterisk.org/r/3907/
ASTERISK-24229 #close
Reported by: Matt Jordan
........
Merged revisions 421695 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421696 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes gcc warnings that occur due to the type qualifier 'const'
being ignored on a return type of int.
ASTERISK-24246 #close
Reported by: Shaun Ruffell
patches:
0001-main-uri-Quiet-warning-about-ignored-attribute-on-re.patch uploaded by Shaun Ruffell (License 5417)
........
Merged revisions 421675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On a SIP reinvite that changes media strams, the PJSIP channel driver was
flooding the log with "Asked to transmit frame type %s, while native
formats is %s" warnings.
* Fixes PJSIP not setting up translation paths when the formats change on
a reinvite. AFS-63 was effectively reintroduced because of the media
formats work. res_pjsip_sdp_rtp.c:set_caps()
* Improved the unexpected frame format WARNING message to include more
information.
* Added protective locking while altering formats on a channel. Reworked
set_format() to simplify and protect the formats under manipulation.
* Restored some code that got lost in the media_formats work.
(channel.c:set_format() and res_pjsip_sdp_rtp.c:set_caps())
AFS-137 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3906/
........
Merged revisions 421645 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.
This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
........
Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds the AllVariables parameter to the Status AMI action such that
if defined and set to "true", all channel variables will be reported in
the subsequent Status event(s). This parameter does not negate the
functionality of the "Variables" parameter so that global variables and
dialplan functions can be requested.
Review: https://reviewboard.asterisk.org/r/3915/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a few issues:
1) The order of Dial events have been changed when performing a call forward.
The order has now been altered to
1) Dial begins dialing channel A.
2) When A forwards the call to B, we issue the dial end event to channel
A, indicating the dial is being canceled due to a forward to B.
3) When the call to channel B occurs, we then issue a new dial begin to
channel B.
2) Call forwards are now reported on the calling channel, not the peer channel.
3) AMI DialEnd events have been altered to display the extension the call is
being forwarded to when relevant.
4) You can now get the values of channel variables for channels that are not
currently in the Stasis application. This brings the retrieval of channel
variables more in line with the rest of channel read operations since they
may be performed on channels not in Stasis.
ASTERISK-24134 #close
Reported by Matt Jordan
ASTERISK-24138 #close
Reported by Matt Jordan
Patches:
forward-shenanigans.diff uploaded by Matt Jordan (License #6283)
Review: https://reviewboard.asterisk.org/r/3899
........
Merged revisions 420794 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL typically tracks a lot of information using the unique ID of the channel.
This is typically needed due to tying events together using the linked ID of
the various channels involved in a "call", which is derived from the channel ID
of the oldest channel involved in a bridge (or in the case of a Dial, the
parent channel).
Previously, we had updated the extra fields to include the involved channel
names, but forgot to put in the unique ID. This patch corrects that error.
........
Merged revisions 421037 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421042 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a manager or CLI user attached a mixmonitor to a call running a dynamic
bridge feature while in a bridge, the feature would be interrupted and the
channel would be forcibly kicked out of the bridge (usually ending the call
during a simple 1 to 1 call). This would also occur during any similar action
that could set the unbridge soft hangup flag, so the fix for this was to
remove unbridge from the soft hangup flags and make it a separate thing all
together.
ASTERISK-24027 #close
Reported by: mjordan
Review: https://reviewboard.asterisk.org/r/3900/
........
Merged revisions 420934 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 420940 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit adds the ability for a user to configure
a resource list in pjsip.conf. Subscribing to this
list simultaneously subscribes the subscriber to all
resources listed. This has the potential to reduce
the amount of SIP traffic when loads of subscribers
on a system attempt to subscribe to each others' states.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed the iax.conf bandwidth option. This is the root cause of
ASTERISK-24150.
* Added checks in iax2_request() to ensure that there are actual formats
requested for the new channel to prevent any more fracks from issues like
ASTERISK-24150. This is a consequence of the iax.conf bandwidth option
not working.
* Fixed struct iax2_codec_pref.order member size mismatch issue when
converting to and from the codec preference order list passed over the
wire. In addition the values sent over the wire are now compatible with
previous Asterisk versions.
* Fixed several issues dealing with the struct iax2_codec_pref members.
Off-by-one, array limit errors, and the order/framing members always need
to be updated together.
* Made iax2_request() setup the channel's native format preference order
according to the user's wishes. The new media format strategy needs the
order specified earler.
* Fixed usage of ast_format_compatibility_bitfield2format(). The function
can return NULL if the bitfield was not associated with a function.
* Deleted dead code iax2_codec_pref_getsize() and
iax2_codec_pref_setsize().
* Made iax2_parse_allow_disallow() and iax2_codec_pref_string() call
iax2_codec_pref_to_cap() instead of inlining it.
* Made IAX_CAPABILITY_MEDBANDWIDTH, IAX_CAPABILITY_LOWBANDWIDTH, and
IAX_CAPABILITY_LOWFREE constants again as they were in Asterisk v1.8.
* Renamed prefs to prefs_global so it won't get confused with the local
pref versions.
* Fixed too small buffer in handle_cli_iax2_show_peer().
* Fixed ast_cli() calls in handle_cli_iax2_show_peer() to output complete
lines.
* Changed struct create_addr_info.prefs to be struct iax2_codec_pref as an
optimization so iax2_request() and iax2_call() do less work.
* Fixed a potential deadlock in ast_iax2_new() on an off-nominal path when
the pbx could not get started.
* Made set_config() setup a local prefs list along side the local
capability format bitfield. Once the config is loaded, then the local
copies are put into the global versions.
* Fix unininialized codec_buf in function_iaxpeer().
ASTERISK-24150 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3890/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Hints that are a pattern match are technically stored in the hint container in
the same fashion as concrete implementations of hints. The pattern matching
hints, however, are not "real" in the sense that things can subscribe to them:
rather, they are stored in the hints container so that when a subscription is
made a "real" hint can be generated for the subscription if one does not yet
exist. The extension state core takes care of this correctly by matching
against non-pattern matching extensions prior to pattern matching extensions.
Because of this, however, the ExtensionStateList AMI action was returning
pattern matching hints when executed. These hints are meaningless from the
perspective of AMI clients: their state will never change, they cannot be
subscribed to, and events would never normally be generated from them. As such,
we now filter these out of the response.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-23818 (lua contexts being overwritten by contexts of the same name in
pbx_config) surfaced because pbx_lua, having the AST_MODFLAG_GLOBAL_SYMBOLS
set, was always force loaded before pbx_config. Since I couldn't find any
reason for pbx_lua to export it's symbols to the rest of Asterisk, I simply
changed the flag to AST_MODFLAG_DEFAULT. Problem solved. What I didn't
realize was that the symbols need to be exported not because Asterisk needs
them but because any external Lua modules like luasql.mysql need the base
Lua language APIs exported (ASTERISK-17279).
Back to ASTERISK-23818... It looks like there's an issue in pbx.c where
context_merge was only merging includes, switches and ignore patterns if
the context was already existing AND has extensions, or if the context was
brand new. If pbx_lua is loaded before pbx_config, the context will exist
BUT pbx_lua, being implemented as a switch, will never place extensions in
it, just the switch statement. The result is that when pbx_config loads,
it never merges the switch statement created by pbx_lua into the final
context.
This patch sets pbx_lua's modflag back to AST_MODFLAG_GLOBAL_SYMBOLS and adds
an "else if" in context_merge that catches the case where an existing context
has includes, switchs or ingore patterns but no actual extensions.
ASTERISK-23818 #close
Reported by: Dennis Guse
Reported by: Timo Teräs
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3891/
........
Merged revisions 420146 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 420147 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 420148 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420149 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces stasis.conf and a mechanism to prevent certain message
types from being published. Internally, this works by preventing the
chosen message types from being created which ensures that those
message types can never be published. This patch also adjusts message
publishers such that message payloads are not created if the related
message type is not available.
ASTERISK-23943 #close
Review: https://reviewboard.asterisk.org/r/3823/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.
Inbound messages can now be received over ARI as well. An ARI application that
subscribes to endpoints will receive messages from those endpoints:
{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" <sip:alice@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has
two callbacks: one to determine if the handler has a destination for the
message, and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them.
Various other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when
the lifetime of things is well defined and the number of things is very
small.
res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.
Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
fix for that as well.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new module to Asterisk, res_hep_rtcp. The module subscribes
to the RTCP topics in Stasis and receives RTCP information back from the
message bus. It encodes into HEPv3 packets and sends the information to the
res_hep module for transmission.
Using this, someone with a Homer server can get live call quality monitoring
for all RTP-based channels in their Asterisk 12+ systems.
In addition, there were a few bugs in the RTP engine, res_rtp_asterisk, and
chan_pjsip that were uncovered by the tests written for the Asterisk Test
Suite. This patch fixes the following:
1) chan_pjsip failed to set its channel unique ids on its RTP instance on
outbound calls. It now does this in the appropriate location, in the
serialized call callback.
2) The rtp_engine was overflowing some values when packed into JSON.
Specifically, some longs and unsigned ints can't be be packed into integer
values, for obvious reasons. Since libjansson only supports integers,
floats, strings, booleans, and objects, we print these values into strings.
3) res_rtp_asterisk had a few problems:
(a) it would emit a source IP address of 0.0.0.0 if bound to that IP
address. We now use ast_find_ourip to get a better IP address, and
properly marshal the result into an ast_strdupa'd string.
(b) Reports can be generated with no report bodies. In particular, this
occurs when a sender is transmitting information to a receiver (who
will send no RTP back to the sender). As such, the sender has no report
body for what it received. We now properly handle this case, and the
sender will emit SR reports with no body. Likewise, if we receive an
RTCP packet with no report body, we will still generate the appropriate
events.
ASTERISK-24119 #close
........
Merged revisions 419823 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for an <example /> tag in the XML documentation schema.
For CLI help, this doesn't change the formatting too much:
- Preceeding white space is removed
- Unlike with para elements, new lines are preserved
However, having an <example /> tag in the XML schema allows for the wiki
documentation generation script to surround the documentation with {code} or
{noformat} tags, generating much better content for the wiki - and allowing us
to put dialplan examples (and other code snippets, if desired) into the
documentation for an application/function/AMI command/etc.
Review: https://reviewboard.asterisk.org/r/3807/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds three new AMI commands:
* ExtensionStateList (pbx.c) - list all known extension state hints
and their current statuses. Events emitted by the list action are
equivalent to the ExtensionStatus events.
* PresenceStateList (res_manager_presencestate) - list all known
presence state values. Events emitted are generated by the stasis
message type, and hence are PresenceStateChange events.
* DeviceStateList (res_manager_devicestate) - list all known device
state values. Events emitted are generated by the stasis message
type, and hence are DeviceStateChange events.
Patch-by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3799/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-24124 #close
Reported by Matt Jordan
AFS-131 #close
Reported by Matt Jordan
Patches:
userevent.patch uploaded by Matt Jordan (License #6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When creating the alphabetical sorted list each module is added to a list
temporarily. On the second iteration each module already has a pointer to
another module, causing stuff to go into a loop.
ASTERISK-24123 #close
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "bridge destroy" CLI command is invasive to bridges and can leave them in an unexpected
state for the users of them. Since this command may be useful for developers it is now
only available when developer mode is available. To take its place "all" has been added
as a valid option to the "bridge kick" CLI command. It will kick all of the channels
in the bridge out.
ASTERISK-23987
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3840/
........
Merged revisions 419536 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous behavior was to simply set the accountcode of an outgoing
channel to the accountcode of the channel initiating the call. It was
done this way a long time ago to allow the accountcode set on the SIP/100
channel to be propagated to a local channel so the dialplan execution on
the Local;2 channel would have the SIP/100 accountcode available.
SIP/100 -> Local;1/Local;2 -> SIP/200
Propagating the SIP/100 accountcode to the local channels is very useful.
Without any dialplan manipulation, all channels in this call would have
the same accountcode.
Using dialplan, you can set a different accountcode on the SIP/200 channel
either by setting the accountcode on the Local;2 channel or by the Dial
application's b(pre-dial), M(macro) or U(gosub) options, or by the
FollowMe application's b(pre-dial) option, or by the Queue application's
macro or gosub options. Before Asterisk v12, the altered accountcode on
SIP/200 will remain until the local channels optimize out and the
accountcode would change to the SIP/100 accountcode.
Asterisk v1.8 attempted to add peeraccount support but ultimately had to
punt on the support. The peeraccount support was rendered useless because
of how the CDR code needed to unconditionally force the caller's
accountcode onto the peer channel's accountcode. The CEL events were thus
intentionally made to always use the channel's accountcode as the
peeraccount value.
With the arrival of Asterisk v12, the situation has improved somewhat so
peeraccount support can be made to work. Using the indicated example, the
the accountcode values become as follows when the peeraccount is set on
SIP/100 before calling SIP/200:
SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200
acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200
peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100
If a channel already has an accountcode it can only change by the
following explicit user actions:
1) A channel originate method that can specify an accountcode to use.
2) The calling channel propagating its non-empty peeraccount or its
non-empty accountcode if the peeraccount was empty to the outgoing
channel's accountcode before initiating the dial. e.g., Dial and
FollowMe. The exception to this propagation method is Queue. Queue will
only propagate peeraccounts this way only if the outgoing channel does not
have an accountcode.
3) Dialplan using CHANNEL(accountcode).
4) Dialplan using CHANNEL(peeraccount) on the other end of a local
channel pair.
If a channel does not have an accountcode it can get one from the
following places:
1) The channel driver's configuration at channel creation.
2) Explicit user action as already indicated.
3) Entering a basic or stasis-mixing bridge from a peer channel's
peeraccount value.
You can specify the accountcode for an outgoing channel by setting the
CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue
applications. Queue adds the wrinkle that it will not overwrite an
existing accountcode on the outgoing channel with the calling channels
values.
Accountcode and peeraccount values propagate to an outgoing channel before
dialing. Accountcodes also propagate when channels enter or leave a basic
or stasis-mixing bridge. The peeraccount value only makes sense for
mixing bridges with two channels; it is meaningless otherwise.
* Made peeraccount functional by changing accountcode propagation as
described above.
* Fixed CEL extracting the wrong ie value for the peeraccount. This was
done intentionally in Asterisk v1.8 when that version had to punt on
peeraccount.
* Fixed a few places dealing with accountcodes that were reading from
channels without the lock held.
AFS-65 #close
Review: https://reviewboard.asterisk.org/r/3601/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk, it is possible for a device to have a status of ONHOLD. This is
not typically an easy thing to determine, as a channel being on hold is not
a direct channel state. Typically, this has to be calculated outside of the
core independently in channel drivers, notably, chan_sip and chan_pjsip. Both
of these channel drivers already have to calculate device state in a fashion
more complex than the core can handle, as they aggregate all state of all
channels associated with a peer/endpoint; they also independently track
whether or not one of those channels is currently on hold and mark the device
state appropriately.
In 12+, we now have the ability to report an AST_DEVICE_ONHOLD state for all
channels that defer their device state to the core. This is due to channel hold
state actually now being tracked on the channel itself. If a channel driver
defers its device state to the core (which many, such as DAHDI, IAX2, and
others do in most situations), the device state core already goes out to get a
channel associated with the device. As such, it can now also factor the channel
hold state in its calculation.
This patch adds this logic to the device state core. It also uses an existing
mapping between device state and channel state to handle more channel states.
chan_pjsip has been updated slightly as well to make use of this (as it was,
for some reason, reporting a channel state of BUSY as a device state of INUSE,
which feels slightly wrong).
Review: https://reviewboard.asterisk.org/r/3771/
ASTERISK-24038 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
(1) It updates the unit tests to expect additional stasis messages. More
messages are now sent to the endpoint topic, due to forwarding all
channel messages and the forwarding relationship set up between
endpoints themselves.
(2) Remove the technology forwarding subscription during
ast_endpoint_shutdown. This prevents an improper double shutdown of
an endpoint from occurring.
........
Merged revisions 419318 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Say you wanted to include variables in an application map and have those
variables substituted and passed along to the application being executed;
currently this does not happen.
This patch adds this ability to pass channel variable values to an
application before being executed.
ASTERISK-22608 #close
Reported by: Michael L. Young
patches:
features_substitute_arguments_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3819/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When updating a row, we are currently doing an INSERT OR REPLACE INTO. The
downside to this is that the row is deleted if it exists and then a new row is
inserted. So, we are hitting the disk twice. One for the deletion and one for
the insertion.
This patch changes this statement to an INSERT INTO and if the insert fails
because a row with that key exists, we will IGNORE the failure. Then we will
attempt to perform an UPDATE on the existing row if that row wasn't just
INSERTed.
ASTERISK-24050 #close
Reported by: Michael L. Young
patches:
astdb-insert-update-io-help_trunk_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3815/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
for sending/receiving arbitrary out of call text messages through ARI in a
technology agnostic fashion.
The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
arbitrary technology defined URI. This is less straight forward, as
endpoints are formed from a tech + resource pair. We don't have a
mechanism to note that a technology that *may* have endpoints exists.
This patch provides such a mechanism, and fixes a few bugs along the way.
The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
most of the interesting bits (such as channel creation, destruction, state
changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
This resulted in endpoints missing the channel creation message, which
limited the usefulness of the subscription in the first place (a major use
case being 'tell me when this endpoint has a channel'). Unfortunately,
this meant another parameter to ast_channel_alloc. Since not all channel
technologies support an ast_endpoint, this patch makes such a call
optional and opts for a new function, ast_channel_alloc_with_endpoint.
When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.
Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
ARI, through the applications resource, can:
- subscribe to endpoint:PJSIP/foo and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
- subscribe to endpoint:PJSIP/bar and get notifications for channels
PJSIP/bar-1 and endpoint PJSIP/bar
- subscribe to endpoint:PJSIP and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).
This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents a crash in the Dial API triggered by use of the Page()
application where a format capability struct was used before checking
whether it was NULL.
ASTERISK-24074 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a reference count goes negative, instead of
just logging that fact, be more helpful with a
backtrace and an assert that will DO_CRASH.
This patch also removes the duplicate ao2_bt()
function and cleans up extraneous usage of the
ast_log_backtrace() call.
Review: https://reviewboard.asterisk.org/r/3765/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.
Review: https://reviewboard.asterisk.org/r/3721/
........
Merged revisions 418914 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418936 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the PresenceState action is executed, the nominal path fails to include
the ActionID in the successful response. This patch adds a call to
astman_start_ack, which guarantees that an ActionID (if provided) will be
sent back to the AMI client.
Unlike the Asterisk 11 and 12 patches, this patch also deprecates the
duplicate Message key in the response to the action, replacing it with the
key 'PresenceMessage'.
Review: https://reviewboard.asterisk.org/r/3776/
ASTERISK-23985 #close
........
Merged revisions 418713 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 418714 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Create a Stasis bridge sub-class to propagate linkedids and
accountcodes.
* Fixed the basic bridge sub-class to update peeraccount codes when the
number of channels in the bridge drops back down to two parties.
* Refactored ast_bridge_channel_update_accountcodes() to handle channels
joining/leaving the bridge.
* Fixed the basic bridge sub-class to not call the base bridge class pull
method twice.
AFS-105 #close
ASTERISK-23852 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/3720/
........
Merged revisions 418225 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects two issues with the extra field information in Asterisk
12+ in channel event logs.
It is possible to inject custom values into the dialstatus provided by
ast_channel_dial_type() Stasis messages that fall outside the
enumeration allowed for the DIALSTATUS channel variable. CEL now
filters for the allowed values and ignores other values.
The "hangupsource" extra field key is always blank if the far end
channel is a chan_pjsip channel. This is because the hangupsource is
never set for the pjsip channel driver. This change sets the
hangupsource whenever a hangup is queued for chan_pjsip channels.
This corrects an issue with the pjsip channel driver where the
hangupcause information was not being set properly.
Review: https://reviewboard.asterisk.org/r/3690/
........
Merged revisions 418071 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous patch (r418034) fixed the 'glitch' that the channels/h323
Makefile no longer existed. Unfortunately, removing the entire line was a bit
of a blunder, as it meant that build_tools/menuselect-deps was never
generated. Hilarity ensued when actually trying to compile.
But hey! At least configure worked.
This patch fixes *that* glitch, and removes some more of the vestiges of h323.
(It had tendrils in the main Makefile? Crazy.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Billing records are fair,
To get paid is quite bright,
You should really use ODBC;
Good-bye cdr_sqlite.
Microsoft did once push H.323,
Hell, we all remember NetMeeting.
But try to compile chan_h323 now
And you will take quite a beating.
The XMPP and SIP war was fierce,
And in the distant fray
Was birthed res_jabber/chan_jingle;
But neither to stay.
For everyone did care and chase what Google professed.
"Free Internet Calling" was what devotees cried,
But Google did change the specs so often
That the developers were happy the day chan_gtalk died.
And then there was that odd application
Dedicated to the Polish tongue.
app_saycountpl was subsumed by Say;
One could say its bell was rung.
To read and parse a file from the dialplan
You could (I guess) use an application.
app_readfile did fill that purpose, but I think
A function is perhaps better in its creation.
Barging is rude, I'm not sure why we do it.
Inwardly, the caller will probably sigh.
But if you really must do it,
Don't use app_dahdibarge, use ChanSpy.
We all despise the sound of tinny robots
It makes our queues so cold.
To control such an abomination
It's better to not use Wait/SetMusicOnHold.
It's often nice to know properties of a channel
It makes our calls right
We have a nice function called CHANNEL
And so SIPCHANINFO is sent off into the night.
And now things get odd;
Apparently one could delimit with a colon
Properties from the SIPPEER function!
Commas are in; all others are done.
Finally, a word on pipes and commas.
We're sorry. We can't say it enough.
But those compatibility options in asterisk.conf;
To maintain them forever was just too tough.
This patch removes:
* cdr_sqlite
* chan_gtalk
* chan_jingle
* chan_h323
* res_jabber
* app_saycountpl
* app_readfile
* app_dahdibarge
It removes the following applications/functions:
* WaitMusicOnHold
* SetMusicOnHold
* SIPCHANINFO
It removes the colon delimiter from the SIPPEER function.
Finally, it also removes all compatibility options that were configurable from
asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems.
Review: https://reviewboard.asterisk.org/r/3698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Persistent HTTP connection support is needed due to the increased usage of
the Asterisk core HTTP transport and the frequency at which REST API calls
are going to be issued.
* Add http.conf session_keep_alive option to enable persistent
connections.
* Parse and discard optional chunked body extension information and
trailing request headers.
* Increased the maximum application/json and
application/x-www-form-urlencoded body size allowed to 4k. The previous
1k was kind of small.
* Removed a couple inlined versions of ast_http_manid_from_vars() by
calling the function. manager.c:generic_http_callback() and
res_http_post.c:http_post_callback()
* Add missing va_end() in ast_ari_response_error().
* Eliminated unnecessary RAII_VAR() use in http.c:auth_create().
ASTERISK-23552 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3691/
........
Merged revisions 417880 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The patch for ASTERISK-23905 that added PFS support in Asterisk depends on the
elliptic curve library support being present in OpenSSL. As it turns out, some
versions of OpenSSL don't have this library - notably the version running on
our build agents.
This patch fixes the build by providing a configure check for the specific
library calls that the PFS patch relies on.
Review: https://reviewboard.asterisk.org/r/3709/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch enables Perfect Forward Secrecy (PFS) in Asterisk's core TLS API.
Modules that wish to enable PFS should consider the following:
- Ephemeral ECDH (ECDHE) is enabled by default. To disable it, do not
specify a ECDHE cipher suite in a module's configuration, for example:
tlscipher=AES128-SHA:DES-CBC3-SHA
- Ephemeral DH (DHE) is disabled by default. To enable it, add DH parameters
into the private key file, i.e., tlsprivatekey. For an example, see the
default dh2048.pem at
http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-35.1/src/apps/dh2048.pem?txt
- Because clients expect the server to prefer PFS, and because OpenSSL sorts
its cipher suites by bit strength, (see "openssl ciphers -v DEFAULT")
consider re-ordering your cipher suites in the conf file. For example:
tlscipher=AES128+kEECDH:AES128+kEDH:3DES+kEDH:AES128-SHA:DES-CBC3-SHA:-ADH:-AECDH
will use PFS when offered by the client. Clients which do not offer PFS
fall-back to AES-128 (or even 3DES as recommend by RFC 3261).
Review: https://reviewboard.asterisk.org/r/3647/
ASTERISK-23905 #close
Reported by: Alexander Traud
patches:
tlsPFS_for_HEAD.patch uploaded by Alexander Traud (License 6520)
tlsPFS.patch uploaded by Alexander Traud (License 6520)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A loop in ast_careful_fwrite exists that will continually attempt to write to
a file stream, even in the presence of EAGAIN/EINTR errors. However, if a
connection that uses ast_careful_fwrite closes suddenly, ast_careful_fwrite's
call to fflush may return EAGAIN/EINTER along with EOF. A subsequent call to
fflush will return EOF but not clear errno, resulting in an infinite loop.
This patch clears errno after it is detected and handled the loop, such that
any subsequent call to fflush will not get erroneously stuck.
Review: https://reviewboard.asterisk.org/r/3704
#ASTERISK-23984 #close
Reported by: Steve Davies
patches:
fflush_loop_fix uploaded by one47 (License 5012)
........
Merged revisions 417797 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 417798 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417799 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417800 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip and chan_pjsip have also been added to
allow behavior to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
Review: https://reviewboard.asterisk.org/r/3686/
........
Merged revisions 417678 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for the Japanese language to both the say family of
applications, as well as for VoiceMail and VoiceMailMain. A new pack of
language sounds will be released at the same time as the next major version
of Asterisk to support the new language features.
The language features can be enabled using a language code of 'ja'.
Review: https://reviewboard.asterisk.org/r/3477
ASTERISK-23324 #close
Reported by: Kevin McCoy
patches:
app_voicemail.c.20140226.jb.patch uploaded by Kevin McCoy (License 6586)
say.c.20140226.jb.patch uploaded by Kevin McCoy (License 6586)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In v12+ the type values from the table are only used by the CEL unit
tests. Since the unit tests were only comparing a generated expected
event with a real event to see if the ie contents matched and using the
same table IE_PLTYPE values to read the event contents, the type
mismatches were not detected.
........
Merged revisions 417565 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417571 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add the "bridge_technology" extra field key to BRIDGE_ENTER and
BRIDGE_EXIT CEL events to convey the bridge technology in use at the
time the record was generated.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch allows the current owner of a channel to define various
feature hooks to be made available once the channel has entered a
bridge. This includes any hooks that are setup on the
ast_bridge_features struct such as DTMF hooks, bridge event hooks
(join, leave, etc.), and interval hooks.
Review: https://reviewboard.asterisk.org/r/3649/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move eid functions from netsock.c to utils.c. These functions were
already published by utils.h. Flag netsock.h as deprecated and switch
res_pjsip_session.h to use netsock2.h. The only code that still uses
netsock.h is chan_iax2.
ASTERISK-23920 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Appending the ;2 to the user supplied ;1 uniqueid to create the ;2 version
if the user did not also supply an extra uniqueid for the ;2 channel
resulted in allocating a buffer that was one byte too small.
* Fix off by one error in ast_unreal_new_channels() when generating the ;2
uniqueid from the user suppled ;1 version.
* Pulled some long assignment lines from if tests to improve line break
readability in ast_unreal_new_channels().
........
Merged revisions 417119 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Extract the sayname API call to its own registerd callback. This allows
the app_directory and app_chanspy applications to say a mailbox owner's
name using an alternate provider when app_voicemail is not available
because you are using res_mwi_external. app_directory still uses the
voicemail.conf file.
AFS-64 #close
Reported by: Mark Michelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move some implementation specific code from astobj2_container.c into
astobj2_hash.c and astobj2_rbtree.c. This completely removes the need for
astobj2_container to switch on RTTI and it no longer has any knowledge of
the implementation details.
Also adds AO2_DEBUG as a new compile option in menuselect which controls
astobj2 debugging independently of AST_DEVMODE and REF_DEBUG.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3593/
........
Merged revisions 416806 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added ast_sockaddr_cidr_bits() to count the 1 bits in an ast_sockaddr.
* Added ast_ha_join_cidr() which uses ast_sockaddr_cidr_bits() for the netmask
instead of ast_sockaddr_stringify_addr.
* Changed res_pjsip_endpoint_identifier_ip to call ast_ha_join_cidr() instead
of ast_ha_join() for the CLI output.
This is a CLI change only. AMI was not affected.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3652/
........
Merged revisions 416737 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r416211, the publishing of variable changes was modified such that a
cached channel snapshot was used if manager variables were not requested
with each AMI event. This was done to reduce the amount of channel snapshots
created.
However, an assumption was made that generating a channel snapshot and
publishing the snapshot to the channel topic was sufficient to ensure that
the cache would be updated; this is not the case. The channel snapshot type
must be used to force a snapshot update.
This patch updates the publication of channel variables such that the cache
is updated prior to publication of the channel variable message if manager
variables are in use. This ensures that all AMI events receive the variable
update when they are supposed to.
Note that this issue was caught by the Asterisk Test Suite (go go testing)
........
Merged revisions 416557 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Snapshots are now not published *quite* as much as they used to. One instance
where they are not published any longer is during bridge enter and exit - the
state of the channel doesn't change, the bridge does. However, channels are
changed when a linkedid is propagated; previously, the channel's state would
be updated and published during the bridge enter event. Now this must be
explicitly done.
........
Merged revisions 416300 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416301 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
#ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
........
Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
........
Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 415854 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415896 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The supplied hash function to a container must be idempotent given the
object's key value to figure out which container bucket the object belongs
in. Returning a random number or the current container count is not
idempotent. The "computed hash" value doesn't help find the object later
in those cases.
* Fixed the format_list container to actually be a list since that is how
the container is used. Conceptually, if more than 283 formats were added
to the format_list then odd things may have happened before the fix.
........
Merged revisions 415728 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415729 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415730 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds presence state value to output of core show
hints. Also reformats the output slightly so it
doesn't use as much space as it would otherwise.
Was:
1000@demo : SIP/1000 State:Unavailable Watchers 0
Now:
1000@demo : SIP/1000 State:Unavailable Presence:Idle Watchers 0
AFS-53 #close
Review: https://reviewboard.asterisk.org/r/3604/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Documentation for how to add custom headers/content to notifies created
with the PJSIPNotify manager action was a little sparse and it also
wasn't vetting application of Content-length headers like its chan_sip
equivalent was (so two Content-length headers could be applied... and
PJSIP determines the content length anyway, so it just opens people up
for error). This patch also flips the variable order so that the
variables are interpreted in the same order as they are put in the AMI
action.
Review: https://reviewboard.asterisk.org/r/3587/
........
Merged revisions 415658 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415659 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is a re-do of r414122.
When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft
hangup flags have a catastrophic effect on the pbx core if they leak out from
the bridge layer: the channel gets hung up. With the number of threads
involved in a blind transfer, and with the initial patch, it was likely that
this would occur. This caused a large number of test failures
This patch is nearly identical with the one proposed in r414122, save for the
following changes:
- We explicitly clear the UNBRIDGE flag when setting an after goto on a
channel in a bridge
- Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it
https://reviewboard.asterisk.org/r/3585/
........
Merged revisions 415443 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If using the custom URI parsing code (not external uriparser lib) and there
was no query parameters the resulting pointer would be NULL and then an
attempt was made to subtract from it. The pointer is now set to a valid
value if there is no query parameter(s).
Also, in the 'ast_uri_make_host_with_port' function when setting the terminator
on the resulting string it was writing it one past the end of allocated memory.
It now writes the string terminator appropriately.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
