Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Let RTP Be Your Friend

What to know about this protocol for transport of real-time data

This is Part 4 of a series about IT fundamentals. These articles are based on excerpts from the Society of Broadcast Engineers CBNT/CBNE Study Topics webinar series, designed to assist those seeking SBE certification and to provide others a broad overview of IT as used in broadcast engineering. (The series starts here.)

The transport protocols utilized within the Internet Protocol (IP) family are the foundation of host-to-host communications in our broadcast station network. 

Most broadcast engineers are familiar with the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). 

TCP is known as a reliable transport protocol due to the acknowledgement handshake and possible packet re-transmission occurring between a send host and the receive host. UDP is commonly described as a best effort or non-guaranteed transport protocol. UDP offers the advantage of low latency as time is not taken up with any host-to-host handshake exchange or packet re-transmission.

Potentially less familiar is the Real Time Protocol. RTP is essential to the audio over IP (AoIP) systems we use today in our broadcast plant that requires low latency and minimal packet loss. Whether Dante, LiveWire, Wheatnet or whatever your favorite system may be, RTP is in use.

RTP is outlined by the Internet Engineering Task Force Request for Comment #3550 and is defined as the “common protocol for the transport of real-time data.”

RTP is actually transported by UDP by encapsulation of the real-time payload data with associated header information. The RTP Encapsulation diagram shown here illustrates the encapsulation process beginning with the RTP payload data with added RTP header through the UDP segment to an IP packet and finally to the Ethernet frame which is in turn transmitted as bits across the network.

The RTP header is relatively simple and contains several data fields describing the payload data. The header is at least 12 bytes in length, but may be longer based upon the use of optional extension header fields. 

RTP Encapsulation

Several of the header data fields are worthy of describing in greater detail including packet sequence numbering, timestamping and payload type. 

The packet sequence number is used to check for any missing packets and reorder packets that may be received out of the proper order. Packet loss is not usually found in the Local Area Network (LAN) environment, but may occur in a more complex network. If packets are missing, no correction is attempted as the UDP transport that RTP rides on does not offer any retransmission. Correction is left to a higher layer such as the AoIP application to mask or re-create the missing packet information. The packet sequence number begins with a randomly selected 16-bit number by the send host and is simply incriminated with each packet sent. The use of the initial random selected sequence number is to minimize potential cybersecurity attacks. The sequence number can be thought of as a sequential serial number for each transmitted packet.

The packet timestamp is utilized to determine jitter or the correlation of the timing of received packets by the receiving host and to synchronize companion streams such as an audio stream and associated video stream. The 32-bit timestamp indicates the sampling of the first octet of the RTP data packet. The timestamp is simply a count or a number of ticks rather than an actual clock time. 

The payload type (PT) field allocates seven bits to specify the type of data in the payload. This indicates the format of the data in the payload field or the source codec used to the receiving host. The Internet Assigned Numbers Authority (IANA) coordinates the RTP payload type registration. A unique number is used for the PT such as “4” indicating a G723 audio codec, or a “34” indicating a H.263 video codec.

[Sign Up for Radio World’s SmartBrief Newsletter]

Additional header data fields include the frame identifier or marker bit to indicate a significant event such as the start of audio or in the delivery of data packaged in logical units such as a frame in a video data stream. The contributor identifier field may be used when multiple RTP sources are available in a session. If a single source is involved, this field is set to zero (binary 0000).

Closely associated with RTP is the Real-Time Transport Control Protocol (RTCP), which works hand in hand with RTP allowing the receiving host to provide feedback information to the sending host. RTCP is described in RFC # 3550 along with RTP. RTCP does not transport any payload data and only conveys transmission performance metrics from the receiving host to the sending host. 

[Read Part 5 of this series]

The webinar on which this article is based, and many others, are available to anyone for a modest fee, with members receiving a discounted rate and free to those with the SBE MemberPlus upgrade. Consider joining if you are not a member at