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