Real-time Transport Control Protocol
RFC 3550 defines two interoperable protocols, the Real-time Transport Protocol (RTP) and the Real-time Transport Control Protocol (RTCP). RTCP provides feedback between peer RTP devices via status reports. Either device in the connection can send or receive reports.
The reports contain the statistics the devices maintain for timing and sequence counts. The RTP frame contains a sequence counter that is incremented for each frame sent. The device can use this counter to gather statistics as to the number of lost frames per unit of time. The other frame content is the timestamp. It is incremented to indicate the amount of media present in a frame. The timestamp can be used to gather statistics about the relative delay of the incoming packets. These statistics allow the devices to generate jitter measurements.
Although, service providers can use the reports to monitor the health of the network, the reports are typically used as a keep-alive mechanism for the devices for the RTP media stream.
Each RTCP packet can transport multiple reports. These compound reports are called stacked reports and have a recommended content of a sender report/receiver report pair and a source descriptoin (SDES) plus any of the other reports as necessary. This allows the transmission of full connection information in all stacks. The timing of the reports is a complex algorithm based on report types, bandwidth available, and the number of devices in a connection. At a minimum the reports or report stacks should be sent every five seconds.
This five second timer allows two devices to share transmission counters and timers, receiver parameters (e.g., loss and jitter), and device characteristics on a regular basis.
RTCP Reports Types
RFC 3550 defines six report types for RTCP that convey various control information between devices. The sender report (SR) is used to transmit statistics from active devices in a session. The receiver report (RR) is used to send reception (incoming) statistics from devices that are not actively transmitting RTP media. The receiver reports are also sent in combination with sender reports for devices that are actively sending reports on more than 31 sources (media players). The source description (SDES) report is generated by devices sending RTP media and includes information about the RTP session. The source BYE report indicates that a device is no longer participating in a RTP session. The final report, application-specific (APP) functions, is intended for experimental use as new applications and new features are developed, without requiring report type registration with IANA.
Receiver Report Example
An RTCP receiver report can define statistics for multiple RTP media streams. The example below reports on a single media stream. The source identifier is given to align this report to the proper media stream at the recipient. (Consider a VoIP gateway that has multiple simultaneous media streams. This ID would allow the RTP process to determine the health of any one stream.) The received sequence numbers are used to spot packet loss in the RTP stream. In this example no packets were lost to date in the sequence counters.
The report also contains the average inter-arrival jitter being calculated. In the example the jitter is 552 timestamp units. The final entries show the elapsed time from the last sender report.
Packet type: Receiver Report (201) Length: 7 Sender SSRC: 168886047 Source 1 Identifier: 297139993 SSRC contents Fraction lost: 0 / 256 Cumulative number of packets lost: 0 Extended highest sequence number received: 3966 Sequence number cycles count: 0 Highest sequence number received: 3966 Interarrival jitter: 552 Last SR timestamp: 0 Delay since last SR timestamp: 0
Sender Report Example
The sender report below shows the actual counter and timestamp counts for the transmitter at the time of the report. The receiver report (RR) gathers statistics about the media stream, and the sender report (SR) validates that the transmitter is operational in that the counters and timers are incrementing. Each SR should show an incremental increase from the last SR received. The SR contains the timestamps, sequence counters, and stream content counters for each active media stream for this device. In our example there is a single media stream.
Packet type: Sender report (200) Length: 6 Sender SSRC: 297139993 Timestamp, MSW: 3287248451 Timestamp, LSW: 2078323127 RTP timestamp: 0 Sender’s packet count: 478 Sender’s octet count: 19120
Source Description Example
The third mandatory report in an RTCP packet is the source description (SDES) report. This report contains the information related to the sending device. This information can be as simple as that shown below and include the CNAME, Name, and Tool. This allows the identification of the device sending the report, the common name (i.e., administrative name) of the device, and the manufacturers name for the device (i.e., type and model). In this example the device is a Cisco VoIP gateway at IP address 10.1.255.25. Optional information about the device includes geographic location, administrative notes and private information, phone number of the device, and email address.
Packet type: Source description (202) Length: 19 Chunk 1, SSRC/CSRC 297139993 Identifier: 297139993 SDES items Type: CNAME (user and domain) (1) Length: 17 Text: email@example.com Type: NAME (common name) (2) Length: 23 Text: Cisco IOS, VoIP gateway Type: TOOL (name/version of source app) (6) Length: 23 Text: Cisco IOS, VoIP gateway