multiplex: Improve comments in reception_flow

This commit is contained in:
Heikki Tampio 2023-07-31 10:07:38 +03:00
parent 10c14b9f99
commit 16d9748260
3 changed files with 11 additions and 9 deletions

View File

@ -680,7 +680,7 @@ uvgrtp::frame::rtp_frame *uvgrtp::media_stream::pull_frame()
return nullptr;
}
// If the remote_ssrc is set, only pull frames that come from this ssrc
if (remote_ssrc_.get()->load() != 0) {
if (remote_ssrc_.get()->load() != ssrc_.get()->load() + 1) {
return reception_flow_->pull_frame(remote_ssrc_);
}
return reception_flow_->pull_frame();

View File

@ -192,7 +192,6 @@ rtp_error_t uvgrtp::reception_flow::install_receive_hook(
if (!hook)
return RTP_INVALID_VALUE;
// ssrc 0 is used when streams are not multiplexed into a single socket
receive_pkt_hook new_hook = { arg, hook };
hooks_[remote_ssrc] = new_hook;
@ -366,8 +365,8 @@ void uvgrtp::reception_flow::return_frame(uvgrtp::frame::rtp_frame *frame)
{
uint32_t ssrc = frame->header.ssrc;
// 1. Check if there exists a hook that this ssrc belongs to
// 2. If not, check if there is a "universal hook"
// 1. Check if there is only one hook installed -> no socket muxing
// 2. Multiple handlers -> check if there exists a hook that this ssrc belongs to
// 3. If neither is found, push the frame to the queue
if (hooks_.size() == 1) {
/* No socket multiplexing: All packets are given to this hook */
@ -528,14 +527,16 @@ void uvgrtp::reception_flow::process_packet(int rce_flags)
if (ring_buffer_[ring_read_index_].read > 0)
{
/* When processing a packet, the following checks are done
* 1. Check the SSRC of the packets. This field is in the same place for RTP and ZRTP, octets 8-11. For RTCP, it is
* 1. If there is only a single set of handlers installed, there is no socket multiplexing. All packets
* to to this handler
* 2. Check the SSRC of the packets. This field is in the same place for RTP and ZRTP, octets 8-11. For RTCP, it is
* in octets 4-7
* 2. If there is no SSRC match for any of the handlers, this either a holepuncher or a user packet.
* 3. SSRC match found -> Determine which protocol this packet belongs to. RTCP packets can be told apart from RTP packets via
* 3. If there is no SSRC match for any of the handlers, this either a holepuncher or a user packet.
* 4. SSRC match found -> Determine which protocol this packet belongs to. RTCP packets can be told apart from RTP packets via
* bits 8-15. ZRTP packets can be told apart from others via their 2 first bits being 0 and the Magic Cookie
* field being 0x5a525450. Holepuncher packets contain 0x00 payload. However, holepunching is
* not needed if RTCP is enabled.
* 4. After determining the correct protocol, hand out the packet to the correct handler(s) if it exists. */
* 5. After determining the correct protocol, hand out the packet to the correct handler(s) if it exists. */
uint8_t* ptr = (uint8_t*)ring_buffer_[ring_read_index_].data;
//sockaddr_in from = ring_buffer_[ring_read_index_].from;

View File

@ -75,7 +75,8 @@ namespace uvgrtp {
* When multiplexing several media streams into a single socket, SSRC is what
* separates one stream from another. You can also give each media stream pair
* their own ports, which eliminates the need for SSRC checking. In this case
* the REMOTE SSRC will be 0 and all packets are given to the single media stream.
* each reception_flow object will have just a single set of packet handlers
* and all packets are given to these.
*
* If there is no valid SSRC to be found in the received packet's header, the
* packet is assumed to be a user packet, in which case it is handed over to