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