1 2 3 4 5 6 7Network Working Group H. Schulzrinne 8Request for Comments: 3550 Columbia University 9Obsoletes: 1889 S. Casner 10Category: Standards Track Packet Design 11 R. Frederick 12 Blue Coat Systems Inc. 13 V. Jacobson 14 Packet Design 15 July 2003 16 17 18 RTP: A Transport Protocol for Real-Time Applications 19 20Status of this Memo 21 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. 27 28Copyright Notice 29 30 Copyright (C) The Internet Society (2003). All Rights Reserved. 31 32Abstract 33 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. 46 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. 54 55 56 57 58Schulzrinne, et al. Standards Track [Page 1] 59 60RFC 3550 RTP July 2003 61 62 63Table of Contents 64 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 111 112 113 114Schulzrinne, et al. Standards Track [Page 2] 115 116RFC 3550 RTP July 2003 117 118 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 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170Schulzrinne, et al. Standards Track [Page 3] 171 172RFC 3550 RTP July 2003 173 174 1751. Introduction 176 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 187 underlying network. 188 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. 198 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. 204 205 This document defines RTP, consisting of two closely-linked parts: 206 207 o the real-time transport protocol (RTP), to carry data that has 208 real-time properties. 209 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 218 document. 219 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 223 224 225 226Schulzrinne, et al. Standards Track [Page 4] 227 228RFC 3550 RTP July 2003 229 230 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 241 5.3 and 6.4.3. 242 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): 246 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 253 3551 [1]. 254 255 o payload format specification documents, which define how a 256 particular payload, such as an audio or video encoding, is to be 257 carried in RTP. 258 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]. 262 2631.1 Terminology 264 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. 269 2702. RTP Use Scenarios 271 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. 278 279 280 281 282Schulzrinne, et al. Standards Track [Page 5] 283 284RFC 3550 RTP July 2003 285 286 2872.1 Simple Multicast Audio Conference 288 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 299 the scope of RTP. 300 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 309 network congestion. 310 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 320 being lost. 321 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 332 conference. 333 334 335 336 337 338Schulzrinne, et al. Standards Track [Page 6] 339 340RFC 3550 RTP July 2003 341 342 3432.2 Audio and Video Conference 344 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 352 can be associated. 353 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 359 sessions. 360 3612.3 Mixers and Translators 362 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. 379 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. 391 392 393 394Schulzrinne, et al. Standards Track [Page 7] 395 396RFC 3550 RTP July 2003 397 398 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. 408 4092.4 Layered Encodings 410 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 419 "broadcast". 420 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 428 multicast groups. 429 430 Details of the use of RTP with layered encodings are given in 431 Sections 6.3.9, 8.3 and 11. 432 4333. Definitions 434 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. 438 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). 446 447 448 449 450Schulzrinne, et al. Standards Track [Page 8] 451 452RFC 3550 RTP July 2003 453 454 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. 462 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. 470 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. 475 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. 479 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. 484 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. 501 502 503 504 505 506Schulzrinne, et al. Standards Track [Page 9] 507 508RFC 3550 RTP July 2003 509 510 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 527 participants. 528 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. 532 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 550 SSRC. 551 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 559 560 561 562Schulzrinne, et al. Standards Track [Page 10] 563 564RFC 3550 RTP July 2003 565 566 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). 570 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. 575 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. 584 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. 590 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 602 session. 603 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 614 [16]). For simple 615 616 617 618Schulzrinne, et al. Standards Track [Page 11] 619 620RFC 3550 RTP July 2003 621 622 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. 626 6274. Byte Order, Alignment, and Time Format 628 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). 633 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 637 zero. 638 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 648 independently. 649 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. 655 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. 661 662 663 664 665 666 667 668 669 670 671 672 673 674Schulzrinne, et al. Standards Track [Page 12] 675 676RFC 3550 RTP July 2003 677 678 6795. RTP Data Transfer Protocol 680 6815.1 RTP Fixed Header Fields 682 683 The RTP header has the following format: 684 685 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | timestamp | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | synchronization source (SSRC) identifier | 693 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 694 | contributing source (CSRC) identifiers | 695 | .... | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 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: 701 702 version (V): 2 bits 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.) 707 708 padding (P): 1 bit 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 715 unit. 716 717 extension (X): 1 bit 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 720 5.3.1. 721 722 CSRC count (CC): 4 bits 723 The CSRC count contains the number of CSRC identifiers that follow 724 the fixed header. 725 726 727 728 729 730Schulzrinne, et al. Standards Track [Page 13] 731 732RFC 3550 RTP July 2003 733 734 735 marker (M): 1 bit 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). 741 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 751 (see Section 5.2). 752 753 A receiver MUST ignore packets with payload types that it does not 754 understand. 755 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]. 765 766 timestamp: 32 bits 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 783 784 785 786Schulzrinne, et al. Standards Track [Page 14] 787 788RFC 3550 RTP July 2003 789 790 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. 794 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.) 803 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. 816 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. 822 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. 832 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 839 840 841 842Schulzrinne, et al. Standards Track [Page 15] 843 844RFC 3550 RTP July 2003 845 846 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. 856 857 SSRC: 32 bits 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). 871 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 881 receiver. 882 8835.2 Multiplexing RTP Sessions 884 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 892 transport address. 893 894 895 896 897 898Schulzrinne, et al. Standards Track [Page 16] 899 900RFC 3550 RTP July 2003 901 902 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: 907 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. 912 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. 918 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. 922 923 4. An RTP mixer would not be able to combine interleaved streams of 924 incompatible media into one stream. 925 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. 933 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 936 two. 937 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. 945 946 947 948 949 950 951 952 953 954Schulzrinne, et al. Standards Track [Page 17] 955 956RFC 3550 RTP July 2003 957 958 9595.3 Profile-Specific Modifications to the RTP Header 960 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. 967 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 977 and the marker bit. 978 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. 984 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. 993 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. 997 9985.3.1 RTP Header Extension 999 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. 1006 1007 1008 1009 1010Schulzrinne, et al. Standards Track [Page 18] 1011 1012RFC 3550 RTP July 2003 1013 1014 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. 1023 1024 0 1 2 3 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 | 1030 | .... | 1031 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. 1046 10476. RTP Control Protocol -- RTCP 1048 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 1054 functions: 1055 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 1063 1064 1065 1066Schulzrinne, et al. Standards Track [Page 19] 1067 1068RFC 3550 RTP July 2003 1069 1070 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. 1081 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. 1091 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. 1099 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. 1110 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 1117 possible. 1118 1119 1120 1121 1122Schulzrinne, et al. Standards Track [Page 20] 1123 1124RFC 3550 RTP July 2003 1125 1126 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 1135 can be maintained. 1136 11376.1 RTCP Packet Format 1138 1139 This specification defines several RTCP packet types to carry a 1140 variety of control information: 1141 1142 SR: Sender report, for transmission and reception statistics from 1143 participants that are active senders 1144 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 1148 1149 SDES: Source description items, including CNAME 1150 1151 BYE: Indicates end of participation 1152 1153 APP: Application-specific functions 1154 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. 1166 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: 1171 1172 1173 1174 1175 1176 1177 1178Schulzrinne, et al. Standards Track [Page 21] 1179 1180RFC 3550 RTP July 2003 1181 1182 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. 1187 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. 1193 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 1198 unrelated packets. 1199 1200 Thus, all RTCP packets MUST be sent in a compound packet of at least 1201 two individual packets, with the following format: 1202 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. 1208 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. 1214 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. 1219 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). 1225 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 1229 more than once. 1230 1231 1232 1233 1234Schulzrinne, et al. Standards Track [Page 22] 1235 1236RFC 3550 RTP July 2003 1237 1238 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. 1249 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. 1261 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 1265 Section 15. 1266 1267 if encrypted: random 32-bit integer 1268 | 1269 |[--------- packet --------][---------- packet ----------][-packet-] 1270 | 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 -------------------------------------------------------------------- 1276 | | 1277 |<----------------------- compound packet ----------------------->| 1278 |<-------------------------- UDP packet ------------------------->| 1279 1280 #: SSRC/CSRC identifier 1281 1282 Figure 1: Example of an RTCP compound packet 1283 1284 1285 1286 1287 1288 1289 1290Schulzrinne, et al. Standards Track [Page 23] 1291 1292RFC 3550 RTP July 2003 1293 1294 12956.2 RTCP Transmission Interval 1296 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. 1308 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. 1324 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 1332 be calculated. 1333 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 1340 it travels. 1341 1342 1343 1344 1345 1346Schulzrinne, et al. Standards Track [Page 24] 1347 1348RFC 3550 RTP July 2003 1349 1350 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. 1370 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. 1377 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 1397 congestion. 1398 1399 1400 1401 1402Schulzrinne, et al. Standards Track [Page 25] 1403 1404RFC 3550 RTP July 2003 1405 1406 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. 1421 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: 1425 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. 1429 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. 1433 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 1438 prematurely. 1439 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. 1443 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: 1452 1453 1454 1455 1456 1457 1458Schulzrinne, et al. Standards Track [Page 26] 1459 1460RFC 3550 RTP July 2003 1461 1462 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 1466 across all members. 1467 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. 1473 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. 1478 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. 1490 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. 1496 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. 1503 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. 1508 1509 Details of the algorithm's operation are given in the sections that 1510 follow. Appendix A.7 gives an example implementation. 1511 1512 1513 1514Schulzrinne, et al. Standards Track [Page 27] 1515 1516RFC 3550 RTP July 2003 1517 1518 15196.2.1 Maintaining the Number of Session Members 1520 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. 1534 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. 1542 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 1550 MAY overestimate. 1551 15526.3 RTCP Packet Send and Receive Rules 1553 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. 1566 1567 1568 1569 1570Schulzrinne, et al. Standards Track [Page 28] 1571 1572RFC 3550 RTP July 2003 1573 1574 1575 To execute these rules, a session participant must maintain several 1576 pieces of state: 1577 1578 tp: the last time an RTCP packet was transmitted; 1579 1580 tc: the current time; 1581 1582 tn: the next scheduled transmission time of an RTCP packet; 1583 1584 pmembers: the estimated number of session members at the time tn 1585 was last recomputed; 1586 1587 members: the most current estimate for the number of session 1588 members; 1589 1590 senders: the most current estimate for the number of senders in 1591 the session; 1592 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 1597 startup. 1598 1599 we_sent: Flag that is true if the application has sent data 1600 since the 2nd previous RTCP report was transmitted. 1601 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. 1606 1607 initial: Flag that is true if the application has not yet sent 1608 an RTCP packet. 1609 1610 Many of these rules make use of the "calculated interval" between 1611 packet transmissions. This interval is described in the following 1612 section. 1613 16146.3.1 Computing the RTCP Transmission Interval 1615 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: 1621 1622 1623 1624 1625 1626Schulzrinne, et al. Standards Track [Page 29] 1627 1628RFC 3550 RTP July 2003 1629 1630 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. 1651 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. 1655 1656 3. The deterministic calculated interval Td is set to max(Tmin, n*C). 1657 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. 1660 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. 1664 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. 1670 16716.3.2 Initialization 1672 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 1679 1680 1681 1682Schulzrinne, et al. Standards Track [Page 30] 1683 1684RFC 3550 RTP July 2003 1685 1686 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. 1690 1691 The participant adds its own SSRC to the member table. 1692 16936.3.3 Receiving an RTP or Non-BYE RTCP Packet 1694 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. 1700 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. 1704 1705 For each compound RTCP packet received, the value of avg_rtcp_size is 1706 updated: 1707 1708 avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size 1709 1710 where packet_size is the size of the RTCP packet just received. 1711 17126.3.4 Receiving an RTCP BYE Packet 1713 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. 1720 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: 1725 1726 o The value for tn is updated according to the following formula: 1727 1728 tn = tc + (members/pmembers) * (tn - tc) 1729 1730 o The value for tp is updated according the following formula: 1731 1732 tp = tc - (members/pmembers) * (tc - tp). 1733 1734 1735 1736 1737 1738Schulzrinne, et al. Standards Track [Page 31] 1739 1740RFC 3550 RTP July 2003 1741 1742 1743 o The next RTCP packet is rescheduled for transmission at time tn, 1744 which is now earlier. 1745 1746 o The value of pmembers is set equal to members. 1747 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. 1755 17566.3.5 Timing Out an SSRC 1757 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. 1769 1770 If any members time out, the reverse reconsideration algorithm 1771 described in Section 6.3.4 SHOULD be performed. 1772 1773 The participant MUST perform this check at least once per RTCP 1774 transmission interval. 1775 17766.3.6 Expiration of Transmission Timer 1777 1778 When the packet transmission timer expires, the participant performs 1779 the following operations: 1780 1781 o The transmission interval T is computed as described in Section 1782 6.3.1, including the randomization factor. 1783 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. 1790 1791 1792 1793 1794Schulzrinne, et al. Standards Track [Page 32] 1795 1796RFC 3550 RTP July 2003 1797 1798 1799 o pmembers is set to members. 1800 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: 1803 1804 avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size 1805 1806 where packet_size is the size of the RTCP packet just transmitted. 1807 18086.3.7 Transmitting a BYE Packet 1809 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: 1817 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. 1824 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. 1833 1834 o Transmission of the BYE packet then follows the rules for 1835 transmitting a regular RTCP packet, as above. 1836 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. 1841 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. 1846 1847 1848 1849 1850Schulzrinne, et al. Standards Track [Page 33] 1851 1852RFC 3550 RTP July 2003 1853 1854 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. 1859 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. 1862 18636.3.8 Updating we_sent 1864 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. 1878 18796.3.9 Allocation of Source Description Bandwidth 1880 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. 1896 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 1903 1904 1905 1906Schulzrinne, et al. Standards Track [Page 34] 1907 1908RFC 3550 RTP July 2003 1909 1910 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 1915 EMAIL item. 1916 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). 1924 19256.4 Sender and Receiver Reports 1926 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. 1935 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. 1951 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 1956 Section 7. 1957 1958 1959 1960 1961 1962Schulzrinne, et al. Standards Track [Page 35] 1963 1964RFC 3550 RTP July 2003 1965 1966 19676.4.1 SR: Sender Report RTCP Packet 1968 1969 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972header |V=2|P| RC | PT=SR=200 | length | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | SSRC of sender | 1975 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1976sender | NTP timestamp, most significant word | 1977info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | NTP timestamp, least significant word | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | RTP timestamp | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | sender's packet count | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | sender's octet count | 1985 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1986report | SSRC_1 (SSRC of first source) | 1987block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 1 | fraction lost | cumulative number of packets lost | 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | extended highest sequence number received | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | interarrival jitter | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | last SR (LSR) | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 | delay since last SR (DLSR) | 1997 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1998report | SSRC_2 (SSRC of second source) | 1999block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 2 : ... : 2001 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2002 | profile-specific extensions | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 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 2008 following meaning: 2009 2010 version (V): 2 bits 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 2013 is two (2). 2014 2015 2016 2017 2018Schulzrinne, et al. Standards Track [Page 36] 2019 2020RFC 3550 RTP July 2003 2021 2022 2023 padding (P): 1 bit 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. 2039 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. 2043 2044 packet type (PT): 8 bits 2045 Contains the constant 200 to identify this as an RTCP SR packet. 2046 2047 length: 16 bits 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.) 2053 2054 SSRC: 32 bits 2055 The synchronization source identifier for the originator of this 2056 SR packet. 2057 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 2061 meaning: 2062 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 2071 2072 2073 2074Schulzrinne, et al. Standards Track [Page 37] 2075 2076RFC 3550 RTP July 2003 2077 2078 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 2090 timestamp to zero. 2091 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 2104 sampling instant. 2105 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 2110 SSRC identifier. 2111 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 2118 payload data rate. 2119 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: 2126 2127 2128 2129 2130Schulzrinne, et al. Standards Track [Page 38] 2131 2132RFC 3550 RTP July 2003 2133 2134 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. 2138 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. 2153 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. 2165 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. 2174 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; 2183 2184 2185 2186Schulzrinne, et al. Standards Track [Page 39] 2187 2188RFC 3550 RTP July 2003 2189 2190 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. 2194 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 2198 2199 D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) 2200 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 2205 2206 J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16 2207 2208 Whenever a reception report is issued, the current value of J is 2209 sampled. 2210 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. 2220 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. 2226 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. 2232 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 2239 2240 2241 2242Schulzrinne, et al. Standards Track [Page 40] 2243 2244RFC 3550 RTP July 2003 2245 2246 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. 2251 2252 This may be used as an approximate measure of distance to cluster 2253 receivers, although some links have very asymmetric delays. 2254 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 ----------------------------------------------------------------> 2258 v ^ 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 ^ 2262 r v ^ RR(n) 2263 ----------------------------------------------------------------> 2264 |<-DLSR->| 2265 (5.250 s) 2266 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) 2272 2273 Figure 2: Example for round-trip time computation 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298Schulzrinne, et al. Standards Track [Page 41] 2299 2300RFC 3550 RTP July 2003 2301 2302 23036.4.2 RR: Receiver Report RTCP Packet 2304 2305 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308header |V=2|P| RC | PT=RR=201 | length | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 | SSRC of packet sender | 2311 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2312report | SSRC_1 (SSRC of first source) | 2313block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 1 | fraction lost | cumulative number of packets lost | 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 | extended highest sequence number received | 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | interarrival jitter | 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 | last SR (LSR) | 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | delay since last SR (DLSR) | 2323 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2324report | SSRC_2 (SSRC of second source) | 2325block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 2 : ... : 2327 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2328 | profile-specific extensions | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 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. 2336 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 2339 report. 2340 23416.4.3 Extending the Sender and Receiver Reports 2342 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: 2348 2349 o fewer octets in the packet (no RTCP header or SSRC field); 2350 2351 2352 2353 2354Schulzrinne, et al. Standards Track [Page 42] 2355 2356RFC 3550 RTP July 2003 2357 2358 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. 2362 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 2371 field. 2372 23736.4.4 Analyzing Sender and Receiver Reports 2374 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. 2383 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. 2394 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 2406 2407 2408 2409 2410Schulzrinne, et al. Standards Track [Page 43] 2411 2412RFC 3550 RTP July 2003 2413 2414 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. 2418 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. 2427 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. 2435 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. 2447 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 2462 2463 2464 2465 2466Schulzrinne, et al. Standards Track [Page 44] 2467 2468RFC 3550 RTP July 2003 2469 2470 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 2473 inconsequential. 2474 24756.5 SDES: Source Description RTCP Packet 2476 2477 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480header |V=2|P| SC | PT=SDES=202 | length | 2481 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2482chunk | SSRC/CSRC_1 | 2483 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | SDES items | 2485 | ... | 2486 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2487chunk | SSRC/CSRC_2 | 2488 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | SDES items | 2490 | ... | 2491 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2492 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. 2497 2498 version (V), padding (P), length: 2499 As described for the SR packet (see Section 6.4.1). 2500 2501 packet type (PT): 8 bits 2502 Contains the constant 202 to identify this as an RTCP SDES packet. 2503 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. 2507 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. 2515 2516 2517 2518 2519 2520 2521 2522Schulzrinne, et al. Standards Track [Page 45] 2523 2524RFC 3550 RTP July 2003 2525 2526 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 2531 value of one. 2532 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. 2543 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). 2550 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 2557 Section 15. 2558 25596.5.1 CNAME: Canonical End-Point Identifier SDES Item 2560 2561 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 2567 The CNAME identifier has the following properties: 2568 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. 2574 2575 2576 2577 2578Schulzrinne, et al. Standards Track [Page 46] 2579 2580RFC 3550 RTP July 2003 2581 2582 2583 o Like the SSRC identifier, the CNAME identifier SHOULD also be 2584 unique among all participants within one RTP session. 2585 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. 2589 2590 o To facilitate third-party monitoring, the CNAME SHOULD be suitable 2591 for either a program or a person to locate the source. 2592 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. 2614 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". 2619 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. 2624 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. 2630 2631 2632 2633 2634Schulzrinne, et al. Standards Track [Page 47] 2635 2636RFC 3550 RTP July 2003 2637 2638 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. 2645 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 2656 from being exposed. 2657 26586.5.2 NAME: User Name SDES Item 2659 2660 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 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. 2674 26756.5.3 EMAIL: Electronic Mail Address SDES Item 2676 2677 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 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. 2686 2687 2688 2689 2690Schulzrinne, et al. Standards Track [Page 48] 2691 2692RFC 3550 RTP July 2003 2693 2694 26956.5.4 PHONE: Phone Number SDES Item 2696 2697 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 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. 2706 27076.5.5 LOC: Geographic User Location SDES Item 2708 2709 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 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. 2723 27246.5.6 TOOL: Application or Tool Name SDES Item 2725 2726 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 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. 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746Schulzrinne, et al. Standards Track [Page 49] 2747 2748RFC 3550 RTP July 2003 2749 2750 27516.5.7 NOTE: Notice/Status SDES Item 2752 2753 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 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. 2770 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. 2780 27816.5.8 PRIV: Private Extensions SDES Item 2782 2783 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 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 2799 2800 2801 2802Schulzrinne, et al. Standards Track [Page 50] 2803 2804RFC 3550 RTP July 2003 2805 2806 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. 2810 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. 2816 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 2821 efficiency. 2822 28236.6 BYE: Goodbye RTCP Packet 2824 2825 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 | SSRC/CSRC | 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 : ... : 2833 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2834(opt) | length | reason for leaving ... 2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 2837 The BYE packet indicates that one or more sources are no longer 2838 active. 2839 2840 version (V), padding (P), length: 2841 As described for the SR packet (see Section 6.4.1). 2842 2843 packet type (PT): 8 bits 2844 Contains the constant 203 to identify this as an RTCP BYE packet. 2845 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. 2849 2850 The rules for when a BYE packet should be sent are specified in 2851 Sections 6.3.7 and 8.2. 2852 2853 2854 2855 2856 2857 2858Schulzrinne, et al. Standards Track [Page 51] 2859 2860RFC 3550 RTP July 2003 2861 2862 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. 2875 28766.7 APP: Application-Defined RTCP Packet 2877 2878 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2883 | SSRC/CSRC | 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 | name (ASCII) | 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | application-dependent data ... 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 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. 2896 2897 version (V), padding (P), length: 2898 As described for the SR packet (see Section 6.4.1). 2899 2900 subtype: 5 bits 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 2903 data. 2904 2905 packet type (PT): 8 bits 2906 Contains the constant 204 to identify this as an RTCP APP packet. 2907 2908 2909 2910 2911 2912 2913 2914Schulzrinne, et al. Standards Track [Page 52] 2915 2916RFC 3550 RTP July 2003 2917 2918 2919 name: 4 octets 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. 2930 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. 2935 29367. RTP Translators and Mixers 2937 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. 2946 29477.1 General Description 2948 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. 2957 2958 In order to avoid creating a loop when a translator or mixer is 2959 installed, the following rules MUST be observed: 2960 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. 2965 2966 2967 2968 2969 2970Schulzrinne, et al. Standards Track [Page 53] 2971 2972RFC 3550 RTP July 2003 2973 2974 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. 2978 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. 2984 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 2992 stream: 2993 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. 3007 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. 3022 3023 3024 3025 3026Schulzrinne, et al. Standards Track [Page 54] 3027 3028RFC 3550 RTP July 2003 3029 3030 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. 3034 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. 3045 3046 [E1] [E6] 3047 | | 3048 E1:17 | E6:15 | 3049 | | E6:15 3050 V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17) 3051 (M1)-------------><T1>-----------------><T2>-------------->[E7] 3052 ^ ^ E4:47 ^ E4:47 3053 E2:1 | E4:47 | | M3:89 (64,45) 3054 | | | 3055 [E2] [E4] M3:89 (64,45) | 3056 | legend: 3057 [E3] --------->(M2)----------->(M3)------------| [End system] 3058 E3:64 M2:12 (64) ^ (Mixer) 3059 | E5:45 <Translator> 3060 | 3061 [E5] source: SSRC (CSRCs) 3062 -------------------> 3063 3064 Figure 3: Sample RTP network with end systems, mixers and translators 3065 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. 3073 30747.2 RTCP Processing in Translators 3075 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 3079 3080 3081 3082Schulzrinne, et al. Standards Track [Page 55] 3083 3084RFC 3550 RTP July 2003 3085 3086 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 3090 itself. 3091 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 3102 DLSR fields. 3103 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. 3113 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 3125 translation. 3126 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. 3133 3134 3135 3136 3137 3138Schulzrinne, et al. Standards Track [Page 56] 3139 3140RFC 3550 RTP July 2003 3141 3142 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. 3150 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. 3156 3157 APP: Translators forward APP packets unchanged. 3158 31597.3 RTCP Processing in Mixers 3160 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. 3164 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. 3171 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 3177 there (only CSRCs). 3178 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 3187 packets. 3188 3189 3190 3191 3192 3193 3194Schulzrinne, et al. Standards Track [Page 57] 3195 3196RFC 3550 RTP July 2003 3197 3198 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. 3212 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 3217 detected. 3218 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. 3224 3225 APP: The treatment of APP packets by mixers is application-specific. 3226 32277.4 Cascaded Mixers 3228 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. 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250Schulzrinne, et al. Standards Track [Page 58] 3251 3252RFC 3550 RTP July 2003 3253 3254 32558. SSRC Identifier Allocation and Use 3256 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. 3262 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. 3269 3270 Multiple sources running on one host would also conflict. 3271 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 3275 Appendix A.6. 3276 32778.1 Probability of Collision 3278 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 3287 roughly 10**-4. 3288 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. 3296 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 3301 3302 3303 3304 3305 3306Schulzrinne, et al. Standards Track [Page 59] 3307 3308RFC 3550 RTP July 2003 3309 3310 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 3313 else choose again. 3314 33158.2 Collision Resolution and Loop Detection 3316 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. 3328 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: 3334 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 3339 network sources. 3340 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 3345 loop. 3346 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 3351 data packet. 3352 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. 3359 3360 3361 3362Schulzrinne, et al. Standards Track [Page 60] 3363 3364RFC 3550 RTP July 2003 3365 3366 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. 3378 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. 3384 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 3396 of BYE packets. 3397 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 3405 addresses. 3406 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 3415 3416 3417 3418Schulzrinne, et al. Standards Track [Page 61] 3419 3420RFC 3550 RTP July 2003 3421 3422 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). 3430 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. 3438 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). 3450 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. 3455 3456 if (SSRC or CSRC identifier is not found in the source 3457 identifier table) { 3458 create a new entry storing the data or control source 3459 transport address, the SSRC or CSRC and other state; 3460 } 3461 3462 /* Identifier is found in the table */ 3463 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; 3467 } 3468 else if (source transport address from the packet does not match 3469 the one saved in the table entry for this identifier) { 3470 3471 3472 3473 3474Schulzrinne, et al. Standards Track [Page 62] 3475 3476RFC 3550 RTP July 2003 3477 3478 3479 /* An identifier collision or a loop is indicated */ 3480 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; 3487 } else { 3488 count a third-party loop; 3489 } 3490 abort processing of data packet or control element; 3491 /* MAY choose a different policy to keep new source */ 3492 } 3493 3494 /* A collision or loop of the participant's own packets */ 3495 3496 else if (source transport address is found in the list of 3497 conflicting data or control source transport 3498 addresses) { 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; 3504 } 3505 mark current time in conflicting address list entry; 3506 abort processing of data packet or control element; 3507 } 3508 3509 /* New collision, change SSRC identifier */ 3510 3511 else { 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; 3520 } 3521 } 3522 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 3527 3528 3529 3530Schulzrinne, et al. Standards Track [Page 63] 3531 3532RFC 3550 RTP July 2003 3533 3534 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. 3539 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. 3551 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 3556 repeated. 3557 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). 3570 35718.3 Use with Layered Encodings 3572 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. 3580 3581 3582 3583 3584 3585 3586Schulzrinne, et al. Standards Track [Page 64] 3587 3588RFC 3550 RTP July 2003 3589 3590 35919. Security 3592 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. 3606 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 3619 appropriate use. 3620 3621 Key distribution and certificates are outside the scope of this 3622 document. 3623 36249.1 Confidentiality 3625 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 3629 encryption. 3630 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 3638 3639 3640 3641 3642Schulzrinne, et al. Standards Track [Page 65] 3643 3644RFC 3550 RTP July 2003 3645 3646 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. 3650 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. 3663 3664 UDP packet UDP packet 3665 ----------------------------- ------------------------------ 3666 [random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2] 3667 ----------------------------- ------------------------------ 3668 encrypted not encrypted 3669 3670 #: SSRC identifier 3671 3672 Figure 4: Encrypted and non-encrypted RTCP packets 3673 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. 3678 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 3687 vectors, see [30]. 3688 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. 3695 3696 3697 3698Schulzrinne, et al. Standards Track [Page 66] 3699 3700RFC 3550 RTP July 2003 3701 3702 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. 3718 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. 3730 37319.2 Authentication and Message Integrity 3732 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. 3737 373810. Congestion Control 3739 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. 3750 3751 3752 3753 3754Schulzrinne, et al. Standards Track [Page 67] 3755 3756RFC 3550 RTP July 2003 3757 3758 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. 3767 376811. RTP over Network and Transport Protocols 3769 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 3773 specification. 3774 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 3790 streams. 3791 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. 3803 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 3807 3808 3809 3810Schulzrinne, et al. Standards Track [Page 68] 3811 3812RFC 3550 RTP July 2003 3813 3814 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 3823 address ranges. 3824 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. 3832 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. 3837 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 3844 defined here. 3845 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. 3852 385312. Summary of Protocol Constants 3854 3855 This section contains a summary listing of the constants defined in 3856 this specification. 3857 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 3863 3864 3865 3866Schulzrinne, et al. Standards Track [Page 69] 3867 3868RFC 3550 RTP July 2003 3869 3870 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. 3874 387512.1 RTCP Packet Types 3876 3877 abbrev. name value 3878 SR sender report 200 3879 RR receiver report 201 3880 SDES source description 202 3881 BYE goodbye 203 3882 APP application-defined 204 3883 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. 3893 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. 3897 3898 Additional RTCP packet types may be registered through IANA (see 3899 Section 15). 3900 390112.2 SDES Types 3902 3903 abbrev. name value 3904 END end of SDES list 0 3905 CNAME canonical name 1 3906 NAME user name 2 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 3913 3914 Additional SDES types may be registered through IANA (see Section 3915 15). 3916 3917 3918 3919 3920 3921 3922Schulzrinne, et al. Standards Track [Page 70] 3923 3924RFC 3550 RTP July 2003 3925 3926 392713. RTP Profiles and Payload Format Specifications 3928 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. 3932 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 3943 Profile for ...". 3944 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. 3953 3954 Within this specification, the following items have been identified 3955 for possible definition within a profile, but this list is not meant 3956 to be exhaustive: 3957 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). 3962 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). 3970 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). 3975 3976 3977 3978Schulzrinne, et al. Standards Track [Page 71] 3979 3980RFC 3550 RTP July 2003 3981 3982 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). 3987 3988 RTCP packet types: New application-class-specific RTCP packet 3989 types MAY be defined and registered with IANA. 3990 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. 3998 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). 4003 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. 4010 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). 4014 4015 String-to-key mapping: A profile MAY specify how a user-provided 4016 password or pass phrase is mapped into an encryption key. 4017 4018 Congestion: A profile SHOULD specify the congestion control 4019 behavior appropriate for that profile. 4020 4021 Underlying protocol: Use of a particular underlying network or 4022 transport layer protocol to carry RTP packets MAY be required. 4023 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. 4027 4028 4029 4030 4031 4032 4033 4034Schulzrinne, et al. Standards Track [Page 72] 4035 4036RFC 3550 RTP July 2003 4037 4038 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). 4043 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 4052 specification. 4053 405414. Security Considerations 4055 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 4067 Section 9. 4068 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 4074 firewall. 4075 407615. IANA Considerations 4077 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." 4087 4088 4089 4090Schulzrinne, et al. Standards Track [Page 73] 4091 4092RFC 3550 RTP July 2003 4093 4094 4095 (Contact the IANA for the contact information of the current expert.) 4096 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. 4102 410316. Intellectual Property Rights Statement 4104 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. 4118 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 4123 Director. 4124 412517. Acknowledgments 4126 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 4136 Steve McCanne. 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146Schulzrinne, et al. Standards Track [Page 74] 4147 4148RFC 3550 RTP July 2003 4149 4150 4151Appendix A - Algorithms 4152 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. 4158 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. 4165 4166 /* 4167 * rtp.h -- RTP header file 4168 */ 4169 #include <sys/types.h> 4170 4171 /* 4172 * The type definitions below are valid for 32-bit architectures and 4173 * may have to be adjusted for 16- or 64-bit architectures. 4174 */ 4175 typedef unsigned char u_int8; 4176 typedef unsigned short u_int16; 4177 typedef unsigned int u_int32; 4178 typedef short int16; 4179 4180 /* 4181 * Current protocol version. 4182 */ 4183 #define RTP_VERSION 2 4184 4185 #define RTP_SEQ_MOD (1<<16) 4186 #define RTP_MAX_SDES 255 /* maximum text length for SDES */ 4187 4188 typedef enum { 4189 RTCP_SR = 200, 4190 RTCP_RR = 201, 4191 RTCP_SDES = 202, 4192 RTCP_BYE = 203, 4193 RTCP_APP = 204 4194 } rtcp_type_t; 4195 4196 typedef enum { 4197 RTCP_SDES_END = 0, 4198 RTCP_SDES_CNAME = 1, 4199 4200 4201 4202Schulzrinne, et al. Standards Track [Page 75] 4203 4204RFC 3550 RTP July 2003 4205 4206 4207 RTCP_SDES_NAME = 2, 4208 RTCP_SDES_EMAIL = 3, 4209 RTCP_SDES_PHONE = 4, 4210 RTCP_SDES_LOC = 5, 4211 RTCP_SDES_TOOL = 6, 4212 RTCP_SDES_NOTE = 7, 4213 RTCP_SDES_PRIV = 8 4214 } rtcp_sdes_type_t; 4215 4216 /* 4217 * RTP data header 4218 */ 4219 typedef struct { 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 */ 4230 } rtp_hdr_t; 4231 4232 /* 4233 * RTCP common header word 4234 */ 4235 typedef struct { 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 */ 4241 } rtcp_common_t; 4242 4243 /* 4244 * Big-endian mask for version, padding bit and packet type pair 4245 */ 4246 #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe) 4247 #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR) 4248 4249 /* 4250 * Reception report block 4251 */ 4252 typedef struct { 4253 u_int32 ssrc; /* data source being reported */ 4254 unsigned int fraction:8; /* fraction lost since last SR/RR */ 4255 4256 4257 4258Schulzrinne, et al. Standards Track [Page 76] 4259 4260RFC 3550 RTP July 2003 4261 4262 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 */ 4268 } rtcp_rr_t; 4269 4270 /* 4271 * SDES item 4272 */ 4273 typedef struct { 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 */ 4277 } rtcp_sdes_item_t; 4278 4279 /* 4280 * One RTCP packet 4281 */ 4282 typedef struct { 4283 rtcp_common_t common; /* common header */ 4284 union { 4285 /* sender report (SR) */ 4286 struct { 4287 u_int32 ssrc; /* sender generating this report */ 4288 u_int32 ntp_sec; /* NTP timestamp */ 4289 u_int32 ntp_frac; 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 */ 4294 } sr; 4295 4296 /* reception report (RR) */ 4297 struct { 4298 u_int32 ssrc; /* receiver generating this report */ 4299 rtcp_rr_t rr[1]; /* variable-length list */ 4300 } rr; 4301 4302 /* source description (SDES) */ 4303 struct rtcp_sdes { 4304 u_int32 src; /* first SSRC/CSRC */ 4305 rtcp_sdes_item_t item[1]; /* list of SDES items */ 4306 } sdes; 4307 4308 /* BYE */ 4309 struct { 4310 u_int32 src[1]; /* list of sources */ 4311 4312 4313 4314Schulzrinne, et al. Standards Track [Page 77] 4315 4316RFC 3550 RTP July 2003 4317 4318 4319 /* can't express trailing text for reason */ 4320 } bye; 4321 } r; 4322 } rtcp_t; 4323 4324 typedef struct rtcp_sdes rtcp_sdes_t; 4325 4326 /* 4327 * Per-source state information 4328 */ 4329 typedef struct { 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 */ 4340 /* ... */ 4341 } source; 4342 4343A.1 RTP Data Header Validity Checks 4344 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. 4353 4354 Only weak validity checks are possible on an RTP data packet from a 4355 source that has not been heard before: 4356 4357 o RTP version field must equal 2. 4358 4359 o The payload type must be known, and in particular it must not be 4360 equal to SR or RR. 4361 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. 4365 4366 4367 4368 4369 4370Schulzrinne, et al. Standards Track [Page 78] 4371 4372RFC 3550 RTP July 2003 4373 4374 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. 4379 4380 o The length of the packet must be consistent with CC and payload 4381 type (if payloads have a known length). 4382 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. 4393 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. 4399 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: 4405 4406 init_seq(s, seq); 4407 s->max_seq = seq - 1; 4408 s->probation = MIN_SEQUENTIAL; 4409 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. 4413 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. 4421 4422 4423 4424 4425 4426Schulzrinne, et al. Standards Track [Page 79] 4427 4428RFC 3550 RTP July 2003 4429 4430 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. 4438 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 4445 restart. 4446 4447 void init_seq(source *s, u_int16 seq) 4448 { 4449 s->base_seq = seq; 4450 s->max_seq = seq; 4451 s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */ 4452 s->cycles = 0; 4453 s->received = 0; 4454 s->received_prior = 0; 4455 s->expected_prior = 0; 4456 /* other initialization */ 4457 } 4458 4459 int update_seq(source *s, u_int16 seq) 4460 { 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; 4465 4466 /* 4467 * Source is not valid until MIN_SEQUENTIAL packets with 4468 * sequential sequence numbers have been received. 4469 */ 4470 if (s->probation) { 4471 /* packet is in sequence */ 4472 if (seq == s->max_seq + 1) { 4473 s->probation--; 4474 s->max_seq = seq; 4475 if (s->probation == 0) { 4476 init_seq(s, seq); 4477 s->received++; 4478 return 1; 4479 4480 4481 4482Schulzrinne, et al. Standards Track [Page 80] 4483 4484RFC 3550 RTP July 2003 4485 4486 4487 } 4488 } else { 4489 s->probation = MIN_SEQUENTIAL - 1; 4490 s->max_seq = seq; 4491 } 4492 return 0; 4493 } else if (udelta < MAX_DROPOUT) { 4494 /* in order, with permissible gap */ 4495 if (seq < s->max_seq) { 4496 /* 4497 * Sequence number wrapped - count another 64K cycle. 4498 */ 4499 s->cycles += RTP_SEQ_MOD; 4500 } 4501 s->max_seq = seq; 4502 } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) { 4503 /* the sequence number made a very large jump */ 4504 if (seq == s->bad_seq) { 4505 /* 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). 4509 */ 4510 init_seq(s, seq); 4511 } 4512 else { 4513 s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1); 4514 return 0; 4515 } 4516 } else { 4517 /* duplicate or reordered packet */ 4518 } 4519 s->received++; 4520 return 1; 4521 } 4522 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. 4533 4534 4535 4536 4537 4538Schulzrinne, et al. Standards Track [Page 81] 4539 4540RFC 3550 RTP July 2003 4541 4542 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). 4549 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 4556 time. 4557 4558A.2 RTCP Header Validity Checks 4559 4560 The following checks should be applied to RTCP packets. 4561 4562 o RTP version field must equal 2. 4563 4564 o The payload type field of the first RTCP packet in a compound 4565 packet must be equal to SR or RR. 4566 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. 4570 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. 4574 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. 4578 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 */ 4582 4583 if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) { 4584 /* something wrong with packet format */ 4585 } 4586 end = (rtcp_t *)((u_int32 *)r + len); 4587 4588 do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1); 4589 while (r < end && r->common.version == 2); 4590 4591 4592 4593 4594Schulzrinne, et al. Standards Track [Page 82] 4595 4596RFC 3550 RTP July 2003 4597 4598 4599 if (r != end) { 4600 /* something wrong with packet format */ 4601 } 4602 4603A.3 Determining Number of Packets Expected and Lost 4604 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. 4618 4619 extended_max = s->cycles + s->max_seq; 4620 expected = extended_max - s->base_seq + 1; 4621 4622 The number of packets lost is defined to be the number of packets 4623 expected less the number of packets actually received: 4624 4625 lost = expected - s->received; 4626 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. 4630 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: 4636 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; 4644 4645 The resulting fraction is an 8-bit fixed point number with the binary 4646 point at the left edge. 4647 4648 4649 4650Schulzrinne, et al. Standards Track [Page 83] 4651 4652RFC 3550 RTP July 2003 4653 4654 4655A.4 Generating RTCP SDES Packets 4656 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. 4660 4661 char *rtp_write_sdes(char *b, u_int32 src, int argc, 4662 rtcp_sdes_type_t type[], char *value[], 4663 int length[]) 4664 { 4665 rtcp_sdes_t *s = (rtcp_sdes_t *)b; 4666 rtcp_sdes_item_t *rsp; 4667 int i; 4668 int len; 4669 int pad; 4670 4671 /* SSRC header */ 4672 s->src = src; 4673 rsp = &s->item[0]; 4674 4675 /* SDES items */ 4676 for (i = 0; i < argc; i++) { 4677 rsp->type = type[i]; 4678 len = length[i]; 4679 if (len > RTP_MAX_SDES) { 4680 /* invalid length, may want to take other action */ 4681 len = RTP_MAX_SDES; 4682 } 4683 rsp->length = len; 4684 memcpy(rsp->data, value[i], len); 4685 rsp = (rtcp_sdes_item_t *)&rsp->data[len]; 4686 } 4687 4688 /* terminate with end marker and pad to next 4-octet boundary */ 4689 len = ((char *) rsp) - b; 4690 pad = 4 - (len & 0x3); 4691 b = (char *) rsp; 4692 while (pad--) *b++ = RTCP_SDES_END; 4693 4694 return b; 4695 } 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706Schulzrinne, et al. Standards Track [Page 84] 4707 4708RFC 3550 RTP July 2003 4709 4710 4711A.5 Parsing RTCP SDES Packets 4712 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 4717 the RTCP packet. 4718 4719 void rtp_read_sdes(rtcp_t *r) 4720 { 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); 4726 source *s; 4727 4728 while (--count >= 0) { 4729 rsp = &sd->item[0]; 4730 if (rsp >= end) break; 4731 s = find_member(sd->src); 4732 4733 for (; rsp->type; rsp = rspn ) { 4734 rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2); 4735 if (rspn >= end) { 4736 rsp = rspn; 4737 break; 4738 } 4739 member_sdes(s, rsp->type, rsp->data, rsp->length); 4740 } 4741 sd = (rtcp_sdes_t *) 4742 ((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1); 4743 } 4744 if (count >= 0) { 4745 /* invalid packet format */ 4746 } 4747 } 4748 4749A.6 Generating a Random 32-bit Identifier 4750 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 4756 4757 4758 4759 4760 4761 4762Schulzrinne, et al. Standards Track [Page 85] 4763 4764RFC 3550 RTP July 2003 4765 4766 4767 o getdomainname(), 4768 4769 o getwd(), or 4770 4771 o getrusage(). 4772 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]. 4776 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. 4786 4787 /* 4788 * Generate a random 32-bit quantity. 4789 */ 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 */ 4798 4799 #define MD_CTX MD5_CTX 4800 #define MDInit MD5Init 4801 #define MDUpdate MD5Update 4802 #define MDFinal MD5Final 4803 4804 static u_long md_32(char *string, int length) 4805 { 4806 MD_CTX context; 4807 union { 4808 char c[16]; 4809 u_long x[4]; 4810 } digest; 4811 u_long r; 4812 int i; 4813 4814 MDInit (&context); 4815 4816 4817 4818Schulzrinne, et al. Standards Track [Page 86] 4819 4820RFC 3550 RTP July 2003 4821 4822 4823 MDUpdate (&context, string, length); 4824 MDFinal ((unsigned char *)&digest, &context); 4825 r = 0; 4826 for (i = 0; i < 3; i++) { 4827 r ^= digest.x[i]; 4828 } 4829 return r; 4830 } /* md_32 */ 4831 4832 /* 4833 * Return random unsigned 32-bit quantity. Use 'type' argument if 4834 * you need to generate several different values in close succession. 4835 */ 4836 u_int32 random32(int type) 4837 { 4838 struct { 4839 int type; 4840 struct timeval tv; 4841 clock_t cpu; 4842 pid_t pid; 4843 u_long hid; 4844 uid_t uid; 4845 gid_t gid; 4846 struct utsname name; 4847 } s; 4848 4849 gettimeofday(&s.tv, 0); 4850 uname(&s.name); 4851 s.type = type; 4852 s.cpu = clock(); 4853 s.pid = getpid(); 4854 s.hid = gethostid(); 4855 s.uid = getuid(); 4856 s.gid = getgid(); 4857 /* also: system uptime */ 4858 4859 return md_32((char *)&s, sizeof(s)); 4860 } /* random32 */ 4861 4862A.7 Computing the RTCP Transmission Interval 4863 4864 The following functions implement the RTCP transmission and reception 4865 rules described in Section 6.2. These rules are coded in several 4866 functions: 4867 4868 o rtcp_interval() computes the deterministic calculated interval, 4869 measured in seconds. The parameters are defined in Section 6.3. 4870 4871 4872 4873 4874Schulzrinne, et al. Standards Track [Page 87] 4875 4876RFC 3550 RTP July 2003 4877 4878 4879 o OnExpire() is called when the RTCP transmission timer expires. 4880 4881 o OnReceive() is called whenever an RTCP packet is received. 4882 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 4886 available: 4887 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 4890 argument. 4891 4892 o Reschedule(time t, event e) reschedules a previously scheduled 4893 event e for time t. 4894 4895 o SendRTCPReport(event e) sends an RTCP report. 4896 4897 o SendBYEPacket(event e) sends a BYE packet. 4898 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 4901 EVENT_REPORT. 4902 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. 4906 4907 o ReceivedPacketSize() and SentPacketSize() return the size of the 4908 referenced packet in octets. 4909 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 4914 be processed. 4915 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 4918 otherwise. 4919 4920 o AddMember() and RemoveMember() to add and remove participants from 4921 the member list. 4922 4923 o AddSender() and RemoveSender() to add and remove participants from 4924 the sender sublist of the member list. 4925 4926 4927 4928 4929 4930Schulzrinne, et al. Standards Track [Page 88] 4931 4932RFC 3550 RTP July 2003 4933 4934 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. 4940 4941 double rtcp_interval(int members, 4942 int senders, 4943 double rtcp_bw, 4944 int we_sent, 4945 double avg_rtcp_size, 4946 int initial) 4947 { 4948 /* 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. 4955 */ 4956 double const RTCP_MIN_TIME = 5.; 4957 /* 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. 4964 */ 4965 double const RTCP_SENDER_BW_FRACTION = 0.25; 4966 double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION); 4967 /* 4968 /* To compensate for "timer reconsideration" converging to a 4969 * value below the intended average. 4970 */ 4971 double const COMPENSATION = 2.71828 - 1.5; 4972 4973 double t; /* interval */ 4974 double rtcp_min_time = RTCP_MIN_TIME; 4975 int n; /* no. of members for computation */ 4976 4977 /* 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. 4983 4984 4985 4986Schulzrinne, et al. Standards Track [Page 89] 4987 4988RFC 3550 RTP July 2003 4989 4990 4991 */ 4992 if (initial) { 4993 rtcp_min_time /= 2; 4994 } 4995 /* 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. 4999 */ 5000 n = members; 5001 if (senders <= members * RTCP_SENDER_BW_FRACTION) { 5002 if (we_sent) { 5003 rtcp_bw *= RTCP_SENDER_BW_FRACTION; 5004 n = senders; 5005 } else { 5006 rtcp_bw *= RTCP_RCVR_BW_FRACTION; 5007 n -= senders; 5008 } 5009 } 5010 5011 /* 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. 5019 */ 5020 t = avg_rtcp_size * n / rtcp_bw; 5021 if (t < rtcp_min_time) t = rtcp_min_time; 5022 5023 /* 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. 5027 */ 5028 t = t * (drand48() + 0.5); 5029 t = t / COMPENSATION; 5030 return t; 5031 } 5032 5033 void OnExpire(event e, 5034 int members, 5035 int senders, 5036 double rtcp_bw, 5037 int we_sent, 5038 double *avg_rtcp_size, 5039 5040 5041 5042Schulzrinne, et al. Standards Track [Page 90] 5043 5044RFC 3550 RTP July 2003 5045 5046 5047 int *initial, 5048 time_tp tc, 5049 time_tp *tp, 5050 int *pmembers) 5051 { 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(). 5057 */ 5058 5059 double t; /* Interval */ 5060 double tn; /* Next transmit time */ 5061 5062 /* In the case of a BYE, we use "timer reconsideration" to 5063 * reschedule the transmission of the BYE if necessary */ 5064 5065 if (TypeOfEvent(e) == EVENT_BYE) { 5066 t = rtcp_interval(members, 5067 senders, 5068 rtcp_bw, 5069 we_sent, 5070 *avg_rtcp_size, 5071 *initial); 5072 tn = *tp + t; 5073 if (tn <= tc) { 5074 SendBYEPacket(e); 5075 exit(1); 5076 } else { 5077 Schedule(tn, e); 5078 } 5079 5080 } else if (TypeOfEvent(e) == EVENT_REPORT) { 5081 t = rtcp_interval(members, 5082 senders, 5083 rtcp_bw, 5084 we_sent, 5085 *avg_rtcp_size, 5086 *initial); 5087 tn = *tp + t; 5088 if (tn <= tc) { 5089 SendRTCPReport(e); 5090 *avg_rtcp_size = (1./16.)*SentPacketSize(e) + 5091 (15./16.)*(*avg_rtcp_size); 5092 *tp = tc; 5093 5094 /* We must redraw the interval. Don't reuse the 5095 5096 5097 5098Schulzrinne, et al. Standards Track [Page 91] 5099 5100RFC 3550 RTP July 2003 5101 5102 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 5106 be sent */ 5107 5108 t = rtcp_interval(members, 5109 senders, 5110 rtcp_bw, 5111 we_sent, 5112 *avg_rtcp_size, 5113 *initial); 5114 5115 Schedule(t+tc,e); 5116 *initial = 0; 5117 } else { 5118 Schedule(tn, e); 5119 } 5120 *pmembers = members; 5121 } 5122 } 5123 5124 void OnReceive(packet p, 5125 event e, 5126 int *members, 5127 int *pmembers, 5128 int *senders, 5129 double *avg_rtcp_size, 5130 double *tp, 5131 double tc, 5132 double tn) 5133 { 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. */ 5137 5138 if (PacketType(p) == PACKET_RTCP_REPORT) { 5139 if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) { 5140 AddMember(p); 5141 *members += 1; 5142 } 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)) { 5147 AddMember(p); 5148 *members += 1; 5149 } 5150 if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) { 5151 5152 5153 5154Schulzrinne, et al. Standards Track [Page 92] 5155 5156RFC 3550 RTP July 2003 5157 5158 5159 AddSender(p); 5160 *senders += 1; 5161 } 5162 } else if (PacketType(p) == PACKET_BYE) { 5163 *avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) + 5164 (15./16.)*(*avg_rtcp_size); 5165 5166 if (TypeOfEvent(e) == EVENT_REPORT) { 5167 if (NewSender(p) == FALSE) { 5168 RemoveSender(p); 5169 *senders -= 1; 5170 } 5171 5172 if (NewMember(p) == FALSE) { 5173 RemoveMember(p); 5174 *members -= 1; 5175 } 5176 5177 if (*members < *pmembers) { 5178 tn = tc + 5179 (((double) *members)/(*pmembers))*(tn - tc); 5180 *tp = tc - 5181 (((double) *members)/(*pmembers))*(tc - *tp); 5182 5183 /* Reschedule the next report for time tn */ 5184 5185 Reschedule(tn, e); 5186 *pmembers = *members; 5187 } 5188 5189 } else if (TypeOfEvent(e) == EVENT_BYE) { 5190 *members += 1; 5191 } 5192 } 5193 } 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210Schulzrinne, et al. Standards Track [Page 93] 5211 5212RFC 3550 RTP July 2003 5213 5214 5215A.8 Estimating the Interarrival Jitter 5216 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: 5228 5229 int transit = arrival - r->ts; 5230 int d = transit - s->transit; 5231 s->transit = transit; 5232 if (d < 0) d = -d; 5233 s->jitter += (1./16.) * ((double)d - s->jitter); 5234 5235 When a reception report block (to which rr points) is generated for 5236 this member, the current jitter estimate is returned: 5237 5238 rr->jitter = (u_int32) s->jitter; 5239 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 5242 for the last line: 5243 5244 s->jitter += d - ((s->jitter + 8) >> 4); 5245 5246 In this case, the estimate is sampled for the reception report as: 5247 5248 rr->jitter = s->jitter >> 4; 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266Schulzrinne, et al. Standards Track [Page 94] 5267 5268RFC 3550 RTP July 2003 5269 5270 5271Appendix B - Changes from RFC 1889 5272 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: 5278 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. 5288 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. 5292 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 5300 partition heals. 5301 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. 5313 5314 Other functional changes were: 5315 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]. 5319 5320 5321 5322Schulzrinne, et al. Standards Track [Page 95] 5323 5324RFC 3550 RTP July 2003 5325 5326 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. 5333 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. 5342 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 5346 sessions. 5347 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. 5351 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. 5354 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. 5360 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 5366 and 11). 5367 5368 o A new Section 10 was added to explain the requirement for 5369 congestion control in applications using RTP. 5370 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 5375 5376 5377 5378Schulzrinne, et al. Standards Track [Page 96] 5379 5380RFC 3550 RTP July 2003 5381 5382 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. 5388 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. 5394 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. 5398 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 5406 restored). 5407 5408 o Clamping of number of packets lost in Section A.3 was corrected to 5409 use both positive and negative limits. 5410 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. 5416 5417 Non-functional changes: 5418 5419 o It is specified that a receiver MUST ignore packets with payload 5420 types it does not understand. 5421 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. 5425 5426 o The inconsequence of NTP timestamps wrapping around in the year 5427 2036 is explained. 5428 5429 5430 5431 5432 5433 5434Schulzrinne, et al. Standards Track [Page 97] 5435 5436RFC 3550 RTP July 2003 5437 5438 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 5444 also specified. 5445 5446 o The reference for the UTF-8 character set was changed from an 5447 X/Open Preliminary Specification to be RFC 2279. 5448 5449 o The reference for RFC 1597 was updated to RFC 1918 and the 5450 reference for RFC 2543 was updated to RFC 3261. 5451 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. 5455 5456 o A non-normative note regarding the use of RTP with Source-Specific 5457 Multicast (SSM) was added in Section 6. 5458 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". 5466 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 5469 Section 5.1. 5470 5471 o Small clarifications of the text have been made in several places, 5472 some in response to questions from readers. In particular: 5473 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. 5477 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. 5484 5485 - The definition for "non-RTP means" was expanded to include 5486 examples of other protocols constituting non-RTP means. 5487 5488 5489 5490Schulzrinne, et al. Standards Track [Page 98] 5491 5492RFC 3550 RTP July 2003 5493 5494 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 5498 the data traffic. 5499 5500 - The effect of varying packet duration on the jitter calculation 5501 was explained in Section 6.4.4. 5502 5503 - The method for terminating and padding a sequence of SDES items 5504 was clarified in Section 6.5. 5505 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. 5509 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. 5520 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. 5524 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 5529 intervals. 5530 5531 - A note was added in Appendix A.1 that packets may be saved 5532 during RTP header validation and delivered upon success. 5533 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. 5538 5539 - Section 13 clarifies that an RTP application may use multiple 5540 profiles but typically only one in a given session. 5541 5542 5543 5544 5545 5546Schulzrinne, et al. Standards Track [Page 99] 5547 5548RFC 3550 RTP July 2003 5549 5550 5551 - The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 5552 2119. 5553 5554 - The bibliography was divided into normative and informative 5555 references. 5556 5557References 5558 5559Normative References 5560 5561 [1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 5562 Conferences with Minimal Control", RFC 3551, July 2003. 5563 5564 [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 5565 Levels", BCP 14, RFC 2119, March 1997. 5566 5567 [3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 5568 5569 [4] Mills, D., "Network Time Protocol (Version 3) Specification, 5570 Implementation and Analysis", RFC 1305, March 1992. 5571 5572 [5] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC 5573 2279, January 1998. 5574 5575 [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 5576 13, RFC 1034, November 1987. 5577 5578 [7] Mockapetris, P., "Domain Names - Implementation and 5579 Specification", STD 13, RFC 1035, November 1987. 5580 5581 [8] Braden, R., "Requirements for Internet Hosts - Application and 5582 Support", STD 3, RFC 1123, October 1989. 5583 5584 [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 5585 5586Informative References 5587 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. 5593 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. 5597 5598 5599 5600 5601 5602Schulzrinne, et al. Standards Track [Page 100] 5603 5604RFC 3550 RTP July 2003 5605 5606 5607 [12] Comer, D., Internetworking with TCP/IP , vol. 1. Englewood 5608 Cliffs, New Jersey: Prentice Hall, 1991. 5609 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. 5613 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. 5619 5620 [15] Handley, M. and V. Jacobson, "SDP: Session Description 5621 Protocol", RFC 2327, April 1998. 5622 5623 [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 5624 Protocol (RTSP)", RFC 2326, April 1998. 5625 5626 [17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness 5627 Recommendations for Security", RFC 1750, December 1994. 5628 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. 5633 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. 5637 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]. 5642 5643 [21] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group 5644 Membership in RTP", RFC 2762, February 2000. 5645 5646 [22] Cadzow, J., Foundations of Digital Signal Processing and Data 5647 Analysis New York, New York: Macmillan, 1987. 5648 5649 [23] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 5650 Addressing Architecture", RFC 3513, April 2003. 5651 5652 [24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. 5653 Lear, "Address Allocation for Private Internets", RFC 1918, 5654 February 1996. 5655 5656 5657 5658Schulzrinne, et al. Standards Track [Page 101] 5659 5660RFC 3550 RTP July 2003 5661 5662 5663 [25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "Network 10 5664 Considered Harmful (Some Practices Shouldn't be Codified)", RFC 5665 1627, July 1994. 5666 5667 [26] Feller, W., An Introduction to Probability Theory and its 5668 Applications, vol. 1. New York, New York: John Wiley and Sons, 5669 third ed., 1968. 5670 5671 [27] Kent, S. and R. Atkinson, "Security Architecture for the 5672 Internet Protocol", RFC 2401, November 1998. 5673 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. 5677 5678 [29] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: 5679 Part III", RFC 1423, February 1993. 5680 5681 [30] Voydock, V. and S. Kent, "Security Mechanisms in High-Level 5682 Network Protocols", ACM Computing Surveys, vol. 15, pp. 135-171, 5683 June 1983. 5684 5685 [31] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, 5686 September 2000. 5687 5688 [32] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 5689 1992. 5690 5691 [33] Stubblebine, S., "Security Services for Multimedia 5692 Conferencing", in 16th National Computer Security Conference, 5693 (Baltimore, Maryland), pp. 391--395, September 1993. 5694 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. 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714Schulzrinne, et al. Standards Track [Page 102] 5715 5716RFC 3550 RTP July 2003 5717 5718 5719Authors' Addresses 5720 5721 Henning Schulzrinne 5722 Department of Computer Science 5723 Columbia University 5724 1214 Amsterdam Avenue 5725 New York, NY 10027 5726 United States 5727 5728 EMail: schulzrinne@cs.columbia.edu 5729 5730 5731 Stephen L. Casner 5732 Packet Design 5733 3400 Hillview Avenue, Building 3 5734 Palo Alto, CA 94304 5735 United States 5736 5737 EMail: casner@acm.org 5738 5739 5740 Ron Frederick 5741 Blue Coat Systems Inc. 5742 650 Almanor Avenue 5743 Sunnyvale, CA 94085 5744 United States 5745 5746 EMail: ronf@bluecoat.com 5747 5748 5749 Van Jacobson 5750 Packet Design 5751 3400 Hillview Avenue, Building 3 5752 Palo Alto, CA 94304 5753 United States 5754 5755 EMail: van@packetdesign.com 5756 5757 5758 5759 5760 5761 5762 5763 5764 5765 5766 5767 5768 5769 5770Schulzrinne, et al. Standards Track [Page 103] 5771 5772RFC 3550 RTP July 2003 5773 5774 5775Full Copyright Statement 5776 5777 Copyright (C) The Internet Society (2003). All Rights Reserved. 5778 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 5791 English. 5792 5793 The limited permissions granted above are perpetual and will not be 5794 revoked by the Internet Society or its successors or assigns. 5795 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. 5802 5803Acknowledgement 5804 5805 Funding for the RFC Editor function is currently provided by the 5806 Internet Society. 5807 5808 5809 5810 5811 5812 5813 5814 5815 5816 5817 5818 5819 5820 5821 5822 5823 5824 5825 5826Schulzrinne, et al. Standards Track [Page 104] 5827 5828