Because kvzRTP only supports the mandatory algorithms required by the
spec, we don't even need to parse the remote's Hello message because
by assuming it supports all the mandatory too, we can just fill the
capabilities struct with those algorithms and proceeds with the session
initialization.
Calculate CRC32 checksum of the whole ZRTP packet and add it at the
end of packet and verify the checksum when a packet is received.
If the verification fails, the packet is simply discarded
Recalculate all session hashes using H0 received in the ConfirmN
Message, calculate MACs for all received messages and compare them
against the MACs that were received in the messages to see if the
session is valid
Because the confirm_mac is computed over the encrypted portion of
the message and because ConfirmN's parse_msg() decrypts the message,
the obvious place to verify the MAC is parse_msg()
Now all the message related to DH key exchange are supported and
all that is left is creating a public API and verifying messages
before the ZRTP is ended.
Now kvzRTP creates a private/public key pair and sends the public
key in the DHPartN message to remote.
kvzRTP does not support Preshared mode so the retained secrets just
contain random values and are going to be ignore when the shared
secrets are established.
DHResult is already calculated successfully though the architecture
is really starting show its limitations because the sha256 values
of various messages are calculated everywhere in the code which is
pretty ugly. Maybe create getters for various messages and calculate
all hashes at once.
Commit message partially depends on DHPart2 and Hello messages to
construct the hvi value. The architecture of ZRTP is going to change
a tiny bit in the near future to construct the DHPart2 and create
the actual public/private key pairs before anything else
Now they should work on both Linux and Windows and Hello messages
contain all the information required by the specification.
The parsing of algorithms is still missing but because kvzRTP's
implementation is only going to provide the mandatory algorithms,
the lists can be omitted and as long as we're only communicating with
ourselves, the parsing can be omitted too.
At some point in the future I'll add proper parsing and remove the GNU
extension from ZRTP to make it truly cross-platform and compatible with
other RTP libraries supporting ZRTP
Commit messages are exchanged and roles for both parties are selected
as defined in RFC 6189. Lots of details are omitted and they will be
implemented later on when crypto functionality is added to the project
kvzRTP's ZRTP implementation shall support only the mandatory algorithms
defined in the specification. There are several things missing from Hello
but those are somewhat minor details and will be fixed when the ZRTP is
starting to be ready
Making configuration global was moronic considering there are
different types of media streams per session (f.ex Opus and HEVC)
which have very different types of needs. For example, setting
receiver's UDP buffer size to 40 MB would make no sense for Opus.
Now each connection can be configured individually which is also
a needed feature for SRTP
This change reverted the changes made earlier to global API
The security layer is injected between reading a datagram from OS and
RTP/RTCP payload processing so the obvious place for that layer is socket.
Make all recv/send function calls go through socket API so the security
layer function calls doesn't have to be copied everywhere
To prevent excess relocations but to minimize the nubmer of system
calls done, OFR reads 15 datagrams from OS using one system call if
more than 2% or less than 98% of the frame has been read.
These values are a result of experimentation and they lowered the CPU
utilization most. Compared to simple receiver, OFR, with dynamic datagram
read size, uses 14% less CPU than.
These numbers could be improved even further if media-specific
optimizations would be done such as keeping track of intra or VPS
period to adjust max datagram read size or the legal interval for
max read.
This optimizations are, however, probably not going to yield a lot
of benefit compared to the current state of OFR and are thus not
implemented. As it is, OFR is already able to receive HEVC at
580 MB/s and uses 14% less CPU than simple so for high-quality video
conferencing situations with multiple participants this is a good
choice.
The version that does not use sendmmsg(2) didn't return proper status
codes for __push_hevc_frame() when it had sent the smaller NAL units.
This caused it to send far less data than it should have
The NTP millisecond diff calculation seems to be incorrect (it gives
very weird results) but miraculously it still produced playable video
stream.
I'll need to figure out what's wrong with the calculation at some point
but for now switch to use HRC.
Aaro Altonen