The vector was not always cleared which caused it to accumulate
old aggregation packets and when that was coupled with the WSABUF size
problem, memory errors happened.
This is a temporary fix but increasing it and making sure the
incoming vector has fewer elements at least prevents memory access
errors.
The size should grow dynamically though and not just fail. Not sure
what kind of a stream requires more than 32 WSABUFs though.
The previous assumption was that the stream utilizing holepuncher
would have already sent a datagram and would then switch just receiving
which is why the holepuncher did not send anything if the media stream
had not (yet) sent anything.
This does not, however, work for those streams that only receive packets
as they would never call push_frame() and thus never update the last_dgram_sent_
of the holepuncher, essentially making holepuncher disabled for the stream.
Save the frame info to the media object and fetch it from there
when a packet is received, update the code to better handle out-of-order
packets and add support for RCE_H26X_PREPEND_SC
Before, if RCE_FRAGMENT_GENERIC was enabled, the sender would
set marker bit to every outgoing packet which the receiver
would then interpret to be a fragment of a larger frame.
This is not correct behaviour because one can also send small packets
using the RCE_FRAGMENT_GENERIC in which case the packet is handled
normally.
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
1443 is the maximum payload size for H26X Fragmentation Units but
for generic frames there is no NAL + FU header meaning the 3 bytes
can be used for payload data
Aaro Altonen
Joni Räsänen