The correct incantations to enable certification common name / subject
alternative name verification, per our code, are `subjects_all`,
`subjects_in`, and `subjects_out` in a Sofia profile's
`tls-verify-policy`. What we've had in our examples and documentation
for years are `all_subjects`, `in_subjects`, and `out_subjects`.
The result of this is that we've almost certainly confused people into
using the incorrect forms. Those poor people will believe that they
are verifying the CN/SAN of the received host certificate against the
list in `tls-verify-in-subjects` when in fact they are not.
One clear issue in this case was that the incorrect forms failed to
have any effect without providing any warning or error. This issue
could not have persisted if we had made more noise about incorrect
input.
Given how long this has been broken, it's tempting to alias the
incorrect forms to the correct ones. However this would certainly
break many existing installations that have, because of this error,
never actually tested their setup with CN/SAN validation enabled.
In this commit, we fix the examples and documentation, and add an
error-level log output when unknown values are passed to
`tls-verify-policy`.
Thanks-to: Andrew Patrikalakis <anrp+freeswitch@anrp.net>
Two new params added to autoload_configs/rayo.conf.xml
offer-algorithm
all: offer to all clients (default and old behavior)
first: offer to first client, fails over to next client in list
random: offer to random client, fails over to next random client
offer-timeout-ms
0: disable
> 0 and < 120000: time to wait for reply from offer. On timeout, next client is offered call.
If no other clients available, call is rejected. 5000 is default.
Ephemeral ECDH (ECDHE) was supported already. This patch adds Ephemeral
DH (DHE). To enable it, add DH parameters into the private-key file of
your server (agent.pem). For example via:
openssl dhparam -out dh.pem 2048
FS-7561 #resolve
FS-7338: remove libsilk from tree, use system lib instead
FS-7338: change to always use system liblua
FS-7338: remove libbroadvoice from tree, use system lib instead
FS-7338: remove libilbc from tree, use system lib instead
FS-7338: remove libs using system libs from bootstrap
FS-7338: remove libg722_1 from tree, use system lib instead
FS-7338: remove mod_celt, it has be superseded by mod_opus
FS-7338: remove libcodec2 from tree, use system lib instead
FS-7338: remove libopus from tree, use system lib instead
FS-7338: remove libsoundtouch build from tree, use system lib instead
FS-7338: remove flite build from tree, use system lib instead
FS-7338: remove openldap build from tree, use system lib instead
FS-7338: remove libmongoc build from tree, use system lib instead
FS-7338: remove mod_mongo deps that are no longer actually required
FS-7338: remove some dup demo modules and don't include demo code in packages
AMQP(Advanced Message Queueing Protocol) is an event bus protocol
with more info here http://www.amqp.org/about/what
mod_amqp implements the client side of the amqp protocol. Currently
the module supports two separate, but not mutually exclusive usages:
1. Sending a filtered whitelist of events to an AMQP server. The
before the events are sent an amqp routing header is generated so that
downstream subscriptions can subscribe using filters. If the
connection to the remote server is interrupted, the module will
attempt to reconnect.
2. Subscribing to a 'control' channel on the remote AMQP server. When
events are received on this channel if they match a configured filter,
the commands are run locally as api commands. If the filter for the
events being sent to the remote AMQP server include SWITCH_EVENT_API
then the results of the api commands will be sent back to the AMQP
server.
FS-7060 #resolve
Thanks-to: Daniel Bryars <danb@aeriandi.com> and Tim Brown <tim.brown@aeriandi.com>
The default "vanilla" configuration that comes with FreeSWITCH has
been designed as a showcase of the configurability of the myriad of
features that FreeSWITCH comes with out of the box. While it is very
helpful in tinkering with FreeSWITCH, it has a lot of extraneous stuff
enabled/configured for use in a production system. This configuration
aims to take the reverse stance -- it attempts to be a starting point
for configuring a new system by "adding" required features (instead of
removing them as one would do if one starts with the default
configuration).
Jira: FS-7362
Source: 270941d6f2
In certain deployments it might be desirable to remove the User-Agent header from the SIP message.
Set the sofia profile parameter "user-agent-string" to "none" to suppress this header.
mod_v8 is commented out in modules.conf (possibly because it requires
v8 development files installed), but is present in modules.conf. This
commit updates modules.conf.xml to reflect the defaults present in
modules.conf and not try and autoload mod_v8. With this change, the
spurious warning during start up goes away.
having the same gateway definition bound to the ipv6 and ipv4 external
profiles caused confusion for some new users. Also having a gateway
bound to the internal profile was a bit confusing.
fs-6859
As an example of using mod_sofia's gateway parameter `contact-params`
we'd used the value `tport=tcp`. Looking around, it's clear this has
misled people into believing you can specify `tport=tcp` to make the
gateway use TCP or `tport=tls` to make the gateway use TLS. This does
not work.
The actual contact parameter is named `transport` rather than `tport`,
and you shouldn't use `transport` in `contact-params` because we
automatically add a `transport` to the Contact: based on the value of
`register-transport` (even if the gateway is set to not register).
It's clear why this would be confusing, so we'll just remove this as
an example.
Before Jay, no one must have actually tried using the example SBC
config.
Thanks-to: Jay Blinks <jaybinks@gmail.com>
Thanks-to: Cal Leeming <cal.leeming@simplicitymedialtd.co.uk>
FS-6144 --resolve
Luis Azedo