idnits 2.17.1 draft-ietf-avt-rtp-new-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 23 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 19 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 985 has weird spacing: '... item item ...' == Line 3304 has weird spacing: '...ed char u_int...' == Line 3306 has weird spacing: '...ned int u_in...' == Line 3834 has weird spacing: '... char c[16...' == Line 3858 has weird spacing: '... struct timev...' == (6 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 4444 looks like a reference -- Missing reference section? '2' on line 4450 looks like a reference -- Missing reference section? '3' on line 4454 looks like a reference -- Missing reference section? '4' on line 4458 looks like a reference -- Missing reference section? '5' on line 4462 looks like a reference -- Missing reference section? '6' on line 4465 looks like a reference -- Missing reference section? '7' on line 4469 looks like a reference -- Missing reference section? '8' on line 4474 looks like a reference -- Missing reference section? '9' on line 4478 looks like a reference -- Missing reference section? '10' on line 4482 looks like a reference -- Missing reference section? '11' on line 4485 looks like a reference -- Missing reference section? '12' on line 4489 looks like a reference -- Missing reference section? '13' on line 4493 looks like a reference -- Missing reference section? '14' on line 4498 looks like a reference -- Missing reference section? '-packet-' on line 982 looks like a reference -- Missing reference section? '15' on line 4502 looks like a reference -- Missing reference section? '16' on line 4507 looks like a reference -- Missing reference section? '17' on line 4511 looks like a reference -- Missing reference section? '18' on line 4514 looks like a reference -- Missing reference section? '19' on line 4518 looks like a reference -- Missing reference section? '20' on line 4522 looks like a reference -- Missing reference section? '21' on line 4526 looks like a reference -- Missing reference section? '22' on line 4530 looks like a reference -- Missing reference section? '23' on line 4534 looks like a reference -- Missing reference section? '24' on line 4539 looks like a reference -- Missing reference section? 'E1' on line 2436 looks like a reference -- Missing reference section? 'E6' on line 2436 looks like a reference -- Missing reference section? 'E2' on line 2445 looks like a reference -- Missing reference section? 'E4' on line 2445 looks like a reference -- Missing reference section? 'E3' on line 2447 looks like a reference -- Missing reference section? 'E5' on line 2451 looks like a reference -- Missing reference section? '25' on line 4543 looks like a reference -- Missing reference section? '26' on line 4547 looks like a reference -- Missing reference section? 'RR' on line 2952 looks like a reference -- Missing reference section? '27' on line 4551 looks like a reference -- Missing reference section? '28' on line 4555 looks like a reference -- Missing reference section? '29' on line 4559 looks like a reference -- Missing reference section? '0' on line 3765 looks like a reference -- Missing reference section? '30' on line 4563 looks like a reference -- Missing reference section? '31' on line 4567 looks like a reference -- Missing reference section? '32' on line 4571 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 44 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio/Video Transport Working Group 3 Internet Draft Schulzrinne/Casner/Frederick/Jacobson 4 draft-ietf-avt-rtp-new-10.txt Columbia U./Packet Design/ 5 July 20, 2001 Cacheflow/Packet Design 6 Expires: January 2002 8 RTP: A Transport Protocol for Real-Time Applications 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memorandum is a revision of RFC 1889 in preparation for 34 advancement from Proposed Standard to Draft Standard status. Readers 35 are encouraged to use the PostScript form of this draft to see where 36 changes from RFC 1889 are marked by change bars. 38 This memorandum describes RTP, the real-time transport protocol. RTP 39 provides end-to-end network transport functions suitable for 40 applications transmitting real-time data, such as audio, video or 41 simulation data, over multicast or unicast network services. RTP does 42 not address resource reservation and does not guarantee quality-of- 43 service for real-time services. The data transport is augmented by a 44 control protocol (RTCP) to allow monitoring of the data delivery in a 45 manner scalable to large multicast networks, and to provide minimal 46 control and identification functionality. RTP and RTCP are designed 47 to be independent of the underlying transport and network layers. The 48 protocol supports the use of RTP-level translators and mixers. 50 This specification is a product of the Audio/Video Transport working 51 group within the Internet Engineering Task Force. Comments are 52 solicited and should be addressed to the working group's mailing list 53 at avt@ietf.org and/or the authors. 55 Resolution of Open Issues 57 [Note to the RFC Editor: This section is to be deleted when this 58 draft is published as an RFC but is shown here for reference during 59 the Last Call. The first paragraph of the Abstract is also to be 60 deleted.] 62 Readers are directed to Appendix B, Changes from RFC 1889, for a 63 listing of the changes that have been made in this draft. The changes 64 are marked with change bars in the PostScript form of this draft. 66 The only changes in this revision of the draft from the previous one 67 were a few clarifications in the text: 69 o Clarified that SDES CNAME is carried in only one part when the 70 compound RTCP packet is split for partial encryption as 71 described in Section 9.1. 73 o Clarified in Section 6.3 that avg_rtcp_size includes lower- 74 layer transport and network protocol headers (e.g., UDP and 75 IP). 77 o Clarified the updating of the avg_rtcp_size and senders 78 variables during BYE reconsideration. 80 o Added some text to clarify the use of hexadecimal numbers in 81 Fig. 2. 83 This version of the draft is intended to be complete for Working 84 Group last call; the open issues from previous drafts have been 85 addressed: 87 o A fudge factor has been added to the RTCP unconditional 88 reconsideration algorithm to compensate for the fact that it 89 settles to a steady state bandwidth that is below the desired 90 level. 92 o As agreed at the Chicago IETF, the conditional and hybrid 93 reconsideration schemes have been removed in favor of 94 unconditional reconsideration. 96 o The SSRC sampling algorithm has been extracted to a separate 97 draft as agreed at the Chicago IETF. That draft describes the 98 "bin" mechanism that avoids a temporary underestimate in group 99 size when the group size is decreasing. 101 o The "reverse reconsideration" algorithm does not prevent the 102 group size estimate from incorrectly dropping to zero for a 103 short time when most participants of a large session leave at 104 once but some remain. This has just been noted as only a 105 secondary concern. 107 o Scaling of the minimum RTCP interval inversely proportional to 108 the session bandwidth parameter has been added, but only in 109 the direction of smaller intervals for higher bandwidth. 110 Scaling to longer intervals for low bandwidths would cause a 111 problem because this is an optional step. Some participants 112 might be timed out prematurely if they scaled to a longer 113 interval while others kept the nominal 5 seconds. The benefit 114 of scaling longer was not considered great in any case. 116 o No change was specified for the jitter computation for media 117 with several packets with the same timestamp. There is not a 118 clear answer as to what should be done, or that any change 119 would make a significant improvement. 121 o As proposed without objection at the Los Angeles IETF, 122 definition of additional SDES items such as PHOTO URL and 123 NICKNAME will be deferred to subsequent registration through 124 IANA since that method has been established. This is in the 125 spirit of minimizing changes to the protocol in the transition 126 from Proposed to Draft. 128 o Nothing was added about allowing a translator to add its own 129 random offsets to the sequence number and timestamp fields 130 because it would likely cause more trouble than good. 132 o It was decided that it is not necessary for the length of a 133 compound RTCP packet containing information about N sources 134 (usually from a mixer that aggregates RTCP) to be divided by N 135 before adding it into the average length since the smoothing 136 of the estimator is sufficient. 138 1 Introduction 140 This memorandum specifies the real-time transport protocol (RTP), 141 which provides end-to-end delivery services for data with real-time 142 characteristics, such as interactive audio and video. Those services 143 include payload type identification, sequence numbering, timestamping 144 and delivery monitoring. Applications typically run RTP on top of UDP 145 to make use of its multiplexing and checksum services; both protocols 146 contribute parts of the transport protocol functionality. However, 147 RTP may be used with other suitable underlying network or transport 148 protocols (see Section 11). RTP supports data transfer to multiple 149 destinations using multicast distribution if provided by the 150 underlying network. 152 Note that RTP itself does not provide any mechanism to ensure timely 153 delivery or provide other quality-of-service guarantees, but relies 154 on lower-layer services to do so. It does not guarantee delivery or 155 prevent out-of-order delivery, nor does it assume that the underlying 156 network is reliable and delivers packets in sequence. The sequence 157 numbers included in RTP allow the receiver to reconstruct the 158 sender's packet sequence, but sequence numbers might also be used to 159 determine the proper location of a packet, for example in video 160 decoding, without necessarily decoding packets in sequence. 162 While RTP is primarily designed to satisfy the needs of multi- 163 participant multimedia conferences, it is not limited to that 164 particular application. Storage of continuous data, interactive 165 distributed simulation, active badge, and control and measurement 166 applications may also find RTP applicable. 168 This document defines RTP, consisting of two closely-linked parts: 170 o the real-time transport protocol (RTP), to carry data that has 171 real-time properties. 173 o the RTP control protocol (RTCP), to monitor the quality of 174 service and to convey information about the participants in an 175 on-going session. The latter aspect of RTCP may be sufficient 176 for "loosely controlled" sessions, i.e., where there is no 177 explicit membership control and set-up, but it is not 178 necessarily intended to support all of an application's 179 control communication requirements. This functionality may be 180 fully or partially subsumed by a separate session control 181 protocol, which is beyond the scope of this document. 183 RTP represents a new style of protocol following the principles of 184 application level framing and integrated layer processing proposed by 185 Clark and Tennenhouse [1]. That is, RTP is intended to be malleable 186 to provide the information required by a particular application and 187 will often be integrated into the application processing rather than 188 being implemented as a separate layer. RTP is a protocol framework 189 that is deliberately not complete. This document specifies those 190 functions expected to be common across all the applications for which 191 RTP would be appropriate. Unlike conventional protocols in which 192 additional functions might be accommodated by making the protocol 193 more general or by adding an option mechanism that would require 194 parsing, RTP is intended to be tailored through modifications and/or 195 additions to the headers as needed. Examples are given in Sections 196 5.3 and 6.4.3. 198 Therefore, in addition to this document, a complete specification of 199 RTP for a particular application will require one or more companion 200 documents (see Section 13): 202 o a profile specification document, which defines a set of 203 payload type codes and their mapping to payload formats (e.g., 204 media encodings). A profile may also define extensions or 205 modifications to RTP that are specific to a particular class 206 of applications. Typically an application will operate under 207 only one profile. A profile for audio and video data may be 208 found in the companion RFC 1890 (updated by Internet-Draft 209 draft-ietf-avt-profile-new [2]). 211 o payload format specification documents, which define how a 212 particular payload, such as an audio or video encoding, is to 213 be carried in RTP. 215 A discussion of real-time services and algorithms for their 216 implementation as well as background discussion on some of the RTP 217 design decisions can be found in [3]. 219 1.1 Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in RFC 2119 [4] and 224 indicate requirement levels for compliant RTP implementations. 226 2 RTP Use Scenarios 228 The following sections describe some aspects of the use of RTP. The 229 examples were chosen to illustrate the basic operation of 230 applications using RTP, not to limit what RTP may be used for. In 231 these examples, RTP is carried on top of IP and UDP, and follows the 232 conventions established by the profile for audio and video specified 233 in the companion RFC 1890 (updated by Internet-Draft draft-ietf-avt- 234 profile-new ). 236 2.1 Simple Multicast Audio Conference 238 A working group of the IETF meets to discuss the latest protocol 239 draft, using the IP multicast services of the Internet for voice 240 communications. Through some allocation mechanism the working group 241 chair obtains a multicast group address and pair of ports. One port 242 is used for audio data, and the other is used for control (RTCP) 243 packets. This address and port information is distributed to the 244 intended participants. If privacy is desired, the data and control 245 packets may be encrypted as specified in Section 9.1, in which case 246 an encryption key must also be generated and distributed. The exact 247 details of these allocation and distribution mechanisms are beyond 248 the scope of RTP. 250 The audio conferencing application used by each conference 251 participant sends audio data in small chunks of, say, 20 ms duration. 252 Each chunk of audio data is preceded by an RTP header; RTP header and 253 data are in turn contained in a UDP packet. The RTP header indicates 254 what type of audio encoding (such as PCM, ADPCM or LPC) is contained 255 in each packet so that senders can change the encoding during a 256 conference, for example, to accommodate a new participant that is 257 connected through a low-bandwidth link or react to indications of 258 network congestion. 260 The Internet, like other packet networks, occasionally loses and 261 reorders packets and delays them by variable amounts of time. To cope 262 with these impairments, the RTP header contains timing information 263 and a sequence number that allow the receivers to reconstruct the 264 timing produced by the source, so that in this example, chunks of 265 audio are contiguously played out the speaker every 20 ms. This 266 timing reconstruction is performed separately for each source of RTP 267 packets in the conference. The sequence number can also be used by 268 the receiver to estimate how many packets are being lost. 270 Since members of the working group join and leave during the 271 conference, it is useful to know who is participating at any moment 272 and how well they are receiving the audio data. For that purpose, 273 each instance of the audio application in the conference periodically 274 multicasts a reception report plus the name of its user on the RTCP 275 (control) port. The reception report indicates how well the current 276 speaker is being received and may be used to control adaptive 277 encodings. In addition to the user name, other identifying 278 information may also be included subject to control bandwidth limits. 279 A site sends the RTCP BYE packet (Section 6.6) when it leaves the 280 conference. 282 2.2 Audio and Video Conference 284 If both audio and video media are used in a conference, they are 285 transmitted as separate RTP sessions RTCP packets are transmitted for 286 each medium using two different UDP port pairs and/or multicast 287 addresses. There is no direct coupling at the RTP level between the 288 audio and video sessions, except that a user participating in both 289 sessions should use the same distinguished (canonical) name in the 290 RTCP packets for both so that the sessions can be associated. 292 One motivation for this separation is to allow some participants in 293 the conference to receive only one medium if they choose. Further 294 explanation is given in Section 5.2. Despite the separation, 295 synchronized playback of a source's audio and video can be achieved 296 using timing information carried in the RTCP packets for both 297 sessions. 299 2.3 Mixers and Translators 301 So far, we have assumed that all sites want to receive media data in 302 the same format. However, this may not always be appropriate. 303 Consider the case where participants in one area are connected 304 through a low-speed link to the majority of the conference 305 participants who enjoy high-speed network access. Instead of forcing 306 everyone to use a lower-bandwidth, reduced-quality audio encoding, an 307 RTP-level relay called a mixer may be placed near the low-bandwidth 308 area. This mixer resynchronizes incoming audio packets to reconstruct 309 the constant 20 ms spacing generated by the sender, mixes these 310 reconstructed audio streams into a single stream, translates the 311 audio encoding to a lower-bandwidth one and forwards the lower- 312 bandwidth packet stream across the low-speed link. These packets 313 might be unicast to a single recipient or multicast on a different 314 address to multiple recipients. The RTP header includes a means for 315 mixers to identify the sources that contributed to a mixed packet so 316 that correct talker indication can be provided at the receivers. 318 Some of the intended participants in the audio conference may be 319 connected with high bandwidth links but might not be directly 320 reachable via IP multicast. For example, they might be behind an 321 application-level firewall that will not let any IP packets pass. For 322 these sites, mixing may not be necessary, in which case another type 323 of RTP-level relay called a translator may be used. Two translators 324 are installed, one on either side of the firewall, with the outside 325 one funneling all multicast packets received through a secure 326 connection to the translator inside the firewall. The translator 327 inside the firewall sends them again as multicast packets to a 328 multicast group restricted to the site's internal network. 330 Mixers and translators may be designed for a variety of purposes. An 331 example is a video mixer that scales the images of individual people 332 in separate video streams and composites them into one video stream 333 to simulate a group scene. Other examples of translation include the 334 connection of a group of hosts speaking only IP/UDP to a group of 335 hosts that understand only ST-II, or the packet-by-packet encoding 336 translation of video streams from individual sources without 337 resynchronization or mixing. Details of the operation of mixers and 338 translators are given in Section 7. 340 2.4 Layered Encodings 342 Multimedia applications should be able to adjust the transmission 343 rate to match the capacity of the receiver or to adapt to network 344 congestion. Many implementations place the responsibility of rate- 345 adaptivity at the source. This does not work well with multicast 346 transmission because of the conflicting bandwidth requirements of 347 heterogeneous receivers. The result is often a least-common 348 denominator scenario, where the smallest pipe in the network mesh 349 dictates the quality and fidelity of the overall live multimedia 350 "broadcast". 352 Instead, responsibility for rate-adaptation can be placed at the 353 receivers by combining a layered encoding with a layered transmission 354 system. In the context of RTP over IP multicast, the source can 355 stripe the progressive layers of a hierarchically represented signal 356 across multiple RTP sessions each carried on its own multicast group. 357 Receivers can then adapt to network heterogeneity and control their 358 reception bandwidth by joining only the appropriate subset of the 359 multicast groups. 361 Details of the use of RTP with layered encodings are given in 362 Sections 6.3.9, 8.3 and 11. 364 3 Definitions 366 RTP payload: The data transported by RTP in a packet, for 367 example audio samples or compressed video data. The payload 368 format and interpretation are beyond the scope of this 369 document. 371 RTP packet: A data packet consisting of the fixed RTP header, a 372 possibly empty list of contributing sources (see below), 373 and the payload data. Some underlying protocols may require 374 an encapsulation of the RTP packet to be defined. Typically 375 one packet of the underlying protocol contains a single RTP 376 packet, but several RTP packets MAY be contained if 377 permitted by the encapsulation method (see Section 11). 379 RTCP packet: A control packet consisting of a fixed header part 380 similar to that of RTP data packets, followed by structured 381 elements that vary depending upon the RTCP packet type. The 382 formats are defined in Section 6. Typically, multiple RTCP 383 packets are sent together as a compound RTCP packet in a 384 single packet of the underlying protocol; this is enabled 385 by the length field in the fixed header of each RTCP 386 packet. 388 Port: The "abstraction that transport protocols use to 389 distinguish among multiple destinations within a given host 390 computer. TCP/IP protocols identify ports using small 391 positive integers." [5] The transport selectors (TSEL) used 392 by the OSI transport layer are equivalent to ports. RTP 393 depends upon the lower-layer protocol to provide some 394 mechanism such as ports to multiplex the RTP and RTCP 395 packets of a session. 397 Transport address: The combination of a network address and port 398 that identifies a transport-level endpoint, for example an 399 IP address and a UDP port. Packets are transmitted from a 400 source transport address to a destination transport 401 address. 403 RTP media type: An RTP media type is the collection of payload 404 types which can be carried within a single RTP session. The 405 RTP Profile assigns RTP media types to RTP payload types. 407 RTP session: The association among a set of participants 408 communicating with RTP. For each participant, the session 409 is defined by a particular pair of destination transport 410 addresses (one network address plus a port pair for RTP and 411 RTCP). The destination transport address pair may be common 412 for all participants, as in the case of IP multicast, or 413 may be different for each, as in the case of individual 414 unicast network addresses and port pairs. In a multimedia 415 session, each medium is carried in a separate RTP session 416 with its own RTCP packets. The multiple RTP sessions are 417 distinguished by different port number pairs and/or 418 different multicast addresses. 420 Synchronization source (SSRC): The source of a stream of RTP 421 packets, identified by a 32-bit numeric SSRC identifier 422 carried in the RTP header so as not to be dependent upon 423 the network address. All packets from a synchronization 424 source form part of the same timing and sequence number 425 space, so a receiver groups packets by synchronization 426 source for playback. Examples of synchronization sources 427 include the sender of a stream of packets derived from a 428 signal source such as a microphone or a camera, or an RTP 429 mixer (see below). A synchronization source may change its 430 data format, e.g., audio encoding, over time. The SSRC 431 identifier is a randomly chosen value meant to be globally 432 unique within a particular RTP session (see Section 8). A 433 participant need not use the same SSRC identifier for all 434 the RTP sessions in a multimedia session; the binding of 435 the SSRC identifiers is provided through RTCP (see Section 436 6.5.1). If a participant generates multiple streams in one 437 RTP session, for example from separate video cameras, each 438 MUST be identified as a different SSRC. 440 Contributing source (CSRC): A source of a stream of RTP packets 441 that has contributed to the combined stream produced by an 442 RTP mixer (see below). The mixer inserts a list of the SSRC 443 identifiers of the sources that contributed to the 444 generation of a particular packet into the RTP header of 445 that packet. This list is called the CSRC list. An example 446 application is audio conferencing where a mixer indicates 447 all the talkers whose speech was combined to produce the 448 outgoing packet, allowing the receiver to indicate the 449 current talker, even though all the audio packets contain 450 the same SSRC identifier (that of the mixer). 452 End system: An application that generates the content to be sent 453 in RTP packets and/or consumes the content of received RTP 454 packets. An end system can act as one or more 455 synchronization sources in a particular RTP session, but 456 typically only one. 458 Mixer: An intermediate system that receives RTP packets from one 459 or more sources, possibly changes the data format, combines 460 the packets in some manner and then forwards a new RTP 461 packet. Since the timing among multiple input sources will 462 not generally be synchronized, the mixer will make timing 463 adjustments among the streams and generate its own timing 464 for the combined stream. Thus, all data packets originating 465 from a mixer will be identified as having the mixer as 466 their synchronization source. 468 Translator: An intermediate system that forwards RTP packets 469 with their synchronization source identifier intact. 470 Examples of translators include devices that convert 471 encodings without mixing, replicators from multicast to 472 unicast, and application-level filters in firewalls. 474 Monitor: An application that receives RTCP packets sent by 475 participants in an RTP session, in particular the reception 476 reports, and estimates the current quality of service for 477 distribution monitoring, fault diagnosis and long-term 478 statistics. The monitor function is likely to be built into 479 the application(s) participating in the session, but may 480 also be a separate application that does not otherwise 481 participate and does not send or receive the RTP data 482 packets (since they are on a separate port). These are 483 called third-party monitors. It is also acceptable for a 484 third-party monitor to receive the RTP data packets but not 485 send RTCP packets or otherwise be counted in the session. 487 Non-RTP means: Protocols and mechanisms that may be needed in 488 addition to RTP to provide a usable service. In particular, 489 for multimedia conferences, a control protocol may 490 distribute multicast addresses and keys for encryption, 491 negotiate the encryption algorithm to be used, and define 492 dynamic mappings between RTP payload type values and the 493 payload formats they represent for formats that do not have 494 a predefined payload type value. Examples of such protocols 495 include the Session Initiation Protocol (SIP) (RFC 2543 496 [6]), H.323 [7] and applications using SDP (RFC 2327 [8]), 497 such as RTSP (RFC 2326 [9]). For simple applications, 498 electronic mail or a conference database may also be used. 499 The specification of such protocols and mechanisms is 500 outside the scope of this document. 502 4 Byte Order, Alignment, and Time Format 504 All integer fields are carried in network byte order, that is, most 505 significant byte (octet) first. This byte order is commonly known as 506 big-endian. The transmission order is described in detail in [10]. 507 Unless otherwise noted, numeric constants are in decimal (base 10). 509 All header data is aligned to its natural length, i.e., 16-bit fields 510 are aligned on even offsets, 32-bit fields are aligned at offsets 511 divisible by four, etc. Octets designated as padding have the value 512 zero. 514 Wallclock time (absolute date and time) is represented using the 515 timestamp format of the Network Time Protocol (NTP), which is in 516 seconds relative to 0h UTC on 1 January 1900 [11]. The full 517 resolution NTP timestamp is a 64-bit unsigned fixed-point number with 518 the integer part in the first 32 bits and the fractional part in the 519 last 32 bits. In some fields where a more compact representation is 520 appropriate, only the middle 32 bits are used; that is, the low 16 521 bits of the integer part and the high 16 bits of the fractional part. 522 The high 16 bits of the integer part must be determined 523 independently. 525 An implementation is not required to run the Network Time Protocol in 526 order to use RTP. Other time sources, or none at all, may be used 527 (see the description of the NTP timestamp field in Section 6.4.1). 528 However, running NTP may be useful for synchronizing streams 529 transmitted from separate hosts. 531 The NTP timestamp will wrap around to zero some time in the year 532 2036, but for RTP purposes, only differences between pairs of NTP 533 timestamps are used. So long as the pairs of timestamps can be 534 assumed to be within 68 years of each other, using modulo arithmetic 535 for subtractions and comparisons makes the wraparound irrelevant. 537 5 RTP Data Transfer Protocol 539 5.1 RTP Fixed Header Fields 541 The RTP header has the following format: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |V=2|P|X| CC |M| PT | sequence number | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | timestamp | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | synchronization source (SSRC) identifier | 551 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 552 | contributing source (CSRC) identifiers | 553 | .... | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 The first twelve octets are present in every RTP packet, while the 557 list of CSRC identifiers is present only when inserted by a mixer. 558 The fields have the following meaning: 560 version (V): 2 bits 561 This field identifies the version of RTP. The version 562 defined by this specification is two (2). (The value 1 is 563 used by the first draft version of RTP and the value 0 is 564 used by the protocol initially implemented in the "vat" 565 audio tool.) 567 padding (P): 1 bit 568 If the padding bit is set, the packet contains one or more 569 additional padding octets at the end which are not part of 570 the payload. The last octet of the padding contains a count 571 of how many padding octets should be ignored, including 572 itself. Padding may be needed by some encryption 573 algorithms with fixed block sizes or for carrying several 574 RTP packets in a lower-layer protocol data unit. 576 extension (X): 1 bit 577 If the extension bit is set, the fixed header MUST be 578 followed by exactly one header extension, with a format 579 defined in Section 5.3.1. 581 CSRC count (CC): 4 bits 582 The CSRC count contains the number of CSRC identifiers that 583 follow the fixed header. 585 marker (M): 1 bit 586 The interpretation of the marker is defined by a profile. 587 It is intended to allow significant events such as frame 588 boundaries to be marked in the packet stream. A profile MAY 589 define additional marker bits or specify that there is no 590 marker bit by changing the number of bits in the payload 591 type field (see Section 5.3). 593 payload type (PT): 7 bits 594 This field identifies the format of the RTP payload and 595 determines its interpretation by the application. A profile 596 MAY specify a default static mapping of payload type codes 597 to payload formats. Additional payload type codes MAY be 598 defined dynamically through non-RTP means (see Section 3). 599 A set of default mappings for audio and video is specified 600 in the companion RFC 1890 (updated by Internet-Draft 601 draft-ietf-avt-profile-new [2]). An RTP source MAY change 602 the payload type during a session, but this field SHOULD 603 NOT be used for multiplexing separate media streams (see 604 Section 5.2). 606 A receiver MUST ignore packets with payload types that it 607 does not understand. 609 sequence number: 16 bits 610 The sequence number increments by one for each RTP data 611 packet sent, and may be used by the receiver to detect 612 packet loss and to restore packet sequence. The initial 613 value of the sequence number SHOULD be random 614 (unpredictable) to make known-plaintext attacks on 615 encryption more difficult, even if the source itself does 616 not encrypt according to the method in Section 9.1, because 617 the packets may flow through a translator that does. 618 Techniques for choosing unpredictable numbers are discussed 619 in [12]. 621 timestamp: 32 bits 622 The timestamp reflects the sampling instant of the first 623 octet in the RTP data packet. The sampling instant MUST be 624 derived from a clock that increments monotonically and 625 linearly in time to allow synchronization and jitter 626 calculations (see Section 6.4.1). The resolution of the 627 clock MUST be sufficient for the desired synchronization 628 accuracy and for measuring packet arrival jitter (one tick 629 per video frame is typically not sufficient). The clock 630 frequency is dependent on the format of data carried as 631 payload and is specified statically in the profile or 632 payload format specification that defines the format, or 633 MAY be specified dynamically for payload formats defined 634 through non-RTP means. If RTP packets are generated 635 periodically, the nominal sampling instant as determined 636 from the sampling clock is to be used, not a reading of the 637 system clock. As an example, for fixed-rate audio the 638 timestamp clock would likely increment by one for each 639 sampling period. If an audio application reads blocks 640 covering 160 sampling periods from the input device, the 641 timestamp would be increased by 160 for each such block, 642 regardless of whether the block is transmitted in a packet 643 or dropped as silent. 645 The initial value of the timestamp SHOULD be random, as for 646 the sequence number. Several consecutive RTP packets will 647 have equal timestamps if they are (logically) generated at 648 once, e.g., belong to the same video frame. Consecutive RTP 649 packets MAY contain timestamps that are not monotonic if 650 the data is not transmitted in the order it was sampled, as 651 in the case of MPEG interpolated video frames. (The 652 sequence numbers of the packets as transmitted will still 653 be monotonic.) 655 SSRC: 32 bits 656 The SSRC field identifies the synchronization source. This 657 identifier SHOULD be chosen randomly, with the intent that 658 no two synchronization sources within the same RTP session 659 will have the same SSRC identifier. An example algorithm 660 for generating a random identifier is presented in Appendix 661 A.6. Although the probability of multiple sources choosing 662 the same identifier is low, all RTP implementations must be 663 prepared to detect and resolve collisions. Section 8 664 describes the probability of collision along with a 665 mechanism for resolving collisions and detecting RTP-level 666 forwarding loops based on the uniqueness of the SSRC 667 identifier. If a source changes its source transport 668 address, it must also choose a new SSRC identifier to avoid 669 being interpreted as a looped source (see Section 8.2). 671 CSRC list: 0 to 15 items, 32 bits each 672 The CSRC list identifies the contributing sources for the 673 payload contained in this packet. The number of identifiers 674 is given by the CC field. If there are more than 15 675 contributing sources, only 15 can be identified. CSRC 676 identifiers are inserted by mixers (see Section 7.1), using 677 the SSRC identifiers of contributing sources. For example, 678 for audio packets the SSRC identifiers of all sources that 679 were mixed together to create a packet are listed, allowing 680 correct talker indication at the receiver. 682 5.2 Multiplexing RTP Sessions 684 For efficient protocol processing, the number of multiplexing points 685 should be minimized, as described in the integrated layer processing 686 design principle [1]. In RTP, multiplexing is provided by the 687 destination transport address (network address and port number) which 688 define an RTP session. For example, in a teleconference composed of 689 audio and video media encoded separately, each medium SHOULD be 690 carried in a separate RTP session with its own destination transport 691 address. 693 Separate audio and video streams SHOULD NOT be carried in a single 694 RTP session and demultiplexed based on the payload type or SSRC 695 fields. Interleaving packets with different RTP media types but using 696 the same SSRC would introduce several problems: 698 1. If, say, two audio streams shared the same RTP session and 699 the same SSRC value, and one were to change encodings and 700 thus acquire a different RTP payload type, there would be 701 no general way of identifying which stream had changed 702 encodings. 704 2. An SSRC is defined to identify a single timing and sequence 705 number space. Interleaving multiple payload types would 706 require different timing spaces if the media clock rates 707 differ and would require different sequence number spaces 708 to tell which payload type suffered packet loss. 710 3. The RTCP sender and receiver reports (see Section 6.4) can 711 only describe one timing and sequence number space per SSRC 712 and do not carry a payload type field. 714 4. An RTP mixer would not be able to combine interleaved 715 streams of incompatible media into one stream. 717 5. Carrying multiple media in one RTP session precludes: the 718 use of different network paths or network resource 719 allocations if appropriate; reception of a subset of the 720 media if desired, for example just audio if video would 721 exceed the available bandwidth; and receiver 722 implementations that use separate processes for the 723 different media, whereas using separate RTP sessions 724 permits either single- or multiple-process implementations. 726 Using a different SSRC for each medium but sending them in the same 727 RTP session would avoid the first three problems but not the last 728 two. 730 5.3 Profile-Specific Modifications to the RTP Header 732 The existing RTP data packet header is believed to be complete for 733 the set of functions required in common across all the application 734 classes that RTP might support. However, in keeping with the ALF 735 design principle, the header MAY be tailored through modifications or 736 additions defined in a profile specification while still allowing 737 profile-independent monitoring and recording tools to function. 739 o The marker bit and payload type field carry profile-specific 740 information, but they are allocated in the fixed header since 741 many applications are expected to need them and might 742 otherwise have to add another 32-bit word just to hold them. 743 The octet containing these fields MAY be redefined by a 744 profile to suit different requirements, for example with a 745 more or fewer marker bits. If there are any marker bits, one 746 SHOULD be located in the most significant bit of the octet 747 since profile-independent monitors may be able to observe a 748 correlation between packet loss patterns and the marker bit. 750 o Additional information that is required for a particular 751 payload format, such as a video encoding, SHOULD be carried in 752 the payload section of the packet. This might be in a header 753 that is always present at the start of the payload section, or 754 might be indicated by a reserved value in the data pattern. 756 o If a particular class of applications needs additional 757 functionality independent of payload format, the profile under 758 which those applications operate SHOULD define additional 759 fixed fields to follow immediately after the SSRC field of the 760 existing fixed header. Those applications will be able to 761 quickly and directly access the additional fields while 762 profile-independent monitors or recorders can still process 763 the RTP packets by interpreting only the first twelve octets. 765 If it turns out that additional functionality is needed in common 766 across all profiles, then a new version of RTP should be defined to 767 make a permanent change to the fixed header. 769 5.3.1 RTP Header Extension 771 An extension mechanism is provided to allow individual 772 implementations to experiment with new payload-format-independent 773 functions that require additional information to be carried in the 774 RTP data packet header. This mechanism is designed so that the header 775 extension may be ignored by other interoperating implementations that 776 have not been extended. 778 Note that this header extension is intended only for limited use. 779 Most potential uses of this mechanism would be better done another 780 way, using the methods described in the previous section. For 781 example, a profile-specific extension to the fixed header is less 782 expensive to process because it is not conditional nor in a variable 783 location. Additional information required for a particular payload 784 format SHOULD NOT use this header extension, but SHOULD be carried in 785 the payload section of the packet. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | defined by profile | length | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | header extension | 793 | .... | 795 If the X bit in the RTP header is one, a variable-length header 796 extension MUST be appended to the RTP header, following the CSRC list 797 if present. The header extension contains a 16-bit length field that 798 counts the number of 32-bit words in the extension, excluding the 799 four-octet extension header (therefore zero is a valid length). Only 800 a single extension can be appended to the RTP data header. To allow 801 multiple interoperating implementations to each experiment 802 independently with different header extensions, or to allow a 803 particular implementation to experiment with more than one type of 804 header extension, the first 16 bits of the header extension are left 805 open for distinguishing identifiers or parameters. The format of 806 these 16 bits is to be defined by the profile specification under 807 which the implementations are operating. This RTP specification does 808 not define any header extensions itself. 810 6 RTP Control Protocol -- RTCP 812 The RTP control protocol (RTCP) is based on the periodic transmission 813 of control packets to all participants in the session, using the same 814 distribution mechanism as the data packets. The underlying protocol 815 MUST provide multiplexing of the data and control packets, for 816 example using separate port numbers with UDP. RTCP performs four 817 functions: 819 1. The primary function is to provide feedback on the quality 820 of the data distribution. This is an integral part of the 821 RTP's role as a transport protocol and is related to the 822 flow and congestion control functions of other transport 823 protocols (see Section 10 on the requirement for congestion 824 control). The feedback may be directly useful for control 825 of adaptive encodings [13,14], but experiments with IP 826 multicasting have shown that it is also critical to get 827 feedback from the receivers to diagnose faults in the 828 distribution. Sending reception feedback reports to all 829 participants allows one who is observing problems to 830 evaluate whether those problems are local or global. With a 831 distribution mechanism like IP multicast, it is also 832 possible for an entity such as a network service provider 833 who is not otherwise involved in the session to receive the 834 feedback information and act as a third-party monitor to 835 diagnose network problems. This feedback function is 836 performed by the RTCP sender and receiver reports, 837 described below in Section 6.4. 839 2. RTCP carries a persistent transport-level identifier for an 840 RTP source called the canonical name or CNAME, Section 841 6.5.1. Since the SSRC identifier may change if a conflict 842 is discovered or a program is restarted, receivers require 843 the CNAME to keep track of each participant. Receivers may 844 also require the CNAME to associate multiple data streams 845 from a given participant in a set of related RTP sessions, 846 for example to synchronize audio and video. Inter-media 847 synchronization also requires the NTP and RTP timestamps 848 included in RTCP packets by data senders. 850 3. The first two functions require that all participants send 851 RTCP packets, therefore the rate must be controlled in 852 order for RTP to scale up to a large number of 853 participants. By having each participant send its control 854 packets to all the others, each can independently observe 855 the number of participants. This number is used to 856 calculate the rate at which the packets are sent, as 857 explained in Section 6.2. 859 4. A fourth, OPTIONAL function is to convey minimal session 860 control information, for example participant identification 861 to be displayed in the user interface. This is most likely 862 to be useful in "loosely controlled" sessions where 863 participants enter and leave without membership control or 864 parameter negotiation. RTCP serves as a convenient channel 865 to reach all the participants, but it is not necessarily 866 expected to support all the control communication 867 requirements of an application. A higher-level session 868 control protocol, which is beyond the scope of this 869 document, may be needed. 871 Functions 1-3 SHOULD be used in all environments, but particularly in 872 the IP multicast environment. RTP application designers SHOULD avoid 873 mechanisms that can only work in unicast mode and will not scale to 874 larger numbers. Transmission of RTCP MAY be controlled separately for 875 senders and receivers, as described in Section 6.2, for cases such as 876 unidirectional links where feedback from receivers is not possible. 878 6.1 RTCP Packet Format 880 This specification defines several RTCP packet types to carry a 881 variety of control information: 883 SR: Sender report, for transmission and reception statistics 884 from participants that are active senders 886 RR: Receiver report, for reception statistics from participants 887 that are not active senders and in combination with SR for 888 active senders reporting on more than 31 sources 890 SDES: Source description items, including CNAME 892 BYE: Indicates end of participation 894 APP: Application specific functions 896 Each RTCP packet begins with a fixed part similar to that of RTP data 897 packets, followed by structured elements that MAY be of variable 898 length according to the packet type but MUST end on a 32-bit 899 boundary. The alignment requirement and a length field in the fixed 900 part of each packet are included to make RTCP packets "stackable". 901 Multiple RTCP packets can be concatenated without any intervening 902 separators to form a compound RTCP packet that is sent in a single 903 packet of the lower layer protocol, for example UDP. There is no 904 explicit count of individual RTCP packets in the compound packet 905 since the lower layer protocols are expected to provide an overall 906 length to determine the end of the compound packet. 908 Each individual RTCP packet in the compound packet may be processed 909 independently with no requirements upon the order or combination of 910 packets. However, in order to perform the functions of the protocol, 911 the following constraints are imposed: 913 o Reception statistics (in SR or RR) should be sent as often as 914 bandwidth constraints will allow to maximize the resolution of 915 the statistics, therefore each periodically transmitted 916 compound RTCP packet MUST include a report packet. 918 o New receivers need to receive the CNAME for a source as soon 919 as possible to identify the source and to begin associating 920 media for purposes such as lip-sync, so each compound RTCP 921 packet MUST also include the SDES CNAME except when the 922 compound RTCP packet is split for partial encryption as 923 described in Section 9.1. 925 o The number of packet types that may appear first in the 926 compound packet needs to be limited to increase the number of 927 constant bits in the first word and the probability of 928 successfully validating RTCP packets against misaddressed RTP 929 data packets or other unrelated packets. 931 Thus, all RTCP packets MUST be sent in a compound packet of at least 932 two individual packets, with the following format: 934 Encryption prefix: If and only if the compound packet is to be 935 encrypted according to the method in Section 9.1, it MUST 936 be prefixed by a random 32-bit quantity redrawn for every 937 compound packet transmitted. If padding is required for 938 the encryption, it MUST be added to the last packet of the 939 compound packet. 941 SR or RR: The first RTCP packet in the compound packet MUST 942 always be a report packet to facilitate header validation 943 as described in Appendix A.2. This is true even if no data 944 has been sent or received, in which case an empty RR MUST 945 be sent, and even if the only other RTCP packet in the 946 compound packet is a BYE. 948 Additional RRs: If the number of sources for which reception 949 statistics are being reported exceeds 31, the number that 950 will fit into one SR or RR packet, then additional RR 951 packets SHOULD follow the initial report packet. 953 SDES: An SDES packet containing a CNAME item MUST be included 954 in each compound RTCP packet, except as noted in Section 955 9.1. Other source description items MAY optionally be 956 included if required by a particular application, subject 957 to bandwidth constraints (see Section 6.3.9). 959 BYE or APP: Other RTCP packet types, including those yet to be 960 defined, MAY follow in any order, except that BYE SHOULD be 961 the last packet sent with a given SSRC/CSRC. Packet types 962 MAY appear more than once. 964 It is RECOMMENDED that translators and mixers combine individual RTCP 965 packets from the multiple sources they are forwarding into one 966 compound packet whenever feasible in order to amortize the packet 967 overhead (see Section 7). An example RTCP compound packet as might be 968 produced by a mixer is shown in Fig. 1. If the overall length of a 969 compound packet would exceed the maximum transmission unit (MTU) of 970 the network path, it SHOULD be segmented into multiple shorter 971 compound packets to be transmitted in separate packets of the 972 underlying protocol. Note that each of the compound packets MUST 973 begin with an SR or RR packet. 975 An implementation SHOULD ignore incoming RTCP packets with types 976 unknown to it. Additional RTCP packet types may be registered with 977 the Internet Assigned Numbers Authority (IANA) as described in 978 Section 14. 980 if encrypted: random 32-bit integer 981 | 982 |[--------- packet --------][---------- packet ----------][-packet-] 983 | 984 | receiver chunk chunk 985 V reports item item item item 986 -------------------------------------------------------------------- 987 R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why] 988 -------------------------------------------------------------------- 989 | | 990 |<----------------------- compound packet ----------------------->| 991 |<-------------------------- UDP packet ------------------------->| 993 #: SSRC/CSRC identifier 995 Figure 1: Example of an RTCP compound packet 997 6.2 RTCP Transmission Interval 999 RTP is designed to allow an application to scale automatically over 1000 session sizes ranging from a few participants to thousands. For 1001 example, in an audio conference the data traffic is inherently self- 1002 limiting because only one or two people will speak at a time, so with 1003 multicast distribution the data rate on any given link remains 1004 relatively constant independent of the number of participants. 1005 However, the control traffic is not self-limiting. If the reception 1006 reports from each participant were sent at a constant rate, the 1007 control traffic would grow linearly with the number of participants. 1008 Therefore, the rate must be scaled down by dynamically calculating 1009 the interval between RTCP packet transmissions. 1011 For each session, it is assumed that the data traffic is subject to 1012 an aggregate limit called the "session bandwidth" to be divided among 1013 the participants. This bandwidth might be reserved and the limit 1014 enforced by the network. If there is no reservation, there may be 1015 other constraints, depending on the environment, that establish the 1016 "reasonable" maximum for the session to use, and that would be the 1017 session bandwidth. The session bandwidth may be chosen based or some 1018 cost or a priori knowledge of the available network bandwidth for the 1019 session. It is somewhat independent of the media encoding, but the 1020 encoding choice may be limited by the session bandwidth. Often, the 1021 session bandwidth is the sum of the nominal bandwidths of the senders 1022 expected to be concurrently active. For teleconference audio, this 1023 number would typically be one sender's bandwidth. For layered 1024 encodings, each layer is a separate RTP session with its own session 1025 bandwidth parameter. 1027 The session bandwidth parameter is expected to be supplied by a 1028 session management application when it invokes a media application, 1029 but media applications MAY set a default based on the single-sender 1030 data bandwidth for the encoding selected for the session. The 1031 application MAY also enforce bandwidth limits based on multicast 1032 scope rules or other criteria. All participants MUST use the same 1033 value for the session bandwidth so that the same RTCP interval will 1034 be calculated. 1036 Bandwidth calculations for control and data traffic include lower- 1037 layer transport and network protocols (e.g., UDP and IP) since that 1038 is what the resource reservation system would need to know. The 1039 application can also be expected to know which of these protocols are 1040 in use. Link level headers are not included in the calculation since 1041 the packet will be encapsulated with different link level headers as 1042 it travels. 1044 The control traffic should be limited to a small and known fraction 1045 of the session bandwidth: small so that the primary function of the 1046 transport protocol to carry data is not impaired; known so that the 1047 control traffic can be included in the bandwidth specification given 1048 to a resource reservation protocol, and so that each participant can 1049 independently calculate its share. It is RECOMMENDED that the 1050 fraction of the session bandwidth allocated to RTCP be fixed at 5%. 1051 It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to 1052 participants that are sending data so that in sessions with a large 1053 number of receivers but a small number of senders, newly joining 1054 participants will more quickly receive the CNAME for the sending 1055 sites. When the proportion of senders is greater than 1/4 of the 1056 participants, the senders get their proportion of the full RTCP 1057 bandwidth. While the values of these and other constants in the 1058 interval calculation are not critical, all participants in the 1059 session MUST use the same values so the same interval will be 1060 calculated. Therefore, these constants SHOULD be fixed for a 1061 particular profile. 1063 A profile MAY specify that the control traffic bandwidth may be a 1064 separate parameter of the session rather than a strict percentage of 1065 the session bandwidth. Using a separate parameter allows rate- 1066 adaptive applications to set an RTCP bandwidth consistent with a 1067 "typical" data bandwidth that is lower than the maximum bandwidth 1068 specified by the session bandwidth parameter. 1070 The profile MAY further specify that the control traffic bandwidth 1071 may be divided into two separate session parameters for those 1072 participants which are active data senders and those which are not. 1073 Following the recommendation that 1/4 of the RTCP bandwidth be 1074 dedicated to data senders, the RECOMMENDED default values for these 1075 two parameters would be 1.25% and 3.75%, respectively. When the 1076 proportion of senders is greater than 1/4 of the participants, the 1077 senders get their proportion of the sum of these parameters. Using 1078 two parameters allows RTCP reception reports to be turned off 1079 entirely for a particular session by setting the RTCP bandwidth for 1080 non-data-senders to zero while keeping the RTCP bandwidth for data 1081 senders non-zero so that sender reports can still be sent for inter- 1082 media synchronization. This may be appropriate for systems operating 1083 on unidirectional links or for sessions that don't require feedback 1084 on the quality of reception. 1086 The calculated interval between transmissions of compound RTCP 1087 packets SHOULD also have a lower bound to avoid having bursts of 1088 packets exceed the allowed bandwidth when the number of participants 1089 is small and the traffic isn't smoothed according to the law of large 1090 numbers. It also keeps the report interval from becoming too small 1091 during transient outages like a network partition such that 1092 adaptation is delayed when the partition heals. At application 1093 startup, a delay SHOULD be imposed before the first compound RTCP 1094 packet is sent to allow time for RTCP packets to be received from 1095 other participants so the report interval will converge to the 1096 correct value more quickly. This delay MAY be set to half the 1097 minimum interval to allow quicker notification that the new 1098 participant is present. The RECOMMENDED value for a fixed minimum 1099 interval is 5 seconds. 1101 An implementation MAY scale the minimum RTCP interval to a smaller 1102 value inversely proportional to the session bandwidth parameter with 1103 the following limitations: 1105 o For multicast sessions, only active data senders MAY use the 1106 reduced minimum value to calculate the interval for 1107 transmission of compound RTCP packets. 1109 o For unicast sessions, the reduced value MAY be used by 1110 participants that are not active data senders as well, and the 1111 delay before sending the initial compound RTCP packet MAY be 1112 zero. 1114 o For all sessions, the fixed minimum SHOULD be used when 1115 calculating the participant timeout interval (see Section 1116 6.3.5) so that implementations which do not use the reduced 1117 value for transmitting RTCP packets are not timed out by other 1118 participants prematurely. 1120 o The RECOMMENDED value for the reduced minimum in seconds is 1121 360 divided by the session bandwidth in kilobits/second. This 1122 minimum is smaller than 5 seconds for bandwidths greater than 1123 72 kb/s. 1125 The algorithm described in Section 6.3 and Appendix A.7 was designed 1126 to meet the goals outlined in this section. It calculates the 1127 interval between sending compound RTCP packets to divide the allowed 1128 control traffic bandwidth among the participants. This allows an 1129 application to provide fast response for small sessions where, for 1130 example, identification of all participants is important, yet 1131 automatically adapt to large sessions. The algorithm incorporates the 1132 following characteristics: 1134 o The calculated interval between RTCP packets scales linearly 1135 with the number of members in the group. It is this linear 1136 factor which allows for a constant amount of control traffic 1137 when summed across all members. 1139 o The interval between RTCP packets is varied randomly over the 1140 range [0.5,1.5] times the calculated interval to avoid 1141 unintended synchronization of all participants [15]. The 1142 first RTCP packet sent after joining a session is also delayed 1143 by a random variation of half the minimum RTCP interval. 1145 o A dynamic estimate of the average compound RTCP packet size is 1146 calculated, including all those received and sent, to 1147 automatically adapt to changes in the amount of control 1148 information carried. 1150 o Since the calculated interval is dependent on the number of 1151 observed group members, there may be undesirable startup 1152 effects when a new user joins an existing session, or many 1153 users simultaneously join a new session. These new users will 1154 initially have incorrect estimates of the group membership, 1155 and thus their RTCP transmission interval will be too short. 1156 This problem can be significant if many users join the session 1157 simultaneously. To deal with this, an algorithm called "timer 1158 reconsideration" is employed. This algorithm implements a 1159 simple back-off mechanism which causes users to hold back RTCP 1160 packet transmission if the group sizes are increasing. 1162 o When users leave a session, either with a BYE or by timeout, 1163 the group membership decreases, and thus the calculated 1164 interval should decrease. A "reverse reconsideration" 1165 algorithm is used to allow members to more quickly reduce 1166 their intervals in response to group membership decreases. 1168 o BYE packets are given different treatment than other RTCP 1169 packets. When a user leaves a group, and wishes to send a BYE 1170 packet, it may do so before its next scheduled RTCP packet. 1171 However, transmission of BYE's follows a back-off algorithm 1172 which avoids floods of BYE packets should a large number of 1173 members simultaneously leave the session. 1175 This algorithm may be used for sessions in which all participants are 1176 allowed to send. In that case, the session bandwidth parameter is the 1177 product of the individual sender's bandwidth times the number of 1178 participants, and the RTCP bandwidth is 5% of that. 1180 Details of the algorithm's operation are given in the sections that 1181 follow. Appendix A.7 gives an example implementation. 1183 6.2.1 Maintaining the number of session members 1185 Calculation of the RTCP packet interval depends upon an estimate of 1186 the number of sites participating in the session. New sites are added 1187 to the count when they are heard, and an entry for each SHOULD be 1188 created in a table indexed by the SSRC or CSRC identifier (see 1189 Section 8.2) to keep track of them. New entries MAY be considered not 1190 valid until multiple packets carrying the new SSRC have been received 1191 (see Appendix A.1), or until an SDES RTCP packet containing a CNAME 1192 for that SSRC has been received. Entries MAY be deleted from the 1193 table when an RTCP BYE packet with the corresponding SSRC identifier 1194 is received, except that some straggler data packets might arrive 1195 after the BYE and cause the entry to be recreated. Instead, the entry 1196 SHOULD be marked as having received a BYE and then deleted after an 1197 appropriate delay. 1199 A participant MAY mark another site inactive, or delete it if not yet 1200 valid, if no RTP or RTCP packet has been received for a small number 1201 of RTCP report intervals (5 is RECOMMENDED). This provides some 1202 robustness against packet loss. All sites must have the same value 1203 for this multiplier and must calculate roughly the same value for the 1204 RTCP report interval in order for this timeout to work properly. 1205 Therefore, this multiplier SHOULD be fixed for a particular profile. 1207 For sessions with a very large number of participants, it may be 1208 impractical to maintain a table to store the SSRC identifier and 1209 state information for all of them. An implementation MAY use SSRC 1210 sampling, as described in [16], to reduce the storage requirements. 1211 An implementation MAY use any other algorithm with similar 1212 performance. A key requirement is that any algorithm considered 1213 SHOULD NOT substantially underestimate the group size, although it 1214 MAY overestimate. 1216 6.3 RTCP Packet Send and Receive Rules 1218 The rules for how to send, and what to do when receiving an RTCP 1219 packet are outlined here. An implementation that allows operation in 1220 a multicast environment or a multipoint unicast environment MUST meet 1221 the requirements in Section 6.2. Such an implementation MAY use the 1222 algorithm defined in this section to meet those requirements, or MAY 1223 use some other algorithm so long as it provides equivalent or better 1224 performance. An implementation which is constrained to two-party 1225 unicast operation SHOULD still use randomization of the RTCP 1226 transmission interval to avoid unintended synchronization of multiple 1227 instances operating in the same environment, but MAY omit the "timer 1228 reconsideration" and "reverse reconsideration" algorithms in Sections 1229 6.3.3, 6.3.6 and 6.3.7. 1231 To execute these rules, a session participant must maintain several 1232 pieces of state: 1234 tp: the last time an RTCP packet was transmitted; 1236 tc: the current time; 1238 tn: the next scheduled transmission time of an RTCP packet; 1240 pmembers: the estimated number of session members at the time tn 1241 was last recomputed; 1243 members: the most current estimate for the number of session 1244 members; 1246 senders: the most current estimate for the number of senders in 1247 the session; 1249 rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth 1250 that will be used for RTCP packets by all members of this 1251 session, in octets per second. This will be a specified 1252 fraction of the "session bandwidth" parameter supplied to 1253 the application at startup. 1255 we_sent: Flag that is true if the application has sent data 1256 since the 2nd previous RTCP report was transmitted. 1258 avg_rtcp_size: The average compound RTCP packet size, in octets, 1259 over all RTCP packets sent and received by this 1260 participant. The size includes lower-layer transport and 1261 network protocol headers (e.g., UDP and IP) as explained in 1262 Section 6.2. 1264 initial: Flag that is true if the application has not yet sent 1265 an RTCP packet. 1267 Many of these rules make use of the "calculated interval" between 1268 packet transmissions. This interval is described in the following 1269 section. 1271 6.3.1 Computing the RTCP transmission interval 1273 To maintain scalability, the average interval between packets from a 1274 session participant should scale with the group size. This interval 1275 is called the calculated interval. It is obtained by combining a 1276 number of the pieces of state described above. The calculated 1277 interval T is then determined as follows: 1279 1. If there are any senders (senders > 0) in the session, but 1280 the number of senders is less than 25% of the membership 1281 (members), the interval depends on whether the participant 1282 is a sender or not (based on the value of we_sent). If the 1283 participant is a sender (we_sent true), the constant C is 1284 set to the average RTCP packet size (avg_rtcp_size) divided 1285 by 25% of the RTCP bandwidth (rtcp_bw), and the constant n 1286 is set to the number of senders. If we_sent is not true, 1287 the constant C is set to the average RTCP packet size 1288 divided by 75% of the RTCP bandwidth. The constant n is set 1289 to the number of receivers (members - senders). If the 1290 number of senders is greater than 25%, senders and 1291 receivers are treated together. The constant C is set to 1292 the total RTCP bandwidth and n is set to the total number 1293 of members. 1295 2. If the participant has not yet sent an RTCP packet (the 1296 variable initial is true), the constant Tmin is set to 2.5 1297 seconds, else it is set to 5 seconds. 1299 3. The deterministic calculated interval Td is set to 1300 max(Tmin, n*C). 1302 4. The calculated interval T is set to a number uniformly 1303 distributed between 0.5 and 1.5 times the deterministic 1304 calculated interval. 1306 5. The resulting value of T is divided by e-3/2=1.21828 to 1307 compensate for the fact that the timer reconsideration 1308 algorithm converges to a value of the RTCP bandwidth below 1309 the intended average. 1311 This procedure results in an interval which is random, but which, on 1312 average, gives at least 25% of the RTCP bandwidth to senders and the 1313 rest to receivers. If the senders constitute more than one quarter of 1314 the membership, this procedure splits the bandwidth equally among all 1315 participants, on average. 1317 6.3.2 Initialization 1319 Upon joining the session, the participant initializes tp to 0, tc to 1320 0, senders to 0, pmembers to 1, members to 1, we_sent to false, 1321 rtcp_bw to the specified fraction of the session bandwidth, initial 1322 to true, and avg_rtcp_size to the probable size of the first RTCP 1323 packet that the application will later construct. The calculated 1324 interval T is then computed, and the first packet is scheduled for 1325 time tn = T. This means that a transmission timer is set which 1326 expires at time T. Note that an application MAY use any desired 1327 approach for implementing this timer. 1329 The participant adds its own SSRC to the member table. 1331 6.3.3 Receiving an RTP or non-BYE RTCP packet 1333 When an RTP or RTCP packet is received from a participant whose SSRC 1334 is not in the member table, the SSRC is added to the table, and the 1335 value for members is updated once the participant has been validated 1336 as described in Section 6.2.1. The same processing occurs for each 1337 CSRC in a validated RTP packet. 1339 When an RTP packet is received from a participant whose SSRC is not 1340 in the sender table, the SSRC is added to the table, and the value 1341 for senders is updated. 1343 For each compound RTCP packet received, the value of avg_rtcp_size is 1344 updated: avg_rtcp_size = (1/16)*packet_size + (15/16)* avg_rtcp_size, 1345 where packet_size is the size of the RTCP packet just received. 1347 6.3.4 Receiving an RTCP BYE packet 1349 Except as described in Section 6.3.7 for the case when an RTCP BYE is 1350 to be transmitted, if the received packet is an RTCP BYE packet, the 1351 SSRC is checked against the member table. If present, the entry is 1352 removed from the table, and the value for members is updated. The 1353 SSRC is then checked against the sender table. If present, the entry 1354 is removed from the table, and the value for senders is updated. 1356 Furthermore, to make the transmission rate of RTCP packets more 1357 adaptive to changes in group membership, the following "reverse 1358 reconsideration" algorithm SHOULD be executed when a BYE packet is 1359 received that reduces members to a value less than pmembers: 1361 o The value for tn is updated according to the following 1362 formula: tn = tc + (members/pmembers)(tn - tc). 1364 o The value for tp is updated according the following formula: 1365 tp = tc - (members/pmembers)(tc - tp). 1367 o The next RTCP packet is rescheduled for transmission at time 1368 tn, which is now earlier. 1370 o The value of pmembers is set equal to members. 1372 This algorithm does not prevent the group size estimate from 1373 incorrectly dropping to zero for a short time due to premature 1374 timeouts when most participants of a large session leave at once but 1375 some remain. The algorithm does make the estimate return to the 1376 correct value more rapidly. This situation is unusual enough and the 1377 consequences are sufficiently harmless that this problem is deemed 1378 only a secondary concern. 1380 6.3.5 Timing Out an SSRC 1382 At occassional intervals, the participant MUST check to see if any of 1383 the other participants time out. To do this, the participant computes 1384 the deterministic (without the randomization factor) calculated 1385 interval Td for a receiver, that is, with we_sent false. Any other 1386 session member who has not sent an RTP or RTCP packet since time tc - 1387 MTd (M is the timeout multiplier, and defaults to 5) is timed out. 1388 This means that its SSRC is removed from the member list, and members 1389 is updated. A similar check is performed on the sender list. Any 1390 member on the sender list who has not sent an RTP packet since time 1391 tc - 2T (within the last two RTCP report intervals) is removed from 1392 the sender list, and senders is updated. 1394 If any members time out, the reverse reconsideration algorithm 1395 described in Section 6.3.4 SHOULD be performed. 1397 The participant MUST perform this check at least once per RTCP 1398 transmission interval. 1400 6.3.6 Expiration of transmission timer 1402 When the packet transmission timer expires, the participant performs 1403 the following operations: 1405 o The transmission interval T is computed as described in 1406 Section 6.3.1, including the randomization factor. 1408 o If tp + T is less than or equal to tc, an RTCP packet is 1409 transmitted. tp is set to tc, then another value for T is 1410 calculated as in the previous step and tn is set to tc + T. 1411 The transmission timer is set to expire again at time tn. If 1412 tp + T is greater than tc, tn is set to tp + T. No RTCP packet 1413 is transmitted. The transmission timer is set to expire at 1414 time tn. 1416 o pmembers is set to members. 1418 If an RTCP packet is transmitted, the value of initial is set to 1419 FALSE. Furthermore, the value of avg_rtcp_size is updated: 1420 avg_rtcp_size = (1/16)*packet_size + (15/16)* avg_rtcp_size, where 1421 packet_size is the size of the RTCP packet just transmitted. 1423 6.3.7 Transmitting a BYE packet 1425 When a participant wishes to leave a session, a BYE packet is 1426 transmitted to inform the other participants of the event. In order 1427 to avoid a flood of BYE packets when many participants leave the 1428 system, a participant MUST execute the following algorithm if the 1429 number of members is more than 50 when the participant chooses to 1430 leave. This algorithm usurps the normal role of the members variable 1431 to count BYE packets instead: 1433 o When the participant decides to leave the system, tp is reset 1434 to tc, the current time, members and pmembers are initialized 1435 to 1, initial is set to 1, we_sent is set to false, senders is 1436 set to 0, and avg_rtcp_size is set to the size of the compound 1437 BYE packet. The calculated interval T is computed. The BYE 1438 packet is then scheduled for time tn = tc + T. 1440 o Every time a BYE packet from another participant is received, 1441 members is incremented by 1 regardless of whether that 1442 participant exists in the member table or not, and when SSRC 1443 sampling is in use, regardless of whether or not the BYE SSRC 1444 would be included in the sample. members is NOT incremented 1445 when other RTCP packets or RTP packets are received, but only 1446 for BYE packets. Similarly, avg_rtcp_size is updated only for 1447 received BYE packets. senders is NOT updated when RTP packets 1448 arrive; it remains 0. 1450 o Transmission of the BYE packet then follows the rules for 1451 transmitting a regular RTCP packet, as above. 1453 This allows BYE packets to be sent right away, yet controls their 1454 total bandwidth usage. In the worst case, this could cause RTCP 1455 control packets to use twice the bandwidth as normal (10%) -- 5% for 1456 non BYE RTCP packets and 5% for BYE. 1458 A participant that does not want to wait for the above mechanism to 1459 allow transmission of a BYE packet MAY leave the group without 1460 sending a BYE at all. That participant will eventually be timed out 1461 by the other group members. 1463 If the group size estimate members is less than 50 when the 1464 participant decides to leave, the participant MAY send a BYE packet 1465 immediately. Alternatively, the participant MAY choose to execute 1466 the above BYE backoff algorithm. 1468 In either case, a participant which never sent an RTP or RTCP packet 1469 MUST NOT send a BYE packet when they leave the group. 1471 6.3.8 Updating we_sent 1473 The variable we_sent contains true if the participant has sent an RTP 1474 packet recently, false otherwise. This determination is made by using 1475 the same mechanisms as for managing the set of other participants 1476 listed in the senders table. If the participant sends an RTP packet 1477 when we_sent is false, it adds itself to the sender table and sets 1478 we_sent to true. The reverse reconsideration algorithm described in 1479 Section 6.3.4 SHOULD be performed to possibly reduce the delay before 1480 sending an SR packet. Every time another RTP packet is sent, the 1481 time of transmission of that packet is maintained in the table. The 1482 normal sender timeout algorithm is then applied to the participant -- 1483 if an RTP packet has not been transmitted since time tc - 2T, the 1484 participant removes itself from the sender table, decrements the 1485 sender count, and sets we_sent to false. 1487 6.3.9 Allocation of source description bandwidth 1489 This specification defines several source description (SDES) items in 1490 addition to the mandatory CNAME item, such as NAME (personal name) 1491 and EMAIL (email address). It also provides a means to define new 1492 application-specific RTCP packet types. Applications should exercise 1493 caution in allocating control bandwidth to this additional 1494 information because it will slow down the rate at which reception 1495 reports and CNAME are sent, thus impairing the performance of the 1496 protocol. It is RECOMMENDED that no more than 20% of the RTCP 1497 bandwidth allocated to a single participant be used to carry the 1498 additional information. Furthermore, it is not intended that all 1499 SDES items will be included in every application. Those that are 1500 included SHOULD be assigned a fraction of the bandwidth according to 1501 their utility. Rather than estimate these fractions dynamically, it 1502 is recommended that the percentages be translated statically into 1503 report interval counts based on the typical length of an item. 1505 For example, an application may be designed to send only CNAME, NAME 1506 and EMAIL and not any others. NAME might be given much higher 1507 priority than EMAIL because the NAME would be displayed continuously 1508 in the application's user interface, whereas EMAIL would be displayed 1509 only when requested. At every RTCP interval, an RR packet and an SDES 1510 packet with the CNAME item would be sent. For a small session 1511 operating at the minimum interval, that would be every 5 seconds on 1512 the average. Every third interval (15 seconds), one extra item would 1513 be included in the SDES packet. Seven out of eight times this would 1514 be the NAME item, and every eighth time (2 minutes) it would be the 1515 EMAIL item. 1517 When multiple applications operate in concert using cross-application 1518 binding through a common CNAME for each participant, for example in a 1519 multimedia conference composed of an RTP session for each medium, the 1520 additional SDES information MAY be sent in only one RTP session. The 1521 other sessions would carry only the CNAME item. In particular, this 1522 approach should be applied to the multiple sessions of a layered 1523 encoding scheme (see Section 2.4). 1525 6.4 Sender and Receiver Reports 1527 RTP receivers provide reception quality feedback using RTCP report 1528 packets which may take one of two forms depending upon whether or not 1529 the receiver is also a sender. The only difference between the sender 1530 report (SR) and receiver report (RR) forms, besides the packet type 1531 code, is that the sender report includes a 20-byte sender information 1532 section for use by active senders. The SR is issued if a site has 1533 sent any data packets during the interval since issuing the last 1534 report or the previous one, otherwise the RR is issued. 1536 Both the SR and RR forms include zero or more reception report 1537 blocks, one for each of the synchronization sources from which this 1538 receiver has received RTP data packets since the last report. Reports 1539 are not issued for contributing sources listed in the CSRC list. Each 1540 reception report block provides statistics about the data received 1541 from the particular source indicated in that block. Since a maximum 1542 of 31 reception report blocks will fit in an SR or RR packet, 1543 additional RR packets MAY be stacked after the initial SR or RR 1544 packet as needed to contain the reception reports for all sources 1545 heard during the interval since the last report. 1547 The next sections define the formats of the two reports, how they may 1548 be extended in a profile-specific manner if an application requires 1549 additional feedback information, and how the reports may be used. 1550 Details of reception reporting by translators and mixers is given in 1551 Section 7. 1553 6.4.1 SR: Sender report RTCP packet 1554 0 1 2 3 1555 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 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 |V=2|P| RC | PT=SR=200 | length | header 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | SSRC of sender | 1560 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1561 | NTP timestamp, most significant word | sender 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info 1563 | NTP timestamp, least significant word | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | RTP timestamp | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | sender's packet count | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | sender's octet count | 1570 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1571 | SSRC_1 (SSRC of first source) | report 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1573 | fraction lost | cumulative number of packets lost | 1 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | extended highest sequence number received | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | interarrival jitter | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | last SR (LSR) | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | delay since last SR (DLSR) | 1582 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1583 | SSRC_2 (SSRC of second source) | report 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1585 : ... : 2 1586 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1587 | profile-specific extensions | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 The sender report packet consists of three sections, possibly 1591 followed by a fourth profile-specific extension section if defined. 1592 The first section, the header, is 8 octets long. The fields have the 1593 following meaning: 1595 version (V): 2 bits 1596 Identifies the version of RTP, which is the same in RTCP 1597 packets as in RTP data packets. The version defined by this 1598 specification is two (2). 1600 padding (P): 1 bit 1601 If the padding bit is set, this individual RTCP packet 1602 contains some additional padding octets at the end which 1603 are not part of the control information but are included in 1604 the length field. The last octet of the padding is a count 1605 of how many padding octets should be ignored, including 1606 itself (it will be a multiple of four). Padding may be 1607 needed by some encryption algorithms with fixed block 1608 sizes. In a compound RTCP packet, padding is only required 1609 on one individual packet because the compound packet is 1610 encrypted as a whole for the method in Section 9.1. Thus, 1611 padding MUST only be added to the last individual packet, 1612 and if padding is added to that packet, the padding bit 1613 MUST be set only on that packet. This convention aids the 1614 header validity checks described in Appendix A.2 and allows 1615 detection of packets from some early implementations that 1616 incorrectly set the padding bit on the first individual 1617 packet and add padding to the last individual packet. 1619 reception report count (RC): 5 bits 1620 The number of reception report blocks contained in this 1621 packet. A value of zero is valid. 1623 packet type (PT): 8 bits 1624 Contains the constant 200 to identify this as an RTCP SR 1625 packet. 1627 length: 16 bits 1628 The length of this RTCP packet in 32-bit words minus one, 1629 including the header and any padding. (The offset of one 1630 makes zero a valid length and avoids a possible infinite 1631 loop in scanning a compound RTCP packet, while counting 1632 32-bit words avoids a validity check for a multiple of 4.) 1634 SSRC: 32 bits 1635 The synchronization source identifier for the originator of 1636 this SR packet. 1638 The second section, the sender information, is 20 octets long and is 1639 present in every sender report packet. It summarizes the data 1640 transmissions from this sender. The fields have the following 1641 meaning: 1643 NTP timestamp: 64 bits 1644 Indicates the wallclock time (see Section 4) when this 1645 report was sent so that it may be used in combination with 1646 timestamps returned in reception reports from other 1647 receivers to measure round-trip propagation to those 1648 receivers. Receivers should expect that the measurement 1649 accuracy of the timestamp may be limited to far less than 1650 the resolution of the NTP timestamp. The measurement 1651 uncertainty of the timestamp is not indicated as it may not 1652 be known. On a system that has no notion of wallclock time 1653 but does have some system-specific clock such as "system 1654 uptime", a sender MAY use that clock as a reference to 1655 calculate relative NTP timestamps. It is important to 1656 choose a commonly used clock so that if separate 1657 implementations are used to produce the individual streams 1658 of a multimedia session, all implementations will use the 1659 same clock. Until the year 2036, relative and absolute 1660 timestamps will differ in the high bit so (invalid) 1661 comparisons will show a large difference; by then one hopes 1662 relative timestamps will no longer be needed. A sender 1663 that has no notion of wallclock or elapsed time MAY set the 1664 NTP timestamp to zero. 1666 RTP timestamp: 32 bits 1667 Corresponds to the same time as the NTP timestamp (above), 1668 but in the same units and with the same random offset as 1669 the RTP timestamps in data packets. This correspondence may 1670 be used for intra- and inter-media synchronization for 1671 sources whose NTP timestamps are synchronized, and may be 1672 used by media-independent receivers to estimate the nominal 1673 RTP clock frequency. Note that in most cases this timestamp 1674 will not be equal to the RTP timestamp in any adjacent data 1675 packet. Rather, it MUST be calculated from the 1676 corresponding NTP timestamp using the relationship between 1677 the RTP timestamp counter and real time as maintained by 1678 periodically checking the wallclock time at a sampling 1679 instant. 1681 sender's packet count: 32 bits 1682 The total number of RTP data packets transmitted by the 1683 sender since starting transmission up until the time this 1684 SR packet was generated. The count SHOULD be reset if the 1685 sender changes its SSRC identifier. 1687 sender's octet count: 32 bits 1688 The total number of payload octets (i.e., not including 1689 header or padding) transmitted in RTP data packets by the 1690 sender since starting transmission up until the time this 1691 SR packet was generated. The count SHOULD be reset if the 1692 sender changes its SSRC identifier. This field can be used 1693 to estimate the average payload data rate. 1695 The third section contains zero or more reception report blocks 1696 depending on the number of other sources heard by this sender since 1697 the last report. Each reception report block conveys statistics on 1698 the reception of RTP packets from a single synchronization source. 1699 Receivers SHOULD NOT carry over statistics when a source changes its 1700 SSRC identifier due to a collision. These statistics are: 1702 SSRC_n (source identifier): 32 bits 1703 The SSRC identifier of the source to which the information 1704 in this reception report block pertains. 1706 fraction lost: 8 bits 1707 The fraction of RTP data packets from source SSRC_n lost 1708 since the previous SR or RR packet was sent, expressed as a 1709 fixed point number with the binary point at the left edge 1710 of the field. (That is equivalent to taking the integer 1711 part after multiplying the loss fraction by 256.) This 1712 fraction is defined to be the number of packets lost 1713 divided by the number of packets expected, as defined in 1714 the next paragraph. An implementation is shown in Appendix 1715 A.3. If the loss is negative due to duplicates, the 1716 fraction lost is set to zero. Note that a receiver cannot 1717 tell whether any packets were lost after the last one 1718 received, and that there will be no reception report block 1719 issued for a source if all packets from that source sent 1720 during the last reporting interval have been lost. 1722 cumulative number of packets lost: 24 bits 1723 The total number of RTP data packets from source SSRC_n 1724 that have been lost since the beginning of reception. This 1725 number is defined to be the number of packets expected less 1726 the number of packets actually received, where the number 1727 of packets received includes any which are late or 1728 duplicates. Thus packets that arrive late are not counted 1729 as lost, and the loss may be negative if there are 1730 duplicates. The number of packets expected is defined to 1731 be the extended last sequence number received, as defined 1732 next, less the initial sequence number received. This may 1733 be calculated as shown in Appendix A.3. 1735 extended highest sequence number received: 32 bits 1736 The low 16 bits contain the highest sequence number 1737 received in an RTP data packet from source SSRC_n, and the 1738 most significant 16 bits extend that sequence number with 1739 the corresponding count of sequence number cycles, which 1740 may be maintained according to the algorithm in Appendix 1741 A.1. Note that different receivers within the same session 1742 will generate different extensions to the sequence number 1743 if their start times differ significantly. 1745 interarrival jitter: 32 bits 1746 An estimate of the statistical variance of the RTP data 1747 packet interarrival time, measured in timestamp units and 1748 expressed as an unsigned integer. The interarrival jitter J 1749 is defined to be the mean deviation (smoothed absolute 1750 value) of the difference D in packet spacing at the 1751 receiver compared to the sender for a pair of packets. As 1752 shown in the equation below, this is equivalent to the 1753 difference in the "relative transit time" for the two 1754 packets; the relative transit time is the difference 1755 between a packet's RTP timestamp and the receiver's clock 1756 at the time of arrival, measured in the same units. 1758 If Si is the RTP timestamp from packet i, and Ri is the 1759 time of arrival in RTP timestamp units for packet i, then 1760 for two packets i and j, D may be expressed as D(i,j) = 1761 (R_j - R_i) - (S_j - S_i) = (R_j - S_j) - (R_i - S_i) 1763 The interarrival jitter SHOULD be calculated continuously 1764 as each data packet i is received from source SSRC_n, using 1765 this difference D for that packet and the previous packet 1766 i-1 in order of arrival (not necessarily in sequence), 1767 according to the formula J_i = J_i-1 + (|D(i-1,i)| - J_i- 1768 1)/16 1769 Whenever a reception report is issued, the current value of 1770 J is sampled. 1772 The jitter calculation MUST conform to the formula 1773 specified here in order to allow profile-independent 1774 monitors to make valid interpretations of reports coming 1775 from different implementations. This algorithm is the 1776 optimal first-order estimator and the gain parameter 1/16 1777 gives a good noise reduction ratio while maintaining a 1778 reasonable rate of convergence [17]. A sample 1779 implementation is shown in Appendix A.8. 1781 last SR timestamp (LSR): 32 bits 1782 The middle 32 bits out of 64 in the NTP timestamp (as 1783 explained in Section 4) received as part of the most recent 1784 RTCP sender report (SR) packet from source SSRC_n. If no SR 1785 has been received yet, the field is set to zero. 1787 delay since last SR (DLSR): 32 bits 1788 The delay, expressed in units of 1/65536 seconds, between 1789 receiving the last SR packet from source SSRC_n and sending 1790 this reception report block. If no SR packet has been 1791 received yet from SSRC_n, the DLSR field is set to zero. 1793 Let SSRC_r denote the receiver issuing this receiver 1794 report. Source SSRC_n can compute the round-trip 1795 propagation delay to SSRC_r by recording the time A when 1796 this reception report block is received. It calculates the 1797 total round-trip time A-LSR using the last SR timestamp 1798 (LSR) field, and then subtracting this field to leave the 1799 round-trip propagation delay as (A- LSR - DLSR). This is 1800 illustrated in Fig. 2. Times are shown in both a 1801 hexadecimal representation of the 32-bit fields and the 1802 equivalent floating-point decimal representation. Colons 1803 indicate a 32-bit field divided into a 16-bit integer part 1804 and 16-bit fraction part. 1806 This may be used as an approximate measure of distance to 1807 cluster receivers, although some links have very asymmetric 1808 delays. 1810 [10 Nov 1995 11:33:25.125] [10 Nov 1995 11:33:36.5] 1811 n SR(n) A=b710:8000 (46864.500 s) 1812 ----------------------------------------------------------------> 1813 v ^ 1814 ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s) 1815 ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s) 1816 (3024992016.125 s) v ^ 1817 r v ^ RR(n) 1818 ----------------------------------------------------------------> 1819 |<-DLSR->| 1820 (5.250 s) 1822 A 0xb710:8000 (46864.500 s) 1823 DLSR -0x0005:4000 ( 5.250 s) 1824 LSR -0xb705:2000 (46853.125 s) 1825 ------------------------------- 1826 delay 0x 6:2000 ( 6.125 s) 1828 Figure 2: Example for round-trip time computation 1830 6.4.2 RR: Receiver report RTCP packet 1831 0 1 2 3 1832 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 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 |V=2|P| RC | PT=RR=201 | length | header 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | SSRC of packet sender | 1837 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1838 | SSRC_1 (SSRC of first source) | report 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1840 | fraction lost | cumulative number of packets lost | 1 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | extended highest sequence number received | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 | interarrival jitter | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | last SR (LSR) | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | delay since last SR (DLSR) | 1849 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1850 | SSRC_2 (SSRC of second source) | report 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1852 : ... : 2 1853 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1854 | profile-specific extensions | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 The format of the receiver report (RR) packet is the same as that of 1858 the SR packet except that the packet type field contains the constant 1859 201 and the five words of sender information are omitted (these are 1860 the NTP and RTP timestamps and sender's packet and octet counts). The 1861 remaining fields have the same meaning as for the SR packet. 1863 An empty RR packet (RC = 0) MUST be put at the head of a compound 1864 RTCP packet when there is no data transmission or reception to 1865 report. 1867 6.4.3 Extending the sender and receiver reports 1869 A profile SHOULD define profile-specific extensions to the sender 1870 report and receiver report if there is additional information that 1871 needs to be reported regularly about the sender or receivers. This 1872 method SHOULD be used in preference to defining another RTCP packet 1873 type because it requires less overhead: 1875 o fewer octets in the packet (no RTCP header or SSRC field); 1877 o simpler and faster parsing because applications running under 1878 that profile would be programmed to always expect the 1879 extension fields in the directly accessible location after the 1880 reception reports. 1882 The extension is a fourth section in the sender- or receiver-report 1883 packet which comes at the end after the reception report blocks, if 1884 any. If additional sender information is required, then for sender 1885 reports it would be included first in the extension section, but for 1886 receiver reports it would not be present. If information about 1887 receivers is to be included, that data SHOULD be structured as an 1888 array of blocks parallel to the existing array of reception report 1889 blocks; that is, the number of blocks would be indicated by the RC 1890 field. 1892 6.4.4 Analyzing sender and receiver reports 1894 It is expected that reception quality feedback will be useful not 1895 only for the sender but also for other receivers and third-party 1896 monitors. The sender may modify its transmissions based on the 1897 feedback; receivers can determine whether problems are local, 1898 regional or global; network managers may use profile-independent 1899 monitors that receive only the RTCP packets and not the corresponding 1900 RTP data packets to evaluate the performance of their networks for 1901 multicast distribution. 1903 Cumulative counts are used in both the sender information and 1904 receiver report blocks so that differences may be calculated between 1905 any two reports to make measurements over both short and long time 1906 periods, and to provide resilience against the loss of a report. The 1907 difference between the last two reports received can be used to 1908 estimate the recent quality of the distribution. The NTP timestamp is 1909 included so that rates may be calculated from these differences over 1910 the interval between two reports. Since that timestamp is independent 1911 of the clock rate for the data encoding, it is possible to implement 1912 encoding- and profile-independent quality monitors. 1914 An example calculation is the packet loss rate over the interval 1915 between two reception reports. The difference in the cumulative 1916 number of packets lost gives the number lost during that interval. 1917 The difference in the extended last sequence numbers received gives 1918 the number of packets expected during the interval. The ratio of 1919 these two is the packet loss fraction over the interval. This ratio 1920 should equal the fraction lost field if the two reports are 1921 consecutive, but otherwise it may not. The loss rate per second can 1922 be obtained by dividing the loss fraction by the difference in NTP 1923 timestamps, expressed in seconds. The number of packets received is 1924 the number of packets expected minus the number lost. The number of 1925 packets expected may also be used to judge the statistical validity 1926 of any loss estimates. For example, 1 out of 5 packets lost has a 1927 lower significance than 200 out of 1000. 1929 From the sender information, a third-party monitor can calculate the 1930 average payload data rate and the average packet rate over an 1931 interval without receiving the data. Taking the ratio of the two 1932 gives the average payload size. If it can be assumed that packet loss 1933 is independent of packet size, then the number of packets received by 1934 a particular receiver times the average payload size (or the 1935 corresponding packet size) gives the apparent throughput available to 1936 that receiver. 1938 In addition to the cumulative counts which allow long-term packet 1939 loss measurements using differences between reports, the fraction 1940 lost field provides a short-term measurement from a single report. 1941 This becomes more important as the size of a session scales up enough 1942 that reception state information might not be kept for all receivers 1943 or the interval between reports becomes long enough that only one 1944 report might have been received from a particular receiver. 1946 The interarrival jitter field provides a second short-term measure of 1947 network congestion. Packet loss tracks persistent congestion while 1948 the jitter measure tracks transient congestion. The jitter measure 1949 may indicate congestion before it leads to packet loss. Since the 1950 interarrival jitter field is only a snapshot of the jitter at the 1951 time of a report, it may be necessary to analyze a number of reports 1952 from one receiver over time or from multiple receivers, e.g., within 1953 a single network. 1955 6.5 SDES: Source description RTCP packet 1957 0 1 2 3 1958 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 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 |V=2|P| SC | PT=SDES=202 | length | header 1961 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1962 | SSRC/CSRC_1 | chunk 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1964 | SDES items | 1965 | ... | 1966 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1967 | SSRC/CSRC_2 | chunk 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 1969 | SDES items | 1970 | ... | 1971 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1972 The SDES packet is a three-level structure composed of a header and 1973 zero or more chunks, each of of which is composed of items describing 1974 the source identified in that chunk. The items are described 1975 individually in subsequent sections. 1977 version (V), padding (P), length: 1978 As described for the SR packet (see Section 6.4.1). 1980 packet type (PT): 8 bits 1981 Contains the constant 202 to identify this as an RTCP SDES 1982 packet. 1984 source count (SC): 5 bits 1985 The number of SSRC/CSRC chunks contained in this SDES 1986 packet. A value of zero is valid but useless. 1988 Each chunk consists of an SSRC/CSRC identifier followed by a list of 1989 zero or more items, which carry information about the SSRC/CSRC. Each 1990 chunk starts on a 32-bit boundary. Each item consists of an 8-bit 1991 type field, an 8-bit octet count describing the length of the text 1992 (thus, not including this two-octet header), and the text itself. 1993 Note that the text can be no longer than 255 octets, but this is 1994 consistent with the need to limit RTCP bandwidth consumption. 1996 The text is encoded according to the UTF-8 encoding specified in RFC 1997 2279 [18]. US-ASCII is a subset of this encoding and requires no 1998 additional encoding. The presence of multi-octet encodings is 1999 indicated by setting the most significant bit of a character to a 2000 value of one. 2002 Items are contiguous, i.e., items are not individually padded to a 2003 32-bit boundary. Text is not null terminated because some multi-octet 2004 encodings include null octets. The list of items in each chunk MUST 2005 be terminated by one or more null octets, the first of which is 2006 interpreted as an item type of zero to denote the end of the list. 2007 No length octet follows the null item type octet, but additional null 2008 octets MUST be included if needed to pad until the next 32-bit 2009 boundary. Note that this padding is separate from that indicated by 2010 the P bit in the RTCP header. A chunk with zero items (four null 2011 octets) is valid but useless. 2013 End systems send one SDES packet containing their own source 2014 identifier (the same as the SSRC in the fixed RTP header). A mixer 2015 sends one SDES packet containing a chunk for each contributing source 2016 from which it is receiving SDES information, or multiple complete 2017 SDES packets in the format above if there are more than 31 such 2018 sources (see Section 7). 2020 The SDES items currently defined are described in the next sections. 2021 Only the CNAME item is mandatory. Some items shown here may be useful 2022 only for particular profiles, but the item types are all assigned 2023 from one common space to promote shared use and to simplify profile- 2024 independent applications. Additional items may be defined in a 2025 profile by registering the type numbers with IANA as described in 2026 Section 14. 2028 6.5.1 CNAME: Canonical end-point identifier SDES item 2030 0 1 2 3 2031 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 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | CNAME=1 | length | user and domain name ... 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 The CNAME identifier has the following properties: 2038 o Because the randomly allocated SSRC identifier may change if a 2039 conflict is discovered or if a program is restarted, the CNAME 2040 item MUST be included to provide the binding from the SSRC 2041 identifier to an identifier for the source that remains 2042 constant. 2044 o Like the SSRC identifier, the CNAME identifier SHOULD also be 2045 unique among all participants within one RTP session. 2047 o To provide a binding across multiple media tools used by one 2048 participant in a set of related RTP sessions, the CNAME SHOULD 2049 be fixed for that participant. 2051 o To facilitate third-party monitoring, the CNAME SHOULD be 2052 suitable for either a program or a person to locate the 2053 source. 2055 Therefore, the CNAME SHOULD be derived algorithmically and not 2056 entered manually, when possible. To meet these requirements, the 2057 following format SHOULD be used unless a profile specifies an 2058 alternate syntax or semantics. The CNAME item SHOULD have the format 2059 "user@host", or "host" if a user name is not available as on single- 2060 user systems. For both formats, "host" is either the fully qualified 2061 domain name of the host from which the real-time data originates, 2062 formatted according to the rules specified in RFC 1034 [19], RFC 1035 2063 [20] and Section 2.1 of RFC 1123 [21]; or the standard ASCII 2064 representation of the host's numeric address on the interface used 2065 for the RTP communication. For example, the standard ASCII 2066 representation of an IP Version 4 address is "dotted decimal", also 2067 known as dotted quad. Other address types are expected to have ASCII 2068 representations that are mutually unique. The fully qualified domain 2069 name is more convenient for a human observer and may avoid the need 2070 to send a NAME item in addition, but it may be difficult or 2071 impossible to obtain reliably in some operating environments. 2072 Applications that may be run in such environments SHOULD use the 2073 ASCII representation of the address instead. 2075 Examples are "doe@sleepy.megacorp.com" or "doe@192.0.2.89" for a 2076 multi-user system. On a system with no user name, examples would be 2077 "sleepy.megacorp.com" or "192.0.2.89". 2079 The user name SHOULD be in a form that a program such as "finger" or 2080 "talk" could use, i.e., it typically is the login name rather than 2081 the personal name. The host name is not necessarily identical to the 2082 one in the participant's electronic mail address. 2084 This syntax will not provide unique identifiers for each source if an 2085 application permits a user to generate multiple sources from one 2086 host. Such an application would have to rely on the SSRC to further 2087 identify the source, or the profile for that application would have 2088 to specify additional syntax for the CNAME identifier. 2090 If each application creates its CNAME independently, the resulting 2091 CNAMEs may not be identical as would be required to provide a binding 2092 across multiple media tools belonging to one participant in a set of 2093 related RTP sessions. If cross-media binding is required, it may be 2094 necessary for the CNAME of each tool to be externally configured with 2095 the same value by a coordination tool. 2097 Application writers should be aware that private network address 2098 assignments such as the Net-10 assignment proposed in RFC 1597 [22] 2099 may create network addresses that are not globally unique. This would 2100 lead to non-unique CNAMEs if hosts with private addresses and no 2101 direct IP connectivity to the public Internet have their RTP packets 2102 forwarded to the public Internet through an RTP-level translator. 2103 (See also RFC 1627 [23].) To handle this case, applications MAY 2104 provide a means to configure a unique CNAME, but the burden is on the 2105 translator to translate CNAMEs from private addresses to public 2106 addresses if necessary to keep private addresses from being exposed. 2108 6.5.2 NAME: User name SDES item 2109 0 1 2 3 2110 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 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | NAME=2 | length | common name of source ... 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 This is the real name used to describe the source, e.g., "John Doe, 2116 Bit Recycler, Megacorp". It may be in any form desired by the user. 2117 For applications such as conferencing, this form of name may be the 2118 most desirable for display in participant lists, and therefore might 2119 be sent most frequently of those items other than CNAME. Profiles MAY 2120 establish such priorities. The NAME value is expected to remain 2121 constant at least for the duration of a session. It SHOULD NOT be 2122 relied upon to be unique among all participants in the session. 2124 6.5.3 EMAIL: Electronic mail address SDES item 2126 0 1 2 3 2127 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 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | EMAIL=3 | length | email address of source ... 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 The email address is formatted according to RFC 822 [24], for 2133 example, "John.Doe@megacorp.com". The EMAIL value is expected to 2134 remain constant for the duration of a session. 2136 6.5.4 PHONE: Phone number SDES item 2138 0 1 2 3 2139 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 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | PHONE=4 | length | phone number of source ... 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 The phone number SHOULD be formatted with the plus sign replacing the 2145 international access code. For example, "+1 908 555 1212" for a 2146 number in the United States. 2148 6.5.5 LOC: Geographic user location SDES item 2149 0 1 2 3 2150 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 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | LOC=5 | length | geographic location of site ... 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 Depending on the application, different degrees of detail are 2156 appropriate for this item. For conference applications, a string 2157 like "Murray Hill, New Jersey" may be sufficient, while, for an 2158 active badge system, strings like "Room 2A244, AT&T BL MH" might be 2159 appropriate. The degree of detail is left to the implementation 2160 and/or user, but format and content MAY be prescribed by a profile. 2161 The LOC value is expected to remain constant for the duration of a 2162 session, except for mobile hosts. 2164 6.5.6 TOOL: Application or tool name SDES item 2166 0 1 2 3 2167 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 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | TOOL=6 | length | name/version of source appl. ... 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 A string giving the name and possibly version of the application 2173 generating the stream, e.g., "videotool 1.2". This information may be 2174 useful for debugging purposes and is similar to the Mailer or Mail- 2175 System-Version SMTP headers. The TOOL value is expected to remain 2176 constant for the duration of the session. 2178 6.5.7 NOTE: Notice/status SDES item 2180 0 1 2 3 2181 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 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | NOTE=7 | length | note about the source ... 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 The following semantics are suggested for this item, but these or 2187 other semantics MAY be explicitly defined by a profile. The NOTE item 2188 is intended for transient messages describing the current state of 2189 the source, e.g., "on the phone, can't talk". Or, during a seminar, 2190 this item might be used to convey the title of the talk. It should be 2191 used only to carry exceptional information and SHOULD NOT be included 2192 routinely by all participants because this would slow down the rate 2193 at which reception reports and CNAME are sent, thus impairing the 2194 performance of the protocol. In particular, it SHOULD NOT be included 2195 as an item in a user's configuration file nor automatically generated 2196 as in a quote-of-the-day. 2198 Since the NOTE item may be important to display while it is active, 2199 the rate at which other non-CNAME items such as NAME are transmitted 2200 might be reduced so that the NOTE item can take that part of the RTCP 2201 bandwidth. When the transient message becomes inactive, the NOTE item 2202 SHOULD continue to be transmitted a few times at the same repetition 2203 rate but with a string of length zero to signal the receivers. 2204 However, receivers SHOULD also consider the NOTE item inactive if it 2205 is not received for a small multiple of the repetition rate, or 2206 perhaps 20-30 RTCP intervals. 2208 6.5.8 PRIV: Private extensions SDES item 2210 0 1 2 3 2211 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 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | PRIV=8 | length | prefix length | prefix string... 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 ... | value string ... 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 This item is used to define experimental or application-specific SDES 2219 extensions. The item contains a prefix consisting of a length-string 2220 pair, followed by the value string filling the remainder of the item 2221 and carrying the desired information. The prefix length field is 8 2222 bits long. The prefix string is a name chosen by the person defining 2223 the PRIV item to be unique with respect to other PRIV items this 2224 application might receive. The application creator might choose to 2225 use the application name plus an additional subtype identification if 2226 needed. Alternatively, it is RECOMMENDED that others choose a name 2227 based on the entity they represent, then coordinate the use of the 2228 name within that entity. 2230 Note that the prefix consumes some space within the item's total 2231 length of 255 octets, so the prefix should be kept as short as 2232 possible. This facility and the constrained RTCP bandwidth SHOULD NOT 2233 be overloaded; it is not intended to satisfy all the control 2234 communication requirements of all applications. 2236 SDES PRIV prefixes will not be registered by IANA. If some form of 2237 the PRIV item proves to be of general utility, it SHOULD instead be 2238 assigned a regular SDES item type registered with IANA so that no 2239 prefix is required. This simplifies use and increases transmission 2240 efficiency. 2242 6.6 BYE: Goodbye RTCP packet 2244 0 1 2 3 2245 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 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 |V=2|P| SC | PT=BYE=203 | length | 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | SSRC/CSRC | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 : ... : 2252 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2253 | length | reason for leaving ... (opt) 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 The BYE packet indicates that one or more sources are no longer 2257 active. 2259 version (V), padding (P), length: 2260 As described for the SR packet (see Section 6.4.1). 2262 packet type (PT): 8 bits 2263 Contains the constant 203 to identify this as an RTCP BYE 2264 packet. 2266 source count (SC): 5 bits 2267 The number of SSRC/CSRC identifiers included in this BYE 2268 packet. A count value of zero is valid, but useless. 2270 The rules for when a BYE packet should be sent are specified in 2271 Sections 6.3.7 and 8.2. 2273 If a BYE packet is received by a mixer, the mixer SHOULD forward the 2274 BYE packet with the SSRC/CSRC identifier(s) unchanged. If a mixer 2275 shuts down, it SHOULD send a BYE packet listing all contributing 2276 sources it handles, as well as its own SSRC identifier. Optionally, 2277 the BYE packet MAY include an 8-bit octet count followed by that many 2278 octets of text indicating the reason for leaving, e.g., "camera 2279 malfunction" or "RTP loop detected". The string has the same encoding 2280 as that described for SDES. If the string fills the packet to the 2281 next 32-bit boundary, the string is not null terminated. If not, the 2282 BYE packet MUST be padded with null octets to the next 32-bit 2283 boundary. This padding is separate from that indicated by the P bit 2284 in the RTCP header. 2286 6.7 APP: Application-defined RTCP packet 2287 0 1 2 3 2288 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 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 |V=2|P| subtype | PT=APP=204 | length | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | SSRC/CSRC | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | name (ASCII) | 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 | application-dependent data ... 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 The APP packet is intended for experimental use as new applications 2300 and new features are developed, without requiring packet type value 2301 registration. APP packets with unrecognized names SHOULD be ignored. 2302 After testing and if wider use is justified, it is RECOMMENDED that 2303 each APP packet be redefined without the subtype and name fields and 2304 registered with IANA using an RTCP packet type. 2306 version (V), padding (P), length: 2307 As described for the SR packet (see Section 6.4.1). 2309 subtype: 5 bits 2310 May be used as a subtype to allow a set of APP packets to 2311 be defined under one unique name, or for any application- 2312 dependent data. 2314 packet type (PT): 8 bits 2315 Contains the constant 204 to identify this as an RTCP APP 2316 packet. 2318 name: 4 octets 2319 A name chosen by the person defining the set of APP packets 2320 to be unique with respect to other APP packets this 2321 application might receive. The application creator might 2322 choose to use the application name, and then coordinate the 2323 allocation of subtype values to others who want to define 2324 new packet types for the application. Alternatively, it is 2325 RECOMMENDED that others choose a name based on the entity 2326 they represent, then coordinate the use of the name within 2327 that entity. The name is interpreted as a sequence of four 2328 ASCII characters, with uppercase and lowercase characters 2329 treated as distinct. 2331 application-dependent data: variable length 2332 Application-dependent data may or may not appear in an APP 2333 packet. It is interpreted by the application and not RTP 2334 itself. It MUST be a multiple of 32 bits long. 2336 7 RTP Translators and Mixers 2338 In addition to end systems, RTP supports the notion of "translators" 2339 and "mixers", which could be considered as "intermediate systems" at 2340 the RTP level. Although this support adds some complexity to the 2341 protocol, the need for these functions has been clearly established 2342 by experiments with multicast audio and video applications in the 2343 Internet. Example uses of translators and mixers given in Section 2.3 2344 stem from the presence of firewalls and low bandwidth connections, 2345 both of which are likely to remain. 2347 7.1 General Description 2349 An RTP translator/mixer connects two or more transport-level 2350 "clouds". Typically, each cloud is defined by a common network and 2351 transport protocol (e.g., IP/UDP) plus a multicast address and 2352 transport level destination port or a pair of unicast addresses and 2353 ports. (Network-level protocol translators, such as IP version 4 to 2354 IP version 6, may be present within a cloud invisibly to RTP.) One 2355 system may serve as a translator or mixer for a number of RTP 2356 sessions, but each is considered a logically separate entity. 2358 In order to avoid creating a loop when a translator or mixer is 2359 installed, the following rules MUST be observed: 2361 o Each of the clouds connected by translators and mixers 2362 participating in one RTP session either MUST be distinct from 2363 all the others in at least one of these parameters (protocol, 2364 address, port), or MUST be isolated at the network level from 2365 the others. 2367 o A derivative of the first rule is that there MUST NOT be 2368 multiple translators or mixers connected in parallel unless by 2369 some arrangement they partition the set of sources to be 2370 forwarded. 2372 Similarly, all RTP end systems that can communicate through one or 2373 more RTP translators or mixers share the same SSRC space, that is, 2374 the SSRC identifiers MUST be unique among all these end systems. 2375 Section 8.2 describes the collision resolution algorithm by which 2376 SSRC identifiers are kept unique and loops are detected. 2378 There may be many varieties of translators and mixers designed for 2379 different purposes and applications. Some examples are to add or 2380 remove encryption, change the encoding of the data or the underlying 2381 protocols, or replicate between a multicast address and one or more 2382 unicast addresses. The distinction between translators and mixers is 2383 that a translator passes through the data streams from different 2384 sources separately, whereas a mixer combines them to form one new 2385 stream: 2387 Translator: Forwards RTP packets with their SSRC identifier 2388 intact; this makes it possible for receivers to identify 2389 individual sources even though packets from all the sources 2390 pass through the same translator and carry the translator's 2391 network source address. Some kinds of translators will pass 2392 through the data untouched, but others MAY change the 2393 encoding of the data and thus the RTP data payload type and 2394 timestamp. If multiple data packets are re-encoded into 2395 one, or vice versa, a translator MUST assign new sequence 2396 numbers to the outgoing packets. Losses in the incoming 2397 packet stream may induce corresponding gaps in the outgoing 2398 sequence numbers. Receivers cannot detect the presence of a 2399 translator unless they know by some other means what 2400 payload type or transport address was used by the original 2401 source. 2403 Mixer: Receives streams of RTP data packets from one or more 2404 sources, possibly changes the data format, combines the 2405 streams in some manner and then forwards the combined 2406 stream. Since the timing among multiple input sources will 2407 not generally be synchronized, the mixer will make timing 2408 adjustments among the streams and generate its own timing 2409 for the combined stream, so it is the synchronization 2410 source. Thus, all data packets forwarded by a mixer MUST be 2411 marked with the mixer's own SSRC identifier. In order to 2412 preserve the identity of the original sources contributing 2413 to the mixed packet, the mixer SHOULD insert their SSRC 2414 identifiers into the CSRC identifier list following the 2415 fixed RTP header of the packet. A mixer that is also itself 2416 a contributing source for some packet SHOULD explicitly 2417 include its own SSRC identifier in the CSRC list for that 2418 packet. 2420 For some applications, it MAY be acceptable for a mixer not 2421 to identify sources in the CSRC list. However, this 2422 introduces the danger that loops involving those sources 2423 could not be detected. 2425 The advantage of a mixer over a translator for applications like 2426 audio is that the output bandwidth is limited to that of one source 2427 even when multiple sources are active on the input side. This may be 2428 important for low-bandwidth links. The disadvantage is that receivers 2429 on the output side don't have any control over which sources are 2430 passed through or muted, unless some mechanism is implemented for 2431 remote control of the mixer. The regeneration of synchronization 2432 information by mixers also means that receivers can't do inter-media 2433 synchronization of the original streams. A multi-media mixer could do 2434 it. 2436 [E1] [E6] 2437 | | 2438 E1:17 | E6:15 | 2439 | | E6:15 2440 V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17) 2441 (M1)------------->----------------->-------------->[E7] 2442 ^ ^ E4:47 ^ E4:47 2443 E2:1 | E4:47 | | M3:89 (64,45) 2444 | | | 2445 [E2] [E4] M3:89 (64,45) | 2446 | legend: 2447 [E3] --------->(M2)----------->(M3)------------| [End system] 2448 E3:64 M2:12 (64) ^ (Mixer) 2449 | E5:45 2450 | 2451 [E5] source: SSRC (CSRCs) 2452 -------------------> 2454 Figure 3: Sample RTP network with end systems, mixers and translators 2456 A collection of mixers and translators is shown in Figure 3 to 2457 illustrate their effect on SSRC and CSRC identifiers. In the figure, 2458 end systems are shown as rectangles (named E), translators as 2459 triangles (named T) and mixers as ovals (named M). The notation "M1: 2460 48(1,17)" designates a packet originating a mixer M1, identified with 2461 M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17, 2462 copied from the SSRC identifiers of packets from E1 and E2. 2464 7.2 RTCP Processing in Translators 2466 In addition to forwarding data packets, perhaps modified, translators 2467 and mixers MUST also process RTCP packets. In many cases, they will 2468 take apart the compound RTCP packets received from end systems to 2469 aggregate SDES information and to modify the SR or RR packets. 2470 Retransmission of this information may be triggered by the packet 2471 arrival or by the RTCP interval timer of the translator or mixer 2472 itself. 2474 A translator that does not modify the data packets, for example one 2475 that just replicates between a multicast address and a unicast 2476 address, MAY simply forward RTCP packets unmodified as well. A 2477 translator that transforms the payload in some way MUST make 2478 corresponding transformations in the SR and RR information so that it 2479 still reflects the characteristics of the data and the reception 2480 quality. These translators MUST NOT simply forward RTCP packets. In 2481 general, a translator SHOULD NOT aggregate SR and RR packets from 2482 different sources into one packet since that would reduce the 2483 accuracy of the propagation delay measurements based on the LSR and 2484 DLSR fields. 2486 SR sender information: A translator does not generate its own 2487 sender information, but forwards the SR packets received 2488 from one cloud to the others. The SSRC is left intact but 2489 the sender information MUST be modified if required by the 2490 translation. If a translator changes the data encoding, it 2491 MUST change the "sender's byte count" field. If it also 2492 combines several data packets into one output packet, it 2493 MUST change the "sender's packet count" field. If it 2494 changes the timestamp frequency, it MUST change the "RTP 2495 timestamp" field in the SR packet. 2497 SR/RR reception report blocks: A translator forwards reception 2498 reports received from one cloud to the others. Note that 2499 these flow in the direction opposite to the data. The SSRC 2500 is left intact. If a translator combines several data 2501 packets into one output packet, and therefore changes the 2502 sequence numbers, it MUST make the inverse manipulation for 2503 the packet loss fields and the "extended last sequence 2504 number" field. This may be complex. In the extreme case, 2505 there may be no meaningful way to translate the reception 2506 reports, so the translator MAY pass on no reception report 2507 at all or a synthetic report based on its own reception. 2508 The general rule is to do what makes sense for a particular 2509 translation. 2511 A translator does not require an SSRC identifier of its 2512 own, but MAY choose to allocate one for the purpose of 2513 sending reports about what it has received. These would be 2514 sent to all the connected clouds, each corresponding to the 2515 translation of the data stream as sent to that cloud, since 2516 reception reports are normally multicast to all 2517 participants. 2519 SDES: Translators typically forward without change the SDES 2520 information they receive from one cloud to the others, but 2521 MAY, for example, decide to filter non-CNAME SDES 2522 information if bandwidth is limited. The CNAMEs MUST be 2523 forwarded to allow SSRC identifier collision detection to 2524 work. A translator that generates its own RR packets MUST 2525 send SDES CNAME information about itself to the same clouds 2526 that it sends those RR packets. 2528 BYE: Translators forward BYE packets unchanged. A translator 2529 that is about to cease forwarding packets SHOULD send a BYE 2530 packet to each connected cloud containing all the SSRC 2531 identifiers that were previously being forwarded to that 2532 cloud, including the translator's own SSRC identifier if it 2533 sent reports of its own. 2535 APP: Translators forward APP packets unchanged. 2537 7.3 RTCP Processing in Mixers 2539 Since a mixer generates a new data stream of its own, it does not 2540 pass through SR or RR packets at all and instead generates new 2541 information for both sides. 2543 SR sender information: A mixer does not pass through sender 2544 information from the sources it mixes because the 2545 characteristics of the source streams are lost in the mix. 2546 As a synchronization source, the mixer SHOULD generate its 2547 own SR packets with sender information about the mixed data 2548 stream and send them in the same direction as the mixed 2549 stream. 2551 SR/RR reception report blocks: A mixer generates its own 2552 reception reports for sources in each cloud and sends them 2553 out only to the same cloud. It MUST NOT send these 2554 reception reports to the other clouds and MUST NOT forward 2555 reception reports from one cloud to the others because the 2556 sources would not be SSRCs there (only CSRCs). 2558 SDES: Mixers typically forward without change the SDES 2559 information they receive from one cloud to the others, but 2560 MAY, for example, decide to filter non-CNAME SDES 2561 information if bandwidth is limited. The CNAMEs MUST be 2562 forwarded to allow SSRC identifier collision detection to 2563 work. (An identifier in a CSRC list generated by a mixer 2564 might collide with an SSRC identifier generated by an end 2565 system.) A mixer MUST send SDES CNAME information about 2566 itself to the same clouds that it sends SR or RR packets. 2568 Since mixers do not forward SR or RR packets, they will 2569 typically be extracting SDES packets from a compound RTCP 2570 packet. To minimize overhead, chunks from the SDES packets 2571 MAY be aggregated into a single SDES packet which is then 2572 stacked on an SR or RR packet originating from the mixer. 2573 A mixer which aggregates SDES packets will use more RTCP 2574 bandwidth than an individual source because the compound 2575 packets will be longer, but that is appropriate since the 2576 mixer represents multiple sources. Similarly, a mixer 2577 which passes through SDES packets as they are received will 2578 be transmitting RTCP packets at higher than the single 2579 source rate, but again that is correct since the packets 2580 come from multiple sources. The RTCP packet rate may be 2581 different on each side of the mixer. 2583 A mixer that does not insert CSRC identifiers MAY also 2584 refrain from forwarding SDES CNAMEs. In this case, the SSRC 2585 identifier spaces in the two clouds are independent. As 2586 mentioned earlier, this mode of operation creates a danger 2587 that loops can't be detected. 2589 BYE: Mixers MUST forward BYE packets. A mixer that is about to 2590 cease forwarding packets SHOULD send a BYE packet to each 2591 connected cloud containing all the SSRC identifiers that 2592 were previously being forwarded to that cloud, including 2593 the mixer's own SSRC identifier if it sent reports of its 2594 own. 2596 APP: The treatment of APP packets by mixers is application- 2597 specific. 2599 7.4 Cascaded Mixers 2601 An RTP session may involve a collection of mixers and translators as 2602 shown in Figure 3. If two mixers are cascaded, such as M2 and M3 in 2603 the figure, packets received by a mixer may already have been mixed 2604 and may include a CSRC list with multiple identifiers. The second 2605 mixer SHOULD build the CSRC list for the outgoing packet using the 2606 CSRC identifiers from already-mixed input packets and the SSRC 2607 identifiers from unmixed input packets. This is shown in the output 2608 arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case 2609 of mixers that are not cascaded, if the resulting CSRC list has more 2610 than 15 identifiers, the remainder cannot be included. 2612 8 SSRC Identifier Allocation and Use 2614 The SSRC identifier carried in the RTP header and in various fields 2615 of RTCP packets is a random 32-bit number that is required to be 2616 globally unique within an RTP session. It is crucial that the number 2617 be chosen with care in order that participants on the same network or 2618 starting at the same time are not likely to choose the same number. 2620 It is not sufficient to use the local network address (such as an 2621 IPv4 address) for the identifier because the address may not be 2622 unique. Since RTP translators and mixers enable interoperation among 2623 multiple networks with different address spaces, the allocation 2624 patterns for addresses within two spaces might result in a much 2625 higher rate of collision than would occur with random allocation. 2627 Multiple sources running on one host would also conflict. 2629 It is also not sufficient to obtain an SSRC identifier simply by 2630 calling random() without carefully initializing the state. An example 2631 of how to generate a random identifier is presented in Appendix A.6. 2633 8.1 Probability of Collision 2635 Since the identifiers are chosen randomly, it is possible that two or 2636 more sources will choose the same number. Collision occurs with the 2637 highest probability when all sources are started simultaneously, for 2638 example when triggered automatically by some session management 2639 event. If N is the number of sources and L the length of the 2640 identifier (here, 32 bits), the probability that two sources 2641 independently pick the same value can be approximated for large N 2642 [25] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is 2643 roughly 10**-4. 2645 The typical collision probability is much lower than the worst-case 2646 above. When one new source joins an RTP session in which all the 2647 other sources already have unique identifiers, the probability of 2648 collision is just the fraction of numbers used out of the space. 2649 Again, if N is the number of sources and L the length of the 2650 identifier, the probability of collision is N / 2**L. For N=1000, the 2651 probability is roughly 2*10**-7. 2653 The probability of collision is further reduced by the opportunity 2654 for a new source to receive packets from other participants before 2655 sending its first packet (either data or control). If the new source 2656 keeps track of the other participants (by SSRC identifier), then 2657 before transmitting its first packet the new source can verify that 2658 its identifier does not conflict with any that have been received, or 2659 else choose again. 2661 8.2 Collision Resolution and Loop Detection 2663 Although the probability of SSRC identifier collision is low, all RTP 2664 implementations MUST be prepared to detect collisions and take the 2665 appropriate actions to resolve them. If a source discovers at any 2666 time that another source is using the same SSRC identifier as its 2667 own, it MUST send an RTCP BYE packet for the old identifier and 2668 choose another random one. (As explained below, this step is taken 2669 only once in case of a loop.) If a receiver discovers that two other 2670 sources are colliding, it MAY keep the packets from one and discard 2671 the packets from the other when this can be detected by different 2672 source transport addresses or CNAMEs. The two sources are expected 2673 to resolve the collision so that the situation doesn't last. 2675 Because the random SSRC identifiers are kept globally unique for each 2676 RTP session, they can also be used to detect loops that may be 2677 introduced by mixers or translators. A loop causes duplication of 2678 data and control information, either unmodified or possibly mixed, as 2679 in the following examples: 2681 o A translator may incorrectly forward a packet to the same 2682 multicast group from which it has received the packet, either 2683 directly or through a chain of translators. In that case, the 2684 same packet appears several times, originating from different 2685 network sources. 2687 o Two translators incorrectly set up in parallel, i.e., with the 2688 same multicast groups on both sides, would both forward 2689 packets from one multicast group to the other. Unidirectional 2690 translators would produce two copies; bidirectional 2691 translators would form a loop. 2693 o A mixer can close a loop by sending to the same transport 2694 destination upon which it receives packets, either directly or 2695 through another mixer or translator. In this case a source 2696 might show up both as an SSRC on a data packet and a CSRC in a 2697 mixed data packet. 2699 A source may discover that its own packets are being looped, or that 2700 packets from another source are being looped (a third-party loop). 2702 Both loops and collisions in the random selection of a source 2703 identifier result in packets arriving with the same SSRC identifier 2704 but a different source transport address, which may be that of the 2705 end system originating the packet or an intermediate system. 2706 Therefore, if a source changes its source transport address, it MAY 2707 also choose a new SSRC identifier to avoid being interpreted as a 2708 looped source. (This is not MUST because in some applications of RTP 2709 sources may be expected to change addresses during a session.) Note 2710 that if a translator restarts and consequently changes the source 2711 transport address (e.g., changes the UDP source port number) on which 2712 it forwards packets, then all those packets will appear to receivers 2713 to be looped because the SSRC identifiers are applied by the original 2714 source and will not change. This problem can be avoided by keeping 2715 the source transport addressed fixed across restarts, but in any case 2716 will be resolved after a timeout at the receivers. 2718 Loops or collisions occurring on the far side of a translator or 2719 mixer cannot be detected using the source transport address if all 2720 copies of the packets go through the translator or mixer, however 2721 collisions may still be detected when chunks from two RTCP SDES 2722 packets contain the same SSRC identifier but different CNAMEs. 2724 To detect and resolve these conflicts, an RTP implementation MUST 2725 include an algorithm similar to the one described below, though the 2726 implementation MAY choose a different policy for which packets from 2727 colliding third-party sources are kept. The algorithm described below 2728 ignores packets from a new source or loop that collide with an 2729 established source. It resolves collisions with the participant's own 2730 SSRC identifier by sending an RTCP BYE for the old identifier and 2731 choosing a new one. However, when the collision was induced by a loop 2732 of the participant's own packets, the algorithm will choose a new 2733 identifier only once and thereafter ignore packets from the looping 2734 source transport address. This is required to avoid a flood of BYE 2735 packets. 2737 This algorithm requires keeping a table indexed by the source 2738 identifier and containing the source transport addresses from the 2739 first RTP packet and first RTCP packet received with that identifier, 2740 along with other state for that source. Two source transport 2741 addresses are required since, for example, the UDP source port 2742 numbers may be different on RTP and RTCP packets. However, it may be 2743 assumed that the network address is the same in both source transport 2744 addresses. 2746 Each SSRC or CSRC identifier received in an RTP or RTCP packet is 2747 looked up in the source identifier table in order to process that 2748 data or control information. The source transport address from the 2749 packet is compared to the corresponding source transport address in 2750 the table to detect a loop or collision if they don't match. For 2751 control packets, each element with its own SSRC id, for example an 2752 SDES chunk, requires a separate lookup. (The SSRC id in a reception 2753 report block is an exception because it identifies a source heard by 2754 the reporter, and that SSRC id is unrelated to the source transport 2755 adddress of the RTCP packet sent by the reporter.) If the SSRC or 2756 CSRC is not found, a new entry is created. These table entries are 2757 removed when an RTCP BYE packet is received with the corresponding 2758 SSRC id and validated by a matching source transport address, or 2759 after no packets have arrived for a relatively long time (see Section 2760 6.2.1). 2762 Note that if two sources on the same host are transmitting with the 2763 same source identifier at the time a receiver begins operation, it 2764 would be possible that the first RTP packet received came from one of 2765 the sources while the first RTCP packet received came from the other. 2766 This would cause the wrong RTCP information to be associated with the 2767 RTP data, but this situation should be sufficiently rare and harmless 2768 that it may be disregarded. 2770 In order to track loops of the participant's own data packets, the 2771 implementation MUST also keep a separate list of source transport 2772 addresses (not identifiers) that have been found to be conflicting. 2773 As in the source identifier table, two source transport addresses 2774 MUST be kept to separately track conflicting RTP and RTCP packets. 2775 Note that the conflicting address list should be short, usually 2776 empty. Each element in this list stores the source addresses plus 2777 the time when the most recent conflicting packet was received. An 2778 element MAY be removed from the list when no conflicting packet has 2779 arrived from that source for a time on the order of 10 RTCP report 2780 intervals (see Section 6.2). 2782 For the algorithm as shown, it is assumed that the participant's own 2783 source identifier and state are included in the source identifier 2784 table. The algorithm could be restructured to first make a separate 2785 comparison against the participant's own source identifier. 2787 if (SSRC or CSRC identifier is not found in the source 2788 identifier table) { 2789 create a new entry storing the data or control source 2790 transport address, the SSRC or CSRC id and other state; 2791 } 2793 /* Identifier is found in the table */ 2795 else if (table entry was created on receipt of a control packet 2796 and this is the first data packet or vice versa) { 2797 store the source transport address from this packet; 2798 } 2799 else if (source transport address from the packet does not match 2800 the one saved in the table entry for this identifier) { 2802 /* An identifier collision or a loop is indicated */ 2804 if (source identifier is not the participant's own) { 2805 /* OPTIONAL error counter step */ 2806 if (source identifier is from an RTCP SDES chunk 2807 containing a CNAME item that differs from the CNAME 2808 in the table entry) { 2809 count a third-party collision; 2810 } else { 2811 count a third-party loop; 2812 } 2813 abort processing of data packet or control element; 2814 /* MAY choose a different policy to keep new source */ 2815 } 2817 /* A collision or loop of the participant's own packets */ 2819 else if (source transport address is found in the list of 2820 conflicting data or control source transport 2821 addresses) { 2822 /* OPTIONAL error counter step */ 2823 if (source identifier is not from an RTCP SDES chunk 2824 containing a CNAME item or CNAME is the 2825 participant's own) { 2826 count occurrence of own traffic looped; 2827 } 2828 mark current time in conflicting address list entry; 2829 abort processing of data packet or control element; 2830 } 2832 /* New collision, change SSRC identifier */ 2834 else { 2835 log occurrence of a collision; 2836 create a new entry in the conflicting data or control 2837 source transport address list and mark current time; 2838 send an RTCP BYE packet with the old SSRC identifier; 2839 choose a new SSRC identifier; 2840 create a new entry in the source identifier table with 2841 the old SSRC plus the source transport address from 2842 the data or control packet being processed; 2843 } 2844 } 2846 In this algorithm, packets from a newly conflicting source address 2847 will be ignored and packets from the original source address will be 2848 kept. If no packets arrive from the original source for an extended 2849 period, the table entry will be timed out and the new source will be 2850 able to take over. This might occur if the original source detects 2851 the collision and moves to a new source identifier, but in the usual 2852 case an RTCP BYE packet will be received from the original source to 2853 delete the state without having to wait for a timeout. 2855 If the original source address was through a mixer (i.e., learned as 2856 a CSRC) and later the same source is received directly, the receiver 2857 may be well advised to switch to the new source address unless other 2858 sources in the mix would be lost. Furthermore, for applications such 2859 as telephony in which some sources such as mobile entities may change 2860 addresses during the course of an RTP session, the RTP implementation 2861 SHOULD modify the collision detection algorithm to accept packets 2862 from the new source transport address. To guard against flip-flopping 2863 between addresses if a genuine collision does occur, the algorithm 2864 SHOULD include some means to detect this case and avoid switching. 2866 When a new SSRC identifier is chosen due to a collision, the 2867 candidate identifier SHOULD first be looked up in the source 2868 identifier table to see if it was already in use by some other 2869 source. If so, another candidate MUST be generated and the process 2870 repeated. 2872 A loop of data packets to a multicast destination can cause severe 2873 network flooding. All mixers and translators MUST implement a loop 2874 detection algorithm like the one here so that they can break loops. 2875 This should limit the excess traffic to no more than one duplicate 2876 copy of the original traffic, which may allow the session to continue 2877 so that the cause of the loop can be found and fixed. However, in 2878 extreme cases where a mixer or translator does not properly break the 2879 loop and high traffic levels result, it may be necessary for end 2880 systems to cease transmitting data or control packets entirely. This 2881 decision may depend upon the application. An error condition SHOULD 2882 be indicated as appropriate. Transmission MAY be attempted again 2883 periodically after a long, random time (on the order of minutes). 2885 8.3 Use with Layered Encodings 2887 For layered encodings transmitted on separate RTP sessions (see 2888 Section 2.4), a single SSRC identifier space SHOULD be used across 2889 the sessions of all layers and the core (base) layer SHOULD be used 2890 for SSRC identifier allocation and collision resolution. When a 2891 source discovers that it has collided, it transmits an RTCP BYE 2892 packet on only the base layer but changes the SSRC identifier to the 2893 new value in all layers. 2895 9 Security 2897 Lower layer protocols may eventually provide all the security 2898 services that may be desired for applications of RTP, including 2899 authentication, integrity, and confidentiality. These services have 2900 been specified for IP in [26]. Since the initial audio and video 2901 applications using RTP needed a confidentiality service before such 2902 services were available for the IP layer, the confidentiality service 2903 described in the next section was defined for use with RTP and RTCP. 2904 That description is included here to codify existing practice. New 2905 applications of RTP MAY implement this RTP-specific confidentiality 2906 service for backward compatibility, and/or they MAY implement IP 2907 layer security services. The overhead on the RTP protocol for this 2908 confidentiality service is low, so the penalty will be minimal if 2909 this service is obsoleted by lower layer services in the future. 2911 Alternatively, other services, other implementations of services and 2912 other algorithms may be defined for RTP in the future if warranted. 2913 The selection presented here is meant to simplify implementation of 2914 interoperable, secure applications and provide guidance to 2915 implementors. No claim is made that the methods presented here are 2916 appropriate for a particular security need. A profile may specify 2917 which services and algorithms should be offered by applications, and 2918 may provide guidance as to their appropriate use. 2920 Key distribution and certificates are outside the scope of this 2921 document. 2923 9.1 Confidentiality 2925 Confidentiality means that only the intended receiver(s) can decode 2926 the received packets; for others, the packet contains no useful 2927 information. Confidentiality of the content is achieved by 2928 encryption. 2930 When encryption of RTP or RTCP is desired, all the octets that will 2931 be encapsulated for transmission in a single lower-layer packet are 2932 encrypted as a unit. For RTCP, a 32-bit random number MUST be 2933 prepended to the unit before encryption to deter known plaintext 2934 attacks. For RTP, no prefix is required because the sequence number 2935 and timestamp fields are initialized with random offsets. 2937 For RTCP, an implementation MAY segregate the individual RTCP packets 2938 in a compound RTCP packet into two separate compound RTCP packets, 2939 one to be encrypted and one to be sent in the clear. For example, 2940 SDES information might be encrypted while reception reports were sent 2941 in the clear to accommodate third-party monitors that are not privy 2942 to the encryption key. In this example, depicted in Fig. 4, the SDES 2943 information MUST be appended to an RR packet with no reports (and the 2944 random number) to satisfy the requirement that all compound RTCP 2945 packets begin with an SR or RR packet. The SDES CNAME item is 2946 required in either the encrypted or unencrypted packet, but not both. 2947 The same SDES information SHOULD NOT be carried in both packets as 2948 this may compromise the encryption. 2950 UDP packet UDP packet 2951 ----------------------------- ------------------------------ 2952 [random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2] 2953 ----------------------------- ------------------------------ 2954 encrypted not encrypted 2956 #: SSRC identifier 2958 Figure 4: Encrypted and non-encrypted RTCP packets 2960 The presence of encryption and the use of the correct key are 2961 confirmed by the receiver through header or payload validity checks. 2962 Examples of such validity checks for RTP and RTCP headers are given 2963 in Appendices A.1 and A.2. 2965 To be consistent with existing practice, the default encryption 2966 algorithm is the Data Encryption Standard (DES) algorithm in cipher 2967 block chaining (CBC) mode, as described in Section 1.1 of RFC 1423 2968 [27], except that padding to a multiple of 8 octets is indicated as 2969 described for the P bit in Section 5.1. The initialization vector is 2970 zero because random values are supplied in the RTP header or by the 2971 random prefix for compound RTCP packets. For details on the use of 2972 CBC initialization vectors, see [28]. Implementations that support 2973 encryption SHOULD always support the DES algorithm in CBC mode as the 2974 default to maximize interoperability. This method was chosen because 2975 it has been demonstrated to be easy and practical to use in 2976 experimental audio and video tools in operation on the Internet. 2977 Other encryption algorithms MAY be specified dynamically for a 2978 session by non-RTP means. It is RECOMMENDED that stronger encryption 2979 algorithms such as Triple-DES be used in place of the default 2980 algorithm. 2982 As an alternative to encryption at the IP level or at the RTP level 2983 as described above, profiles MAY define additional payload types for 2984 encrypted encodings. Those encodings MUST specify how padding and 2985 other aspects of the encryption are to be handled. This method allows 2986 encrypting only the data while leaving the headers in the clear for 2987 applications where that is desired. It may be particularly useful for 2988 hardware devices that will handle both decryption and decoding. It 2989 is also valuable for applications where link-level compression of RTP 2990 and lower-layer headers is desired and confidentiality of the payload 2991 (but not addresses) is sufficient since encryption of the headers 2992 precludes compression. 2994 9.2 Authentication and Message Integrity 2996 Authentication and message integrity services are not defined at the 2997 RTP level since these services would not be directly feasible without 2998 a key management infrastructure. It is expected that authentication 2999 and integrity services will be provided by lower layer protocols. 3001 10 Congestion Control 3003 All transport protocols used on the Internet need to address 3004 congestion control in some way [29]. RTP is not an exception, but 3005 because the data transported over RTP is often inelastic (generated 3006 at a fixed or controlled rate), the means to control congestion in 3007 RTP may be quite different from those for other transport protocols 3008 such as TCP. In one sense, inelasticity reduces the risk of 3009 congestion because the RTP stream will not expand to consume all 3010 available bandwidth as a TCP stream can. However, inelasticity also 3011 means that the RTP stream cannot arbitrarily reduce its load on the 3012 network to eliminate congestion when it occurs. 3014 Since RTP may be used for a wide variety of applications in many 3015 different contexts, there is no single congestion control mechanism 3016 that will work for all. Therefore, congestion control SHOULD be 3017 defined in each RTP profile as appropriate. For some profiles, it may 3018 be sufficient to include an applicability statement restricting the 3019 use of that profile to environments where congestion is avoided by 3020 engineering. For other profiles, specific methods such as data rate 3021 adaptation based on RTCP feedback may be required. 3023 11 RTP over Network and Transport Protocols 3025 This section describes issues specific to carrying RTP packets within 3026 particular network and transport protocols. The following rules apply 3027 unless superseded by protocol-specific definitions outside this 3028 specification. 3030 RTP relies on the underlying protocol(s) to provide demultiplexing of 3031 RTP data and RTCP control streams. For UDP and similar protocols, RTP 3032 SHOULD use an even destination port number and the corresponding RTCP 3033 stream SHOULD use the next higher (odd) destination port number. If 3034 an application is supplied with an odd number for use as the 3035 destination RTP port, it SHOULD replace this number with the next 3036 lower (even) number. 3038 In a unicast session, both participants need to identify a port pair 3039 for receiving RTP and RTCP packets. Both participants MAY use the 3040 same port pair. A participant MUST NOT assume that the source port of 3041 the incoming RTP or RTCP packet can be used as the destination port 3042 for outgoing RTP or RTCP packets. When RTP data packets are being 3043 sent in both directions, each participant MUST send RTCP SR packets 3044 to the port that the other participant has specified for reception of 3045 RTCP. The RTCP SR packets combine sender information for the outgoing 3046 data plus reception report information for the incoming data. If a 3047 side is not actively sending data (see Section 6.4), an RTCP RR 3048 packet is sent instead. 3050 It is RECOMMENDED that layered encoding applications (see Section 3051 2.4) use a set of contiguous port numbers. The port numbers MUST be 3052 distinct because of a widespread deficiency in existing operating 3053 systems that prevents use of the same port with multiple multicast 3054 addresses, and for unicast, there is only one permissible address. 3055 Thus for layer n, the data port is P + 2n, and the control port is P 3056 + 2n + 1. When IP multicast is used, the addresses MUST also be 3057 distinct because multicast routing and group membership are managed 3058 on an address granularity. However, allocation of contiguous IP 3059 multicast addresses cannot be assumed because some groups may require 3060 different scopes and may therefore be allocated from different 3061 address ranges. 3063 The previous paragraph conflicts with the SDP specification, RFC 2327 3064 [8], which says that it is illegal for both multiple addresses and 3065 multiple ports to be specified in the same session description 3066 because the association of addresses with ports could be ambiguous. 3067 It is intended that this restriction will be relaxed in a revision of 3068 RFC 2327 to allow an equal number of addresses and ports to be 3069 specified with a one-to-one mapping implied. 3071 RTP data packets contain no length field or other delineation, 3072 therefore RTP relies on the underlying protocol(s) to provide a 3073 length indication. The maximum length of RTP packets is limited only 3074 by the underlying protocols. 3076 If RTP packets are to be carried in an underlying protocol that 3077 provides the abstraction of a continuous octet stream rather than 3078 messages (packets), an encapsulation of the RTP packets MUST be 3079 defined to provide a framing mechanism. Framing is also needed if the 3080 underlying protocol may contain padding so that the extent of the RTP 3081 payload cannot be determined. The framing mechanism is not defined 3082 here. 3084 A profile MAY specify a framing method to be used even when RTP is 3085 carried in protocols that do provide framing in order to allow 3086 carrying several RTP packets in one lower-layer protocol data unit, 3087 such as a UDP packet. Carrying several RTP packets in one network or 3088 transport packet reduces header overhead and may simplify 3089 synchronization between different streams. 3091 12 Summary of Protocol Constants 3093 This section contains a summary listing of the constants defined in 3094 this specification. 3096 The RTP payload type (PT) constants are defined in profiles rather 3097 than this document. However, the octet of the RTP header which 3098 contains the marker bit(s) and payload type MUST avoid the reserved 3099 values 200 and 201 (decimal) to distinguish RTP packets from the RTCP 3100 SR and RR packet types for the header validation procedure described 3101 in Appendix A.1. For the standard definition of one marker bit and a 3102 7-bit payload type field as shown in this specification, this 3103 restriction means that payload types 72 and 73 are reserved. 3105 12.1 RTCP packet types 3107 abbrev. name value 3108 SR sender report 200 3109 RR receiver report 201 3110 SDES source description 202 3111 BYE goodbye 203 3112 APP application-defined 204 3114 These type values were chosen in the range 200-204 for improved 3115 header validity checking of RTCP packets compared to RTP packets or 3116 other unrelated packets. When the RTCP packet type field is compared 3117 to the corresponding octet of the RTP header, this range corresponds 3118 to the marker bit being 1 (which it usually is not in data packets) 3119 and to the high bit of the standard payload type field being 1 (since 3120 the static payload types are typically defined in the low half). This 3121 range was also chosen to be some distance numerically from 0 and 255 3122 since all-zeros and all-ones are common data patterns. 3124 Since all compound RTCP packets MUST begin with SR or RR, these codes 3125 were chosen as an even/odd pair to allow the RTCP validity check to 3126 test the maximum number of bits with mask and value. 3128 Additional RTCP packet types may be registered through IANA (see 3129 Section 14). 3131 12.2 SDES types 3132 abbrev. name value 3133 END end of SDES list 0 3134 CNAME canonical name 1 3135 NAME user name 2 3136 EMAIL user's electronic mail address 3 3137 PHONE user's phone number 4 3138 LOC geographic user location 5 3139 TOOL name of application or tool 6 3140 NOTE notice about the source 7 3141 PRIV private extensions 8 3143 Additional SDES types may be registered through IANA (see Section 3144 14). 3146 13 RTP Profiles and Payload Format Specifications 3148 A complete specification of RTP for a particular application will 3149 require one or more companion documents of two types described here: 3150 profiles, and payload format specifications. 3152 RTP may be used for a variety of applications with somewhat differing 3153 requirements. The flexibility to adapt to those requirements is 3154 provided by allowing multiple choices in the main protocol 3155 specification, then selecting the appropriate choices or defining 3156 extensions for a particular environment and class of applications in 3157 a separate profile document. Typically an application will operate 3158 under only one profile in a particular RTP session, so there is no 3159 explicit indication within the RTP protocol itself as to which 3160 profile is in use. A profile for audio and video applications may be 3161 found in the companion RFC 1890 (updated by Internet-Draft draft- 3162 ietf-avt-profile-new ). Profiles are typically titled "RTP Profile 3163 for ...". 3165 The second type of companion document is a payload format 3166 specification, which defines how a particular kind of payload data, 3167 such as H.261 encoded video, should be carried in RTP. These 3168 documents are typically titled "RTP Payload Format for XYZ 3169 Audio/Video Encoding". Payload formats may be useful under multiple 3170 profiles and may therefore be defined independently of any particular 3171 profile. The profile documents are then responsible for assigning a 3172 default mapping of that format to a payload type value if needed. 3174 Within this specification, the following items have been identified 3175 for possible definition within a profile, but this list is not meant 3176 to be exhaustive: 3178 RTP data header: The octet in the RTP data header that contains 3179 the marker bit and payload type field MAY be redefined by a 3180 profile to suit different requirements, for example with 3181 more or fewer marker bits (Section 5.3, p. 15). 3183 Payload types: Assuming that a payload type field is included, 3184 the profile will usually define a set of payload formats 3185 (e.g., media encodings) and a default static mapping of 3186 those formats to payload type values. Some of the payload 3187 formats may be defined by reference to separate payload 3188 format specifications. For each payload type defined, the 3189 profile MUST specify the RTP timestamp clock rate to be 3190 used (Section 5.1, p. 13). 3192 RTP data header additions: Additional fields MAY be appended to 3193 the fixed RTP data header if some additional functionality 3194 is required across the profile's class of applications 3195 independent of payload type (Section 5.3, p. 15). 3197 RTP data header extensions: The contents of the first 16 bits of 3198 the RTP data header extension structure MUST be defined if 3199 use of that mechanism is to be allowed under the profile 3200 for implementation-specific extensions (Section 5.3.1, p. 3201 15). 3203 RTCP packet types: New application-class-specific RTCP packet 3204 types MAY be defined and registered with IANA. 3206 RTCP report interval: A profile SHOULD specify that the values 3207 suggested in Section 6.2 for the constants employed in the 3208 calculation of the RTCP report interval will be used. Those 3209 are the RTCP fraction of session bandwidth, the minimum 3210 report interval, and the bandwidth split between senders 3211 and receivers. A profile MAY specify alternate values if 3212 they have been demonstrated to work in a scalable manner. 3214 SR/RR extension: An extension section MAY be defined for the 3215 RTCP SR and RR packets if there is additional information 3216 that should be reported regularly about the sender or 3217 receivers (Section 6.4.3, p. 33). 3219 SDES use: The profile MAY specify the relative priorities for 3220 RTCP SDES items to be transmitted or excluded entirely 3221 (Section 6.3.9); an alternate syntax or semantics for the 3222 CNAME item (Section 6.5.1); the format of the LOC item 3223 (Section 6.5.5); the semantics and use of the NOTE item 3224 (Section 6.5.7); or new SDES item types to be registered 3225 with IANA. 3227 Security: A profile MAY specify which security services and 3228 algorithms should be offered by applications, and MAY 3229 provide guidance as to their appropriate use (Section 9, p. 3230 50). 3232 String-to-key mapping: A profile MAY specify how a user-provided 3233 password or pass phrase is mapped into an encryption key. 3235 Congestion: A profile SHOULD specify the congestion control 3236 behavior appropriate for that profile. 3238 Underlying protocol: Use of a particular underlying network or 3239 transport layer protocol to carry RTP packets MAY be 3240 required. 3242 Transport mapping: A mapping of RTP and RTCP to transport-level 3243 addresses, e.g., UDP ports, other than the standard mapping 3244 defined in Section 11, p. 53 may be specified. 3246 Encapsulation: An encapsulation of RTP packets may be defined to 3247 allow multiple RTP data packets to be carried in one 3248 lower-layer packet or to provide framing over underlying 3249 protocols that do not already do so (Section 11, p. 53). 3251 It is not expected that a new profile will be required for every 3252 application. Within one application class, it would be better to 3253 extend an existing profile rather than make a new one in order to 3254 facilitate interoperation among the applications since each will 3255 typically run under only one profile. Simple extensions such as the 3256 definition of additional payload type values or RTCP packet types may 3257 be accomplished by registering them through IANA and publishing their 3258 descriptions in an addendum to the profile or in a payload format 3259 specification. 3261 14 IANA Considerations 3263 Additional RTCP packet types and SDES item types may be registered 3264 through the Internet Assigned Numbers Authority (IANA). Since these 3265 number spaces are small, allowing unconstrained registration of new 3266 values would not be prudent. To facilitate review of requests and to 3267 promote shared use of new types among multiple applications, requests 3268 for registration of new values must be documented in an RFC or other 3269 permanent and readily available reference such as the product of 3270 another cooperative standards body (e.g., ITU-T). Other requests may 3271 also be accepted, under the advice of a "designated expert." (Contact 3272 the IANA for the contact information of the current expert.) 3274 RTP profile specifications SHOULD register with IANA a name for the 3275 profile in the form "RTP/xxx", where xxx is a short abbreviation of 3276 the profile title. These names are for use by higher-level control 3277 protocols, such as the Session Description Protocol (SDP), RFC 2327 3278 [8], to refer to transport methods. 3280 A Algorithms 3282 We provide examples of C code for aspects of RTP sender and receiver 3283 algorithms. There may be other implementation methods that are faster 3284 in particular operating environments or have other advantages. These 3285 implementation notes are for informational purposes only and are 3286 meant to clarify the RTP specification. 3288 The following definitions are used for all examples; for clarity and 3289 brevity, the structure definitions are only valid for 32-bit big- 3290 endian (most significant octet first) architectures. Bit fields are 3291 assumed to be packed tightly in big-endian bit order, with no 3292 additional padding. Modifications would be required to construct a 3293 portable implementation. 3295 /* 3296 * rtp.h -- RTP header file 3297 */ 3298 #include 3300 /* 3301 * The type definitions below are valid for 32-bit architectures and 3302 * may have to be adjusted for 16- or 64-bit architectures. 3303 */ 3304 typedef unsigned char u_int8; 3305 typedef unsigned short u_int16; 3306 typedef unsigned int u_int32; 3307 typedef short int16; 3309 /* 3310 * Current protocol version. 3311 */ 3312 #define RTP_VERSION 2 3314 #define RTP_SEQ_MOD (1<<16) 3315 #define RTP_MAX_SDES 255 /* maximum text length for SDES */ 3317 typedef enum { 3318 RTCP_SR = 200, 3319 RTCP_RR = 201, 3320 RTCP_SDES = 202, 3321 RTCP_BYE = 203, 3322 RTCP_APP = 204 3323 } rtcp_type_t; 3325 typedef enum { 3326 RTCP_SDES_END = 0, 3327 RTCP_SDES_CNAME = 1, 3328 RTCP_SDES_NAME = 2, 3329 RTCP_SDES_EMAIL = 3, 3330 RTCP_SDES_PHONE = 4, 3331 RTCP_SDES_LOC = 5, 3332 RTCP_SDES_TOOL = 6, 3333 RTCP_SDES_NOTE = 7, 3334 RTCP_SDES_PRIV = 8 3335 } rtcp_sdes_type_t; 3337 /* 3338 * RTP data header 3339 */ 3340 typedef struct { 3341 unsigned int version:2; /* protocol version */ 3342 unsigned int p:1; /* padding flag */ 3343 unsigned int x:1; /* header extension flag */ 3344 unsigned int cc:4; /* CSRC count */ 3345 unsigned int m:1; /* marker bit */ 3346 unsigned int pt:7; /* payload type */ 3347 unsigned int seq:16; /* sequence number */ 3348 u_int32 ts; /* timestamp */ 3349 u_int32 ssrc; /* synchronization source */ 3350 u_int32 csrc[1]; /* optional CSRC list */ 3351 } rtp_hdr_t; 3353 /* 3354 * RTCP common header word 3355 */ 3356 typedef struct { 3357 unsigned int version:2; /* protocol version */ 3358 unsigned int p:1; /* padding flag */ 3359 unsigned int count:5; /* varies by packet type */ 3360 unsigned int pt:8; /* RTCP packet type */ 3361 u_int16 length; /* pkt len in words, w/o this word */ 3362 } rtcp_common_t; 3364 /* 3365 * Big-endian mask for version, padding bit and packet type pair 3366 */ 3367 #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe) 3368 #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR) 3370 /* 3371 * Reception report block 3372 */ 3373 typedef struct { 3374 u_int32 ssrc; /* data source being reported */ 3375 unsigned int fraction:8; /* fraction lost since last SR/RR */ 3376 int lost:24; /* cumul. no. pkts lost (signed!) */ 3377 u_int32 last_seq; /* extended last seq. no. received */ 3378 u_int32 jitter; /* interarrival jitter */ 3379 u_int32 lsr; /* last SR packet from this source */ 3380 u_int32 dlsr; /* delay since last SR packet */ 3381 } rtcp_rr_t; 3383 /* 3384 * SDES item 3385 */ 3386 typedef struct { 3387 u_int8 type; /* type of item (rtcp_sdes_type_t) */ 3388 u_int8 length; /* length of item (in octets) */ 3389 char data[1]; /* text, not null-terminated */ 3391 } rtcp_sdes_item_t; 3393 /* 3394 * One RTCP packet 3395 */ 3396 typedef struct { 3397 rtcp_common_t common; /* common header */ 3398 union { 3399 /* sender report (SR) */ 3400 struct { 3401 u_int32 ssrc; /* sender generating this report */ 3402 u_int32 ntp_sec; /* NTP timestamp */ 3403 u_int32 ntp_frac; 3404 u_int32 rtp_ts; /* RTP timestamp */ 3405 u_int32 psent; /* packets sent */ 3406 u_int32 osent; /* octets sent */ 3407 rtcp_rr_t rr[1]; /* variable-length list */ 3408 } sr; 3410 /* reception report (RR) */ 3411 struct { 3412 u_int32 ssrc; /* receiver generating this report */ 3413 rtcp_rr_t rr[1]; /* variable-length list */ 3414 } rr; 3416 /* source description (SDES) */ 3417 struct rtcp_sdes { 3418 u_int32 src; /* first SSRC/CSRC */ 3419 rtcp_sdes_item_t item[1]; /* list of SDES items */ 3420 } sdes; 3422 /* BYE */ 3423 struct { 3424 u_int32 src[1]; /* list of sources */ 3425 /* can't express trailing text for reason */ 3426 } bye; 3427 } r; 3428 } rtcp_t; 3430 typedef struct rtcp_sdes rtcp_sdes_t; 3431 /* 3432 * Per-source state information 3433 */ 3434 typedef struct { 3435 u_int16 max_seq; /* highest seq. number seen */ 3436 u_int32 cycles; /* shifted count of seq. number cycles */ 3437 u_int32 base_seq; /* base seq number */ 3438 u_int32 bad_seq; /* last 'bad' seq number + 1 */ 3439 u_int32 probation; /* sequ. packets till source is valid */ 3440 u_int32 received; /* packets received */ 3441 u_int32 expected_prior; /* packet expected at last interval */ 3442 u_int32 received_prior; /* packet received at last interval */ 3443 u_int32 transit; /* relative trans time for prev pkt */ 3444 u_int32 jitter; /* estimated jitter */ 3445 /* ... */ 3446 } source; 3448 A.1 RTP Data Header Validity Checks 3450 An RTP receiver SHOULD check the validity of the RTP header on 3451 incoming packets since they might be encrypted or might be from a 3452 different application that happens to be misaddressed. Similarly, if 3453 encryption according to the method described in Section 9 is enabled, 3454 the header validity check is needed to verify that incoming packets 3455 have been correctly decrypted, although a failure of the header 3456 validity check (e.g., unknown payload type) may not necessarily 3457 indicate decryption failure. 3459 Only weak validity checks are possible on an RTP data packet from a 3460 source that has not been heard before: 3462 o RTP version field must equal 2. 3464 o The payload type must be known, in particular it must not be 3465 equal to SR or RR. 3467 o If the P bit is set, then the last octet of the packet must 3468 contain a valid octet count, in particular, less than the 3469 total packet length minus the header size. 3471 o The X bit must be zero if the profile does not specify that 3472 the header extension mechanism may be used. Otherwise, the 3473 extension length field must be less than the total packet size 3474 minus the fixed header length and padding. 3476 o The length of the packet must be consistent with CC and 3477 payload type (if payloads have a known length). 3479 The last three checks are somewhat complex and not always possible, 3480 leaving only the first two which total just a few bits. If the SSRC 3481 identifier in the packet is one that has been received before, then 3482 the packet is probably valid and checking if the sequence number is 3483 in the expected range provides further validation. If the SSRC 3484 identifier has not been seen before, then data packets carrying that 3485 identifier may be considered invalid until a small number of them 3486 arrive with consecutive sequence numbers. Those invalid packets MAY 3487 be discarded or they MAY be stored and delivered once validation has 3488 been achieved if the resulting delay is acceptable. 3490 The routine update_seq shown below ensures that a source is declared 3491 valid only after MIN_SEQUENTIAL packets have been received in 3492 sequence. It also validates the sequence number seq of a newly 3493 received packet and updates the sequence state for the packet's 3494 source in the structure to which s points. 3496 When a new source is heard for the first time, that is, its SSRC 3497 identifier is not in the table (see Section 8.2), and the per-source 3498 state is allocated for it, s->probation should be set to the number 3499 of sequential packets required before declaring a source valid 3500 (parameter MIN_SEQUENTIAL ) and s->max_seq initialized to seq-1 s- 3501 >probation marks the source as not yet valid so the state may be 3502 discarded after a short timeout rather than a long one, as discussed 3503 in Section 6.2.1. 3505 After a source is considered valid, the sequence number is considered 3506 valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more 3507 than MAX_MISORDER behind. If the new sequence number is ahead of 3508 max_seq modulo the RTP sequence number range (16 bits), but is 3509 smaller than max_seq , it has wrapped around and the (shifted) count 3510 of sequence number cycles is incremented. A value of one is returned 3511 to indicate a valid sequence number. 3513 Otherwise, the value zero is returned to indicate that the validation 3514 failed, and the bad sequence number is stored. If the next packet 3515 received carries the next higher sequence number, it is considered 3516 the valid start of a new packet sequence presumably caused by an 3517 extended dropout or a source restart. Since multiple complete 3518 sequence number cycles may have been missed, the packet loss 3519 statistics are reset. 3521 Typical values for the parameters are shown, based on a maximum 3522 misordering time of 2 seconds at 50 packets/second and a maximum 3523 dropout of 1 minute. The dropout parameter MAX_DROPOUT SHOULD be a 3524 small fraction of the 16-bit sequence number space to give a 3525 reasonable probability that new sequence numbers after a restart will 3526 not fall in the acceptable range for sequence numbers from before the 3527 restart. 3529 void init_seq(source *s, u_int16 seq) 3530 { 3531 s->base_seq = seq - 1; 3532 s->max_seq = seq; 3533 s->bad_seq = RTP_SEQ_MOD + 1; 3534 s->cycles = 0; 3535 s->received = 0; 3536 s->received_prior = 0; 3537 s->expected_prior = 0; 3538 /* other initialization */ 3539 } 3541 int update_seq(source *s, u_int16 seq) 3542 { 3543 u_int16 udelta = seq - s->max_seq; 3544 const int MAX_DROPOUT = 3000; 3545 const int MAX_MISORDER = 100; 3546 const int MIN_SEQUENTIAL = 2; 3548 /* 3549 * Source is not valid until MIN_SEQUENTIAL packets with 3550 * sequential sequence numbers have been received. 3551 */ 3552 if (s->probation) { 3553 /* packet is in sequence */ 3554 if (seq == s->max_seq + 1) { 3555 s->probation--; 3556 s->max_seq = seq; 3557 if (s->probation == 0) { 3558 init_seq(s, seq); 3559 s->received++; 3560 return 1; 3561 } 3562 } else { 3563 s->probation = MIN_SEQUENTIAL - 1; 3564 s->max_seq = seq; 3565 } 3566 return 0; 3567 } else if (udelta < MAX_DROPOUT) { 3568 /* in order, with permissible gap */ 3569 if (seq < s->max_seq) { 3570 /* 3571 * Sequence number wrapped - count another 64K cycle. 3572 */ 3573 s->cycles += RTP_SEQ_MOD; 3574 } 3575 s->max_seq = seq; 3577 } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) { 3578 /* the sequence number made a very large jump */ 3579 if (seq == s->bad_seq) { 3580 /* 3581 * Two sequential packets -- assume that the other side 3582 * restarted without telling us so just re-sync 3583 * (i.e., pretend this was the first packet). 3584 */ 3585 init_seq(s, seq); 3586 } 3587 else { 3588 s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1); 3589 return 0; 3590 } 3591 } else { 3592 /* duplicate or reordered packet */ 3593 } 3594 s->received++; 3595 return 1; 3596 } 3598 The validity check can be made stronger requiring more than two 3599 packets in sequence. The disadvantages are that a larger number of 3600 initial packets will be discarded (or delayed in a queue) and that 3601 high packet loss rates could prevent validation. However, because the 3602 RTCP header validation is relatively strong, if an RTCP packet is 3603 received from a source before the data packets, the count could be 3604 adjusted so that only two packets are required in sequence. If 3605 initial data loss for a few seconds can be tolerated, an application 3606 MAY choose to discard all data packets from a source until a valid 3607 RTCP packet has been received from that source. 3609 Depending on the application and encoding, algorithms may exploit 3610 additional knowledge about the payload format for further validation. 3611 For payload types where the timestamp increment is the same for all 3612 packets, the timestamp values can be predicted from the previous 3613 packet received from the same source using the sequence number 3614 difference (assuming no change in payload type). 3616 A strong "fast-path" check is possible since with high probability 3617 the first four octets in the header of a newly received RTP data 3618 packet will be just the same as that of the previous packet from the 3619 same SSRC except that the sequence number will have increased by one. 3620 Similarly, a single-entry cache may be used for faster SSRC lookups 3621 in applications where data is typically received from one source at a 3622 time. 3624 A.2 RTCP Header Validity Checks 3626 The following checks SHOULD be applied to RTCP packets. 3628 o RTP version field must equal 2. 3630 o The payload type field of the first RTCP packet in a compound 3631 packet must be equal to SR or RR. 3633 o The padding bit (P) should be zero for the first packet of a 3634 compound RTCP packet because padding should only be applied, 3635 if it is needed, to the last packet. 3637 o The length fields of the individual RTCP packets must total to 3638 the overall length of the compound RTCP packet as received. 3639 This is a fairly strong check. 3641 The code fragment below performs all of these checks. The packet type 3642 is not checked for subsequent packets since unknown packet types may 3643 be present and should be ignored. 3645 u_int32 len; /* length of compound RTCP packet in words */ 3646 rtcp_t *r; /* RTCP header */ 3647 rtcp_t *end; /* end of compound RTCP packet */ 3649 if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) { 3650 /* something wrong with packet format */ 3651 } 3652 end = (rtcp_t *)((u_int32 *)r + len); 3654 do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1); 3655 while (r < end && r->common.version == 2); 3657 if (r != end) { 3658 /* something wrong with packet format */ 3659 } 3661 A.3 Determining the Number of RTP Packets Expected and Lost 3663 In order to compute packet loss rates, the number of packets expected 3664 and actually received from each source needs to be known, using per- 3665 source state information defined in struct source referenced via 3666 pointer s in the code below. The number of packets received is simply 3667 the count of packets as they arrive, including any late or duplicate 3668 packets. The number of packets expected can be computed by the 3669 receiver as the difference between the highest sequence number 3670 received ( s->max_seq ) and the first sequence number received ( s- 3671 >base_seq ). Since the sequence number is only 16 bits and will wrap 3672 around, it is necessary to extend the highest sequence number with 3673 the (shifted) count of sequence number wraparounds ( s->cycles ). 3674 Both the received packet count and the count of cycles are maintained 3675 the RTP header validity check routine in Appendix A.1. 3677 extended_max = s->cycles + s->max_seq; 3678 expected = extended_max - s->base_seq + 1; 3680 The number of packets lost is defined to be the number of packets 3681 expected less the number of packets actually received: 3683 lost = expected - s->received; 3685 Since this signed number is carried in 24 bits, it SHOULD be clamped 3686 at 0x7fffff for positive loss or 0x800000 for negative loss rather 3687 than wrapping around. 3689 The fraction of packets lost during the last reporting interval 3690 (since the previous SR or RR packet was sent) is calculated from 3691 differences in the expected and received packet counts across the 3692 interval, where expected_prior and received_prior are the values 3693 saved when the previous reception report was generated: 3695 expected_interval = expected - s->expected_prior; 3696 s->expected_prior = expected; 3697 received_interval = s->received - s->received_prior; 3698 s->received_prior = s->received; 3699 lost_interval = expected_interval - received_interval; 3700 if (expected_interval == 0 || lost_interval <= 0) fraction = 0; 3701 else fraction = (lost_interval << 8) / expected_interval; 3703 The resulting fraction is an 8-bit fixed point number with the binary 3704 point at the left edge. 3706 A.4 Generating SDES RTCP Packets 3708 This function builds one SDES chunk into buffer b composed of argc 3709 items supplied in arrays type , value and length b 3711 char *rtp_write_sdes(char *b, u_int32 src, int argc, 3712 rtcp_sdes_type_t type[], char *value[], 3713 int length[]) 3714 { 3715 rtcp_sdes_t *s = (rtcp_sdes_t *)b; 3716 rtcp_sdes_item_t *rsp; 3717 int i; 3718 int len; 3719 int pad; 3721 /* SSRC header */ 3722 s->src = src; 3723 rsp = &s->item[0]; 3725 /* SDES items */ 3726 for (i = 0; i < argc; i++) { 3727 rsp->type = type[i]; 3728 len = length[i]; 3729 if (len > RTP_MAX_SDES) { 3730 /* invalid length, may want to take other action */ 3731 len = RTP_MAX_SDES; 3732 } 3733 rsp->length = len; 3734 memcpy(rsp->data, value[i], len); 3735 rsp = (rtcp_sdes_item_t *)&rsp->data[len]; 3736 } 3738 /* terminate with end marker and pad to next 4-octet boundary */ 3739 len = ((char *) rsp) - b; 3740 pad = 4 - (len & 0x3); 3741 b = (char *) rsp; 3742 while (pad--) *b++ = RTCP_SDES_END; 3744 return b; 3745 } 3747 A.5 Parsing RTCP SDES Packets 3749 This function parses an SDES packet, calling functions find_member() 3750 to find a pointer to the information for a session member given the 3751 SSRC identifier and member_sdes() to store the new SDES information 3752 for that member. This function expects a pointer to the header of the 3753 RTCP packet. 3755 void rtp_read_sdes(rtcp_t *r) 3756 { 3757 int count = r->common.count; 3758 rtcp_sdes_t *sd = &r->r.sdes; 3759 rtcp_sdes_item_t *rsp, *rspn; 3760 rtcp_sdes_item_t *end = (rtcp_sdes_item_t *) 3761 ((u_int32 *)r + r->common.length + 1); 3762 source *s; 3764 while (--count >= 0) { 3765 rsp = &sd->item[0]; 3766 if (rsp >= end) break; 3767 s = find_member(sd->src); 3769 for (; rsp->type; rsp = rspn ) { 3770 rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2); 3771 if (rspn >= end) { 3772 rsp = rspn; 3773 break; 3774 } 3775 member_sdes(s, rsp->type, rsp->data, rsp->length); 3776 } 3777 sd = (rtcp_sdes_t *) 3778 ((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1); 3779 } 3780 if (count >= 0) { 3781 /* invalid packet format */ 3782 } 3783 } 3785 A.6 Generating a Random 32-bit Identifier 3787 The following subroutine generates a random 32-bit identifier using 3788 the MD5 routines published in RFC 1321 [30]. The system routines may 3789 not be present on all operating systems, but they should serve as 3790 hints as to what kinds of information may be used. Other system calls 3791 that may be appropriate include 3793 o getdomainname() , 3795 o getwd() , or 3797 o getrusage() 3799 "Live" video or audio samples are also a good source of random 3800 numbers, but care must be taken to avoid using a turned-off 3801 microphone or blinded camera as a source [12]. 3803 Use of this or similar routine is RECOMMENDED to generate the initial 3804 seed for the random number generator producing the RTCP period (as 3805 shown in Appendix A.7), to generate the initial values for the 3806 sequence number and timestamp, and to generate SSRC values. Since 3807 this routine is likely to be CPU-intensive, its direct use to 3808 generate RTCP periods is inappropriate because predictability is not 3809 an issue. Note that this routine produces the same result on repeated 3810 calls until the value of the system clock changes unless different 3811 values are supplied for the type argument. 3813 /* 3814 * Generate a random 32-bit quantity. 3815 */ 3816 #include /* u_long */ 3817 #include /* gettimeofday() */ 3818 #include /* get..() */ 3819 #include /* printf() */ 3820 #include /* clock() */ 3821 #include /* uname() */ 3822 #include "global.h" /* from RFC 1321 */ 3823 #include "md5.h" /* from RFC 1321 */ 3825 #define MD_CTX MD5_CTX 3826 #define MDInit MD5Init 3827 #define MDUpdate MD5Update 3828 #define MDFinal MD5Final 3830 static u_long md_32(char *string, int length) 3831 { 3832 MD_CTX context; 3833 union { 3834 char c[16]; 3835 u_long x[4]; 3836 } digest; 3837 u_long r; 3838 int i; 3840 MDInit (&context); 3841 MDUpdate (&context, string, length); 3842 MDFinal ((unsigned char *)&digest, &context); 3843 r = 0; 3844 for (i = 0; i < 3; i++) { 3845 r ^= digest.x[i]; 3846 } 3847 return r; 3848 } /* md_32 */ 3850 /* 3851 * Return random unsigned 32-bit quantity. Use 'type' argument if you 3852 * need to generate several different values in close succession. 3853 */ 3854 u_int32 random32(int type) 3855 { 3856 struct { 3857 int type; 3858 struct timeval tv; 3859 clock_t cpu; 3860 pid_t pid; 3861 u_long hid; 3862 uid_t uid; 3863 gid_t gid; 3864 struct utsname name; 3865 } s; 3867 gettimeofday(&s.tv, 0); 3868 uname(&s.name); 3869 s.type = type; 3870 s.cpu = clock(); 3871 s.pid = getpid(); 3872 s.hid = gethostid(); 3873 s.uid = getuid(); 3874 s.gid = getgid(); 3875 /* also: system uptime */ 3877 return md_32((char *)&s, sizeof(s)); 3878 } /* random32 */ 3880 A.7 Computing the RTCP Transmission Interval 3882 The following functions implement the RTCP transmission and reception 3883 rules described in Section 6.2. These rules are coded in several 3884 functions: 3886 o rtcp_interval() computes the deterministic calculated 3887 interval, measured in seconds. The parameters are defined in 3888 Section 6.3. 3890 o OnExpire() is called when the RTCP transmission timer expires. 3892 o OnReceive() is called whenever an RTCP packet is received. 3894 Both OnExpire() and OnReceive() have event e as an argument. This is 3895 the next scheduled event for that participant, either an RTCP report 3896 or a BYE packet. It is assumed that the following functions are 3897 available: 3899 o Schedule(time t, event e) schedules an event e to occur at 3900 time t. When time t arrives, the funcion OnExpire is called 3901 with e as an argument. 3903 o Reschedule(time t, event e) reschedules a previously scheduled 3904 event e for time t. 3906 o SendRTCPReport(event e) sends an RTCP report. 3908 o SendBYEPacket(event e) sends a BYE packet. 3910 o TypeOfEvent(event e) returns EVENT_BYE if the event being 3911 processed is for a BYE packet to be sent, else it returns 3912 EVENT_REPORT. 3914 o PacketType(p) returns PACKET_RTCP_REPORT if packet p is an 3915 RTCP report (not BYE), PACKET_BYE if its a BYE RTCP packet, 3916 and PACKET_RTP if its a regular RTP data packet. 3918 o ReceivedPacketSize() and SentPacketSize() return the size of 3919 the referenced packet in octets. 3921 o NewMember(p) returns a 1 if the participant who sent packet p 3922 is not currently in the member list, 0 otherwise. Note this 3923 function is not sufficient for a complete implementation 3924 because each CSRC identifier in an RTP packet and each SSRC in 3925 a BYE packet should be processed. 3927 o NewSender(p) returns a 1 if the participant who sent packet p 3928 is not currently in the sender sublist of the member list, 0 3929 otherwise. 3931 o AddMember() and RemoveMember() to add and remove participants 3932 from the member list. 3934 o AddSender() and RemoveSender() to add and remove participants 3935 from the sender sublist of the member list. 3937 double rtcp_interval(int members, 3938 int senders, 3939 double rtcp_bw, 3940 int we_sent, 3941 double avg_rtcp_size, 3942 int initial) 3943 { 3944 /* 3945 * Minimum average time between RTCP packets from this site (in 3946 * seconds). This time prevents the reports from `clumping' when 3947 * sessions are small and the law of large numbers isn't helping 3948 * to smooth out the traffic. It also keeps the report interval 3949 * from becoming ridiculously small during transient outages like 3950 * a network partition. 3951 */ 3952 double const RTCP_MIN_TIME = 5.; 3953 /* 3954 * Fraction of the RTCP bandwidth to be shared among active 3955 * senders. (This fraction was chosen so that in a typical 3956 * session with one or two active senders, the computed report 3957 * time would be roughly equal to the minimum report time so that 3958 * we don't unnecessarily slow down receiver reports.) The 3959 * receiver fraction must be 1 - the sender fraction. 3960 */ 3961 double const RTCP_SENDER_BW_FRACTION = 0.25; 3962 double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION); 3963 /* 3964 /* To compensate for "unconditional reconsideration" converging to a 3965 * value below the intended average. 3966 */ 3967 double const COMPENSATION = 2.71828 - 1.5; 3969 double t; /* interval */ 3970 double rtcp_min_time = RTCP_MIN_TIME; 3971 int n; /* no. of members for computation */ 3973 /* 3974 * Very first call at application start-up uses half the min 3975 * delay for quicker notification while still allowing some time 3976 * before reporting for randomization and to learn about other 3977 * sources so the report interval will converge to the correct 3978 * interval more quickly. 3979 */ 3980 if (initial) { 3981 rtcp_min_time /= 2; 3982 } 3983 /* 3984 * If there were active senders, give them at least a minimum 3985 * share of the RTCP bandwidth. Otherwise all participants share 3986 * the RTCP bandwidth equally. 3987 */ 3988 n = members; 3989 if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) { 3990 if (we_sent) { 3991 rtcp_bw *= RTCP_SENDER_BW_FRACTION; 3992 n = senders; 3993 } else { 3994 rtcp_bw *= RTCP_RCVR_BW_FRACTION; 3995 n -= senders; 3996 } 3997 } 3999 /* 4000 * The effective number of sites times the average packet size is 4001 * the total number of octets sent when each site sends a report. 4002 * Dividing this by the effective bandwidth gives the time 4003 * interval over which those packets must be sent in order to 4004 * meet the bandwidth target, with a minimum enforced. In that 4005 * time interval we send one report so this time is also our 4006 * average time between reports. 4007 */ 4008 t = avg_rtcp_size * n / rtcp_bw; 4009 if (t < rtcp_min_time) t = rtcp_min_time; 4011 /* 4012 * To avoid traffic bursts from unintended synchronization with 4013 * other sites, we then pick our actual next report interval as a 4014 * random number uniformly distributed between 0.5*t and 1.5*t. 4015 */ 4016 t = t * (drand48() + 0.5); 4017 t = t / COMPENSATION; 4018 return t; 4019 } 4020 void OnExpire(event e, 4021 int members, 4022 int senders, 4023 double rtcp_bw, 4024 int we_sent, 4025 double *avg_rtcp_size, 4026 int *initial, 4027 time_tp tc, 4028 time_tp *tp, 4029 int *pmembers) 4030 { 4031 /* This function is responsible for deciding whether to send 4032 * an RTCP report or BYE packet now, or to reschedule transmission. 4033 * It is also responsible for updating the pmembers, initial, tp, 4034 * and avg_rtcp_size state variables. This function should be called 4035 * upon expiration of the event timer used by Schedule(). */ 4037 double t; /* Interval */ 4038 double tn; /* Next transmit time */ 4040 /* In the case of a BYE, we use "unconditional reconsideration" to 4041 * reschedule the transmission of the BYE if necessary */ 4043 if (TypeOfEvent(e) == EVENT_BYE) { 4044 t = rtcp_interval(members, 4045 senders, 4046 rtcp_bw, 4047 we_sent, 4048 *avg_rtcp_size, 4049 *initial); 4050 tn = *tp + t; 4051 if (tn <= tc) { 4052 SendBYEPacket(e); 4053 exit(1); 4054 } else { 4055 Schedule(tn, e); 4056 } 4058 } else if (TypeOfEvent(e) == EVENT_REPORT) { 4059 t = rtcp_interval(members, 4060 senders, 4061 rtcp_bw, 4062 we_sent, 4063 *avg_rtcp_size, 4064 *initial); 4065 tn = *tp + t; 4066 if (tn <= tc) { 4067 SendRTCPReport(e); 4068 *avg_rtcp_size = (1./16.)*SentPacketSize(e) + 4069 (15./16.)*(*avg_rtcp_size); 4070 *tp = tc; 4072 /* We must redraw the interval. Don't reuse the 4073 one computed above, since its not actually 4074 distributed the same, as we are conditioned 4075 on it being small enough to cause a packet to 4076 be sent */ 4078 t = rtcp_interval(members, 4079 senders, 4080 rtcp_bw, 4081 we_sent, 4082 *avg_rtcp_size, 4083 *initial); 4085 Schedule(t+tc,e); 4086 *initial = 0; 4087 } else { 4088 Schedule(tn, e); 4089 } 4090 *pmembers = members; 4091 } 4092 } 4093 void OnReceive(packet p, 4094 event e, 4095 int *members, 4096 int *pmembers, 4097 int *senders, 4098 double *avg_rtcp_size, 4099 double *tp, 4100 double tc, 4101 double tn) 4102 { 4103 /* What we do depends on whether we have left the group, and 4104 * are waiting to send a BYE (TypeOfEvent(e) == EVENT_BYE) or 4105 * an RTCP report. p represents the packet that was just received. */ 4107 if (PacketType(p) == PACKET_RTCP_REPORT) { 4108 if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) { 4109 AddMember(p); 4110 *members += 1; 4111 } 4112 *avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) + 4113 (15./16.)*(*avg_rtcp_size); 4114 } else if (PacketType(p) == PACKET_RTP) { 4115 if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) { 4116 AddMember(p); 4117 *members += 1; 4118 } 4119 if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) { 4120 AddSender(p); 4121 *senders += 1; 4122 } 4123 } else if (PacketType(p) == PACKET_BYE) { 4124 *avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) + 4125 (15./16.)*(*avg_rtcp_size); 4127 if (TypeOfEvent(e) == EVENT_REPORT) { 4128 if (NewSender(p) == FALSE) { 4129 RemoveSender(p); 4130 *senders -= 1; 4131 } 4133 if (NewMember(p) == FALSE) { 4134 RemoveMember(p); 4135 *members -= 1; 4136 } 4138 if(*members < *pmembers) { 4139 tn = tc + (((double) *members)/(*pmembers))*(tn - tc); 4140 *tp = tc - (((double) *members)/(*pmembers))*(tc - *tp); 4142 /* Reschedule the next report for time tn */ 4144 Reschedule(tn, e); 4145 *pmembers = *members; 4146 } 4148 } else if (TypeOfEvent(e) == EVENT_BYE) { 4149 *members += 1; 4150 } 4151 } 4152 } 4154 A.8 Estimating the Interarrival Jitter 4156 The code fragments below implement the algorithm given in Section 4157 6.4.1 for calculating an estimate of the statistical variance of the 4158 RTP data interarrival time to be inserted in the interarrival jitter 4159 field of reception reports. The inputs are r->ts , the timestamp from 4160 the incoming packet, and arrival , the current time in the same 4161 units. Here s points to state for the source; s->transit holds the 4162 relative transit time for the previous packet, and s->jitter holds 4163 the estimated jitter. The jitter field of the reception report is 4164 measured in timestamp units and expressed as an unsigned integer, but 4165 the jitter estimate is kept in a floating point. As each data packet 4166 arrives, the jitter estimate is updated: 4168 int transit = arrival - r->ts; 4169 int d = transit - s->transit; 4170 s->transit = transit; 4171 if (d < 0) d = -d; 4172 s->jitter += (1./16.) * ((double)d - s->jitter); 4174 When a reception report block (to which rr points) is generated for 4175 this member, the current jitter estimate is returned: 4177 rr->jitter = (u_int32) s->jitter; 4179 Alternatively, the jitter estimate can be kept as an integer, but 4180 scaled to reduce round-off error. The calculation is the same except 4181 for the last line: 4183 s->jitter += d - ((s->jitter + 8) >> 4); 4185 In this case, the estimate is sampled for the reception report as: 4187 rr->jitter = s->jitter >> 4; 4189 B Changes from RFC 1889 4191 Most of this RFC is identical to RFC 1889. The changes are listed 4192 below. 4194 o The algorithm for calculating the RTCP transmission interval 4195 specified in Sections 6.2 and 6.3 and illustrated in Appendix 4196 A.7 is augmented to include "reconsideration" to minimize 4197 transmission over the intended rate when many participants 4198 join a session simultaneously, and "reverse reconsideration" 4199 to reduce the incidence and duration of false participant 4200 timeouts when the number of participants drops rapidly. 4201 Reverse reconsideration is also used to possibly shorten the 4202 delay before sending RTCP SR when transitioning from passive 4203 receiver to active sender mode. 4205 o Section 6.3.7 specifies new rules controlling when an RTCP BYE 4206 packet should be sent in order to avoid a flood of packets 4207 when many participants leave a session simultaneously. 4208 Sections 7.2 and 7.3 specify that translators and mixers 4209 should send BYE packets for the sources they are no longer 4210 forwarding. 4212 o Section 6.2.1 specifies that implementations may store only a 4213 sampling of the participants' SSRC identifiers to allow 4214 scaling to very large sessions. Algorithms are specified in 4215 RFC 2762 [16]. 4217 o In Section 6.2 it is specified that RTCP sender and receiver 4218 bandwidths to be set as separate parameters of the session 4219 rather than a strict percentage of the session bandwidth, and 4220 may be set to zero. The requirement that RTCP was mandatory 4221 for RTP sessions using IP multicast was relaxed. 4223 o Also in Section 6.2 it is specified that the minimum RTCP 4224 interval may be scaled to smaller values for high bandwidth 4225 sessions, and that the initial RTCP delay may be set to zero 4226 for unicast sessions. 4228 o The requirement to retain state for inactive participants for 4229 a period long enough to span typical network partitions was 4230 removed from Section 6.2.1. In a session where many 4231 participants join for a brief time and fail to send BYE, this 4232 requirement would cause a significant overestimate of the 4233 number of participants. The reconsideration algorithm added in 4234 this revision compensates for the large number of new 4235 participants joining simultaneously when a partition heals. 4237 o Timing out a participant is to be based on inactivity for a 4238 number of RTCP report intervals calculated using the receiver 4239 RTCP bandwidth fraction even for active senders. 4241 o Rule changes for layered encodings are defined in Sections 4242 2.4, 6.3.9, 8.3 and 11. In the last of these, it is noted that 4243 the address and port assignment rule conflicts with the SDP 4244 specification, RFC 2327 [8], but it is intended that this 4245 restriction will be relaxed in a revision of RFC 2327. 4247 o A new Section 10 on congestion control was added. 4249 o In Section 8.2, the requirement that a new SSRC identifier 4250 MUST be chosen whenever the source transport address is 4251 changed has been relaxed to say that a new SSRC identifier MAY 4252 be chosen. Correspondingly, it was clarified that an 4253 implementation MAY choose to keep packets from the new source 4254 address rather than the existing source address when a 4255 collision occurs, and SHOULD do so for applications such as 4256 telephony in which some sources such as mobile entities may 4257 change addresses during the course of an RTP session. 4259 o An indentation bug in the RFC 1889 printing of the pseudo-code 4260 for the collision detection and resolution algorithm in 4261 Section 8.2 has been corrected by translating the syntax to 4262 pseudo C language, and the algorithm has been modified to 4263 remove the restriction that both RTP and RTCP must be sent 4264 from the same source port number. 4266 o For unicast RTP sessions, distinct port pairs may be used for 4267 the two ends (Sections 3 and 7.1). 4269 o The description of the padding mechanism for RTCP packets was 4270 clarified and it is specified that padding MUST be applied to 4271 the last packet of a compound RTCP packet. 4273 o Clamping of number of packets lost in Section A.3 was 4274 corrected to use both positive and negative limits. 4276 o It is specified that a receiver MUST ignore packets with 4277 payload types it does not understand. 4279 o The specification of "relative" NTP timestamp in the RTCP SR 4280 section now defines these timestamps to be based on the most 4281 common system-specific clock, such as system uptime, rather 4282 than on session elapsed time which would not be the same for 4283 multiple applications started on the same machine at different 4284 times. 4286 o The inconsequence of NTP timestamps wrapping around in the 4287 year 2036 is explained. 4289 o The policy for registration of RTCP packet types and SDES 4290 types was clarified in a new Section 14, IANA Considerations. 4291 The suggestion that experimenters register the numbers they 4292 need and then unregister those which prove to be unneeded has 4293 been removed in in favor of using APP and PRIV. Registration 4294 of profile names was also specified. 4296 o The reference for the UTF-8 character set was changed from an 4297 X/Open Preliminary Specification to be RFC 2279. 4299 o The last paragraph of the introduction in RFC 1889, which 4300 cautioned implementers to limit deployment in the Internet, 4301 was removed because it was deemed no longer relevant. 4303 o Small clarifications of the text have been made in several 4304 places, some in response to questions from readers. In 4305 particular: 4307 - A definition for "RTP media type" is given in Section 3 to 4308 allow the explanation of multiplexing RTP sessions in 4309 Section 5.2 to be more clear regarding the multiplexing of 4310 multiple media. 4312 - The definition for "non-RTP means" was expanded to include 4313 examples of other protocols constituting non-RTP means. 4315 - The description of the session bandwidth parameter is 4316 expanded in Section 6.2. 4318 - The method for terminating and padding a sequence of SDES 4319 items was clarified in Section 6.5. 4321 - The Security section adds a formal reference to IPSEC now 4322 that it is available, and says that the confidentiality 4323 method defined in this specification is primarily to codify 4324 existing practice. It is RECOMMENDED that stronger 4325 encryption algorithms such as Triple-DES be used in place of 4326 the default algorithm. It is also noted that payload-only 4327 encryption is necessary to allow for header compression. 4329 - The method for partial encryption of RTCP was clarified; in 4330 particular, SDES CNAME is carried in only one part when the 4331 compound RTCP packet is split. 4333 - The convention for using even/odd port pairs in Section 11 4334 was clarified to refer to destination ports. 4336 - A note was added in Appendix A.1 that packets may be saved 4337 during RTP header validation and delivered upon success. 4339 - Section 7.3 now explains that a mixer aggregating SDES 4340 packets uses more RTCP bandwidth due to longer packets, and 4341 a mixer passing through RTCP naturally sends packets at 4342 higher than the single source rate, but both behaviors are 4343 valid. 4345 - Section 13 clarifies that an RTP application may use 4346 multiple profiles but typically only one in a given session. 4348 - The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 4349 2119. 4351 C Security Considerations 4353 RTP suffers from the same security liabilities as the underlying 4354 protocols. For example, an impostor can fake source or destination 4355 network addresses, or change the header or payload. Within RTCP, the 4356 CNAME and NAME information may be used to impersonate another 4357 participant. In addition, RTP may be sent via IP multicast, which 4358 provides no direct means for a sender to know all the receivers of 4359 the data sent and therefore no measure of privacy. Rightly or not, 4360 users may be more sensitive to privacy concerns with audio and video 4361 communication than they have been with more traditional forms of 4362 network communication [31]. Therefore, the use of security mechanisms 4363 with RTP is important. These mechanisms are discussed in Section 9. 4365 RTP-level translators or mixers may be used to allow RTP traffic to 4366 reach hosts behind firewalls. Appropriate firewall security 4367 principles and practices, which are beyond the scope of this 4368 document, should be followed in the design and installation of these 4369 devices and in the admission of RTP applications for use behind the 4370 firewall. 4372 D Full Copyright Statement 4374 Copyright (C) The Internet Society (2001). All Rights Reserved. 4376 This document and translations of it may be copied and furnished to 4377 others, and derivative works that comment on or otherwise explain it 4378 or assist in its implmentation may be prepared, copied, published and 4379 distributed, in whole or in part, without restriction of any kind, 4380 provided that the above copyright notice and this paragraph are 4381 included on all such copies and derivative works. However, this 4382 document itself may not be modified in any way, such as by removing 4383 the copyright notice or references to the Internet Society or other 4384 Internet organizations, except as needed for the purpose of 4385 developing Internet standards in which case the procedures for 4386 copyrights defined in the Internet Standards process must be 4387 followed, or as required to translate it into languages other than 4388 English. 4390 The limited permissions granted above are perpetual and will not be 4391 revoked by the Internet Society or its successors or assigns. 4393 This document and the information contained herein is provided on an 4394 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4395 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4396 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4397 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4398 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4400 E Addresses of Authors 4402 Henning Schulzrinne 4403 Department of Computer Science 4404 Columbia University 4405 1214 Amsterdam Avenue 4406 New York, NY 10027 4407 USA 4408 electronic mail: schulzrinne@cs.columbia.edu 4410 Stephen L. Casner 4411 Packet Design 4412 2465 Latham Street 4413 Mountain View, CA 94040 4414 United States 4415 electronic mail: casner@acm.org 4417 Ron Frederick 4418 Cacheflow Inc. 4419 650 Almanor Avenue 4420 Sunnyvale, CA 94085 4421 United States 4422 electronic mail: ronf@cacheflow.com 4424 Van Jacobson 4425 Packet Design 4426 2465 Latham Street 4427 Mountain View, CA 94040 4428 United States 4429 electronic mail: van@packetdesign.com 4431 Acknowledgments 4433 This memorandum is based on discussions within the IETF Audio/Video 4434 Transport working group chaired by Stephen Casner and Colin Perkins. 4435 The current protocol has its origins in the Network Voice Protocol 4436 and the Packet Video Protocol (Danny Cohen and Randy Cole) and the 4437 protocol implemented by the vat application (Van Jacobson and Steve 4438 McCanne). Christian Huitema provided ideas for the random identifier 4439 generator. Extensive analysis and simulation of the timer 4440 reconsideration algorithm was done by Jonathan Rosenberg. 4442 F Bibliography 4444 [1] D. D. Clark and D. L. Tennenhouse, "Architectural considerations 4445 for a new generation of protocols," in SIGCOMM Symposium on 4446 Communications Architectures and Protocols , (Philadelphia, 4447 Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer 4448 Communications Review, Vol. 20(4), Sept. 1990. 4450 [2] H. Schulzrinne and S. Casner, "RTP profile for audio and video 4451 conferences with minimal control," Internet Draft, Internet 4452 Engineering Task Force, June 1999. Work in progress. 4454 [3] H. Schulzrinne, "Issues in designing a transport protocol for 4455 audio and video conferences and other multiparticipant real-time 4456 applications." expired Internet draft, Oct. 1993. 4458 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 4459 levels," Request for Comments (Best Current Practice) 2119, Internet 4460 Engineering Task Force, Mar. 1997. 4462 [5] D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood 4463 Cliffs, New Jersey: Prentice Hall, 1991. 4465 [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 4466 session initiation protocol," Request for Comments (Proposed 4467 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 4469 [7] International Telecommunication Union, "Visual telephone systems 4470 and equipment for local area networks which provide a non-guaranteed 4471 quality of service," Recommendation H.323, Telecommunication 4472 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 4474 [8] M. Handley and V. Jacobson, "SDP: session description protocol," 4475 Request for Comments (Proposed Standard) 2327, Internet Engineering 4476 Task Force, Apr. 1998. 4478 [9] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 4479 protocol (RTSP)," Request for Comments (Proposed Standard) 2326, 4480 Internet Engineering Task Force, Apr. 1998. 4482 [10] J. Postel, "Internet protocol," Request for Comments (Standard) 4483 791, Internet Engineering Task Force, Sept. 1981. 4485 [11] D. L. Mills, "Network time protocol (version 3) specification, 4486 implementation," Request for Comments (Draft Standard) 1305, Internet 4487 Engineering Task Force, Mar. 1992. 4489 [12] D. Eastlake, 3rd, S. Crocker, and J. Schiller, "Randomness 4490 recommendations for security," Request for Comments (Informational) 4491 1750, Internet Engineering Task Force, Dec. 1994. 4493 [13] J.-C. Bolot, T. Turletti, and I. Wakeman, "Scalable feedback 4494 control for multicast video distribution in the internet," in SIGCOMM 4495 Symposium on Communications Architectures and Protocols , (London, 4496 England), pp. 58--67, ACM, Aug. 1994. 4498 [14] I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control 4499 of multimedia applications based on RTP," Computer Communications , 4500 vol. 19, pp. 49--58, Jan. 1996. 4502 [15] S. Floyd and V. Jacobson, "The synchronization of periodic 4503 routing messages," in SIGCOMM Symposium on Communications 4504 Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, 4505 California), pp. 33--44, ACM, Sept. 1993. also in [32]. 4507 [16] J. Rosenberg and H. Schulzrinne, "Sampling of the group 4508 membership in RTP," Request for Comments (Experimental) 2762, 4509 Internet Engineering Task Force, May 1999. 4511 [17] J. A. Cadzow, Foundations of digital signal processing and data 4512 analysis New York, New York: Macmillan, 1987. 4514 [18] F. Yergeau, "UTF-8, a transformation format of ISO 10646," 4515 Request for Comments (Proposed Standard) 2279, Internet Engineering 4516 Task Force, Jan. 1998. 4518 [19] P. V. Mockapetris, "Domain names - concepts and facilities," 4519 Request for Comments (Standard) 1034, Internet Engineering Task 4520 Force, Nov. 1987. 4522 [20] P. V. Mockapetris, "Domain names - implementation and 4523 specification," Request for Comments (Standard) 1035, Internet 4524 Engineering Task Force, Nov. 1987. 4526 [21] R. T. Braden, "Requirements for internet hosts - application and 4527 support," Request for Comments (Standard) 1123, Internet Engineering 4528 Task Force, Oct. 1989. 4530 [22] Y. Rekhter, B. Moskowitz, D. Karrenberg, and G. de Groot, 4531 "Address allocation for private internets," Request for Comments 4532 (Informational) 1597, Internet Engineering Task Force, Mar. 1994. 4534 [23] E. Lear, E. Fair, D. Crocker, and T. Kessler, "Network 10 4535 considered harmful (some practices shouldn't be codified)," Request 4536 for Comments (Informational) 1627, Internet Engineering Task Force, 4537 June 1994. 4539 [24] D. Crocker, "Standard for the format of ARPA internet text 4540 messages," Request for Comments (Standard) 822, Internet Engineering 4541 Task Force, Aug. 1982. 4543 [25] W. Feller, An Introduction to Probability Theory and its 4544 Applications, Volume 1 , vol. 1. New York, New York: John Wiley and 4545 Sons, third ed., 1968. 4547 [26] S. Kent and R. Atkinson, "Security architecture for the internet 4548 protocol," Request for Comments (Proposed Standard) 2401, Internet 4549 Engineering Task Force, Nov. 1998. 4551 [27] D. Balenson, "Privacy enhancement for internet electronic mail: 4552 Part III: algorithms, modes, and identifiers," Request for Comments 4553 (Proposed Standard) 1423, Internet Engineering Task Force, Feb. 1993. 4555 [28] V. L. Voydock and S. T. Kent, "Security mechanisms in high-level 4556 network protocols," ACM Computing Surveys , vol. 15, pp. 135--171, 4557 June 1983. 4559 [29] S. Floyd, "Congestion Control Principles," Request for Comments 4560 (Best Current Practice) 2914, Internet Engineering Task Force, Sep. 4561 2000. 4563 [30] R. Rivest, "The MD5 message-digest algorithm," Request for 4564 Comments (Informational) 1321, Internet Engineering Task Force, Apr. 4565 1992. 4567 [31] S. Stubblebine, "Security services for multimedia conferencing," 4568 in 16th National Computer Security Conference , (Baltimore, 4569 Maryland), pp. 391--395, Sept. 1993. 4571 [32] S. Floyd and V. Jacobson, "The synchronization of periodic 4572 routing messages," IEEE/ACM Transactions on Networking , vol. 2, pp. 4573 122--136, Apr. 1994. 4575 Table of Contents 4577 1 Introduction ........................................ 3 4578 1.1 Terminology ......................................... 5 4579 2 RTP Use Scenarios ................................... 5 4580 2.1 Simple Multicast Audio Conference ................... 5 4581 2.2 Audio and Video Conference .......................... 6 4582 2.3 Mixers and Translators .............................. 7 4583 2.4 Layered Encodings ................................... 8 4584 3 Definitions ......................................... 8 4585 4 Byte Order, Alignment, and Time Format .............. 11 4586 5 RTP Data Transfer Protocol .......................... 12 4587 5.1 RTP Fixed Header Fields ............................. 12 4588 5.2 Multiplexing RTP Sessions ........................... 15 4589 5.3 Profile-Specific Modifications to the RTP Header 4590 ................................................................ 16 4591 5.3.1 RTP Header Extension ................................ 17 4592 6 RTP Control Protocol -- RTCP ........................ 17 4593 6.1 RTCP Packet Format .................................. 19 4594 6.2 RTCP Transmission Interval .......................... 21 4595 6.2.1 Maintaining the number of session members ........... 25 4596 6.3 RTCP Packet Send and Receive Rules .................. 26 4597 6.3.1 Computing the RTCP transmission interval ............ 27 4598 6.3.2 Initialization ...................................... 28 4599 6.3.3 Receiving an RTP or non-BYE RTCP packet ............. 28 4600 6.3.4 Receiving an RTCP BYE packet ........................ 29 4601 6.3.5 Timing Out an SSRC .................................. 29 4602 6.3.6 Expiration of transmission timer .................... 30 4603 6.3.7 Transmitting a BYE packet ........................... 30 4604 6.3.8 Updating we_sent .................................... 31 4605 6.3.9 Allocation of source description bandwidth .......... 32 4606 6.4 Sender and Receiver Reports ......................... 32 4607 6.4.1 SR: Sender report RTCP packet ....................... 33 4608 6.4.2 RR: Receiver report RTCP packet ..................... 39 4609 6.4.3 Extending the sender and receiver reports ........... 40 4610 6.4.4 Analyzing sender and receiver reports ............... 41 4611 6.5 SDES: Source description RTCP packet ................ 42 4612 6.5.1 CNAME: Canonical end-point identifier SDES item ..... 44 4613 6.5.2 NAME: User name SDES item ........................... 45 4614 6.5.3 EMAIL: Electronic mail address SDES item ............ 46 4615 6.5.4 PHONE: Phone number SDES item ....................... 46 4616 6.5.5 LOC: Geographic user location SDES item ............. 46 4617 6.5.6 TOOL: Application or tool name SDES item ............ 47 4618 6.5.7 NOTE: Notice/status SDES item ....................... 47 4619 6.5.8 PRIV: Private extensions SDES item .................. 48 4620 6.6 BYE: Goodbye RTCP packet ............................ 49 4621 6.7 APP: Application-defined RTCP packet ................ 49 4622 7 RTP Translators and Mixers .......................... 51 4623 7.1 General Description ................................. 51 4624 7.2 RTCP Processing in Translators ...................... 53 4625 7.3 RTCP Processing in Mixers ........................... 55 4626 7.4 Cascaded Mixers ..................................... 56 4627 8 SSRC Identifier Allocation and Use .................. 56 4628 8.1 Probability of Collision ............................ 57 4629 8.2 Collision Resolution and Loop Detection ............. 57 4630 8.3 Use with Layered Encodings .......................... 62 4631 9 Security ............................................ 62 4632 9.1 Confidentiality ..................................... 63 4633 9.2 Authentication and Message Integrity ................ 65 4634 10 Congestion Control .................................. 65 4635 11 RTP over Network and Transport Protocols ............ 65 4636 12 Summary of Protocol Constants ....................... 67 4637 12.1 RTCP packet types ................................... 67 4638 12.2 SDES types .......................................... 67 4639 13 RTP Profiles and Payload Format Specifications ...... 68 4640 14 IANA Considerations ................................. 70 4641 A Algorithms .......................................... 71 4642 A.1 RTP Data Header Validity Checks ..................... 75 4643 A.2 RTCP Header Validity Checks ......................... 80 4644 A.3 Determining the Number of RTP Packets Expected and 4645 Lost ........................................................... 80 4646 A.4 Generating SDES RTCP Packets ........................ 81 4647 A.5 Parsing RTCP SDES Packets ........................... 82 4648 A.6 Generating a Random 32-bit Identifier ............... 83 4649 A.7 Computing the RTCP Transmission Interval ............ 86 4650 A.8 Estimating the Interarrival Jitter .................. 93 4651 B Changes from RFC 1889 ............................... 94 4652 C Security Considerations ............................. 97 4653 D Full Copyright Statement ............................ 98 4654 E Addresses of Authors ................................ 98 4655 F Bibliography ........................................ 99