RTP, or Real-time Transport Protocol, is a framework for carrying real-time audio, video and other media data across a network. It adds information that helps a receiver identify, order and time media packets, but it is not a codec, a streaming service or a complete delivery system.
A sender divides encoded media into packets and adds an RTP header to each one. The receiver reads that header, uses the relevant payload format to interpret the media, and works with the network and application around it to present the result. RTCP runs alongside RTP to provide delivery reports and participant information.
What RTP Streaming Means
People often use “RTP streaming” to describe media being transported with RTP packets. The phrase can refer to audio or video in a voice call, a WebRTC session, a production workflow or another real-time application. It does not identify one consumer service or one fixed method of delivering video to viewers.
The standard definition is deliberately broad. RFC 3550 describes RTP as providing end-to-end network transport functions for applications that transmit real-time data, including audio, video and simulation data, over multicast or unicast network services.
That wording matters because RTP sits between the media application and the network. An application produces or receives media. A codec may compress and encode that media. RTP gives the resulting pieces useful transport metadata. Other parts of the system deal with signalling, security, session control, network traversal, buffering, decoding and presentation.
A simple example is a video call. A camera produces frames, an encoder turns them into a selected video format, and the application divides the encoded result into pieces. RTP identifies the media payload and gives each packet timing and sequence information. The receiving application then uses the payload definition and those fields to decide how the pieces fit into playback.
RTP does not make an unreliable network reliable. It does not guarantee that every packet will arrive, that packets will arrive in order, that they will arrive in time, or that the finished call will have a particular quality level. Those outcomes depend on the complete system and the conditions between sender and receiver.
For an always-on YouTube channel, this distinction prevents a common mistake. RTP may be part of a contribution or communications workflow somewhere upstream, but it is not by itself the service that stores a video, keeps a broadcast running overnight, publishes it to YouTube and handles every failure around that process.
What RTP Carries
RTP carries real-time data as a payload. The payload can contain encoded audio, encoded video or another type of real-time information. RTP does not prescribe one universal audio or video format, so the receiver must know which payload format and profile apply.
The packet therefore has two broad parts:
- a header containing RTP metadata
- a payload containing a piece of the media data
The media payload is not normally a complete song, film or camera recording in one packet. It is a portion of an encoded stream, prepared according to the codec and payload-format rules being used. Packet size, framing and the way encoded data is divided depend on the application and the selected media format.
Suppose a microphone produces continuous speech. The application encodes the speech and divides the result into manageable units. Each unit is carried in an RTP packet. At the other end, the receiver examines the packet metadata, passes the payload to the appropriate decoder and schedules the decoded audio for playback.
Video follows the same broad pattern, although its payload rules can be more involved. A camera produces frames, the encoder creates a compressed video stream, and the application packetizes that stream. The receiver uses the relevant payload-format definition to understand how the packets relate to encoded video data.
RTP can also carry more than one media stream. Audio and video commonly have separate RTP streams, each with its own packet sequence and timing information. The receiver needs enough information to keep those streams aligned during playback. The exact method depends on the profile, application and media formats involved.
RTP metadata identifies the payload type being used, helps identify the source and gives the receiver sequence and timing information. That metadata is useful only when interpreted in the context of the relevant RTP profile and payload specification. A header does not tell a receiver everything it needs to decode arbitrary media.
This is why RTP should not be called a codec. A codec describes how media is encoded and decoded. RTP describes how packets carrying that media can be labelled and transported for real-time use. A codec and RTP solve different problems, even though they are normally selected together.
How an RTP Packet Is Structured
An RTP packet begins with a header and is followed by the media payload. The header contains fields that help the receiver understand the packet’s role in the stream. The most important fields for a first explanation are the payload type, sequence number, timestamp and synchronisation source identifier.
The payload type indicates how the payload should be interpreted within the applicable profile. It is not simply a full description of a codec embedded in every packet. The sender and receiver need an agreed mapping or signalling arrangement that explains which media format the value represents.
The sequence number changes as packets are sent. It gives the receiver a way to detect gaps and determine the relative order of packets. If packet 41 is followed by packet 43, the receiver can recognise that something is missing. It may also identify that packets arrived in a different order from the order in which they were sent.
The timestamp represents the sampling instant or media timing position for the payload, using the media clock associated with that stream. It is not necessarily a wall-clock time and should not be read as the time shown on a phone or computer. Its purpose is to help the receiver place media correctly in playback.
The synchronisation source, commonly called the SSRC, identifies the source of a stream within an RTP session. This helps the receiver distinguish packets belonging to different sources or streams. RTP also supports other header fields and extensions, but their use depends on the profile and application.
A useful mental model is a set of labelled envelopes. The media is inside each envelope. The labels do not repair a damaged road or guarantee that every envelope arrives, but they give the recipient information about what is inside, which source sent it, where it belongs in the sequence and when its contents should be played.
The packet structure also explains why RTP is not a complete streaming service. RTP does not automatically provide a media library, viewer access, channel publishing, account management or a policy decision from a platform. It supplies transport-oriented information for a real-time media exchange, while the surrounding system supplies the rest.
Sequence Numbers and Timestamps
Sequence numbers and timestamps answer different questions.
The sequence number answers, “Which packet is this relative to the other packets from this source?” It helps a receiver notice loss and deal with packets that arrive out of order. The timestamp answers, “Where does this payload belong on the media timeline?” It helps the receiver schedule playback and understand the timing relationship between media units.
Imagine that packets are sent in the order 100, 101, 102 and 103, but the network delivers 100, 102, 101 and 103. Sequence numbers reveal the arrival order and allow the receiver to recognise that 101 arrived late. The receiver can then apply the buffering and reordering policy chosen by the application.
If packet 102 never arrives, the sequence number can reveal a gap. It cannot recreate the missing media. The application may wait briefly, continue without it, use concealment, request another form of recovery or take some other action. RTP itself does not dictate one answer for every situation.
Timestamps are important when the network delivery rhythm differs from the original media rhythm. Packets may arrive with uneven spacing even though the sender produced media at a steady rate. The receiver can use timestamps, together with its buffering and playback logic, to avoid treating every network delay as a change in the source’s intended timing.
Separate audio and video streams also need a way to maintain their relationship. Their timestamps use media clocks, and the wider RTP and RTCP arrangements provide information that can help an application correlate streams. Synchronisation is therefore a system task supported by RTP metadata, not a promise that RTP alone will always keep every stream perfectly aligned.
The practical limit is worth keeping in view. Sequence numbers and timestamps describe what happened to the packets and where the media belongs. They do not reserve bandwidth, remove congestion, guarantee low latency or ensure quality of service. If the network loses packets or delivers them too late, the application still has to decide how to respond.
What RTCP Adds
RTCP is RTP’s companion control protocol. It travels alongside RTP and provides control information rather than carrying the main audio or video payload. Its role includes reporting on delivery and identifying participants in the RTP session.
A receiver can report information such as observed packet loss, timing variation and other reception conditions through the applicable RTCP reports. A sender or application can use those reports as input when deciding how to adapt. The precise reports and feedback available depend on the profile, extensions and application.
This gives RTP systems a way to observe the media exchange instead of treating packets as isolated objects. If a receiver reports worsening conditions, the wider application may adjust its media behaviour, change a sending mode or make another decision. RTCP supplies information; it does not guarantee that a particular adaptation will occur or that quality will improve.
RTCP can also provide participant and source information. In a multi-party call, that helps systems understand which sources are present and how they relate to the media streams. Again, this is control and monitoring information, not the audio or video itself.
It is helpful to keep the division clear:
| Part | Main role | What it does not do on its own |
|---|---|---|
| RTP | Carries real-time media payloads with packet metadata | Guarantee delivery, ordering, timing or quality |
| RTCP | Reports on delivery and provides control and participant information | Carry the main media payload or fix network problems automatically |
| Codec | Encodes and decodes audio or video | Transport packets or monitor the network |
| Wider application | Handles signalling, playback, adaptation and other behaviour | Reduce the whole system to RTP alone |
The RTP standard and RTCP specification define the relationship in more detail. Reading RTCP as a monitoring companion rather than a second media stream makes it easier to understand why a system can have packet reports without those reports guaranteeing a successful broadcast.
RTP, Codecs and the Underlying Transport
RTP is independent of the codec used for the media. A system might choose one audio format and one video format, then use the corresponding RTP payload definitions to carry them. Another system can choose different formats while keeping the same general RTP transport model.
The codec affects how media is represented, compressed and decoded. It can affect the amount of data that needs to travel and the processing required at each end. RTP does not make that choice for the application. The payload type and related signalling help the receiver select the right interpretation, but the codec rules remain separate.
RTP is also not the same thing as a network transport such as UDP. UDP is common for RTP because real-time applications often prefer to avoid the waiting behaviour associated with retransmitting every missing packet. However, RTP is designed to be independent of the underlying transport and network layers. It is not defined as UDP-only.
Choosing a transport involves trade-offs. A real-time application may value timely arrival more than perfect recovery of every old packet. Another application may add retransmission, forward error correction, encryption or other mechanisms. Those choices belong to the wider profile and system, not to the basic existence of an RTP header.
RTP also does not replace signalling. Before a call or media session can work, the participants may need to agree on addresses, media formats, keys, policies and other session details. RTP then carries packets within that established context.
WebRTC shows the layered nature clearly. RFC 8834 specifies RTP as the media transport protocol required for WebRTC and also requires RTCP. WebRTC adds profiles and related mechanisms, including security and feedback provisions. RFC 8835 covers WebRTC transport protocols and their interaction with network intermediaries.
So WebRTC is not simply another name for RTP. RTP is a required media layer within WebRTC, while WebRTC also includes signalling arrangements, security expectations, transport behaviour and methods for dealing with devices such as firewalls, relays and network address translators.
Where RTP Appears in Real-Time Media
RTP appears where an application needs to move media while the media is being produced or consumed. Voice calls, video conferences, live contribution links, interactive broadcasts and WebRTC sessions are common examples. The exact profile, payload formats, security measures and network behaviour vary between systems.
In a video call, RTP may carry the camera and microphone streams between participants. RTCP can provide reports that help the application understand reception conditions. Signalling establishes the session, security protects the exchange, and the application decides how to display or adapt the media.
In WebRTC, a browser-based meeting or support tool may use RTP for its media transport even though the user never sees an RTP setting. The browser and service manage the surrounding pieces. This is why changing a camera or microphone option is not the same as configuring an RTP streaming service.
RTP can also appear in production and contribution workflows. A camera feed might be sent from one part of a workflow to another before a platform receives, processes or distributes the final programme. Whether that is suitable depends on the equipment, network, payload formats, security requirements and receiving system.
For a small 24/7 YouTube channel, the useful question is usually not “Should I use RTP?” in isolation. Ask which part of the workflow needs real-time transport, who receives the feed, which formats are accepted, how failures are detected and what keeps the channel running when the local computer or connection stops.
If you are building from a computer, the choice may involve a playlist application, an encoder and a stable connection. A 24/7 YouTube stream using a Raspberry Pi has a different operational profile from a cloud-based workflow. Neither approach is defined by RTP alone.
For a music or ambience channel, the file and playback loop may matter more than learning packet headers. A guide to making a YouTube music radio stream with a playlist file deals with that publishing problem directly. If the concern is a long-running playback fault, the practical symptoms may be drifting audio, a stopped encoder or a disconnected broadcast rather than an RTP-specific error.
An always-on channel also has platform tasks outside media transport. You still need to configure the YouTube live event, protect the stream key, check the content rights and monitor the broadcast. If YouTube blocks a stream, consult the current platform guidance and use the copyright troubleshooting steps for a 24/7 live stream, rather than assuming a transport protocol can resolve the issue.
RTP becomes relevant when a tool, encoder or receiving service explicitly asks for it. In that case, confirm the required codec, payload format, transport, security method, address and monitoring expectations from the receiving system’s documentation. Do not infer those settings from the word RTP alone.
When the practical problem is keeping an uploaded video running on YouTube while your own computer is switched off, StreamNeo removes the need to leave that computer responsible for the continuous broadcast: you upload the file, provide the YouTube stream key and let the channel run from the service, with monitoring and automatic restart if the broadcast drops. That is a complete publishing workflow around the video, not a claim that RTP itself provides those functions.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What does RTP stand for?
RTP stands for Real-time Transport Protocol. It carries real-time data such as audio and video with metadata for payload identification, sequencing and timing. It does not define every codec or provide a complete streaming service.
Is RTP a codec?
No. A codec encodes and decodes the media, while RTP carries packets containing the encoded media and transport metadata. The sender and receiver must agree on the codec and the relevant RTP payload format.
What is the difference between RTP and RTCP?
RTP carries the main real-time media payload. RTCP runs alongside it to provide delivery reports, participant information and other control functions. RTCP can help an application observe conditions, but it does not guarantee delivery or repair every network problem.
Does RTP guarantee packet delivery or low latency?
No. RTP provides sequence numbers and timestamps that help the receiver identify gaps, handle ordering and schedule media. It does not guarantee that packets arrive, arrive in order, arrive on time or meet a particular quality level.