RFC 5762
RTP and the Datagram Congestion Control Protocol (DCCP)
RFC 5762: RTP and the Datagram Congestion Control Protocol (DCCP) 🦋
- RFC number: 5762
- Title: RTP and the Datagram Congestion Control Protocol (DCCP) 🎀
- Author: C. Perkins, University of Glasgow
- Category: Standards Track (this is an Internet Standards Track document, so it's the real deal 👑)
- Date: April 2010
- ISSN: 2070-1721
- Obsoletes / Updates: the header doesn't list any RFCs it obsoletes or updates 🌸
Abstract ✨
okay so RTP is the super popular transport for real-time multimedia on IP networks, and DCCP is a transport protocol with some really desirable perks for real-time apps 💖. This memo is the one that says how to map RTP onto DCCP, plus the signalling that goes with it, so real-time apps can actually use what DCCP offers 🫶.
Status of This Memo ✨
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5762.
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents 📚
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Conventions Used in This Memo ...................................4
4. RTP over DCCP: Framing ..........................................4
4.1. RTP Data Packets ...........................................4
4.2. RTP Control Packets ........................................5
4.3. Multiplexing Data and Control ..............................7
4.4. RTP Sessions and DCCP Connections ..........................7
4.5. RTP Profiles ...............................................8
5. RTP over DCCP: Signalling using SDP .............................8
5.1. Protocol Identification ....................................8
5.2. Service Codes .............................................10
5.3. Connection Management .....................................11
5.4. Multiplexing Data and Control .............................11
5.5. Example ...................................................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................151. Introduction 🧚
okay so RTP [1] is everywhere in video streaming, telephony, and basically every other real-time networked app you can think of 📞🎥. It can run over a bunch of different lower-layer transport protocols, and how well an RTP app performs depends a LOT on which one you pick 😤. DCCP [2] is a transport protocol with properties that real-time apps are obsessed with, and it's built for unmanaged best-effort IP networks 🌐. This memo explains how to frame RTP for transport over DCCP, talks through some of the implications of doing that, and shows how SDP [3] can be used to signal these sessions 💅.
Here's the roadmap. Section 2 is the rationale, so you get why an RTP-to-DCCP mapping is needed at all 🎀. Section 3 covers the conventions used in the memo. Section 4 is where the actual spec starts, with how RTP packets get framed inside DCCP 🍓. Section 5 is the associated signalling. Section 6 is security considerations, and Section 7 is IANA considerations 🔐.
2. Rationale 💭
As RTP got really popular, people started getting worried that a lot of real-time apps don't implement congestion control 😬. That could lead to congestion collapse of the network, which is a whole disaster [15]. The RTP designers saw this coming and said so in RFC 3551 [4]:
If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
The goal is clear, but building TCP-friendly congestion control that works with RTP and real-time media is still an open research question 🔬. There are tons of proposals for new algorithms, but not a lot of real deployment experience yet, ngl 🙈.
There are two approaches for getting congestion control with RTP 🔁. The first is to develop RTP extensions that build congestion control in. An example is [16], which extends RTP with feedback info so TCP Friendly Rate Control (TFRC) [17] can run at the application level 🧩. The upside is you can add congestion control to existing apps without any OS or network support, and you get the flexibility to test new algorithms as they come out ✨. The downside is that the complexity of implementing congestion control lands on the application authors, and most of them would rather not deal with that 😭.
The second approach is to run RTP over a lower-layer transport protocol that already does congestion control 🚀. One option is running RTP over TCP, as defined in [5]. But TCP is reliable and its congestion control dynamics make it a bad fit for most interactive real-time apps, and SCTP is also a bad fit for similar reasons 🙅♀️. A better match is running RTP over DCCP, since DCCP gives you unreliable packet delivery plus a choice of congestion control 💖. That means apps can tailor the transport to what they need, get better congestion control algorithms as they become available, and still hand the implementation complexity off to the operating system 👑. The belief is that if DCCP becomes widely available, these will be seriously compelling advantages 🌟. So this memo defines a mapping of RTP onto DCCP 🎀.
3. Conventions Used in This Memo 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6].
4. RTP over DCCP: Framing 🧵
This section defines how RTP and RTP Control Protocol (RTCP) packets can be framed for transport using DCCP 🎀. It also explains how RTP sessions and DCCP connections are different, and what that difference means for how apps get designed 🫶.
4.1. RTP Data Packets 💌
Each RTP data packet MUST be conveyed in a single DCCP datagram. Fields in the RTP header MUST be interpreted according to the RTP specification, and any applicable RTP Profile and Payload Format. Header processing is not affected by DCCP framing. Note especially that the semantics of the RTP sequence number and the DCCP sequence number are not compatible, and you can't infer the value of one from the other 🙅♀️. Keep those two sequence numbers separate in your head, bestie 🧠.
A DCCP connection is opened when an end system joins an RTP session, and it stays open for the whole duration of the session 🔓. To keep NAT bindings open, an end system SHOULD send a zero-length DCCP-Data packet once every 15 seconds during periods when it has no other data to send 🕰️. This gets rid of the need for RTP no-op packets [18] and similar application-level keepalives when you're using RTP over DCCP, which is so iconic 🙌. This application-level keepalive does not need to be sent if it's known that the DCCP CCID in use provides a transport-level keepalive, or if the application can determine that there are no NAT devices on the path 🧐.
RTP data packets MUST obey the dictates of DCCP congestion control 🚦. Sometimes the congestion control will require a sender to send at a rate below what the payload format would normally use. To support this, an application could use either a rate-adaptive payload format, or a range of payload formats so it can switch to a lower rate format when it needs to 🔄. Details of the rate adaptation policy for particular payload formats are outside the scope of this memo, but see [19] and [20] for guidance 📚.
RTP extensions that provide application-level congestion control (e.g., [16]) will conflict with DCCP congestion control, and MUST NOT be used. Literally do not use these together, it's a clash 💀.
DCCP lets an application choose its checksum coverage, using a partial checksum so the app can receive packets with corrupt payloads 🧩. Some RTP Payload Formats (e.g., [21]) can use this feature together with payload-specific mechanisms to improve performance in environments with frequent non-congestive packet corruption 🌸. If such a payload format is used, an RTP end system MAY enable partial checksums at the DCCP layer. In that case, the checksum MUST cover at least the DCCP and RTP headers so packets are correctly delivered 🔍. Partial checksums MUST NOT be used unless they're supported by mechanisms in the RTP payload format. No exceptions, no vibes-based checksums 🙅♀️💅.
(part 2 coming soon, stay tuned 🧚✨)
4.2. RTP Control Packets 🎀
RTCP (the RTP Control Protocol) works with DCCP in the usual way 💖. RTCP packets get bundled into compound packets, as described in Section 6.1 of [1], and each compound RTCP packet rides in one DCCP datagram 📦.
The normal RTCP timing rules still apply, with one extra catch: RTCP packets MUST obey the DCCP congestion control algorithm negotiated for the connection 🚦. So if there isn't enough network capacity, a participant might not be able to send an RTCP packet right when its transmission timer expires 😭. In that case the packet gets delayed and goes out at the earliest possible moment once capacity opens up. The time it actually got sent is then used as the starting point for working out the next RTCP transmission time ⏰.
RTCP is only a tiny slice of all the traffic in an RTP session 🤏. So delays from congestion control shouldn't be super common, as long as the configured nominal "session bandwidth" (see Section 6.2 of [1]) matches what the DCCP connection can actually handle 🌸. But if the DCCP connection's capacity is way below the nominal session bandwidth, RTCP packets could get delayed long enough that participants time out thinking nobody's there 💀. When that happens, the session parameters SHOULD be renegotiated to better fit the capacity available. For example, you can do a re-invite with an updated "b=" line when you're using the Session Initiation Protocol [22] for signalling 🧚.
Note: Since the nominal session bandwidth is chosen based on media codec capabilities, a session where the nominal bandwidth is much larger than the available bandwidth will likely become unusable due to constraints on the media channel, and so require negotiation of a lower bandwidth codec, before it becomes unusable due to constraints on the RTCP channel. 🙈
As noted in Section 17.1 of [2], RTCP packets and DCCP acknowledgement options could overlap in what information they carry 👀. Usually that's not a big deal, because RTCP packets hold media-specific data that DCCP acknowledgement options don't have, and DCCP options hold network-level data that RTCP doesn't have 🫶. In fact, there's no overlap between the five RTCP packet types defined in the RTP specification [1] and the standard DCCP options [2] ✨. BUT there are cases where it does happen, most clearly between the Loss RLE Report Blocks defined as part of the RTCP Extended Reports [23] and the DCCP Ack Vector option 😱. If RTCP report packets and DCCP acknowledgements overlap, an application SHOULD use either RTCP feedback or DCCP acknowledgements, but not both. Using both just wastes available network capacity, though it isn't otherwise harmful 🫠.
4.3. Multiplexing Data and Control 🧩
The obvious way to map RTP onto DCCP makes two DCCP connections for every RTP flow: one for RTP data packets and one for RTP control packets 👯. People love to complain about how many ports RTP eats up 🙄. Big telephony gateways can handle more than 32768 RTP flows between the same pair of gateways, which means they can run out of UDP ports 😩. Using multiple ports also makes NAT traversal more complicated 🌀. So for all these reasons, it is RECOMMENDED that the RTP and RTCP traffic for a single RTP session gets multiplexed onto one DCCP connection, following the guidelines in [7], where possible 💜. It might not be possible in every situation, though. For example, when translating from an RTP stream over a non-DCCP transport that uses conflicting RTP payload types and RTCP packet types, you might be stuck 🥲.
4.4. RTP Sessions and DCCP Connections 🌐
An end system SHOULD NOT assume that it will only see a single RTP synchronisation source (SSRC) just because it's using DCCP framing 🙅♀️. An RTP session can stretch across any number of transport connections, and it can include RTP mixers or translators that bring other participants into the session 🎉. Using a unicast DCCP connection doesn't mean the session only has two people in it. RTP end systems SHOULD assume that they might see multiple synchronisation sources when using RTP over DCCP, unless something signals otherwise 👑.
An RTP translator that bridges multiple DCCP connections into one RTP session needs to be aware of the congestion state of each DCCP connection, and must adapt the media to the available capacity of each 🧠. The Codec Control Messages defined in [24] can be used to signal congestion state to the media senders, so they can adapt how much they send 📡. Another option is media transcoding, which can do the adaptation too 🔄. But that's computationally expensive, adds delay, and usually gives poor-quality results 😬. Depending on the payload, it might also be possible to use some form of scalable coding 🦋.
A single RTP session can also span a DCCP connection and some other type of transport connection 🌈. One example: an RTP over DCCP connection from an RTP end system to an RTP translator, with an RTP over UDP/IP multicast group on the other side of the translator 💫. Another example: an RTP over DCCP connection that links Public Switched Telephone Network (PSTN) gateways 📞. The issues for a translator like that are similar to the ones for linking two DCCP connections, except the congestion control algorithms on each side of the translator might not be compatible 😵. Building effective translators for this kind of environment is non-trivial 🛠️.
4.5. RTP Profiles 📋
Generally, new RTP profiles don't clash with DCCP framing, and most RTP profiles can be negotiated for use over DCCP ✅. The exceptions are:
- An RTP profile that is intolerant of packet corruption may conflict with the DCCP partial checksum feature. An example is the integrity protection provided by the RTP/SAVP profile, which cannot be used in conjunction with DCCP partial checksums 🙃.
- An RTP profile that mandates a particular non-DCCP lower-layer transport will conflict with DCCP 🚫.
RTP profiles that fall under these exceptions SHOULD NOT be used with DCCP unless the conflicting features can be disabled 🙅.
Of the profiles defined so far, the RTP Profile for Audio and Video Conferences with Minimal Control [4], the Secure Real-time Transport Protocol [8], the Extended RTP Profile for RTCP-based Feedback [9], and the Extended Secure RTP Profile for RTCP-based Feedback [10] MAY be used with DCCP. Just keep in mind the potential conflict between DCCP partial checksums and the integrity protection in the secure RTP variants (see Section 6) 🔐✨.
5. RTP over DCCP: Signalling using SDP 📣
The Session Description Protocol (SDP) [3] and the offer/answer model [11] are used everywhere to negotiate RTP sessions, for example with the Session Initiation Protocol [22] 💅. This section explains how SDP signals RTP sessions running over DCCP 🎀.
5.1. Protocol Identification 🔖
SDP uses a media ("m=") line to describe the media format and the transport protocol being used 📝. The ABNF syntax of a media line goes like this (from [3]):
media-field = %x6d "=" media SP port ["/" integer] SP proto
1*(SP fmt) CRLFThe proto field says which transport protocol carries the media, and the port says which transport port the media gets sent to 🌸. Following [5] and [12], this memo defines these five values of the proto field to indicate media carried over DCCP 🦋:
DCCP
DCCP/RTP/AVP
DCCP/RTP/SAVP
DCCP/RTP/AVPF
DCCP/RTP/SAVPFThe "DCCP" protocol identifier is kind of like the "UDP" and "TCP" ones, and it means the DCCP transport protocol [2], but NOT the upper-layer protocol on top of it 🧁. An SDP "m=" line that says "DCCP" MUST also qualify the application-layer protocol using a "fmt" identifier. (The "fmt" namespace is managed the same way as it is for the "UDP" protocol identifier.) A single DCCP port gets used, shown by the port field in the media line 🎯. And the "DCCP" protocol identifier MUST NOT be used to signal RTP sessions running over DCCP. Those sessions MUST use a protocol identifier of the form "DCCP/RTP/..." as described below 🚫.
The "DCCP/RTP/AVP" protocol identifier means RTP using the RTP Profile for Audio and Video Conferences with Minimal Control [4], running over DCCP 💜.
The "DCCP/RTP/SAVP" protocol identifier means RTP using the Secure Real-time Transport Protocol [8], running over DCCP 🔐.
The "DCCP/RTP/AVPF" protocol identifier means RTP using the Extended RTP Profile for RTCP-based Feedback [9], running over DCCP 🔁.
The "DCCP/RTP/SAVPF" protocol identifier means RTP using the Extended Secure RTP Profile for RTCP-based Feedback [10], running over DCCP 🛡️.
RTP payload formats used with the "DCCP/RTP/AVP", "DCCP/RTP/SAVP", "DCCP/RTP/AVPF", and "DCCP/RTP/SAVPF" protocol identifiers MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned, an additional "rtpmap" attribute MUST be included to specify the format name and parameters, as defined by the media type registration for the payload format 🧾.
DCCP port 5004 is registered for use by the RTP profiles listed above, and SHOULD be the default port that applications pick when using those profiles 🎀. If a host has multiple RTP sessions active, even-numbered ports in the dynamic range SHOULD be used for the other sessions 🔢. If RTCP is going to be sent on a separate DCCP connection from RTP, the RTCP connection SHOULD use the next higher destination port number, unless an alternative DCCP port is signalled using the "a=rtcp:" attribute [13] 🌟. For improved interoperability, "a=rtcp:" SHOULD be used whenever an alternate DCCP port is used 🫶.
5.2. Service Codes ✨
Okay so, on top of the port number in the SDP "m=" line, a DCCP connection also has a service code attached to it 🎀 There's one new SDP attribute, "dccp-service-code", for signalling it, and it's defined with this ABNF [14]:
dccp-service-attr = %x61 "=dccp-service-code:" service-code
service-code = hex-sc / decimal-sc / ascii-sc
hex-sc = %x53 %x43 "=" %x78 *HEXDIG
decimal-sc = %x53 %x43 "=" *DIGIT
ascii-sc = %x53 %x43 ":" *sc-char
sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122DIGIT and HEXDIG are defined in [14], so you already have them 💅 The service code gets interpreted the way Section 8.1.2 of [2] describes, and you can write it in hexadecimal, decimal, or ASCII format, whichever you like 🦋 One thing to lock in: a parser MUST interpret service codes by their numeric value, no matter which format shows up in the SDP. Format doesn't change the meaning, periodt 😭
These DCCP service codes are registered for RTP:
SC:RTPA(equivalentlySC=1381257281orSC=x52545041): an RTP session carrying audio data (and OPTIONAL multiplexed RTCP) 🎵SC:RTPV(equivalentlySC=1381257302orSC=x52545056): an RTP session carrying video data (and OPTIONAL multiplexed RTCP) 🎬SC:RTPT(equivalentlySC=1381257300orSC=x52545054): an RTP session carrying text media (and OPTIONAL multiplexed RTCP) 📝SC:RTPO(equivalentlySC=1381257295orSC=x5254504f): an RTP session carrying any other type of media (and OPTIONAL multiplexed RTCP) 🌈SC:RTCP(equivalentlySC=1381253968orSC=x52544350): an RTCP connection, separate from the corresponding RTP 🧚
To make life easier for middleboxes, applications SHOULD use these service codes to identify RTP sessions running over DCCP. The service code SHOULD match the top-level media type signalled for the session (that's the SDP "m=" line). Two exceptions: connections using media types other than audio, video, or text use SC:RTPO, and connections carrying only RTCP packets use SC:RTCP 🍓
The "a=dccp-service-code:" attribute is a media-level attribute, and it is not subject to the charset attribute. Bestie, that's a lot of detail, but it's all in there ✨
5.3. Connection Management
The "a=setup:" attribute tells you which endpoint should start the DCCP connection establishment, meaning which one sends the initial DCCP-Request packet 🚀 It MUST be used in a manner comparable with [12], except that DCCP connections are being initiated instead of TCP connections. It's the same vibe as TCP, just with DCCP 🦋
After the initial offer/answer exchange, the endpoints might decide to re-negotiate some parameters. The "a=connection:" attribute MUST be used in a manner compatible with [12] to decide whether a new DCCP connection needs to be set up because of a later offer/answer exchange, or whether the existing connection should keep going 🌸
5.4. Multiplexing Data and Control
A single DCCP connection can carry multiplexed RTP and RTCP packets, so you don't need two separate pipes 💖 That multiplexing MUST be signalled with an "a=rtcp-mux" attribute, following [7]. If you're NOT doing multiplexed RTP and RTCP, then the "a=rtcp-mux" attribute MUST NOT be present in the SDP offer, and a separate DCCP connection MUST be opened to carry the RTCP data on a different DCCP port 🫶
5.5. Example
Let's see it in action 👑 An offerer at 192.0.2.47 announces it's available for an H.261 video session, using RTP/AVP over DCCP with the service code "RTPV" (written in the hexadecimal encoding in the SDP). RTP and RTCP get multiplexed onto one DCCP connection:
v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=setup:passive
a=connection:newAn answerer at 192.0.2.128 gets this offer and replies with the following answer 💜
v=0
o=bob 1129377364 1 IN IP4 192.0.2.128
s=-
c=IN IP4 192.0.2.128
t=0 0
m=video 9 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC:RTPV
a=setup:active
a=connection:newThen the end point at 192.0.2.128 starts a DCCP connection to port 5004 at 192.0.2.47. DCCP port 5004 handles both the RTP and RTCP data, and port 5005 goes unused 🙈 The answer uses the textual encoding of the service code, and it represents the same service code as the offer, so they match perfectly 🎀
6. Security Considerations
The security considerations in the RTP specification [1] apply when you transport RTP over DCCP, and so do the ones in any applicable RTP profile (e.g., [4], [8], [9], or [10]) or payload format 🔐
The security considerations in the DCCP specification [2] apply too 💀
The SDP signalling described in Section 5 is subject to the security considerations of [3], [11], [12], [5], and [7] 🛡️
Effective congestion control for RTP through DCCP is expected to help reduce the potential for denial of service. That matters because RTP flows that ignore the advice in [1] to monitor packet loss and cut their sending rate during persistent congestion can cause exactly that problem 🚦
Heads up, this one's serious: there's a potential conflict between the Secure RTP profiles ([8], [10]) and the DCCP partial checksum option. These profiles introduce, and recommend the use of, message authentication for RTP and RTCP packets. Message authentication codes of the type used by these profiles cannot be used with partial checksums, since any bit error in the DCCP packet payload will cause the authentication check to fail. So DCCP partial checksums SHOULD NOT be used in conjunction with Secure Real-time Transport Protocol (SRTP) authentication. The confidentiality features of the basic RTP specification cannot be used with DCCP partial checksums, because bit errors propagate. Also, even though bit errors don't propagate when AES is used in counter mode, the Secure RTP profiles SHOULD NOT be used with DCCP partial checksums, since the profiles require authentication for security, and authentication is incompatible with partial checksums 😭🚨
7. IANA Considerations
The following SDP "proto" field identifiers have been registered (see Section 5.1) 📋
Type SDP Name Reference
---- -------- ---------
proto DCCP [RFC5762]
DCCP/RTP/AVP [RFC5762]
DCCP/RTP/SAVP [RFC5762]
DCCP/RTP/AVPF [RFC5762]
DCCP/RTP/SAVPF [RFC5762]The following new SDP attribute ("att-field") has been registered 💅
Contact name: Colin Perkins <csp@csperkins.org>
Attribute name: dccp-service-code
Long-form attribute name in English: DCCP service code
Type of attribute: Media level.
Subject to the charset attribute? No.
Purpose of the attribute: see RFC 5762, Section 5.2
Allowed attribute values: see RFC 5762, Section 5.2The following DCCP service code values have been registered (see Section 5.2) 🦋
1381257281 RTPA RTP session conveying audio [RFC5762]
data (and associated RTCP)
1381257302 RTPV RTP session conveying video [RFC5762]
data (and associated RTCP)
1381257300 RTPT RTP session conveying text [RFC5762]
media (and associated RTCP)
1381257295 RTPO RTP session conveying other [RFC5762]
media (and associated RTCP)
1381253968 RTCP RTCP connection, separate from [RFC5762]
the corresponding RTPThe following DCCP ports have been registered (see Section 5.1) 🌈
avt-profile-1 5004/dccp RTP media data [RFC3551, RFC5762]
avt-profile-2 5005/dccp RTP control protocol [RFC3551, RFC5762]Heads up on a bit of cleanup: ports 5004/tcp, 5004/udp, 5005/tcp, and 5005/udp already had registrations, but their descriptions and references were wrong. IANA has updated those existing registrations like this 🧹
avt-profile-1 5004/tcp RTP media data [RFC3551, RFC4571]
avt-profile-1 5004/udp RTP media data [RFC3551]
avt-profile-2 5005/tcp RTP control protocol [RFC3551, RFC4571]
avt-profile-2 5005/udp RTP control protocol [RFC3551]8. Acknowledgements
This work was supported in part by the UK Engineering and Physical Sciences Research Council 🇬🇧 Big thanks to Philippe Gentric, Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane Bortzmeyer, Arjuna Sathiaseelan, Tom Phelan, Lars Eggert, Eddie Kohler, Miguel Garcia, and the rest of the DCCP working group for their comments 🫶✨
9. References
9.1. Normative References
These are the references I'm pulling in, the full details included 📚
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and
RTP Control Protocol (RTCP) Packets over Connection-Oriented
Transport", RFC 4571, July 2006.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[9] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-
time Transport Control Protocol (RTCP)-Based Feedback (RTP/
SAVPF)", RFC 5124, February 2008.
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Session Description Protocol (SDP)", RFC 4145, September 2005.
[13] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003.
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.9.2. Informative References 📚
okay so these are the "extra reading" refs, the ones that aren't required to implement anything but give you the backstory 🧚 they're listed in order, same as the original
- [15] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004. 🎀
- [16] Gharai, L., "RTP with TCP Friendly Rate Control", Work in Progress, July 2007. 🦋
- [17] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. 💖
- [18] Andreasen, F., Oran, D., and D. Wing, "A No-Op Payload Format for RTP", Work in Progress, May 2005. 🌸
- [19] Phelan, T., "Strategies for Streaming Media Applications Using TCP-Friendly Rate Control", Work in Progress, July 2007. ✨
- [20] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User Guide", Work in Progress, April 2005. 💅
- [21] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007. 🫶
- [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 👑
- [23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. 🌈
- [24] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", Work in Progress, October 2007. 🍓
Author's Address 🖊️
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ UK
EMail: csp@csperkins.org
and that's the whole RFC, bestie 💜 you made it through every single section 😭🫶
📦 where this page comes from
- ietf: rfc5762 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms