[FS-5422] Modify SRTP to use OpenSSL Created: 14/May/13  Updated: 24/Feb/14  Resolved: 24/Feb/14

Status: Closed
Project: FreeSWITCH
Component/s: RTP
Affects Version/s: 1.3.0
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Kristian Kielhofner Assignee: Mike Jerris
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Attachments: Text File freeswitch-libsrtp-openssl.patch    
CPU Architecture:
FreeSWITCH GIT Revision: All
GIT Master Revision hash:: Yes


SRTP currently uses libsrtp which provides its own AES implementation. I would like SRTP functionality in FreeSWITCH to use the built in OpenSSL AES functions, with the eventual goal (potentially) being the use of OpenSSL hardware engine acceleration (VIA padlock, hifn, Xeon AES, Geode, etc).

Comment by Travis Cross [ 26/May/13 ]

It's almost futile to speed up the AES calculation in SRTP because the auth tag calculation is more expensive.

Comment by Kristian Kielhofner [ 28/Oct/13 ]

It looks like a good chunk of this work is being done in the (now official) libsrtp github repo:


Comment by Kristian Kielhofner [ 02/Nov/13 ]

The office libsrtp github repo now supports AES-NI with the feature-openssl branch:


Check out those performance improvements! Also, performance can be even better when AES-GCM mode is used:


Comment by Kristian Kielhofner [ 06/Nov/13 ]

Added (very early) patch to build FreeSWITCH with the feature-openssl branch of libsrtp from github. A few caveats:

  • Builds with warnings (not good)
  • May not work in non-Linux, non-x86_64 environments
  • Is generally ugly (calls libsrtp/configure --enable-openssl from Makefile, for example)
  • May not work at all

Has been tested successfully with AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, and AES_GCM_128_8:


Comment by John Foley [ 07/Nov/13 ]

The libsrtp feature-openssl branch will compile for non-Intel platforms. However, the link dependency on openssl (libcrypto.so) still remains. Therefore, openssl would need to be compiled first.

Additionally, the --enable-openssl knob could be removed when building libsrtp for cross-compiled targets, which reverts libsrtp to the legacy ciphers and eliminates the need for openssl. However, there is no GCM support in libsrtp when doing this. Therefore, you would need to conditionally remove GCM support in Freeswitch to avoid link errors.

Comment by Kristian Kielhofner [ 07/Nov/13 ]

I was addressing limitations in my patch, not limitations in feature-openssl. Namely that some things (like CFLAGS=-fPIC) are hardcoded in my patch and it has barely been tested; even then only on Linux x86_64. My patch also calls pkg-config to get CFLAGS and libs for OpenSSL, ideally feature-openssl would support --with-openssl=[PATH] instead of --enable-openssl so that FreeSWITCH (and others) could pass the path to OpenSSL directly. I'll work on that but it still needs to get more cleanly integrated with the FS build system.

Comment by John Foley [ 07/Nov/13 ]

In response to the comments from Travis, OpenSSL has a built-in performance test that can be used for rudimentary performance comparison. Here are some results that show SHA1, AES w/o AES-NI, and AES w/AES-NI:

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc-ni 594457.88k 643835.24k 657815.12k 656594.26k 659701.76k
aes-128 cbc 105631.41k 117847.40k 122038.61k 120942.59k 122225.19k
sha1 52862.42k 155876.32k 362228.82k 538963.29k 631921.02k

As you can see, SHA1 performs quite well compared to legacy AES if the packets are 64 bytes or larger. Maybe the SHA1 implementation in the legacy libsrtp library is much slower. But given the data above, you should see a significant improvement in CPU utilization for SRTP traffic when using AES-NI. However, this will vary by packet size.

Comment by Travis Cross [ 25/Jan/14 ]

John: For SRTP you should be comparing to CTR mode.

I clearly don't have any objection to making this faster; I was just pointing out the gains won't be nearly as large as you would otherwise expect. Of course, if you use AES-GCM mode as in FS-5937 then you will likely see impressive gains.

Comment by Brian West [ 19/Feb/14 ]

If you have patches for this issue that need to be updated for use with MASTER please do so ASAP, If this is an issue where the problem persists please response and provide additional details after you test again on Stable and/or Master. If your issue is a feature request please follow up and express interest in the features that aren't complete being done via a bounty or possibly a community member.

Provide additional details or guidance for moving your issues forward.

Feel free to ping me via email if you have questions directly brian@freeswitch.org


Brian West
FreeSWITCH Solutions, LLC
PO BOX 2531
Brookfield, WI 53008-2531
Twitter: @FreeSWITCH , @briankwest

T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST
iNUM: +883 5100 1420 9001
ISN: 410*543
PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)

Comment by Travis Cross [ 24/Feb/14 ]

This went in with commits 80c7eb85e6c506e4eed6288da4e9eaba90a371a9 and bab923923a530d244dbbfe3ac94d96d8f74daef2.

Generated at Thu Aug 22 21:23:40 CDT 2019 using Jira 8.1.0#801000-sha1:2e1cd1bb771978cda2c5e8f3f10539ab180613f6.