This patch allows conference flags to be set dynamically from the
dial plan by either passing them to the conference application in
the +flags{ } string or by setting the "conference_flags" dial plan
variable.
The +flags{ } string is currently used to set *user* flags only.
This patch changes this by allowing the +flags{ } string to contain
conference related flags as well (for example wait_mod). It shouldn't
be a problem to pass both types of flags via +flags{ } as long as
the user and conference flag names are kept unique.
FS-5099 #resolve
* commit 'a9b2e061dcd1d95322d27e169ac2f0016aa628a3':
mod_gsmopen: clean up "gsm list" output a little
mod_gsmopen: convert reported RSSI from AT+CSQ to dBm.
mod_gsmopen: get device manufacturer, model and firmware version info.
mod_gsmopen: add support for reading own number from ON phonebook using AT+CNUM
mod_gsmopen: add AT+COPS support to get operator name.
when video floor is locked by a member, changing audio floor on del_member
will cause the video floor lock cleared unexpectedly, this commit fixes that.
In the FreeSWITCH core, the return value of switch_case_db_test_reactive
is ignored, but it is usable in LUA modules (and other bindings via
SWIG). The LUA API example[1] shows how to check the return value, but
that example miserably fails if the database did not exist before.
Changes:
- Document the expected behavior of the test_reactive function.
- Assert that test_sql and sql_reactive are both given. If either
query is not given, the caller is using the wrong API.
- When SCF_AUTO_SCHEMAS is cleared, use the return value of the
test_sql execution. Does anybody use this? Why not remove it?
- Do not unconditionally return SWITCH_FALSE when test_sql fails,
instead allow it to become SWITCH_TRUE when reactive_sql passes.
- Remove the unnecessary test_sql check for SCDB_TYPE_CORE_DB
(this is now enforced through an assert check). (+reindent)
- Clarify the error message of drop_sql, prepending "Ignoring" to
the "SQL ERR" message.
- LUA: Do not print "DBH NOT Connected" if the query fails. This was
the initial source of confusion.
[1]: https://confluence.freeswitch.org/display/FREESWITCH/Lua+API+Reference
When we specifically release all limits on a channel we destroy the
hash table stored in the "limit_hash" private channel data but we
don't destroy the private data as it will be reclaimed as part of the
session. If limit increment is called after the limit release we can
reuse that channel private, but we need to check whether the hash
table is null first. Fortunately this makes the code look better
anyway.
FS-6775 #resolve
FS-6783 #resolve
* Added BERT stats channel variables
* Check if the channel is going down when out of sync to avoid flagging it
as out of sync, if the channel is going down it is expected to have some errors