Name |
Date |
Size |
#Lines |
LOC |
||
---|---|---|---|---|---|---|
.. | - | - | ||||
crypto/ | 03-May-2024 | - | 14,490 | 8,347 | ||
doc/ | 03-May-2024 | - | 4,002 | 3,176 | ||
exported_include/srtp2/ | 03-May-2024 | - | ||||
fuzzer/ | 03-May-2024 | - | 1,296 | 978 | ||
include/ | 03-May-2024 | - | 2,375 | 456 | ||
srtp/ | 03-May-2024 | - | 5,012 | 3,155 | ||
test/ | 03-May-2024 | - | 8,859 | 6,181 | ||
.clang-format | D | 03-May-2024 | 1.9 KiB | 80 | 63 | |
.gitignore | D | 03-May-2024 | 591 | 50 | 44 | |
.travis.yml | D | 03-May-2024 | 5.8 KiB | 213 | 185 | |
Android.bp | D | 03-May-2024 | 2.8 KiB | 99 | 95 | |
CHANGES | D | 03-May-2024 | 7.2 KiB | 228 | 129 | |
CMakeLists.txt | D | 03-May-2024 | 5.1 KiB | 201 | 171 | |
LICENSE | D | 03-May-2024 | 1.6 KiB | 36 | 35 | |
METADATA | D | 03-May-2024 | 39 | 4 | 3 | |
Makefile.in | D | 03-May-2024 | 10.3 KiB | 332 | 228 | |
README.md | D | 03-May-2024 | 22 KiB | 509 | 409 | |
config.guess | D | 03-May-2024 | 42.7 KiB | 1,457 | 1,264 | |
config.h_win32vc7 | D | 03-May-2024 | 4.3 KiB | 163 | 111 | |
config.hw | D | 03-May-2024 | 4.9 KiB | 183 | 128 | |
config.sub | D | 03-May-2024 | 35.3 KiB | 1,816 | 1,678 | |
config_in.h | D | 03-May-2024 | 5.1 KiB | 197 | 71 | |
config_in_cmake.h | D | 03-May-2024 | 3.3 KiB | 116 | 42 | |
configure | D | 03-May-2024 | 216 KiB | 7,772 | 6,551 | |
configure.ac | D | 03-May-2024 | 14.8 KiB | 427 | 381 | |
format.sh | D | 03-May-2024 | 640 | 36 | 25 | |
install-sh | D | 03-May-2024 | 14.3 KiB | 502 | 327 | |
install-win.bat | D | 03-May-2024 | 939 | 36 | 29 | |
libsrtp2.pc.in | D | 03-May-2024 | 251 | 12 | 9 | |
srtp.def | D | 03-May-2024 | 2 KiB | 76 | 75 | |
srtp.sln | D | 03-May-2024 | 2.1 KiB | 41 | 39 | |
srtp2.vcxproj | D | 03-May-2024 | 20.1 KiB | 406 | 405 | |
srtp2.vcxproj.filters | D | 03-May-2024 | 6.6 KiB | 190 | 189 | |
timing | D | 03-May-2024 | 1.1 KiB | 36 | 36 | |
undos.sh | D | 03-May-2024 | 167 | 11 | 2 | |
update.sh | D | 03-May-2024 | 188 | 16 | 5 |
README.md
1[](https://travis-ci.org/cisco/libsrtp) 2[](https://scan.coverity.com/projects/cisco-libsrtp) 3 4<a name="introduction-to-libsrtp"></a> 5# Introduction to libSRTP 6 7This package provides an implementation of the Secure Real-time 8Transport Protocol (SRTP), the Universal Security Transform (UST), and 9a supporting cryptographic kernel. The SRTP API is documented in include/srtp.h, 10and the library is in libsrtp2.a (after compilation). 11 12This document describes libSRTP, the Open Source Secure RTP library 13from Cisco Systems, Inc. RTP is the Real-time Transport Protocol, an 14IETF standard for the transport of real-time data such as telephony, 15audio, and video, defined by [RFC 3550](https://www.ietf.org/rfc/rfc3550.txt). 16Secure RTP (SRTP) is an RTP profile for providing confidentiality to RTP data 17and authentication to the RTP header and payload. SRTP is an IETF Standard, 18defined in [RFC 3711](https://www.ietf.org/rfc/rfc3711.txt), and was developed 19in the IETF Audio/Video Transport (AVT) Working Group. This library supports 20all of the mandatory features of SRTP, but not all of the optional features. See 21the [Supported Features](#supported-features) section for more detailed information. 22 23This document is also used to generate the documentation files in the /doc/ 24folder where a more detailed reference to the libSRTP API and related functions 25can be created (requires installing doxygen.). The reference material is created 26automatically from comments embedded in some of the C header files. The 27documentation is organized into modules in order to improve its clarity. These 28modules do not directly correspond to files. An underlying cryptographic kernel 29provides much of the basic functionality of libSRTP but is mostly undocumented 30because it does its work behind the scenes. 31 32-------------------------------------------------------------------------------- 33 34<a name="contact-us"></a> 35# Contact Us 36 37- [libsrtp@lists.packetizer.com](mailto:libsrtp@lists.packetizer.com) general mailing list for news / announcements / discussions. This is an open list, see 38[https://lists.packetizer.com/mailman/listinfo/libsrtp](https://lists.packetizer.com/mailman/listinfo/libsrtp) for singing up. 39 40- [libsrtp-security@lists.packetizer.com](mailto:libsrtp-security@lists.packetizer.com) for disclosing security issues to the libsrtp maintenance team. This is a closed list but anyone can send to it. 41 42 43-------------------------------------------------------------------------------- 44 45<a name="contents"></a> 46## Contents 47 48- [Introduction to libSRTP](#introduction-to-libsrtp) 49- [Contact Us](#contact-us) 50 - [Contents](#contents) 51- [License and Disclaimer](#license-and-disclaimer) 52- [libSRTP Overview](#libsrtp-overview) 53 - [Secure RTP Background](#secure-rtp-background) 54 - [Supported Features](#supported-features) 55 - [Implementation Notes](#implementation-notes) 56- [Installing and Building libSRTP](#installing-and-building-libsrtp) 57 - [Changing Build Configuration](#changing-build-configuration) 58 - [Using Visual Studio](#using-visual-studio) 59- [Applications](#applications) 60 - [Example Code](#example-code) 61- [Credits](#credits) 62- [References](#references) 63 64-------------------------------------------------------------------------------- 65 66<a name="license-and-disclaimer"></a> 67# License and Disclaimer 68 69libSRTP is distributed under the following license, which is included 70in the source code distribution. It is reproduced in the manual in 71case you got the library from another source. 72 73> Copyright (c) 2001-2017 Cisco Systems, Inc. All rights reserved. 74> 75> Redistribution and use in source and binary forms, with or without 76> modification, are permitted provided that the following conditions 77> are met: 78> 79> - Redistributions of source code must retain the above copyright 80> notice, this list of conditions and the following disclaimer. 81> - Redistributions in binary form must reproduce the above copyright 82> notice, this list of conditions and the following disclaimer in 83> the documentation and/or other materials provided with the distribution. 84> - Neither the name of the Cisco Systems, Inc. nor the names of its 85> contributors may be used to endorse or promote products derived 86> from this software without specific prior written permission. 87> 88> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 89> "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 90> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 91> FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 92> COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 93> INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 94> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 95> SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 96> HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 97> STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 98> ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 99> OF THE POSSIBILITY OF SUCH DAMAGE. 100 101-------------------------------------------------------------------------------- 102 103<a name="libsrtp-overview"></a> 104# libSRTP Overview 105 106libSRTP provides functions for protecting RTP and RTCP. RTP packets 107can be encrypted and authenticated (using the `srtp_protect()` 108function), turning them into SRTP packets. Similarly, SRTP packets 109can be decrypted and have their authentication verified (using the 110`srtp_unprotect()` function), turning them into RTP packets. Similar 111functions apply security to RTCP packets. 112 113The typedef `srtp_stream_t` points to a structure holding all of the 114state associated with an SRTP stream, including the keys and 115parameters for cipher and message authentication functions and the 116anti-replay data. A particular `srtp_stream_t` holds the information 117needed to protect a particular RTP and RTCP stream. This datatype 118is intentionally opaque in order to better seperate the libSRTP 119API from its implementation. 120 121Within an SRTP session, there can be multiple streams, each 122originating from a particular sender. Each source uses a distinct 123stream context to protect the RTP and RTCP stream that it is 124originating. The typedef `srtp_t` points to a structure holding all of 125the state associated with an SRTP session. There can be multiple 126stream contexts associated with a single `srtp_t`. A stream context 127cannot exist indepent from an `srtp_t`, though of course an `srtp_t` can 128be created that contains only a single stream context. A device 129participating in an SRTP session must have a stream context for each 130source in that session, so that it can process the data that it 131receives from each sender. 132 133In libSRTP, a session is created using the function `srtp_create()`. 134The policy to be implemented in the session is passed into this 135function as an `srtp_policy_t` structure. A single one of these 136structures describes the policy of a single stream. These structures 137can also be linked together to form an entire session policy. A linked 138list of `srtp_policy_t` structures is equivalent to a session policy. 139In such a policy, we refer to a single `srtp_policy_t` as an *element*. 140 141An `srtp_policy_t` structure contains two `srtp_crypto_policy_t` structures 142that describe the cryptograhic policies for RTP and RTCP, as well as 143the SRTP master key and the SSRC value. The SSRC describes what to 144protect (e.g. which stream), and the `srtp_crypto_policy_t` structures 145describe how to protect it. The key is contained in a policy element 146because it simplifies the interface to the library. In many cases, it 147is desirable to use the same cryptographic policies across all of the 148streams in a session, but to use a distinct key for each stream. A 149`srtp_crypto_policy_t` structure can be initialized by using either the 150`srtp_crypto_policy_set_rtp_default()` or `srtp_crypto_policy_set_rtcp_default()` 151functions, which set a crypto policy structure to the default policies 152for RTP and RTCP protection, respectively. 153 154-------------------------------------------------------------------------------- 155 156<a name="secure-rtp-background"></a> 157## Secure RTP Background 158 159In this section we review SRTP and introduce some terms that are used 160in libSRTP. An RTP session is defined by a pair of destination 161transport addresses, that is, a network address plus a pair of UDP 162ports for RTP and RTCP. RTCP, the RTP control protocol, is used to 163coordinate between the participants in an RTP session, e.g. to provide 164feedback from receivers to senders. An *SRTP session* is 165similarly defined; it is just an RTP session for which the SRTP 166profile is being used. An SRTP session consists of the traffic sent 167to the SRTP or SRTCP destination transport addresses. Each 168participant in a session is identified by a synchronization source 169(SSRC) identifier. Some participants may not send any SRTP traffic; 170they are called receivers, even though they send out SRTCP traffic, 171such as receiver reports. 172 173RTP allows multiple sources to send RTP and RTCP traffic during the 174same session. The synchronization source identifier (SSRC) is used to 175distinguish these sources. In libSRTP, we call the SRTP and SRTCP 176traffic from a particular source a *stream*. Each stream has its own 177SSRC, sequence number, rollover counter, and other data. A particular 178choice of options, cryptographic mechanisms, and keys is called a 179*policy*. Each stream within a session can have a distinct policy 180applied to it. A session policy is a collection of stream policies. 181 182A single policy can be used for all of the streams in a given session, 183though the case in which a single *key* is shared across multiple 184streams requires care. When key sharing is used, the SSRC values that 185identify the streams **must** be distinct. This requirement can be 186enforced by using the convention that each SRTP and SRTCP key is used 187for encryption by only a single sender. In other words, the key is 188shared only across streams that originate from a particular device (of 189course, other SRTP participants will need to use the key for 190decryption). libSRTP supports this enforcement by detecting the case 191in which a key is used for both inbound and outbound data. 192 193-------------------------------------------------------------------------------- 194 195<a name="supported-features"></a> 196## Supported Features 197 198This library supports all of the mandatory-to-implement features of 199SRTP (as defined in [RFC 3711](https://www.ietf.org/rfc/rfc3711.txt)). Some of these 200features can be selected (or de-selected) at run time by setting an 201appropriate policy; this is done using the structure `srtp_policy_t`. 202Some other behaviors of the protocol can be adapted by defining an 203approriate event handler for the exceptional events; see the SRTPevents 204section in the generated documentation. 205 206Some options that are described in the SRTP specification are not 207supported. This includes 208 209- key derivation rates other than zero, 210- the cipher F8, 211- the use of the packet index to select between master keys. 212 213The user should be aware that it is possible to misuse this libary, 214and that the result may be that the security level it provides is 215inadequate. If you are implementing a feature using this library, you 216will want to read the Security Considerations section of [RFC 3711](https://www.ietf.org/rfc/rfc3711.txt). 217In addition, it is important that you read and understand the 218terms outlined in the [License and Disclaimer](#license-and-disclaimer) section. 219 220-------------------------------------------------------------------------------- 221 222<a name="implementation-notes"></a> 223## Implementation Notes 224 225 * The `srtp_protect()` function assumes that the buffer holding the 226 rtp packet has enough storage allocated that the authentication 227 tag can be written to the end of that packet. If this assumption 228 is not valid, memory corruption will ensue. 229 230 * Automated tests for the crypto functions are provided through 231 the `cipher_type_self_test()` and `auth_type_self_test()` functions. 232 These functions should be used to test each port of this code 233 to a new platform. 234 235 * Replay protection is contained in the crypto engine, and 236 tests for it are provided. 237 238 * This implementation provides calls to initialize, protect, and 239 unprotect RTP packets, and makes as few as possible assumptions 240 about how these functions will be called. For example, the 241 caller is not expected to provide packets in order (though if 242 they're called more than 65k out of sequence, synchronization 243 will be lost). 244 245 * The sequence number in the rtp packet is used as the low 16 bits 246 of the sender's local packet index. Note that RTP will start its 247 sequence number in a random place, and the SRTP layer just jumps 248 forward to that number at its first invocation. An earlier 249 version of this library used initial sequence numbers that are 250 less than 32,768; this trick is no longer required as the 251 `rdbx_estimate_index(...)` function has been made smarter. 252 253 * The replay window for (S)RTCP is hardcoded to 128 bits in length. 254 255-------------------------------------------------------------------------------- 256 257<a name="installing-and-building-libsrtp"></a> 258# Installing and Building libSRTP 259 260To install libSRTP, download the latest release of the distribution 261from [https://github.com/cisco/libsrtp/releases](https://github.com/cisco/libsrtp/releases). 262You probably want to get the most recent release. Unpack the distribution and 263extract the source files; the directory into which the source files 264will go is named `libsrtp-A-B-C` where `A` is the version number, `B` is the 265major release number and `C` is the minor release number. 266 267libSRTP uses the GNU `autoconf` and `make` utilities (BSD make will not work; if 268both versions of make are on your platform, you can invoke GNU make as 269`gmake`.). In the `libsrtp` directory, run the configure script and then 270make: 271 272~~~.txt 273./configure [ options ] 274make 275~~~ 276 277The configure script accepts the following options: 278 279Option | Description 280-------------------------------|-------------------- 281\-\-help \-h | Display help 282\-\-enable-debug-logging | Enable debug logging in all modules 283\-\-enable-log-stdout | Enable logging to stdout 284\-\-enable-openssl | Enable OpenSSL crypto engine 285\-\-enable-openssl-kdf | Enable OpenSSL KDF algorithm 286\-\-with-log-file | Use file for logging 287\-\-with-openssl-dir | Location of OpenSSL installation 288 289By default there is no log output, logging can be enabled to be output to stdout 290or a given file using the configure options. 291 292This package has been tested on the following platforms: Mac OS X 293(powerpc-apple-darwin1.4), Cygwin (i686-pc-cygwin), Solaris 294(sparc-sun-solaris2.6), RedHat Linux 7.1 and 9 (i686-pc-linux), and 295OpenBSD (sparc-unknown-openbsd2.7). 296 297-------------------------------------------------------------------------------- 298 299<a name="changing-build-configuration"></a> 300## Changing Build Configuration 301 302To build the `./configure` script mentioned above, libSRTP relies on the 303[automake](https://www.gnu.org/software/automake/) toolchain. Since 304`./configure` is built from `configure.in` by automake, if you make changes in 305how `./configure` works (e.g., to add a new library dependency), you will need 306to rebuild `./configure` and commit the updated version. In addition to 307automake itself, you will need to have the `pkgconfig` tools installed as well. 308 309For example, on macOS: 310 311``` 312brew install automake pkgconfig 313# Edit configure.in 314autoremake -ivf 315``` 316 317-------------------------------------------------------------------------------- 318<a name="using-visual-studio"></a> 319## Using Visual Studio 320 321On Windows one can use Visual Studio via CMake. CMake can be downloaded here: 322https://cmake.org/ . To create Visual Studio build files, for example run the 323following commands: 324 325``` 326# Create build subdirectory 327mkdir build 328cd build 329 330# Make project files 331cmake .. -G "Visual Studio 15 2017" 332 333# Or for 64 bit project files 334cmake .. -G "Visual Studio 15 2017 Win64" 335``` 336 337-------------------------------------------------------------------------------- 338 339<a name="applications"></a> 340# Applications 341 342Several test drivers and a simple and portable srtp application are 343included in the `test/` subdirectory. 344 345Test driver | Function tested 346--------- | ------- 347kernel_driver | crypto kernel (ciphers, auth funcs, rng) 348srtp_driver | srtp in-memory tests (does not use the network) 349rdbx_driver | rdbx (extended replay database) 350roc_driver | extended sequence number functions 351replay_driver | replay database 352cipher_driver | ciphers 353auth_driver | hash functions 354 355The app `rtpw` is a simple rtp application which reads words from 356`/usr/dict/words` and then sends them out one at a time using [s]rtp. 357Manual srtp keying uses the -k option; automated key management 358using gdoi will be added later. 359 360usage: 361~~~.txt 362rtpw [[-d <debug>]* [-k|b <key> [-a][-e <key size>][-g]] [-s | -r] dest_ip dest_port] | [-l] 363~~~ 364 365Either the -s (sender) or -r (receiver) option must be chosen. The 366values `dest_ip`, `dest_port` are the IP address and UDP port to which 367the dictionary will be sent, respectively. 368 369The options are: 370 371Option | Description 372--------- | ------- 373 -s | (S)RTP sender - causes app to send words 374 -r | (S)RTP receive - causes app to receive words 375 -k <key> | use SRTP master key <key>, where the key is a hexadecimal (without the leading "0x") 376 -b <key> | same as -k but with base64 encoded key 377 -e <keysize> | encrypt/decrypt (for data confidentiality) (requires use of -k option as well) (use 128, 192, or 256 for keysize) 378 -g | use AES-GCM mode (must be used with -e) 379 -a | message authentication (requires use of -k option as well) 380 -l | list the available debug modules 381 -d <debug> | turn on debugging for module <debug> 382 383In order to get random 30-byte values for use as key/salt pairs , you 384can use the following bash function to format the output of 385`/dev/random` (where that device is available). 386 387~~~.txt 388function randhex() { 389 cat /dev/random | od --read-bytes=32 --width=32 -x | awk '{ print $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 }' 390} 391~~~ 392 393An example of an SRTP session using two rtpw programs follows: 394 395~~~.txt 396set k=c1eec3717da76195bb878578790af71c4ee9f859e197a414a78d5abc7451 397 398[sh1]$ test/rtpw -s -k $k -e 128 -a 0.0.0.0 9999 399Security services: confidentiality message authentication 400set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC7451 401setting SSRC to 2078917053 402sending word: A 403sending word: a 404sending word: aa 405sending word: aal 406... 407 408[sh2]$ test/rtpw -r -k $k -e 128 -a 0.0.0.0 9999 409security services: confidentiality message authentication 410set master key/salt to C1EEC3717DA76195BB878578790AF71C/4EE9F859E197A414A78D5ABC7451 41119 octets received from SSRC 2078917053 word: A 41219 octets received from SSRC 2078917053 word: a 41320 octets received from SSRC 2078917053 word: aa 41421 octets received from SSRC 2078917053 word: aal 415... 416~~~ 417 418-------------------------------------------------------------------------------- 419 420<a name="example-code"></a> 421## Example Code 422 423This section provides a simple example of how to use libSRTP. The 424example code lacks error checking, but is functional. Here we assume 425that the value ssrc is already set to describe the SSRC of the stream 426that we are sending, and that the functions `get_rtp_packet()` and 427`send_srtp_packet()` are available to us. The former puts an RTP packet 428into the buffer and returns the number of octets written to that 429buffer. The latter sends the RTP packet in the buffer, given the 430length as its second argument. 431 432~~~.c 433srtp_t session; 434srtp_policy_t policy; 435 436// Set key to predetermined value 437uint8_t key[30] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 438 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 439 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 440 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D}; 441 442// initialize libSRTP 443srtp_init(); 444 445// default policy values 446memset(&policy, 0x0, sizeof(srtp_policy_t)); 447 448// set policy to describe a policy for an SRTP stream 449srtp_crypto_policy_set_rtp_default(&policy.rtp); 450srtp_crypto_policy_set_rtcp_default(&policy.rtcp); 451policy.ssrc = ssrc; 452policy.key = key; 453policy.next = NULL; 454 455// allocate and initialize the SRTP session 456srtp_create(&session, &policy); 457 458// main loop: get rtp packets, send srtp packets 459while (1) { 460 char rtp_buffer[2048]; 461 unsigned len; 462 463 len = get_rtp_packet(rtp_buffer); 464 srtp_protect(session, rtp_buffer, &len); 465 send_srtp_packet(rtp_buffer, len); 466} 467~~~ 468 469-------------------------------------------------------------------------------- 470 471<a name="credits"></a> 472# Credits 473 474The original implementation and documentation of libSRTP was written 475by David McGrew of Cisco Systems, Inc. in order to promote the use, 476understanding, and interoperability of Secure RTP. Michael Jerris 477contributed support for building under MSVC. Andris Pavenis 478contributed many important fixes. Brian West contributed changes to 479enable dynamic linking. Yves Shumann reported documentation bugs. 480Randell Jesup contributed a working SRTCP implementation and other 481fixes. Steve Underwood contributed x86_64 portability changes. We also give 482thanks to Fredrik Thulin, Brian Weis, Mark Baugher, Jeff Chan, Bill 483Simon, Douglas Smith, Bill May, Richard Preistley, Joe Tardo and 484others for contributions, comments, and corrections. 485 486This reference material, when applicable, in this documenation was generated 487using the doxygen utility for automatic documentation of source code. 488 489Copyright 2001-2005 by David A. McGrew, Cisco Systems, Inc. 490 491-------------------------------------------------------------------------------- 492 493<a name="references"></a> 494# References 495 496SRTP and ICM References 497September, 2005 498 499Secure RTP is defined in [RFC 3711](https://www.ietf.org/rfc/rfc3711.txt). 500The counter mode definition is in Section 4.1.1. 501 502SHA-1 is defined in [FIPS PUB 180-4](http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf). 503 504HMAC is defined in [RFC 2104](https://www.ietf.org/rfc/rfc2104.txt) 505and HMAC-SHA1 test vectors are available 506in [RFC 2202](https://www.ietf.org/rfc/rfc2202.txt). 507 508AES-GCM usage in SRTP is defined in [RFC 7714](https://www.ietf.org/html/rfc7714) 509