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
Revert "depend on fs before install"
This reverts commit 6c52217920148f633b3d03ef5428dfa5938e4fd3.
Revert "removing commented work in progress on SDES and logging tunning on"
This reverts commit 6df5288f5ac7ac9c48d7f7cc730c26dae3215495.
Revert "more formatting and logging tuning"
This reverts commit 0e89bbd0333c027273e4165af850bc304861dbdc.
Revert "logging adjustment"
This reverts commit 764faad671902d734bb18ca9f87798f0670396eb.
Revert "missing host to network conversion highest_sequence_number_received"
This reverts commit 50c62cdfd7a9ddee22e9e779c0a8c4dfba23f717.
Revert "logging correction"
This reverts commit ea973b0b4cde8ecf562252d6d22faad583e30846.
Revert "[FS-6623] implement RTCP report generation"
This reverts commit 0b7863a9b7e786d35ddf5babc51ba19f1dfa7a1a.
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
