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