I have no idea why the name had an underscore but now it's gone.
The old namespace is kept as an alias for backwards-compatibility
but it may be removed in the future
Create separate classes for SRTP and SRTCP because even though
they are quite similar, they require some different actions when
en/decrypting the packets and create a whole bunch of if-elses
is ugly
Operate on a raw block of memory, extract interesting fields from the
packet and create user-friendly struct for the APP packet that
can be queried using SSRC
Caller must remember to free the memory occupied by the APP payload
Operate on a raw block of memory, extract interesting fields from the
packet and create user-friendly struct for the SDES packet that
can be queried using SSRC
Caller must remember to free the memory occupied by the SDES items
Operate on a raw block of memory, extract interesting fields from the
packet and create user-friendly struct for the Sender Report that
can be queried using SSRC
PACKED_STRUCT is quite an ugly hack if it must be cross-platform
so better to process the incoming (and soon outgoing) RTCP data
as raw memory and craft user-friendly RTCP packets from those
memory blocks which do not including strict padding or truncated fields.
Some packet handlers (such as RTCP) may need access to the parent
object or they may require some additional data from outside the
packet handler that is required when processing the packet.
Having a 1100 lines long file is not manageable so split RTCP
code into different files by packet type and leave all the
session-related code to src/rtcp.cc
Because most packet handlers do not require the raw UDP datagram
received through the socket, it makes little sense to relay those
parameters to them.
Additionally, there's a clear distinction between crafting
an RTP frame and operating on it so having one handler type
for both operations is not the best design choice.
Thus the packet handlers are divided into primary and auxiliary
handlers. Primary handlers are responsible for creating a packet
that the auxiliary handlers can operate on and auxiliary handlers
are responsible for doing all other operations on the packet such as
gathering sessions statistic information or decrypting the packet.
RTCP is used to gather session statistics and detect SSRC collisions
so all packets should be relayd to the RTCP layer for monitoring
even if RTCP packets are not being sent.
If RTCP Sender/Receiver reports are needed, RCE_RTCP should be given
when creating a media stream.
Aaro Altonen