Understanding Real Time Protocol (URTP)

URTP: SOLD

Natural selection is testing this #Altcoins season 🌊. In this cycle, many are once again diving deep into research, searching for “the best” after Bitcoin & @Joseinnewworld makes waves 124 #NFTs — Wow, a strong signal for those still weighing their moves. #eCash $XEC #CryptoNews pic.twitter.com/GB3dRvH01U
— NFToa (@nftoa_) September 26, 2025

1. What RTP Does

RTP is a standard for sending multimedia data in real-time such as audio and video.
Provides end-to-end delivery services for data that has real-time characteristics, such as interactive audio and video.
RTP consists of a data and control part called RTCP.
It is a protocol on the application layer.
Runs on top of UDP but can also be on top of other protocols (to optimize the use of multiplexing and checksum services built into the UDP protocol).
Provides real-time end-to-end data delivery services.
These services include payload type identification, sequence numbering, time stamping and delivery monitoring.
Supports data transfer to multiple destinations using multicast distribution, if provided by the network.
RTP has been developed with flexibility and scalability capabilities and is even used as a core real-time protocol on IP networks and hybrid MPOA (Multiprotocol Over ATM) systems.
RTP is a standard for sending multimedia data in real-time such as audio and video.
Provides end-to-end delivery services for data that has real-time characteristics, such as interactive audio and video.
RTP consists of a data and control part called RTCP.
It is a protocol on the application layer.
Runs on top of UDP but can also be on top of other protocols (to optimize the use of multiplexing and checksum services built into the UDP protocol).
Provides real-time end-to-end data delivery services.
These services include payload type identification, sequence numbering, time stamping and delivery monitoring.
Supports data transfer to multiple destinations using multicast distribution, if provided by the network.
RTP has been developed with flexibility and scalability capabilities and is even used as a core real-time protocol on IP networks and hybrid MPOA (Multiprotocol Over ATM) systems.

2. What RTP Doesn't Do

It does not provide any mechanism to ensure timely delivery or provide quality of service (reliable data delivery) guarantees, but delegates these tasks to a lower layer, namely QoS-based RSVP.
Does not guarantee Quality of Service (QoS) for real-time applications.
Does not provide a resource reservation addressing mechanism.
It is not designed to meet the needs of many participants in a multimedia conference (delivery of encryption key to participant), but also as a continuous data storage, distributed interactive simulation, and measurement and control applications.

RTP implements the transport features required to provide synchronization of multimedia data streams. Considering the application usage between video and audio components. RTP can be used to mark packets associated with individual video and audio streams. This passes the streams to be synchronized at the receiving host. Figure 2 below shows the operation of RTP in multimedia transmission. Audio and video data are encapsulated in RTP packets before they travel from the sender to the receiver.

Figure 5.17. RTP Operations on Multimedia

If a multimedia application does not use RTP, the receiver may not be able to connect to the audio and video packet conversation. Multimedia applications can connect to various levels of network views provided during a multimedia session. Congestion or other transient conditions in the environment can cause packets to be lost or reordered during transit. This can delay packet delivery by varying amounts of time. This behavior can be a quality problem with many types of multimedia applications.

Figure 5.18. RTP Application Layer

Information :

UDP does not indicate a way to detect packet loss and correct packet sequences.
RTP covers up these issues (using sequence numbers, time stamping).
RTP provides a proper mechanism by using QoS protocols.

3. RTP Header Format

Figure 5.19. RTP Header Format

The parts contained in the RTP header format include:

a. Version (V)

The 2 bit long field indicates the RTP stream. The RTP stream is 2.0 (to identify the RTP version).

b. Padding (P)

This field is 1 bit long. If P is set, the packet contains one or more additional 8-layer compositions at the end, which are not part of the payload. These layers are required by some encryption algorithms, which require block size or to carry multiple RTP packets in a lower-layer PDU. When constructed, a packet contains one or more padding (additional layers of octets at the end that are not part of the payload).

c. Extension (X)

This field is 1 bit long. If X is set, it is followed by exactly one extension header. A fixed header is usually followed by exactly one extension header, in a specified format.

d. CSRC count (CC)

This field is 4 bits long. The field indicates the number of CSRC identifiers followed by the header. This section consists of a number of CSRC identifiers that follow the fixed header.

e. Marker bit (M)

This field is 1 bit long. Markers can be interpreted as profiles. Markers are intended to provide significant events such as frame boundaries marked in the packet stream.

f. Payload type (PT)

This field is 7 bits long. This section is created so that the RTP payload format can be recognized and discovered by applications that use it. A profile defines a standard static mapping from payload code types to payload formats. Additional payload types may be dynamically defined via non-RTP definitions.

g. Sequence number

This field is 16 bits long. The sequence number is incremented by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and restore the packet sequence.

h. Time stamp

This field is 32 bits long. It represents the instantaneous sampling of the first octet in the RTP data packet. This sampling must be derived from a monotonically and linearly increasing time in order to allow synchronization and jitter calculations. The resolution of the time must be sufficient for the desired level of synchronization accuracy and for measuring packet jitter.

i. SSRC

This field is 32 bits long. It is the identifier of the synchronization source. This identifier is chosen randomly so that no two synchronization sources have the same SSRC identifier in a single RTP session.

j. CSRC list

Contributing a list of source identifiers. The CSRC is intended to identify the sources that contributed to the payload contained in the packet.

The image below explains that a film/video is a collection of several images (TV/video). Each video frame is added with a timer (1 second to 25 frames) and entered into the RTP protocol. With a sequence number of 100. The payload type is represented by JPEG. The video is broken down into JPEG image formats. The nth hour is given a timer, including in what order (sequence number) with the JPEG payload type. The payload and video frame must be synchronized and sent to UDP then to IP.

Figure 20.5. RTP Generation Packet in Video Application

5. How RTP Works

Figure 5.21. How RTP Works