7 Network Working Group H. Schulzrinne
8 Request for Comments: 3550 Columbia University
9 Obsoletes: 1889 S. Casner
10 Category: Standards Track Packet Design
12 Blue Coat Systems Inc.
18 RTP: A Transport Protocol for Real-Time Applications
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
30 Copyright (C) The Internet Society (2003). All Rights Reserved.
34 This memorandum describes RTP, the real-time transport protocol. RTP
35 provides end-to-end network transport functions suitable for
36 applications transmitting real-time data, such as audio, video or
37 simulation data, over multicast or unicast network services. RTP
38 does not address resource reservation and does not guarantee
39 quality-of-service for real-time services. The data transport is
40 augmented by a control protocol (RTCP) to allow monitoring of the
41 data delivery in a manner scalable to large multicast networks, and
42 to provide minimal control and identification functionality. RTP and
43 RTCP are designed to be independent of the underlying transport and
44 network layers. The protocol supports the use of RTP-level
45 translators and mixers.
47 Most of the text in this memorandum is identical to RFC 1889 which it
48 obsoletes. There are no changes in the packet formats on the wire,
49 only changes to the rules and algorithms governing how the protocol
50 is used. The biggest change is an enhancement to the scalable timer
51 algorithm for calculating when to send RTCP packets in order to
52 minimize transmission in excess of the intended rate when many
53 participants join a session simultaneously.
58 Schulzrinne, et al. Standards Track [Page 1]
60 RFC 3550 RTP July 2003
65 1. Introduction ................................................ 4
66 1.1 Terminology ............................................ 5
67 2. RTP Use Scenarios ........................................... 5
68 2.1 Simple Multicast Audio Conference ...................... 6
69 2.2 Audio and Video Conference ............................. 7
70 2.3 Mixers and Translators ................................. 7
71 2.4 Layered Encodings ...................................... 8
72 3. Definitions ................................................. 8
73 4. Byte Order, Alignment, and Time Format ...................... 12
74 5. RTP Data Transfer Protocol .................................. 13
75 5.1 RTP Fixed Header Fields ................................ 13
76 5.2 Multiplexing RTP Sessions .............................. 16
77 5.3 Profile-Specific Modifications to the RTP Header ....... 18
78 5.3.1 RTP Header Extension ............................ 18
79 6. RTP Control Protocol -- RTCP ................................ 19
80 6.1 RTCP Packet Format ..................................... 21
81 6.2 RTCP Transmission Interval ............................. 24
82 6.2.1 Maintaining the Number of Session Members ....... 28
83 6.3 RTCP Packet Send and Receive Rules ..................... 28
84 6.3.1 Computing the RTCP Transmission Interval ........ 29
85 6.3.2 Initialization .................................. 30
86 6.3.3 Receiving an RTP or Non-BYE RTCP Packet ......... 31
87 6.3.4 Receiving an RTCP BYE Packet .................... 31
88 6.3.5 Timing Out an SSRC .............................. 32
89 6.3.6 Expiration of Transmission Timer ................ 32
90 6.3.7 Transmitting a BYE Packet ....................... 33
91 6.3.8 Updating we_sent ................................ 34
92 6.3.9 Allocation of Source Description Bandwidth ...... 34
93 6.4 Sender and Receiver Reports ............................ 35
94 6.4.1 SR: Sender Report RTCP Packet ................... 36
95 6.4.2 RR: Receiver Report RTCP Packet ................. 42
96 6.4.3 Extending the Sender and Receiver Reports ....... 42
97 6.4.4 Analyzing Sender and Receiver Reports ........... 43
98 6.5 SDES: Source Description RTCP Packet ................... 45
99 6.5.1 CNAME: Canonical End-Point Identifier SDES Item . 46
100 6.5.2 NAME: User Name SDES Item ....................... 48
101 6.5.3 EMAIL: Electronic Mail Address SDES Item ........ 48
102 6.5.4 PHONE: Phone Number SDES Item ................... 49
103 6.5.5 LOC: Geographic User Location SDES Item ......... 49
104 6.5.6 TOOL: Application or Tool Name SDES Item ........ 49
105 6.5.7 NOTE: Notice/Status SDES Item ................... 50
106 6.5.8 PRIV: Private Extensions SDES Item .............. 50
107 6.6 BYE: Goodbye RTCP Packet ............................... 51
108 6.7 APP: Application-Defined RTCP Packet ................... 52
109 7. RTP Translators and Mixers .................................. 53
110 7.1 General Description .................................... 53
114 Schulzrinne, et al. Standards Track [Page 2]
116 RFC 3550 RTP July 2003
119 7.2 RTCP Processing in Translators ......................... 55
120 7.3 RTCP Processing in Mixers .............................. 57
121 7.4 Cascaded Mixers ........................................ 58
122 8. SSRC Identifier Allocation and Use .......................... 59
123 8.1 Probability of Collision ............................... 59
124 8.2 Collision Resolution and Loop Detection ................ 60
125 8.3 Use with Layered Encodings ............................. 64
126 9. Security .................................................... 65
127 9.1 Confidentiality ........................................ 65
128 9.2 Authentication and Message Integrity ................... 67
129 10. Congestion Control .......................................... 67
130 11. RTP over Network and Transport Protocols .................... 68
131 12. Summary of Protocol Constants ............................... 69
132 12.1 RTCP Packet Types ...................................... 70
133 12.2 SDES Types ............................................. 70
134 13. RTP Profiles and Payload Format Specifications .............. 71
135 14. Security Considerations ..................................... 73
136 15. IANA Considerations ......................................... 73
137 16. Intellectual Property Rights Statement ...................... 74
138 17. Acknowledgments ............................................. 74
139 Appendix A. Algorithms ........................................ 75
140 Appendix A.1 RTP Data Header Validity Checks ................... 78
141 Appendix A.2 RTCP Header Validity Checks ....................... 82
142 Appendix A.3 Determining Number of Packets Expected and Lost ... 83
143 Appendix A.4 Generating RTCP SDES Packets ...................... 84
144 Appendix A.5 Parsing RTCP SDES Packets ......................... 85
145 Appendix A.6 Generating a Random 32-bit Identifier ............. 85
146 Appendix A.7 Computing the RTCP Transmission Interval .......... 87
147 Appendix A.8 Estimating the Interarrival Jitter ................ 94
148 Appendix B. Changes from RFC 1889 ............................. 95
149 References ...................................................... 100
150 Normative References ............................................ 100
151 Informative References .......................................... 100
152 Authors' Addresses .............................................. 103
153 Full Copyright Statement ........................................ 104
170 Schulzrinne, et al. Standards Track [Page 3]
172 RFC 3550 RTP July 2003
177 This memorandum specifies the real-time transport protocol (RTP),
178 which provides end-to-end delivery services for data with real-time
179 characteristics, such as interactive audio and video. Those services
180 include payload type identification, sequence numbering, timestamping
181 and delivery monitoring. Applications typically run RTP on top of
182 UDP to make use of its multiplexing and checksum services; both
183 protocols contribute parts of the transport protocol functionality.
184 However, RTP may be used with other suitable underlying network or
185 transport protocols (see Section 11). RTP supports data transfer to
186 multiple destinations using multicast distribution if provided by the
189 Note that RTP itself does not provide any mechanism to ensure timely
190 delivery or provide other quality-of-service guarantees, but relies
191 on lower-layer services to do so. It does not guarantee delivery or
192 prevent out-of-order delivery, nor does it assume that the underlying
193 network is reliable and delivers packets in sequence. The sequence
194 numbers included in RTP allow the receiver to reconstruct the
195 sender's packet sequence, but sequence numbers might also be used to
196 determine the proper location of a packet, for example in video
197 decoding, without necessarily decoding packets in sequence.
199 While RTP is primarily designed to satisfy the needs of multi-
200 participant multimedia conferences, it is not limited to that
201 particular application. Storage of continuous data, interactive
202 distributed simulation, active badge, and control and measurement
203 applications may also find RTP applicable.
205 This document defines RTP, consisting of two closely-linked parts:
207 o the real-time transport protocol (RTP), to carry data that has
208 real-time properties.
210 o the RTP control protocol (RTCP), to monitor the quality of service
211 and to convey information about the participants in an on-going
212 session. The latter aspect of RTCP may be sufficient for "loosely
213 controlled" sessions, i.e., where there is no explicit membership
214 control and set-up, but it is not necessarily intended to support
215 all of an application's control communication requirements. This
216 functionality may be fully or partially subsumed by a separate
217 session control protocol, which is beyond the scope of this
220 RTP represents a new style of protocol following the principles of
221 application level framing and integrated layer processing proposed by
222 Clark and Tennenhouse [10]. That is, RTP is intended to be malleable
226 Schulzrinne, et al. Standards Track [Page 4]
228 RFC 3550 RTP July 2003
231 to provide the information required by a particular application and
232 will often be integrated into the application processing rather than
233 being implemented as a separate layer. RTP is a protocol framework
234 that is deliberately not complete. This document specifies those
235 functions expected to be common across all the applications for which
236 RTP would be appropriate. Unlike conventional protocols in which
237 additional functions might be accommodated by making the protocol
238 more general or by adding an option mechanism that would require
239 parsing, RTP is intended to be tailored through modifications and/or
240 additions to the headers as needed. Examples are given in Sections
243 Therefore, in addition to this document, a complete specification of
244 RTP for a particular application will require one or more companion
245 documents (see Section 13):
247 o a profile specification document, which defines a set of payload
248 type codes and their mapping to payload formats (e.g., media
249 encodings). A profile may also define extensions or modifications
250 to RTP that are specific to a particular class of applications.
251 Typically an application will operate under only one profile. A
252 profile for audio and video data may be found in the companion RFC
255 o payload format specification documents, which define how a
256 particular payload, such as an audio or video encoding, is to be
259 A discussion of real-time services and algorithms for their
260 implementation as well as background discussion on some of the RTP
261 design decisions can be found in [11].
265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
267 document are to be interpreted as described in BCP 14, RFC 2119 [2]
268 and indicate requirement levels for compliant RTP implementations.
272 The following sections describe some aspects of the use of RTP. The
273 examples were chosen to illustrate the basic operation of
274 applications using RTP, not to limit what RTP may be used for. In
275 these examples, RTP is carried on top of IP and UDP, and follows the
276 conventions established by the profile for audio and video specified
277 in the companion RFC 3551.
282 Schulzrinne, et al. Standards Track [Page 5]
284 RFC 3550 RTP July 2003
287 2.1 Simple Multicast Audio Conference
289 A working group of the IETF meets to discuss the latest protocol
290 document, using the IP multicast services of the Internet for voice
291 communications. Through some allocation mechanism the working group
292 chair obtains a multicast group address and pair of ports. One port
293 is used for audio data, and the other is used for control (RTCP)
294 packets. This address and port information is distributed to the
295 intended participants. If privacy is desired, the data and control
296 packets may be encrypted as specified in Section 9.1, in which case
297 an encryption key must also be generated and distributed. The exact
298 details of these allocation and distribution mechanisms are beyond
301 The audio conferencing application used by each conference
302 participant sends audio data in small chunks of, say, 20 ms duration.
303 Each chunk of audio data is preceded by an RTP header; RTP header and
304 data are in turn contained in a UDP packet. The RTP header indicates
305 what type of audio encoding (such as PCM, ADPCM or LPC) is contained
306 in each packet so that senders can change the encoding during a
307 conference, for example, to accommodate a new participant that is
308 connected through a low-bandwidth link or react to indications of
311 The Internet, like other packet networks, occasionally loses and
312 reorders packets and delays them by variable amounts of time. To
313 cope with these impairments, the RTP header contains timing
314 information and a sequence number that allow the receivers to
315 reconstruct the timing produced by the source, so that in this
316 example, chunks of audio are contiguously played out the speaker
317 every 20 ms. This timing reconstruction is performed separately for
318 each source of RTP packets in the conference. The sequence number
319 can also be used by the receiver to estimate how many packets are
322 Since members of the working group join and leave during the
323 conference, it is useful to know who is participating at any moment
324 and how well they are receiving the audio data. For that purpose,
325 each instance of the audio application in the conference periodically
326 multicasts a reception report plus the name of its user on the RTCP
327 (control) port. The reception report indicates how well the current
328 speaker is being received and may be used to control adaptive
329 encodings. In addition to the user name, other identifying
330 information may also be included subject to control bandwidth limits.
331 A site sends the RTCP BYE packet (Section 6.6) when it leaves the
338 Schulzrinne, et al. Standards Track [Page 6]
340 RFC 3550 RTP July 2003
343 2.2 Audio and Video Conference
345 If both audio and video media are used in a conference, they are
346 transmitted as separate RTP sessions. That is, separate RTP and RTCP
347 packets are transmitted for each medium using two different UDP port
348 pairs and/or multicast addresses. There is no direct coupling at the
349 RTP level between the audio and video sessions, except that a user
350 participating in both sessions should use the same distinguished
351 (canonical) name in the RTCP packets for both so that the sessions
354 One motivation for this separation is to allow some participants in
355 the conference to receive only one medium if they choose. Further
356 explanation is given in Section 5.2. Despite the separation,
357 synchronized playback of a source's audio and video can be achieved
358 using timing information carried in the RTCP packets for both
361 2.3 Mixers and Translators
363 So far, we have assumed that all sites want to receive media data in
364 the same format. However, this may not always be appropriate.
365 Consider the case where participants in one area are connected
366 through a low-speed link to the majority of the conference
367 participants who enjoy high-speed network access. Instead of forcing
368 everyone to use a lower-bandwidth, reduced-quality audio encoding, an
369 RTP-level relay called a mixer may be placed near the low-bandwidth
370 area. This mixer resynchronizes incoming audio packets to
371 reconstruct the constant 20 ms spacing generated by the sender, mixes
372 these reconstructed audio streams into a single stream, translates
373 the audio encoding to a lower-bandwidth one and forwards the lower-
374 bandwidth packet stream across the low-speed link. These packets
375 might be unicast to a single recipient or multicast on a different
376 address to multiple recipients. The RTP header includes a means for
377 mixers to identify the sources that contributed to a mixed packet so
378 that correct talker indication can be provided at the receivers.
380 Some of the intended participants in the audio conference may be
381 connected with high bandwidth links but might not be directly
382 reachable via IP multicast. For example, they might be behind an
383 application-level firewall that will not let any IP packets pass.
384 For these sites, mixing may not be necessary, in which case another
385 type of RTP-level relay called a translator may be used. Two
386 translators are installed, one on either side of the firewall, with
387 the outside one funneling all multicast packets received through a
388 secure connection to the translator inside the firewall. The
389 translator inside the firewall sends them again as multicast packets
390 to a multicast group restricted to the site's internal network.
394 Schulzrinne, et al. Standards Track [Page 7]
396 RFC 3550 RTP July 2003
399 Mixers and translators may be designed for a variety of purposes. An
400 example is a video mixer that scales the images of individual people
401 in separate video streams and composites them into one video stream
402 to simulate a group scene. Other examples of translation include the
403 connection of a group of hosts speaking only IP/UDP to a group of
404 hosts that understand only ST-II, or the packet-by-packet encoding
405 translation of video streams from individual sources without
406 resynchronization or mixing. Details of the operation of mixers and
407 translators are given in Section 7.
409 2.4 Layered Encodings
411 Multimedia applications should be able to adjust the transmission
412 rate to match the capacity of the receiver or to adapt to network
413 congestion. Many implementations place the responsibility of rate-
414 adaptivity at the source. This does not work well with multicast
415 transmission because of the conflicting bandwidth requirements of
416 heterogeneous receivers. The result is often a least-common
417 denominator scenario, where the smallest pipe in the network mesh
418 dictates the quality and fidelity of the overall live multimedia
421 Instead, responsibility for rate-adaptation can be placed at the
422 receivers by combining a layered encoding with a layered transmission
423 system. In the context of RTP over IP multicast, the source can
424 stripe the progressive layers of a hierarchically represented signal
425 across multiple RTP sessions each carried on its own multicast group.
426 Receivers can then adapt to network heterogeneity and control their
427 reception bandwidth by joining only the appropriate subset of the
430 Details of the use of RTP with layered encodings are given in
431 Sections 6.3.9, 8.3 and 11.
435 RTP payload: The data transported by RTP in a packet, for
436 example audio samples or compressed video data. The payload
437 format and interpretation are beyond the scope of this document.
439 RTP packet: A data packet consisting of the fixed RTP header, a
440 possibly empty list of contributing sources (see below), and the
441 payload data. Some underlying protocols may require an
442 encapsulation of the RTP packet to be defined. Typically one
443 packet of the underlying protocol contains a single RTP packet,
444 but several RTP packets MAY be contained if permitted by the
445 encapsulation method (see Section 11).
450 Schulzrinne, et al. Standards Track [Page 8]
452 RFC 3550 RTP July 2003
455 RTCP packet: A control packet consisting of a fixed header part
456 similar to that of RTP data packets, followed by structured
457 elements that vary depending upon the RTCP packet type. The
458 formats are defined in Section 6. Typically, multiple RTCP
459 packets are sent together as a compound RTCP packet in a single
460 packet of the underlying protocol; this is enabled by the length
461 field in the fixed header of each RTCP packet.
463 Port: The "abstraction that transport protocols use to
464 distinguish among multiple destinations within a given host
465 computer. TCP/IP protocols identify ports using small positive
466 integers." [12] The transport selectors (TSEL) used by the OSI
467 transport layer are equivalent to ports. RTP depends upon the
468 lower-layer protocol to provide some mechanism such as ports to
469 multiplex the RTP and RTCP packets of a session.
471 Transport address: The combination of a network address and port
472 that identifies a transport-level endpoint, for example an IP
473 address and a UDP port. Packets are transmitted from a source
474 transport address to a destination transport address.
476 RTP media type: An RTP media type is the collection of payload
477 types which can be carried within a single RTP session. The RTP
478 Profile assigns RTP media types to RTP payload types.
480 Multimedia session: A set of concurrent RTP sessions among a
481 common group of participants. For example, a videoconference
482 (which is a multimedia session) may contain an audio RTP session
483 and a video RTP session.
485 RTP session: An association among a set of participants
486 communicating with RTP. A participant may be involved in multiple
487 RTP sessions at the same time. In a multimedia session, each
488 medium is typically carried in a separate RTP session with its own
489 RTCP packets unless the the encoding itself multiplexes multiple
490 media into a single data stream. A participant distinguishes
491 multiple RTP sessions by reception of different sessions using
492 different pairs of destination transport addresses, where a pair
493 of transport addresses comprises one network address plus a pair
494 of ports for RTP and RTCP. All participants in an RTP session may
495 share a common destination transport address pair, as in the case
496 of IP multicast, or the pairs may be different for each
497 participant, as in the case of individual unicast network
498 addresses and port pairs. In the unicast case, a participant may
499 receive from all other participants in the session using the same
500 pair of ports, or may use a distinct pair of ports for each.
506 Schulzrinne, et al. Standards Track [Page 9]
508 RFC 3550 RTP July 2003
511 The distinguishing feature of an RTP session is that each
512 maintains a full, separate space of SSRC identifiers (defined
513 next). The set of participants included in one RTP session
514 consists of those that can receive an SSRC identifier transmitted
515 by any one of the participants either in RTP as the SSRC or a CSRC
516 (also defined below) or in RTCP. For example, consider a three-
517 party conference implemented using unicast UDP with each
518 participant receiving from the other two on separate port pairs.
519 If each participant sends RTCP feedback about data received from
520 one other participant only back to that participant, then the
521 conference is composed of three separate point-to-point RTP
522 sessions. If each participant provides RTCP feedback about its
523 reception of one other participant to both of the other
524 participants, then the conference is composed of one multi-party
525 RTP session. The latter case simulates the behavior that would
526 occur with IP multicast communication among the three
529 The RTP framework allows the variations defined here, but a
530 particular control protocol or application design will usually
531 impose constraints on these variations.
533 Synchronization source (SSRC): The source of a stream of RTP
534 packets, identified by a 32-bit numeric SSRC identifier carried in
535 the RTP header so as not to be dependent upon the network address.
536 All packets from a synchronization source form part of the same
537 timing and sequence number space, so a receiver groups packets by
538 synchronization source for playback. Examples of synchronization
539 sources include the sender of a stream of packets derived from a
540 signal source such as a microphone or a camera, or an RTP mixer
541 (see below). A synchronization source may change its data format,
542 e.g., audio encoding, over time. The SSRC identifier is a
543 randomly chosen value meant to be globally unique within a
544 particular RTP session (see Section 8). A participant need not
545 use the same SSRC identifier for all the RTP sessions in a
546 multimedia session; the binding of the SSRC identifiers is
547 provided through RTCP (see Section 6.5.1). If a participant
548 generates multiple streams in one RTP session, for example from
549 separate video cameras, each MUST be identified as a different
552 Contributing source (CSRC): A source of a stream of RTP packets
553 that has contributed to the combined stream produced by an RTP
554 mixer (see below). The mixer inserts a list of the SSRC
555 identifiers of the sources that contributed to the generation of a
556 particular packet into the RTP header of that packet. This list
557 is called the CSRC list. An example application is audio
558 conferencing where a mixer indicates all the talkers whose speech
562 Schulzrinne, et al. Standards Track [Page 10]
564 RFC 3550 RTP July 2003
567 was combined to produce the outgoing packet, allowing the receiver
568 to indicate the current talker, even though all the audio packets
569 contain the same SSRC identifier (that of the mixer).
571 End system: An application that generates the content to be sent
572 in RTP packets and/or consumes the content of received RTP
573 packets. An end system can act as one or more synchronization
574 sources in a particular RTP session, but typically only one.
576 Mixer: An intermediate system that receives RTP packets from one
577 or more sources, possibly changes the data format, combines the
578 packets in some manner and then forwards a new RTP packet. Since
579 the timing among multiple input sources will not generally be
580 synchronized, the mixer will make timing adjustments among the
581 streams and generate its own timing for the combined stream.
582 Thus, all data packets originating from a mixer will be identified
583 as having the mixer as their synchronization source.
585 Translator: An intermediate system that forwards RTP packets
586 with their synchronization source identifier intact. Examples of
587 translators include devices that convert encodings without mixing,
588 replicators from multicast to unicast, and application-level
589 filters in firewalls.
591 Monitor: An application that receives RTCP packets sent by
592 participants in an RTP session, in particular the reception
593 reports, and estimates the current quality of service for
594 distribution monitoring, fault diagnosis and long-term statistics.
595 The monitor function is likely to be built into the application(s)
596 participating in the session, but may also be a separate
597 application that does not otherwise participate and does not send
598 or receive the RTP data packets (since they are on a separate
599 port). These are called third-party monitors. It is also
600 acceptable for a third-party monitor to receive the RTP data
601 packets but not send RTCP packets or otherwise be counted in the
604 Non-RTP means: Protocols and mechanisms that may be needed in
605 addition to RTP to provide a usable service. In particular, for
606 multimedia conferences, a control protocol may distribute
607 multicast addresses and keys for encryption, negotiate the
608 encryption algorithm to be used, and define dynamic mappings
609 between RTP payload type values and the payload formats they
610 represent for formats that do not have a predefined payload type
611 value. Examples of such protocols include the Session Initiation
612 Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] and
613 applications using SDP (RFC 2327 [15]), such as RTSP (RFC 2326
618 Schulzrinne, et al. Standards Track [Page 11]
620 RFC 3550 RTP July 2003
623 applications, electronic mail or a conference database may also be
624 used. The specification of such protocols and mechanisms is
625 outside the scope of this document.
627 4. Byte Order, Alignment, and Time Format
629 All integer fields are carried in network byte order, that is, most
630 significant byte (octet) first. This byte order is commonly known as
631 big-endian. The transmission order is described in detail in [3].
632 Unless otherwise noted, numeric constants are in decimal (base 10).
634 All header data is aligned to its natural length, i.e., 16-bit fields
635 are aligned on even offsets, 32-bit fields are aligned at offsets
636 divisible by four, etc. Octets designated as padding have the value
639 Wallclock time (absolute date and time) is represented using the
640 timestamp format of the Network Time Protocol (NTP), which is in
641 seconds relative to 0h UTC on 1 January 1900 [4]. The full
642 resolution NTP timestamp is a 64-bit unsigned fixed-point number with
643 the integer part in the first 32 bits and the fractional part in the
644 last 32 bits. In some fields where a more compact representation is
645 appropriate, only the middle 32 bits are used; that is, the low 16
646 bits of the integer part and the high 16 bits of the fractional part.
647 The high 16 bits of the integer part must be determined
650 An implementation is not required to run the Network Time Protocol in
651 order to use RTP. Other time sources, or none at all, may be used
652 (see the description of the NTP timestamp field in Section 6.4.1).
653 However, running NTP may be useful for synchronizing streams
654 transmitted from separate hosts.
656 The NTP timestamp will wrap around to zero some time in the year
657 2036, but for RTP purposes, only differences between pairs of NTP
658 timestamps are used. So long as the pairs of timestamps can be
659 assumed to be within 68 years of each other, using modular arithmetic
660 for subtractions and comparisons makes the wraparound irrelevant.
674 Schulzrinne, et al. Standards Track [Page 12]
676 RFC 3550 RTP July 2003
679 5. RTP Data Transfer Protocol
681 5.1 RTP Fixed Header Fields
683 The RTP header has the following format:
686 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
688 |V=2|P|X| CC |M| PT | sequence number |
689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
692 | synchronization source (SSRC) identifier |
693 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
694 | contributing source (CSRC) identifiers |
696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
698 The first twelve octets are present in every RTP packet, while the
699 list of CSRC identifiers is present only when inserted by a mixer.
700 The fields have the following meaning:
703 This field identifies the version of RTP. The version defined by
704 this specification is two (2). (The value 1 is used by the first
705 draft version of RTP and the value 0 is used by the protocol
706 initially implemented in the "vat" audio tool.)
709 If the padding bit is set, the packet contains one or more
710 additional padding octets at the end which are not part of the
711 payload. The last octet of the padding contains a count of how
712 many padding octets should be ignored, including itself. Padding
713 may be needed by some encryption algorithms with fixed block sizes
714 or for carrying several RTP packets in a lower-layer protocol data
718 If the extension bit is set, the fixed header MUST be followed by
719 exactly one header extension, with a format defined in Section
722 CSRC count (CC): 4 bits
723 The CSRC count contains the number of CSRC identifiers that follow
730 Schulzrinne, et al. Standards Track [Page 13]
732 RFC 3550 RTP July 2003
736 The interpretation of the marker is defined by a profile. It is
737 intended to allow significant events such as frame boundaries to
738 be marked in the packet stream. A profile MAY define additional
739 marker bits or specify that there is no marker bit by changing the
740 number of bits in the payload type field (see Section 5.3).
742 payload type (PT): 7 bits
743 This field identifies the format of the RTP payload and determines
744 its interpretation by the application. A profile MAY specify a
745 default static mapping of payload type codes to payload formats.
746 Additional payload type codes MAY be defined dynamically through
747 non-RTP means (see Section 3). A set of default mappings for
748 audio and video is specified in the companion RFC 3551 [1]. An
749 RTP source MAY change the payload type during a session, but this
750 field SHOULD NOT be used for multiplexing separate media streams
753 A receiver MUST ignore packets with payload types that it does not
756 sequence number: 16 bits
757 The sequence number increments by one for each RTP data packet
758 sent, and may be used by the receiver to detect packet loss and to
759 restore packet sequence. The initial value of the sequence number
760 SHOULD be random (unpredictable) to make known-plaintext attacks
761 on encryption more difficult, even if the source itself does not
762 encrypt according to the method in Section 9.1, because the
763 packets may flow through a translator that does. Techniques for
764 choosing unpredictable numbers are discussed in [17].
767 The timestamp reflects the sampling instant of the first octet in
768 the RTP data packet. The sampling instant MUST be derived from a
769 clock that increments monotonically and linearly in time to allow
770 synchronization and jitter calculations (see Section 6.4.1). The
771 resolution of the clock MUST be sufficient for the desired
772 synchronization accuracy and for measuring packet arrival jitter
773 (one tick per video frame is typically not sufficient). The clock
774 frequency is dependent on the format of data carried as payload
775 and is specified statically in the profile or payload format
776 specification that defines the format, or MAY be specified
777 dynamically for payload formats defined through non-RTP means. If
778 RTP packets are generated periodically, the nominal sampling
779 instant as determined from the sampling clock is to be used, not a
780 reading of the system clock. As an example, for fixed-rate audio
781 the timestamp clock would likely increment by one for each
782 sampling period. If an audio application reads blocks covering
786 Schulzrinne, et al. Standards Track [Page 14]
788 RFC 3550 RTP July 2003
791 160 sampling periods from the input device, the timestamp would be
792 increased by 160 for each such block, regardless of whether the
793 block is transmitted in a packet or dropped as silent.
795 The initial value of the timestamp SHOULD be random, as for the
796 sequence number. Several consecutive RTP packets will have equal
797 timestamps if they are (logically) generated at once, e.g., belong
798 to the same video frame. Consecutive RTP packets MAY contain
799 timestamps that are not monotonic if the data is not transmitted
800 in the order it was sampled, as in the case of MPEG interpolated
801 video frames. (The sequence numbers of the packets as transmitted
802 will still be monotonic.)
804 RTP timestamps from different media streams may advance at
805 different rates and usually have independent, random offsets.
806 Therefore, although these timestamps are sufficient to reconstruct
807 the timing of a single stream, directly comparing RTP timestamps
808 from different media is not effective for synchronization.
809 Instead, for each medium the RTP timestamp is related to the
810 sampling instant by pairing it with a timestamp from a reference
811 clock (wallclock) that represents the time when the data
812 corresponding to the RTP timestamp was sampled. The reference
813 clock is shared by all media to be synchronized. The timestamp
814 pairs are not transmitted in every data packet, but at a lower
815 rate in RTCP SR packets as described in Section 6.4.
817 The sampling instant is chosen as the point of reference for the
818 RTP timestamp because it is known to the transmitting endpoint and
819 has a common definition for all media, independent of encoding
820 delays or other processing. The purpose is to allow synchronized
821 presentation of all media sampled at the same time.
823 Applications transmitting stored data rather than data sampled in
824 real time typically use a virtual presentation timeline derived
825 from wallclock time to determine when the next frame or other unit
826 of each medium in the stored data should be presented. In this
827 case, the RTP timestamp would reflect the presentation time for
828 each unit. That is, the RTP timestamp for each unit would be
829 related to the wallclock time at which the unit becomes current on
830 the virtual presentation timeline. Actual presentation occurs
831 some time later as determined by the receiver.
833 An example describing live audio narration of prerecorded video
834 illustrates the significance of choosing the sampling instant as
835 the reference point. In this scenario, the video would be
836 presented locally for the narrator to view and would be
837 simultaneously transmitted using RTP. The "sampling instant" of a
838 video frame transmitted in RTP would be established by referencing
842 Schulzrinne, et al. Standards Track [Page 15]
844 RFC 3550 RTP July 2003
847 its timestamp to the wallclock time when that video frame was
848 presented to the narrator. The sampling instant for the audio RTP
849 packets containing the narrator's speech would be established by
850 referencing the same wallclock time when the audio was sampled.
851 The audio and video may even be transmitted by different hosts if
852 the reference clocks on the two hosts are synchronized by some
853 means such as NTP. A receiver can then synchronize presentation
854 of the audio and video packets by relating their RTP timestamps
855 using the timestamp pairs in RTCP SR packets.
858 The SSRC field identifies the synchronization source. This
859 identifier SHOULD be chosen randomly, with the intent that no two
860 synchronization sources within the same RTP session will have the
861 same SSRC identifier. An example algorithm for generating a
862 random identifier is presented in Appendix A.6. Although the
863 probability of multiple sources choosing the same identifier is
864 low, all RTP implementations must be prepared to detect and
865 resolve collisions. Section 8 describes the probability of
866 collision along with a mechanism for resolving collisions and
867 detecting RTP-level forwarding loops based on the uniqueness of
868 the SSRC identifier. If a source changes its source transport
869 address, it must also choose a new SSRC identifier to avoid being
870 interpreted as a looped source (see Section 8.2).
872 CSRC list: 0 to 15 items, 32 bits each
873 The CSRC list identifies the contributing sources for the payload
874 contained in this packet. The number of identifiers is given by
875 the CC field. If there are more than 15 contributing sources,
876 only 15 can be identified. CSRC identifiers are inserted by
877 mixers (see Section 7.1), using the SSRC identifiers of
878 contributing sources. For example, for audio packets the SSRC
879 identifiers of all sources that were mixed together to create a
880 packet are listed, allowing correct talker indication at the
883 5.2 Multiplexing RTP Sessions
885 For efficient protocol processing, the number of multiplexing points
886 should be minimized, as described in the integrated layer processing
887 design principle [10]. In RTP, multiplexing is provided by the
888 destination transport address (network address and port number) which
889 is different for each RTP session. For example, in a teleconference
890 composed of audio and video media encoded separately, each medium
891 SHOULD be carried in a separate RTP session with its own destination
898 Schulzrinne, et al. Standards Track [Page 16]
900 RFC 3550 RTP July 2003
903 Separate audio and video streams SHOULD NOT be carried in a single
904 RTP session and demultiplexed based on the payload type or SSRC
905 fields. Interleaving packets with different RTP media types but
906 using the same SSRC would introduce several problems:
908 1. If, say, two audio streams shared the same RTP session and the
909 same SSRC value, and one were to change encodings and thus acquire
910 a different RTP payload type, there would be no general way of
911 identifying which stream had changed encodings.
913 2. An SSRC is defined to identify a single timing and sequence number
914 space. Interleaving multiple payload types would require
915 different timing spaces if the media clock rates differ and would
916 require different sequence number spaces to tell which payload
917 type suffered packet loss.
919 3. The RTCP sender and receiver reports (see Section 6.4) can only
920 describe one timing and sequence number space per SSRC and do not
921 carry a payload type field.
923 4. An RTP mixer would not be able to combine interleaved streams of
924 incompatible media into one stream.
926 5. Carrying multiple media in one RTP session precludes: the use of
927 different network paths or network resource allocations if
928 appropriate; reception of a subset of the media if desired, for
929 example just audio if video would exceed the available bandwidth;
930 and receiver implementations that use separate processes for the
931 different media, whereas using separate RTP sessions permits
932 either single- or multiple-process implementations.
934 Using a different SSRC for each medium but sending them in the same
935 RTP session would avoid the first three problems but not the last
938 On the other hand, multiplexing multiple related sources of the same
939 medium in one RTP session using different SSRC values is the norm for
940 multicast sessions. The problems listed above don't apply: an RTP
941 mixer can combine multiple audio sources, for example, and the same
942 treatment is applicable for all of them. It may also be appropriate
943 to multiplex streams of the same medium using different SSRC values
944 in other scenarios where the last two problems do not apply.
954 Schulzrinne, et al. Standards Track [Page 17]
956 RFC 3550 RTP July 2003
959 5.3 Profile-Specific Modifications to the RTP Header
961 The existing RTP data packet header is believed to be complete for
962 the set of functions required in common across all the application
963 classes that RTP might support. However, in keeping with the ALF
964 design principle, the header MAY be tailored through modifications or
965 additions defined in a profile specification while still allowing
966 profile-independent monitoring and recording tools to function.
968 o The marker bit and payload type field carry profile-specific
969 information, but they are allocated in the fixed header since many
970 applications are expected to need them and might otherwise have to
971 add another 32-bit word just to hold them. The octet containing
972 these fields MAY be redefined by a profile to suit different
973 requirements, for example with more or fewer marker bits. If
974 there are any marker bits, one SHOULD be located in the most
975 significant bit of the octet since profile-independent monitors
976 may be able to observe a correlation between packet loss patterns
979 o Additional information that is required for a particular payload
980 format, such as a video encoding, SHOULD be carried in the payload
981 section of the packet. This might be in a header that is always
982 present at the start of the payload section, or might be indicated
983 by a reserved value in the data pattern.
985 o If a particular class of applications needs additional
986 functionality independent of payload format, the profile under
987 which those applications operate SHOULD define additional fixed
988 fields to follow immediately after the SSRC field of the existing
989 fixed header. Those applications will be able to quickly and
990 directly access the additional fields while profile-independent
991 monitors or recorders can still process the RTP packets by
992 interpreting only the first twelve octets.
994 If it turns out that additional functionality is needed in common
995 across all profiles, then a new version of RTP should be defined to
996 make a permanent change to the fixed header.
998 5.3.1 RTP Header Extension
1000 An extension mechanism is provided to allow individual
1001 implementations to experiment with new payload-format-independent
1002 functions that require additional information to be carried in the
1003 RTP data packet header. This mechanism is designed so that the
1004 header extension may be ignored by other interoperating
1005 implementations that have not been extended.
1010 Schulzrinne, et al. Standards Track [Page 18]
1012 RFC 3550 RTP July 2003
1015 Note that this header extension is intended only for limited use.
1016 Most potential uses of this mechanism would be better done another
1017 way, using the methods described in the previous section. For
1018 example, a profile-specific extension to the fixed header is less
1019 expensive to process because it is not conditional nor in a variable
1020 location. Additional information required for a particular payload
1021 format SHOULD NOT use this header extension, but SHOULD be carried in
1022 the payload section of the packet.
1025 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1027 | defined by profile | length |
1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1029 | header extension |
1032 If the X bit in the RTP header is one, a variable-length header
1033 extension MUST be appended to the RTP header, following the CSRC list
1034 if present. The header extension contains a 16-bit length field that
1035 counts the number of 32-bit words in the extension, excluding the
1036 four-octet extension header (therefore zero is a valid length). Only
1037 a single extension can be appended to the RTP data header. To allow
1038 multiple interoperating implementations to each experiment
1039 independently with different header extensions, or to allow a
1040 particular implementation to experiment with more than one type of
1041 header extension, the first 16 bits of the header extension are left
1042 open for distinguishing identifiers or parameters. The format of
1043 these 16 bits is to be defined by the profile specification under
1044 which the implementations are operating. This RTP specification does
1045 not define any header extensions itself.
1047 6. RTP Control Protocol -- RTCP
1049 The RTP control protocol (RTCP) is based on the periodic transmission
1050 of control packets to all participants in the session, using the same
1051 distribution mechanism as the data packets. The underlying protocol
1052 MUST provide multiplexing of the data and control packets, for
1053 example using separate port numbers with UDP. RTCP performs four
1056 1. The primary function is to provide feedback on the quality of the
1057 data distribution. This is an integral part of the RTP's role as
1058 a transport protocol and is related to the flow and congestion
1059 control functions of other transport protocols (see Section 10 on
1060 the requirement for congestion control). The feedback may be
1061 directly useful for control of adaptive encodings [18,19], but
1062 experiments with IP multicasting have shown that it is also
1066 Schulzrinne, et al. Standards Track [Page 19]
1068 RFC 3550 RTP July 2003
1071 critical to get feedback from the receivers to diagnose faults in
1072 the distribution. Sending reception feedback reports to all
1073 participants allows one who is observing problems to evaluate
1074 whether those problems are local or global. With a distribution
1075 mechanism like IP multicast, it is also possible for an entity
1076 such as a network service provider who is not otherwise involved
1077 in the session to receive the feedback information and act as a
1078 third-party monitor to diagnose network problems. This feedback
1079 function is performed by the RTCP sender and receiver reports,
1080 described below in Section 6.4.
1082 2. RTCP carries a persistent transport-level identifier for an RTP
1083 source called the canonical name or CNAME, Section 6.5.1. Since
1084 the SSRC identifier may change if a conflict is discovered or a
1085 program is restarted, receivers require the CNAME to keep track of
1086 each participant. Receivers may also require the CNAME to
1087 associate multiple data streams from a given participant in a set
1088 of related RTP sessions, for example to synchronize audio and
1089 video. Inter-media synchronization also requires the NTP and RTP
1090 timestamps included in RTCP packets by data senders.
1092 3. The first two functions require that all participants send RTCP
1093 packets, therefore the rate must be controlled in order for RTP to
1094 scale up to a large number of participants. By having each
1095 participant send its control packets to all the others, each can
1096 independently observe the number of participants. This number is
1097 used to calculate the rate at which the packets are sent, as
1098 explained in Section 6.2.
1100 4. A fourth, OPTIONAL function is to convey minimal session control
1101 information, for example participant identification to be
1102 displayed in the user interface. This is most likely to be useful
1103 in "loosely controlled" sessions where participants enter and
1104 leave without membership control or parameter negotiation. RTCP
1105 serves as a convenient channel to reach all the participants, but
1106 it is not necessarily expected to support all the control
1107 communication requirements of an application. A higher-level
1108 session control protocol, which is beyond the scope of this
1109 document, may be needed.
1111 Functions 1-3 SHOULD be used in all environments, but particularly in
1112 the IP multicast environment. RTP application designers SHOULD avoid
1113 mechanisms that can only work in unicast mode and will not scale to
1114 larger numbers. Transmission of RTCP MAY be controlled separately
1115 for senders and receivers, as described in Section 6.2, for cases
1116 such as unidirectional links where feedback from receivers is not
1122 Schulzrinne, et al. Standards Track [Page 20]
1124 RFC 3550 RTP July 2003
1127 Non-normative note: In the multicast routing approach
1128 called Source-Specific Multicast (SSM), there is only one sender
1129 per "channel" (a source address, group address pair), and
1130 receivers (except for the channel source) cannot use multicast to
1131 communicate directly with other channel members. The
1132 recommendations here accommodate SSM only through Section 6.2's
1133 option of turning off receivers' RTCP entirely. Future work will
1134 specify adaptation of RTCP for SSM so that feedback from receivers
1137 6.1 RTCP Packet Format
1139 This specification defines several RTCP packet types to carry a
1140 variety of control information:
1142 SR: Sender report, for transmission and reception statistics from
1143 participants that are active senders
1145 RR: Receiver report, for reception statistics from participants
1146 that are not active senders and in combination with SR for
1147 active senders reporting on more than 31 sources
1149 SDES: Source description items, including CNAME
1151 BYE: Indicates end of participation
1153 APP: Application-specific functions
1155 Each RTCP packet begins with a fixed part similar to that of RTP data
1156 packets, followed by structured elements that MAY be of variable
1157 length according to the packet type but MUST end on a 32-bit
1158 boundary. The alignment requirement and a length field in the fixed
1159 part of each packet are included to make RTCP packets "stackable".
1160 Multiple RTCP packets can be concatenated without any intervening
1161 separators to form a compound RTCP packet that is sent in a single
1162 packet of the lower layer protocol, for example UDP. There is no
1163 explicit count of individual RTCP packets in the compound packet
1164 since the lower layer protocols are expected to provide an overall
1165 length to determine the end of the compound packet.
1167 Each individual RTCP packet in the compound packet may be processed
1168 independently with no requirements upon the order or combination of
1169 packets. However, in order to perform the functions of the protocol,
1170 the following constraints are imposed:
1178 Schulzrinne, et al. Standards Track [Page 21]
1180 RFC 3550 RTP July 2003
1183 o Reception statistics (in SR or RR) should be sent as often as
1184 bandwidth constraints will allow to maximize the resolution of the
1185 statistics, therefore each periodically transmitted compound RTCP
1186 packet MUST include a report packet.
1188 o New receivers need to receive the CNAME for a source as soon as
1189 possible to identify the source and to begin associating media for
1190 purposes such as lip-sync, so each compound RTCP packet MUST also
1191 include the SDES CNAME except when the compound RTCP packet is
1192 split for partial encryption as described in Section 9.1.
1194 o The number of packet types that may appear first in the compound
1195 packet needs to be limited to increase the number of constant bits
1196 in the first word and the probability of successfully validating
1197 RTCP packets against misaddressed RTP data packets or other
1200 Thus, all RTCP packets MUST be sent in a compound packet of at least
1201 two individual packets, with the following format:
1203 Encryption prefix: If and only if the compound packet is to be
1204 encrypted according to the method in Section 9.1, it MUST be
1205 prefixed by a random 32-bit quantity redrawn for every compound
1206 packet transmitted. If padding is required for the encryption, it
1207 MUST be added to the last packet of the compound packet.
1209 SR or RR: The first RTCP packet in the compound packet MUST
1210 always be a report packet to facilitate header validation as
1211 described in Appendix A.2. This is true even if no data has been
1212 sent or received, in which case an empty RR MUST be sent, and even
1213 if the only other RTCP packet in the compound packet is a BYE.
1215 Additional RRs: If the number of sources for which reception
1216 statistics are being reported exceeds 31, the number that will fit
1217 into one SR or RR packet, then additional RR packets SHOULD follow
1218 the initial report packet.
1220 SDES: An SDES packet containing a CNAME item MUST be included
1221 in each compound RTCP packet, except as noted in Section 9.1.
1222 Other source description items MAY optionally be included if
1223 required by a particular application, subject to bandwidth
1224 constraints (see Section 6.3.9).
1226 BYE or APP: Other RTCP packet types, including those yet to be
1227 defined, MAY follow in any order, except that BYE SHOULD be the
1228 last packet sent with a given SSRC/CSRC. Packet types MAY appear
1234 Schulzrinne, et al. Standards Track [Page 22]
1236 RFC 3550 RTP July 2003
1239 An individual RTP participant SHOULD send only one compound RTCP
1240 packet per report interval in order for the RTCP bandwidth per
1241 participant to be estimated correctly (see Section 6.2), except when
1242 the compound RTCP packet is split for partial encryption as described
1243 in Section 9.1. If there are too many sources to fit all the
1244 necessary RR packets into one compound RTCP packet without exceeding
1245 the maximum transmission unit (MTU) of the network path, then only
1246 the subset that will fit into one MTU SHOULD be included in each
1247 interval. The subsets SHOULD be selected round-robin across multiple
1248 intervals so that all sources are reported.
1250 It is RECOMMENDED that translators and mixers combine individual RTCP
1251 packets from the multiple sources they are forwarding into one
1252 compound packet whenever feasible in order to amortize the packet
1253 overhead (see Section 7). An example RTCP compound packet as might
1254 be produced by a mixer is shown in Fig. 1. If the overall length of
1255 a compound packet would exceed the MTU of the network path, it SHOULD
1256 be segmented into multiple shorter compound packets to be transmitted
1257 in separate packets of the underlying protocol. This does not impair
1258 the RTCP bandwidth estimation because each compound packet represents
1259 at least one distinct participant. Note that each of the compound
1260 packets MUST begin with an SR or RR packet.
1262 An implementation SHOULD ignore incoming RTCP packets with types
1263 unknown to it. Additional RTCP packet types may be registered with
1264 the Internet Assigned Numbers Authority (IANA) as described in
1267 if encrypted: random 32-bit integer
1269 |[--------- packet --------][---------- packet ----------][-packet-]
1271 | receiver chunk chunk
1272 V reports item item item item
1273 --------------------------------------------------------------------
1274 R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
1275 --------------------------------------------------------------------
1277 |<----------------------- compound packet ----------------------->|
1278 |<-------------------------- UDP packet ------------------------->|
1280 #: SSRC/CSRC identifier
1282 Figure 1: Example of an RTCP compound packet
1290 Schulzrinne, et al. Standards Track [Page 23]
1292 RFC 3550 RTP July 2003
1295 6.2 RTCP Transmission Interval
1297 RTP is designed to allow an application to scale automatically over
1298 session sizes ranging from a few participants to thousands. For
1299 example, in an audio conference the data traffic is inherently self-
1300 limiting because only one or two people will speak at a time, so with
1301 multicast distribution the data rate on any given link remains
1302 relatively constant independent of the number of participants.
1303 However, the control traffic is not self-limiting. If the reception
1304 reports from each participant were sent at a constant rate, the
1305 control traffic would grow linearly with the number of participants.
1306 Therefore, the rate must be scaled down by dynamically calculating
1307 the interval between RTCP packet transmissions.
1309 For each session, it is assumed that the data traffic is subject to
1310 an aggregate limit called the "session bandwidth" to be divided among
1311 the participants. This bandwidth might be reserved and the limit
1312 enforced by the network. If there is no reservation, there may be
1313 other constraints, depending on the environment, that establish the
1314 "reasonable" maximum for the session to use, and that would be the
1315 session bandwidth. The session bandwidth may be chosen based on some
1316 cost or a priori knowledge of the available network bandwidth for the
1317 session. It is somewhat independent of the media encoding, but the
1318 encoding choice may be limited by the session bandwidth. Often, the
1319 session bandwidth is the sum of the nominal bandwidths of the senders
1320 expected to be concurrently active. For teleconference audio, this
1321 number would typically be one sender's bandwidth. For layered
1322 encodings, each layer is a separate RTP session with its own session
1323 bandwidth parameter.
1325 The session bandwidth parameter is expected to be supplied by a
1326 session management application when it invokes a media application,
1327 but media applications MAY set a default based on the single-sender
1328 data bandwidth for the encoding selected for the session. The
1329 application MAY also enforce bandwidth limits based on multicast
1330 scope rules or other criteria. All participants MUST use the same
1331 value for the session bandwidth so that the same RTCP interval will
1334 Bandwidth calculations for control and data traffic include lower-
1335 layer transport and network protocols (e.g., UDP and IP) since that
1336 is what the resource reservation system would need to know. The
1337 application can also be expected to know which of these protocols are
1338 in use. Link level headers are not included in the calculation since
1339 the packet will be encapsulated with different link level headers as
1346 Schulzrinne, et al. Standards Track [Page 24]
1348 RFC 3550 RTP July 2003
1351 The control traffic should be limited to a small and known fraction
1352 of the session bandwidth: small so that the primary function of the
1353 transport protocol to carry data is not impaired; known so that the
1354 control traffic can be included in the bandwidth specification given
1355 to a resource reservation protocol, and so that each participant can
1356 independently calculate its share. The control traffic bandwidth is
1357 in addition to the session bandwidth for the data traffic. It is
1358 RECOMMENDED that the fraction of the session bandwidth added for RTCP
1359 be fixed at 5%. It is also RECOMMENDED that 1/4 of the RTCP
1360 bandwidth be dedicated to participants that are sending data so that
1361 in sessions with a large number of receivers but a small number of
1362 senders, newly joining participants will more quickly receive the
1363 CNAME for the sending sites. When the proportion of senders is
1364 greater than 1/4 of the participants, the senders get their
1365 proportion of the full RTCP bandwidth. While the values of these and
1366 other constants in the interval calculation are not critical, all
1367 participants in the session MUST use the same values so the same
1368 interval will be calculated. Therefore, these constants SHOULD be
1369 fixed for a particular profile.
1371 A profile MAY specify that the control traffic bandwidth may be a
1372 separate parameter of the session rather than a strict percentage of
1373 the session bandwidth. Using a separate parameter allows rate-
1374 adaptive applications to set an RTCP bandwidth consistent with a
1375 "typical" data bandwidth that is lower than the maximum bandwidth
1376 specified by the session bandwidth parameter.
1378 The profile MAY further specify that the control traffic bandwidth
1379 may be divided into two separate session parameters for those
1380 participants which are active data senders and those which are not;
1381 let us call the parameters S and R. Following the recommendation
1382 that 1/4 of the RTCP bandwidth be dedicated to data senders, the
1383 RECOMMENDED default values for these two parameters would be 1.25%
1384 and 3.75%, respectively. When the proportion of senders is greater
1385 than S/(S+R) of the participants, the senders get their proportion of
1386 the sum of these parameters. Using two parameters allows RTCP
1387 reception reports to be turned off entirely for a particular session
1388 by setting the RTCP bandwidth for non-data-senders to zero while
1389 keeping the RTCP bandwidth for data senders non-zero so that sender
1390 reports can still be sent for inter-media synchronization. Turning
1391 off RTCP reception reports is NOT RECOMMENDED because they are needed
1392 for the functions listed at the beginning of Section 6, particularly
1393 reception quality feedback and congestion control. However, doing so
1394 may be appropriate for systems operating on unidirectional links or
1395 for sessions that don't require feedback on the quality of reception
1396 or liveness of receivers and that have other means to avoid
1402 Schulzrinne, et al. Standards Track [Page 25]
1404 RFC 3550 RTP July 2003
1407 The calculated interval between transmissions of compound RTCP
1408 packets SHOULD also have a lower bound to avoid having bursts of
1409 packets exceed the allowed bandwidth when the number of participants
1410 is small and the traffic isn't smoothed according to the law of large
1411 numbers. It also keeps the report interval from becoming too small
1412 during transient outages like a network partition such that
1413 adaptation is delayed when the partition heals. At application
1414 startup, a delay SHOULD be imposed before the first compound RTCP
1415 packet is sent to allow time for RTCP packets to be received from
1416 other participants so the report interval will converge to the
1417 correct value more quickly. This delay MAY be set to half the
1418 minimum interval to allow quicker notification that the new
1419 participant is present. The RECOMMENDED value for a fixed minimum
1420 interval is 5 seconds.
1422 An implementation MAY scale the minimum RTCP interval to a smaller
1423 value inversely proportional to the session bandwidth parameter with
1424 the following limitations:
1426 o For multicast sessions, only active data senders MAY use the
1427 reduced minimum value to calculate the interval for transmission
1428 of compound RTCP packets.
1430 o For unicast sessions, the reduced value MAY be used by
1431 participants that are not active data senders as well, and the
1432 delay before sending the initial compound RTCP packet MAY be zero.
1434 o For all sessions, the fixed minimum SHOULD be used when
1435 calculating the participant timeout interval (see Section 6.3.5)
1436 so that implementations which do not use the reduced value for
1437 transmitting RTCP packets are not timed out by other participants
1440 o The RECOMMENDED value for the reduced minimum in seconds is 360
1441 divided by the session bandwidth in kilobits/second. This minimum
1442 is smaller than 5 seconds for bandwidths greater than 72 kb/s.
1444 The algorithm described in Section 6.3 and Appendix A.7 was designed
1445 to meet the goals outlined in this section. It calculates the
1446 interval between sending compound RTCP packets to divide the allowed
1447 control traffic bandwidth among the participants. This allows an
1448 application to provide fast response for small sessions where, for
1449 example, identification of all participants is important, yet
1450 automatically adapt to large sessions. The algorithm incorporates
1451 the following characteristics:
1458 Schulzrinne, et al. Standards Track [Page 26]
1460 RFC 3550 RTP July 2003
1463 o The calculated interval between RTCP packets scales linearly with
1464 the number of members in the group. It is this linear factor
1465 which allows for a constant amount of control traffic when summed
1468 o The interval between RTCP packets is varied randomly over the
1469 range [0.5,1.5] times the calculated interval to avoid unintended
1470 synchronization of all participants [20]. The first RTCP packet
1471 sent after joining a session is also delayed by a random variation
1472 of half the minimum RTCP interval.
1474 o A dynamic estimate of the average compound RTCP packet size is
1475 calculated, including all those packets received and sent, to
1476 automatically adapt to changes in the amount of control
1477 information carried.
1479 o Since the calculated interval is dependent on the number of
1480 observed group members, there may be undesirable startup effects
1481 when a new user joins an existing session, or many users
1482 simultaneously join a new session. These new users will initially
1483 have incorrect estimates of the group membership, and thus their
1484 RTCP transmission interval will be too short. This problem can be
1485 significant if many users join the session simultaneously. To
1486 deal with this, an algorithm called "timer reconsideration" is
1487 employed. This algorithm implements a simple back-off mechanism
1488 which causes users to hold back RTCP packet transmission if the
1489 group sizes are increasing.
1491 o When users leave a session, either with a BYE or by timeout, the
1492 group membership decreases, and thus the calculated interval
1493 should decrease. A "reverse reconsideration" algorithm is used to
1494 allow members to more quickly reduce their intervals in response
1495 to group membership decreases.
1497 o BYE packets are given different treatment than other RTCP packets.
1498 When a user leaves a group, and wishes to send a BYE packet, it
1499 may do so before its next scheduled RTCP packet. However,
1500 transmission of BYEs follows a back-off algorithm which avoids
1501 floods of BYE packets should a large number of members
1502 simultaneously leave the session.
1504 This algorithm may be used for sessions in which all participants are
1505 allowed to send. In that case, the session bandwidth parameter is
1506 the product of the individual sender's bandwidth times the number of
1507 participants, and the RTCP bandwidth is 5% of that.
1509 Details of the algorithm's operation are given in the sections that
1510 follow. Appendix A.7 gives an example implementation.
1514 Schulzrinne, et al. Standards Track [Page 27]
1516 RFC 3550 RTP July 2003
1519 6.2.1 Maintaining the Number of Session Members
1521 Calculation of the RTCP packet interval depends upon an estimate of
1522 the number of sites participating in the session. New sites are
1523 added to the count when they are heard, and an entry for each SHOULD
1524 be created in a table indexed by the SSRC or CSRC identifier (see
1525 Section 8.2) to keep track of them. New entries MAY be considered
1526 not valid until multiple packets carrying the new SSRC have been
1527 received (see Appendix A.1), or until an SDES RTCP packet containing
1528 a CNAME for that SSRC has been received. Entries MAY be deleted from
1529 the table when an RTCP BYE packet with the corresponding SSRC
1530 identifier is received, except that some straggler data packets might
1531 arrive after the BYE and cause the entry to be recreated. Instead,
1532 the entry SHOULD be marked as having received a BYE and then deleted
1533 after an appropriate delay.
1535 A participant MAY mark another site inactive, or delete it if not yet
1536 valid, if no RTP or RTCP packet has been received for a small number
1537 of RTCP report intervals (5 is RECOMMENDED). This provides some
1538 robustness against packet loss. All sites must have the same value
1539 for this multiplier and must calculate roughly the same value for the
1540 RTCP report interval in order for this timeout to work properly.
1541 Therefore, this multiplier SHOULD be fixed for a particular profile.
1543 For sessions with a very large number of participants, it may be
1544 impractical to maintain a table to store the SSRC identifier and
1545 state information for all of them. An implementation MAY use SSRC
1546 sampling, as described in [21], to reduce the storage requirements.
1547 An implementation MAY use any other algorithm with similar
1548 performance. A key requirement is that any algorithm considered
1549 SHOULD NOT substantially underestimate the group size, although it
1552 6.3 RTCP Packet Send and Receive Rules
1554 The rules for how to send, and what to do when receiving an RTCP
1555 packet are outlined here. An implementation that allows operation in
1556 a multicast environment or a multipoint unicast environment MUST meet
1557 the requirements in Section 6.2. Such an implementation MAY use the
1558 algorithm defined in this section to meet those requirements, or MAY
1559 use some other algorithm so long as it provides equivalent or better
1560 performance. An implementation which is constrained to two-party
1561 unicast operation SHOULD still use randomization of the RTCP
1562 transmission interval to avoid unintended synchronization of multiple
1563 instances operating in the same environment, but MAY omit the "timer
1564 reconsideration" and "reverse reconsideration" algorithms in Sections
1565 6.3.3, 6.3.6 and 6.3.7.
1570 Schulzrinne, et al. Standards Track [Page 28]
1572 RFC 3550 RTP July 2003
1575 To execute these rules, a session participant must maintain several
1578 tp: the last time an RTCP packet was transmitted;
1580 tc: the current time;
1582 tn: the next scheduled transmission time of an RTCP packet;
1584 pmembers: the estimated number of session members at the time tn
1585 was last recomputed;
1587 members: the most current estimate for the number of session
1590 senders: the most current estimate for the number of senders in
1593 rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth
1594 that will be used for RTCP packets by all members of this session,
1595 in octets per second. This will be a specified fraction of the
1596 "session bandwidth" parameter supplied to the application at
1599 we_sent: Flag that is true if the application has sent data
1600 since the 2nd previous RTCP report was transmitted.
1602 avg_rtcp_size: The average compound RTCP packet size, in octets,
1603 over all RTCP packets sent and received by this participant. The
1604 size includes lower-layer transport and network protocol headers
1605 (e.g., UDP and IP) as explained in Section 6.2.
1607 initial: Flag that is true if the application has not yet sent
1610 Many of these rules make use of the "calculated interval" between
1611 packet transmissions. This interval is described in the following
1614 6.3.1 Computing the RTCP Transmission Interval
1616 To maintain scalability, the average interval between packets from a
1617 session participant should scale with the group size. This interval
1618 is called the calculated interval. It is obtained by combining a
1619 number of the pieces of state described above. The calculated
1620 interval T is then determined as follows:
1626 Schulzrinne, et al. Standards Track [Page 29]
1628 RFC 3550 RTP July 2003
1631 1. If the number of senders is less than or equal to 25% of the
1632 membership (members), the interval depends on whether the
1633 participant is a sender or not (based on the value of we_sent).
1634 If the participant is a sender (we_sent true), the constant C is
1635 set to the average RTCP packet size (avg_rtcp_size) divided by 25%
1636 of the RTCP bandwidth (rtcp_bw), and the constant n is set to the
1637 number of senders. If we_sent is not true, the constant C is set
1638 to the average RTCP packet size divided by 75% of the RTCP
1639 bandwidth. The constant n is set to the number of receivers
1640 (members - senders). If the number of senders is greater than
1641 25%, senders and receivers are treated together. The constant C
1642 is set to the average RTCP packet size divided by the total RTCP
1643 bandwidth and n is set to the total number of members. As stated
1644 in Section 6.2, an RTP profile MAY specify that the RTCP bandwidth
1645 may be explicitly defined by two separate parameters (call them S
1646 and R) for those participants which are senders and those which
1647 are not. In that case, the 25% fraction becomes S/(S+R) and the
1648 75% fraction becomes R/(S+R). Note that if R is zero, the
1649 percentage of senders is never greater than S/(S+R), and the
1650 implementation must avoid division by zero.
1652 2. If the participant has not yet sent an RTCP packet (the variable
1653 initial is true), the constant Tmin is set to 2.5 seconds, else it
1654 is set to 5 seconds.
1656 3. The deterministic calculated interval Td is set to max(Tmin, n*C).
1658 4. The calculated interval T is set to a number uniformly distributed
1659 between 0.5 and 1.5 times the deterministic calculated interval.
1661 5. The resulting value of T is divided by e-3/2=1.21828 to compensate
1662 for the fact that the timer reconsideration algorithm converges to
1663 a value of the RTCP bandwidth below the intended average.
1665 This procedure results in an interval which is random, but which, on
1666 average, gives at least 25% of the RTCP bandwidth to senders and the
1667 rest to receivers. If the senders constitute more than one quarter
1668 of the membership, this procedure splits the bandwidth equally among
1669 all participants, on average.
1671 6.3.2 Initialization
1673 Upon joining the session, the participant initializes tp to 0, tc to
1674 0, senders to 0, pmembers to 1, members to 1, we_sent to false,
1675 rtcp_bw to the specified fraction of the session bandwidth, initial
1676 to true, and avg_rtcp_size to the probable size of the first RTCP
1677 packet that the application will later construct. The calculated
1678 interval T is then computed, and the first packet is scheduled for
1682 Schulzrinne, et al. Standards Track [Page 30]
1684 RFC 3550 RTP July 2003
1687 time tn = T. This means that a transmission timer is set which
1688 expires at time T. Note that an application MAY use any desired
1689 approach for implementing this timer.
1691 The participant adds its own SSRC to the member table.
1693 6.3.3 Receiving an RTP or Non-BYE RTCP Packet
1695 When an RTP or RTCP packet is received from a participant whose SSRC
1696 is not in the member table, the SSRC is added to the table, and the
1697 value for members is updated once the participant has been validated
1698 as described in Section 6.2.1. The same processing occurs for each
1699 CSRC in a validated RTP packet.
1701 When an RTP packet is received from a participant whose SSRC is not
1702 in the sender table, the SSRC is added to the table, and the value
1703 for senders is updated.
1705 For each compound RTCP packet received, the value of avg_rtcp_size is
1708 avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
1710 where packet_size is the size of the RTCP packet just received.
1712 6.3.4 Receiving an RTCP BYE Packet
1714 Except as described in Section 6.3.7 for the case when an RTCP BYE is
1715 to be transmitted, if the received packet is an RTCP BYE packet, the
1716 SSRC is checked against the member table. If present, the entry is
1717 removed from the table, and the value for members is updated. The
1718 SSRC is then checked against the sender table. If present, the entry
1719 is removed from the table, and the value for senders is updated.
1721 Furthermore, to make the transmission rate of RTCP packets more
1722 adaptive to changes in group membership, the following "reverse
1723 reconsideration" algorithm SHOULD be executed when a BYE packet is
1724 received that reduces members to a value less than pmembers:
1726 o The value for tn is updated according to the following formula:
1728 tn = tc + (members/pmembers) * (tn - tc)
1730 o The value for tp is updated according the following formula:
1732 tp = tc - (members/pmembers) * (tc - tp).
1738 Schulzrinne, et al. Standards Track [Page 31]
1740 RFC 3550 RTP July 2003
1743 o The next RTCP packet is rescheduled for transmission at time tn,
1744 which is now earlier.
1746 o The value of pmembers is set equal to members.
1748 This algorithm does not prevent the group size estimate from
1749 incorrectly dropping to zero for a short time due to premature
1750 timeouts when most participants of a large session leave at once but
1751 some remain. The algorithm does make the estimate return to the
1752 correct value more rapidly. This situation is unusual enough and the
1753 consequences are sufficiently harmless that this problem is deemed
1754 only a secondary concern.
1756 6.3.5 Timing Out an SSRC
1758 At occasional intervals, the participant MUST check to see if any of
1759 the other participants time out. To do this, the participant
1760 computes the deterministic (without the randomization factor)
1761 calculated interval Td for a receiver, that is, with we_sent false.
1762 Any other session member who has not sent an RTP or RTCP packet since
1763 time tc - MTd (M is the timeout multiplier, and defaults to 5) is
1764 timed out. This means that its SSRC is removed from the member list,
1765 and members is updated. A similar check is performed on the sender
1766 list. Any member on the sender list who has not sent an RTP packet
1767 since time tc - 2T (within the last two RTCP report intervals) is
1768 removed from the sender list, and senders is updated.
1770 If any members time out, the reverse reconsideration algorithm
1771 described in Section 6.3.4 SHOULD be performed.
1773 The participant MUST perform this check at least once per RTCP
1774 transmission interval.
1776 6.3.6 Expiration of Transmission Timer
1778 When the packet transmission timer expires, the participant performs
1779 the following operations:
1781 o The transmission interval T is computed as described in Section
1782 6.3.1, including the randomization factor.
1784 o If tp + T is less than or equal to tc, an RTCP packet is
1785 transmitted. tp is set to tc, then another value for T is
1786 calculated as in the previous step and tn is set to tc + T. The
1787 transmission timer is set to expire again at time tn. If tp + T
1788 is greater than tc, tn is set to tp + T. No RTCP packet is
1789 transmitted. The transmission timer is set to expire at time tn.
1794 Schulzrinne, et al. Standards Track [Page 32]
1796 RFC 3550 RTP July 2003
1799 o pmembers is set to members.
1801 If an RTCP packet is transmitted, the value of initial is set to
1802 FALSE. Furthermore, the value of avg_rtcp_size is updated:
1804 avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
1806 where packet_size is the size of the RTCP packet just transmitted.
1808 6.3.7 Transmitting a BYE Packet
1810 When a participant wishes to leave a session, a BYE packet is
1811 transmitted to inform the other participants of the event. In order
1812 to avoid a flood of BYE packets when many participants leave the
1813 system, a participant MUST execute the following algorithm if the
1814 number of members is more than 50 when the participant chooses to
1815 leave. This algorithm usurps the normal role of the members variable
1816 to count BYE packets instead:
1818 o When the participant decides to leave the system, tp is reset to
1819 tc, the current time, members and pmembers are initialized to 1,
1820 initial is set to 1, we_sent is set to false, senders is set to 0,
1821 and avg_rtcp_size is set to the size of the compound BYE packet.
1822 The calculated interval T is computed. The BYE packet is then
1823 scheduled for time tn = tc + T.
1825 o Every time a BYE packet from another participant is received,
1826 members is incremented by 1 regardless of whether that participant
1827 exists in the member table or not, and when SSRC sampling is in
1828 use, regardless of whether or not the BYE SSRC would be included
1829 in the sample. members is NOT incremented when other RTCP packets
1830 or RTP packets are received, but only for BYE packets. Similarly,
1831 avg_rtcp_size is updated only for received BYE packets. senders
1832 is NOT updated when RTP packets arrive; it remains 0.
1834 o Transmission of the BYE packet then follows the rules for
1835 transmitting a regular RTCP packet, as above.
1837 This allows BYE packets to be sent right away, yet controls their
1838 total bandwidth usage. In the worst case, this could cause RTCP
1839 control packets to use twice the bandwidth as normal (10%) -- 5% for
1840 non-BYE RTCP packets and 5% for BYE.
1842 A participant that does not want to wait for the above mechanism to
1843 allow transmission of a BYE packet MAY leave the group without
1844 sending a BYE at all. That participant will eventually be timed out
1845 by the other group members.
1850 Schulzrinne, et al. Standards Track [Page 33]
1852 RFC 3550 RTP July 2003
1855 If the group size estimate members is less than 50 when the
1856 participant decides to leave, the participant MAY send a BYE packet
1857 immediately. Alternatively, the participant MAY choose to execute
1858 the above BYE backoff algorithm.
1860 In either case, a participant which never sent an RTP or RTCP packet
1861 MUST NOT send a BYE packet when they leave the group.
1863 6.3.8 Updating we_sent
1865 The variable we_sent contains true if the participant has sent an RTP
1866 packet recently, false otherwise. This determination is made by
1867 using the same mechanisms as for managing the set of other
1868 participants listed in the senders table. If the participant sends
1869 an RTP packet when we_sent is false, it adds itself to the sender
1870 table and sets we_sent to true. The reverse reconsideration
1871 algorithm described in Section 6.3.4 SHOULD be performed to possibly
1872 reduce the delay before sending an SR packet. Every time another RTP
1873 packet is sent, the time of transmission of that packet is maintained
1874 in the table. The normal sender timeout algorithm is then applied to
1875 the participant -- if an RTP packet has not been transmitted since
1876 time tc - 2T, the participant removes itself from the sender table,
1877 decrements the sender count, and sets we_sent to false.
1879 6.3.9 Allocation of Source Description Bandwidth
1881 This specification defines several source description (SDES) items in
1882 addition to the mandatory CNAME item, such as NAME (personal name)
1883 and EMAIL (email address). It also provides a means to define new
1884 application-specific RTCP packet types. Applications should exercise
1885 caution in allocating control bandwidth to this additional
1886 information because it will slow down the rate at which reception
1887 reports and CNAME are sent, thus impairing the performance of the
1888 protocol. It is RECOMMENDED that no more than 20% of the RTCP
1889 bandwidth allocated to a single participant be used to carry the
1890 additional information. Furthermore, it is not intended that all
1891 SDES items will be included in every application. Those that are
1892 included SHOULD be assigned a fraction of the bandwidth according to
1893 their utility. Rather than estimate these fractions dynamically, it
1894 is recommended that the percentages be translated statically into
1895 report interval counts based on the typical length of an item.
1897 For example, an application may be designed to send only CNAME, NAME
1898 and EMAIL and not any others. NAME might be given much higher
1899 priority than EMAIL because the NAME would be displayed continuously
1900 in the application's user interface, whereas EMAIL would be displayed
1901 only when requested. At every RTCP interval, an RR packet and an
1902 SDES packet with the CNAME item would be sent. For a small session
1906 Schulzrinne, et al. Standards Track [Page 34]
1908 RFC 3550 RTP July 2003
1911 operating at the minimum interval, that would be every 5 seconds on
1912 the average. Every third interval (15 seconds), one extra item would
1913 be included in the SDES packet. Seven out of eight times this would
1914 be the NAME item, and every eighth time (2 minutes) it would be the
1917 When multiple applications operate in concert using cross-application
1918 binding through a common CNAME for each participant, for example in a
1919 multimedia conference composed of an RTP session for each medium, the
1920 additional SDES information MAY be sent in only one RTP session. The
1921 other sessions would carry only the CNAME item. In particular, this
1922 approach should be applied to the multiple sessions of a layered
1923 encoding scheme (see Section 2.4).
1925 6.4 Sender and Receiver Reports
1927 RTP receivers provide reception quality feedback using RTCP report
1928 packets which may take one of two forms depending upon whether or not
1929 the receiver is also a sender. The only difference between the
1930 sender report (SR) and receiver report (RR) forms, besides the packet
1931 type code, is that the sender report includes a 20-byte sender
1932 information section for use by active senders. The SR is issued if a
1933 site has sent any data packets during the interval since issuing the
1934 last report or the previous one, otherwise the RR is issued.
1936 Both the SR and RR forms include zero or more reception report
1937 blocks, one for each of the synchronization sources from which this
1938 receiver has received RTP data packets since the last report.
1939 Reports are not issued for contributing sources listed in the CSRC
1940 list. Each reception report block provides statistics about the data
1941 received from the particular source indicated in that block. Since a
1942 maximum of 31 reception report blocks will fit in an SR or RR packet,
1943 additional RR packets SHOULD be stacked after the initial SR or RR
1944 packet as needed to contain the reception reports for all sources
1945 heard during the interval since the last report. If there are too
1946 many sources to fit all the necessary RR packets into one compound
1947 RTCP packet without exceeding the MTU of the network path, then only
1948 the subset that will fit into one MTU SHOULD be included in each
1949 interval. The subsets SHOULD be selected round-robin across multiple
1950 intervals so that all sources are reported.
1952 The next sections define the formats of the two reports, how they may
1953 be extended in a profile-specific manner if an application requires
1954 additional feedback information, and how the reports may be used.
1955 Details of reception reporting by translators and mixers is given in
1962 Schulzrinne, et al. Standards Track [Page 35]
1964 RFC 3550 RTP July 2003
1967 6.4.1 SR: Sender Report RTCP Packet
1970 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1972 header |V=2|P| RC | PT=SR=200 | length |
1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1975 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
1976 sender | NTP timestamp, most significant word |
1977 info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1978 | NTP timestamp, least significant word |
1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1982 | sender's packet count |
1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1984 | sender's octet count |
1985 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
1986 report | SSRC_1 (SSRC of first source) |
1987 block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1988 1 | fraction lost | cumulative number of packets lost |
1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1990 | extended highest sequence number received |
1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1992 | interarrival jitter |
1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1996 | delay since last SR (DLSR) |
1997 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
1998 report | SSRC_2 (SSRC of second source) |
1999 block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2001 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2002 | profile-specific extensions |
2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2005 The sender report packet consists of three sections, possibly
2006 followed by a fourth profile-specific extension section if defined.
2007 The first section, the header, is 8 octets long. The fields have the
2011 Identifies the version of RTP, which is the same in RTCP packets
2012 as in RTP data packets. The version defined by this specification
2018 Schulzrinne, et al. Standards Track [Page 36]
2020 RFC 3550 RTP July 2003
2024 If the padding bit is set, this individual RTCP packet contains
2025 some additional padding octets at the end which are not part of
2026 the control information but are included in the length field. The
2027 last octet of the padding is a count of how many padding octets
2028 should be ignored, including itself (it will be a multiple of
2029 four). Padding may be needed by some encryption algorithms with
2030 fixed block sizes. In a compound RTCP packet, padding is only
2031 required on one individual packet because the compound packet is
2032 encrypted as a whole for the method in Section 9.1. Thus, padding
2033 MUST only be added to the last individual packet, and if padding
2034 is added to that packet, the padding bit MUST be set only on that
2035 packet. This convention aids the header validity checks described
2036 in Appendix A.2 and allows detection of packets from some early
2037 implementations that incorrectly set the padding bit on the first
2038 individual packet and add padding to the last individual packet.
2040 reception report count (RC): 5 bits
2041 The number of reception report blocks contained in this packet. A
2042 value of zero is valid.
2044 packet type (PT): 8 bits
2045 Contains the constant 200 to identify this as an RTCP SR packet.
2048 The length of this RTCP packet in 32-bit words minus one,
2049 including the header and any padding. (The offset of one makes
2050 zero a valid length and avoids a possible infinite loop in
2051 scanning a compound RTCP packet, while counting 32-bit words
2052 avoids a validity check for a multiple of 4.)
2055 The synchronization source identifier for the originator of this
2058 The second section, the sender information, is 20 octets long and is
2059 present in every sender report packet. It summarizes the data
2060 transmissions from this sender. The fields have the following
2063 NTP timestamp: 64 bits
2064 Indicates the wallclock time (see Section 4) when this report was
2065 sent so that it may be used in combination with timestamps
2066 returned in reception reports from other receivers to measure
2067 round-trip propagation to those receivers. Receivers should
2068 expect that the measurement accuracy of the timestamp may be
2069 limited to far less than the resolution of the NTP timestamp. The
2070 measurement uncertainty of the timestamp is not indicated as it
2074 Schulzrinne, et al. Standards Track [Page 37]
2076 RFC 3550 RTP July 2003
2079 may not be known. On a system that has no notion of wallclock
2080 time but does have some system-specific clock such as "system
2081 uptime", a sender MAY use that clock as a reference to calculate
2082 relative NTP timestamps. It is important to choose a commonly
2083 used clock so that if separate implementations are used to produce
2084 the individual streams of a multimedia session, all
2085 implementations will use the same clock. Until the year 2036,
2086 relative and absolute timestamps will differ in the high bit so
2087 (invalid) comparisons will show a large difference; by then one
2088 hopes relative timestamps will no longer be needed. A sender that
2089 has no notion of wallclock or elapsed time MAY set the NTP
2092 RTP timestamp: 32 bits
2093 Corresponds to the same time as the NTP timestamp (above), but in
2094 the same units and with the same random offset as the RTP
2095 timestamps in data packets. This correspondence may be used for
2096 intra- and inter-media synchronization for sources whose NTP
2097 timestamps are synchronized, and may be used by media-independent
2098 receivers to estimate the nominal RTP clock frequency. Note that
2099 in most cases this timestamp will not be equal to the RTP
2100 timestamp in any adjacent data packet. Rather, it MUST be
2101 calculated from the corresponding NTP timestamp using the
2102 relationship between the RTP timestamp counter and real time as
2103 maintained by periodically checking the wallclock time at a
2106 sender's packet count: 32 bits
2107 The total number of RTP data packets transmitted by the sender
2108 since starting transmission up until the time this SR packet was
2109 generated. The count SHOULD be reset if the sender changes its
2112 sender's octet count: 32 bits
2113 The total number of payload octets (i.e., not including header or
2114 padding) transmitted in RTP data packets by the sender since
2115 starting transmission up until the time this SR packet was
2116 generated. The count SHOULD be reset if the sender changes its
2117 SSRC identifier. This field can be used to estimate the average
2120 The third section contains zero or more reception report blocks
2121 depending on the number of other sources heard by this sender since
2122 the last report. Each reception report block conveys statistics on
2123 the reception of RTP packets from a single synchronization source.
2124 Receivers SHOULD NOT carry over statistics when a source changes its
2125 SSRC identifier due to a collision. These statistics are:
2130 Schulzrinne, et al. Standards Track [Page 38]
2132 RFC 3550 RTP July 2003
2135 SSRC_n (source identifier): 32 bits
2136 The SSRC identifier of the source to which the information in this
2137 reception report block pertains.
2139 fraction lost: 8 bits
2140 The fraction of RTP data packets from source SSRC_n lost since the
2141 previous SR or RR packet was sent, expressed as a fixed point
2142 number with the binary point at the left edge of the field. (That
2143 is equivalent to taking the integer part after multiplying the
2144 loss fraction by 256.) This fraction is defined to be the number
2145 of packets lost divided by the number of packets expected, as
2146 defined in the next paragraph. An implementation is shown in
2147 Appendix A.3. If the loss is negative due to duplicates, the
2148 fraction lost is set to zero. Note that a receiver cannot tell
2149 whether any packets were lost after the last one received, and
2150 that there will be no reception report block issued for a source
2151 if all packets from that source sent during the last reporting
2152 interval have been lost.
2154 cumulative number of packets lost: 24 bits
2155 The total number of RTP data packets from source SSRC_n that have
2156 been lost since the beginning of reception. This number is
2157 defined to be the number of packets expected less the number of
2158 packets actually received, where the number of packets received
2159 includes any which are late or duplicates. Thus, packets that
2160 arrive late are not counted as lost, and the loss may be negative
2161 if there are duplicates. The number of packets expected is
2162 defined to be the extended last sequence number received, as
2163 defined next, less the initial sequence number received. This may
2164 be calculated as shown in Appendix A.3.
2166 extended highest sequence number received: 32 bits
2167 The low 16 bits contain the highest sequence number received in an
2168 RTP data packet from source SSRC_n, and the most significant 16
2169 bits extend that sequence number with the corresponding count of
2170 sequence number cycles, which may be maintained according to the
2171 algorithm in Appendix A.1. Note that different receivers within
2172 the same session will generate different extensions to the
2173 sequence number if their start times differ significantly.
2175 interarrival jitter: 32 bits
2176 An estimate of the statistical variance of the RTP data packet
2177 interarrival time, measured in timestamp units and expressed as an
2178 unsigned integer. The interarrival jitter J is defined to be the
2179 mean deviation (smoothed absolute value) of the difference D in
2180 packet spacing at the receiver compared to the sender for a pair
2181 of packets. As shown in the equation below, this is equivalent to
2182 the difference in the "relative transit time" for the two packets;
2186 Schulzrinne, et al. Standards Track [Page 39]
2188 RFC 3550 RTP July 2003
2191 the relative transit time is the difference between a packet's RTP
2192 timestamp and the receiver's clock at the time of arrival,
2193 measured in the same units.
2195 If Si is the RTP timestamp from packet i, and Ri is the time of
2196 arrival in RTP timestamp units for packet i, then for two packets
2197 i and j, D may be expressed as
2199 D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
2201 The interarrival jitter SHOULD be calculated continuously as each
2202 data packet i is received from source SSRC_n, using this
2203 difference D for that packet and the previous packet i-1 in order
2204 of arrival (not necessarily in sequence), according to the formula
2206 J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
2208 Whenever a reception report is issued, the current value of J is
2211 The jitter calculation MUST conform to the formula specified here
2212 in order to allow profile-independent monitors to make valid
2213 interpretations of reports coming from different implementations.
2214 This algorithm is the optimal first-order estimator and the gain
2215 parameter 1/16 gives a good noise reduction ratio while
2216 maintaining a reasonable rate of convergence [22]. A sample
2217 implementation is shown in Appendix A.8. See Section 6.4.4 for a
2218 discussion of the effects of varying packet duration and delay
2219 before transmission.
2221 last SR timestamp (LSR): 32 bits
2222 The middle 32 bits out of 64 in the NTP timestamp (as explained in
2223 Section 4) received as part of the most recent RTCP sender report
2224 (SR) packet from source SSRC_n. If no SR has been received yet,
2225 the field is set to zero.
2227 delay since last SR (DLSR): 32 bits
2228 The delay, expressed in units of 1/65536 seconds, between
2229 receiving the last SR packet from source SSRC_n and sending this
2230 reception report block. If no SR packet has been received yet
2231 from SSRC_n, the DLSR field is set to zero.
2233 Let SSRC_r denote the receiver issuing this receiver report.
2234 Source SSRC_n can compute the round-trip propagation delay to
2235 SSRC_r by recording the time A when this reception report block is
2236 received. It calculates the total round-trip time A-LSR using the
2237 last SR timestamp (LSR) field, and then subtracting this field to
2238 leave the round-trip propagation delay as (A - LSR - DLSR). This
2242 Schulzrinne, et al. Standards Track [Page 40]
2244 RFC 3550 RTP July 2003
2247 is illustrated in Fig. 2. Times are shown in both a hexadecimal
2248 representation of the 32-bit fields and the equivalent floating-
2249 point decimal representation. Colons indicate a 32-bit field
2250 divided into a 16-bit integer part and 16-bit fraction part.
2252 This may be used as an approximate measure of distance to cluster
2253 receivers, although some links have very asymmetric delays.
2255 [10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC]
2256 n SR(n) A=b710:8000 (46864.500 s)
2257 ---------------------------------------------------------------->
2259 ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s)
2260 ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
2261 (3024992005.125 s) v ^
2263 ---------------------------------------------------------------->
2267 A 0xb710:8000 (46864.500 s)
2268 DLSR -0x0005:4000 ( 5.250 s)
2269 LSR -0xb705:2000 (46853.125 s)
2270 -------------------------------
2271 delay 0x0006:2000 ( 6.125 s)
2273 Figure 2: Example for round-trip time computation
2298 Schulzrinne, et al. Standards Track [Page 41]
2300 RFC 3550 RTP July 2003
2303 6.4.2 RR: Receiver Report RTCP Packet
2306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2308 header |V=2|P| RC | PT=RR=201 | length |
2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2310 | SSRC of packet sender |
2311 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2312 report | SSRC_1 (SSRC of first source) |
2313 block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2314 1 | fraction lost | cumulative number of packets lost |
2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2316 | extended highest sequence number received |
2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2318 | interarrival jitter |
2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2322 | delay since last SR (DLSR) |
2323 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2324 report | SSRC_2 (SSRC of second source) |
2325 block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2327 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2328 | profile-specific extensions |
2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2331 The format of the receiver report (RR) packet is the same as that of
2332 the SR packet except that the packet type field contains the constant
2333 201 and the five words of sender information are omitted (these are
2334 the NTP and RTP timestamps and sender's packet and octet counts).
2335 The remaining fields have the same meaning as for the SR packet.
2337 An empty RR packet (RC = 0) MUST be put at the head of a compound
2338 RTCP packet when there is no data transmission or reception to
2341 6.4.3 Extending the Sender and Receiver Reports
2343 A profile SHOULD define profile-specific extensions to the sender
2344 report and receiver report if there is additional information that
2345 needs to be reported regularly about the sender or receivers. This
2346 method SHOULD be used in preference to defining another RTCP packet
2347 type because it requires less overhead:
2349 o fewer octets in the packet (no RTCP header or SSRC field);
2354 Schulzrinne, et al. Standards Track [Page 42]
2356 RFC 3550 RTP July 2003
2359 o simpler and faster parsing because applications running under that
2360 profile would be programmed to always expect the extension fields
2361 in the directly accessible location after the reception reports.
2363 The extension is a fourth section in the sender- or receiver-report
2364 packet which comes at the end after the reception report blocks, if
2365 any. If additional sender information is required, then for sender
2366 reports it would be included first in the extension section, but for
2367 receiver reports it would not be present. If information about
2368 receivers is to be included, that data SHOULD be structured as an
2369 array of blocks parallel to the existing array of reception report
2370 blocks; that is, the number of blocks would be indicated by the RC
2373 6.4.4 Analyzing Sender and Receiver Reports
2375 It is expected that reception quality feedback will be useful not
2376 only for the sender but also for other receivers and third-party
2377 monitors. The sender may modify its transmissions based on the
2378 feedback; receivers can determine whether problems are local,
2379 regional or global; network managers may use profile-independent
2380 monitors that receive only the RTCP packets and not the corresponding
2381 RTP data packets to evaluate the performance of their networks for
2382 multicast distribution.
2384 Cumulative counts are used in both the sender information and
2385 receiver report blocks so that differences may be calculated between
2386 any two reports to make measurements over both short and long time
2387 periods, and to provide resilience against the loss of a report. The
2388 difference between the last two reports received can be used to
2389 estimate the recent quality of the distribution. The NTP timestamp
2390 is included so that rates may be calculated from these differences
2391 over the interval between two reports. Since that timestamp is
2392 independent of the clock rate for the data encoding, it is possible
2393 to implement encoding- and profile-independent quality monitors.
2395 An example calculation is the packet loss rate over the interval
2396 between two reception reports. The difference in the cumulative
2397 number of packets lost gives the number lost during that interval.
2398 The difference in the extended last sequence numbers received gives
2399 the number of packets expected during the interval. The ratio of
2400 these two is the packet loss fraction over the interval. This ratio
2401 should equal the fraction lost field if the two reports are
2402 consecutive, but otherwise it may not. The loss rate per second can
2403 be obtained by dividing the loss fraction by the difference in NTP
2404 timestamps, expressed in seconds. The number of packets received is
2405 the number of packets expected minus the number lost. The number of
2410 Schulzrinne, et al. Standards Track [Page 43]
2412 RFC 3550 RTP July 2003
2415 packets expected may also be used to judge the statistical validity
2416 of any loss estimates. For example, 1 out of 5 packets lost has a
2417 lower significance than 200 out of 1000.
2419 From the sender information, a third-party monitor can calculate the
2420 average payload data rate and the average packet rate over an
2421 interval without receiving the data. Taking the ratio of the two
2422 gives the average payload size. If it can be assumed that packet
2423 loss is independent of packet size, then the number of packets
2424 received by a particular receiver times the average payload size (or
2425 the corresponding packet size) gives the apparent throughput
2426 available to that receiver.
2428 In addition to the cumulative counts which allow long-term packet
2429 loss measurements using differences between reports, the fraction
2430 lost field provides a short-term measurement from a single report.
2431 This becomes more important as the size of a session scales up enough
2432 that reception state information might not be kept for all receivers
2433 or the interval between reports becomes long enough that only one
2434 report might have been received from a particular receiver.
2436 The interarrival jitter field provides a second short-term measure of
2437 network congestion. Packet loss tracks persistent congestion while
2438 the jitter measure tracks transient congestion. The jitter measure
2439 may indicate congestion before it leads to packet loss. The
2440 interarrival jitter field is only a snapshot of the jitter at the
2441 time of a report and is not intended to be taken quantitatively.
2442 Rather, it is intended for comparison across a number of reports from
2443 one receiver over time or from multiple receivers, e.g., within a
2444 single network, at the same time. To allow comparison across
2445 receivers, it is important the the jitter be calculated according to
2446 the same formula by all receivers.
2448 Because the jitter calculation is based on the RTP timestamp which
2449 represents the instant when the first data in the packet was sampled,
2450 any variation in the delay between that sampling instant and the time
2451 the packet is transmitted will affect the resulting jitter that is
2452 calculated. Such a variation in delay would occur for audio packets
2453 of varying duration. It will also occur for video encodings because
2454 the timestamp is the same for all the packets of one frame but those
2455 packets are not all transmitted at the same time. The variation in
2456 delay until transmission does reduce the accuracy of the jitter
2457 calculation as a measure of the behavior of the network by itself,
2458 but it is appropriate to include considering that the receiver buffer
2459 must accommodate it. When the jitter calculation is used as a
2460 comparative measure, the (constant) component due to variation in
2461 delay until transmission subtracts out so that a change in the
2466 Schulzrinne, et al. Standards Track [Page 44]
2468 RFC 3550 RTP July 2003
2471 network jitter component can then be observed unless it is relatively
2472 small. If the change is small, then it is likely to be
2475 6.5 SDES: Source Description RTCP Packet
2478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2480 header |V=2|P| SC | PT=SDES=202 | length |
2481 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2482 chunk | SSRC/CSRC_1 |
2483 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2486 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2487 chunk | SSRC/CSRC_2 |
2488 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2491 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2493 The SDES packet is a three-level structure composed of a header and
2494 zero or more chunks, each of which is composed of items describing
2495 the source identified in that chunk. The items are described
2496 individually in subsequent sections.
2498 version (V), padding (P), length:
2499 As described for the SR packet (see Section 6.4.1).
2501 packet type (PT): 8 bits
2502 Contains the constant 202 to identify this as an RTCP SDES packet.
2504 source count (SC): 5 bits
2505 The number of SSRC/CSRC chunks contained in this SDES packet. A
2506 value of zero is valid but useless.
2508 Each chunk consists of an SSRC/CSRC identifier followed by a list of
2509 zero or more items, which carry information about the SSRC/CSRC.
2510 Each chunk starts on a 32-bit boundary. Each item consists of an 8-
2511 bit type field, an 8-bit octet count describing the length of the
2512 text (thus, not including this two-octet header), and the text
2513 itself. Note that the text can be no longer than 255 octets, but
2514 this is consistent with the need to limit RTCP bandwidth consumption.
2522 Schulzrinne, et al. Standards Track [Page 45]
2524 RFC 3550 RTP July 2003
2527 The text is encoded according to the UTF-8 encoding specified in RFC
2528 2279 [5]. US-ASCII is a subset of this encoding and requires no
2529 additional encoding. The presence of multi-octet encodings is
2530 indicated by setting the most significant bit of a character to a
2533 Items are contiguous, i.e., items are not individually padded to a
2534 32-bit boundary. Text is not null terminated because some multi-
2535 octet encodings include null octets. The list of items in each chunk
2536 MUST be terminated by one or more null octets, the first of which is
2537 interpreted as an item type of zero to denote the end of the list.
2538 No length octet follows the null item type octet, but additional null
2539 octets MUST be included if needed to pad until the next 32-bit
2540 boundary. Note that this padding is separate from that indicated by
2541 the P bit in the RTCP header. A chunk with zero items (four null
2542 octets) is valid but useless.
2544 End systems send one SDES packet containing their own source
2545 identifier (the same as the SSRC in the fixed RTP header). A mixer
2546 sends one SDES packet containing a chunk for each contributing source
2547 from which it is receiving SDES information, or multiple complete
2548 SDES packets in the format above if there are more than 31 such
2549 sources (see Section 7).
2551 The SDES items currently defined are described in the next sections.
2552 Only the CNAME item is mandatory. Some items shown here may be
2553 useful only for particular profiles, but the item types are all
2554 assigned from one common space to promote shared use and to simplify
2555 profile-independent applications. Additional items may be defined in
2556 a profile by registering the type numbers with IANA as described in
2559 6.5.1 CNAME: Canonical End-Point Identifier SDES Item
2562 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2564 | CNAME=1 | length | user and domain name ...
2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2567 The CNAME identifier has the following properties:
2569 o Because the randomly allocated SSRC identifier may change if a
2570 conflict is discovered or if a program is restarted, the CNAME
2571 item MUST be included to provide the binding from the SSRC
2572 identifier to an identifier for the source (sender or receiver)
2573 that remains constant.
2578 Schulzrinne, et al. Standards Track [Page 46]
2580 RFC 3550 RTP July 2003
2583 o Like the SSRC identifier, the CNAME identifier SHOULD also be
2584 unique among all participants within one RTP session.
2586 o To provide a binding across multiple media tools used by one
2587 participant in a set of related RTP sessions, the CNAME SHOULD be
2588 fixed for that participant.
2590 o To facilitate third-party monitoring, the CNAME SHOULD be suitable
2591 for either a program or a person to locate the source.
2593 Therefore, the CNAME SHOULD be derived algorithmically and not
2594 entered manually, when possible. To meet these requirements, the
2595 following format SHOULD be used unless a profile specifies an
2596 alternate syntax or semantics. The CNAME item SHOULD have the format
2597 "user@host", or "host" if a user name is not available as on single-
2598 user systems. For both formats, "host" is either the fully qualified
2599 domain name of the host from which the real-time data originates,
2600 formatted according to the rules specified in RFC 1034 [6], RFC 1035
2601 [7] and Section 2.1 of RFC 1123 [8]; or the standard ASCII
2602 representation of the host's numeric address on the interface used
2603 for the RTP communication. For example, the standard ASCII
2604 representation of an IP Version 4 address is "dotted decimal", also
2605 known as dotted quad, and for IP Version 6, addresses are textually
2606 represented as groups of hexadecimal digits separated by colons (with
2607 variations as detailed in RFC 3513 [23]). Other address types are
2608 expected to have ASCII representations that are mutually unique. The
2609 fully qualified domain name is more convenient for a human observer
2610 and may avoid the need to send a NAME item in addition, but it may be
2611 difficult or impossible to obtain reliably in some operating
2612 environments. Applications that may be run in such environments
2613 SHOULD use the ASCII representation of the address instead.
2615 Examples are "doe@sleepy.example.com", "doe@192.0.2.89" or
2616 "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system
2617 with no user name, examples would be "sleepy.example.com",
2618 "192.0.2.89" or "2201:056D::112E:144A:1E24".
2620 The user name SHOULD be in a form that a program such as "finger" or
2621 "talk" could use, i.e., it typically is the login name rather than
2622 the personal name. The host name is not necessarily identical to the
2623 one in the participant's electronic mail address.
2625 This syntax will not provide unique identifiers for each source if an
2626 application permits a user to generate multiple sources from one
2627 host. Such an application would have to rely on the SSRC to further
2628 identify the source, or the profile for that application would have
2629 to specify additional syntax for the CNAME identifier.
2634 Schulzrinne, et al. Standards Track [Page 47]
2636 RFC 3550 RTP July 2003
2639 If each application creates its CNAME independently, the resulting
2640 CNAMEs may not be identical as would be required to provide a binding
2641 across multiple media tools belonging to one participant in a set of
2642 related RTP sessions. If cross-media binding is required, it may be
2643 necessary for the CNAME of each tool to be externally configured with
2644 the same value by a coordination tool.
2646 Application writers should be aware that private network address
2647 assignments such as the Net-10 assignment proposed in RFC 1918 [24]
2648 may create network addresses that are not globally unique. This
2649 would lead to non-unique CNAMEs if hosts with private addresses and
2650 no direct IP connectivity to the public Internet have their RTP
2651 packets forwarded to the public Internet through an RTP-level
2652 translator. (See also RFC 1627 [25].) To handle this case,
2653 applications MAY provide a means to configure a unique CNAME, but the
2654 burden is on the translator to translate CNAMEs from private
2655 addresses to public addresses if necessary to keep private addresses
2658 6.5.2 NAME: User Name SDES Item
2661 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2663 | NAME=2 | length | common name of source ...
2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2666 This is the real name used to describe the source, e.g., "John Doe,
2667 Bit Recycler". It may be in any form desired by the user. For
2668 applications such as conferencing, this form of name may be the most
2669 desirable for display in participant lists, and therefore might be
2670 sent most frequently of those items other than CNAME. Profiles MAY
2671 establish such priorities. The NAME value is expected to remain
2672 constant at least for the duration of a session. It SHOULD NOT be
2673 relied upon to be unique among all participants in the session.
2675 6.5.3 EMAIL: Electronic Mail Address SDES Item
2678 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2680 | EMAIL=3 | length | email address of source ...
2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2683 The email address is formatted according to RFC 2822 [9], for
2684 example, "John.Doe@example.com". The EMAIL value is expected to
2685 remain constant for the duration of a session.
2690 Schulzrinne, et al. Standards Track [Page 48]
2692 RFC 3550 RTP July 2003
2695 6.5.4 PHONE: Phone Number SDES Item
2698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2700 | PHONE=4 | length | phone number of source ...
2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2703 The phone number SHOULD be formatted with the plus sign replacing the
2704 international access code. For example, "+1 908 555 1212" for a
2705 number in the United States.
2707 6.5.5 LOC: Geographic User Location SDES Item
2710 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2712 | LOC=5 | length | geographic location of site ...
2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2715 Depending on the application, different degrees of detail are
2716 appropriate for this item. For conference applications, a string
2717 like "Murray Hill, New Jersey" may be sufficient, while, for an
2718 active badge system, strings like "Room 2A244, AT&T BL MH" might be
2719 appropriate. The degree of detail is left to the implementation
2720 and/or user, but format and content MAY be prescribed by a profile.
2721 The LOC value is expected to remain constant for the duration of a
2722 session, except for mobile hosts.
2724 6.5.6 TOOL: Application or Tool Name SDES Item
2727 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2729 | TOOL=6 | length |name/version of source appl. ...
2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2732 A string giving the name and possibly version of the application
2733 generating the stream, e.g., "videotool 1.2". This information may
2734 be useful for debugging purposes and is similar to the Mailer or
2735 Mail-System-Version SMTP headers. The TOOL value is expected to
2736 remain constant for the duration of the session.
2746 Schulzrinne, et al. Standards Track [Page 49]
2748 RFC 3550 RTP July 2003
2751 6.5.7 NOTE: Notice/Status SDES Item
2754 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2756 | NOTE=7 | length | note about the source ...
2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2759 The following semantics are suggested for this item, but these or
2760 other semantics MAY be explicitly defined by a profile. The NOTE
2761 item is intended for transient messages describing the current state
2762 of the source, e.g., "on the phone, can't talk". Or, during a
2763 seminar, this item might be used to convey the title of the talk. It
2764 should be used only to carry exceptional information and SHOULD NOT
2765 be included routinely by all participants because this would slow
2766 down the rate at which reception reports and CNAME are sent, thus
2767 impairing the performance of the protocol. In particular, it SHOULD
2768 NOT be included as an item in a user's configuration file nor
2769 automatically generated as in a quote-of-the-day.
2771 Since the NOTE item may be important to display while it is active,
2772 the rate at which other non-CNAME items such as NAME are transmitted
2773 might be reduced so that the NOTE item can take that part of the RTCP
2774 bandwidth. When the transient message becomes inactive, the NOTE
2775 item SHOULD continue to be transmitted a few times at the same
2776 repetition rate but with a string of length zero to signal the
2777 receivers. However, receivers SHOULD also consider the NOTE item
2778 inactive if it is not received for a small multiple of the repetition
2779 rate, or perhaps 20-30 RTCP intervals.
2781 6.5.8 PRIV: Private Extensions SDES Item
2784 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2786 | PRIV=8 | length | prefix length |prefix string...
2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2788 ... | value string ...
2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2791 This item is used to define experimental or application-specific SDES
2792 extensions. The item contains a prefix consisting of a length-string
2793 pair, followed by the value string filling the remainder of the item
2794 and carrying the desired information. The prefix length field is 8
2795 bits long. The prefix string is a name chosen by the person defining
2796 the PRIV item to be unique with respect to other PRIV items this
2797 application might receive. The application creator might choose to
2798 use the application name plus an additional subtype identification if
2802 Schulzrinne, et al. Standards Track [Page 50]
2804 RFC 3550 RTP July 2003
2807 needed. Alternatively, it is RECOMMENDED that others choose a name
2808 based on the entity they represent, then coordinate the use of the
2809 name within that entity.
2811 Note that the prefix consumes some space within the item's total
2812 length of 255 octets, so the prefix should be kept as short as
2813 possible. This facility and the constrained RTCP bandwidth SHOULD
2814 NOT be overloaded; it is not intended to satisfy all the control
2815 communication requirements of all applications.
2817 SDES PRIV prefixes will not be registered by IANA. If some form of
2818 the PRIV item proves to be of general utility, it SHOULD instead be
2819 assigned a regular SDES item type registered with IANA so that no
2820 prefix is required. This simplifies use and increases transmission
2823 6.6 BYE: Goodbye RTCP Packet
2826 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2828 |V=2|P| SC | PT=BYE=203 | length |
2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2833 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
2834 (opt) | length | reason for leaving ...
2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2837 The BYE packet indicates that one or more sources are no longer
2840 version (V), padding (P), length:
2841 As described for the SR packet (see Section 6.4.1).
2843 packet type (PT): 8 bits
2844 Contains the constant 203 to identify this as an RTCP BYE packet.
2846 source count (SC): 5 bits
2847 The number of SSRC/CSRC identifiers included in this BYE packet.
2848 A count value of zero is valid, but useless.
2850 The rules for when a BYE packet should be sent are specified in
2851 Sections 6.3.7 and 8.2.
2858 Schulzrinne, et al. Standards Track [Page 51]
2860 RFC 3550 RTP July 2003
2863 If a BYE packet is received by a mixer, the mixer SHOULD forward the
2864 BYE packet with the SSRC/CSRC identifier(s) unchanged. If a mixer
2865 shuts down, it SHOULD send a BYE packet listing all contributing
2866 sources it handles, as well as its own SSRC identifier. Optionally,
2867 the BYE packet MAY include an 8-bit octet count followed by that many
2868 octets of text indicating the reason for leaving, e.g., "camera
2869 malfunction" or "RTP loop detected". The string has the same
2870 encoding as that described for SDES. If the string fills the packet
2871 to the next 32-bit boundary, the string is not null terminated. If
2872 not, the BYE packet MUST be padded with null octets to the next 32-
2873 bit boundary. This padding is separate from that indicated by the P
2874 bit in the RTCP header.
2876 6.7 APP: Application-Defined RTCP Packet
2879 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2881 |V=2|P| subtype | PT=APP=204 | length |
2882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2887 | application-dependent data ...
2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2890 The APP packet is intended for experimental use as new applications
2891 and new features are developed, without requiring packet type value
2892 registration. APP packets with unrecognized names SHOULD be ignored.
2893 After testing and if wider use is justified, it is RECOMMENDED that
2894 each APP packet be redefined without the subtype and name fields and
2895 registered with IANA using an RTCP packet type.
2897 version (V), padding (P), length:
2898 As described for the SR packet (see Section 6.4.1).
2901 May be used as a subtype to allow a set of APP packets to be
2902 defined under one unique name, or for any application-dependent
2905 packet type (PT): 8 bits
2906 Contains the constant 204 to identify this as an RTCP APP packet.
2914 Schulzrinne, et al. Standards Track [Page 52]
2916 RFC 3550 RTP July 2003
2920 A name chosen by the person defining the set of APP packets to be
2921 unique with respect to other APP packets this application might
2922 receive. The application creator might choose to use the
2923 application name, and then coordinate the allocation of subtype
2924 values to others who want to define new packet types for the
2925 application. Alternatively, it is RECOMMENDED that others choose
2926 a name based on the entity they represent, then coordinate the use
2927 of the name within that entity. The name is interpreted as a
2928 sequence of four ASCII characters, with uppercase and lowercase
2929 characters treated as distinct.
2931 application-dependent data: variable length
2932 Application-dependent data may or may not appear in an APP packet.
2933 It is interpreted by the application and not RTP itself. It MUST
2934 be a multiple of 32 bits long.
2936 7. RTP Translators and Mixers
2938 In addition to end systems, RTP supports the notion of "translators"
2939 and "mixers", which could be considered as "intermediate systems" at
2940 the RTP level. Although this support adds some complexity to the
2941 protocol, the need for these functions has been clearly established
2942 by experiments with multicast audio and video applications in the
2943 Internet. Example uses of translators and mixers given in Section
2944 2.3 stem from the presence of firewalls and low bandwidth
2945 connections, both of which are likely to remain.
2947 7.1 General Description
2949 An RTP translator/mixer connects two or more transport-level
2950 "clouds". Typically, each cloud is defined by a common network and
2951 transport protocol (e.g., IP/UDP) plus a multicast address and
2952 transport level destination port or a pair of unicast addresses and
2953 ports. (Network-level protocol translators, such as IP version 4 to
2954 IP version 6, may be present within a cloud invisibly to RTP.) One
2955 system may serve as a translator or mixer for a number of RTP
2956 sessions, but each is considered a logically separate entity.
2958 In order to avoid creating a loop when a translator or mixer is
2959 installed, the following rules MUST be observed:
2961 o Each of the clouds connected by translators and mixers
2962 participating in one RTP session either MUST be distinct from all
2963 the others in at least one of these parameters (protocol, address,
2964 port), or MUST be isolated at the network level from the others.
2970 Schulzrinne, et al. Standards Track [Page 53]
2972 RFC 3550 RTP July 2003
2975 o A derivative of the first rule is that there MUST NOT be multiple
2976 translators or mixers connected in parallel unless by some
2977 arrangement they partition the set of sources to be forwarded.
2979 Similarly, all RTP end systems that can communicate through one or
2980 more RTP translators or mixers share the same SSRC space, that is,
2981 the SSRC identifiers MUST be unique among all these end systems.
2982 Section 8.2 describes the collision resolution algorithm by which
2983 SSRC identifiers are kept unique and loops are detected.
2985 There may be many varieties of translators and mixers designed for
2986 different purposes and applications. Some examples are to add or
2987 remove encryption, change the encoding of the data or the underlying
2988 protocols, or replicate between a multicast address and one or more
2989 unicast addresses. The distinction between translators and mixers is
2990 that a translator passes through the data streams from different
2991 sources separately, whereas a mixer combines them to form one new
2994 Translator: Forwards RTP packets with their SSRC identifier
2995 intact; this makes it possible for receivers to identify
2996 individual sources even though packets from all the sources pass
2997 through the same translator and carry the translator's network
2998 source address. Some kinds of translators will pass through the
2999 data untouched, but others MAY change the encoding of the data and
3000 thus the RTP data payload type and timestamp. If multiple data
3001 packets are re-encoded into one, or vice versa, a translator MUST
3002 assign new sequence numbers to the outgoing packets. Losses in
3003 the incoming packet stream may induce corresponding gaps in the
3004 outgoing sequence numbers. Receivers cannot detect the presence
3005 of a translator unless they know by some other means what payload
3006 type or transport address was used by the original source.
3008 Mixer: Receives streams of RTP data packets from one or more
3009 sources, possibly changes the data format, combines the streams in
3010 some manner and then forwards the combined stream. Since the
3011 timing among multiple input sources will not generally be
3012 synchronized, the mixer will make timing adjustments among the
3013 streams and generate its own timing for the combined stream, so it
3014 is the synchronization source. Thus, all data packets forwarded
3015 by a mixer MUST be marked with the mixer's own SSRC identifier.
3016 In order to preserve the identity of the original sources
3017 contributing to the mixed packet, the mixer SHOULD insert their
3018 SSRC identifiers into the CSRC identifier list following the fixed
3019 RTP header of the packet. A mixer that is also itself a
3020 contributing source for some packet SHOULD explicitly include its
3021 own SSRC identifier in the CSRC list for that packet.
3026 Schulzrinne, et al. Standards Track [Page 54]
3028 RFC 3550 RTP July 2003
3031 For some applications, it MAY be acceptable for a mixer not to
3032 identify sources in the CSRC list. However, this introduces the
3033 danger that loops involving those sources could not be detected.
3035 The advantage of a mixer over a translator for applications like
3036 audio is that the output bandwidth is limited to that of one source
3037 even when multiple sources are active on the input side. This may be
3038 important for low-bandwidth links. The disadvantage is that
3039 receivers on the output side don't have any control over which
3040 sources are passed through or muted, unless some mechanism is
3041 implemented for remote control of the mixer. The regeneration of
3042 synchronization information by mixers also means that receivers can't
3043 do inter-media synchronization of the original streams. A multi-
3044 media mixer could do it.
3050 V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
3051 (M1)-------------><T1>-----------------><T2>-------------->[E7]
3053 E2:1 | E4:47 | | M3:89 (64,45)
3055 [E2] [E4] M3:89 (64,45) |
3057 [E3] --------->(M2)----------->(M3)------------| [End system]
3058 E3:64 M2:12 (64) ^ (Mixer)
3059 | E5:45 <Translator>
3061 [E5] source: SSRC (CSRCs)
3062 ------------------->
3064 Figure 3: Sample RTP network with end systems, mixers and translators
3066 A collection of mixers and translators is shown in Fig. 3 to
3067 illustrate their effect on SSRC and CSRC identifiers. In the figure,
3068 end systems are shown as rectangles (named E), translators as
3069 triangles (named T) and mixers as ovals (named M). The notation "M1:
3070 48(1,17)" designates a packet originating a mixer M1, identified by
3071 M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17,
3072 copied from the SSRC identifiers of packets from E1 and E2.
3074 7.2 RTCP Processing in Translators
3076 In addition to forwarding data packets, perhaps modified, translators
3077 and mixers MUST also process RTCP packets. In many cases, they will
3078 take apart the compound RTCP packets received from end systems to
3082 Schulzrinne, et al. Standards Track [Page 55]
3084 RFC 3550 RTP July 2003
3087 aggregate SDES information and to modify the SR or RR packets.
3088 Retransmission of this information may be triggered by the packet
3089 arrival or by the RTCP interval timer of the translator or mixer
3092 A translator that does not modify the data packets, for example one
3093 that just replicates between a multicast address and a unicast
3094 address, MAY simply forward RTCP packets unmodified as well. A
3095 translator that transforms the payload in some way MUST make
3096 corresponding transformations in the SR and RR information so that it
3097 still reflects the characteristics of the data and the reception
3098 quality. These translators MUST NOT simply forward RTCP packets. In
3099 general, a translator SHOULD NOT aggregate SR and RR packets from
3100 different sources into one packet since that would reduce the
3101 accuracy of the propagation delay measurements based on the LSR and
3104 SR sender information: A translator does not generate its own
3105 sender information, but forwards the SR packets received from one
3106 cloud to the others. The SSRC is left intact but the sender
3107 information MUST be modified if required by the translation. If a
3108 translator changes the data encoding, it MUST change the "sender's
3109 byte count" field. If it also combines several data packets into
3110 one output packet, it MUST change the "sender's packet count"
3111 field. If it changes the timestamp frequency, it MUST change the
3112 "RTP timestamp" field in the SR packet.
3114 SR/RR reception report blocks: A translator forwards reception
3115 reports received from one cloud to the others. Note that these
3116 flow in the direction opposite to the data. The SSRC is left
3117 intact. If a translator combines several data packets into one
3118 output packet, and therefore changes the sequence numbers, it MUST
3119 make the inverse manipulation for the packet loss fields and the
3120 "extended last sequence number" field. This may be complex. In
3121 the extreme case, there may be no meaningful way to translate the
3122 reception reports, so the translator MAY pass on no reception
3123 report at all or a synthetic report based on its own reception.
3124 The general rule is to do what makes sense for a particular
3127 A translator does not require an SSRC identifier of its own, but
3128 MAY choose to allocate one for the purpose of sending reports
3129 about what it has received. These would be sent to all the
3130 connected clouds, each corresponding to the translation of the
3131 data stream as sent to that cloud, since reception reports are
3132 normally multicast to all participants.
3138 Schulzrinne, et al. Standards Track [Page 56]
3140 RFC 3550 RTP July 2003
3143 SDES: Translators typically forward without change the SDES
3144 information they receive from one cloud to the others, but MAY,
3145 for example, decide to filter non-CNAME SDES information if
3146 bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC
3147 identifier collision detection to work. A translator that
3148 generates its own RR packets MUST send SDES CNAME information
3149 about itself to the same clouds that it sends those RR packets.
3151 BYE: Translators forward BYE packets unchanged. A translator
3152 that is about to cease forwarding packets SHOULD send a BYE packet
3153 to each connected cloud containing all the SSRC identifiers that
3154 were previously being forwarded to that cloud, including the
3155 translator's own SSRC identifier if it sent reports of its own.
3157 APP: Translators forward APP packets unchanged.
3159 7.3 RTCP Processing in Mixers
3161 Since a mixer generates a new data stream of its own, it does not
3162 pass through SR or RR packets at all and instead generates new
3163 information for both sides.
3165 SR sender information: A mixer does not pass through sender
3166 information from the sources it mixes because the characteristics
3167 of the source streams are lost in the mix. As a synchronization
3168 source, the mixer SHOULD generate its own SR packets with sender
3169 information about the mixed data stream and send them in the same
3170 direction as the mixed stream.
3172 SR/RR reception report blocks: A mixer generates its own
3173 reception reports for sources in each cloud and sends them out
3174 only to the same cloud. It MUST NOT send these reception reports
3175 to the other clouds and MUST NOT forward reception reports from
3176 one cloud to the others because the sources would not be SSRCs
3179 SDES: Mixers typically forward without change the SDES
3180 information they receive from one cloud to the others, but MAY,
3181 for example, decide to filter non-CNAME SDES information if
3182 bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC
3183 identifier collision detection to work. (An identifier in a CSRC
3184 list generated by a mixer might collide with an SSRC identifier
3185 generated by an end system.) A mixer MUST send SDES CNAME
3186 information about itself to the same clouds that it sends SR or RR
3194 Schulzrinne, et al. Standards Track [Page 57]
3196 RFC 3550 RTP July 2003
3199 Since mixers do not forward SR or RR packets, they will typically
3200 be extracting SDES packets from a compound RTCP packet. To
3201 minimize overhead, chunks from the SDES packets MAY be aggregated
3202 into a single SDES packet which is then stacked on an SR or RR
3203 packet originating from the mixer. A mixer which aggregates SDES
3204 packets will use more RTCP bandwidth than an individual source
3205 because the compound packets will be longer, but that is
3206 appropriate since the mixer represents multiple sources.
3207 Similarly, a mixer which passes through SDES packets as they are
3208 received will be transmitting RTCP packets at higher than the
3209 single source rate, but again that is correct since the packets
3210 come from multiple sources. The RTCP packet rate may be different
3211 on each side of the mixer.
3213 A mixer that does not insert CSRC identifiers MAY also refrain
3214 from forwarding SDES CNAMEs. In this case, the SSRC identifier
3215 spaces in the two clouds are independent. As mentioned earlier,
3216 this mode of operation creates a danger that loops can't be
3219 BYE: Mixers MUST forward BYE packets. A mixer that is about to
3220 cease forwarding packets SHOULD send a BYE packet to each
3221 connected cloud containing all the SSRC identifiers that were
3222 previously being forwarded to that cloud, including the mixer's
3223 own SSRC identifier if it sent reports of its own.
3225 APP: The treatment of APP packets by mixers is application-specific.
3229 An RTP session may involve a collection of mixers and translators as
3230 shown in Fig. 3. If two mixers are cascaded, such as M2 and M3 in
3231 the figure, packets received by a mixer may already have been mixed
3232 and may include a CSRC list with multiple identifiers. The second
3233 mixer SHOULD build the CSRC list for the outgoing packet using the
3234 CSRC identifiers from already-mixed input packets and the SSRC
3235 identifiers from unmixed input packets. This is shown in the output
3236 arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case
3237 of mixers that are not cascaded, if the resulting CSRC list has more
3238 than 15 identifiers, the remainder cannot be included.
3250 Schulzrinne, et al. Standards Track [Page 58]
3252 RFC 3550 RTP July 2003
3255 8. SSRC Identifier Allocation and Use
3257 The SSRC identifier carried in the RTP header and in various fields
3258 of RTCP packets is a random 32-bit number that is required to be
3259 globally unique within an RTP session. It is crucial that the number
3260 be chosen with care in order that participants on the same network or
3261 starting at the same time are not likely to choose the same number.
3263 It is not sufficient to use the local network address (such as an
3264 IPv4 address) for the identifier because the address may not be
3265 unique. Since RTP translators and mixers enable interoperation among
3266 multiple networks with different address spaces, the allocation
3267 patterns for addresses within two spaces might result in a much
3268 higher rate of collision than would occur with random allocation.
3270 Multiple sources running on one host would also conflict.
3272 It is also not sufficient to obtain an SSRC identifier simply by
3273 calling random() without carefully initializing the state. An
3274 example of how to generate a random identifier is presented in
3277 8.1 Probability of Collision
3279 Since the identifiers are chosen randomly, it is possible that two or
3280 more sources will choose the same number. Collision occurs with the
3281 highest probability when all sources are started simultaneously, for
3282 example when triggered automatically by some session management
3283 event. If N is the number of sources and L the length of the
3284 identifier (here, 32 bits), the probability that two sources
3285 independently pick the same value can be approximated for large N
3286 [26] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is
3289 The typical collision probability is much lower than the worst-case
3290 above. When one new source joins an RTP session in which all the
3291 other sources already have unique identifiers, the probability of
3292 collision is just the fraction of numbers used out of the space.
3293 Again, if N is the number of sources and L the length of the
3294 identifier, the probability of collision is N / 2**L. For N=1000,
3295 the probability is roughly 2*10**-7.
3297 The probability of collision is further reduced by the opportunity
3298 for a new source to receive packets from other participants before
3299 sending its first packet (either data or control). If the new source
3300 keeps track of the other participants (by SSRC identifier), then
3306 Schulzrinne, et al. Standards Track [Page 59]
3308 RFC 3550 RTP July 2003
3311 before transmitting its first packet the new source can verify that
3312 its identifier does not conflict with any that have been received, or
3315 8.2 Collision Resolution and Loop Detection
3317 Although the probability of SSRC identifier collision is low, all RTP
3318 implementations MUST be prepared to detect collisions and take the
3319 appropriate actions to resolve them. If a source discovers at any
3320 time that another source is using the same SSRC identifier as its
3321 own, it MUST send an RTCP BYE packet for the old identifier and
3322 choose another random one. (As explained below, this step is taken
3323 only once in case of a loop.) If a receiver discovers that two other
3324 sources are colliding, it MAY keep the packets from one and discard
3325 the packets from the other when this can be detected by different
3326 source transport addresses or CNAMEs. The two sources are expected
3327 to resolve the collision so that the situation doesn't last.
3329 Because the random SSRC identifiers are kept globally unique for each
3330 RTP session, they can also be used to detect loops that may be
3331 introduced by mixers or translators. A loop causes duplication of
3332 data and control information, either unmodified or possibly mixed, as
3333 in the following examples:
3335 o A translator may incorrectly forward a packet to the same
3336 multicast group from which it has received the packet, either
3337 directly or through a chain of translators. In that case, the
3338 same packet appears several times, originating from different
3341 o Two translators incorrectly set up in parallel, i.e., with the
3342 same multicast groups on both sides, would both forward packets
3343 from one multicast group to the other. Unidirectional translators
3344 would produce two copies; bidirectional translators would form a
3347 o A mixer can close a loop by sending to the same transport
3348 destination upon which it receives packets, either directly or
3349 through another mixer or translator. In this case a source might
3350 show up both as an SSRC on a data packet and a CSRC in a mixed
3353 A source may discover that its own packets are being looped, or that
3354 packets from another source are being looped (a third-party loop).
3355 Both loops and collisions in the random selection of a source
3356 identifier result in packets arriving with the same SSRC identifier
3357 but a different source transport address, which may be that of the
3358 end system originating the packet or an intermediate system.
3362 Schulzrinne, et al. Standards Track [Page 60]
3364 RFC 3550 RTP July 2003
3367 Therefore, if a source changes its source transport address, it MAY
3368 also choose a new SSRC identifier to avoid being interpreted as a
3369 looped source. (This is not MUST because in some applications of RTP
3370 sources may be expected to change addresses during a session.) Note
3371 that if a translator restarts and consequently changes the source
3372 transport address (e.g., changes the UDP source port number) on which
3373 it forwards packets, then all those packets will appear to receivers
3374 to be looped because the SSRC identifiers are applied by the original
3375 source and will not change. This problem can be avoided by keeping
3376 the source transport address fixed across restarts, but in any case
3377 will be resolved after a timeout at the receivers.
3379 Loops or collisions occurring on the far side of a translator or
3380 mixer cannot be detected using the source transport address if all
3381 copies of the packets go through the translator or mixer, however,
3382 collisions may still be detected when chunks from two RTCP SDES
3383 packets contain the same SSRC identifier but different CNAMEs.
3385 To detect and resolve these conflicts, an RTP implementation MUST
3386 include an algorithm similar to the one described below, though the
3387 implementation MAY choose a different policy for which packets from
3388 colliding third-party sources are kept. The algorithm described
3389 below ignores packets from a new source or loop that collide with an
3390 established source. It resolves collisions with the participant's
3391 own SSRC identifier by sending an RTCP BYE for the old identifier and
3392 choosing a new one. However, when the collision was induced by a
3393 loop of the participant's own packets, the algorithm will choose a
3394 new identifier only once and thereafter ignore packets from the
3395 looping source transport address. This is required to avoid a flood
3398 This algorithm requires keeping a table indexed by the source
3399 identifier and containing the source transport addresses from the
3400 first RTP packet and first RTCP packet received with that identifier,
3401 along with other state for that source. Two source transport
3402 addresses are required since, for example, the UDP source port
3403 numbers may be different on RTP and RTCP packets. However, it may be
3404 assumed that the network address is the same in both source transport
3407 Each SSRC or CSRC identifier received in an RTP or RTCP packet is
3408 looked up in the source identifier table in order to process that
3409 data or control information. The source transport address from the
3410 packet is compared to the corresponding source transport address in
3411 the table to detect a loop or collision if they don't match. For
3412 control packets, each element with its own SSRC identifier, for
3413 example an SDES chunk, requires a separate lookup. (The SSRC
3414 identifier in a reception report block is an exception because it
3418 Schulzrinne, et al. Standards Track [Page 61]
3420 RFC 3550 RTP July 2003
3423 identifies a source heard by the reporter, and that SSRC identifier
3424 is unrelated to the source transport address of the RTCP packet sent
3425 by the reporter.) If the SSRC or CSRC is not found, a new entry is
3426 created. These table entries are removed when an RTCP BYE packet is
3427 received with the corresponding SSRC identifier and validated by a
3428 matching source transport address, or after no packets have arrived
3429 for a relatively long time (see Section 6.2.1).
3431 Note that if two sources on the same host are transmitting with the
3432 same source identifier at the time a receiver begins operation, it
3433 would be possible that the first RTP packet received came from one of
3434 the sources while the first RTCP packet received came from the other.
3435 This would cause the wrong RTCP information to be associated with the
3436 RTP data, but this situation should be sufficiently rare and harmless
3437 that it may be disregarded.
3439 In order to track loops of the participant's own data packets, the
3440 implementation MUST also keep a separate list of source transport
3441 addresses (not identifiers) that have been found to be conflicting.
3442 As in the source identifier table, two source transport addresses
3443 MUST be kept to separately track conflicting RTP and RTCP packets.
3444 Note that the conflicting address list should be short, usually
3445 empty. Each element in this list stores the source addresses plus
3446 the time when the most recent conflicting packet was received. An
3447 element MAY be removed from the list when no conflicting packet has
3448 arrived from that source for a time on the order of 10 RTCP report
3449 intervals (see Section 6.2).
3451 For the algorithm as shown, it is assumed that the participant's own
3452 source identifier and state are included in the source identifier
3453 table. The algorithm could be restructured to first make a separate
3454 comparison against the participant's own source identifier.
3456 if (SSRC or CSRC identifier is not found in the source
3458 create a new entry storing the data or control source
3459 transport address, the SSRC or CSRC and other state;
3462 /* Identifier is found in the table */
3464 else if (table entry was created on receipt of a control packet
3465 and this is the first data packet or vice versa) {
3466 store the source transport address from this packet;
3468 else if (source transport address from the packet does not match
3469 the one saved in the table entry for this identifier) {
3474 Schulzrinne, et al. Standards Track [Page 62]
3476 RFC 3550 RTP July 2003
3479 /* An identifier collision or a loop is indicated */
3481 if (source identifier is not the participant's own) {
3482 /* OPTIONAL error counter step */
3483 if (source identifier is from an RTCP SDES chunk
3484 containing a CNAME item that differs from the CNAME
3485 in the table entry) {
3486 count a third-party collision;
3488 count a third-party loop;
3490 abort processing of data packet or control element;
3491 /* MAY choose a different policy to keep new source */
3494 /* A collision or loop of the participant's own packets */
3496 else if (source transport address is found in the list of
3497 conflicting data or control source transport
3499 /* OPTIONAL error counter step */
3500 if (source identifier is not from an RTCP SDES chunk
3501 containing a CNAME item or CNAME is the
3502 participant's own) {
3503 count occurrence of own traffic looped;
3505 mark current time in conflicting address list entry;
3506 abort processing of data packet or control element;
3509 /* New collision, change SSRC identifier */
3512 log occurrence of a collision;
3513 create a new entry in the conflicting data or control
3514 source transport address list and mark current time;
3515 send an RTCP BYE packet with the old SSRC identifier;
3516 choose a new SSRC identifier;
3517 create a new entry in the source identifier table with
3518 the old SSRC plus the source transport address from
3519 the data or control packet being processed;
3523 In this algorithm, packets from a newly conflicting source address
3524 will be ignored and packets from the original source address will be
3525 kept. If no packets arrive from the original source for an extended
3526 period, the table entry will be timed out and the new source will be
3530 Schulzrinne, et al. Standards Track [Page 63]
3532 RFC 3550 RTP July 2003
3535 able to take over. This might occur if the original source detects
3536 the collision and moves to a new source identifier, but in the usual
3537 case an RTCP BYE packet will be received from the original source to
3538 delete the state without having to wait for a timeout.
3540 If the original source address was received through a mixer (i.e.,
3541 learned as a CSRC) and later the same source is received directly,
3542 the receiver may be well advised to switch to the new source address
3543 unless other sources in the mix would be lost. Furthermore, for
3544 applications such as telephony in which some sources such as mobile
3545 entities may change addresses during the course of an RTP session,
3546 the RTP implementation SHOULD modify the collision detection
3547 algorithm to accept packets from the new source transport address.
3548 To guard against flip-flopping between addresses if a genuine
3549 collision does occur, the algorithm SHOULD include some means to
3550 detect this case and avoid switching.
3552 When a new SSRC identifier is chosen due to a collision, the
3553 candidate identifier SHOULD first be looked up in the source
3554 identifier table to see if it was already in use by some other
3555 source. If so, another candidate MUST be generated and the process
3558 A loop of data packets to a multicast destination can cause severe
3559 network flooding. All mixers and translators MUST implement a loop
3560 detection algorithm like the one here so that they can break loops.
3561 This should limit the excess traffic to no more than one duplicate
3562 copy of the original traffic, which may allow the session to continue
3563 so that the cause of the loop can be found and fixed. However, in
3564 extreme cases where a mixer or translator does not properly break the
3565 loop and high traffic levels result, it may be necessary for end
3566 systems to cease transmitting data or control packets entirely. This
3567 decision may depend upon the application. An error condition SHOULD
3568 be indicated as appropriate. Transmission MAY be attempted again
3569 periodically after a long, random time (on the order of minutes).
3571 8.3 Use with Layered Encodings
3573 For layered encodings transmitted on separate RTP sessions (see
3574 Section 2.4), a single SSRC identifier space SHOULD be used across
3575 the sessions of all layers and the core (base) layer SHOULD be used
3576 for SSRC identifier allocation and collision resolution. When a
3577 source discovers that it has collided, it transmits an RTCP BYE
3578 packet on only the base layer but changes the SSRC identifier to the
3579 new value in all layers.
3586 Schulzrinne, et al. Standards Track [Page 64]
3588 RFC 3550 RTP July 2003
3593 Lower layer protocols may eventually provide all the security
3594 services that may be desired for applications of RTP, including
3595 authentication, integrity, and confidentiality. These services have
3596 been specified for IP in [27]. Since the initial audio and video
3597 applications using RTP needed a confidentiality service before such
3598 services were available for the IP layer, the confidentiality service
3599 described in the next section was defined for use with RTP and RTCP.
3600 That description is included here to codify existing practice. New
3601 applications of RTP MAY implement this RTP-specific confidentiality
3602 service for backward compatibility, and/or they MAY implement
3603 alternative security services. The overhead on the RTP protocol for
3604 this confidentiality service is low, so the penalty will be minimal
3605 if this service is obsoleted by other services in the future.
3607 Alternatively, other services, other implementations of services and
3608 other algorithms may be defined for RTP in the future. In
3609 particular, an RTP profile called Secure Real-time Transport Protocol
3610 (SRTP) [28] is being developed to provide confidentiality of the RTP
3611 payload while leaving the RTP header in the clear so that link-level
3612 header compression algorithms can still operate. It is expected that
3613 SRTP will be the correct choice for many applications. SRTP is based
3614 on the Advanced Encryption Standard (AES) and provides stronger
3615 security than the service described here. No claim is made that the
3616 methods presented here are appropriate for a particular security
3617 need. A profile may specify which services and algorithms should be
3618 offered by applications, and may provide guidance as to their
3621 Key distribution and certificates are outside the scope of this
3626 Confidentiality means that only the intended receiver(s) can decode
3627 the received packets; for others, the packet contains no useful
3628 information. Confidentiality of the content is achieved by
3631 When it is desired to encrypt RTP or RTCP according to the method
3632 specified in this section, all the octets that will be encapsulated
3633 for transmission in a single lower-layer packet are encrypted as a
3634 unit. For RTCP, a 32-bit random number redrawn for each unit MUST be
3635 prepended to the unit before encryption. For RTP, no prefix is
3636 prepended; instead, the sequence number and timestamp fields are
3637 initialized with random offsets. This is considered to be a weak
3642 Schulzrinne, et al. Standards Track [Page 65]
3644 RFC 3550 RTP July 2003
3647 initialization vector (IV) because of poor randomness properties. In
3648 addition, if the subsequent field, the SSRC, can be manipulated by an
3649 enemy, there is further weakness of the encryption method.
3651 For RTCP, an implementation MAY segregate the individual RTCP packets
3652 in a compound RTCP packet into two separate compound RTCP packets,
3653 one to be encrypted and one to be sent in the clear. For example,
3654 SDES information might be encrypted while reception reports were sent
3655 in the clear to accommodate third-party monitors that are not privy
3656 to the encryption key. In this example, depicted in Fig. 4, the SDES
3657 information MUST be appended to an RR packet with no reports (and the
3658 random number) to satisfy the requirement that all compound RTCP
3659 packets begin with an SR or RR packet. The SDES CNAME item is
3660 required in either the encrypted or unencrypted packet, but not both.
3661 The same SDES information SHOULD NOT be carried in both packets as
3662 this may compromise the encryption.
3664 UDP packet UDP packet
3665 ----------------------------- ------------------------------
3666 [random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
3667 ----------------------------- ------------------------------
3668 encrypted not encrypted
3672 Figure 4: Encrypted and non-encrypted RTCP packets
3674 The presence of encryption and the use of the correct key are
3675 confirmed by the receiver through header or payload validity checks.
3676 Examples of such validity checks for RTP and RTCP headers are given
3677 in Appendices A.1 and A.2.
3679 To be consistent with existing implementations of the initial
3680 specification of RTP in RFC 1889, the default encryption algorithm is
3681 the Data Encryption Standard (DES) algorithm in cipher block chaining
3682 (CBC) mode, as described in Section 1.1 of RFC 1423 [29], except that
3683 padding to a multiple of 8 octets is indicated as described for the P
3684 bit in Section 5.1. The initialization vector is zero because random
3685 values are supplied in the RTP header or by the random prefix for
3686 compound RTCP packets. For details on the use of CBC initialization
3689 Implementations that support the encryption method specified here
3690 SHOULD always support the DES algorithm in CBC mode as the default
3691 cipher for this method to maximize interoperability. This method was
3692 chosen because it has been demonstrated to be easy and practical to
3693 use in experimental audio and video tools in operation on the
3694 Internet. However, DES has since been found to be too easily broken.
3698 Schulzrinne, et al. Standards Track [Page 66]
3700 RFC 3550 RTP July 2003
3703 It is RECOMMENDED that stronger encryption algorithms such as
3704 Triple-DES be used in place of the default algorithm. Furthermore,
3705 secure CBC mode requires that the first block of each packet be XORed
3706 with a random, independent IV of the same size as the cipher's block
3707 size. For RTCP, this is (partially) achieved by prepending each
3708 packet with a 32-bit random number, independently chosen for each
3709 packet. For RTP, the timestamp and sequence number start from random
3710 values, but consecutive packets will not be independently randomized.
3711 It should be noted that the randomness in both cases (RTP and RTCP)
3712 is limited. High-security applications SHOULD consider other, more
3713 conventional, protection means. Other encryption algorithms MAY be
3714 specified dynamically for a session by non-RTP means. In particular,
3715 the SRTP profile [28] based on AES is being developed to take into
3716 account known plaintext and CBC plaintext manipulation concerns, and
3717 will be the correct choice in the future.
3719 As an alternative to encryption at the IP level or at the RTP level
3720 as described above, profiles MAY define additional payload types for
3721 encrypted encodings. Those encodings MUST specify how padding and
3722 other aspects of the encryption are to be handled. This method
3723 allows encrypting only the data while leaving the headers in the
3724 clear for applications where that is desired. It may be particularly
3725 useful for hardware devices that will handle both decryption and
3726 decoding. It is also valuable for applications where link-level
3727 compression of RTP and lower-layer headers is desired and
3728 confidentiality of the payload (but not addresses) is sufficient
3729 since encryption of the headers precludes compression.
3731 9.2 Authentication and Message Integrity
3733 Authentication and message integrity services are not defined at the
3734 RTP level since these services would not be directly feasible without
3735 a key management infrastructure. It is expected that authentication
3736 and integrity services will be provided by lower layer protocols.
3738 10. Congestion Control
3740 All transport protocols used on the Internet need to address
3741 congestion control in some way [31]. RTP is not an exception, but
3742 because the data transported over RTP is often inelastic (generated
3743 at a fixed or controlled rate), the means to control congestion in
3744 RTP may be quite different from those for other transport protocols
3745 such as TCP. In one sense, inelasticity reduces the risk of
3746 congestion because the RTP stream will not expand to consume all
3747 available bandwidth as a TCP stream can. However, inelasticity also
3748 means that the RTP stream cannot arbitrarily reduce its load on the
3749 network to eliminate congestion when it occurs.
3754 Schulzrinne, et al. Standards Track [Page 67]
3756 RFC 3550 RTP July 2003
3759 Since RTP may be used for a wide variety of applications in many
3760 different contexts, there is no single congestion control mechanism
3761 that will work for all. Therefore, congestion control SHOULD be
3762 defined in each RTP profile as appropriate. For some profiles, it
3763 may be sufficient to include an applicability statement restricting
3764 the use of that profile to environments where congestion is avoided
3765 by engineering. For other profiles, specific methods such as data
3766 rate adaptation based on RTCP feedback may be required.
3768 11. RTP over Network and Transport Protocols
3770 This section describes issues specific to carrying RTP packets within
3771 particular network and transport protocols. The following rules
3772 apply unless superseded by protocol-specific definitions outside this
3775 RTP relies on the underlying protocol(s) to provide demultiplexing of
3776 RTP data and RTCP control streams. For UDP and similar protocols,
3777 RTP SHOULD use an even destination port number and the corresponding
3778 RTCP stream SHOULD use the next higher (odd) destination port number.
3779 For applications that take a single port number as a parameter and
3780 derive the RTP and RTCP port pair from that number, if an odd number
3781 is supplied then the application SHOULD replace that number with the
3782 next lower (even) number to use as the base of the port pair. For
3783 applications in which the RTP and RTCP destination port numbers are
3784 specified via explicit, separate parameters (using a signaling
3785 protocol or other means), the application MAY disregard the
3786 restrictions that the port numbers be even/odd and consecutive
3787 although the use of an even/odd port pair is still encouraged. The
3788 RTP and RTCP port numbers MUST NOT be the same since RTP relies on
3789 the port numbers to demultiplex the RTP data and RTCP control
3792 In a unicast session, both participants need to identify a port pair
3793 for receiving RTP and RTCP packets. Both participants MAY use the
3794 same port pair. A participant MUST NOT assume that the source port
3795 of the incoming RTP or RTCP packet can be used as the destination
3796 port for outgoing RTP or RTCP packets. When RTP data packets are
3797 being sent in both directions, each participant's RTCP SR packets
3798 MUST be sent to the port that the other participant has specified for
3799 reception of RTCP. The RTCP SR packets combine sender information
3800 for the outgoing data plus reception report information for the
3801 incoming data. If a side is not actively sending data (see Section
3802 6.4), an RTCP RR packet is sent instead.
3804 It is RECOMMENDED that layered encoding applications (see Section
3805 2.4) use a set of contiguous port numbers. The port numbers MUST be
3806 distinct because of a widespread deficiency in existing operating
3810 Schulzrinne, et al. Standards Track [Page 68]
3812 RFC 3550 RTP July 2003
3815 systems that prevents use of the same port with multiple multicast
3816 addresses, and for unicast, there is only one permissible address.
3817 Thus for layer n, the data port is P + 2n, and the control port is P
3818 + 2n + 1. When IP multicast is used, the addresses MUST also be
3819 distinct because multicast routing and group membership are managed
3820 on an address granularity. However, allocation of contiguous IP
3821 multicast addresses cannot be assumed because some groups may require
3822 different scopes and may therefore be allocated from different
3825 The previous paragraph conflicts with the SDP specification, RFC 2327
3826 [15], which says that it is illegal for both multiple addresses and
3827 multiple ports to be specified in the same session description
3828 because the association of addresses with ports could be ambiguous.
3829 It is intended that this restriction will be relaxed in a revision of
3830 RFC 2327 to allow an equal number of addresses and ports to be
3831 specified with a one-to-one mapping implied.
3833 RTP data packets contain no length field or other delineation,
3834 therefore RTP relies on the underlying protocol(s) to provide a
3835 length indication. The maximum length of RTP packets is limited only
3836 by the underlying protocols.
3838 If RTP packets are to be carried in an underlying protocol that
3839 provides the abstraction of a continuous octet stream rather than
3840 messages (packets), an encapsulation of the RTP packets MUST be
3841 defined to provide a framing mechanism. Framing is also needed if
3842 the underlying protocol may contain padding so that the extent of the
3843 RTP payload cannot be determined. The framing mechanism is not
3846 A profile MAY specify a framing method to be used even when RTP is
3847 carried in protocols that do provide framing in order to allow
3848 carrying several RTP packets in one lower-layer protocol data unit,
3849 such as a UDP packet. Carrying several RTP packets in one network or
3850 transport packet reduces header overhead and may simplify
3851 synchronization between different streams.
3853 12. Summary of Protocol Constants
3855 This section contains a summary listing of the constants defined in
3858 The RTP payload type (PT) constants are defined in profiles rather
3859 than this document. However, the octet of the RTP header which
3860 contains the marker bit(s) and payload type MUST avoid the reserved
3861 values 200 and 201 (decimal) to distinguish RTP packets from the RTCP
3862 SR and RR packet types for the header validation procedure described
3866 Schulzrinne, et al. Standards Track [Page 69]
3868 RFC 3550 RTP July 2003
3871 in Appendix A.1. For the standard definition of one marker bit and a
3872 7-bit payload type field as shown in this specification, this
3873 restriction means that payload types 72 and 73 are reserved.
3875 12.1 RTCP Packet Types
3878 SR sender report 200
3879 RR receiver report 201
3880 SDES source description 202
3882 APP application-defined 204
3884 These type values were chosen in the range 200-204 for improved
3885 header validity checking of RTCP packets compared to RTP packets or
3886 other unrelated packets. When the RTCP packet type field is compared
3887 to the corresponding octet of the RTP header, this range corresponds
3888 to the marker bit being 1 (which it usually is not in data packets)
3889 and to the high bit of the standard payload type field being 1 (since
3890 the static payload types are typically defined in the low half).
3891 This range was also chosen to be some distance numerically from 0 and
3892 255 since all-zeros and all-ones are common data patterns.
3894 Since all compound RTCP packets MUST begin with SR or RR, these codes
3895 were chosen as an even/odd pair to allow the RTCP validity check to
3896 test the maximum number of bits with mask and value.
3898 Additional RTCP packet types may be registered through IANA (see
3904 END end of SDES list 0
3905 CNAME canonical name 1
3907 EMAIL user's electronic mail address 3
3908 PHONE user's phone number 4
3909 LOC geographic user location 5
3910 TOOL name of application or tool 6
3911 NOTE notice about the source 7
3912 PRIV private extensions 8
3914 Additional SDES types may be registered through IANA (see Section
3922 Schulzrinne, et al. Standards Track [Page 70]
3924 RFC 3550 RTP July 2003
3927 13. RTP Profiles and Payload Format Specifications
3929 A complete specification of RTP for a particular application will
3930 require one or more companion documents of two types described here:
3931 profiles, and payload format specifications.
3933 RTP may be used for a variety of applications with somewhat differing
3934 requirements. The flexibility to adapt to those requirements is
3935 provided by allowing multiple choices in the main protocol
3936 specification, then selecting the appropriate choices or defining
3937 extensions for a particular environment and class of applications in
3938 a separate profile document. Typically an application will operate
3939 under only one profile in a particular RTP session, so there is no
3940 explicit indication within the RTP protocol itself as to which
3941 profile is in use. A profile for audio and video applications may be
3942 found in the companion RFC 3551. Profiles are typically titled "RTP
3945 The second type of companion document is a payload format
3946 specification, which defines how a particular kind of payload data,
3947 such as H.261 encoded video, should be carried in RTP. These
3948 documents are typically titled "RTP Payload Format for XYZ
3949 Audio/Video Encoding". Payload formats may be useful under multiple
3950 profiles and may therefore be defined independently of any particular
3951 profile. The profile documents are then responsible for assigning a
3952 default mapping of that format to a payload type value if needed.
3954 Within this specification, the following items have been identified
3955 for possible definition within a profile, but this list is not meant
3958 RTP data header: The octet in the RTP data header that contains
3959 the marker bit and payload type field MAY be redefined by a
3960 profile to suit different requirements, for example with more or
3961 fewer marker bits (Section 5.3, p. 18).
3963 Payload types: Assuming that a payload type field is included,
3964 the profile will usually define a set of payload formats (e.g.,
3965 media encodings) and a default static mapping of those formats to
3966 payload type values. Some of the payload formats may be defined
3967 by reference to separate payload format specifications. For each
3968 payload type defined, the profile MUST specify the RTP timestamp
3969 clock rate to be used (Section 5.1, p. 14).
3971 RTP data header additions: Additional fields MAY be appended to
3972 the fixed RTP data header if some additional functionality is
3973 required across the profile's class of applications independent of
3974 payload type (Section 5.3, p. 18).
3978 Schulzrinne, et al. Standards Track [Page 71]
3980 RFC 3550 RTP July 2003
3983 RTP data header extensions: The contents of the first 16 bits of
3984 the RTP data header extension structure MUST be defined if use of
3985 that mechanism is to be allowed under the profile for
3986 implementation-specific extensions (Section 5.3.1, p. 18).
3988 RTCP packet types: New application-class-specific RTCP packet
3989 types MAY be defined and registered with IANA.
3991 RTCP report interval: A profile SHOULD specify that the values
3992 suggested in Section 6.2 for the constants employed in the
3993 calculation of the RTCP report interval will be used. Those are
3994 the RTCP fraction of session bandwidth, the minimum report
3995 interval, and the bandwidth split between senders and receivers.
3996 A profile MAY specify alternate values if they have been
3997 demonstrated to work in a scalable manner.
3999 SR/RR extension: An extension section MAY be defined for the
4000 RTCP SR and RR packets if there is additional information that
4001 should be reported regularly about the sender or receivers
4002 (Section 6.4.3, p. 42 and 43).
4004 SDES use: The profile MAY specify the relative priorities for
4005 RTCP SDES items to be transmitted or excluded entirely (Section
4006 6.3.9); an alternate syntax or semantics for the CNAME item
4007 (Section 6.5.1); the format of the LOC item (Section 6.5.5); the
4008 semantics and use of the NOTE item (Section 6.5.7); or new SDES
4009 item types to be registered with IANA.
4011 Security: A profile MAY specify which security services and
4012 algorithms should be offered by applications, and MAY provide
4013 guidance as to their appropriate use (Section 9, p. 65).
4015 String-to-key mapping: A profile MAY specify how a user-provided
4016 password or pass phrase is mapped into an encryption key.
4018 Congestion: A profile SHOULD specify the congestion control
4019 behavior appropriate for that profile.
4021 Underlying protocol: Use of a particular underlying network or
4022 transport layer protocol to carry RTP packets MAY be required.
4024 Transport mapping: A mapping of RTP and RTCP to transport-level
4025 addresses, e.g., UDP ports, other than the standard mapping
4026 defined in Section 11, p. 68 may be specified.
4034 Schulzrinne, et al. Standards Track [Page 72]
4036 RFC 3550 RTP July 2003
4039 Encapsulation: An encapsulation of RTP packets may be defined to
4040 allow multiple RTP data packets to be carried in one lower-layer
4041 packet or to provide framing over underlying protocols that do not
4042 already do so (Section 11, p. 69).
4044 It is not expected that a new profile will be required for every
4045 application. Within one application class, it would be better to
4046 extend an existing profile rather than make a new one in order to
4047 facilitate interoperation among the applications since each will
4048 typically run under only one profile. Simple extensions such as the
4049 definition of additional payload type values or RTCP packet types may
4050 be accomplished by registering them through IANA and publishing their
4051 descriptions in an addendum to the profile or in a payload format
4054 14. Security Considerations
4056 RTP suffers from the same security liabilities as the underlying
4057 protocols. For example, an impostor can fake source or destination
4058 network addresses, or change the header or payload. Within RTCP, the
4059 CNAME and NAME information may be used to impersonate another
4060 participant. In addition, RTP may be sent via IP multicast, which
4061 provides no direct means for a sender to know all the receivers of
4062 the data sent and therefore no measure of privacy. Rightly or not,
4063 users may be more sensitive to privacy concerns with audio and video
4064 communication than they have been with more traditional forms of
4065 network communication [33]. Therefore, the use of security
4066 mechanisms with RTP is important. These mechanisms are discussed in
4069 RTP-level translators or mixers may be used to allow RTP traffic to
4070 reach hosts behind firewalls. Appropriate firewall security
4071 principles and practices, which are beyond the scope of this
4072 document, should be followed in the design and installation of these
4073 devices and in the admission of RTP applications for use behind the
4076 15. IANA Considerations
4078 Additional RTCP packet types and SDES item types may be registered
4079 through the Internet Assigned Numbers Authority (IANA). Since these
4080 number spaces are small, allowing unconstrained registration of new
4081 values would not be prudent. To facilitate review of requests and to
4082 promote shared use of new types among multiple applications, requests
4083 for registration of new values must be documented in an RFC or other
4084 permanent and readily available reference such as the product of
4085 another cooperative standards body (e.g., ITU-T). Other requests may
4086 also be accepted, under the advice of a "designated expert."
4090 Schulzrinne, et al. Standards Track [Page 73]
4092 RFC 3550 RTP July 2003
4095 (Contact the IANA for the contact information of the current expert.)
4097 RTP profile specifications SHOULD register with IANA a name for the
4098 profile in the form "RTP/xxx", where xxx is a short abbreviation of
4099 the profile title. These names are for use by higher-level control
4100 protocols, such as the Session Description Protocol (SDP), RFC 2327
4101 [15], to refer to transport methods.
4103 16. Intellectual Property Rights Statement
4105 The IETF takes no position regarding the validity or scope of any
4106 intellectual property or other rights that might be claimed to
4107 pertain to the implementation or use of the technology described in
4108 this document or the extent to which any license under such rights
4109 might or might not be available; neither does it represent that it
4110 has made any effort to identify any such rights. Information on the
4111 IETF's procedures with respect to rights in standards-track and
4112 standards-related documentation can be found in BCP-11. Copies of
4113 claims of rights made available for publication and any assurances of
4114 licenses to be made available, or the result of an attempt made to
4115 obtain a general license or permission for the use of such
4116 proprietary rights by implementors or users of this specification can
4117 be obtained from the IETF Secretariat.
4119 The IETF invites any interested party to bring to its attention any
4120 copyrights, patents or patent applications, or other proprietary
4121 rights which may cover technology that may be required to practice
4122 this standard. Please address the information to the IETF Executive
4127 This memorandum is based on discussions within the IETF Audio/Video
4128 Transport working group chaired by Stephen Casner and Colin Perkins.
4129 The current protocol has its origins in the Network Voice Protocol
4130 and the Packet Video Protocol (Danny Cohen and Randy Cole) and the
4131 protocol implemented by the vat application (Van Jacobson and Steve
4132 McCanne). Christian Huitema provided ideas for the random identifier
4133 generator. Extensive analysis and simulation of the timer
4134 reconsideration algorithm was done by Jonathan Rosenberg. The
4135 additions for layered encodings were specified by Michael Speer and
4146 Schulzrinne, et al. Standards Track [Page 74]
4148 RFC 3550 RTP July 2003
4151 Appendix A - Algorithms
4153 We provide examples of C code for aspects of RTP sender and receiver
4154 algorithms. There may be other implementation methods that are
4155 faster in particular operating environments or have other advantages.
4156 These implementation notes are for informational purposes only and
4157 are meant to clarify the RTP specification.
4159 The following definitions are used for all examples; for clarity and
4160 brevity, the structure definitions are only valid for 32-bit big-
4161 endian (most significant octet first) architectures. Bit fields are
4162 assumed to be packed tightly in big-endian bit order, with no
4163 additional padding. Modifications would be required to construct a
4164 portable implementation.
4167 * rtp.h -- RTP header file
4169 #include <sys/types.h>
4172 * The type definitions below are valid for 32-bit architectures and
4173 * may have to be adjusted for 16- or 64-bit architectures.
4175 typedef unsigned char u_int8;
4176 typedef unsigned short u_int16;
4177 typedef unsigned int u_int32;
4178 typedef short int16;
4181 * Current protocol version.
4183 #define RTP_VERSION 2
4185 #define RTP_SEQ_MOD (1<<16)
4186 #define RTP_MAX_SDES 255 /* maximum text length for SDES */
4198 RTCP_SDES_CNAME = 1,
4202 Schulzrinne, et al. Standards Track [Page 75]
4204 RFC 3550 RTP July 2003
4208 RTCP_SDES_EMAIL = 3,
4209 RTCP_SDES_PHONE = 4,
4220 unsigned int version:2; /* protocol version */
4221 unsigned int p:1; /* padding flag */
4222 unsigned int x:1; /* header extension flag */
4223 unsigned int cc:4; /* CSRC count */
4224 unsigned int m:1; /* marker bit */
4225 unsigned int pt:7; /* payload type */
4226 unsigned int seq:16; /* sequence number */
4227 u_int32 ts; /* timestamp */
4228 u_int32 ssrc; /* synchronization source */
4229 u_int32 csrc[1]; /* optional CSRC list */
4233 * RTCP common header word
4236 unsigned int version:2; /* protocol version */
4237 unsigned int p:1; /* padding flag */
4238 unsigned int count:5; /* varies by packet type */
4239 unsigned int pt:8; /* RTCP packet type */
4240 u_int16 length; /* pkt len in words, w/o this word */
4244 * Big-endian mask for version, padding bit and packet type pair
4246 #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
4247 #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
4250 * Reception report block
4253 u_int32 ssrc; /* data source being reported */
4254 unsigned int fraction:8; /* fraction lost since last SR/RR */
4258 Schulzrinne, et al. Standards Track [Page 76]
4260 RFC 3550 RTP July 2003
4263 int lost:24; /* cumul. no. pkts lost (signed!) */
4264 u_int32 last_seq; /* extended last seq. no. received */
4265 u_int32 jitter; /* interarrival jitter */
4266 u_int32 lsr; /* last SR packet from this source */
4267 u_int32 dlsr; /* delay since last SR packet */
4274 u_int8 type; /* type of item (rtcp_sdes_type_t) */
4275 u_int8 length; /* length of item (in octets) */
4276 char data[1]; /* text, not null-terminated */
4283 rtcp_common_t common; /* common header */
4285 /* sender report (SR) */
4287 u_int32 ssrc; /* sender generating this report */
4288 u_int32 ntp_sec; /* NTP timestamp */
4290 u_int32 rtp_ts; /* RTP timestamp */
4291 u_int32 psent; /* packets sent */
4292 u_int32 osent; /* octets sent */
4293 rtcp_rr_t rr[1]; /* variable-length list */
4296 /* reception report (RR) */
4298 u_int32 ssrc; /* receiver generating this report */
4299 rtcp_rr_t rr[1]; /* variable-length list */
4302 /* source description (SDES) */
4304 u_int32 src; /* first SSRC/CSRC */
4305 rtcp_sdes_item_t item[1]; /* list of SDES items */
4310 u_int32 src[1]; /* list of sources */
4314 Schulzrinne, et al. Standards Track [Page 77]
4316 RFC 3550 RTP July 2003
4319 /* can't express trailing text for reason */
4324 typedef struct rtcp_sdes rtcp_sdes_t;
4327 * Per-source state information
4330 u_int16 max_seq; /* highest seq. number seen */
4331 u_int32 cycles; /* shifted count of seq. number cycles */
4332 u_int32 base_seq; /* base seq number */
4333 u_int32 bad_seq; /* last 'bad' seq number + 1 */
4334 u_int32 probation; /* sequ. packets till source is valid */
4335 u_int32 received; /* packets received */
4336 u_int32 expected_prior; /* packet expected at last interval */
4337 u_int32 received_prior; /* packet received at last interval */
4338 u_int32 transit; /* relative trans time for prev pkt */
4339 u_int32 jitter; /* estimated jitter */
4343 A.1 RTP Data Header Validity Checks
4345 An RTP receiver should check the validity of the RTP header on
4346 incoming packets since they might be encrypted or might be from a
4347 different application that happens to be misaddressed. Similarly, if
4348 encryption according to the method described in Section 9 is enabled,
4349 the header validity check is needed to verify that incoming packets
4350 have been correctly decrypted, although a failure of the header
4351 validity check (e.g., unknown payload type) may not necessarily
4352 indicate decryption failure.
4354 Only weak validity checks are possible on an RTP data packet from a
4355 source that has not been heard before:
4357 o RTP version field must equal 2.
4359 o The payload type must be known, and in particular it must not be
4362 o If the P bit is set, then the last octet of the packet must
4363 contain a valid octet count, in particular, less than the total
4364 packet length minus the header size.
4370 Schulzrinne, et al. Standards Track [Page 78]
4372 RFC 3550 RTP July 2003
4375 o The X bit must be zero if the profile does not specify that the
4376 header extension mechanism may be used. Otherwise, the extension
4377 length field must be less than the total packet size minus the
4378 fixed header length and padding.
4380 o The length of the packet must be consistent with CC and payload
4381 type (if payloads have a known length).
4383 The last three checks are somewhat complex and not always possible,
4384 leaving only the first two which total just a few bits. If the SSRC
4385 identifier in the packet is one that has been received before, then
4386 the packet is probably valid and checking if the sequence number is
4387 in the expected range provides further validation. If the SSRC
4388 identifier has not been seen before, then data packets carrying that
4389 identifier may be considered invalid until a small number of them
4390 arrive with consecutive sequence numbers. Those invalid packets MAY
4391 be discarded or they MAY be stored and delivered once validation has
4392 been achieved if the resulting delay is acceptable.
4394 The routine update_seq shown below ensures that a source is declared
4395 valid only after MIN_SEQUENTIAL packets have been received in
4396 sequence. It also validates the sequence number seq of a newly
4397 received packet and updates the sequence state for the packet's
4398 source in the structure to which s points.
4400 When a new source is heard for the first time, that is, its SSRC
4401 identifier is not in the table (see Section 8.2), and the per-source
4402 state is allocated for it, s->probation is set to the number of
4403 sequential packets required before declaring a source valid
4404 (parameter MIN_SEQUENTIAL) and other variables are initialized:
4407 s->max_seq = seq - 1;
4408 s->probation = MIN_SEQUENTIAL;
4410 A non-zero s->probation marks the source as not yet valid so the
4411 state may be discarded after a short timeout rather than a long one,
4412 as discussed in Section 6.2.1.
4414 After a source is considered valid, the sequence number is considered
4415 valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more
4416 than MAX_MISORDER behind. If the new sequence number is ahead of
4417 max_seq modulo the RTP sequence number range (16 bits), but is
4418 smaller than max_seq, it has wrapped around and the (shifted) count
4419 of sequence number cycles is incremented. A value of one is returned
4420 to indicate a valid sequence number.
4426 Schulzrinne, et al. Standards Track [Page 79]
4428 RFC 3550 RTP July 2003
4431 Otherwise, the value zero is returned to indicate that the validation
4432 failed, and the bad sequence number plus 1 is stored. If the next
4433 packet received carries the next higher sequence number, it is
4434 considered the valid start of a new packet sequence presumably caused
4435 by an extended dropout or a source restart. Since multiple complete
4436 sequence number cycles may have been missed, the packet loss
4437 statistics are reset.
4439 Typical values for the parameters are shown, based on a maximum
4440 misordering time of 2 seconds at 50 packets/second and a maximum
4441 dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a
4442 small fraction of the 16-bit sequence number space to give a
4443 reasonable probability that new sequence numbers after a restart will
4444 not fall in the acceptable range for sequence numbers from before the
4447 void init_seq(source *s, u_int16 seq)
4451 s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */
4454 s->received_prior = 0;
4455 s->expected_prior = 0;
4456 /* other initialization */
4459 int update_seq(source *s, u_int16 seq)
4461 u_int16 udelta = seq - s->max_seq;
4462 const int MAX_DROPOUT = 3000;
4463 const int MAX_MISORDER = 100;
4464 const int MIN_SEQUENTIAL = 2;
4467 * Source is not valid until MIN_SEQUENTIAL packets with
4468 * sequential sequence numbers have been received.
4471 /* packet is in sequence */
4472 if (seq == s->max_seq + 1) {
4475 if (s->probation == 0) {
4482 Schulzrinne, et al. Standards Track [Page 80]
4484 RFC 3550 RTP July 2003
4489 s->probation = MIN_SEQUENTIAL - 1;
4493 } else if (udelta < MAX_DROPOUT) {
4494 /* in order, with permissible gap */
4495 if (seq < s->max_seq) {
4497 * Sequence number wrapped - count another 64K cycle.
4499 s->cycles += RTP_SEQ_MOD;
4502 } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
4503 /* the sequence number made a very large jump */
4504 if (seq == s->bad_seq) {
4506 * Two sequential packets -- assume that the other side
4507 * restarted without telling us so just re-sync
4508 * (i.e., pretend this was the first packet).
4513 s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
4517 /* duplicate or reordered packet */
4523 The validity check can be made stronger requiring more than two
4524 packets in sequence. The disadvantages are that a larger number of
4525 initial packets will be discarded (or delayed in a queue) and that
4526 high packet loss rates could prevent validation. However, because
4527 the RTCP header validation is relatively strong, if an RTCP packet is
4528 received from a source before the data packets, the count could be
4529 adjusted so that only two packets are required in sequence. If
4530 initial data loss for a few seconds can be tolerated, an application
4531 MAY choose to discard all data packets from a source until a valid
4532 RTCP packet has been received from that source.
4538 Schulzrinne, et al. Standards Track [Page 81]
4540 RFC 3550 RTP July 2003
4543 Depending on the application and encoding, algorithms may exploit
4544 additional knowledge about the payload format for further validation.
4545 For payload types where the timestamp increment is the same for all
4546 packets, the timestamp values can be predicted from the previous
4547 packet received from the same source using the sequence number
4548 difference (assuming no change in payload type).
4550 A strong "fast-path" check is possible since with high probability
4551 the first four octets in the header of a newly received RTP data
4552 packet will be just the same as that of the previous packet from the
4553 same SSRC except that the sequence number will have increased by one.
4554 Similarly, a single-entry cache may be used for faster SSRC lookups
4555 in applications where data is typically received from one source at a
4558 A.2 RTCP Header Validity Checks
4560 The following checks should be applied to RTCP packets.
4562 o RTP version field must equal 2.
4564 o The payload type field of the first RTCP packet in a compound
4565 packet must be equal to SR or RR.
4567 o The padding bit (P) should be zero for the first packet of a
4568 compound RTCP packet because padding should only be applied, if it
4569 is needed, to the last packet.
4571 o The length fields of the individual RTCP packets must add up to
4572 the overall length of the compound RTCP packet as received. This
4573 is a fairly strong check.
4575 The code fragment below performs all of these checks. The packet
4576 type is not checked for subsequent packets since unknown packet types
4577 may be present and should be ignored.
4579 u_int32 len; /* length of compound RTCP packet in words */
4580 rtcp_t *r; /* RTCP header */
4581 rtcp_t *end; /* end of compound RTCP packet */
4583 if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
4584 /* something wrong with packet format */
4586 end = (rtcp_t *)((u_int32 *)r + len);
4588 do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
4589 while (r < end && r->common.version == 2);
4594 Schulzrinne, et al. Standards Track [Page 82]
4596 RFC 3550 RTP July 2003
4600 /* something wrong with packet format */
4603 A.3 Determining Number of Packets Expected and Lost
4605 In order to compute packet loss rates, the number of RTP packets
4606 expected and actually received from each source needs to be known,
4607 using per-source state information defined in struct source
4608 referenced via pointer s in the code below. The number of packets
4609 received is simply the count of packets as they arrive, including any
4610 late or duplicate packets. The number of packets expected can be
4611 computed by the receiver as the difference between the highest
4612 sequence number received (s->max_seq) and the first sequence number
4613 received (s->base_seq). Since the sequence number is only 16 bits
4614 and will wrap around, it is necessary to extend the highest sequence
4615 number with the (shifted) count of sequence number wraparounds
4616 (s->cycles). Both the received packet count and the count of cycles
4617 are maintained the RTP header validity check routine in Appendix A.1.
4619 extended_max = s->cycles + s->max_seq;
4620 expected = extended_max - s->base_seq + 1;
4622 The number of packets lost is defined to be the number of packets
4623 expected less the number of packets actually received:
4625 lost = expected - s->received;
4627 Since this signed number is carried in 24 bits, it should be clamped
4628 at 0x7fffff for positive loss or 0x800000 for negative loss rather
4629 than wrapping around.
4631 The fraction of packets lost during the last reporting interval
4632 (since the previous SR or RR packet was sent) is calculated from
4633 differences in the expected and received packet counts across the
4634 interval, where expected_prior and received_prior are the values
4635 saved when the previous reception report was generated:
4637 expected_interval = expected - s->expected_prior;
4638 s->expected_prior = expected;
4639 received_interval = s->received - s->received_prior;
4640 s->received_prior = s->received;
4641 lost_interval = expected_interval - received_interval;
4642 if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
4643 else fraction = (lost_interval << 8) / expected_interval;
4645 The resulting fraction is an 8-bit fixed point number with the binary
4646 point at the left edge.
4650 Schulzrinne, et al. Standards Track [Page 83]
4652 RFC 3550 RTP July 2003
4655 A.4 Generating RTCP SDES Packets
4657 This function builds one SDES chunk into buffer b composed of argc
4658 items supplied in arrays type, value and length. It returns a
4659 pointer to the next available location within b.
4661 char *rtp_write_sdes(char *b, u_int32 src, int argc,
4662 rtcp_sdes_type_t type[], char *value[],
4665 rtcp_sdes_t *s = (rtcp_sdes_t *)b;
4666 rtcp_sdes_item_t *rsp;
4676 for (i = 0; i < argc; i++) {
4677 rsp->type = type[i];
4679 if (len > RTP_MAX_SDES) {
4680 /* invalid length, may want to take other action */
4684 memcpy(rsp->data, value[i], len);
4685 rsp = (rtcp_sdes_item_t *)&rsp->data[len];
4688 /* terminate with end marker and pad to next 4-octet boundary */
4689 len = ((char *) rsp) - b;
4690 pad = 4 - (len & 0x3);
4692 while (pad--) *b++ = RTCP_SDES_END;
4706 Schulzrinne, et al. Standards Track [Page 84]
4708 RFC 3550 RTP July 2003
4711 A.5 Parsing RTCP SDES Packets
4713 This function parses an SDES packet, calling functions find_member()
4714 to find a pointer to the information for a session member given the
4715 SSRC identifier and member_sdes() to store the new SDES information
4716 for that member. This function expects a pointer to the header of
4719 void rtp_read_sdes(rtcp_t *r)
4721 int count = r->common.count;
4722 rtcp_sdes_t *sd = &r->r.sdes;
4723 rtcp_sdes_item_t *rsp, *rspn;
4724 rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
4725 ((u_int32 *)r + r->common.length + 1);
4728 while (--count >= 0) {
4730 if (rsp >= end) break;
4731 s = find_member(sd->src);
4733 for (; rsp->type; rsp = rspn ) {
4734 rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
4739 member_sdes(s, rsp->type, rsp->data, rsp->length);
4741 sd = (rtcp_sdes_t *)
4742 ((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
4745 /* invalid packet format */
4749 A.6 Generating a Random 32-bit Identifier
4751 The following subroutine generates a random 32-bit identifier using
4752 the MD5 routines published in RFC 1321 [32]. The system routines may
4753 not be present on all operating systems, but they should serve as
4754 hints as to what kinds of information may be used. Other system
4755 calls that may be appropriate include
4762 Schulzrinne, et al. Standards Track [Page 85]
4764 RFC 3550 RTP July 2003
4773 "Live" video or audio samples are also a good source of random
4774 numbers, but care must be taken to avoid using a turned-off
4775 microphone or blinded camera as a source [17].
4777 Use of this or a similar routine is recommended to generate the
4778 initial seed for the random number generator producing the RTCP
4779 period (as shown in Appendix A.7), to generate the initial values for
4780 the sequence number and timestamp, and to generate SSRC values.
4781 Since this routine is likely to be CPU-intensive, its direct use to
4782 generate RTCP periods is inappropriate because predictability is not
4783 an issue. Note that this routine produces the same result on
4784 repeated calls until the value of the system clock changes unless
4785 different values are supplied for the type argument.
4788 * Generate a random 32-bit quantity.
4790 #include <sys/types.h> /* u_long */
4791 #include <sys/time.h> /* gettimeofday() */
4792 #include <unistd.h> /* get..() */
4793 #include <stdio.h> /* printf() */
4794 #include <time.h> /* clock() */
4795 #include <sys/utsname.h> /* uname() */
4796 #include "global.h" /* from RFC 1321 */
4797 #include "md5.h" /* from RFC 1321 */
4799 #define MD_CTX MD5_CTX
4800 #define MDInit MD5Init
4801 #define MDUpdate MD5Update
4802 #define MDFinal MD5Final
4804 static u_long md_32(char *string, int length)
4818 Schulzrinne, et al. Standards Track [Page 86]
4820 RFC 3550 RTP July 2003
4823 MDUpdate (&context, string, length);
4824 MDFinal ((unsigned char *)&digest, &context);
4826 for (i = 0; i < 3; i++) {
4833 * Return random unsigned 32-bit quantity. Use 'type' argument if
4834 * you need to generate several different values in close succession.
4836 u_int32 random32(int type)
4846 struct utsname name;
4849 gettimeofday(&s.tv, 0);
4854 s.hid = gethostid();
4857 /* also: system uptime */
4859 return md_32((char *)&s, sizeof(s));
4862 A.7 Computing the RTCP Transmission Interval
4864 The following functions implement the RTCP transmission and reception
4865 rules described in Section 6.2. These rules are coded in several
4868 o rtcp_interval() computes the deterministic calculated interval,
4869 measured in seconds. The parameters are defined in Section 6.3.
4874 Schulzrinne, et al. Standards Track [Page 87]
4876 RFC 3550 RTP July 2003
4879 o OnExpire() is called when the RTCP transmission timer expires.
4881 o OnReceive() is called whenever an RTCP packet is received.
4883 Both OnExpire() and OnReceive() have event e as an argument. This is
4884 the next scheduled event for that participant, either an RTCP report
4885 or a BYE packet. It is assumed that the following functions are
4888 o Schedule(time t, event e) schedules an event e to occur at time t.
4889 When time t arrives, the function OnExpire is called with e as an
4892 o Reschedule(time t, event e) reschedules a previously scheduled
4895 o SendRTCPReport(event e) sends an RTCP report.
4897 o SendBYEPacket(event e) sends a BYE packet.
4899 o TypeOfEvent(event e) returns EVENT_BYE if the event being
4900 processed is for a BYE packet to be sent, else it returns
4903 o PacketType(p) returns PACKET_RTCP_REPORT if packet p is an RTCP
4904 report (not BYE), PACKET_BYE if its a BYE RTCP packet, and
4905 PACKET_RTP if its a regular RTP data packet.
4907 o ReceivedPacketSize() and SentPacketSize() return the size of the
4908 referenced packet in octets.
4910 o NewMember(p) returns a 1 if the participant who sent packet p is
4911 not currently in the member list, 0 otherwise. Note this function
4912 is not sufficient for a complete implementation because each CSRC
4913 identifier in an RTP packet and each SSRC in a BYE packet should
4916 o NewSender(p) returns a 1 if the participant who sent packet p is
4917 not currently in the sender sublist of the member list, 0
4920 o AddMember() and RemoveMember() to add and remove participants from
4923 o AddSender() and RemoveSender() to add and remove participants from
4924 the sender sublist of the member list.
4930 Schulzrinne, et al. Standards Track [Page 88]
4932 RFC 3550 RTP July 2003
4935 These functions would have to be extended for an implementation that
4936 allows the RTCP bandwidth fractions for senders and non-senders to be
4937 specified as explicit parameters rather than fixed values of 25% and
4938 75%. The extended implementation of rtcp_interval() would need to
4939 avoid division by zero if one of the parameters was zero.
4941 double rtcp_interval(int members,
4945 double avg_rtcp_size,
4949 * Minimum average time between RTCP packets from this site (in
4950 * seconds). This time prevents the reports from `clumping' when
4951 * sessions are small and the law of large numbers isn't helping
4952 * to smooth out the traffic. It also keeps the report interval
4953 * from becoming ridiculously small during transient outages like
4954 * a network partition.
4956 double const RTCP_MIN_TIME = 5.;
4958 * Fraction of the RTCP bandwidth to be shared among active
4959 * senders. (This fraction was chosen so that in a typical
4960 * session with one or two active senders, the computed report
4961 * time would be roughly equal to the minimum report time so that
4962 * we don't unnecessarily slow down receiver reports.) The
4963 * receiver fraction must be 1 - the sender fraction.
4965 double const RTCP_SENDER_BW_FRACTION = 0.25;
4966 double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
4968 /* To compensate for "timer reconsideration" converging to a
4969 * value below the intended average.
4971 double const COMPENSATION = 2.71828 - 1.5;
4973 double t; /* interval */
4974 double rtcp_min_time = RTCP_MIN_TIME;
4975 int n; /* no. of members for computation */
4978 * Very first call at application start-up uses half the min
4979 * delay for quicker notification while still allowing some time
4980 * before reporting for randomization and to learn about other
4981 * sources so the report interval will converge to the correct
4982 * interval more quickly.
4986 Schulzrinne, et al. Standards Track [Page 89]
4988 RFC 3550 RTP July 2003
4996 * Dedicate a fraction of the RTCP bandwidth to senders unless
4997 * the number of senders is large enough that their share is
4998 * more than that fraction.
5001 if (senders <= members * RTCP_SENDER_BW_FRACTION) {
5003 rtcp_bw *= RTCP_SENDER_BW_FRACTION;
5006 rtcp_bw *= RTCP_RCVR_BW_FRACTION;
5012 * The effective number of sites times the average packet size is
5013 * the total number of octets sent when each site sends a report.
5014 * Dividing this by the effective bandwidth gives the time
5015 * interval over which those packets must be sent in order to
5016 * meet the bandwidth target, with a minimum enforced. In that
5017 * time interval we send one report so this time is also our
5018 * average time between reports.
5020 t = avg_rtcp_size * n / rtcp_bw;
5021 if (t < rtcp_min_time) t = rtcp_min_time;
5024 * To avoid traffic bursts from unintended synchronization with
5025 * other sites, we then pick our actual next report interval as a
5026 * random number uniformly distributed between 0.5*t and 1.5*t.
5028 t = t * (drand48() + 0.5);
5029 t = t / COMPENSATION;
5033 void OnExpire(event e,
5038 double *avg_rtcp_size,
5042 Schulzrinne, et al. Standards Track [Page 90]
5044 RFC 3550 RTP July 2003
5052 /* This function is responsible for deciding whether to send an
5053 * RTCP report or BYE packet now, or to reschedule transmission.
5054 * It is also responsible for updating the pmembers, initial, tp,
5055 * and avg_rtcp_size state variables. This function should be
5056 * called upon expiration of the event timer used by Schedule().
5059 double t; /* Interval */
5060 double tn; /* Next transmit time */
5062 /* In the case of a BYE, we use "timer reconsideration" to
5063 * reschedule the transmission of the BYE if necessary */
5065 if (TypeOfEvent(e) == EVENT_BYE) {
5066 t = rtcp_interval(members,
5080 } else if (TypeOfEvent(e) == EVENT_REPORT) {
5081 t = rtcp_interval(members,
5090 *avg_rtcp_size = (1./16.)*SentPacketSize(e) +
5091 (15./16.)*(*avg_rtcp_size);
5094 /* We must redraw the interval. Don't reuse the
5098 Schulzrinne, et al. Standards Track [Page 91]
5100 RFC 3550 RTP July 2003
5103 one computed above, since its not actually
5104 distributed the same, as we are conditioned
5105 on it being small enough to cause a packet to
5108 t = rtcp_interval(members,
5120 *pmembers = members;
5124 void OnReceive(packet p,
5129 double *avg_rtcp_size,
5134 /* What we do depends on whether we have left the group, and are
5135 * waiting to send a BYE (TypeOfEvent(e) == EVENT_BYE) or an RTCP
5136 * report. p represents the packet that was just received. */
5138 if (PacketType(p) == PACKET_RTCP_REPORT) {
5139 if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
5143 *avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
5144 (15./16.)*(*avg_rtcp_size);
5145 } else if (PacketType(p) == PACKET_RTP) {
5146 if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
5150 if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
5154 Schulzrinne, et al. Standards Track [Page 92]
5156 RFC 3550 RTP July 2003
5162 } else if (PacketType(p) == PACKET_BYE) {
5163 *avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
5164 (15./16.)*(*avg_rtcp_size);
5166 if (TypeOfEvent(e) == EVENT_REPORT) {
5167 if (NewSender(p) == FALSE) {
5172 if (NewMember(p) == FALSE) {
5177 if (*members < *pmembers) {
5179 (((double) *members)/(*pmembers))*(tn - tc);
5181 (((double) *members)/(*pmembers))*(tc - *tp);
5183 /* Reschedule the next report for time tn */
5186 *pmembers = *members;
5189 } else if (TypeOfEvent(e) == EVENT_BYE) {
5210 Schulzrinne, et al. Standards Track [Page 93]
5212 RFC 3550 RTP July 2003
5215 A.8 Estimating the Interarrival Jitter
5217 The code fragments below implement the algorithm given in Section
5218 6.4.1 for calculating an estimate of the statistical variance of the
5219 RTP data interarrival time to be inserted in the interarrival jitter
5220 field of reception reports. The inputs are r->ts, the timestamp from
5221 the incoming packet, and arrival, the current time in the same units.
5222 Here s points to state for the source; s->transit holds the relative
5223 transit time for the previous packet, and s->jitter holds the
5224 estimated jitter. The jitter field of the reception report is
5225 measured in timestamp units and expressed as an unsigned integer, but
5226 the jitter estimate is kept in a floating point. As each data packet
5227 arrives, the jitter estimate is updated:
5229 int transit = arrival - r->ts;
5230 int d = transit - s->transit;
5231 s->transit = transit;
5233 s->jitter += (1./16.) * ((double)d - s->jitter);
5235 When a reception report block (to which rr points) is generated for
5236 this member, the current jitter estimate is returned:
5238 rr->jitter = (u_int32) s->jitter;
5240 Alternatively, the jitter estimate can be kept as an integer, but
5241 scaled to reduce round-off error. The calculation is the same except
5244 s->jitter += d - ((s->jitter + 8) >> 4);
5246 In this case, the estimate is sampled for the reception report as:
5248 rr->jitter = s->jitter >> 4;
5266 Schulzrinne, et al. Standards Track [Page 94]
5268 RFC 3550 RTP July 2003
5271 Appendix B - Changes from RFC 1889
5273 Most of this RFC is identical to RFC 1889. There are no changes in
5274 the packet formats on the wire, only changes to the rules and
5275 algorithms governing how the protocol is used. The biggest change is
5276 an enhancement to the scalable timer algorithm for calculating when
5277 to send RTCP packets:
5279 o The algorithm for calculating the RTCP transmission interval
5280 specified in Sections 6.2 and 6.3 and illustrated in Appendix A.7
5281 is augmented to include "reconsideration" to minimize transmission
5282 in excess of the intended rate when many participants join a
5283 session simultaneously, and "reverse reconsideration" to reduce
5284 the incidence and duration of false participant timeouts when the
5285 number of participants drops rapidly. Reverse reconsideration is
5286 also used to possibly shorten the delay before sending RTCP SR
5287 when transitioning from passive receiver to active sender mode.
5289 o Section 6.3.7 specifies new rules controlling when an RTCP BYE
5290 packet should be sent in order to avoid a flood of packets when
5291 many participants leave a session simultaneously.
5293 o The requirement to retain state for inactive participants for a
5294 period long enough to span typical network partitions was removed
5295 from Section 6.2.1. In a session where many participants join for
5296 a brief time and fail to send BYE, this requirement would cause a
5297 significant overestimate of the number of participants. The
5298 reconsideration algorithm added in this revision compensates for
5299 the large number of new participants joining simultaneously when a
5302 It should be noted that these enhancements only have a significant
5303 effect when the number of session participants is large (thousands)
5304 and most of the participants join or leave at the same time. This
5305 makes testing in a live network difficult. However, the algorithm
5306 was subjected to a thorough analysis and simulation to verify its
5307 performance. Furthermore, the enhanced algorithm was designed to
5308 interoperate with the algorithm in RFC 1889 such that the degree of
5309 reduction in excess RTCP bandwidth during a step join is proportional
5310 to the fraction of participants that implement the enhanced
5311 algorithm. Interoperation of the two algorithms has been verified
5312 experimentally on live networks.
5314 Other functional changes were:
5316 o Section 6.2.1 specifies that implementations may store only a
5317 sampling of the participants' SSRC identifiers to allow scaling to
5318 very large sessions. Algorithms are specified in RFC 2762 [21].
5322 Schulzrinne, et al. Standards Track [Page 95]
5324 RFC 3550 RTP July 2003
5327 o In Section 6.2 it is specified that RTCP sender and non-sender
5328 bandwidths may be set as separate parameters of the session rather
5329 than a strict percentage of the session bandwidth, and may be set
5330 to zero. The requirement that RTCP was mandatory for RTP sessions
5331 using IP multicast was relaxed. However, a clarification was also
5332 added that turning off RTCP is NOT RECOMMENDED.
5334 o In Sections 6.2, 6.3.1 and Appendix A.7, it is specified that the
5335 fraction of participants below which senders get dedicated RTCP
5336 bandwidth changes from the fixed 1/4 to a ratio based on the RTCP
5337 sender and non-sender bandwidth parameters when those are given.
5338 The condition that no bandwidth is dedicated to senders when there
5339 are no senders was removed since that is expected to be a
5340 transitory state. It also keeps non-senders from using sender
5341 RTCP bandwidth when that is not intended.
5343 o Also in Section 6.2 it is specified that the minimum RTCP interval
5344 may be scaled to smaller values for high bandwidth sessions, and
5345 that the initial RTCP delay may be set to zero for unicast
5348 o Timing out a participant is to be based on inactivity for a number
5349 of RTCP report intervals calculated using the receiver RTCP
5350 bandwidth fraction even for active senders.
5352 o Sections 7.2 and 7.3 specify that translators and mixers should
5353 send BYE packets for the sources they are no longer forwarding.
5355 o Rule changes for layered encodings are defined in Sections 2.4,
5356 6.3.9, 8.3 and 11. In the last of these, it is noted that the
5357 address and port assignment rule conflicts with the SDP
5358 specification, RFC 2327 [15], but it is intended that this
5359 restriction will be relaxed in a revision of RFC 2327.
5361 o The convention for using even/odd port pairs for RTP and RTCP in
5362 Section 11 was clarified to refer to destination ports. The
5363 requirement to use an even/odd port pair was removed if the two
5364 ports are specified explicitly. For unicast RTP sessions,
5365 distinct port pairs may be used for the two ends (Sections 3, 7.1
5368 o A new Section 10 was added to explain the requirement for
5369 congestion control in applications using RTP.
5371 o In Section 8.2, the requirement that a new SSRC identifier MUST be
5372 chosen whenever the source transport address is changed has been
5373 relaxed to say that a new SSRC identifier MAY be chosen.
5374 Correspondingly, it was clarified that an implementation MAY
5378 Schulzrinne, et al. Standards Track [Page 96]
5380 RFC 3550 RTP July 2003
5383 choose to keep packets from the new source address rather than the
5384 existing source address when an SSRC collision occurs between two
5385 other participants, and SHOULD do so for applications such as
5386 telephony in which some sources such as mobile entities may change
5387 addresses during the course of an RTP session.
5389 o An indentation bug in the RFC 1889 printing of the pseudo-code for
5390 the collision detection and resolution algorithm in Section 8.2
5391 has been corrected by translating the syntax to pseudo C language,
5392 and the algorithm has been modified to remove the restriction that
5393 both RTP and RTCP must be sent from the same source port number.
5395 o The description of the padding mechanism for RTCP packets was
5396 clarified and it is specified that padding MUST only be applied to
5397 the last packet of a compound RTCP packet.
5399 o In Section A.1, initialization of base_seq was corrected to be seq
5400 rather than seq - 1, and the text was corrected to say the bad
5401 sequence number plus 1 is stored. The initialization of max_seq
5402 and other variables for the algorithm was separated from the text
5403 to make clear that this initialization must be done in addition to
5404 calling the init_seq() function (and a few words lost in RFC 1889
5405 when processing the document from source to output form were
5408 o Clamping of number of packets lost in Section A.3 was corrected to
5409 use both positive and negative limits.
5411 o The specification of "relative" NTP timestamp in the RTCP SR
5412 section now defines these timestamps to be based on the most
5413 common system-specific clock, such as system uptime, rather than
5414 on session elapsed time which would not be the same for multiple
5415 applications started on the same machine at different times.
5417 Non-functional changes:
5419 o It is specified that a receiver MUST ignore packets with payload
5420 types it does not understand.
5422 o In Fig. 2, the floating point NTP timestamp value was corrected,
5423 some missing leading zeros were added in a hex number, and the UTC
5424 timezone was specified.
5426 o The inconsequence of NTP timestamps wrapping around in the year
5434 Schulzrinne, et al. Standards Track [Page 97]
5436 RFC 3550 RTP July 2003
5439 o The policy for registration of RTCP packet types and SDES types
5440 was clarified in a new Section 15, IANA Considerations. The
5441 suggestion that experimenters register the numbers they need and
5442 then unregister those which prove to be unneeded has been removed
5443 in favor of using APP and PRIV. Registration of profile names was
5446 o The reference for the UTF-8 character set was changed from an
5447 X/Open Preliminary Specification to be RFC 2279.
5449 o The reference for RFC 1597 was updated to RFC 1918 and the
5450 reference for RFC 2543 was updated to RFC 3261.
5452 o The last paragraph of the introduction in RFC 1889, which
5453 cautioned implementors to limit deployment in the Internet, was
5454 removed because it was deemed no longer relevant.
5456 o A non-normative note regarding the use of RTP with Source-Specific
5457 Multicast (SSM) was added in Section 6.
5459 o The definition of "RTP session" in Section 3 was expanded to
5460 acknowledge that a single session may use multiple destination
5461 transport addresses (as was always the case for a translator or
5462 mixer) and to explain that the distinguishing feature of an RTP
5463 session is that each corresponds to a separate SSRC identifier
5464 space. A new definition of "multimedia session" was added to
5465 reduce confusion about the word "session".
5467 o The meaning of "sampling instant" was explained in more detail as
5468 part of the definition of the timestamp field of the RTP header in
5471 o Small clarifications of the text have been made in several places,
5472 some in response to questions from readers. In particular:
5474 - In RFC 1889, the first five words of the second sentence of
5475 Section 2.2 were lost in processing the document from source to
5476 output form, but are now restored.
5478 - A definition for "RTP media type" was added in Section 3 to
5479 allow the explanation of multiplexing RTP sessions in Section
5480 5.2 to be more clear regarding the multiplexing of multiple
5481 media. That section also now explains that multiplexing
5482 multiple sources of the same medium based on SSRC identifiers
5483 may be appropriate and is the norm for multicast sessions.
5485 - The definition for "non-RTP means" was expanded to include
5486 examples of other protocols constituting non-RTP means.
5490 Schulzrinne, et al. Standards Track [Page 98]
5492 RFC 3550 RTP July 2003
5495 - The description of the session bandwidth parameter is expanded
5496 in Section 6.2, including a clarification that the control
5497 traffic bandwidth is in addition to the session bandwidth for
5500 - The effect of varying packet duration on the jitter calculation
5501 was explained in Section 6.4.4.
5503 - The method for terminating and padding a sequence of SDES items
5504 was clarified in Section 6.5.
5506 - IPv6 address examples were added in the description of SDES
5507 CNAME in Section 6.5.1, and "example.com" was used in place of
5508 other example domain names.
5510 - The Security section added a formal reference to IPSEC now that
5511 it is available, and says that the confidentiality method
5512 defined in this specification is primarily to codify existing
5513 practice. It is RECOMMENDED that stronger encryption
5514 algorithms such as Triple-DES be used in place of the default
5515 algorithm, and noted that the SRTP profile based on AES will be
5516 the correct choice in the future. A caution about the weakness
5517 of the RTP header as an initialization vector was added. It
5518 was also noted that payload-only encryption is necessary to
5519 allow for header compression.
5521 - The method for partial encryption of RTCP was clarified; in
5522 particular, SDES CNAME is carried in only one part when the
5523 compound RTCP packet is split.
5525 - It is clarified that only one compound RTCP packet should be
5526 sent per reporting interval and that if there are too many
5527 active sources for the reports to fit in the MTU, then a subset
5528 of the sources should be selected round-robin over multiple
5531 - A note was added in Appendix A.1 that packets may be saved
5532 during RTP header validation and delivered upon success.
5534 - Section 7.3 now explains that a mixer aggregating SDES packets
5535 uses more RTCP bandwidth due to longer packets, and a mixer
5536 passing through RTCP naturally sends packets at higher than the
5537 single source rate, but both behaviors are valid.
5539 - Section 13 clarifies that an RTP application may use multiple
5540 profiles but typically only one in a given session.
5546 Schulzrinne, et al. Standards Track [Page 99]
5548 RFC 3550 RTP July 2003
5551 - The terms MUST, SHOULD, MAY, etc. are used as defined in RFC
5554 - The bibliography was divided into normative and informative
5559 Normative References
5561 [1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
5562 Conferences with Minimal Control", RFC 3551, July 2003.
5564 [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
5565 Levels", BCP 14, RFC 2119, March 1997.
5567 [3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
5569 [4] Mills, D., "Network Time Protocol (Version 3) Specification,
5570 Implementation and Analysis", RFC 1305, March 1992.
5572 [5] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC
5575 [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
5576 13, RFC 1034, November 1987.
5578 [7] Mockapetris, P., "Domain Names - Implementation and
5579 Specification", STD 13, RFC 1035, November 1987.
5581 [8] Braden, R., "Requirements for Internet Hosts - Application and
5582 Support", STD 3, RFC 1123, October 1989.
5584 [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
5586 Informative References
5588 [10] Clark, D. and D. Tennenhouse, "Architectural Considerations for
5589 a New Generation of Protocols," in SIGCOMM Symposium on
5590 Communications Architectures and Protocols , (Philadelphia,
5591 Pennsylvania), pp. 200--208, IEEE Computer Communications
5592 Review, Vol. 20(4), September 1990.
5594 [11] Schulzrinne, H., "Issues in designing a transport protocol for
5595 audio and video conferences and other multiparticipant real-time
5596 applications." expired Internet Draft, October 1993.
5602 Schulzrinne, et al. Standards Track [Page 100]
5604 RFC 3550 RTP July 2003
5607 [12] Comer, D., Internetworking with TCP/IP , vol. 1. Englewood
5608 Cliffs, New Jersey: Prentice Hall, 1991.
5610 [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
5611 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
5612 Session Initiation Protocol", RFC 3261, June 2002.
5614 [14] International Telecommunication Union, "Visual telephone systems
5615 and equipment for local area networks which provide a non-
5616 guaranteed quality of service", Recommendation H.323,
5617 Telecommunication Standardization Sector of ITU, Geneva,
5618 Switzerland, July 2003.
5620 [15] Handley, M. and V. Jacobson, "SDP: Session Description
5621 Protocol", RFC 2327, April 1998.
5623 [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
5624 Protocol (RTSP)", RFC 2326, April 1998.
5626 [17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness
5627 Recommendations for Security", RFC 1750, December 1994.
5629 [18] Bolot, J.-C., Turletti, T. and I. Wakeman, "Scalable Feedback
5630 Control for Multicast Video Distribution in the Internet", in
5631 SIGCOMM Symposium on Communications Architectures and Protocols,
5632 (London, England), pp. 58--67, ACM, August 1994.
5634 [19] Busse, I., Deffner, B. and H. Schulzrinne, "Dynamic QoS Control
5635 of Multimedia Applications Based on RTP", Computer
5636 Communications , vol. 19, pp. 49--58, January 1996.
5638 [20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
5639 Routing Messages", in SIGCOMM Symposium on Communications
5640 Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco,
5641 California), pp. 33--44, ACM, September 1993. Also in [34].
5643 [21] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
5644 Membership in RTP", RFC 2762, February 2000.
5646 [22] Cadzow, J., Foundations of Digital Signal Processing and Data
5647 Analysis New York, New York: Macmillan, 1987.
5649 [23] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
5650 Addressing Architecture", RFC 3513, April 2003.
5652 [24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
5653 Lear, "Address Allocation for Private Internets", RFC 1918,
5658 Schulzrinne, et al. Standards Track [Page 101]
5660 RFC 3550 RTP July 2003
5663 [25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "Network 10
5664 Considered Harmful (Some Practices Shouldn't be Codified)", RFC
5667 [26] Feller, W., An Introduction to Probability Theory and its
5668 Applications, vol. 1. New York, New York: John Wiley and Sons,
5671 [27] Kent, S. and R. Atkinson, "Security Architecture for the
5672 Internet Protocol", RFC 2401, November 1998.
5674 [28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M.,
5675 Norrman, K. and D. Oran, "Secure Real-time Transport Protocol",
5676 Work in Progress, April 2003.
5678 [29] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
5679 Part III", RFC 1423, February 1993.
5681 [30] Voydock, V. and S. Kent, "Security Mechanisms in High-Level
5682 Network Protocols", ACM Computing Surveys, vol. 15, pp. 135-171,
5685 [31] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
5688 [32] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
5691 [33] Stubblebine, S., "Security Services for Multimedia
5692 Conferencing", in 16th National Computer Security Conference,
5693 (Baltimore, Maryland), pp. 391--395, September 1993.
5695 [34] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
5696 Routing Messages", IEEE/ACM Transactions on Networking, vol. 2,
5697 pp. 122--136, April 1994.
5714 Schulzrinne, et al. Standards Track [Page 102]
5716 RFC 3550 RTP July 2003
5722 Department of Computer Science
5724 1214 Amsterdam Avenue
5728 EMail: schulzrinne@cs.columbia.edu
5733 3400 Hillview Avenue, Building 3
5737 EMail: casner@acm.org
5741 Blue Coat Systems Inc.
5746 EMail: ronf@bluecoat.com
5751 3400 Hillview Avenue, Building 3
5755 EMail: van@packetdesign.com
5770 Schulzrinne, et al. Standards Track [Page 103]
5772 RFC 3550 RTP July 2003
5775 Full Copyright Statement
5777 Copyright (C) The Internet Society (2003). All Rights Reserved.
5779 This document and translations of it may be copied and furnished to
5780 others, and derivative works that comment on or otherwise explain it
5781 or assist in its implementation may be prepared, copied, published
5782 and distributed, in whole or in part, without restriction of any
5783 kind, provided that the above copyright notice and this paragraph are
5784 included on all such copies and derivative works. However, this
5785 document itself may not be modified in any way, such as by removing
5786 the copyright notice or references to the Internet Society or other
5787 Internet organizations, except as needed for the purpose of
5788 developing Internet standards in which case the procedures for
5789 copyrights defined in the Internet Standards process must be
5790 followed, or as required to translate it into languages other than
5793 The limited permissions granted above are perpetual and will not be
5794 revoked by the Internet Society or its successors or assigns.
5796 This document and the information contained herein is provided on an
5797 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
5798 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
5799 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
5800 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
5801 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5805 Funding for the RFC Editor function is currently provided by the
5826 Schulzrinne, et al. Standards Track [Page 104]