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.
