For outgoing calls send AES crypto in offer using corrected names
for keys of length 192 and 256, i.e. names containing _192_CM_
and _256_CM_ instead of _CM_192_ and CM_256_. For incoming calls
accept both naming conventions, decaying to same entry in SUITES.
+ fix after SRTP failed for 256 keys:
Tests showed loop removing '=' from keys in switch_core_media_build_crypto
1190 if (!switch_channel_var_true(channel, "rtp_pad_srtp_keys")) {
1191 p = strrchr((char *) b64_key, '=');
1192
1193 while (p && *p && *p == '=') {
1194 *p-- = '\0';
1195 }
1196 }
shouldn't be executed for AES_CM_256_HMAC_SHA1_32 and AES_CM_256_HMAC_SHA1_80
keys and it is meaningless for AES_CM_128_HMAC_SHA1_32 AES_CM_128_HMAC_SHA1_80
keys. Tested calling from Bria.
Introduced switch_channel_var_false and changed this to:
if (switch_channel_var_false(channel, "rtp_pad_srtp_keys"))
to enter the loop if var is set to false (and not if it is _not_ set).
update mod_mp4v2 fix record video and lipsync
refactor to use a dedicated video write thread
read frame_size from encoder to support mp3 and aac codec
fix audio only mode
control bandwidth and fps
* commit '720128b61ed0fba0c45ba7caa0d3d7a4bde2ffb4':
FS-11310 #resolve add more params for conference record stop event
FS-11310 #resolve add optional switch_core_file_pre_close() to stop writing to file and possible to get file size related params
In mod_conference 1.6.x, all conference users could get the audio floor
regardless of the kind of video layer they were placed in.
In 1.8.x, the concept of a 'dedicated video layer' was introduced, such that
video layout slots with a reservation ID or a role ID are marked with the
'MFLAG_DED_VID_LAYER' member flag when a member is in the slot, and such
marked layers are prevented from becoming the conference audio/video floor
holder.
This makes sense for the video floor in all circumstances, and the audio floor
in most circumstances.
However, there are some circumstances where allowing users in these dedicated
video layers to become the conference audio floor holder is preferred, such as
when all slots in the layout have reservation IDs, and the audio floor events
are used to manage users in those slots manually.
This adds a conference profile flag, 'ded-vid-layer-audio-floor, which, when
enabled, allows conference members in dedicated video layers to become the
conference audio floor holder.
The 'conference vid-res-id' sub command previously used the CONF_API_SUB_MEMBER_TARGET
command parsing strategy. The standard options exposed by that strategy didn't make
sense for this sub command, so it's now been switched to use the CONF_API_SUB_ARGS_SPLIT
command parsing strategy.
A third, optional 'force' argument has also been added. The default behavior of the
command is to toggle the user in and out of a reservation slot, use the force argument
to ensure the user is placed into the reservation slot provided.
The new signature of the sub command is:
vid-res-id <member_id> <val>|clear [force]
Previously, the font_scale parameter available for the video_mute_banner/video_banner_text
conference channel variable would only accept integer values. It now can accept float
values for more fine grained control, eg:
<action
application="set"
data="video_banner_text={font_scale=.75}Banner Text"
/>
Add params to set min_font_size and max_font_size for video banners.
The hard-coded defaults of 5/24 for min/max font size don't always look good
depending on the layout use case. This adds min_font_size and max_font_size
params for more fine-grained control, eg:
<action
application="set"
data="video_banner_text={min_font_size=8,max_font_size=14}Banner Text"
/>
Regular conference members that are assigned a reservation ID in a layout
are automatically placed in that same reservation ID upon change of a layout.
However, playing files that are assigned a reservation ID are not properly
assigned to the same reservation ID upon layout change.
This patch makes the behavior consistent between the two types.
Andrey Volk