Currently only enabled in the analog e&m module but any
signaling module can easily take advantage of it with a small
modification to the signaling module to set span->sig_release_guard_time_ms
This removes our in-tree version of portaudio-19 and migrates
mod_portaudio and mod_portaudio_stream to use the system version of
the library. Our detection of the system library relies on
pkg-config.
This reverts commit b29a41bb1bf104113596c2f28a6cf255a1119c64.
This commit is no longer needed now that proper infrastructure has been
added to allow signaling modules to generate and detect DTMF
The feature macros should only be used for I/O module features
and not for signaling module features
In `srtp_unprotect_rtcp()` we are not validating that the packet
length is as long as the minimum required. This would cause
`enc_octet_len` to underflow, which would cause us to try to decrypt
data past the end of the packet in memory -- a buffer over-read and
buffer overflow.
In `srtp_protect_rtcp()`, we were similarly not validating the packet
length. Here we were also polluting the address of the SRTCP
encrypted flag and index (the `trailer`), causing us to write one word
to a bogus memory address before getting to the encryption where we
would also overflow.
In this commit we add checks to appropriately validate the RTCP/SRTCP
packet lengths.
`srtp_unprotect_rtcp_aead()` (but not protect) did correctly validate
the packet length; this check would now be redundant as the check in
`srtcp_unprotect_rtcp()` will also run first, so it has been removed.
In the defined AEAD modes, SRTP packets must always be encrypted and
authenticated, but SRTCP packets may be only authenticated. It's
possible, therefore, for us to end up in `srtp_protect_aead()` without
the `sec_serv_conf` bit being set. We should just ignore this and
encrypt the RTP packet anyway.
What we are doing instead is encrypting the packet anyway, but setting
`enc_start` to NULL first. This causes `aad_len` to underflow which
will cause us to over-read in `cipher_set_aad()`.
If we could get past that, we would try to read and write memory
starting at 0x0 down in `cipher_encrypt()`.
This commit causes us to not check the `sec_serv_conf` bit and never
set `enc_start` to NULL in `srtp_protect_aead()`.
`srtp_unprotect_aead()` does not contain a similar error.