idnits 2.17.1 draft-ietf-avt-rtp-08.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-25) 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. ** 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 16 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 219 has weird spacing: '...receive media...' == Line 820 has weird spacing: '... item item ...' == Line 2229 has weird spacing: '...ervices have...' == Line 2540 has weird spacing: '...ed char u_int...' == Line 2542 has weird spacing: '...ned int u_in...' == (4 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 1995) is 10384 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 3349 looks like a reference -- Missing reference section? '2' on line 3355 looks like a reference -- Missing reference section? '3' on line 3359 looks like a reference -- Missing reference section? '4' on line 3362 looks like a reference -- Missing reference section? '5' on line 3365 looks like a reference -- Missing reference section? '6' on line 3368 looks like a reference -- Missing reference section? '7' on line 3371 looks like a reference -- Missing reference section? '8' on line 3375 looks like a reference -- Missing reference section? '9' on line 3380 looks like a reference -- Missing reference section? '-packet-' on line 817 looks like a reference -- Missing reference section? '10' on line 3385 looks like a reference -- Missing reference section? '11' on line 3390 looks like a reference -- Missing reference section? '12' on line 3393 looks like a reference -- Missing reference section? '13' on line 3398 looks like a reference -- Missing reference section? '14' on line 3401 looks like a reference -- Missing reference section? '15' on line 3404 looks like a reference -- Missing reference section? '16' on line 3408 looks like a reference -- Missing reference section? '17' on line 3412 looks like a reference -- Missing reference section? '18' on line 3416 looks like a reference -- Missing reference section? '19' on line 3420 looks like a reference -- Missing reference section? 'E1' on line 1851 looks like a reference -- Missing reference section? 'E6' on line 1851 looks like a reference -- Missing reference section? 'E2' on line 1860 looks like a reference -- Missing reference section? 'E4' on line 1860 looks like a reference -- Missing reference section? 'E3' on line 1862 looks like a reference -- Missing reference section? 'E5' on line 1866 looks like a reference -- Missing reference section? '20' on line 3424 looks like a reference -- Missing reference section? '21' on line 3428 looks like a reference -- Missing reference section? '22' on line 3432 looks like a reference -- Missing reference section? '0' on line 2996 looks like a reference -- Missing reference section? '23' on line 3436 looks like a reference -- Missing reference section? '24' on line 3439 looks like a reference -- Missing reference section? '25' on line 3443 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 7 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 WG 3 Internet Draft Schulzrinne/Casner/Frederick/Jacobson 4 draft-ietf-avt-rtp-08.txt GMD/ISI/Xerox/LBNL 5 November 20, 1995 6 Expires: 3/1/96 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 learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 This memorandum describes RTP, the real-time transport 33 protocol. RTP provides end-to-end network transport 34 functions suitable for applications transmitting real- 35 time data, such as audio, video or simulation data, over 36 multicast or unicast network services. RTP does not 37 address resource reservation and does not guarantee 38 quality-of-service for real-time services. The data 39 transport is augmented by a control protocol (RTCP) to 40 allow monitoring of the data delivery in a manner 41 scalable to large multicast networks, and to provide 42 minimal control and identification functionality. RTP and 43 RTCP are designed to be independent of the underlying 44 transport and network layers. The protocol supports the 45 use of RTP-level translators and mixers. 47 This specification is a product of the Audio/Video Transport working 48 group within the Internet Engineering Task Force. Comments are 49 solicited and should be addressed to the working group's mailing list 50 at rem-conf@es.net and/or the authors. 52 1 Introduction 54 This memorandum specifies the real-time transport protocol (RTP), 55 which provides end-to-end delivery services for data with real-time 56 characteristics, such as interactive audio and video. Those services 57 include payload type identification, sequence numbering, timestamping 58 and delivery monitoring. Applications typically run RTP on top of UDP 59 to make use of its multiplexing and checksum services; both protocols 60 contribute parts of the transport protocol functionality. However, 61 RTP may be used with other suitable underlying network or transport 62 protocols (see Section 10). RTP supports data transfer to multiple 63 destinations using multicast distribution if provided by the 64 underlying network. 66 Note that RTP itself does not provide any mechanism to ensure timely 67 delivery or provide other quality-of-service guarantees, but relies 68 on lower-layer services to do so. It does not guarantee delivery or 69 prevent out-of-order delivery, nor does it assume that the underlying 70 network is reliable and delivers packets in sequence. The sequence 71 numbers included in RTP allow the receiver to reconstruct the 72 sender's packet sequence, but sequence numbers might also be used to 73 determine the proper location of a packet, for example in video 74 decoding, without necessarily decoding packets in sequence. 76 While RTP is primarily designed to satisfy the needs of multi- 77 participant multimedia conferences, it is not limited to that 78 particular application. Storage of continuous data, interactive 79 distributed simulation, active badge, and control and measurement 80 applications may also find RTP applicable. 82 This document defines RTP, consisting of two closely-linked parts: 84 o the real-time transport protocol (RTP), to carry data that has 85 real-time properties. 87 o the RTP control protocol (RTCP), to monitor the quality of 88 service and to convey information about the participants in an 89 on-going session. The latter aspect of RTCP may be sufficient 90 for "loosely controlled" sessions, i.e., where there is no 91 explicit membership control and set-up, but it is not 92 necessarily intended to support all of an application's control 93 communication requirements. This functionality may be fully or 94 partially subsumed by a separate session control protocol, 95 which is beyond the scope of this document. 97 RTP represents a new style of protocol following the principles of 98 application level framing and integrated layer processing proposed by 99 Clark and Tennenhouse [1]. That is, RTP is intended to be malleable 100 to provide the information required by a particular application and 101 will often be integrated into the application processing rather than 102 being implemented as a separate layer. RTP is a protocol framework 103 that is deliberately not complete. This document specifies those 104 functions expected to be common across all the applications for which 105 RTP would be appropriate. Unlike conventional protocols in which 106 additional functions might be accommodated by making the protocol 107 more general or by adding an option mechanism that would require 108 parsing, RTP is intended to be tailored through modifications and/or 109 additions to the headers as needed. Examples are given in Sections 110 5.3 and 6.3.3. 112 Therefore, in addition to this document, a complete specification of 113 RTP for a particular application will require one or more companion 114 documents (see Section 12): 116 o a profile specification document, which defines a set of 117 payload type codes and their mapping to payload formats (e.g., 118 media encodings). A profile may also define extensions or 119 modifications to RTP that are specific to a particular class of 120 applications. Typically an application will operate under only 121 one profile. A profile for audio and video data may be found in 122 the companion RFC TBD. 124 o payload format specification documents, which define how a 125 particular payload, such as an audio or video encoding, is to 126 be carried in RTP. 128 A discussion of real-time services and algorithms for their 129 implementation as well as background discussion on some of the RTP 130 design decisions can be found in [2]. 132 Several RTP applications, both experimental and commercial, have 133 already been implemented from draft specifications. These 134 applications include audio and video tools along with diagnostic 135 tools such as traffic monitors. Users of these tools number in the 136 thousands. However, the current Internet cannot yet support the full 137 potential demand for real-time services. High-bandwidth services 138 using RTP, such as video, can potentially seriously degrade the 139 quality of service of other network services. Thus, implementors 140 should take appropriate precautions to limit accidental bandwidth 141 usage. Application documentation should clearly outline the 142 limitations and possible operational impact of high-bandwidth real- 143 time services on the Internet and other network services. 145 2 RTP Use Scenarios 147 The following sections describe some aspects of the use of RTP. The 148 examples were chosen to illustrate the basic operation of 149 applications using RTP, not to limit what RTP may be used for. In 150 these examples, RTP is carried on top of IP and UDP, and follows the 151 conventions established by the profile for audio and video specified 152 in the companion Internet-Draft draft-ietf-avt-profile 154 2.1 Simple Multicast Audio Conference 156 A working group of the IETF meets to discuss the latest protocol 157 draft, using the IP multicast services of the Internet for voice 158 communications. Through some allocation mechanism the working group 159 chair obtains a multicast group address and pair of ports. One port 160 is used for audio data, and the other is used for control (RTCP) 161 packets. This address and port information is distributed to the 162 intended participants. If privacy is desired, the data and control 163 packets may be encrypted as specified in Section 9.1, in which case 164 an encryption key must also be generated and distributed. The exact 165 details of these allocation and distribution mechanisms are beyond 166 the scope of RTP. 168 The audio conferencing application used by each conference 169 participant sends audio data in small chunks of, say, 20 ms duration. 170 Each chunk of audio data is preceded by an RTP header; RTP header and 171 data are in turn contained in a UDP packet. The RTP header indicates 172 what type of audio encoding (such as PCM, ADPCM or LPC) is contained 173 in each packet so that senders can change the encoding during a 174 conference, for example, to accommodate a new participant that is 175 connected through a low-bandwidth link or react to indications of 176 network congestion. 178 The Internet, like other packet networks, occasionally loses and 179 reorders packets and delays them by variable amounts of time. To cope 180 with these impairments, the RTP header contains timing information 181 and a sequence number that allow the receivers to reconstruct the 182 timing produced by the source, so that in this example, chunks of 183 audio are contiguously played out the speaker every 20 ms. This 184 timing reconstruction is performed separately for each source of RTP 185 packets in the conference. The sequence number can also be used by 186 the receiver to estimate how many packets are being lost. 188 Since members of the working group join and leave during the 189 conference, it is useful to know who is participating at any moment 190 and how well they are receiving the audio data. For that purpose, 191 each instance of the audio application in the conference periodically 192 multicasts a reception report plus the name of its user on the RTCP 193 (control) port. The reception report indicates how well the current 194 speaker is being received and may be used to control adaptive 195 encodings. In addition to the user name, other identifying 196 information may also be included subject to control bandwidth limits. 197 A site sends the RTCP BYE packet (Section 6.5) when it leaves the 198 conference. 200 2.2 Audio and Video Conference 202 If both audio and video media are used in a conference, they are 203 transmitted as separate RTP sessions RTCP packets are transmitted for 204 each medium using two different UDP port pairs and/or multicast 205 addresses. There is no direct coupling at the RTP level between the 206 audio and video sessions, except that a user participating in both 207 sessions should use the same distinguished (canonical) name in the 208 RTCP packets for both so that the sessions can be associated. 210 One motivation for this separation is to allow some participants in 211 the conference to receive only one medium if they choose. Further 212 explanation is given in Section 5.2. Despite the separation, 213 synchronized playback of a source's audio and video can be achieved 214 using timing information carried in the RTCP packets for both 215 sessions. 217 2.3 Mixers and Translators 219 So far, we have assumed that all sites want to receive media data in 220 the same format. However, this may not always be appropriate. 221 Consider the case where participants in one area are connected 222 through a low-speed link to the majority of the conference 223 participants who enjoy high-speed network access. Instead of forcing 224 everyone to use a lower-bandwidth, reduced-quality audio encoding, an 225 RTP-level relay called a mixer may be placed near the low-bandwidth 226 area. This mixer resynchronizes incoming audio packets to reconstruct 227 the constant 20 ms spacing generated by the sender, mixes these 228 reconstructed audio streams into a single stream, translates the 229 audio encoding to a lower-bandwidth one and forwards the lower- 230 bandwidth packet stream across the low-speed link. These packets 231 might be unicast to a single recipient or multicast on a different 232 address to multiple recipients. The RTP header includes a means for 233 mixers to identify the sources that contributed to a mixed packet so 234 that correct talker indication can be provided at the receivers. 236 Some of the intended participants in the audio conference may be 237 connected with high bandwidth links but might not be directly 238 reachable via IP multicast. For example, they might be behind an 239 application-level firewall that will not let any IP packets pass. For 240 these sites, mixing may not be necessary, in which case another type 241 of RTP-level relay called a translator may be used. Two translators 242 are installed, one on either side of the firewall, with the outside 243 one funneling all multicast packets received through a secure 244 connection to the translator inside the firewall. The translator 245 inside the firewall sends them again as multicast packets to a 246 multicast group restricted to the site's internal network. 248 Mixers and translators may be designed for a variety of purposes. An 249 example is a video mixer that scales the images of individual people 250 in separate video streams and composites them into one video stream 251 to simulate a group scene. Other examples of translation include the 252 connection of a group of hosts speaking only IP/UDP to a group of 253 hosts that understand only ST-II, or the packet-by-packet encoding 254 translation of video streams from individual sources without 255 resynchronization or mixing. Details of the operation of mixers and 256 translators are given in Section 7. 258 3 Definitions 260 RTP payload: The data transported by RTP in a packet, for example 261 audio samples or compressed video data. The payload format and 262 interpretation are beyond the scope of this document. 264 RTP packet: A data packet consisting of the fixed RTP header, a 265 possibly empty list of contributing sources (see below), and the 266 payload data. Some underlying protocols may require an 267 encapsulation of the RTP packet to be defined. Typically one 268 packet of the underlying protocol contains a single RTP packet, 269 but several RTP packets may be contained if permitted by the 270 encapsulation method (see Section 10). 272 RTCP packet: A control packet consisting of a fixed header part 273 similar to that of RTP data packets, followed by structured 274 elements that vary depending upon the RTCP packet type. The 275 formats are defined in Section 6. Typically, multiple RTCP 276 packets are sent together as a compound RTCP packet in a single 277 packet of the underlying protocol; this is enabled by the length 278 field in the fixed header of each RTCP packet. 280 Port: The "abstraction that transport protocols use to distinguish 281 among multiple destinations within a given host computer. TCP/IP 282 protocols identify ports using small positive integers." [3] The 283 transport selectors (TSEL) used by the OSI transport layer are 284 equivalent to ports. RTP depends upon the lower-layer protocol 285 to provide some mechanism such as ports to multiplex the RTP and 286 RTCP packets of a session. 288 Transport address: The combination of a network address and port that 289 identifies a transport-level endpoint, for example an IP address 290 and a UDP port. Packets are transmitted from a source transport 291 address to a destination transport address. 293 RTP session: The association among a set of participants 294 communicating with RTP. For each participant, the session is 295 defined by a particular pair of destination transport addresses 296 (one network address plus a port pair for RTP and RTCP). The 297 destination transport address pair may be common for all 298 participants, as in the case of IP multicast, or may be 299 different for each, as in the case of individual unicast network 300 addresses plus a common port pair. In a multimedia session, 301 each medium is carried in a separate RTP session with its own 302 RTCP packets. The multiple RTP sessions are distinguished by 303 different port number pairs and/or different multicast 304 addresses. 306 Synchronization source (SSRC): The source of a stream of RTP packets, 307 identified by a 32-bit numeric SSRC identifier carried in the 308 RTP header so as not to be dependent upon the network address. 309 All packets from a synchronization source form part of the same 310 timing and sequence number space, so a receiver groups packets 311 by synchronization source for playback. Examples of 312 synchronization sources include the sender of a stream of 313 packets derived from a signal source such as a microphone or a 314 camera, or an RTP mixer (see below). A synchronization source 315 may change its data format, e.g., audio encoding, over time. The 316 SSRC identifier is a randomly chosen value meant to be globally 317 unique within a particular RTP session (see Section 8). A 318 participant need not use the same SSRC identifier for all the 319 RTP sessions in a multimedia session; the binding of the SSRC 320 identifiers is provided through RTCP (see Section 6.4.1). If a 321 participant generates multiple streams in one RTP session, for 322 example from separate video cameras, each must be identified as 323 a different SSRC. 325 Contributing source (CSRC): A source of a stream of RTP packets that 326 has contributed to the combined stream produced by an RTP mixer 327 (see below). The mixer inserts a list of the SSRC identifiers of 328 the sources that contributed to the generation of a particular 329 packet into the RTP header of that packet. This list is called 330 the CSRC list. An example application is audio conferencing 331 where a mixer indicates all the talkers whose speech was 332 combined to produce the outgoing packet, allowing the receiver 333 to indicate the current talker, even though all the audio 334 packets contain the same SSRC identifier (that of the mixer). 336 End system: An application that generates the content to be sent in 337 RTP packets and/or consumes the content of received RTP packets. 338 An end system can act as one or more synchronization sources in 339 a particular RTP session, but typically only one. 341 Mixer: An intermediate system that receives RTP packets from one or 342 more sources, possibly changes the data format, combines the 343 packets in some manner and then forwards a new RTP packet. Since 344 the timing among multiple input sources will not generally be 345 synchronized, the mixer will make timing adjustments among the 346 streams and generate its own timing for the combined stream. 347 Thus, all data packets originating from a mixer will be 348 identified as having the mixer as their synchronization source. 350 Translator: An intermediate system that forwards RTP packets with 351 their synchronization source identifier intact. Examples of 352 translators include devices that convert encodings without 353 mixing, replicators from multicast to unicast, and application- 354 level filters in firewalls. 356 Monitor: An application that receives RTCP packets sent by 357 participants in an RTP session, in particular the reception 358 reports, and estimates the current quality of service for 359 distribution monitoring, fault diagnosis and long-term 360 statistics. The monitor function is likely to be built into the 361 application(s) participating in the session, but may also be a 362 separate application that does not otherwise participate and 363 does not send or receive the RTP data packets. These are called 364 third party monitors. 366 Non-RTP means: Protocols and mechanisms that may be needed in 367 addition to RTP to provide a usable service. In particular, for 368 multimedia conferences, a conference control application may 369 distribute multicast addresses and keys for encryption, 370 negotiate the encryption algorithm to be used, and define 371 dynamic mappings between RTP payload type values and the payload 372 formats they represent for formats that do not have a predefined 373 payload type value. For simple applications, electronic mail or 374 a conference database may also be used. The specification of 375 such protocols and mechanisms is outside the scope of this 376 document. 378 4 Byte Order, Alignment, and Time Format 380 All integer fields are carried in network byte order, that is, most 381 significant byte (octet) first. This byte order is commonly known as 382 big-endian. The transmission order is described in detail in [4]. 383 Unless otherwise noted, numeric constants are in decimal (base 10). 385 All header data is aligned to its natural length, i.e., 16-bit fields 386 are aligned on even offsets, 32-bit fields are aligned at offsets 387 divisible by four, etc. Octets designated as padding have the value 388 zero. 390 Wallclock time (absolute time) is represented using the timestamp 391 format of the Network Time Protocol (NTP), which is in seconds 392 relative to 0h UTC on 1 January 1900 [5]. The full resolution NTP 393 timestamp is a 64-bit unsigned fixed-point number with the integer 394 part in the first 32 bits and the fractional part in the last 32 395 bits. In some fields where a more compact representation is 396 appropriate, only the middle 32 bits are used; that is, the low 16 397 bits of the integer part and the high 16 bits of the fractional part. 398 The high 16 bits of the integer part must be determined 399 independently. 401 5 RTP Data Transfer Protocol 403 5.1 RTP Fixed Header Fields 405 The RTP header has the following format: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |V=2|P|X| CC |M| PT | sequence number | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | timestamp | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | synchronization source (SSRC) identifier | 415 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 416 | contributing source (CSRC) identifiers | 417 | .... | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 The first twelve octets are present in every RTP packet, while the 421 list of CSRC identifiers is present only when inserted by a mixer. 422 The fields have the following meaning: 424 version (V): 2 bits 425 This field identifies the version of RTP. The version defined by 426 this specification is two (2). (The value 1 is used by the first 427 draft version of RTP and the value 0 is used by the protocol 428 initially implemented in the "vat" audio tool.) 430 padding (P): 1 bit 431 If the padding bit is set, the packet contains one or more 432 additional padding octets at the end which are not part of the 433 payload. The last octet of the padding contains a count of how 434 many padding octets should be ignored. Padding may be needed by 435 some encryption algorithms with fixed block sizes or for 436 carrying several RTP packets in a lower-layer protocol data 437 unit. 439 extension (X): 1 bit 440 If the extension bit is set, the fixed header is followed by 441 exactly one header extension, with a format defined in Section 442 5.3.1. 444 CSRC count (CC): 4 bits 445 The CSRC count contains the number of CSRC identifiers that 446 follow the fixed header. 448 marker (M): 1 bit 449 The interpretation of the marker is defined by a profile. It is 450 intended to allow significant events such as frame boundaries to 451 be marked in the packet stream. A profile may define additional 452 marker bits or specify that there is no marker bit by changing 453 the number of bits in the payload type field (see Section 5.3). 455 payload type (PT): 7 bits 456 This field identifies the format of the RTP payload and 457 determines its interpretation by the application. A profile 458 specifies a default static mapping of payload type codes to 459 payload formats. Additional payload type codes may be defined 460 dynamically through non-RTP means (see Section 3). An initial 461 set of default mappings for audio and video is specified in the 462 companion profile Internet-Draft draft-ietf-avt-profile , and 463 may be extended in future editions of the Assigned Numbers RFC 464 [6]. An RTP sender emits a single RTP payload type at any given 465 time; this field is not intended for multiplexing separate media 466 streams (see Section 5.2). 468 sequence number: 16 bits 469 The sequence number increments by one for each RTP data packet 470 sent, and may be used by the receiver to detect packet loss and 471 to restore packet sequence. The initial value of the sequence 472 number is random (unpredictable) to make known-plaintext attacks 473 on encryption more difficult, even if the source itself does not 474 encrypt, because the packets may flow through a translator that 475 does. Techniques for choosing unpredictable numbers are 476 discussed in [7]. 478 timestamp: 32 bits 479 The timestamp reflects the sampling instant of the first octet 480 in the RTP data packet. The sampling instant must be derived 481 from a clock that increments monotonically and linearly in time 482 to allow synchronization and jitter calculations (see Section 483 6.3.1). The resolution of the clock must be sufficient for the 484 desired synchronization accuracy and for measuring packet 485 arrival jitter (one tick per video frame is typically not 486 sufficient). The clock frequency is dependent on the format of 487 data carried as payload and is specified statically in the 488 profile or payload format specification that defines the format, 489 or may be specified dynamically for payload formats defined 490 through non-RTP means. If RTP packets are generated 491 periodically, the nominal sampling instant as determined from 492 the sampling clock is to be used, not a reading of the system 493 clock. As an example, for fixed-rate audio the timestamp clock 494 would likely increment by one for each sampling period. If an 495 audio application reads blocks covering 160 sampling periods 496 from the input device, the timestamp would be increased by 160 497 for each such block, regardless of whether the block is 498 transmitted in a packet or dropped as silent. 500 The initial value of the timestamp is random, as for the sequence 501 number. Several consecutive RTP packets may have equal timestamps if 502 they are (logically) generated at once, e.g., belong to the same 503 video frame. Consecutive RTP packets may contain timestamps that are 504 not monotonic if the data is not transmitted in the order it was 505 sampled, as in the case of MPEG interpolated video frames. (The 506 sequence numbers of the packets as transmitted will still be 507 monotonic.) 509 SSRC: 32 bits 510 The SSRC field identifies the synchronization source. This 511 identifier is chosen randomly, with the intent that no two 512 synchronization sources within the same RTP session will have 513 the same SSRC identifier. An example algorithm for generating a 514 random identifier is presented in Appendix A.6. Although the 515 probability of multiple sources choosing the same identifier is 516 low, all RTP implementations must be prepared to detect and 517 resolve collisions. Section 8 describes the probability of 518 collision along with a mechanism for resolving collisions and 519 detecting RTP-level forwarding loops based on the uniqueness of 520 the SSRC identifier. If a source changes its source transport 521 address, it must also choose a new SSRC identifier to avoid 522 being interpreted as a looped source. 524 CSRC list: 0 to 15 items, 32 bits each 525 The CSRC list identifies the contributing sources for the 526 payload contained in this packet. The number of identifiers is 527 given by the CC field. If there are more than 15 contributing 528 sources, only 15 may be identified. CSRC identifiers are 529 inserted by mixers, using the SSRC identifiers of contributing 530 sources. For example, for audio packets the SSRC identifiers of 531 all sources that were mixed together to create a packet are 532 listed, allowing correct talker indication at the receiver. 534 5.2 Multiplexing RTP Sessions 536 For efficient protocol processing, the number of multiplexing points 537 should be minimized, as described in the integrated layer processing 538 design principle [1]. In RTP, multiplexing is provided by the 539 destination transport address (network address and port number) which 540 define an RTP session. For example, in a teleconference composed of 541 audio and video media encoded separately, each medium should be 542 carried in a separate RTP session with its own destination transport 543 address. It is not intended that the audio and video be carried in a 544 single RTP session and demultiplexed based on the payload type or 545 SSRC fields. Interleaving packets with different payload types but 546 using the same SSRC would introduce several problems: 548 1. If one payload type were switched during a session, there 549 would be no general means to identify which of the old 550 values the new one replaced. 552 2. An SSRC is defined to identify a single timing and sequence 553 number space. Interleaving multiple payload types would 554 require different timing spaces if the media clock rates 555 differ and would require different sequence number spaces 556 to tell which payload type suffered packet loss. 558 3. The RTCP sender and receiver reports (see Section 6.3) can 559 only describe one timing and sequence number space per SSRC 560 and do not carry a payload type field. 562 4. An RTP mixer would not be able to combine interleaved 563 streams of incompatible media into one stream. 565 5. Carrying multiple media in one RTP session precludes: the 566 use of different network paths or network resource 567 allocations if appropriate; reception of a subset of the 568 media if desired, for example just audio if video would 569 exceed the available bandwidth; and receiver 570 implementations that use separate processes for the 571 different media, whereas using separate RTP sessions 572 permits either single- or multiple-process implementations. 574 Using a different SSRC for each medium but sending them in the same 575 RTP session would avoid the first three problems but not the last 576 two. 578 5.3 Profile-Specific Modifications to the RTP Header 580 The existing RTP data packet header is believed to be complete for 581 the set of functions required in common across all the application 582 classes that RTP might support. However, in keeping with the ALF 583 design principle, the header may be tailored through modifications or 584 additions defined in a profile specification while still allowing 585 profile-independent monitoring and recording tools to function. 587 o The marker bit and payload type field carry profile-specific 588 information, but they are allocated in the fixed header since 589 many applications are expected to need them and might otherwise 590 have to add another 32-bit word just to hold them. The octet 591 containing these fields may be redefined by a profile to suit 592 different requirements, for example with a more or fewer marker 593 bits. If there are any marker bits, one should be located in 594 the most significant bit of the octet since profile-independent 595 monitors may be able to observe a correlation between packet 596 loss patterns and the marker bit. 598 o Additional information that is required for a particular 599 payload format, such as a video encoding, should be carried in 600 the payload section of the packet. This might be in a header 601 that is always present at the start of the payload section, or 602 might be indicated by a reserved value in the data pattern. 604 o If a particular class of applications needs additional 605 functionality independent of payload format, the profile under 606 which those applications operate should define additional fixed 607 fields to follow immediately after the SSRC field of the 608 existing fixed header. Those applications will be able to 609 quickly and directly access the additional fields while 610 profile-independent monitors or recorders can still process the 611 RTP packets by interpreting only the first twelve octets. 613 If it turns out that additional functionality is needed in common 614 across all profiles, then a new version of RTP should be defined to 615 make a permanent change to the fixed header. 617 5.3.1 RTP Header Extension 619 An extension mechanism is provided to allow individual 620 implementations to experiment with new payload-format-independent 621 functions that require additional information to be carried in the 622 RTP data packet header. This mechanism is designed so that the header 623 extension may be ignored by other interoperating implementations that 624 have not been extended. 626 Note that this header extension is intended only for limited use. 627 Most potential uses of this mechanism would be better done another 628 way, using the methods described in the previous section. For 629 example, a profile-specific extension to the fixed header is less 630 expensive to process because it is not conditional nor in a variable 631 location. Additional information required for a particular payload 632 format should not use this header extension, but should be carried in 633 the payload section of the packet. 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | defined by profile | length | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | header extension | 641 | .... | 643 If the X bit in the RTP header is one, a variable-length header 644 extension is appended to the RTP header, following the CSRC list if 645 present. The header extension contains a 16-bit length field that 646 counts the number of 32-bit words in the extension, excluding the 647 four-octet extension header (therefore zero is a valid length). Only 648 a single extension may be appended to the RTP data header. To allow 649 multiple interoperating implementations to each experiment 650 independently with different header extensions, or to allow a 651 particular implementation to experiment with more than one type of 652 header extension, the first 16 bits of the header extension are left 653 open for distinguishing identifiers or parameters. The format of 654 these 16 bits is to be defined by the profile specification under 655 which the implementations are operating. This RTP specification does 656 not define any header extensions itself. 658 6 RTP Control Protocol -- RTCP 660 The RTP control protocol (RTCP) is based on the periodic transmission 661 of control packets to all participants in the session, using the same 662 distribution mechanism as the data packets. The underlying protocol 663 must provide multiplexing of the data and control packets, for 664 example using separate port numbers with UDP. RTCP performs four 665 functions: 667 1. The primary function is to provide feedback on the quality 668 of the data distribution. This is an integral part of the 669 RTP's role as a transport protocol and is related to the 670 flow and congestion control functions of other transport 671 protocols. The feedback may be directly useful for control 672 of adaptive encodings [8,9], but experiments with IP 673 multicasting have shown that it is also critical to get 674 feedback from the receivers to diagnose faults in the 675 distribution. Sending reception feedback reports to all 676 participants allows one who is observing problems to 677 evaluate whether those problems are local or global. With a 678 distribution mechanism like IP multicast, it is also 679 possible for an entity such as a network service provider 680 who is not otherwise involved in the session to receive the 681 feedback information and act as a third-party monitor to 682 diagnose network problems. This feedback function is 683 performed by the RTCP sender and receiver reports, 684 described below in Section 6.3. 686 2. RTCP carries a persistent transport-level identifier for an 687 RTP source called the canonical name or CNAME, Section 688 6.4.1. Since the SSRC identifier may change if a conflict 689 is discovered or a program is restarted, receivers require 690 the CNAME to keep track of each participant. Receivers also 691 require the CNAME to associate multiple data streams from a 692 given participant in a set of related RTP sessions, for 693 example to synchronize audio and video. 695 3. The first two functions require that all participants send 696 RTCP packets, therefore the rate must be controlled in 697 order for RTP to scale up to a large number of 698 participants. By having each participant send its control 699 packets to all the others, each can independently observe 700 the number of participants. This number is used to 701 calculate the rate at which the packets are sent, as 702 explained in Section 6.2. 704 4. A fourth, optional function is to convey minimal session 705 control information, for example participant identification 706 to be displayed in the user interface. This is most likely 707 to be useful in "loosely controlled" sessions where 708 participants enter and leave without membership control or 709 parameter negotiation. RTCP serves as a convenient channel 710 to reach all the participants, but it is not necessarily 711 expected to support all the control communication 712 requirements of an application. A higher-level session 713 control protocol, which is beyond the scope of this 714 document, may be needed. 716 Functions 1-3 are mandatory when RTP is used in the IP multicast 717 environment, and are recommended for all environments. RTP 718 application designers are advised to avoid mechanisms that can only 719 work in unicast mode and will not scale to larger numbers. 721 6.1 RTCP Packet Format 723 This specification defines several RTCP packet types to carry a 724 variety of control information: 726 SR: Sender report, for transmission and reception statistics from 727 participants that are active senders 729 RR: Receiver report, for reception statistics from participants that 730 are not active senders 732 SDES: Source description items, including CNAME 734 BYE: Indicates end of participation 736 APP: Application specific functions 738 Each RTCP packet begins with a fixed part similar to that of RTP data 739 packets, followed by structured elements that may be of variable 740 length according to the packet type but always end on a 32-bit 741 boundary. The alignment requirement and a length field in the fixed 742 part are included to make RTCP packets "stackable". Multiple RTCP 743 packets may be concatenated without any intervening separators to 744 form a compound RTCP packet that is sent in a single packet of the 745 lower layer protocol, for example UDP. There is no explicit count of 746 individual RTCP packets in the compound packet since the lower layer 747 protocols are expected to provide an overall length to determine the 748 end of the compound packet. 750 Each individual RTCP packet in the compound packet may be processed 751 independently with no requirements upon the order or combination of 752 packets. However, in order to perform the functions of the protocol, 753 the following constraints are imposed: 755 o Reception statistics (in SR or RR) should be sent as often as 756 bandwidth constraints will allow to maximize the resolution of 757 the statistics, therefore each periodically transmitted 758 compound RTCP packet should include a report packet. 760 o New receivers need to receive the CNAME for a source as soon 761 as possible to identify the source and to begin associating 762 media for purposes such as lip-sync, so each compound RTCP 763 packet should also include the SDES CNAME. 765 o The number of packet types that may appear first in the 766 compound packet should be limited to increase the number of 767 constant bits in the first word and the probability of 768 successfully validating RTCP packets against misaddressed RTP 769 data packets or other unrelated packets. 771 Thus, all RTCP packets must be sent in a compound packet of at least 772 two individual packets, with the following format recommended: 774 Encryption prefix: If and only if the compound packet is to be 775 encrypted, it is prefixed by a random 32-bit quantity redrawn 776 for every compound packet transmitted. 778 SR or RR: The first RTCP packet in the compound packet must always 779 be a report packet to facilitate header validation as described 780 in Appendix A.2. This is true even if no data has been sent nor 781 received, in which case an empty RR is sent, and even if the 782 only other RTCP packet in the compound packet is a BYE. 784 Additional RRs: If the number of sources for which reception 785 statistics are being reported exceeds 31, the number that will 786 fit into one SR or RR packet, then additional RR packets should 787 follow the initial report packet. 789 SDES: An SDES packet containing a CNAME item must be included in 790 each compound RTCP packet. Other source description items may 791 optionally be included if required by a particular application, 792 subject to bandwidth constraints (see Section 6.2.2). 794 BYE or APP: Other RTCP packet types, including those yet to be 795 defined, may follow in any order, except that BYE should be the 796 last packet sent with a given SSRC/CSRC. Packet types may appear 797 more than once. 799 It is advisable for translators and mixers to combine individual RTCP 800 packets from the multiple sources they are forwarding into one 801 compound packet whenever feasible in order to amortize the packet 802 overhead (see Section 7). An example RTCP compound packet as might be 803 produced by a mixer is shown in Fig. 1. If the overall length of a 804 compound packet would exceed the maximum transmission unit (MTU) of 805 the network path, it may be segmented into multiple shorter compound 806 packets to be transmitted in separate packets of the underlying 807 protocol. Note that each of the compound packets must begin with an 808 SR or RR packet. 810 An implementation may ignore incoming RTCP packets with types unknown 811 to it. Additional RTCP packet types may be registered with the 812 Internet Assigned Numbers Authority (IANA). 814 6.2 RTCP Transmission Interval 815 if encrypted: random 32-bit integer 816 | 817 |[------- packet -------][----------- packet -----------][-packet-] 818 | 819 | receiver reports chunk chunk 820 V item item item item 821 -------------------------------------------------------------------- 822 |R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why] 823 |R[ |# report # 1 # 2 ][ |# |# ][ ## ] 824 |R[ |# # # ][ |# |# ][ ## ] 825 |R[ |# # # ][ |# |# ][ ## ] 826 -------------------------------------------------------------------- 827 |<------------------ UDP packet (compound packet) --------------->| 829 #: SSRC/CSRC 831 Figure 1: Example of an RTCP compound packet 833 RTP is designed to allow an application to scale automatically over 834 session sizes ranging from a few participants to thousands. For 835 example, in an audio conference the data traffic is inherently self- 836 limiting because only one or two people will speak at a time, so with 837 multicast distribution the data rate on any given link remains 838 relatively constant independent of the number of participants. 839 However, the control traffic is not self-limiting. If the reception 840 reports from each participant were sent at a constant rate, the 841 control traffic would grow linearly with the number of participants. 842 Therefore, the rate must be scaled down. 844 For each session, it is assumed that the data traffic is subject to 845 an aggregate limit called the "session bandwidth" to be divided among 846 the participants. This bandwidth might be reserved and the limit 847 enforced by the network, or it might just be a reasonable share. The 848 session bandwidth may be chosen based or some cost or a priori 849 knowledge of the available network bandwidth for the session. It is 850 somewhat independent of the media encoding, but the encoding choice 851 may be limited by the session bandwidth. The session bandwidth 852 parameter is expected to be supplied by a session management 853 application when it invokes a media application, but media 854 applications may also set a default based on the single-sender data 855 bandwidth for the encoding selected for the session. The application 856 may also enforce bandwidth limits based on multicast scope rules or 857 other criteria. 859 Bandwidth calculations for control and data traffic include lower- 860 layer transport and network protocols (e.g., UDP and IP) since that 861 is what the resource reservation system would need to know. The 862 application can also be expected to know which of these protocols are 863 in use. Link level headers are not included in the calculation since 864 the packet will be encapsulated with different link level headers as 865 it travels. 867 The control traffic should be limited to a small and known fraction 868 of the session bandwidth: small so that the primary function of the 869 transport protocol to carry data is not impaired; known so that the 870 control traffic can be included in the bandwidth specification given 871 to a resource reservation protocol, and so that each participant can 872 independently calculate its share. It is suggested that the fraction 873 of the session bandwidth allocated to RTCP be fixed at 5%. While the 874 value of this and other constants in the interval calculation is not 875 critical, all participants in the session must use the same values so 876 the same interval will be calculated. Therefore, these constants 877 should be fixed for a particular profile. 879 The algorithm described in Appendix A.7 was designed to meet the 880 goals outlined above. It calculates the interval between sending 881 compound RTCP packets to divide the allowed control traffic bandwidth 882 among the participants. This allows an application to provide fast 883 response for small sessions where, for example, identification of all 884 participants is important, yet automatically adapt to large sessions. 885 The algorithm incorporates the following characteristics: 887 o Senders are collectively allocated at least 1/4 of the control 888 traffic bandwidth so that in sessions with a large number of 889 receivers but a small number of senders, newly joining 890 participants will more quickly receive the CNAME for the 891 sending sites. 893 o The calculated interval between RTCP packets is required to be 894 greater than a minimum of 5 seconds to avoid having bursts of 895 RTCP packets exceed the allowed bandwidth when the number of 896 participants is small and the traffic isn't smoothed according 897 to the law of large numbers. 899 o The interval between RTCP packets is varied randomly over the 900 range [0.5,1.5] times the calculated interval to avoid 901 unintended synchronization of all participants [10]. The first 902 RTCP packet sent after joining a session is also delayed by a 903 random variation of half the minimum RTCP interval in case the 904 application is started at multiple sites simultaneously, for 905 example as initiated by a session announcement. 907 o A dynamic estimate of the average compound RTCP packet size is 908 calculated, including all those received and sent, to 909 automatically adapt to changes in the amount of control 910 information carried. 912 This algorithm may be used for sessions in which all participants are 913 allowed to send. In that case, the session bandwidth parameter is the 914 product of the individual sender's bandwidth times the number of 915 participants, and the RTCP bandwidth is 5% of that. 917 6.2.1 Maintaining the number of session members 919 Calculation of the RTCP packet interval depends upon an estimate of 920 the number of sites participating in the session. New sites are added 921 to the count when they are heard, and an entry for each is created in 922 a table indexed by the SSRC or CSRC identifier (see Section 8.2) to 923 keep track of them. New entries may not be considered valid until 924 multiple packets carrying the new SSRC have been received (see 925 Appendix A.1). Entries may be deleted from the table when an RTCP BYE 926 packet with the corresponding SSRC identifier is received. 928 A participant may mark another site inactive, or delete it if not yet 929 valid, if no RTP or RTCP packet has been received for a small number 930 of RTCP report intervals (5 is suggested). This provides some 931 robustness against packet loss. All sites must calculate roughly the 932 same value for the RTCP report interval in order for this timeout to 933 work properly. 935 Once a site has been validated, then if it is later marked inactive 936 the state for that site should still be retained and the site should 937 continue to be counted in the total number of sites sharing RTCP 938 bandwidth for a period long enough to span typical network 939 partitions. This is to avoid excessive traffic, when the partition 940 heals, due to an RTCP report interval that is too small. A timeout of 941 30 minutes is suggested. Note that this is still larger than 5 times 942 the largest value to which the RTCP report interval is expected to 943 usefully scale, about 2 to 5 minutes. 945 6.2.2 Allocation of source description bandwidth 947 This specification defines several source description (SDES) items in 948 addition to the mandatory CNAME item, such as NAME (personal name) 949 and EMAIL (email address). It also provides a means to define new 950 application-specific RTCP packet types. Applications should exercise 951 caution in allocating control bandwidth to this additional 952 information because it will slow down the rate at which reception 953 reports and CNAME are sent, thus impairing the performance of the 954 protocol. It is recommended that no more than 20% of the RTCP 955 bandwidth allocated to a single participant be used to carry the 956 additional information. Furthermore, it is not intended that all 957 SDES items should be included in every application. Those that are 958 included should be assigned a fraction of the bandwidth according to 959 their utility. Rather than estimate these fractions dynamically, it 960 is recommended that the percentages be translated statically into 961 report interval counts based on the typical length of an item. 963 For example, an application may be designed to send only CNAME, NAME 964 and EMAIL and not any others. NAME might be given much higher 965 priority than EMAIL because the NAME would be displayed continuously 966 in the application's user interface, whereas EMAIL would be displayed 967 only when requested. At every RTCP interval, an RR packet and an SDES 968 packet with the CNAME item would be sent. For a small session 969 operating at the minimum interval, that would be every 5 seconds on 970 the average. Every third interval (15 seconds), one extra item would 971 be included in the SDES packet. Seven out of eight times this would 972 be the NAME item, and every eighth time (2 minutes) it would be the 973 EMAIL item. 975 When multiple applications operate in concert using cross-application 976 binding through a common CNAME for each participant, for example in a 977 multimedia conference composed of an RTP session for each medium, the 978 additional SDES information might be sent in only one RTP session. 979 The other sessions would carry only the CNAME item. 981 6.3 Sender and Receiver Reports 983 RTP receivers provide reception quality feedback using RTCP report 984 packets which may take one of two forms depending upon whether or not 985 the receiver is also a sender. The only difference between the sender 986 report (SR) and receiver report (RR) forms, besides the packet type 987 code, is that the sender report includes a 20-byte sender information 988 section for use by active senders. The SR is issued if a site has 989 sent any data packets during the interval since issuing the last 990 report or the previous one, otherwise the RR is issued. 992 Both the SR and RR forms include zero or more reception report 993 blocks, one for each of the synchronization sources from which this 994 receiver has received RTP data packets since the last report. Reports 995 are not issued for contributing sources listed in the CSRC list. Each 996 reception report block provides statistics about the data received 997 from the particular source indicated in that block. Since a maximum 998 of 31 reception report blocks will fit in an SR or RR packet, 999 additional RR packets may be stacked after the initial SR or RR 1000 packet as needed to contain the reception reports for all sources 1001 heard during the interval since the last report. 1003 The next sections define the formats of the two reports, how they may 1004 be extended in a profile-specific manner if an application requires 1005 additional feedback information, and how the reports may be used. 1006 Details of reception reporting by translators and mixers is given in 1007 Section 7. 1009 6.3.1 SR: Sender report RTCP packet 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 |V=2|P| RC | PT=SR=200 | length | header 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | SSRC of sender | 1017 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1018 | NTP timestamp, most significant word | sender 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info 1020 | NTP timestamp, least significant word | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | RTP timestamp | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | sender's packet count | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | sender's octet count | 1027 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1028 | SSRC_1 (SSRC of first source) | report 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1030 | fraction lost | cumulative number of packets lost | 1 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | extended highest sequence number received | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | interarrival jitter | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | last SR (LSR) | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | delay since last SR (DLSR) | 1039 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1040 | SSRC_2 (SSRC of second source) | report 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1042 : ... : 2 1043 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1044 | profile-specific extensions | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 The sender report packet consists of three sections, possibly 1048 followed by a fourth profile-specific extension section if defined. 1049 The first section, the header, is 8 octets long. The fields have the 1050 following meaning: 1052 version (V): 2 bits 1053 Identifies the version of RTP, which is the same in RTCP packets 1054 as in RTP data packets. The version defined by this 1055 specification is two (2). 1057 padding (P): 1 bit 1058 If the padding bit is set, this RTCP packet contains some 1059 additional padding octets at the end which are not part of the 1060 control information. The last octet of the padding is a count of 1061 how many padding octets should be ignored. Padding may be needed 1062 by some encryption algorithms with fixed block sizes. In a 1063 compound RTCP packet, padding should only be required on the 1064 last individual packet because the compound packet is encrypted 1065 as a whole. 1067 reception report count (RC): 5 bits 1068 The number of reception report blocks contained in this packet. 1069 A value of zero is valid. 1071 packet type (PT): 8 bits 1072 Contains the constant 200 to identify this as an RTCP SR packet. 1074 length: 16 bits 1075 The length of this RTCP packet in 32-bit words minus one, 1076 including the header and any padding. (The offset of one makes 1077 zero a valid length and avoids a possible infinite loop in 1078 scanning a compound RTCP packet, while counting 32-bit words 1079 avoids a validity check for a multiple of 4.) 1081 SSRC: 32 bits 1082 The synchronization source identifier for the originator of this 1083 SR packet. 1085 The second section, the sender information, is 20 octets long and is 1086 present in every sender report packet. It summarizes the data 1087 transmissions from this sender. The fields have the following 1088 meaning: 1090 NTP timestamp: 64 bits 1091 Indicates the wallclock time when this report was sent so that 1092 it may be used in combination with timestamps returned in 1093 reception reports from other receivers to measure round-trip 1094 propagation to those receivers. Receivers should expect that the 1095 measurement accuracy of the timestamp may be limited to far less 1096 than the resolution of the NTP timestamp. The measurement 1097 uncertainty of the timestamp is not indicated as it may not be 1098 known. A sender that can keep track of elapsed time but has no 1099 notion of wallclock time may use the elapsed time since joining 1100 the session instead. This is assumed to be less than 68 years, 1101 so the high bit will be zero. It is permissible to use the 1102 sampling clock to estimate elapsed wallclock time. A sender that 1103 has no notion of wallclock or elapsed time may set the NTP 1104 timestamp to zero. 1106 RTP timestamp: 32 bits 1107 Corresponds to the same time as the NTP timestamp (above), but 1108 in the same units and with the same random offset as the RTP 1109 timestamps in data packets. This correspondence may be used for 1110 intra- and inter-media synchronization for sources whose NTP 1111 timestamps are synchronized, and may be used by media- 1112 independent receivers to estimate the nominal RTP clock 1113 frequency. Note that in most cases this timestamp will not be 1114 equal to the RTP timestamp in any adjacent data packet. Rather, 1115 it is calculated from the corresponding NTP timestamp using the 1116 relationship between the RTP timestamp counter and real time as 1117 maintained by periodically checking the wallclock time at a 1118 sampling instant. 1120 sender's packet count: 32 bits 1121 The total number of RTP data packets transmitted by the sender 1122 since starting transmission up until the time this SR packet was 1123 generated. The count is reset if the sender changes its SSRC 1124 identifier. 1126 sender's octet count: 32 bits 1127 The total number of payload octets (i.e., not including header 1128 or padding) transmitted in RTP data packets by the sender since 1129 starting transmission up until the time this SR packet was 1130 generated. The count is reset if the sender changes its SSRC 1131 identifier. This field can be used to estimate the average 1132 payload data rate. 1134 The third section contains zero or more reception report blocks 1135 depending on the number of other sources heard by this sender since 1136 the last report. Each reception report block conveys statistics on 1137 the reception of RTP packets from a single synchronization source. 1138 Receivers do not carry over statistics when a source changes its SSRC 1139 identifier due to a collision. These statistics are: 1141 SSRC_n (source identifier): 32 bits 1142 The SSRC identifier of the source to which the information in 1143 this reception report block pertains. 1145 fraction lost: 8 bits 1146 The fraction of RTP data packets from source SSRC_n lost since 1147 the previous SR or RR packet was sent, expressed as a fixed 1148 point number with the binary point at the left edge of the 1149 field. (That is equivalent to taking the integer part after 1150 multiplying the loss fraction by 256.) This fraction is defined 1151 to be the number of packets lost divided by the number of 1152 packets expected, as defined in the next paragraph. An 1153 implementation is shown in Appendix A.3. If the loss is negative 1154 due to duplicates, the fraction lost is set to zero. Note that a 1155 receiver cannot tell whether any packets were lost after the 1156 last one received, and that there will be no reception report 1157 block issued for a source if all packets from that source sent 1158 during the last reporting interval have been lost. 1160 cumulative number of packets lost: 24 bits 1161 The total number of RTP data packets from source SSRC_n that 1162 have been lost since the beginning of reception. This number is 1163 defined to be the number of packets expected less the number of 1164 packets actually received, where the number of packets received 1165 includes any which are late or duplicates. Thus packets that 1166 arrive late are not counted as lost, and the loss may be 1167 negative if there are duplicates. The number of packets 1168 expected is defined to be the extended last sequence number 1169 received, as defined next, less the initial sequence number 1170 received. This may be calculated as shown in Appendix A.3. 1172 extended highest sequence number received: 32 bits 1173 The low 16 bits contain the highest sequence number received in 1174 an RTP data packet from source SSRC_n, and the most significant 1175 16 bits extend that sequence number with the corresponding count 1176 of sequence number cycles, which may be maintained according to 1177 the algorithm in Appendix A.1. Note that different receivers 1178 within the same session will generate different extensions to 1179 the sequence number if their start times differ significantly. 1181 interarrival jitter: 32 bits 1182 An estimate of the statistical variance of the RTP data packet 1183 interarrival time, measured in timestamp units and expressed as 1184 an unsigned integer. The interarrival jitter J is defined to be 1185 the mean deviation (smoothed absolute value) of the difference D 1186 in packet spacing at the receiver compared to the sender for a 1187 pair of packets. As shown in the equation below, this is 1188 equivalent to the difference in the "relative transit time" for 1189 the two packets; the relative transit time is the difference 1190 between a packet's RTP timestamp and the receiver's clock at the 1191 time of arrival, measured in the same units. 1193 If Si is the RTP timestamp from packet i, and Ri is the time of 1194 arrival in RTP timestamp units for packet i, then for two packets i 1195 and j, D may be expressed as 1196 D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si) 1198 The interarrival jitter is calculated continuously as each data 1199 packet i is received from source SSRC_n, using this difference D for 1200 that packet and the previous packet i-1 in order of arrival (not 1201 necessarily in sequence), according to the formula 1203 J=J+(|D(i-1,i)|-J)/16 1204 Whenever a reception report is issued, the current value of J is 1205 sampled. 1207 The jitter calculation is prescribed here to allow profile- 1208 independent monitors to make valid interpretations of reports coming 1209 from different implementations. This algorithm is the optimal first- 1210 order estimator and the gain parameter 1/16 gives a good noise 1211 reduction ratio while maintaining a reasonable rate of convergence 1212 [11]. A sample implementation is shown in Appendix A.8. 1214 last SR timestamp (LSR): 32 bits 1215 The middle 32 bits out of 64 in the NTP timestamp (as explained 1216 in Section 4) received as part of the most recent RTCP sender 1217 report (SR) packet from source SSRC_n. If no SR has been 1218 received yet, the field is set to zero. 1220 delay since last SR (DLSR): 32 bits 1221 The delay, expressed in units of 1/65536 seconds, between 1222 receiving the last SR packet from source SSRC_n and sending this 1223 reception report block. If no SR packet has been received yet 1224 from SSRC_n, the DLSR field is set to zero. 1226 Let SSRC_r denote the receiver issuing this receiver report. Source 1227 SSRC_n can compute the round propagation delay to SSRC_r by recording 1228 the time A when this reception report block is received. It 1229 calculates the total round-trip time A-LSR using the last SR 1230 timestamp (LSR) field, and then subtracting this field to leave the 1231 round-trip propagation delay as (A- LSR - DLSR). This is illustrated 1232 in Fig. 2. 1234 This may be used as an approximate measure of distance to cluster 1235 receivers, although some links have very asymmetric delays. 1237 6.3.2 RR: Receiver report RTCP packet 1239 [10 Nov 1995 11:33:25.125] [10 Nov 1995 11:33:36.5] 1240 n SR(n) A=b710:8000 (46864.500 s) 1241 ----------------------------------------------------------------> 1242 v ^ 1243 ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s) 1244 ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s) 1245 (3024992016.125 s) v ^ 1246 r v ^ RR(n) 1247 ----------------------------------------------------------------> 1248 |<-DLSR->| 1249 (5.250 s) 1251 A 0xb710:8000 (46864.500 s) 1252 DLSR -0x0005:4000 ( 5.250 s) 1253 LSR -0xb705:2000 (46853.125 s) 1254 ------------------------------- 1255 delay 0x 6:2000 ( 6.125 s) 1257 Figure 2: Example for round-trip time computation 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 |V=2|P| RC | PT=RR=201 | length | header 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | SSRC of packet sender | 1265 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1266 | SSRC_1 (SSRC of first source) | report 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1268 | fraction lost | cumulative number of packets lost | 1 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | extended highest sequence number received | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | interarrival jitter | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | last SR (LSR) | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | delay since last SR (DLSR) | 1277 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1278 | SSRC_2 (SSRC of second source) | report 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 1280 : ... : 2 1281 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1282 | profile-specific extensions | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 The format of the receiver report (RR) packet is the same as that of 1286 the SR packet except that the packet type field contains the constant 1287 201 and the five words of sender information are omitted (these are 1288 the NTP and RTP timestamps and sender's packet and octet counts). The 1289 remaining fields have the same meaning as for the SR packet. 1291 An empty RR packet (RC = 0) is put at the head of a compound RTCP 1292 packet when there is no data transmission or reception to report. 1294 6.3.3 Extending the sender and receiver reports 1296 A profile should define profile- or application-specific extensions 1297 to the sender report and receiver if there is additional information 1298 that should be reported regularly about the sender or receivers. This 1299 method should be used in preference to defining another RTCP packet 1300 type because it requires less overhead: 1302 o fewer octets in the packet (no RTCP header or SSRC field); 1304 o simpler and faster parsing because applications running under 1305 that profile would be programmed to always expect the extension 1306 fields in the directly accessible location after the reception 1307 reports. 1309 If additional sender information is required, it should be included 1310 first in the extension for sender reports, but would not be present 1311 in receiver reports. If information about receivers is to be 1312 included, that data may be structured as an array of blocks parallel 1313 to the existing array of reception report blocks; that is, the number 1314 of blocks would be indicated by the RC field. 1316 6.3.4 Analyzing sender and receiver reports 1318 It is expected that reception quality feedback will be useful not 1319 only for the sender but also for other receivers and third-party 1320 monitors. The sender may modify its transmissions based on the 1321 feedback; receivers can determine whether problems are local, 1322 regional or global; network managers may use profile-independent 1323 monitors that receive only the RTCP packets and not the corresponding 1324 RTP data packets to evaluate the performance of their networks for 1325 multicast distribution. 1327 Cumulative counts are used in both the sender information and 1328 receiver report blocks so that differences may be calculated between 1329 any two reports to make measurements over both short and long time 1330 periods, and to provide resilience against the loss of a report. The 1331 difference between the last two reports received can be used to 1332 estimate the recent quality of the distribution. The NTP timestamp is 1333 included so that rates may be calculated from these differences over 1334 the interval between two reports. Since that timestamp is independent 1335 of the clock rate for the data encoding, it is possible to implement 1336 encoding- and profile-independent quality monitors. 1338 An example calculation is the packet loss rate over the interval 1339 between two reception reports. The difference in the cumulative 1340 number of packets lost gives the number lost during that interval. 1341 The difference in the extended last sequence numbers received gives 1342 the number of packets expected during the interval. The ratio of 1343 these two is the packet loss fraction over the interval. This ratio 1344 should equal the fraction lost field if the two reports are 1345 consecutive, but otherwise not. The loss rate per second can be 1346 obtained by dividing the loss fraction by the difference in NTP 1347 timestamps, expressed in seconds. The number of packets received is 1348 the number of packets expected minus the number lost. The number of 1349 packets expected may also be used to judge the statistical validity 1350 of any loss estimates. For example, 1 out of 5 packets lost has a 1351 lower significance than 200 out of 1000. 1353 From the sender information, a third-party monitor can calculate the 1354 average payload data rate and the average packet rate over an 1355 interval without receiving the data. Taking the ratio of the two 1356 gives the average payload size. If it can be assumed that packet loss 1357 is independent of packet size, then the number of packets received by 1358 a particular receiver times the average payload size (or the 1359 corresponding packet size) gives the apparent throughput available to 1360 that receiver. 1362 In addition to the cumulative counts which allow long-term packet 1363 loss measurements using differences between reports, the fraction 1364 lost field provides a short-term measurement from a single report. 1365 This becomes more important as the size of a session scales up enough 1366 that reception state information might not be kept for all receivers 1367 or the interval between reports becomes long enough that only one 1368 report might have been received from a particular receiver. 1370 The interarrival jitter field provides a second short-term measure of 1371 network congestion. Packet loss tracks persistent congestion while 1372 the jitter measure tracks transient congestion. The jitter measure 1373 may indicate congestion before it leads to packet loss. Since the 1374 interarrival jitter field is only a snapshot of the jitter at the 1375 time of a report, it may be necessary to analyze a number of reports 1376 from one receiver over time or from multiple receivers, e.g., within 1377 a single network. 1379 6.4 SDES: Source description RTCP packet 1381 0 1 2 3 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 |V=2|P| SC | PT=SDES=202 | length | header 1385 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1386 | SSRC/CSRC_1 | chunk 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1388 | SDES items | 1389 | ... | 1390 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1391 | SSRC/CSRC_2 | chunk 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 1393 | SDES items | 1394 | ... | 1395 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1397 The SDES packet is a three-level structure composed of a header and 1398 zero or more chunks, each of of which is composed of items describing 1399 the source identified in that chunk. The items are described 1400 individually in subsequent sections. 1402 version (V), padding (P), length: 1403 As described for the SR packet (see Section 6.3.1). 1405 packet type (PT): 8 bits 1406 Contains the constant 202 to identify this as an RTCP SDES 1407 packet. 1409 source count (SC): 5 bits 1410 The number of SSRC/CSRC chunks contained in this SDES packet. A 1411 value of zero is valid but useless. 1413 Each chunk consists of an SSRC/CSRC identifier followed by a list of 1414 zero or more items, which carry information about the SSRC/CSRC. Each 1415 chunk starts on a 32-bit boundary. Each item consists of an 8-bit 1416 type field, an 8-bit octet count describing the length of the text 1417 (thus, not including this two-octet header), and the text itself. 1418 Note that the text can be no longer than 255 octets, but this is 1419 consistent with the need to limit RTCP bandwidth consumption. 1421 The text is encoded according to the UTF-2 encoding specified in 1422 Annex F of ISO standard 10646 [12,13]. This encoding is also known as 1423 UTF-8 or UTF-FSS. It is described in "File System Safe UCS 1424 Transformation Format (FSS_UTF)", X/Open Preliminary Specification, 1425 Document Number P316 and Unicode Technical Report #4. US-ASCII is a 1426 subset of this encoding and requires no additional encoding. The 1427 presence of multi-octet encodings is indicated by setting the most 1428 significant bit of a character to a value of one. 1430 Items are contiguous, i.e., items are not individually padded to a 1431 32-bit boundary. Text is not null terminated because some multi-octet 1432 encodings include null octets. The list of items in each chunk is 1433 terminated by one or more null octets, the first of which is 1434 interpreted as an item type of zero to denote the end of the list, 1435 and the remainder as needed to pad until the next 32-bit boundary. A 1436 chunk with zero items (four null octets) is valid but useless. 1438 End systems send one SDES packet containing their own source 1439 identifier (the same as the SSRC in the fixed RTP header). A mixer 1440 sends one SDES packet containing a chunk for each contributing source 1441 from which it is receiving SDES information, or multiple complete 1442 SDES packets in the format above if there are more than 31 such 1443 sources (see Section 7). 1445 The SDES items currently defined are described in the next sections. 1446 Only the CNAME item is mandatory. Some items shown here may be useful 1447 only for particular profiles, but the item types are all assigned 1448 from one common space to promote shared use and to simplify profile- 1449 independent applications. Additional items may be defined in a 1450 profile by registering the type numbers with IANA. 1452 6.4.1 CNAME: Canonical end-point identifier SDES item 1454 0 1 2 3 1455 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 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | CNAME=1 | length | user and domain name ... 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 The CNAME identifier has the following properties: 1462 o Because the randomly allocated SSRC identifier may change if a 1463 conflict is discovered or if a program is restarted, the CNAME 1464 item is required to provide the binding from the SSRC 1465 identifier to an identifier for the source that remains 1466 constant. 1468 o Like the SSRC identifier, the CNAME identifier should also be 1469 unique among all participants within one RTP session. 1471 o To provide a binding across multiple media tools used by one 1472 participant in a set of related RTP sessions, the CNAME should 1473 be fixed for that participant. 1475 o To facilitate third-party monitoring, the CNAME should be 1476 suitable for either a program or a person to locate the source. 1478 Therefore, the CNAME should be derived algorithmically and not 1479 entered manually, when possible. To meet these requirements, the 1480 following format should be used unless a profile specifies an 1481 alternate syntax or semantics. The CNAME item should have the format 1482 "user@host", or "host" if a user name is not available as on single- 1483 user systems. For both formats, "host" is either the fully qualified 1484 domain name of the host from which the real-time data originates, 1485 formatted according to the rules specified in RFC 1034 [14], RFC 1035 1486 [15] and Section 2.1 of RFC 1123 [16]; or the standard ASCII 1487 representation of the host's numeric address on the interface used 1488 for the RTP communication. For example, the standard ASCII 1489 representation of an IP Version 4 address is "dotted decimal", also 1490 known as dotted quad. Other address types are expected to have ASCII 1491 representations that are mutually unique. The fully qualified domain 1492 name is more convenient for a human observer and may avoid the need 1493 to send a NAME item in addition, but it may be difficult or 1494 impossible to obtain reliably in some operating environments. 1495 Applications that may be run in such environments should use the 1496 ASCII representation of the address instead. 1498 Examples are "doe@sleepy.megacorp.com" or "doe@192.0.2.89" for a 1499 multi-user system. On a system with no user name, examples would be 1500 "sleepy.megacorp.com" or "192.0.2.89". 1502 The user name should be in a form that a program such as "finger" or 1503 "talk" could use, i.e., it typically is the login name rather than 1504 the personal name. The host name is not necessarily identical to the 1505 one in the participant's electronic mail address. 1507 This syntax will not provide unique identifiers for each source if an 1508 application permits a user to generate multiple sources from one 1509 host. Such an application would have to rely on the SSRC to further 1510 identify the source, or the profile for that application would have 1511 to specify additional syntax for the CNAME identifier. 1513 If each application creates its CNAME independently, the resulting 1514 CNAMEs may not be identical as would be required to provide a binding 1515 across multiple media tools belonging to one participant in a set of 1516 related RTP sessions. If cross-media binding is required, it may be 1517 necessary for the CNAME of each tool to be externally configured with 1518 the same value by a coordination tool. 1520 Application writers should be aware that private network address 1521 assignments such as the Net-10 assignment proposed in RFC 1597 [17] 1522 may create network addresses that are not globally unique. This would 1523 lead to non-unique CNAMEs if hosts with private addresses and no 1524 direct IP connectivity to the public Internet have their RTP packets 1525 forwarded to the public Internet through an RTP-level translator. 1526 (See also RFC 1627 [18].) To handle this case, applications may 1527 provide a means to configure a unique CNAME, but the burden is on the 1528 translator to translate CNAMEs from private addresses to public 1529 addresses if necessary to keep private addresses from being exposed. 1531 6.4.2 NAME: User name SDES item 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | NAME=2 | length | common name of source ... 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 This is the real name used to describe the source, e.g., "John Doe, 1540 Bit Recycler, Megacorp". It may be in any form desired by the user. 1541 For applications such as conferencing, this form of name may be the 1542 most desirable for display in participant lists, and therefore might 1543 be sent most frequently of those items other than CNAME. Profiles may 1544 establish such priorities. The NAME value is expected to remain 1545 constant at least for the duration of a session. It should not be 1546 relied upon to be unique among all participants in the session. 1548 6.4.3 EMAIL: Electronic mail address SDES item 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 | EMAIL=3 | length | email address of source ... 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 The email address is formatted according to RFC 822 [19], for 1557 example, "John.Doe@megacorp.com". The EMAIL value is expected to 1558 remain constant for the duration of a session. 1560 6.4.4 PHONE: Phone number SDES item 1561 0 1 2 3 1562 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 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | PHONE=4 | length | phone number of source ... 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 The phone number should be formatted with the plus sign replacing the 1568 international access code. For example, "+1 908 555 1212" for a 1569 number in the United States. 1571 6.4.5 LOC: Geographic user location SDES item 1573 0 1 2 3 1574 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | LOC=5 | length | geographic location of site ... 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 Depending on the application, different degrees of detail are 1580 appropriate for this item. For conference applications, a string like 1581 "Murray Hill, New Jersey" may be sufficient, while, for an active 1582 badge system, strings like "Room 2A244, AT&T BL MH" might be 1583 appropriate. The degree of detail is left to the implementation 1584 and/or user, but format and content may be prescribed by a profile. 1585 The LOC value is expected to remain constant for the duration of a 1586 session, except for mobile hosts. 1588 6.4.6 TOOL: Application or tool name SDES item 1590 0 1 2 3 1591 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 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | TOOL=6 | length | name/version of source appl. ... 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 A string giving the name and possibly version of the application 1597 generating the stream, e.g., "videotool 1.2". This information may be 1598 useful for debugging purposes and is similar to the Mailer or Mail- 1599 System-Version SMTP headers. The TOOL value is expected to remain 1600 constant for the duration of the session. 1602 6.4.7 NOTE: Notice/status SDES item 1603 0 1 2 3 1604 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 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | NOTE=7 | length | note about the source ... 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 The following semantics are suggested for this item, but these or 1610 other semantics may be explicitly defined by a profile. The NOTE item 1611 is intended for transient messages describing the current state of 1612 the source, e.g., "on the phone, can't talk". Or, during a seminar, 1613 this item might be used to convey the title of the talk. It should be 1614 used only to carry exceptional information and should not be included 1615 routinely by all participants because this would slow down the rate 1616 at which reception reports and CNAME are sent, thus impairing the 1617 performance of the protocol. In particular, it should not be included 1618 as an item in a user's configuration file nor automatically generated 1619 as in a quote-of-the-day. 1621 Since the NOTE item may be important to display while it is active, 1622 the rate at which other non-CNAME items such as NAME are transmitted 1623 might be reduced so that the NOTE item can take that part of the RTCP 1624 bandwidth. When the transient message becomes inactive, the NOTE item 1625 should continue to be transmitted a few times at the same repetition 1626 rate but with a string of length zero to signal the receivers. 1627 However, receivers should also consider the NOTE item inactive if it 1628 is not received for a small multiple of the repetition rate, or 1629 perhaps 20-30 RTCP intervals. 1631 6.4.8 PRIV: Private extensions SDES item 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | PRIV=8 | length | prefix length | prefix string... 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 ... | value string ... 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 This item is used to define experimental or application-specific SDES 1642 extensions. The item contains a prefix consisting of a length-string 1643 pair, followed by the value string filling the remainder of the item 1644 and carrying the desired information. The prefix length field is 8 1645 bits long. The prefix string is a name chosen by the person defining 1646 the PRIV item to be unique with respect to other PRIV items this 1647 application might receive. The application creator might choose to 1648 use the application name plus an additional subtype identification if 1649 needed. Alternatively, it is recommended that others choose a name 1650 based on the entity they represent, then coordinate the use of the 1651 name within that entity. 1653 Note that the prefix consumes some space within the item's total 1654 length of 255 octets, so the prefix should be kept as short as 1655 possible. This facility and the constrained RTCP bandwidth should not 1656 be overloaded; it is not intended to satisfy all the control 1657 communication requirements of all applications. 1659 SDES PRIV prefixes will not be registered by IANA. If some form of 1660 the PRIV item proves to be of general utility, it should instead be 1661 assigned a regular SDES item type registered with IANA so that no 1662 prefix is required. This simplifies use and increases transmission 1663 efficiency. 1665 6.5 BYE: Goodbye RTCP packet 1667 0 1 2 3 1668 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 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 |V=2|P| SC | PT=BYE=203 | length | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | SSRC/CSRC | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 : ... : 1675 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1676 | length | reason for leaving ... (opt) 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 The BYE packet indicates that one or more sources are no longer 1680 active. 1682 version (V), padding (P), length: 1683 As described for the SR packet (see Section 6.3.1). 1685 packet type (PT): 8 bits 1686 Contains the constant 203 to identify this as an RTCP BYE 1687 packet. 1689 source count (SC): 5 bits 1690 The number of SSRC/CSRC identifiers included in this BYE packet. 1691 A count value of zero is valid, but useless. 1693 If a BYE packet is received by a mixer, the mixer forwards the BYE 1694 packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts 1695 down, it should send a BYE packet listing all contributing sources it 1696 handles, as well as its own SSRC identifier. Optionally, the BYE 1697 packet may include an 8-bit octet count followed by that many octets 1698 of text indicating the reason for leaving, e.g., "camera malfunction" 1699 or "RTP loop detected". The string has the same encoding as that 1700 described for SDES. If the string fills the packet to the next 32-bit 1701 boundary, the string is not null terminated. If not, the BYE packet 1702 is padded with null octets. 1704 6.6 APP: Application-defined RTCP packet 1706 0 1 2 3 1707 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 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 |V=2|P| subtype | PT=APP=204 | length | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | SSRC/CSRC | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | name (ASCII) | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | application-dependent data ... 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 The APP packet is intended for experimental use as new applications 1719 and new features are developed, without requiring packet type value 1720 registration. APP packets with unrecognized names should be ignored. 1721 After testing and if wider use is justified, it is recommended that 1722 each APP packet be redefined without the subtype and name fields and 1723 registered with the Internet Assigned Numbers Authority using an RTCP 1724 packet type. 1726 version (V), padding (P), length: 1727 As described for the SR packet (see Section 6.3.1). 1729 subtype: 5 bits 1730 May be used as a subtype to allow a set of APP packets to be 1731 defined under one unique name, or for any application-dependent 1732 data. 1734 packet type (PT): 8 bits 1735 Contains the constant 204 to identify this as an RTCP APP 1736 packet. 1738 name: 4 octets 1739 A name chosen by the person defining the set of APP packets to 1740 be unique with respect to other APP packets this application 1741 might receive. The application creator might choose to use the 1742 application name, and then coordinate the allocation of subtype 1743 values to others who want to define new packet types for the 1744 application. Alternatively, it is recommended that others 1745 choose a name based on the entity they represent, then 1746 coordinate the use of the name within that entity. The name is 1747 interpreted as a sequence of four ASCII characters, with 1748 uppercase and lowercase characters treated as distinct. 1750 application-dependent data: variable length 1751 Application-dependent data may or may not appear in an APP 1752 packet. It is interpreted by the application and not RTP itself. 1753 It must be a multiple of 32 bits long. 1755 7 RTP Translators and Mixers 1757 In addition to end systems, RTP supports the notion of "translators" 1758 and "mixers", which could be considered as "intermediate systems" at 1759 the RTP level. Although this support adds some complexity to the 1760 protocol, the need for these functions has been clearly established 1761 by experiments with multicast audio and video applications in the 1762 Internet. Example uses of translators and mixers given in Section 2.3 1763 stem from the presence of firewalls and low bandwidth connections, 1764 both of which are likely to remain. 1766 7.1 General Description 1768 An RTP translator/mixer connects two or more transport-level 1769 "clouds". Typically, each cloud is defined by a common network and 1770 transport protocol (e.g., IP/UDP), multicast address or pair of 1771 unicast addresses, and transport level destination port. (Network- 1772 level protocol translators, such as IP version 4 to IP version 6, may 1773 be present within a cloud invisibly to RTP.) One system may serve as 1774 a translator or mixer for a number of RTP sessions, but each is 1775 considered a logically separate entity. 1777 In order to avoid creating a loop when a translator or mixer is 1778 installed, the following rules must be observed: 1780 o Each of the clouds connected by translators and mixers 1781 participating in one RTP session either must be distinct from 1782 all the others in at least one of these parameters (protocol, 1783 address, port), or must be isolated at the network level from 1784 the others. 1786 o A derivative of the first rule is that there must not be 1787 multiple translators or mixers connected in parallel unless by 1788 some arrangement they partition the set of sources to be 1789 forwarded. 1791 Similarly, all RTP end systems that can communicate through one or 1792 more RTP translators or mixers share the same SSRC space, that is, 1793 the SSRC identifiers must be unique among all these end systems. 1794 Section 8.2 describes the collision resolution algorithm by which 1795 SSRC identifiers are kept unique and loops are detected. 1797 There may be many varieties of translators and mixers designed for 1798 different purposes and applications. Some examples are to add or 1799 remove encryption, change the encoding of the data or the underlying 1800 protocols, or replicate between a multicast address and one or more 1801 unicast addresses. The distinction between translators and mixers is 1802 that a translator passes through the data streams from different 1803 sources separately, whereas a mixer combines them to form one new 1804 stream: 1806 Translator: Forwards RTP packets with their SSRC identifier intact; 1807 this makes it possible for receivers to identify individual 1808 sources even though packets from all the sources pass through 1809 the same translator and carry the translator's network source 1810 address. Some kinds of translators will pass through the data 1811 untouched, but others may change the encoding of the data and 1812 thus the RTP data payload type and timestamp. If multiple data 1813 packets are re-encoded into one, or vice versa, a translator 1814 must assign new sequence numbers to the outgoing packets. Losses 1815 in the incoming packet stream may induce corresponding gaps in 1816 the outgoing sequence numbers. Receivers cannot detect the 1817 presence of a translator unless they know by some other means 1818 what payload type or transport address was used by the original 1819 source. 1821 Mixer: Receives streams of RTP data packets from one or more sources, 1822 possibly changes the data format, combines the streams in some 1823 manner and then forwards the combined stream. Since the timing 1824 among multiple input sources will not generally be synchronized, 1825 the mixer will make timing adjustments among the streams and 1826 generate its own timing for the combined stream, so it is the 1827 synchronization source. Thus, all data packets forwarded by a 1828 mixer will be marked with the mixer's own SSRC identifier. In 1829 order to preserve the identity of the original sources 1830 contributing to the mixed packet, the mixer should insert their 1831 SSRC identifiers into the CSRC identifier list following the 1832 fixed RTP header of the packet. A mixer that is also itself a 1833 contributing source for some packet should explicitly include 1834 its own SSRC identifier in the CSRC list for that packet. 1836 For some applications, it may be acceptable for a mixer not to 1837 identify sources in the CSRC list. However, this introduces the 1838 danger that loops involving those sources could not be detected. 1840 The advantage of a mixer over a translator for applications like 1841 audio is that the output bandwidth is limited to that of one source 1842 even when multiple sources are active on the input side. This may be 1843 important for low-bandwidth links. The disadvantage is that receivers 1844 on the output side don't have any control over which sources are 1845 passed through or muted, unless some mechanism is implemented for 1846 remote control of the mixer. The regeneration of synchronization 1847 information by mixers also means that receivers can't do inter-media 1848 synchronization of the original streams. A multi-media mixer could do 1849 it. 1851 [E1] [E6] 1852 | | 1853 E1:17 | E6:15 | 1854 | | E6:15 1855 V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17) 1856 (M1)------------->----------------->-------------->[E7] 1857 ^ ^ E4:47 ^ E4:47 1858 E2:1 | E4:47 | | M3:89 (64,45) 1859 | | | 1860 [E2] [E4] M3:89 (64,45) | 1861 | legend: 1862 [E3] --------->(M2)----------->(M3)------------| [End system] 1863 E3:64 M2:12 (64) ^ (Mixer) 1864 | E5:45 1865 | 1866 [E5] source: SSRC (CSRCs) 1867 -------------------> 1869 Figure 3: Sample RTP network with end systems, mixers and translators 1871 A collection of mixers and translators is shown in Figure 3 to 1872 illustrate their effect on SSRC and CSRC identifiers. In the figure, 1873 end systems are shown as rectangles (named E), translators as 1874 triangles (named T) and mixers as ovals (named M). The notation "M1: 1875 48(1,17)" designates a packet originating a mixer M1, identified with 1876 M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17, 1877 copied from the SSRC identifiers of packets from E1 and E2. 1879 7.2 RTCP Processing in Translators 1881 In addition to forwarding data packets, perhaps modified, translators 1882 and mixers must also process RTCP packets. In many cases, they will 1883 take apart the compound RTCP packets received from end systems to 1884 aggregate SDES information and to modify the SR or RR packets. 1885 Retransmission of this information may be triggered by the packet 1886 arrival or by the RTCP interval timer of the translator or mixer 1887 itself. 1889 A translator that does not modify the data packets, for example one 1890 that just replicates between a multicast address and a unicast 1891 address, may simply forward RTCP packets unmodified as well. A 1892 translator that transforms the payload in some way must make 1893 corresponding transformations in the SR and RR information so that it 1894 still reflects the characteristics of the data and the reception 1895 quality. These translators must not simply forward RTCP packets. In 1896 general, a translator should not aggregate SR and RR packets from 1897 different sources into one packet since that would reduce the 1898 accuracy of the propagation delay measurements based on the LSR and 1899 DLSR fields. 1901 SR sender information: A translator does not generate its own sender 1902 information, but forwards the SR packets received from one cloud 1903 to the others. The SSRC is left intact but the sender 1904 information must be modified if required by the translation. If 1905 a translator changes the data encoding, it must change the 1906 "sender's byte count" field. If it also combines several data 1907 packets into one output packet, it must change the "sender's 1908 packet count" field. If it changes the timestamp frequency, it 1909 must change the "RTP timestamp" field in the SR packet. 1911 SR/RR reception report blocks: A translator forwards reception 1912 reports received from one cloud to the others. Note that these 1913 flow in the direction opposite to the data. The SSRC is left 1914 intact. If a translator combines several data packets into one 1915 output packet, and therefore changes the sequence numbers, it 1916 must make the inverse manipulation for the packet loss fields 1917 and the "extended last sequence number" field. This may be 1918 complex. In the extreme case, there may be no meaningful way to 1919 translate the reception reports, so the translator may pass on 1920 no reception report at all or a synthetic report based on its 1921 own reception. The general rule is to do what makes sense for a 1922 particular translation. 1924 A translator does not require an SSRC identifier of its own, but may 1925 choose to allocate one for the purpose of sending reports about what 1926 it has received. These would be sent to all the connected clouds, 1927 each corresponding to the translation of the data stream as sent to 1928 that cloud, since reception reports are normally multicast to all 1929 participants. 1931 SDES: Translators typically forward without change the SDES 1932 information they receive from one cloud to the others, but may, 1933 for example, decide to filter non-CNAME SDES information if 1934 bandwidth is limited. The CNAMEs must be forwarded to allow SSRC 1935 identifier collision detection to work. A translator that 1936 generates its own RR packets must send SDES CNAME information 1937 about itself to the same clouds that it sends those RR packets. 1939 BYE: Translators forward BYE packets unchanged. Translators with 1940 their own SSRC should generate BYE packets with that SSRC 1941 identifier if they are about to cease forwarding packets. 1943 APP: Translators forward APP packets unchanged. 1945 7.3 RTCP Processing in Mixers 1947 Since a mixer generates a new data stream of its own, it does not 1948 pass through SR or RR packets at all and instead generates new 1949 information for both sides. 1951 SR sender information: A mixer does not pass through sender 1952 information from the sources it mixes because the 1953 characteristics of the source streams are lost in the mix. As a 1954 synchronization source, the mixer generates its own SR packets 1955 with sender information about the mixed data stream and sends 1956 them in the same direction as the mixed stream. 1958 SR/RR reception report blocks: A mixer generates its own reception 1959 reports for sources in each cloud and sends them out only to the 1960 same cloud. It does not send these reception reports to the 1961 other clouds and does not forward reception reports from one 1962 cloud to the others because the sources would not be SSRCs there 1963 (only CSRCs). 1965 SDES: Mixers typically forward without change the SDES information 1966 they receive from one cloud to the others, but may, for example, 1967 decide to filter non-CNAME SDES information if bandwidth is 1968 limited. The CNAMEs must be forwarded to allow SSRC identifier 1969 collision detection to work. (An identifier in a CSRC list 1970 generated by a mixer might collide with an SSRC identifier 1971 generated by an end system.) A mixer must send SDES CNAME 1972 information about itself to the same clouds that it sends SR or 1973 RR packets. 1975 Since mixers do not forward SR or RR packets, they will typically be 1976 extracting SDES packets from a compound RTCP packet. To minimize 1977 overhead, chunks from the SDES packets may be aggregated into a 1978 single SDES packet which is then stacked on an SR or RR packet 1979 originating from the mixer. The RTCP packet rate may be different on 1980 each side of the mixer. 1982 A mixer that does not insert CSRC identifiers may also refrain from 1983 forwarding SDES CNAMEs. In this case, the SSRC identifier spaces in 1984 the two clouds are independent. As mentioned earlier, this mode of 1985 operation creates a danger that loops can't be detected. 1987 BYE: Mixers need to forward BYE packets. They should generate BYE 1988 packets with their own SSRC identifiers if they are about to 1989 cease forwarding packets. 1991 APP: The treatment of APP packets by mixers is application-specific. 1993 7.4 Cascaded Mixers 1995 An RTP session may involve a collection of mixers and translators as 1996 shown in Figure 3. If two mixers are cascaded, such as M2 and M3 in 1997 the figure, packets received by a mixer may already have been mixed 1998 and may include a CSRC list with multiple identifiers. The second 1999 mixer should build the CSRC list for the outgoing packet using the 2000 CSRC identifiers from already-mixed input packets and the SSRC 2001 identifiers from unmixed input packets. This is shown in the output 2002 arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case 2003 of mixers that are not cascaded, if the resulting CSRC list has more 2004 than 15 identifiers, the remainder cannot be included. 2006 8 SSRC Identifier Allocation and Use 2008 The SSRC identifier carried in the RTP header and in various fields 2009 of RTCP packets is a random 32-bit number that is required to be 2010 globally unique within an RTP session. It is crucial that the number 2011 be chosen with care in order that participants on the same network or 2012 starting at the same time are not likely to choose the same number. 2014 It is not sufficient to use the local network address (such as an 2015 IPv4 address) for the identifier because the address may not be 2016 unique. Since RTP translators and mixers enable interoperation among 2017 multiple networks with different address spaces, the allocation 2018 patterns for addresses within two spaces might result in a much 2019 higher rate of collision than would occur with random allocation. 2021 Multiple sources running on one host would also conflict. 2023 It is also not sufficient to obtain an SSRC identifier simply by 2024 calling random() without carefully initializing the state. An example 2025 of how to generate a random identifier is presented in Appendix A.6. 2027 8.1 Probability of Collision 2029 Since the identifiers are chosen randomly, it is possible that two or 2030 more sources will choose the same number. Collision occurs with the 2031 highest probability when all sources are started simultaneously, for 2032 example when triggered automatically by some session management 2033 event. If N is the number of sources and L the length of the 2034 identifier (here, 32 bits), the probability that two sources 2035 independently pick the same value can be approximated for large N 2036 [20] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is 2037 roughly 10**-4. 2039 The typical collision probability is much lower than the worst-case 2040 above. When one new source joins an RTP session in which all the 2041 other sources already have unique identifiers, the probability of 2042 collision is just the fraction of numbers used out of the space. 2043 Again, if N is the number of sources and L the length of the 2044 identifier, the probability of collision is N / 2**L. For N=1000, the 2045 probability is roughly 2*10**-7. 2047 The probability of collision is further reduced by the opportunity 2048 for a new source to receive packets from other participants before 2049 sending its first packet (either data or control). If the new source 2050 keeps track of the other participants (by SSRC identifier), then 2051 before transmitting its first packet the new source can verify that 2052 its identifier does not conflict with any that have been received, or 2053 else choose again. 2055 8.2 Collision Resolution and Loop Detection 2057 Although the probability of SSRC identifier collision is low, all RTP 2058 implementations must be prepared to detect collisions and take the 2059 appropriate actions to resolve them. If a source discovers at any 2060 time that another source is using the same SSRC identifier as its 2061 own, it must send an RTCP BYE packet for the old identifier and 2062 choose another random one. If a receiver discovers that two other 2063 sources are colliding, it may keep the packets from one and discard 2064 the packets from the other when this can be detected by different 2065 source transport addresses or CNAMEs. The two sources are expected to 2066 resolve the collision so that the situation doesn't last. 2068 Because the random identifiers are kept globally unique for each RTP 2069 session, they can also be used to detect loops that may be introduced 2070 by mixers or translators. A loop causes duplication of data and 2071 control information, either unmodified or possibly mixed, as in the 2072 following examples: 2074 o A translator may incorrectly forward a packet to the same 2075 multicast group from which it has received the packet, either 2076 directly or through a chain of translators. In that case, the 2077 same packet appears several times, originating from different 2078 network sources. 2080 o Two translators incorrectly set up in parallel, i.e., with the 2081 same multicast groups on both sides, would both forward packets 2082 from one multicast group to the other. Unidirectional 2083 translators would produce two copies; bidirectional translators 2084 would form a loop. 2086 o A mixer can close a loop by sending to the same transport 2087 destination upon which it receives packets, either directly or 2088 through another mixer or translator. In this case a source 2089 might show up both as an SSRC on a data packet and a CSRC in a 2090 mixed data packet. 2092 A source may discover that its own packets are being looped, or that 2093 packets from another source are being looped (a third-party loop). 2095 Both loops and collisions in the random selection of a source 2096 identifier result in packets arriving with the same SSRC identifier 2097 but a different source transport address, which may be that of the 2098 end system originating the packet or an intermediate system. 2099 Consequently, if a source changes its source transport address, it 2100 must also choose a new SSRC identifier to avoid being interpreted as 2101 a looped source. Loops or collisions occurring on the far side of a 2102 translator or mixer cannot be detected using the source transport 2103 address if all copies of the packets go through the translator or 2104 mixer, however collisions may still be detected when chunks from two 2105 RTCP SDES packets contain the same SSRC identifier but different 2106 CNAMEs. 2108 To detect and resolve these conflicts, an RTP implementation must 2109 include an algorithm similar to the one described below. It ignores 2110 packets from a new source or loop that collide with an established 2111 source. It resolves collisions with the participant's own SSRC 2112 identifier by sending an RTCP BYE for the old identifier and choosing 2113 a new one. However, when the collision was induced by a loop of the 2114 participant's own packets, the algorithm will choose a new identifier 2115 only once and thereafter ignore packets from the looping source 2116 transport address. This is required to avoid a flood of BYE packets. 2118 This algorithm depends upon the source transport address being the 2119 same for both RTP and RTCP packets from a source. The algorithm would 2120 require modifications to support applications that don't meet this 2121 constraint. 2123 This algorithm requires keeping a table indexed by source identifiers 2124 and containing the source transport address from which the identifier 2125 was (first) received, along with other state for that source. Each 2126 SSRC or CSRC identifier received in a data or control packet is 2127 looked up in this table in order to process that data or control 2128 information. For control packets, each element with its own SSRC, 2129 for example an SDES chunk, requires a separate lookup. (The SSRC in a 2130 reception report block is an exception.) If the SSRC or CSRC is not 2131 found, a new entry is created. These table entries are removed when 2132 an RTCP BYE packet is received with the corresponding SSRC, or after 2133 no packets have arrived for a relatively long time (see Section 2134 6.2.1). 2136 In order to track loops of the participant's own data packets, it is 2137 also necessary to keep a separate list of source transport addresses 2138 (not identifiers) that have been found to be conflicting. Note that 2139 this should be a short list, usually empty. Each element in this list 2140 stores the source address plus the time when the most recent 2141 conflicting packet was received. An element may be removed from the 2142 list when no conflicting packet has arrived from that source for a 2143 time on the order of 10 RTCP report intervals (see Section 6.2). 2145 For the algorithm as shown, it is assumed that the participant's own 2146 source identifier and state are included in the source identifier 2147 table. The algorithm could be restructured to first make a separate 2148 comparison against the participant's own source identifier. 2150 IF the SSRC or CSRC identifier is not found in the source 2151 identifier table: 2152 THEN create a new entry storing the source transport address 2153 and the SSRC or CSRC along with other state. 2154 CONTINUE with normal processing. 2156 (identifier is found in the table) 2158 IF the source transport address from the packet matches 2159 the one saved in the table entry for this identifier: 2160 THEN CONTINUE with normal processing. 2162 (an identifier collision or a loop is indicated) 2164 IF the source identifier is not the participant's own: 2165 THEN IF the source identifier is from an RTCP SDES chunk 2166 containing a CNAME item that differs from the CNAME 2167 in the table entry: 2168 THEN (optionally) count a third-party collision. 2170 ELSE (optionally) count a third-party loop. 2171 ABORT processing of data packet or control element. 2173 (a collision or loop of the participant's own data) 2175 IF the source transport address is found in the list of 2176 conflicting addresses: 2177 THEN IF the source identifier is not from an RTCP SDES chunk 2178 containing a CNAME item OR if that CNAME is the 2179 participant's own: 2180 THEN (optionally) count occurrence of own traffic looped. 2181 mark current time in conflicting address list entry. 2182 ABORT processing of data packet or control element. 2183 log occurrence of a collision. 2184 create a new entry in the conflicting address list and 2185 mark current time. 2186 send an RTCP BYE packet with the old SSRC identifier. 2187 choose a new identifier. 2188 create a new entry in the source identifier table with the 2189 old SSRC plus the source transport address from the packet 2190 being processed. 2191 CONTINUE with normal processing. 2193 In this algorithm, packets from a newly conflicting source address 2194 will be ignored and packets from the original source will be kept. 2195 (If the original source was through a mixer and later the same source 2196 is received directly, the receiver may be well advised to switch 2197 unless other sources in the mix would be lost.) If no packets arrive 2198 from the original source for an extended period, the table entry will 2199 be timed out and the new source will be able to take over. This might 2200 occur if the original source detects the collision and moves to a new 2201 source identifier, but in the usual case an RTCP BYE packet will be 2202 received from the original source to delete the state without having 2203 to wait for a timeout. 2205 When a new SSRC identifier is chosen due to a collision, the 2206 candidate identifier should first be looked up in the source 2207 identifier table to see if it was already in use by some other 2208 source. If so, another candidate should be generated and the process 2209 repeated. 2211 A loop of data packets to a multicast destination can cause severe 2212 network flooding. All mixers and translators are required to 2213 implement a loop detection algorithm like the one here so that they 2214 can break loops. This should limit the excess traffic to no more than 2215 one duplicate copy of the original traffic, which may allow the 2216 session to continue so that the cause of the loop can be found and 2217 fixed. However, in extreme cases where a mixer or translator does not 2218 properly break the loop and high traffic levels result, it may be 2219 necessary for end systems to cease transmitting data or control 2220 packets entirely. This decision may depend upon the application. An 2221 error condition should be indicated as appropriate. Transmission 2222 might be attempted again periodically after a long, random time (on 2223 the order of minutes). 2225 9 Security 2227 Lower layer protocols may eventually provide all the security 2228 services that may be desired for applications of RTP, including 2229 authentication, integrity, and confidentiality. These services have 2230 recently been specified for IP. Since the need for a confidentiality 2231 service is well established in the initial audio and video 2232 applications that are expected to use RTP, a confidentiality service 2233 is defined in the next section for use with RTP and RTCP until lower 2234 layer services are available. The overhead on the protocol for this 2235 service is low, so the penalty will be minimal if this service is 2236 obsoleted by lower layer services in the future. 2238 Alternatively, other services, other implementations of services and 2239 other algorithms may be defined for RTP in the future if warranted. 2240 The selection presented here is meant to simplify implementation of 2241 interoperable, secure applications and provide guidance to 2242 implementors. No claim is made that the methods presented here are 2243 appropriate for a particular security need. A profile may specify 2244 which services and algorithms should be offered by applications, and 2245 may provide guidance as to their appropriate use. 2247 Key distribution and certificates are outside the scope of this 2248 document. 2250 9.1 Confidentiality 2252 Confidentiality means that only the intended receiver(s) can decode 2253 the received packets; for others, the packet contains no useful 2254 information. Confidentiality of the content is achieved by 2255 encryption. 2257 When encryption of RTP or RTCP is desired, all the octets that will 2258 be encapsulated for transmission in a single lower-layer packet are 2259 encrypted as a unit. For RTCP, a 32-bit random number is prepended to 2260 the unit before encryption to deter known plaintext attacks. For RTP, 2261 no prefix is required because the sequence number and timestamp 2262 fields are initialized with random offsets. 2264 For RTCP, it is allowed to split a compound RTCP packet into two 2265 lower-layer packets, one to be encrypted and one to be sent in the 2266 clear. For example, SDES information might be encrypted while 2267 reception reports were sent in the clear to accommodate third-party 2268 monitors that are not privy to the encryption key. In this example, 2269 depicted in Fig. 4, the SDES information must be appended to an RR 2270 packet with no reports (and the encrypted) to satisfy the requirement 2271 that all compound RTCP packets begin with an SR or RR packet. 2273 UDP packet UDP packet 2274 ------------------------------------- ------------------------- 2275 [32-bit ][ ][ # ] [ # sender # receiver] 2276 [random ][ RR ][SDES # CNAME, ...] [ SR # report # report ] 2277 [integer][(empty)][ # ] [ # # ] 2278 ------------------------------------- ------------------------- 2279 encrypted not encrypted 2281 #: SSRC 2283 Figure 4: Encrypted and non-encrypted RTCP packets 2285 The presence of encryption and the use of the correct key are 2286 confirmed by the receiver through header or payload validity checks. 2287 Examples of such validity checks for RTP and RTCP headers are given 2288 in Appendices A.1 and A.2. 2290 The default encryption algorithm is the Data Encryption Standard 2291 (DES) algorithm in cipher block chaining (CBC) mode, as described in 2292 Section 1.1 of RFC 1423 [21], except that padding to a multiple of 8 2293 octets is indicated as described for the P bit in Section 5.1. The 2294 initialization vector is zero because random values are supplied in 2295 the RTP header or by the random prefix for compound RTCP packets. For 2296 details on the use of CBC initialization vectors, see [22]. 2297 Implementations that support encryption should always support the DES 2298 algorithm in CBC mode as the default to maximize interoperability. 2299 This method is chosen because it has been demonstrated to be easy and 2300 practical to use in experimental audio and video tools in operation 2301 on the Internet. Other encryption algorithms may be specified 2302 dynamically for a session by non-RTP means. 2304 As an alternative to encryption at the RTP level as described above, 2305 profiles may define additional payload types for encrypted encodings. 2306 Those encodings must specify how padding and other aspects of the 2307 encryption should be handled. This method allows encrypting only the 2308 data while leaving the headers in the clear for applications where 2309 that is desired. It may be particularly useful for hardware devices 2310 that will handle both decryption and decoding. 2312 9.2 Authentication and Message Integrity 2314 Authentication and message integrity are not defined in the current 2315 specification of RTP since these services would not be directly 2316 feasible without a key management infrastructure. It is expected that 2317 authentication and integrity services will be provided by lower layer 2318 protocols in the future. 2320 10 RTP over Network and Transport Protocols 2322 This section describes issues specific to carrying RTP packets within 2323 particular network and transport protocols. The following rules apply 2324 unless superseded by protocol-specific definitions outside this 2325 specification. 2327 RTP relies on the underlying protocol(s) to provide demultiplexing of 2328 RTP data and RTCP control streams. For UDP and similar protocols, RTP 2329 uses an even port number and the corresponding RTCP stream uses the 2330 next higher (odd) port number. If an application is supplied with an 2331 odd number for use as the RTP port, it should replace this number 2332 with the next lower (even) number. 2334 RTP data packets contain no length field or other delineation, 2335 therefore RTP relies on the underlying protocol(s) to provide a 2336 length indication. The maximum length of RTP packets is limited only 2337 by the underlying protocols. 2339 If RTP packets are to be carried in an underlying protocol that 2340 provides the abstraction of a continuous octet stream rather than 2341 messages (packets), an encapsulation of the RTP packets must be 2342 defined to provide a framing mechanism. Framing is also needed if the 2343 underlying protocol may contain padding so that the extent of the RTP 2344 payload cannot be determined. The framing mechanism is not defined 2345 here. 2347 A profile may specify a framing method to be used even when RTP is 2348 carried in protocols that do provide framing in order to allow 2349 carrying several RTP packets in one lower-layer protocol data unit, 2350 such as a UDP packet. Carrying several RTP packets in one network or 2351 transport packet reduces header overhead and may simplify 2352 synchronization between different streams. 2354 11 Summary of Protocol Constants 2355 This section contains a summary listing of the constants defined in 2356 this specification. 2358 The RTP payload type (PT) constants are defined in profiles rather 2359 than this document. However, the octet of the RTP header which 2360 contains the marker bit(s) and payload type must avoid the reserved 2361 values 200 and 201 (decimal) to distinguish RTP packets from the RTCP 2362 SR and RR packet types for the header validation procedure described 2363 in Appendix A.1. For the standard definition of one marker bit and a 2364 7-bit payload type field as shown in this specification, this 2365 restriction means that payload types 72 and 73 are reserved. 2367 11.1 RTCP packet types 2369 abbrev. name value 2370 SR sender report 200 2371 RR receiver report 201 2372 SDES source description 202 2373 BYE goodbye 203 2374 APP application-defined 204 2376 These type values were chosen in the range 200-204 for improved 2377 header validity checking of RTCP packets compared to RTP packets or 2378 other unrelated packets. When the RTCP packet type field is compared 2379 to the corresponding octet of the RTP header, this range corresponds 2380 to the marker bit being 1 (which it usually is not in data packets) 2381 and to the high bit of the standard payload type field being 1 (since 2382 the static payload types are typically defined in the low half). This 2383 range was also chosen to be some distance numerically from 0 and 255 2384 since all-zeros and all-ones are common data patterns. 2386 Since all compound RTCP packets must begin with SR or RR, these codes 2387 were chosen as an even/odd pair to allow the RTCP validity check to 2388 test the maximum number of bits with mask and value. 2390 Other constants are assigned by IANA. Experimenters are encouraged to 2391 register the numbers they need for experiments, and then unregister 2392 those which prove to be unneeded. 2394 11.2 SDES types 2396 abbrev. name value 2397 END end of SDES list 0 2398 CNAME canonical name 1 2399 NAME user name 2 2400 EMAIL user's electronic mail address 3 2401 PHONE user's phone number 4 2402 LOC geographic user location 5 2403 TOOL name of application or tool 6 2404 NOTE notice about the source 7 2405 PRIV private extensions 8 2407 Other constants are assigned by IANA. Experimenters are encouraged to 2408 register the numbers they need for experiments, and then unregister 2409 those which prove to be unneeded. 2411 12 RTP Profiles and Payload Format Specifications 2413 A complete specification of RTP for a particular application will 2414 require one or more companion documents of two types described here: 2415 profiles, and payload format specifications. 2417 RTP may be used for a variety of applications with somewhat differing 2418 requirements. The flexibility to adapt to those requirements is 2419 provided by allowing multiple choices in the main protocol 2420 specification, then selecting the appropriate choices or defining 2421 extensions for a particular environment and class of applications in 2422 a separate profile document. Typically an application will operate 2423 under only one profile so there is no explicit indication of which 2424 profile is in use. A profile for audio and video applications may be 2425 found in the companion Internet-Draft draft-ietf-avt-profile for 2426 ...". 2428 The second type of companion document is a payload format 2429 specification, which defines how a particular kind of payload data, 2430 such as H.261 encoded video, should be carried in RTP. These 2431 documents are typically titled "RTP Payload Format for XYZ 2432 Audio/Video Encoding". Payload formats may be useful under multiple 2433 profiles and may therefore be defined independently of any particular 2434 profile. The profile documents are then responsible for assigning a 2435 default mapping of that format to a payload type value if needed. 2437 Within this specification, the following items have been identified 2438 for possible definition within a profile, but this list is not meant 2439 to be exhaustive: 2441 RTP data header: The octet in the RTP data header that contains the 2442 marker bit and payload type field may be redefined by a profile 2443 to suit different requirements, for example with more or fewer 2444 marker bits (Section 5.3, p. 11). 2446 Payload types: Assuming that a payload type field is included, the 2447 profile will usually define a set of payload formats (e.g., 2448 media encodings) and a default static mapping of those formats 2449 to payload type values. Some of the payload formats may be 2450 defined by reference to separate payload format specifications. 2451 For each payload type defined, the profile must specify the RTP 2452 timestamp clock rate to be used (Section 5.1, p. 10). 2454 RTP data header additions: Additional fields may be appended to the 2455 fixed RTP data header if some additional functionality is 2456 required across the profile's class of applications independent 2457 of payload type (Section 5.3, p. 11). 2459 RTP data header extensions: The contents of the first 16 bits of the 2460 RTP data header extension structure must be defined if use of 2461 that mechanism is to be allowed under the profile for 2462 implementation-specific extensions (Section 5.3.1, p. 12). 2464 RTCP packet types: New application-class-specific RTCP packet types 2465 may be defined and registered with IANA. 2467 RTCP report interval: A profile should specify that the values 2468 suggested in Section 6.2 for the constants employed in the 2469 calculation of the RTCP report interval will be used. Those are 2470 the RTCP fraction of session bandwidth, the minimum report 2471 interval, and the bandwidth split between senders and receivers. 2472 A profile may specify alternate values if they have been 2473 demonstrated to work in a scalable manner. 2475 SR/RR extension: An extension section may be defined for the RTCP SR 2476 and RR packets if there is additional information that should be 2477 reported regularly about the sender or receivers (Section 6.3.3, 2478 p. 23). 2480 SDES use: The profile may specify the relative priorities for RTCP 2481 SDES items to be transmitted or excluded entirely (Section 2482 6.2.2); an alternate syntax or semantics for the CNAME item 2483 (Section 6.4.1); the format of the LOC item (Section 6.4.5); the 2484 semantics and use of the NOTE item (Section 6.4.7); or new SDES 2485 item types to be registered with IANA. 2487 Security: A profile may specify which security services and 2488 algorithms should be offered by applications, and may provide 2489 guidance as to their appropriate use (Section 9, p. 38). 2491 String-to-key mapping: A profile may specify how a user-provided 2492 password or pass phrase is mapped into an encryption key. 2494 Underlying protocol: Use of a particular underlying network or 2495 transport layer protocol to carry RTP packets may be required. 2497 Transport mapping: A mapping of RTP and RTCP to transport-level 2498 addresses, e.g., UDP ports, other than the standard mapping 2499 defined in Section 10, p. 39 may be specified. 2501 Encapsulation: An encapsulation of RTP packets may be defined to 2502 allow multiple RTP data packets to be carried in one lower-layer 2503 packet or to provide framing over underlying protocols that do 2504 not already do so (Section 10, p. 39). 2506 It is not expected that a new profile will be required for every 2507 application. Within one application class, it would be better to 2508 extend an existing profile rather than make a new one in order to 2509 facilitate interoperation among the applications since each will 2510 typically run under only one profile. Simple extensions such as the 2511 definition of additional payload type values or RTCP packet types may 2512 be accomplished by registering them through the Internet Assigned 2513 Numbers Authority and publishing their descriptions in an addendum to 2514 the profile or in a payload format specification. 2516 A Algorithms 2518 We provide examples of C code for aspects of RTP sender and receiver 2519 algorithms. There may be other implementation methods that are faster 2520 in particular operating environments or have other advantages. These 2521 implementation notes are for informational purposes only and are 2522 meant to clarify the RTP specification. 2524 The following definitions are used for all examples; for clarity and 2525 brevity, the structure definitions are only valid for 32-bit big- 2526 endian (most significant octet first) architectures. Bit fields are 2527 assumed to be packed tightly in big-endian bit order, with no 2528 additional padding. Modifications would be required to construct a 2529 portable implementation. 2531 /* 2532 * rtp.h -- RTP header file (RFC XXXX) 2533 */ 2534 #include 2536 /* 2537 * The type definitions below are valid for 32-bit architectures and 2538 * may have to be adjusted for 16- or 64-bit architectures. 2539 */ 2540 typedef unsigned char u_int8; 2541 typedef unsigned short u_int16; 2542 typedef unsigned int u_int32; 2543 typedef short int16; 2545 /* 2546 * Current protocol version. 2547 */ 2548 #define RTP_VERSION 2 2550 #define RTP_SEQ_MOD (1<<16) 2551 #define RTP_MAX_SDES 255 /* maximum text length for SDES */ 2553 typedef enum { 2554 RTCP_SR = 200, 2555 RTCP_RR = 201, 2556 RTCP_SDES = 202, 2557 RTCP_BYE = 203, 2558 RTCP_APP = 204 2559 } rtcp_type_t; 2561 typedef enum { 2562 RTCP_SDES_END = 0, 2563 RTCP_SDES_CNAME = 1, 2564 RTCP_SDES_NAME = 2, 2565 RTCP_SDES_EMAIL = 3, 2566 RTCP_SDES_PHONE = 4, 2567 RTCP_SDES_LOC = 5, 2568 RTCP_SDES_TOOL = 6, 2569 RTCP_SDES_NOTE = 7, 2570 RTCP_SDES_PRIV = 8 2571 } rtcp_sdes_type_t; 2573 /* 2574 * RTP data header 2575 */ 2576 typedef struct { 2577 unsigned int version:2; /* protocol version */ 2578 unsigned int p:1; /* padding flag */ 2579 unsigned int x:1; /* header extension flag */ 2580 unsigned int cc:4; /* CSRC count */ 2581 unsigned int m:1; /* marker bit */ 2582 unsigned int pt:7; /* payload type */ 2583 u_int16 seq; /* sequence number */ 2584 u_int32 ts; /* timestamp */ 2585 u_int32 ssrc; /* synchronization source */ 2586 u_int32 csrc[1]; /* optional CSRC list */ 2587 } rtp_hdr_t; 2589 /* 2590 * RTCP common header word 2591 */ 2592 typedef struct { 2593 unsigned int version:2; /* protocol version */ 2594 unsigned int p:1; /* padding flag */ 2595 unsigned int count:5; /* varies by packet type */ 2596 unsigned int pt:8; /* RTCP packet type */ 2597 u_int16 length; /* pkt len in words, w/o this word */ 2598 } rtcp_common_t; 2600 /* 2601 * Big-endian mask for version, padding bit and packet type pair 2602 */ 2603 #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe) 2604 #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR) 2606 /* 2607 * Reception report block 2608 */ 2609 typedef struct { 2610 u_int32 ssrc; /* data source being reported */ 2611 unsigned int fraction:8; /* fraction lost since last SR/RR */ 2612 int lost:24; /* cumul. no. pkts lost (signed!) */ 2613 u_int32 last_seq; /* extended last seq. no. received */ 2614 u_int32 jitter; /* interarrival jitter */ 2615 u_int32 lsr; /* last SR packet from this source */ 2616 u_int32 dlsr; /* delay since last SR packet */ 2617 } rtcp_rr_t; 2619 /* 2620 * SDES item 2621 */ 2622 typedef struct { 2623 u_int8 type; /* type of item (rtcp_sdes_type_t) */ 2624 u_int8 length; /* length of item (in octets) */ 2625 char data[1]; /* text, not null-terminated */ 2627 } rtcp_sdes_item_t; 2629 /* 2630 * One RTCP packet 2631 */ 2632 typedef struct { 2633 rtcp_common_t common; /* common header */ 2634 union { 2635 /* sender report (SR) */ 2636 struct { 2637 u_int32 ssrc; /* sender generating this report */ 2638 u_int32 ntp_sec; /* NTP timestamp */ 2639 u_int32 ntp_frac; 2640 u_int32 rtp_ts; /* RTP timestamp */ 2641 u_int32 psent; /* packets sent */ 2642 u_int32 osent; /* octets sent */ 2643 rtcp_rr_t rr[1]; /* variable-length list */ 2644 } sr; 2646 /* reception report (RR) */ 2647 struct { 2648 u_int32 ssrc; /* receiver generating this report */ 2649 rtcp_rr_t rr[1]; /* variable-length list */ 2650 } rr; 2652 /* source description (SDES) */ 2653 struct rtcp_sdes { 2654 u_int32 src; /* first SSRC/CSRC */ 2655 rtcp_sdes_item_t item[1]; /* list of SDES items */ 2656 } sdes; 2658 /* BYE */ 2659 struct { 2660 u_int32 src[1]; /* list of sources */ 2661 /* can't express trailing text for reason */ 2662 } bye; 2663 } r; 2664 } rtcp_t; 2666 typedef struct rtcp_sdes rtcp_sdes_t; 2667 /* 2668 * Per-source state information 2669 */ 2670 typedef struct { 2671 u_int16 max_seq; /* highest seq. number seen */ 2672 u_int32 cycles; /* shifted count of seq. number cycles */ 2673 u_int32 base_seq; /* base seq number */ 2674 u_int32 bad_seq; /* last 'bad' seq number + 1 */ 2675 u_int32 probation; /* sequ. packets till source is valid */ 2676 u_int32 received; /* packets received */ 2677 u_int32 expected_prior; /* packet expected at last interval */ 2678 u_int32 received_prior; /* packet received at last interval */ 2679 u_int32 transit; /* relative trans time for prev pkt */ 2680 u_int32 jitter; /* estimated jitter */ 2681 /* ... */ 2682 } source; 2684 A.1 RTP Data Header Validity Checks 2686 An RTP receiver should check the validity of the RTP header on 2687 incoming packets since they might be encrypted or might be from a 2688 different application that happens to be misaddressed. Similarly, if 2689 encryption is enabled, the header validity check is needed to verify 2690 that incoming packets have been correctly decrypted, although a 2691 failure of the header validity check (e.g., unknown payload type) may 2692 not necessarily indicate decryption failure. 2694 Only weak validity checks are possible on an RTP data packet from a 2695 source that has not been heard before: 2697 o RTP version field must equal 2. 2699 o The payload type must be known, in particular it must not be 2700 equal to SR or RR. 2702 o If the P bit is set, then the last octet of the packet must 2703 contain a valid octet count, in particular, less than the total 2704 packet length minus the header size. 2706 o The X bit must be zero if the profile does not specify that 2707 the header extension mechanism may be used. Otherwise, the 2708 extension length field must be less than the total packet size 2709 minus the fixed header length and padding. 2711 o The length of the packet must be consistent with CC and 2712 payload type (if payloads have a known length). 2714 The last three checks are somewhat complex and not always possible, 2715 leaving only the first two which total just a few bits. If the SSRC 2716 identifier in the packet is one that has been received before, then 2717 the packet is probably valid and checking if the sequence number is 2718 in the expected range provides further validation. If the SSRC 2719 identifier has not been seen before, then data packets carrying that 2720 identifier may be considered invalid until a small number of them 2721 arrive with consecutive sequence numbers. 2723 The routine update_seq shown below ensures that a source is declared 2724 valid only after MIN_SEQUENTIAL packets have been received in 2725 sequence. It also validates the sequence number seq of a newly 2726 received packet and updates the sequence state for the packet's 2727 source in the structure to which s points. 2729 When a new source is heard for the first time, that is, its SSRC 2730 identifier is not in the table (see Section 8.2), and the per-source 2731 state is allocated for it, s->probation should be set to the number 2732 of sequential packets required before declaring a source valid 2733 (parameter MIN_SEQUENTIAL ) and s->max_seq initialized to seq-1 s- 2734 >probation marks the source as not yet valid so the state may be 2735 discarded after a short timeout rather than a long one, as discussed 2736 in Section 6.2.1. 2738 After a source is considered valid, the sequence number is considered 2739 valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more 2740 than MAX_MISORDER behind. If the new sequence number is ahead of 2741 max_seq modulo the RTP sequence number range (16 bits), but is 2742 smaller than max_seq , it has wrapped around and the (shifted) count 2743 of sequence number cycles is incremented. A value of one is returned 2744 to indicate a valid sequence number. 2746 Otherwise, the value zero is returned to indicate that the validation 2747 failed, and the bad sequence number is stored. If the next packet 2748 received carries the next higher sequence number, it is considered 2749 the valid start of a new packet sequence presumably caused by an 2750 extended dropout or a source restart. Since multiple complete 2751 sequence number cycles may have been missed, the packet loss 2752 statistics are reset. 2754 Typical values for the parameters are shown, based on a maximum 2755 misordering time of 2 seconds at 50 packets/second and a maximum 2756 dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a 2757 small fraction of the 16-bit sequence number space to give a 2758 reasonable probability that new sequence numbers after a restart will 2759 not fall in the acceptable range for sequence numbers from before the 2760 restart. 2762 void init_seq(source *s, u_int16 seq) 2763 { 2764 s->base_seq = seq - 1; 2765 s->max_seq = seq; 2766 s->bad_seq = RTP_SEQ_MOD + 1; 2767 s->cycles = 0; 2768 s->received = 0; 2769 s->received_prior = 0; 2770 s->expected_prior = 0; 2771 /* other initialization */ 2772 } 2774 int update_seq(source *s, u_int16 seq) 2775 { 2776 u_int16 udelta = seq - s->max_seq; 2777 const int MAX_DROPOUT = 3000; 2778 const int MAX_MISORDER = 100; 2779 const int MIN_SEQUENTIAL = 2; 2781 /* 2782 * Source is not valid until MIN_SEQUENTIAL packets with 2783 * sequential sequence numbers have been received. 2784 */ 2785 if (s->probation) { 2786 /* packet is in sequence */ 2787 if (seq == s->max_seq + 1) { 2788 s->probation--; 2789 s->max_seq = seq; 2790 if (s->probation == 0) { 2791 init_seq(s, seq); 2792 s->received++; 2793 return 1; 2794 } 2795 } else { 2796 s->probation = MIN_SEQUENTIAL - 1; 2797 s->max_seq = seq; 2798 } 2799 return 0; 2800 } else if (udelta < MAX_DROPOUT) { 2801 /* in order, with permissible gap */ 2802 if (seq < s->max_seq) { 2803 /* 2804 * Sequence number wrapped - count another 64K cycle. 2805 */ 2806 s->cycles += RTP_SEQ_MOD; 2807 } 2808 s->max_seq = seq; 2810 } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) { 2811 /* the sequence number made a very large jump */ 2812 if (seq == s->bad_seq) { 2813 /* 2814 * Two sequential packets -- assume that the other side 2815 * restarted without telling us so just re-sync 2816 * (i.e., pretend this was the first packet). 2817 */ 2818 init_seq(s, seq); 2819 } 2820 else { 2821 s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1); 2822 return 0; 2823 } 2824 } else { 2825 /* duplicate or reordered packet */ 2826 } 2827 s->received++; 2828 return 1; 2829 } 2831 The validity check can be made stronger requiring more than two 2832 packets in sequence. The disadvantages are that a larger number of 2833 initial packets will be discarded and that high packet loss rates 2834 could prevent validation. However, because the RTCP header validation 2835 is relatively strong, if an RTCP packet is received from a source 2836 before the data packets, the count could be adjusted so that only two 2837 packets are required in sequence. If initial data loss for a few 2838 seconds can be tolerated, an application could choose to discard all 2839 data packets from a source until a valid RTCP packet has been 2840 received from that source. 2842 Depending on the application and encoding, algorithms may exploit 2843 additional knowledge about the payload format for further validation. 2844 For payload types where the timestamp increment is the same for all 2845 packets, the timestamp values can be predicted from the previous 2846 packet received from the same source using the sequence number 2847 difference (assuming no change in payload type). 2849 A strong "fast-path" check is possible since with high probability 2850 the first four octets in the header of a newly received RTP data 2851 packet will be just the same as that of the previous packet from the 2852 same SSRC except that the sequence number will have increased by one. 2853 Similarly, a single-entry cache may be used for faster SSRC lookups 2854 in applications where data is typically received from one source at a 2855 time. 2857 A.2 RTCP Header Validity Checks 2859 The following checks can be applied to RTCP packets. 2861 o RTP version field must equal 2. 2863 o The payload type field of the first RTCP packet in a compound 2864 packet must be equal to SR or RR. 2866 o The padding bit (P) should be zero for the first packet of a 2867 compound RTCP packet because only the last should possibly need 2868 padding. 2870 o The length fields of the individual RTCP packets must total to 2871 the overall length of the compound RTCP packet as received. 2872 This is a fairly strong check. 2874 The code fragment below performs all of these checks. The packet type 2875 is not checked for subsequent packets since unknown packet types may 2876 be present and should be ignored. 2878 u_int32 len; /* length of compound RTCP packet in words */ 2879 rtcp_t *r; /* RTCP header */ 2880 rtcp_t *end; /* end of compound RTCP packet */ 2882 if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) { 2883 /* something wrong with packet format */ 2884 } 2885 end = (rtcp_t *)((u_int32 *)r + len); 2887 do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1); 2888 while (r < end && r->common.version == 2); 2890 if (r != end) { 2891 /* something wrong with packet format */ 2892 } 2894 A.3 Determining the Number of RTP Packets Expected and Lost 2896 In order to compute packet loss rates, the number of packets expected 2897 and actually received from each source needs to be known, using per- 2898 source state information defined in struct source referenced via 2899 pointer s in the code below. The number of packets received is simply 2900 the count of packets as they arrive, including any late or duplicate 2901 packets. The number of packets expected can be computed by the 2902 receiver as the difference between the highest sequence number 2903 received ( s->max_seq ) and the first sequence number received ( s- 2904 >base_seq ). Since the sequence number is only 16 bits and will wrap 2905 around, it is necessary to extend the highest sequence number with 2906 the (shifted) count of sequence number wraparounds ( s->cycles ). 2907 Both the received packet count and the count of cycles are maintained 2908 the RTP header validity check routine in Appendix A.1. 2910 extended_max = s->cycles + s->max_seq; 2911 expected = extended_max - s->base_seq + 1; 2913 The number of packets lost is defined to be the number of packets 2914 expected less the number of packets actually received: 2916 lost = expected - s->received; 2918 Since this number is carried in 24 bits, it should be clamped at 2919 0xffffff rather than wrap around to zero. 2921 The fraction of packets lost during the last reporting interval 2922 (since the previous SR or RR packet was sent) is calculated from 2923 differences in the expected and received packet counts across the 2924 interval, where expected_prior and received_prior are the values 2925 saved when the previous reception report was generated: 2927 expected_interval = expected - s->expected_prior; 2928 s->expected_prior = expected; 2929 received_interval = s->received - s->received_prior; 2930 s->received_prior = s->received; 2931 lost_interval = expected_interval - received_interval; 2932 if (expected_interval == 0 || lost_interval <= 0) fraction = 0; 2933 else fraction = (lost_interval << 8) / expected_interval; 2935 The resulting fraction is an 8-bit fixed point number with the binary 2936 point at the left edge. 2938 A.4 Generating SDES RTCP Packets 2939 This function builds one SDES chunk into buffer b composed of argc 2940 items supplied in arrays type , value and length b 2942 char *rtp_write_sdes(char *b, u_int32 src, int argc, 2943 rtcp_sdes_type_t type[], char *value[], 2944 int length[]) 2945 { 2946 rtcp_sdes_t *s = (rtcp_sdes_t *)b; 2947 rtcp_sdes_item_t *rsp; 2948 int i; 2949 int len; 2950 int pad; 2952 /* SSRC header */ 2953 s->src = src; 2954 rsp = &s->item[0]; 2956 /* SDES items */ 2957 for (i = 0; i < argc; i++) { 2958 rsp->type = type[i]; 2959 len = length[i]; 2960 if (len > RTP_MAX_SDES) { 2961 /* invalid length, may want to take other action */ 2962 len = RTP_MAX_SDES; 2963 } 2964 rsp->length = len; 2965 memcpy(rsp->data, value[i], len); 2966 rsp = (rtcp_sdes_item_t *)&rsp->data[len]; 2967 } 2969 /* terminate with end marker and pad to next 4-octet boundary */ 2970 len = ((char *) rsp) - b; 2971 pad = 4 - (len & 0x3); 2972 b = (char *) rsp; 2973 while (pad--) *b++ = RTCP_SDES_END; 2975 return b; 2976 } 2978 A.5 Parsing RTCP SDES Packets 2980 This function parses an SDES packet, calling functions find_member() 2981 to find a pointer to the information for a session member given the 2982 SSRC identifier and member_sdes() to store the new SDES information 2983 for that member. This function expects a pointer to the header of the 2984 RTCP packet. 2986 void rtp_read_sdes(rtcp_t *r) 2987 { 2988 int count = r->common.count; 2989 rtcp_sdes_t *sd = &r->r.sdes; 2990 rtcp_sdes_item_t *rsp, *rspn; 2991 rtcp_sdes_item_t *end = (rtcp_sdes_item_t *) 2992 ((u_int32 *)r + r->common.length + 1); 2993 source *s; 2995 while (--count >= 0) { 2996 rsp = &sd->item[0]; 2997 if (rsp >= end) break; 2998 s = find_member(sd->src); 3000 for (; rsp->type; rsp = rspn ) { 3001 rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2); 3002 if (rspn >= end) { 3003 rsp = rspn; 3004 break; 3005 } 3006 member_sdes(s, rsp->type, rsp->data, rsp->length); 3007 } 3008 sd = (rtcp_sdes_t *) 3009 ((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1); 3010 } 3011 if (count >= 0) { 3012 /* invalid packet format */ 3013 } 3014 } 3016 A.6 Generating a Random 32-bit Identifier 3018 The following subroutine generates a random 32-bit identifier using 3019 the MD5 routines published in RFC 1321 [23]. The system routines may 3020 not be present on all operating systems, but they should serve as 3021 hints as to what kinds of information may be used. Other system calls 3022 that may be appropriate include 3024 o getdomainname() , 3026 o getwd() , or 3028 o getrusage() 3030 "Live" video or audio samples are also a good source of random 3031 numbers, but care must be taken to avoid using a turned-off 3032 microphone or blinded camera as a source [7]. 3034 Use of this or similar routine is suggested to generate the initial 3035 seed for the random number generator producing the RTCP period (as 3036 shown in Appendix A.7), to generate the initial values for the 3037 sequence number and timestamp, and to generate SSRC values. Since 3038 this routine is likely to be CPU-intensive, its direct use to 3039 generate RTCP periods is inappropriate because predictability is not 3040 an issue. Note that this routine produces the same result on repeated 3041 calls until the value of the system clock changes unless different 3042 values are supplied for the type argument. 3044 /* 3045 * Generate a random 32-bit quantity. 3046 */ 3047 #include /* u_long */ 3048 #include /* gettimeofday() */ 3049 #include /* get..() */ 3050 #include /* printf() */ 3051 #include /* clock() */ 3052 #include /* uname() */ 3053 #include "global.h" /* from RFC 1321 */ 3054 #include "md5.h" /* from RFC 1321 */ 3056 #define MD_CTX MD5_CTX 3057 #define MDInit MD5Init 3058 #define MDUpdate MD5Update 3059 #define MDFinal MD5Final 3061 static u_long md_32(char *string, int length) 3062 { 3063 MD_CTX context; 3064 union { 3065 char c[16]; 3066 u_long x[4]; 3067 } digest; 3068 u_long r; 3069 int i; 3071 MDInit (&context); 3072 MDUpdate (&context, string, length); 3073 MDFinal ((unsigned char *)&digest, &context); 3074 r = 0; 3075 for (i = 0; i < 3; i++) { 3076 r ^= digest.x[i]; 3077 } 3078 return r; 3079 } /* md_32 */ 3081 /* 3082 * Return random unsigned 32-bit quantity. Use 'type' argument if you 3083 * need to generate several different values in close succession. 3084 */ 3085 u_int32 random32(int type) 3086 { 3087 struct { 3088 int type; 3089 struct timeval tv; 3090 clock_t cpu; 3091 pid_t pid; 3092 u_long hid; 3093 uid_t uid; 3094 gid_t gid; 3095 struct utsname name; 3096 } s; 3098 gettimeofday(&s.tv, 0); 3099 uname(&s.name); 3100 s.type = type; 3101 s.cpu = clock(); 3102 s.pid = getpid(); 3103 s.hid = gethostid(); 3104 s.uid = getuid(); 3105 s.gid = getgid(); 3107 return md_32((char *)&s, sizeof(s)); 3108 } /* random32 */ 3110 A.7 Computing the RTCP Transmission Interval 3112 The following function returns the time between transmissions of RTCP 3113 packets, measured in seconds. It should be called after sending one 3114 compound RTCP packet to calculate the delay until the next should be 3115 sent. This function should also be called to calculate the delay 3116 before sending the first RTCP packet upon startup rather than send 3117 the packet immediately. This avoids any burst of RTCP packets if an 3118 application is started at many sites simultaneously, for example as a 3119 result of a session announcement. 3121 The parameters have the following meaning: 3123 rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth that 3124 will be used for RTCP packets by all members of this session, in 3125 octets per second. This should be 5% of the "session bandwidth" 3126 parameter supplied to the application at startup. 3128 senders: Number of active senders since sending last report, known 3129 from construction of receiver reports for this RTCP packet. 3130 Includes ourselves, if we also sent during this interval. 3132 members: The estimated number of session members, including 3133 ourselves. Incremented as we discover new session members from 3134 the receipt of RTP or RTCP packets, and decremented as session 3135 members leave (via RTCP BYE) or their state is timed out (30 3136 minutes is recommended). On the first call, this parameter 3137 should have the value 1. 3139 we_sent: Flag that is true if we have sent data during the last two 3140 RTCP intervals. If the flag is true, the compound RTCP packet 3141 just sent contained an SR packet. 3143 packet_size: The size of the compound RTCP packet just sent, in 3144 octets, including the network encapsulation (e.g., 28 octets for 3145 UDP over IP). 3147 avg_rtcp_size: Pointer to estimator for compound RTCP packet size; 3148 initialized and updated by this function for the packet just 3149 sent, and also updated by an identical line of code in the RTCP 3150 receive routine for every RTCP packet received from other 3151 participants in the session. 3153 initial: Flag that is true for the first call upon startup to 3154 calculate the time until the first report should be sent. 3156 #include 3158 double rtcp_interval(int members, 3159 int senders, 3160 double rtcp_bw, 3161 int we_sent, 3162 int packet_size, 3163 int *avg_rtcp_size, 3164 int initial) 3165 { 3166 /* 3167 * Minimum time between RTCP packets from this site (in seconds). 3168 * This time prevents the reports from `clumping' when sessions 3169 * are small and the law of large numbers isn't helping to smooth 3170 * out the traffic. It also keeps the report interval from 3171 * becoming ridiculously small during transient outages like a 3172 * network partition. 3173 */ 3174 double const RTCP_MIN_TIME = 5.; 3175 /* 3176 * Fraction of the RTCP bandwidth to be shared among active 3177 * senders. (This fraction was chosen so that in a typical 3178 * session with one or two active senders, the computed report 3179 * time would be roughly equal to the minimum report time so that 3180 * we don't unnecessarily slow down receiver reports.) The 3181 * receiver fraction must be 1 - the sender fraction. 3182 */ 3183 double const RTCP_SENDER_BW_FRACTION = 0.25; 3184 double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION); 3185 /* 3186 * Gain (smoothing constant) for the low-pass filter that 3187 * estimates the average RTCP packet size (see Cadzow reference). 3188 */ 3189 double const RTCP_SIZE_GAIN = (1./16.); 3191 double t; /* interval */ 3192 double rtcp_min_time = RTCP_MIN_TIME; 3193 int n; /* no. of members for computation */ 3195 /* 3196 * Very first call at application start-up uses half the min 3197 * delay for quicker notification while still allowing some time 3198 * before reporting for randomization and to learn about other 3199 * sources so the report interval will converge to the correct 3200 * interval more quickly. The average RTCP size is initialized 3201 * to 128 octets which is conservative (it assumes everyone else 3202 * is generating SRs instead of RRs: 20 IP + 8 UDP + 52 SR + 48 3203 * SDES CNAME). 3204 */ 3205 if (initial) { 3206 rtcp_min_time /= 2; 3207 *avg_rtcp_size = 128; 3208 } 3210 /* 3211 * If there were active senders, give them at least a minimum 3212 * share of the RTCP bandwidth. Otherwise all participants share 3213 * the RTCP bandwidth equally. 3214 */ 3215 n = members; 3216 if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) { 3217 if (we_sent) { 3218 rtcp_bw *= RTCP_SENDER_BW_FRACTION; 3219 n = senders; 3220 } else { 3221 rtcp_bw *= RTCP_RCVR_BW_FRACTION; 3222 n -= senders; 3223 } 3224 } 3226 /* 3227 * Update the average size estimate by the size of the report 3228 * packet we just sent. 3229 */ 3230 *avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN; 3232 /* 3233 * The effective number of sites times the average packet size is 3234 * the total number of octets sent when each site sends a report. 3235 * Dividing this by the effective bandwidth gives the time 3236 * interval over which those packets must be sent in order to 3237 * meet the bandwidth target, with a minimum enforced. In that 3238 * time interval we send one report so this time is also our 3239 * average time between reports. 3240 */ 3241 t = (*avg_rtcp_size) * n / rtcp_bw; 3242 if (t < rtcp_min_time) t = rtcp_min_time; 3244 /* 3245 * To avoid traffic bursts from unintended synchronization with 3246 * other sites, we then pick our actual next report interval as a 3247 * random number uniformly distributed between 0.5*t and 1.5*t. 3248 */ 3249 return t * (drand48() + 0.5); 3250 } 3252 A.8 Estimating the Interarrival Jitter 3254 The code fragments below implement the algorithm given in Section 3255 6.3.1 for calculating an estimate of the statistical variance of the 3256 RTP data interarrival time to be inserted in the interarrival jitter 3257 field of reception reports. The inputs are r->ts , the timestamp from 3258 the incoming packet, and arrival , the current time in the same 3259 units. Here s points to state for the source; s->transit holds the 3260 relative transit time for the previous packet, and s->jitter holds 3261 the estimated jitter. The jitter field of the reception report is 3262 measured in timestamp units and expressed as an unsigned integer, but 3263 the jitter estimate is kept in a floating point. As each data packet 3264 arrives, the jitter estimate is updated: 3266 int transit = arrival - r->ts; 3267 int d = transit - s->transit; 3268 s->transit = transit; 3269 if (d < 0) d = -d; 3270 s->jitter += (1./16.) * ((double)d - s->jitter); 3272 When a reception report block (to which rr points) is generated for 3273 this member, the current jitter estimate is returned: 3275 rr->jitter = (u_int32) s->jitter; 3277 Alternatively, the jitter estimate can be kept as an integer, but 3278 scaled to reduce round-off error. The calculation is the same except 3279 for the last line: 3281 s->jitter += d - ((s->jitter + 8) >> 4); 3283 In this case, the estimate is sampled for the reception report as: 3285 rr->jitter = s->jitter >> 4; 3287 B Security Considerations 3289 RTP suffers from the same security liabilities as the underlying 3290 protocols. For example, an impostor can fake source or destination 3291 network addresses, or change the header or payload. Within RTCP, the 3292 CNAME and NAME information may be used to impersonate another 3293 participant. In addition, RTP may be sent via IP multicast, which 3294 provides no direct means for a sender to know all the receivers of 3295 the data sent and therefore no measure of privacy. Rightly or not, 3296 users may be more sensitive to privacy concerns with audio and video 3297 communication than they have been with more traditional forms of 3298 network communication [24]. Therefore, the use of security mechanisms 3299 with RTP is important. These mechanisms are discussed in Section 9. 3301 RTP-level translators or mixers may be used to allow RTP traffic to 3302 reach hosts behind firewalls. Appropriate firewall security 3303 principles and practices, which are beyond the scope of this 3304 document, should be followed in the design and installation of these 3305 devices and in the admission of RTP applications for use behind the 3306 firewall. 3308 C Addresses of Authors 3310 Henning Schulzrinne 3311 GMD Fokus 3312 Hardenbergplatz 2 3313 D-10623 Berlin 3314 Germany 3315 electronic mail: schulzrinne@fokus.gmd.de 3317 Stephen L. Casner 3318 Precept Software, Inc. 3319 21580 Stevens Creek Boulevard, Suite 207 3320 Cupertino, CA 95014 3321 United States 3322 electronic mail: casner@precept.com 3324 Ron Frederick 3325 Xerox Palo Alto Research Center 3326 3333 Coyote Hill Road 3327 Palo Alto, CA 94304 3328 United States 3329 electronic mail: frederic@parc.xerox.com 3331 Van Jacobson 3332 MS 46a-1121 3333 Lawrence Berkeley National Laboratory 3334 Berkeley, CA 94720 3335 United States 3336 electronic mail: van@ee.lbl.gov 3338 Acknowledgments 3340 This memorandum is based on discussions within the IETF Audio/Video 3341 Transport working group chaired by Stephen Casner. The current 3342 protocol has its origins in the Network Voice Protocol and the Packet 3343 Video Protocol (Danny Cohen and Randy Cole) and the protocol 3344 implemented by the vat application (Van Jacobson and Steve McCanne). 3345 Christian Huitema provided ideas for the random identifier generator. 3347 D Bibliography 3349 [1] D. D. Clark and D. L. Tennenhouse, "Architectural considerations 3350 for a new generation of protocols," in SIGCOMM Symposium on 3351 Communications Architectures and Protocols , (Philadelphia, 3352 Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer 3353 Communications Review, Vol. 20(4), Sept. 1990. 3355 [2] H. Schulzrinne, "Issues in designing a transport protocol for 3356 audio and video conferences and other multiparticipant real-time 3357 applications." expired Internet draft, Oct. 1993. 3359 [3] D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood 3360 Cliffs, New Jersey: Prentice Hall, 1991. 3362 [4] J. Postel, "Internet protocol," RFC 791, Internet Engineering 3363 Task Force, Sept. 1981. 3365 [5] D. Mills, "Network time protocol (v3)," RFC 1305, Internet 3366 Engineering Task Force, Apr. 1992. 3368 [6] J. Reynolds and J. Postel, "Assigned numbers," STD 2, RFC 1700, 3369 Internet Engineering Task Force, Oct. 1994. 3371 [7] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 3372 recommendations for security," RFC 1750, Internet Engineering Task 3373 Force, Dec. 1994. 3375 [8] J.-C. Bolot, T. Turletti, and I. Wakeman, "Scalable feedback 3376 control for multicast video distribution in the internet," in SIGCOMM 3377 Symposium on Communications Architectures and Protocols , (London, 3378 England), pp. 58--67, ACM, Aug. 1994. 3380 [9] I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of 3381 multimedia applications based on RTP," Computer Communications , Jan. 3383 1996. 3385 [10] S. Floyd and V. Jacobson, "The synchronization of periodic 3386 routing messages," in SIGCOMM Symposium on Communications 3387 Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, 3388 California), pp. 33--44, ACM, Sept. 1993. also in [25]. 3390 [11] J. A. Cadzow, Foundations of digital signal processing and data 3391 analysis New York, New York: Macmillan, 1987. 3393 [12] International Standards Organization, "ISO/IEC DIS 10646-1:1993 3394 information technology -- universal multiple-octet coded character 3395 set (UCS) -- part I: Architecture and basic multilingual plane," 3396 1993. 3398 [13] The Unicode Consortium, The Unicode Standard New York, New York: 3399 Addison-Wesley, 1991. 3401 [14] P. Mockapetris, "Domain names - concepts and facilities," STD 3402 13, RFC 1034, Internet Engineering Task Force, Nov. 1987. 3404 [15] P. Mockapetris, "Domain names - implementation and 3405 specification," STD 13, RFC 1035, Internet Engineering Task Force, 3406 Nov. 1987. 3408 [16] R. Braden, "Requirements for internet hosts - application and 3409 support," STD 3, RFC 1123, Internet Engineering Task Force, Oct. 3410 1989. 3412 [17] Y. Rekhter, R. Moskowitz, D. Karrenberg, and G. de Groot, 3413 "Address allocation for private internets," RFC 1597, Internet 3414 Engineering Task Force, Mar. 1994. 3416 [18] E. Lear, E. Fair, D. Crocker, and T. Kessler, "Network 10 3417 considered harmful (some practices shouldn't be codified)," RFC 3418 1627, Internet Engineering Task Force, July 1994. 3420 [19] D. Crocker, "Standard for the format of ARPA internet text 3421 messages," STD 11, RFC 822, Internet Engineering Task Force, Aug. 3422 1982. 3424 [20] W. Feller, An Introduction to Probability Theory and its 3425 Applications, Volume 1 , vol. 1. New York, New York: John Wiley and 3426 Sons, third ed., 1968. 3428 [21] D. Balenson, "Privacy enhancement for internet electronic mail: 3429 Part III: algorithms, modes, and identifiers," RFC 1423, Internet 3430 Engineering Task Force, Feb. 1993. 3432 [22] V. L. Voydock and S. T. Kent, "Security mechanisms in high-level 3433 network protocols," ACM Computing Surveys , vol. 15, pp. 135--171, 3434 June 1983. 3436 [23] R. Rivest, "The MD5 message-digest algorithm," RFC 1321, 3437 Internet Engineering Task Force, Apr. 1992. 3439 [24] S. Stubblebine, "Security services for multimedia conferencing," 3440 in 16th National Computer Security Conference , (Baltimore, 3441 Maryland), pp. 391--395, Sept. 1993. 3443 [25] S. Floyd and V. Jacobson, "The synchronization of periodic 3444 routing messages," IEEE/ACM Transactions on Networking , vol. 2, pp. 3445 122--136, Apr. 1994. 3447 Table of Contents 3449 1 Introduction ........................................ 2 3450 2 RTP Use Scenarios ................................... 4 3451 2.1 Simple Multicast Audio Conference ................... 4 3452 2.2 Audio and Video Conference .......................... 5 3453 2.3 Mixers and Translators .............................. 5 3454 3 Definitions ......................................... 6 3455 4 Byte Order, Alignment, and Time Format .............. 8 3456 5 RTP Data Transfer Protocol .......................... 9 3457 5.1 RTP Fixed Header Fields ............................. 9 3458 5.2 Multiplexing RTP Sessions ........................... 12 3459 5.3 Profile-Specific Modifications to the RTP Header 3460 ................................................................ 13 3461 5.3.1 RTP Header Extension ................................ 13 3462 6 RTP Control Protocol -- RTCP ........................ 14 3463 6.1 RTCP Packet Format .................................. 16 3464 6.2 RTCP Transmission Interval .......................... 17 3465 6.2.1 Maintaining the number of session members ........... 20 3466 6.2.2 Allocation of source description bandwidth .......... 20 3467 6.3 Sender and Receiver Reports ......................... 21 3468 6.3.1 SR: Sender report RTCP packet ....................... 22 3469 6.3.2 RR: Receiver report RTCP packet ..................... 26 3470 6.3.3 Extending the sender and receiver reports ........... 28 3471 6.3.4 Analyzing sender and receiver reports ............... 28 3472 6.4 SDES: Source description RTCP packet ................ 30 3473 6.4.1 CNAME: Canonical end-point identifier SDES item ..... 31 3474 6.4.2 NAME: User name SDES item ........................... 33 3475 6.4.3 EMAIL: Electronic mail address SDES item ............ 33 3476 6.4.4 PHONE: Phone number SDES item ....................... 33 3477 6.4.5 LOC: Geographic user location SDES item ............. 34 3478 6.4.6 TOOL: Application or tool name SDES item ............ 34 3479 6.4.7 NOTE: Notice/status SDES item ....................... 34 3480 6.4.8 PRIV: Private extensions SDES item .................. 35 3481 6.5 BYE: Goodbye RTCP packet ............................ 36 3482 6.6 APP: Application-defined RTCP packet ................ 37 3483 7 RTP Translators and Mixers .......................... 38 3484 7.1 General Description ................................. 38 3485 7.2 RTCP Processing in Translators ...................... 40 3486 7.3 RTCP Processing in Mixers ........................... 42 3487 7.4 Cascaded Mixers ..................................... 43 3488 8 SSRC Identifier Allocation and Use .................. 43 3489 8.1 Probability of Collision ............................ 44 3490 8.2 Collision Resolution and Loop Detection ............. 44 3491 9 Security ............................................ 48 3492 9.1 Confidentiality ..................................... 48 3493 9.2 Authentication and Message Integrity ................ 50 3494 10 RTP over Network and Transport Protocols ............ 50 3495 11 Summary of Protocol Constants ....................... 50 3496 11.1 RTCP packet types ................................... 51 3497 11.2 SDES types .......................................... 51 3498 12 RTP Profiles and Payload Format Specifications ...... 52 3499 A Algorithms .......................................... 54 3500 A.1 RTP Data Header Validity Checks ..................... 58 3501 A.2 RTCP Header Validity Checks ......................... 62 3502 A.3 Determining the Number of RTP Packets Expected and 3503 Lost ........................................................... 62 3504 A.4 Generating SDES RTCP Packets ........................ 63 3505 A.5 Parsing RTCP SDES Packets ........................... 64 3506 A.6 Generating a Random 32-bit Identifier ............... 65 3507 A.7 Computing the RTCP Transmission Interval ............ 68 3508 A.8 Estimating the Interarrival Jitter .................. 72 3509 B Security Considerations ............................. 73 3510 C Addresses of Authors ................................ 73 3511 D Bibliography ........................................ 74