This page describes the sent reports used to know how the data packets are being sent to the host (SR) and the receive reports used to get the feedback from the receiving hosts (RR).
A sent or receive report along with the name of its user on the RTCP (control) port is multi-casted periodically. This is done to have information on who is joining or leaving at any moment and how well you receive the data in a session.
The RTCP sender and receiver reports describe one timing and sequence number space for each SSRC and do not carry a payload type field.
A Sender Report has three sections:
Header
Sender information, which summarises the data transmissions from current sender.
Reception report block (zero or more), which gives the reception of RTP packets from a single synchronisation source.
RRtcpSRPart provides the information on the data transmitted from the sender as a sender report (SR).
You can access the following information from an SR packet:
NTPTimeStamp: Gets the absolute date and time when the report was sent. This is represented in timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900. This is used in combination with timestamps returned in reception reports from other receivers to measure round-trip propagation to those receivers.
RTPTimeStamp: Gets the RTP time when this packet was sent. RTP time is profile dependant.
ByteCount: Gets the number of bytes sent.
PacketCount: Gets the total number of RTP data packets transmitted by the sender from the start of the transmission until the time this SR packet was generated. You must reset the count if the sender changes its SSRC identifier.
Extension: Retrieves an extension defined for SR packets (also for RR packets) for any additional information to be reported about sender or receiver.
Note: RRtcpSRPart does not have a close function as the resources accessed through this handle are owned by object of RRtpReceiveSource.
To know how the data packets are being sent to the host, feedback is required from the receiving hosts. RRtcpRRItem supports you in getting this information as receiving reports.
RRtcpRRPart provides a list of the receipt reports (RR) from the receiving hosts reporting on the send stream. You can also create an RR object by calling RRtpSession::GetRRs().
To get a specific receive report of a host, call the index operator RRtcpRRPart::operator[]. This returns an object of RRtcpRRItem. You can get the total number of receive reports received by calling RRtcpRRPart::Count.
You can get the following information from a receiver report to assess the quality of the service:
SenderSSRC: Gets the sender’s 32-bit numeric synchronisation source identifier. The same is updated in the member table.
AboutSSRC: Gets the SSRC related to the current packet.
PacketsLost: Returns the total number of RTP packets lost from source SSRC since the beginning of the reception.
FractionLost: Returns the fraction of RTP data packets from the source SSRC lost since the previous SR or RR packet was sent. This is the integer part of the product of loss fraction and 256 (loss fraction x 256).
ExtendedHighestSequenceNumber: Gets the extended highest sequence number received in an RTP data packet from the source.
DelaySinceLastSR: Gets the time elapsed from the receipt of the last SR (Sender Report) and the time when current reception report packet was sent. The delay time is expressed in 1/65536 seconds. If no SR packet has been received yet from SSRC, the DLSR field is set to zero.
InterarrivalJitter: Gets the variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. This gives the measure of network congestion.
LastSRTimestamp: Gets NTP timestamp of the most recent RTCP sender report (SR) packet from source SSRC. If no SR has been received, the field is set to zero.
All the preceding information about the data sent to the receiving hosts is used to modify the transmission and also to determine if the problem is local, regional or global.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.