RTP (Real-time Transport Protocol)
`RTP` is the `IETF` real-time media transport framework used to carry audio, video, and related payloads with sequence numbers, timestamps, source identifiers, and companion `RTCP` reporting. For IT/firewall purposes, the main answer is that there is no one universal "`RTP port`". `RFC 3551` defines `5004` as a default media port for the classic AV profile and the traditional adjacent RTCP convention makes `5005` common, but real AV systems usually negotiate or configure their media ranges through `SDP`, `SIP`, `RTSP`, `WebRTC`, `AES67`, `ST 2110`, or a vendor control plane.
Audio TransportOpen Standardlow latency, medium latencylocal lancampuswan internet
Infrastructure Requirements
- A complete session context, not just raw packet carriage: matching codec and payload-format support
- an agreed `RTP` profile (`RTP/AVP`, `RTP/AVPF`, `RTP/SAVP`, `RTP/SAVPF`, or another explicitly supported profile)
- session description/signalling such as `SDP` (`rtpmap`, `fmtp`, direction, transport, profile name)
- port policy
- jitter buffering
- and usually a companion control/signalling layer such as `RTSP`, `SIP`, `WebRTC`, `AES67`, `ST 2110`, or a vendor-specific control plane. If the path is multicast, it also needs correct multicast design. If the path crosses untrusted or NATed networks, it usually needs `SRTP`, `ICE` / `STUN` / `TURN`, or an `SBC` / gateway strategy. If multiple streams must line up cleanly, the wider timing design matters too
- `RTP` timestamps alone are not a whole plant-sync answer.
Network Ports & Requirements
| Port(s) | Transport | Direction | Purpose | DSCP | Multicast | Config. |
|---|---|---|---|---|---|---|
| — | UDP | Both | Real-time audio/video/metadata payload. This is the normal media path for SIP calls, RTSP streams, WebRTC media after ICE/DTLS setup, AES67/ST 2110 flows, and many vendor stacks. | — | — | No |
| — | TCP | Both | Sender/receiver reports, reception quality, synchronization data, source description, feedback, and related control/statistics. May be adjacent to the RTP port, separate, or multiplexed. | — | — | No |
| 5004 | `RTP/AVP` | Both | Default classic RTP media port from the AV profile and IANA `avt-profile-1` registration. Useful as a convention, not a universal firewall rule. | — | — | Yes |
| 5005 | TCP | Both | Traditional companion control/statistics port for the default `5004` RTP case. Do not assume it exists when `RTCP` multiplexing or another port range is negotiated. | — | — | Yes |
| — | TCP | Both | RTP and RTCP on one port to reduce NAT/firewall pinholes and simplify media path handling. Requires explicit negotiation/support; it is not safe to infer from the protocol name alone. | — | — | No |
| 5004 | TCP | Both | Compatibility/traversal mode when RTP/RTCP packets are length-framed over TCP or another connection-oriented transport. In RTSP systems this may instead be interleaved inside the RTSP control TCP connection. | — | — | Yes |
| — | TCP/Multicast | Both | One-to-many LAN/campus media distribution. Requires multicast engineering; port and group values come from SDP/session configuration, not from the bare RTP standard. | — | — | No |
Gotchas & IT Notes
- ⚠Do not open "`RTP`" by name. Schedule the actual session stack: `SIP` plus endpoint/SBC media range, `RTSP` plus negotiated UDP/interleaved mode, `WebRTC` plus `ICE` / `STUN` / `TURN` / `DTLS-SRTP`, `AES67` / `ST 2110` SDP-defined flows, or the vendor platform's documented media ports.
- ⚠Do not assume `5004/5005`. They are defaults/conventions, not proof of installed behavior. Many AV products use configurable ranges, random negotiated ports, interleaved `RTP` over TCP, `RTCP` multiplexing, or SBC/media-gateway anchored ports.
- ⚠`RTCP` is part of the design. If the vendor firewall note lists RTP but ignores RTCP, ask whether RTCP is separate, adjacent, multiplexed, blocked by policy, or hidden behind a gateway.
- ⚠Profile matters: `RTP/AVP`, `RTP/AVPF`, `RTP/SAVP`, and `RTP/SAVPF` imply different feedback and security behavior. `WebRTC` is normally `DTLS-SRTP` / `RTP/SAVPF`, not plain RTP.
- ⚠`SRTP` protects media only when keying and profiles are actually negotiated. Secure signalling such as `SIP/TLS`, `RTSPS`, or `HTTPS` does not automatically encrypt RTP payloads.
- ⚠Multicast RTP is not a firewall checkbox. It needs IGMP snooping, querier/routing decisions, multicast address scope, receiver-count/fanout sizing, uplink capacity, QoS, and packet-capture proof.
- ⚠Bare RTP is a poor WAN answer when the path is lossy, NAT-heavy, or internet-facing. For contribution over hostile networks, use a stack with explicit traversal, encryption, congestion behavior, and loss recovery rather than pretending raw RTP is enough.
- ⚠`RTP over QUIC` is currently an expired IETF Internet-Draft, not a generic installed-base AV port profile. Treat it as endpoint-specific until the selected products, signalling profile, ALPN/port behavior, firewall/proxy path, and interop matrix explicitly support it.
- ⚠Packet capture should prove six things during commissioning: source/destination/ports, payload type mapping, SSRC/CNAME continuity, RTCP behavior, loss/jitter/reorder statistics, and whether the media is clear RTP or encrypted SRTP.
- ⚠For QoS reviews, do not assume `RTP` equals priority forwarding. Verify the platform's DSCP/CoS marking, whether the switch trusts or rewrites it at the edge, and whether media, RTCP, signalling, and discovery are intentionally separated into the correct queues.