.TH "RTPDataQueue" 3 "Mon Aug 31 2015" "ccRTP" \" -*- nroff -*- .ad l .nh .SH NAME RTPDataQueue \- A packet queue handler for building different kinds of RTP protocol systems\&. .SH SYNOPSIS .br .PP .PP \fC#include \fP .PP Inherits \fBIncomingDataQueue\fP, and \fBOutgoingDataQueue\fP\&. .PP Inherited by \fBQueueRTCPManager\fP, and \fBRTPDuplex\fP\&. .SS "Public Types" .in +1c .ti -1c .RI "enum \fBTos\fP { \fBtosBestEffort\fP, \fBtosEnhanced\fP }" .br .RI "\fI\fBrtp\&.h\fP cc++/rtp\&.h \fP" .in -1c .SS "Public Member Functions" .in +1c .ti -1c .RI "void \fBsetTypeOfService\fP (\fBTos\fP tos)" .br .RI "\fISpecify the kind of service the application expects to use\&. \fP" .ti -1c .RI "void \fBenableStack\fP ()" .br .RI "\fIEnable packet queue processing in the stack\&. \fP" .ti -1c .RI "void \fBdisableStack\fP ()" .br .RI "\fIDisable packet queue processing in the stack\&. \fP" .ti -1c .RI "bool \fBisActive\fP () const " .br .RI "\fIGet active connection state flag\&. \fP" .ti -1c .RI "uint32 \fBgetCurrentTimestamp\fP () const " .br .RI "\fIGet the timestamp that should be given for a packet whose payload sampling instant corresponds to the current system time\&. \fP" .ti -1c .RI "void \fBsetSessionBandwidth\fP (uint32 bw)" .br .RI "\fISpecify the bandwidth of the current session\&. \fP" .ti -1c .RI "uint32 \fBgetDefaultSessionBandwidth\fP () const " .br .ti -1c .RI "uint32 \fBgetSessionBandwidth\fP () const " .br .ti -1c .RI "void \fBsetTimeclock\fP ()" .br .RI "\fISet the packet timeclock for synchronizing timestamps\&. \fP" .ti -1c .RI "timeout_t \fBgetTimeclock\fP () const " .br .RI "\fIGet the packet timeclock for synchronizing timestamps\&. \fP" .in -1c .SS "Protected Member Functions" .in +1c .ti -1c .RI "\fBRTPDataQueue\fP (uint32 size=\fBdefaultMembersHashSize\fP)" .br .RI "\fIConstructor\&. \fP" .ti -1c .RI "\fBRTPDataQueue\fP (uint32 *ssrc, uint32 size=\fBdefaultMembersHashSize\fP)" .br .RI "\fIUsing this constructor you can start a session with the given ssrc, instead of the usual randomly generated one\&. \fP" .ti -1c .RI "virtual \fB~RTPDataQueue\fP ()" .br .RI "\fIThe queue destructor flushes the queue and stops all services\&. \fP" .ti -1c .RI "virtual void \fBtimerTick\fP ()" .br .RI "\fIA plugin point for timer tick driven events\&. \fP" .ti -1c .RI "void \fBrenewLocalSSRC\fP ()" .br .ti -1c .RI "void \fBendQueue\fP ()" .br .RI "\fIThis method ends the queue\&. \fP" .ti -1c .RI "virtual bool \fBisPendingData\fP (\fBmicrotimeout_t\fP timeout)=0" .br .RI "\fIThis function is used to check for and schedule against arriving packets based on the derived connection type\&. \fP" .in -1c .SS "Additional Inherited Members" .SH "Detailed Description" .PP A packet queue handler for building different kinds of RTP protocol systems\&. The queue manages both incoming and outgoing RTP packets, as well as synchronization and transmission/reception timers\&. By making the queue handler a seperate base class it becomes possible to define RTP classes for RTP profiles and sessions of different types\&. .PP Outgoing packets are sent via the \fBOutgoingDataQueue::putData\fP method\&. .PP Incoming packets can be retrieved via \fBIncomingDataQueue::getData\fP method\&. .PP \fBAuthor:\fP .RS 4 David Sugar dyfet@ostel.com RTP data queue handler\&. .RE .PP .SH "Constructor & Destructor Documentation" .PP .SS "RTPDataQueue::RTPDataQueue (uint32 size = \fC\fBdefaultMembersHashSize\fP\fP)\fC [protected]\fP" .PP Constructor\&. This will generate a random application SSRC identifier\&. .PP \fBParameters:\fP .RS 4 \fIsize\fP an estimation of the number of participants in the session .RE .PP .SS "RTPDataQueue::RTPDataQueue (uint32 * ssrc, uint32 size = \fC\fBdefaultMembersHashSize\fP\fP)\fC [protected]\fP" .PP Using this constructor you can start a session with the given ssrc, instead of the usual randomly generated one\&. This is necessary when you need to initiate several sessions having the same SSRC identifier, for instance, to implement layered encoding, in which case each layer is managed through a different session but all sessions share the same SSRC identifier\&. .PP \fBWarning:\fP .RS 4 This doesn't seem to be a good solution .RE .PP \fBParameters:\fP .RS 4 \fIssrc\fP Synchronization SouRCe identifier for this session .br \fIsize\fP an estimation of the number of participants in the session .RE .PP .SS "virtual RTPDataQueue::~RTPDataQueue ()\fC [inline]\fP, \fC [protected]\fP, \fC [virtual]\fP" .PP The queue destructor flushes the queue and stops all services\&. .SH "Member Function Documentation" .PP .SS "void RTPDataQueue::disableStack ()\fC [inline]\fP" .PP Disable packet queue processing in the stack\&. .SS "void RTPDataQueue::enableStack ()\fC [inline]\fP" .PP Enable packet queue processing in the stack\&. This method will not any thread of execution\&. .SS "void RTPDataQueue::endQueue ()\fC [protected]\fP" .PP This method ends the queue\&. .SS "uint32 RTPDataQueue::getCurrentTimestamp () const" .PP Get the timestamp that should be given for a packet whose payload sampling instant corresponds to the current system time\&. The timestamp applications should provide for each packet represents the sampling instant of its payload and should not be a reading of the system clock\&. Nevertheless, the internal operation of the RTP stack relies on the accuracy of the provided timestamp, since several computations assume that there is a certain degree of correspondence between the timestamp and the system clock\&. .PP It is recommended that applications use this method in order to \fIperiodically adjust the RTP timestamp\fP\&. .PP In particular, it is advisable getting the timestamp corresponding to the first sampling instant or any instant after a period of inactivity through a call to this method\&. .PP Applications should use the nominal sampling or any other value provided by the coder in order to compute the next timestamps with minimum computational requirement\&. .PP For instance, an application using an RTP profile that specifies a fixed sampling rate of 8 Khz with eight bits per sample, continuously transmitting audio blocks 80 octets long, would transmit 100 packets every second\&. Every packet would carry a timestamp 80 units greater than the previous one\&. So, the first timestamp would be obtained from this method, whereas the following ones would be computed adding 80 every time\&. Also the timestamp should be increased for every block whether it is put in the queue or dropped\&. .PP The aforementioned increment can be obtained from the RTPDataQueue::getTimestampIncrement() method rather than computing it by hand in the application\&. .PP \fBNote:\fP .RS 4 Frame based applications must follow a specific timestamping method, probably specified in a profile\&. .PP You should take into account that by default ccRTP assumes that the application begins sampling at the queue creation time\&. Moreover, the first sampling instant is assigned a 'user visible' timestamp of 0, although the RTP stack will then add internally a ramdom offset unknown to the application\&. That is to say, the application may count samples from 0 in order to get the timestamp for the next packet, provided that the first sampling instant is the same as the queue creation time\&. Nevertheless, this simpler way of starting will not be as accurate as it would be if the application got at least the first timestamp through getCurrentTimestamp\&. \fIWe provide this option since ccRTP interface is evolving, but we admit that it is ugly, we could remove this option or even replace uint32 timestamps with a restrictively regulated object; suggestions are gladly welcomed\fP .RE .PP .SS "uint32 RTPDataQueue::getDefaultSessionBandwidth () const\fC [inline]\fP" .SS "uint32 RTPDataQueue::getSessionBandwidth () const\fC [inline]\fP" .SS "timeout_t RTPDataQueue::getTimeclock () const\fC [inline]\fP" .PP Get the packet timeclock for synchronizing timestamps\&. .PP \fBReturns:\fP .RS 4 runtime in milliseconds since last set\&. .RE .PP .SS "bool RTPDataQueue::isActive () const\fC [inline]\fP" .PP Get active connection state flag\&. .PP \fBReturns:\fP .RS 4 true if connection 'active'\&. .RE .PP .SS "virtual bool RTPDataQueue::isPendingData (\fBmicrotimeout_t\fP timeout)\fC [protected]\fP, \fC [pure virtual]\fP" .PP This function is used to check for and schedule against arriving packets based on the derived connection type\&. .PP \fBReturns:\fP .RS 4 true if packet waiting for processing\&. .RE .PP \fBParameters:\fP .RS 4 \fInumber\fP of microseconds to wait\&. .RE .PP .PP Implemented in \fBRTPDuplex\fP\&. .SS "void RTPDataQueue::renewLocalSSRC ()\fC [inline]\fP, \fC [protected]\fP, \fC [virtual]\fP" .PP Reimplemented from \fBRTPQueueBase\fP\&. .SS "void RTPDataQueue::setSessionBandwidth (uint32 bw)\fC [inline]\fP" .PP Specify the bandwidth of the current session\&. .PP \fBParameters:\fP .RS 4 \fIbw\fP bandwidth of the current session, in bits/s\&. .RE .PP \fBSee also:\fP .RS 4 \fBAVPQueue::setControlBandwidth()\fP .RE .PP .SS "void RTPDataQueue::setTimeclock ()\fC [inline]\fP" .PP Set the packet timeclock for synchronizing timestamps\&. .SS "void RTPDataQueue::setTypeOfService (\fBTos\fP tos)\fC [inline]\fP" .PP Specify the kind of service the application expects to use\&. .PP \fBParameters:\fP .RS 4 \fItos\fP type of service the application expects to use .RE .PP \fBNote:\fP .RS 4 If enhanced service is specified but packet loss is high (the requested service does not appear to actually be delivered) ccRTP defaults to best-effort suitable behaviour: guarantee fair competition with TCP\&. .RE .PP .SS "virtual void RTPDataQueue::timerTick ()\fC [inline]\fP, \fC [protected]\fP, \fC [virtual]\fP" .PP A plugin point for timer tick driven events\&. .SH "Author" .PP Generated automatically by Doxygen for ccRTP from the source code\&.