The Binaural Rendering patches in the master branch required
menuselect to be updated with a new support type called 'option'.
This allows binaural rendering to be turned on or off when
bridge_softmix is built. This patch backports the 'option'
functionality to the 13 and 14 branches.
Here's what it looks like in menuselect:
[*] bridge_simple
[*] bridge_softmix
--- Module Options ---
[ ] binaural_rendering_in_bridge_softmix
To create an option for a module, you can create (or update) the
menuselect-tree xml snippet in the directory where the module
resides and add a member element with an 'option' support_level.
Example (abbreviated) from bridges/bridges.xml:
<member name="binaural_rendering_in_bridge_softmix"
displayname="Enable binaural rendering in bridge_softmix"
remove_on_change="bridges/bridge_softmix.o bridges/bridge_softmix.so">
<support_level>option</support_level>
<depend>bridge_softmix</depend>
<depend>fftw3</depend>
<defaultenabled>no</defaultenabled>
</member>
The 'name' will be added or removed from the MENUSELECT_<dir>
make variable following the standard module "missing means yes"
rules.
Example (abbreviated) from bridges/Makefile:
ifeq ($(findstring binaural_rendering,$(MENUSELECT_BRIDGES)),)
bridge_softmix.o: _ASTCFLAGS+=-DBINAURAL_RENDERING
bridge_softmix.so: LIBS+=$(FFTW3_LIB)
endif
Change-Id: I66d23755ed6e81f8d439cad410f2ffa7c30f25ad
* apps/app_voicemail.c fromstring field added to mailbox which will
override the global fromstring if set.
ASTERISK-24562 #close
Change-Id: I5e90e3a1ec2b2d5340b49a0db825e4bbb158b2fe
Per the linked issue, we aren't checking the buffer filled by fgets()
to determine if it contains a newline, so we will fail to correctly
parse the trailing portion of a long line.
This patch increases the buffer size from 256 to 1024, and skips any
line that exceeds that length, logging a warning in the process.
ASTERISK-17067 #close
Reported by: Dave Olszewski
Change-Id: I51bcf270c1b4347ba05b43f18dc2094c76f5d7b0
* manager.c:manager_state_cb() Fix potential use of uninitialized hint[]
if a hint does not exist for the requested extension. Ran into this when
developing a testsuite test. The AMI event ExtensionStatus came out with
the hint header value containing garbage. The AMI event PresenceStatus
also had the same issue.
* manager.c:action_extensionstate() no need to completely initialize the
hint[]. Only initialize the first element.
* pbx.c:ast_add_hint() Remove unnecessary assignment.
* chan_sip.c: Eliminate an unneeded hint[] local variable. We only care
about the return value of ast_get_hint() there.
Change-Id: Ia9a8786f01f93f1f917200f0a50bead0319af97b
According to the RFC[1] WSS should only be used in the Via header
for secure Websockets.
* Use WSS in Via for secure transport.
* Only register one transport with the WS name because it would be
ambiguous. Outgoing requests may try to find the transport by name and
pjproject only finds the first one registered. This may mess up unsecure
websockets but the impact should be minimal. Firefox and Chrome do not
support anything other than secure websockets anymore.
* Added and updated some debug messages concerning websockets.
* security_events.c: Relax case restriction when determining security
transport type.
* The res_pjsip_nat module has been updated to not touch the transport
on Websocket originating messages.
[1] https://tools.ietf.org/html/rfc7118
ASTERISK-26796 #close
Change-Id: Ie3a0fb1a41101a4c1e49d875a8aa87b189e7ab12
res_config_pgsql should match the behavior of other realtime backend
drivers so that queue_log can disable adaptive logging.
ASTERISK-25628 #close
Reported by: Dmitry Wagin
Change-Id: Ic1fb1600c7ce10fdfb1bcdc43c5576b7e0014372
The find_table() functions NULL or a locked table pointer. We are
not consistently calling release_table() in failure paths.
Change-Id: I6f665b455799c84b036e5b34904b82b05eab9544
When a subscription was being recreated and the endpoint wasn't
found, we were trying to unref the endpoint. This was causing
FRACKs. Removed the unref.
ASTERISK-26823 #close
Change-Id: If86d2aecff8fe853c7f38a1bfde721fcef3cd164
This change fixes an assumption in res_pjsip that a contact will
always have a status. There is a race condition where this is
not true and would crash. The status will now be unknown when
this situation occurs.
ASTERISK-26623 #close
Change-Id: Id52d3ca4d788562d236da49990a319118f8d22b5
Outbound registration now subscribes to network change events
published by res_stun_monitor and refreshes all registrations
when an event happens.
The 'pjsip send (un)register' CLI commands were updated to accept
'*all' as an argument to operate on all registrations.
The 'PJSIP(Un)Register' AMI commands were also updated to
accept '*all'.
ASTERISK-26808 #close
Change-Id: Iad58a9e0aa5d340477fca200bf293187a6ca5a25
This change fixes a problem where removing the DTLS configuration
options and reloading would not disable DTLS. This occurred
because the DTLS configuration was not reset to an unconfigured
state on reload.
ASTERISK-26313
Change-Id: I10952709cc4a7727fb50534b042bce9d64894b39
... and clean them both up on uninstall.
We've fixed the issue where 'make install' was installing to
/usr/lib on 64-bit systems that use /usr/lib64. Now we need
to clean up the remnants in /usr/lib.
* 'make install' now prints a warning if DESTDIR/ASTLIBDIR
contains 'lib64' and libasterisk* shared libraries or modules
are also found in DESTDIR/ASTLIBDIR with 'lib64' transformed
to 'lib'.
* 'make uninstall' ALWAYS cleans up both DESTDIR/ASTLIBDIR and
DESTDIR/ASTLIBDIR with 'lib64' transformed to 'lib'.
ASTERISK-26705
Change-Id: I6edddeb3c07a51e7c7ba7cac3c05e4bf3ec3f01f
The bridge_native_rtp module did not properly handle the case where
a smart bridge operation occurs while a channel is suspended. In this
scenario the module would incorrectly set up local or remote RTP
bridging despite the media having to flow through Asterisk. The remote
endpoint would see two media streams and experience wonky audio.
The module has been changed so that it ensures both channels are
not suspended when performing the native RTP bridging and this
requirement has been documented in the bridge technology.
ASTERISK-26781
Change-Id: Id4022d73ace837d4a293106445e3ade10dbc7c7c
This change updates the documentation for the outbound_proxy option
to ensure it is consistently stated that a full SIP URI must be
provided for the option.
The res_pjsip_outbound_registration module has also been changed so
that the provided outbound_proxy value is checked to ensure it is a
URI and if not an error is output stating so.
ASTERISK-26782
Change-Id: I6c239a32274846fd44e65b44ad9bf6373479b593
* Removed all 2.5.5 functional patches.
* Updated usages of pj_release_pool to be "safe".
* Updated configure options to disable webrtc.
* Updated config_site.h to disable webrtc in pjmedia.
* Added Richard Mudgett's recent resolver patches.
Change-Id: Ib400cc4dfca68b3d07ce14d314e829bfddc252c7
On some platforms a multiarch approach is used for libraries.
The build system does not take this into account and still
places libraries into the lib directory if no --libdir is
specified to configure. On initial startup this results in
libasteriskssl.so not being found, as it is not in the multiarch
lib directory. To make matters worse, options were being passed
to ldconfig on both Linux and FreeBSD that actually prevented
the rebuild of the cache.
* Fedora has a /usr/share/config.site that automatically tells
autoconf to use /usr/lib64 but CentOS does not. This logic was
copied to configure.ac and modified so systems like Ubuntu,
which still use /usr/lib for 64-bit systems, aren't affected.
Now that we have them in the correct directory...
In order for the system loader to find libasteriskssl and
libasteriskpj, one of 3 things has to happen...
- The linker cache must be rebuilt including the directory
where the libasterisk* libraries were installed. Only root
can rebuild the cache. This was busted.
- We have to link the asterisk binary with an rpath pointing
to the directrory where the libasterisk* libraries were
installed. This makes things very complicated and will happen
over the collective dead bodies of everyone who's had to
package a distribution with an rpath.
- Finally, you can start asterisk with LD_LIBRARY_PATH set to the
directrory where the libasterisk* libraries were installed.
There are no other options. So...
* The invokation of ldconfig has been moved from main/Makefile
to ASTTOPDIR/Makefile, the options have been removed, and
DESTDIR/ASTLIBDIR appended. If you aren't root, you will be
warned after the "Asterisk Installation Compete" banner that
you must re-run 'make install' as root, manually run
'ldconfig DESTDIR/ASTLIBDIR' as root, or run asterisk with
LD_LIBRARY_PATH.
ASTERISK-26705
Change-Id: I2a64b7c33a7d3e9bde20f47e3d3ab771977af982
* A missing AST_LIST_UNLOCK() in find_table()
* The ESCAPE_STRING() macro uses pgsqlConn under the hood and we were
not consistently locking before calling it.
* There were a handful of other places where pgsqlConn was accessed
directly without appropriate locking.
Change-Id: Iea63f0728f76985a01e95b9912c3c5c6065836ed
The initial motivation for this patch was to properly handle memory
allocation failures - we weren't checking the return values from the
various LDAP library allocation functions.
In the process, because update_ldap() and update2_ldap() were
substantially the same code, they've been consolidated.
Change-Id: Iebcfe404177cc6860ee5087976fe97812221b822
Not sure if this is really a bug versus an improvement. I can see it being
viewed as a bug though by some.
The current build_tools/download_externals file depends on wget in order to
download external modules. The current build system is able to discover
which tool to use for fetching remote files - either wget or curl.
This patch takes advantage of this capability by modifying the two calls to
the wget binary to instead use what was discovered by the build system.
ASTERISK-26812 #close
Change-Id: If9411a2554f009274d377445613ae91192d948a1
The patterns provided by pbx_realtime were checked in the order in
which they were returned from the realtime backend. If there was
overlap between multiple patterns, the first one to correctly match was
chosen even though it may not have been the best match.
We now sort the patterns descending by their length and compare in that
order. There may be cases where this still results in a sub-optimal
match, but this patch should improve the overall behavior.
ASTERISK-18271 #close
Reported by: Charlie Smurthwaite
Change-Id: I56d9ac15810eb1775966b669c3028e32cc7bd809
The DUNDi weight field is not always converted from network byte order
to host byte order. This can result in incorrect weight values and
incorrect selection of DUNDi destinations.
ASTERISK-18731 #close
Reported by: Peter Racz
Patches:
dundi_weight.patch (license #6290) patch uploaded by Peter Racz
Change-Id: Iba3e1a700ff539db57211a7bbc26f7b22ea9a1be
