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.
The frame (de)allocation is handled internally by each message
handler and include/frame.hh shall only provide the structure
format for RTCP Receive Report.
This makes it a little simpler to add support Secure RTCP later on,
enables us to deprecate the Receiver Report interface from src/frame.cc
and makes it automatically cross-platform (previously PACKED_STRUCT
was a GCC-only feature)
The authentication tag for each packet is stored inside the active
transaction and they are destroyed when the transaction is deallocated.
This way neither Socket nor SRTP needs to worry about (de)allocation
of those tags.
The authentication tag occupies the last slot in the pkt_vec structure
of each packet so it's easily accessible for the security layer when
calculating the checksum and guaranteed to be there if
RCE_SRTP_AUTHENTICATE_RTP has been provided.
Move frame queue to Media object and implement the generic push API
using a frame queue
This change temporarily disable the fragmentation of generic frames
Introduce buf_vec and pkt_vec structures which enable cross-platform
scatter/gather I/O. This supersedes the previous Linux-only mmsghdr
hack. Buf_vec contains buffers of a single RTP frame
whereas pkt_vec contains multiple buf_vec structures that are sent
all at once when flush_queue() is called.
From now on all media formats should use frame queue to implement
RTP frame sending. This is because internally the frame queue
updates RTP header information and it can inject additional fields
to the RTP frame such as an authentication tag.
uvgRTP can install handler f.ex. for collecting RTCP sender statistics
information or to install SRTP encryption handler.
This way these unrelated objects don't have to be passed to src/socket.cc
and it will only contain code pertaining to actual socket operations
This kind of functionality is now provided by RTP packet dispatcher
for receive-functionality and similar kind of send functionality
is implemented very soon
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.
Indicate to the main thread through a mutex that the packet dispatcher
object can be destroyed. If this is not done, there's race condition
that can result into a segmentation fault as the dispatcher object
could be destroyed before it stops running.
Packet dispatcher does not need to store the socket because it
is passed to the actual runner when the packet dispatcher is started.
This also fixes a bug where the socket's destructor is called right
after the packet dispatcher's constructor
Aaro Altonen