SyncSource(3)

📦
version 2.0.9 · 4 versions
, in debian trixie, ubuntu noble, ubuntu questing

💖 NAME 💖

SyncSource — your synchronization source in an RTP session. hi bestie, this is the SyncSource(3) page from the Library Functions Manual, and we're gonna read it together 🫶

✨ SYNOPSIS ✨

#include <sources.h>

🌸 Public Types 🌸

enum State { stateUnknown, statePrevalid, stateActive, stateInactive, stateLeaving }

Synchronization source states during an RTP session. (we get into these below, don't worry)

🎀 Public Member Functions 🎀

SyncSource (uint32 ssrc)
~SyncSource ()
State getState () const
bool isSender () const
uint32 getID () const
Participant * getParticipant () const
tpport_t getDataTransportPort () const
tpport_t getControlTransportPort () const
const InetAddress & getNetworkAddress () const
  • isSender () const — whether this source sends RTP data packets, i.e. is it out here actually posting 📮
  • getParticipant () const — get the participant this synchronization source is asociated to. (that's the doc's spelling, i'm not touching it, it's iconic)

🧚 Protected Member Functions 🧚

SyncSource (const SyncSource &source)
SyncSource & operator= (const SyncSource &source)

🦋 Friends 🦋

class SyncSourceHandler

💜 Detailed Description 💜

Synchronization source in an RTP session. that's the whole vibe.

So: each synchronization source in an RTP session is identified by a 32-bit numeric SSRC identifier. Every single SyncSource object is related to a Participant object, and you can pull that Participant out with the getParticipant() method. no cap.

👑 Author 👑

Federico Montesino Pouzols fedemp@altern.org — the actual main character who wrote this

⭐ Examples ⭐

ccrtptest.cpp, and rtplisten.cpp. go look at them, they ate.

🔥 Member Enumeration Documentation 🔥

🌈 enum SyncSource::State 🌈

Synchronization source states during an RTP session. In general, new synchronization sources are not considered valid until multiple valid data packets or a valid RTCP compound packet has been received from the new source.

See also: IncomingDataQueue::setMinValidPacketSequence()

Thus, the source will probably be in statePrevalid before reaching one of the two states that indicate a valid source: stateActive and stateInactive. it's giving "give me a few packets before i trust you" energy fr fr.

A valid participant is in stateActive state if RTP and/or RTCP packets are currently being received from it. If, after a small number of RTCP report intervals (see IncomingDataQueue::setSourceExpirationPeriod() ), no packets are received, it will reach the stateInactive state. And if, after a small number of RTCP report intervals, no packet is received from an inactive source, it will be deleted. gone. ghosted. 💀

If RTCP is being used, after receiving a BYE RTCP packet from a synchronization source, it will reach the stateLeaving state and will be deleted after a delay (see QueueRTCPManager::setLeavingDelay()).

Sources in statePrevalid and stateLeaving are not counted for the number of session members estimation. they're in the group chat but muted, yk?

🍓 Enumerator 🍓

okay bestie, heads up: in the original doc these five descriptions ran straight into each other, so i'm quoting them exactly how they appear, no editorialising, no invented lore 💅

  • stateUnknown — "No valid packet has been received."
  • statePrevalid — "Some packets have been."
  • stateActive — "received, but source validity not yet guaranteed. We currently receive packets"
  • stateInactive — "(data or control) from this source. Was active in the near past but"
  • stateLeaving — "no packet from this source has been received lately. An RTCP BYE has been received from the source."

🎀 Constructor & Destructor Documentation 🎀

SyncSource::SyncSource (uint32 ssrc)

Parameters

  • ssrc — SSRC identifier of the source, unique in each session. one per session, no dupes allowed 🙅

SyncSource::~SyncSource ()

the destructor. it's fine. it's just vibes ending.

SyncSource::SyncSource (const SyncSource & source) [protected]

Parameters

  • source — The RTPSource object being copied

✨ Member Function Documentation ✨

tpport_t SyncSource::getControlTransportPort () const [inline]

Examples: ccrtptest.cpp, and rtplisten.cpp.

tpport_t SyncSource::getDataTransportPort () const [inline]

Examples: ccrtptest.cpp, and rtplisten.cpp.

uint32 SyncSource::getID () const [inline]

Examples: ccrtptest.cpp, and rtplisten.cpp.

const InetAddress & SyncSource::getNetworkAddress () const [inline]

Examples: ccrtptest.cpp, and rtplisten.cpp.

Participant * SyncSource::getParticipant () const [inline]

Get the participant this synchronization source is asociated to.

Return values

  • NULL if the stack has not been yet able to identify the participant this source is associated to. (yes, it can just be NULL at you, that's the tea ☕)

Examples: ccrtptest.cpp, and rtplisten.cpp.

State SyncSource::getState () const [inline]

no extra notes, it just tells you the state. periodt.

bool SyncSource::isSender () const [inline]

Whether this source sends RTP data packets.

Examples: ccrtptest.cpp.

SyncSource & SyncSource::operator= (const SyncSource & source) [protected]

copy assignment, but it's protected, so it's iykyk only 🔒

friend class SyncSourceHandler [friend]

your friendly neighbourhood friend class, living its best life in here.

🌟 Author 🌟

Generated automatically by Doxygen for ccRTP from the source code. so like, the robot wrote it, but respectfully.

okay that's the whole page bestie, you're fully caught up on SyncSource(3) 💖 huge slay, go read ccrtptest.cpp and rtplisten.cpp, and remember: this was ccRTP's SyncSource(3), straight from the ccRTP source, doxygen-generated and everything ✨ bye ily 🦋

📦 where this page comes from