With this in place enabling an additional crypto suite
would only require two changes:
- Adding GStreamer capability mapping
- Add case in calls_srtp_parse_sdp_crypto_attribute()
This indicates integer counter mode being used and
helps disambiguate additional crypto suites in the future.
Renamed CALLS_SRTP_SUITE_AES_128_SHA1_80 → CALLS_SRTP_SUITE_AES_128_ICM_SHA1_80
and CALLS_SRTP_SUITE_AES_128_SHA1_32 → CALLS_SRTP_SUITE_AES_128_ICM_SHA1_32
https://www.rfc-editor.org/rfc/rfc4568.html#section-6.1 says:
When base64 decoding the key and salt, padding characters (i.e.,
one or two "=" at the end of the base64-encoded data) are discarded
(see [RFC3548] for details).
https://www.rfc-editor.org/rfc/rfc3548#section-2.2 says:
In some circumstances, the use of padding ("=") in base encoded data
is not required nor used. In the general case, when assumptions on
size of transported data cannot be made, padding is required to yield
correct decoded data.
Since we will introduce another type of plugin for the policy engine
we want to have each plugin type in separate directories.
We also have to adjust:
- plugin search directories
- po file location
- update paths for calls-doc target
2022-08-19 08:43:57 +00:00
Renamed from plugins/sip/calls-srtp-utils.c (Browse further)
