Packet dispatcher is responsible for doing receive-related socket operations
and dispatching the received UDP datagram to the installed packet handlers.
Packet dispatcher goes through all installed handlers until a suitable
handler for the packet is found.
If the operation timeouts, return RTP_INTERRUPTED so the caller does
not have to explicitly check for system-specific error codes when
recvfrom(2) fails
By default authentication is disabled for RTP but in can be enabled
by giving RCE_SRTP_AUTHENTICATE_RTP when creating a media stream.
When security layer gets a packet, outgoing or incoming, it will add
an authentication tag to the packet or verify the tag, respectively.
This implementation is not perfect. The largest issue is
that there is no proper packet dispatcher so late ZRTP packets
can cause some real trouble.
This and a few other issues will be addresses later on when the
architecture of packet reception and the whole socket layer is improved.
Disable SCD for now because there's just too much technical debt
to keep up with and the unknown lifetime of the RTP packet buffers
for SCD make SRTP almost an impossible task to implement properly.
Better scheme for RTP frame allocation and packet construction must
be implemented at some point.
Store the size to context because different streams may have different
maximum payload sizes. For example, an SRTP stream with RTP authentication
enabled has a smaller payload size than a normal RTP stream.
Generate nonce to ZRTP session instead of to the message directly
because in case of a "tie" we must compare hvi values to determine
roles for both participants and msg->hvi is not available at that point
Right after ZRTP has finished and the media reception has been started,
there may be a few ZRTP ACK/ConfACK messages coming in which are
perfectly valid.
This may be useful in situations where a user wishes to join a
conference call but does not wish to send any data only receiver or
vice versa.
This unidirectionality will also dictate the role for the media_stream's
RTCP object
Live555 latency test code requires us to change the design for
FFmpeg and uvgRTP too. Now the test code streams at 30 FPS and
calculates an average latency value for all frames, for intra frames
and for inter frames.
The presence of start codes and frame merging (probabyl due to presence
of SPS et al) makes the usage of frame size as key a little trickier.
Aaro Altonen