Release Version 3.0.0

[pabuhler]

Note: This is task definition is a work in progress

This is a high level issue to track architectural and coding effort to create and release the next major version of libSRTP.

Goal

Provide a cross platform C99 conformant SRTP library with a safe and flexible API.
Fix and close all issues that have been postponed due to ABI and behavioral restrictions.
Update build system and tools to be inline with current conventions.

Plan

Each PR should only change a single piece of functionality to help simplify reviews and traceability. Where possible test should not be refactored in the same commit as major code changes.

Tasks

• Create 2.x branch then prepare main for 3.x development
• Look into CI test between version
• Consider library name, currently libsrtp2.x, maybe libsrtp3.x? Check "so" name has correct version
• Clean out unused files from repo, there are a few old scripts that probably do not belong
• Use consistent types through out code base #671
• update policy config api #790
• Review public API #672
• No consistency when use some srtp_* functions. #220
• provide an new version of protect function that does not corrupt memory #322
• Please add a "non inplace" protect and unprotect API #569
• Handling Master Key Lifetime #588
• Consider setting openssl as default crypto backend #579
• Remove srtp_crypto_policy_set_aes_gcm_128_8_XXXX functions from API #441
• srtp_create fails if setting up RTP encryption with AES-128-GCM and not specifying RTCP encryption #642
• Update fuzzer with new api
• Update target to version 3 #716

[paulej]

Another item to consider is removing the legacy srtp_kdf() calls and types / definitions that do not exist in OpenSSL.

[fquiers]

Could we also consider any improvement related to this ticket please:
#642
Thank you

[pabuhler]

Could we also consider any improvement related to this ticket please: #642 Thank you

Will try to close all issues before 3.0, and this should go away by it's self when cleaning up config api but will make sure of it!

[muradahmed12]

I'm currently working on a project targeting .NET 8 Core and need to integrate the CCSICOILLib library (Cisco COM library). However, I'm facing issues with COM referencing and the ResolveComReference task, which seems unsupported in .NET Core. I would like to know if CCSICOILLib is compatible with .NET 8 Core or if there are any recommended solutions or workarounds to use this library in a .NET 8 Core environment? Any insights or advice would be greatly appreciated.

[hmaarrfk]

Are you considering that downstream users might be co-installing libsrtp2 and libsrtp3? I'm asking since I'm packaging things for downstream usag eat conda-forge and I'm wondering if I should name the package libsrtp or libsrtp2

conda-forge/staged-recipes#30955

[pabuhler]

Are you considering that downstream users might be co-installing libsrtp2 and libsrtp3? I'm asking since I'm packaging things for downstream usag eat conda-forge and I'm wondering if I should name the package libsrtp or libsrtp2

conda-forge/staged-recipes#30955

I think this is up to downstream packages, libsrtp2 and libsrtp3 should be able to live side by side as they have different include paths and library names. It will not be possible to use both simultaneously from an application without some trickery though.