idnits 2.17.1 draft-mauve-rtpi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'BRA97' on line 115 looks like a reference -- Missing reference section? 'Sch99' on line 2041 looks like a reference -- Missing reference section? 'Per99' on line 2030 looks like a reference -- Missing reference section? 'Cla90' on line 1991 looks like a reference -- Missing reference section? 'Flo97' on line 2006 looks like a reference -- Missing reference section? 'Pos81' on line 2034 looks like a reference -- Missing reference section? 'Mil92' on line 2015 looks like a reference -- Missing reference section? 'Flo93' on line 1997 looks like a reference -- Missing reference section? 'Flo94' on line 2002 looks like a reference -- Missing reference section? 'Ros98' on line 2037 looks like a reference -- Missing reference section? 'Yer98' on line 2046 looks like a reference -- Missing reference section? 'Moc87a' on line 2020 looks like a reference -- Missing reference section? 'Moc87b' on line 2026 looks like a reference -- Missing reference section? 'Bra89' on line 1983 looks like a reference -- Missing reference section? '21' on line 1553 looks like a reference -- Missing reference section? 'Ken98' on line 2011 looks like a reference -- Missing reference section? 'Bra97' on line 1987 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. Mauve 2 Internet Draft V. Hilt 3 draft-mauve-rtpi-00.txt C. Kuhmuench 4 March 1, 2000 J. Vogel 5 Expires: August 31, 2000 W. Geyer 6 W. Effelsberg 8 University of Mannheim 10 RTP/I: An Application Level Real-Time Protocol for 11 Distributed Interactive Media 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 ABSTRACT 35 This document specifies RTP/I, an application level real-time 36 protocol for distributed interactive media. Typical examples of 37 distributed interactive media are shared whiteboards, networked 38 computer games and distributed virtual environments. RTP/I defines 39 a standardized framing for the transmission of data and provides 40 mechanisms that are universally needed for this media class. 41 Thereby RTP/I enables the development of reusable functionality and 42 generic services that can be employed for multiple distributed 43 interactive media. Examples for this kind of functionality are the 44 ability to record sessions, to support late coming participants, 45 and to provide security services. RTP/I is a protocol that follows 46 the ideas of application level framing and integrated layer 47 processing. It has been designed to be independent of the 48 underlying network and transport layers. To a large extend RTP/I 50 RTP/I December 1999 52 has been inspired by the real-time transport protocol (RTP), which 53 is used for continuous non-interactive media. 55 This document is intended to stimulate the discussion on how to 56 transport distributed interactive media over the Internet. There 57 exists an RTP/I mailing list. Instructions on how to subscribe to 58 this list can be found at the RTP/I homepage 59 (http://www.informatik.uni-mannheim.de/informatik/pi4/projects/ 60 RTPI/index.html). Feedback on this document should be addressed to 61 the RTP/I mailing list or directly to the authors. 63 Table of Contents 64 1. Terminology .................................................... 3 65 2. Introduction ................................................... 3 66 3. RTP/I Scope .................................................... 6 67 4. Model for Distributed Interactive Media ........................ 6 68 4.1. States and Events ......................................... 6 69 4.2. Partitioning the Medium - Sub-Components .................. 7 70 4.3. Environment ............................................... 8 71 5. Byte Order, Alignment, and Time Format ......................... 8 72 6. RTP/I Data Transfer Protocol ................................... 9 73 6.1. RTP/I Event Packet Type ................................... 9 74 6.2. RTP/I State Packet Type ................................... 12 75 6.3. RTP/I Delta State Packet Type ............................. 13 76 6.4. RTP/I State Query Packet Type ............................. 13 77 6.5. Multiplexing RTP/I Sessions ............................... 14 78 6.6. RTP/I and ALF/ILP Oriented Reliability Mechanisms ......... 15 79 6.7. Profile-Specific Modifications to the RTP/I header ........ 15 80 7. RTP/I Control Protocol -- RTCP/I ............................... 16 81 7.1. RTCP/I Packet Composition ................................. 16 82 7.2. RTCP/I Transmission Interval .............................. 17 83 7.2.1. Maintaining the number of session members .......... 19 84 7.3. RTCP/I Packet Send and Receive Rules ...................... 19 85 7.3.1. Computing the RTCP/I transmission interval ......... 20 86 7.3.2. Initialization ..................................... 21 87 7.3.3. Receiving an RTP/I or non-BYE RTCP/I packet ........ 21 88 7.3.4. Receiving an RTCP/I BYE packet ..................... 21 89 7.3.5. Timing Out a PID ................................... 22 90 7.3.6. Expiration of Transmission Timer ................... 22 91 7.3.7. Transmitting a BYE Packet .......................... 23 92 7.4. RTCP/I Packet Formats ..................................... 23 93 7.4.1. RTPC/I Sub-Component Report Packet ................. 23 94 7.4.2. RTCP/I Source Description Packet ................... 26 95 7.4.3. BYE: Goodbye RTCP/I packet ......................... 32 96 7.4.4. APP: Application-defined RTCP/I packet ............. 32 97 7.5. Allocation of RTCP/I bandwidth ............................ 33 98 8. Security ....................................................... 34 99 9. RTP/I over Network and Transport Protocols ..................... 34 100 10. Summary of Protocol Constants ................................. 35 101 11. IANA Considerations ........................................... 36 102 12. Full Copyright Statement ...................................... 36 103 13. Addresses of Authors .......................................... 37 104 Acknowledgements .................................................. 37 105 Bibliography ...................................................... 38 107 RTP/I December 1999 109 1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [BRA97] and 114 indicate requirement levels for compliant RTP/I implementations. 116 2. Introduction 118 Distributed interactive media, i.e. media involving user interac- 119 tions, have received increasing interest over the past decade. Typi- 120 cal representatives of this media class are shared whiteboards, 121 networked computer games, and distributed virtual environments. The 122 application level real-time protocol for distributed interactive 123 media (RTP/I) captures and supports the common aspects of this media 124 class. RTP/I thereby allows the development of services and func- 125 tionality that are reusable for different distributed interactive 126 media. 128 There have been suggestions to use the real-time transport protocol 129 (RTP) [Sch99] as an application level protocol for this media class. 130 However, RTP has been developed to fit the media model of continuous 131 non-interactive media, e.g. audio and video. These media have an 132 ephemeral state which is frequently and redundantly transmitted. In 133 addition the state of the medium is influenced only by a single 134 entity - the sender of the stream. In contrast distributed interac- 135 tive media require managing the shared state of a medium. All parti- 136 cipants are potentially able to change this state. The key problem of 137 this media class is to keep the shared state reasonably similar for 138 all participants of a session, i.e. to maintain consistency. These 139 fundamental differences in the media models prevent RTP from being an 140 optimal fit for distributed interactive media. For a more detailled 141 discussion on why RTP is not appropriate as an application level pro- 142 tocol for distributed interactive media see [Per99]. 144 RTP/I has been designed to reuse aspects of RTP when appropriate 145 while it is thoroughly adapted to meet the demands of the new media 146 class. Throughout this memorandum original and slightly modified pas- 147 sages from Internet Draft ietf-avt-rtp-new-03.txt [Sch99] are fre- 148 quently used. 150 RTP/I consists of two main parts, both reside on the application 151 level and are independent of the underlying network and transport 152 layers: 154 o the framing protocol (RTP/I). RTP/I is used to frame the data 155 transmitted for distributed interactive media. This framing 156 contains the information that is common to media of that class. It 157 makes it possible to understand the semantics of the transmitted 158 data to a large extent without any medium specific knowledge. This 159 allows the development of meaningful functionality and services 161 RTP/I December 1999 163 that are independent of the media specific data encapsulated by the 164 framing information. 166 o the RTP/I control protocol (RTCP/I). RTCP/I is used to convey meta 167 information about the medium and information about the participants 168 of a session. 170 RTP/I supports the principles of Application Level Framing (ALF) and 171 Integrated Layer Processing (ILP) as proposed by Clark and 172 Tennenhouse [Cla90]. To this end the RTP/I framing provides all the 173 information required to identify Application Data Units (ADUs) and to 174 process them independently. 176 Even though RTP/I provides the application level framing of ADUs it 177 does not define any specific way to realize reliability. This would 178 not be appropriate since the reliability requirements of different 179 distributed interactive media vary widely. For this reason RTP/I 180 allows different reliability mechanisms to cooexist and cooperate 181 with the framing specified by this memorandum. 183 Specifically, RTP/I may also be used by applications that do not 184 follow the principle of ILP and that realize reliability by means of 185 a reliable transport protocol (e.g. TCP). Up to today this approach 186 is used by the vast majority of applications in this area. The 187 applications following this approach trade efficiency for simplicity 188 and a clean application architecture. This may be appropriate for 189 some applications. For those applications RTP/I simply provides a 190 standardized application level protocol, so that generic 191 functionality and services can be used. 193 Nevertheless we consider approaches that do not rely on a reliable 194 transport service as more efficient for distributed interactive 195 media. For those approaches RTP/I can be regarded as a specialization 196 of the ADU framing, as it is used by ALF/ILP oriented reliability 197 mechanisms, such as SRM [Flo97]. RTP/I extends the framing of these 198 mechanisms to the specific needs of distributed interactive media. In 199 order to allow for additional information required by reliability 200 mechanisms RTP/I lets these mechanisms link into the RTP/I header. It 201 specifically grants the reliability mechanisms the right to place 202 additional flags and fields into the RTP/I framing information. This 203 leads to the typical benefits of ILP, namely the avoidance of 204 redundant header information as well as a reduction of copy 205 operations. Furthermore RTP/I also allows reliability mechanisms to 206 transmit additional messages that might be required, e.g. to detect 207 tail loss. With this approach RTP/I provides support for applications 208 following the ALF/ILP principles in addition to enabling the 209 development of generic services and functionality. 211 An ALF/ILP oriented reliability mechanism that is used together with 212 RTP/I is specified in an RTP/I reliability mapping document. This 213 document completely defines the employed mechanism and its 215 RTP/I December 1999 217 cooperation with RTP/I. It MAY do so by referencing an existing 218 specification of the reliability mechanism and by providing 219 information on how it cooperates with RTP/I. This includes the 220 mapping of the information provided by RTP/I to the information 221 required by the reliability mechanism, the specification of any 222 additional information that is to be stored in the RTP/I framing, and 223 the definition of any additional packet types that may be required. 224 Each RTP/I reliability mapping MUST be assigned a unique number in 225 the range of 2-63 by IANA. There exist two special reliability 226 mechanisms that can be used with RTP/I. The first one is no 227 reliability (e.g. for battlefield simulations or telepointers) and 228 the second one is the usage of a reliable transport protocol which is 229 transparent to the application. These mechanisms are assigned the 230 numbers 0 and 1, respectively. 232 RTP/I is not a complete protocol. It needs to be adapted to the 233 requirements of a specific medium or a group of media. This is done 234 using two additional types of documents besides the reliability 235 mapping: 237 o a payload type definition is a specification document that defines 238 how a particular medium is transported using the framework provided 239 by RTP/I. Essentially a payload type definition describes how the 240 medium specific data is encoded. It MAY also define how consistency 241 is ensured if this is not done by a profile under which the payload 242 type operates. 244 o a profile adapts RTP/I to the needs of a group of distributed 245 interactive media. It MAY provide additional fields for the framing 246 of the data as well as new control packet types. A profile is 247 usually defined for media that share a common way to achieve 248 consistency. Examples of media that may belong to the same class 249 are military battlefield simulations and networked action games. 250 Another profile could be defined for a sub-class of shared 251 workspace applications. 253 With this flexibility, generic services and functionality can be 254 developed on three levels. They can be fully generic services usable 255 for all RTP/I based applications, they can be services that are 256 useful for certain RTP/I profiles or they may be defined for a number 257 of RTP/I payloads. 259 The remainder of this document is structured as follows. Section 260 Three defines the scope of this document by identifying the 261 distributed media class for which it should be used. Section Four 262 contains a definition of the media model upon which RTP/I is based. 263 Here the main concepts of distributed interactive media are 264 discussed. The byte order and timestamp format is given in Section 265 Five. In Section Six the RTP/I data protocol is specified. The RTP/I 266 data protocol is used to transport the information that is required 267 to distribute the medium itself. The RTP/I control protocol (RTCP/I) 269 RTP/I December 1999 271 is defined in Section Seven. It is used to transport meta information 272 about the medium and the participants of a session. Section Eight 273 deals with security for RTP/I. How to transport RTP/I over transport 274 services is described in Section Nine. Sections Ten to Thirteen 275 contain an overview over the protocol constants, IANA considerations, 276 the copyright statement, and the authors addresses. 278 3. RTP/I Scope 280 In order to define the scope of RTP/I, we separate distributed media 281 types by means of two criteria. The first criterion distinguishes 282 whether the medium is discrete or continuous. The characteristic of a 283 discrete medium is that its state is independent of the passage of 284 time. Examples of discrete media are still images or digital 285 whiteboard presentations. While discrete media may change their 286 state, they do so only in response to external events, such as a user 287 drawing on a digital whiteboard. 289 The state of a continuous medium, however, depends on the passage of 290 time and can change without the occurrence of external events. Video 291 and animations belong to the class of continuous media. 293 The second criterion distinguishes between interactive and non- 294 interactive media. Non-interactive media change their state only in 295 response to the passage of time and do not accept external events. 296 Typical representations of non-interactive media are video, audio and 297 images. 299 Interactive media are characterized by the fact that their state can 300 be changed by external events such as user interactions. Whiteboard 301 presentations and distributed virtual environments represent 302 interactive media. 304 While the real time protocol RTP is a suitable protocol for the 305 transportation of continuous non-interactive media, it is not 306 appropriate to support distribute interactive media [Per99]. RTP/I is 307 therefore defined as an application level protocol for distributed 308 interactive media, both continuous and discrete. RTP/I reuses aspects 309 of RTP whenever possible, however, it is specifically tailored to the 310 needs of distributed interactive media. 312 4. Model for Distributed Interactive Media 314 4.1. States and Events 316 A distributed interactive medium has a state. For example, at any 317 given point in time the state of a shared whiteboard is defined by 318 the content of all pages present in the shared whiteboard. In order 319 to perceive the state of a distributed interactive medium a user 320 needs an application, e.g. a shared whiteboard application is 322 RTP/I December 1999 324 required to see the pages of a shared whiteboard presentation. This 325 application generally maintains a local copy of (parts of) the 326 medium's state. For all applications participating in a session the 327 local state of the medium should be at least reasonably similar. It 328 is therefore necessary to synchronize the local copies of the 329 distributed interactive medium's state among all participants, so 330 that the overall state of the medium is consistent. 332 The state of a distributed interactive medium can change for two 333 reasons, either by passage of time or by events. The state of the 334 medium between two successive events is fully deterministic and 335 depends only on the passage of time. Generally, a state change caused 336 by the passage of time does not require the exchange of information 337 between applications, since the application of each user can 338 calculate the required state changes independently. An example of a 339 state change caused by the passage of time is the animation of an 340 object moving across the screen. 342 Any state change that is not a fully deterministic function of time 343 is caused by an event. Events can be separated into external events 344 and internal events. External events are (user) interactions with the 345 medium, e.g. the user makes an annotation on a shared whiteboard 346 page. Internal events are non-deterministic state changes of the 347 medium, such as generating a random number. Whenever events occur, 348 the state of the medium is in danger of becoming inconsistent because 349 the local copies of the state could run out of synchronization with 350 the remote copies. Therefore, an event usually requires that the 351 applications exchange information - either about the event itself or 352 about the updated state after the event has taken place. 354 4.2. Partitioning the Medium - Sub-Components 356 In order to provide for a flexible and scalable handling of state 357 information, it is often desirable to partition an interactive medium 358 into several sub-components. In addition to breaking down the 359 complete state of an interactive medium into more manageable parts, 360 such partitioning allows participants of a session to track only the 361 states of those sub-components they are actually interested in. 362 Examples of sub-components are 3D objects (e.g. a house, a car, a 363 room) in a distributed virtual environment or the pages of a shared 364 whiteboard. Events, external as well as internal, have a target sub- 365 component which they affect. Other sub-components than the target are 366 not affected by an event. 368 It is important to notice that sub-components must be independent of 369 each other, since some applications might track only the state of a 370 subset of all available sub-components. Sub-component A is said to be 371 independent of sub-component B if the state of B does influence the 372 state of A only by means of events. While the independence of sub- 373 components is usually guaranteed for a medium like a shared 374 whiteboard, other media require the generation of pseudo events in 376 RTP/I December 1999 378 order to ensure that sub-components are independent of each other. 379 For example, in a distributed car race where the cars are the sub- 380 components of the medium, pseudo events would occur if cars bump into 381 each other. As for internal and external events, pseudo events 382 generally require that the applications exchange either information 383 about the event itself, or about the updated state after the event 384 has taken place. Otherwise the consistency of the overall medium 385 might be damaged. 387 4.3. Environment 389 While it would be conceivable to declare all information which is 390 required by the application to display the distributed interactive 391 medium, to be part of the medium's state, this is generally not 392 desirable. Usually a substantial part of this information remains 393 constant over the course of a session. We call this part of the 394 information the environment of a distributed interactive medium. 395 Examples for environments are the base world descriptions of 396 distributed virtual environments, or the postscript slides of shared 397 whiteboard presentations. Since the environment stays constant, there 398 are no mechanisms required to synchronize it among the participants 399 of a session - the environment information just needs to be received 400 once by each participant. It is therefore a good idea to make the 401 environment part of the medium data as large as possible and to 402 minimize the amount of state information. The distinction between 403 state and environment information is situation dependent - a 404 participant might choose to introduce a new postscript slide into an 405 ongoing shared whiteboard presentation, which makes this page part of 406 the medium's state. It is therefore the task of the application 407 designer to distinguish between state and environment information. 408 Since the environment is a discrete non-interactive medium we do not 409 further investigate how the environment is shared between 410 participants. For the remainder of this memorandum we merely assume 411 that the environment is present for all participant's applications 412 (e.g. by using multi-destination file transfer or by means of an 413 off-line distribution on CD or DVD). 415 5. Byte Order, Alignment, and Time Format 417 All integer fields are carried in network byte order, that is, most 418 significant byte (octet) first. This byte order is commonly known as 419 big-endian. The transmission order is described in detail in [Pos81]. 420 Numeric constants are given in decimal representation. All header 421 data is aligned to its natural length, i.e., 16-bit fields are 422 aligned on even offsets, 32-bit fields are aligned at offsets 423 divisible by four, etc. Octets designated as padding have the value 424 zero. The timestamps of RTP/I are 32 bit fields. They represent the 425 milliseconds passed since 0h UTC on 1 January 1900. Timestamp values 426 may wrap. Participants of an RTP/I session SHOULD have a sufficiently 427 synchronized clock, so that they can identify the current timestamp 428 cycle. Further constraints on the synchronization of the 430 RTP/I December 1999 432 participants' clocks may be made in a profile or a payload type 433 specification. 435 6. RTP/I Data Transfer Protocol 437 The bulk of data for a distributed interactive medium - states, 438 events and requests for state information - are carried in RTP/I data 439 packets. Essentially RTP/I data packets contain medium specific 440 information which is framed by common header fields. In RTP/I there 441 are four distinct data packet types: event, state, delta state, and 442 state query. All four share the same packet header. A particular 443 RTP/I payload or an RTP/I profile may specify that only a subset of 444 these data packet types is to be used for a given medium or a group 445 of media. 447 6.1. RTP/I Event Packet Type 449 The event packet type is used by an application to transmit events to 450 peer applications. The RTP/I event packet type has the following 451 fixed header: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |V=0|E|X| TYPE | PT | length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | RT |PRI| PI | RI | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | participant identifier (PID) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | subcomponent identifier (SUBID) most significant word | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | subcomponent identifier (SUBID) least significant word | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | sequence number | fragment count | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | timestamp | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 version (V): 2 bits 472 This field holds the version number. The version defined by this 473 specification is version 0. 475 end (E): 1 bit 476 This bit is set, if and only if the packet is the last packet of 477 an ADU. 479 reliability header extension (X): 1 bit 480 If this bit is set, the fixed RTP/I header, as shown above, MUST 481 be followed by exactly one header extension that is used for 482 reliability purposes. The format of this extension is specified 484 RTP/I December 1999 486 in Section 6.5. The extension mechanism MUST NOT be used for 487 other purposes than to convey reliability information. If 488 additional information is required for a subclass of distributed 489 interactive media, then a profile SHOULD be used to extend the 490 framing information. If the additional information is relevant 491 to all distributed interactive media, then a new RTP/I version 492 SHOULD be specified which includes this information. 494 type (TYPE): 4 bits 495 This field identifies the type of the ADU the packet belongs to. 496 RTP/I specifies four packet type values: 0 for event packets, 1 497 for state packets, 2 for delta state packets, and 3 for state 498 query packets. Future versions of RTP/I MAY define additional 499 types for the values 4, 5, 6, and 7. The values 8 - 15 MAY be 500 used by ALF/ILP oriented reliability approaches to identify 501 additional packets. They MUST NOT be used for the transmission 502 of media related packets. The type field MUST carry the same 503 value for all packets belonging to one ADU. 505 payload type (PT): 8 bits 506 This field identifies the format of the RTP/I payload and 507 determines its interpretation by the application. A profile MAY 508 specify a default static mapping of payload type codes to 509 payload formats. Additional payload type codes MAY be defined 510 dynamically through non-RTP/I means. The payload type of a 511 medium MAY change during a session. The payload type field 512 SHOULD NOT be used for multiplexing the streams of separate 513 media. A receiver MUST ignore packets with payload types that it 514 does not understand. The payload type field MUST carry the same 515 value for all packets belonging to one ADU. 517 length: 16 bits 518 The length field specifies the length of this packet in octets, 519 excluding the 28 octet fixed RTP/I header, including any 520 reliability or profile specific header extensions. It can be 521 used to stack multiple RTP/I data packets in one transport 522 packet. If the length is no multiple of 4, then a minimal amount 523 of padding octets MUST be appended to the packet so that the 524 total length of the packet including the padding octets is a 525 multiple of 4. These padding octets MUST NOT be included in the 526 size of the packets as expressed in the length field. The last 527 RTP/I packet contained in a transport packet MAY choose not to 528 use padding octets, even if it does not have a size which is a 529 multiple of 4 octets. 531 reliability type (RT): 6 bits 532 This field identifies how reliability is established for the 533 packet. Reliability type 0 is used when the data transmission is 534 unreliable. Reliability type 1 is used when the packet is 535 transmitted over a reliable transport protocol. The meaning of 536 other RT values is defined in RTP/I reliability mapping 538 RTP/I December 1999 540 documents. RT values are assinged by IANA. A profile 541 specification SHOULD specify which reliability types are usable 542 with the profile. The reliability type MAY change during a 543 session. The reliability type field MUST carry the same value 544 for all packets belonging to one ADU. 546 priority (PRI): 2 bits 547 This field is not used for events. 549 reserved for profile information (PI): 8 bits 550 This field MAY be used to transport profile specific 551 information. The usage of this field is specified in profile 552 specification documents. It MUST NOT be used by reliability 553 mechanisms. 555 reserved for reliability information (RI): 16 bits 556 This field MAY be used by reliability mechanisms to hold 557 additional information. The use of this field is specified in 558 RTP/I reliability mapping documents. This field MUST NOT be used 559 for other purposes. 561 participant identifier (PID): 32 bits 562 The participant identifier MUST uniquely identify a participant. 563 This participant is the original sender of the packet. How to 564 choose PIDs is outside the scope of RTP/I. A PID MUST be 565 persistent for the lifetime of a session. In particular, the 566 restart of an application MUST NOT change the PID of the 567 participant. If an application requires multiple RTP/I sessions 568 (e.g. because multiple distributed interactive media are 569 involved, or because a single medium is distributed across 570 multiple sessions) then the PID SHOULD be the same for the 571 participant in all these RTP/I sessions. 573 sub-component identifier (SUBID): 64 bits 574 The sub-component identifier MUST uniquely identify a sub- 575 component. In event packets the SUBID identifies the target 576 sub-component of the event. How to choose SUBIDs is outside the 577 scope of RTP/I. A SUBID MUST be persistent for the lifetime of a 578 session. If an application requires multiple RTP/I sessions 579 (e.g. because a single medium is distributed across multiple 580 sessions) then the SUBID SHOULD be the same for the same sub- 581 component in all these RTP/I sessions. 583 sequence number: 16 bits 584 There are independent sequence numbers for each sub-component 585 and packet type (i.e. events, state, delta states and state 586 queries). For each transmitted full ADU the appropriate sequence 587 number is incremented by one. The sequence number field MUST 588 carry the same value for all packets belonging to one ADU. 590 fragment count: 16 bits 592 RTP/I December 1999 594 In the case that an ADU does not fit into a single network layer 595 packet, the application SHOULD fragment the data, in order to 596 avoid inefficient network-level fragmentation. A single ADU may 597 therefore consist of more than one packet. The fragment count 598 for each ADU starts with 0 and is incremented by one for each 599 packet sent for this ADU by a participant. A receiver knows that 600 it has received all parts of a fragmented ADU when it has 601 received a packet with the fragment count 0, a packet with the E 602 bit set and all fragments in between the fragment count of both 603 packets. A single ADU MUST NOT consist of more than (2^16-1) 604 fragments. 606 timestamp: 32 bits 607 The timestamp value is expressed as milliseconds that have 608 passed since 0h UTC on 1 January 1900 modulo 2^32. For an event 609 the timestamp specifies the time at which an event is applied to 610 the target sub-component. The timestamp MUST be based on a 611 physical clock. The physical clocks of all participants SHOULD 612 be synchronized via external means such as NTP [Mil92] or GPS. A 613 profile or payload type specification MAY limit the maximal 614 allowed time offset between any two participants in a session 615 and the resolution of the clock. The timestamp MAY be used to 616 establish a global ordering on the ADUs transmitted by all 617 participants of a session. For each medium transported over 618 RTP/I a profile or the payload type definition SHOULD therefore 619 specify the interpretation of ADUs that bear the same timestamp. 620 The timestamp field MUST carry the same value for all packets 621 belonging to one ADU. 623 The RTP/I header (including reliability header extension and profile 624 specific extensions) is followed by the payload type specific data 625 describing the event. 627 6.2. RTP/I State Packet Type 628 The state packet type is used by an application to transmit the full 629 state of a sub-component. The RTP/I state packet type header has the 630 same structure as the event packet type header. The following fields 631 are interpreted in a different way than for the event packet type: 633 priority (PRI): 2 bits 634 This field identifies the priority of the state transmission. A 635 state transmitted with priority 3 MUST be adopted by the 636 recipients. A state transmitted with priority 0 MAY be adopted 637 by the recipients. The meaning of the values 1 and 2 MAY be 638 specified in a profile or a payload type definition. This field 639 is required because setting the state of a sub-component can be 640 costly and might not always be reasonable for all participants. 641 Situations where priority 3 is recommended are re- 642 synchronization after errors or packet loss. A state 643 transmission with priority 3 forces every participant to discard 644 its information about the sub-component and requires the 646 RTP/I December 1999 648 adoption of the new state. A state transmitted with priority 0 649 can be ignored at will by any participant. This is useful if 650 only a subset of communication partners is interested in the 651 state. An example of this case are late joins where only 652 applications joining the session might be interested in certain 653 state transmission. All state packets belonging to the same ADU 654 MUST carry the same priority. 656 sub-component identifier (SUBID): 64 bits 657 The SUBID identifies the sub-component to which the state 658 contained in the packet belongs. 660 timestamp: 32 bits 661 For a STATE packet the timestamp specifies the time at which the 662 state was extracted from the sub-component. All STATE packets 663 belonging to the same ADU MUST carry the same timestamp. 665 6.3. RTP/I Delta State Packet Type 667 In cases where a complex sub-component state of an interactive medium 668 is transmitted frequently by an application, it may be desirable to 669 be able to send only those parts of a state that have changed since 670 the last state transmission. This is similar to the concept of P 671 frames in an MPEG encoded video stream. RTP/I supports this by 672 providing a delta state packet type. A delta state ADU (possibly 673 consisting of more than one packet) can only be interpreted if the 674 preceding state ADU is also available. The main advantages of delta 675 state ADUs are their smaller size and that they can be calculated 676 faster than state ADUs. The RTP/I delta state packet type header is 677 the same as the state packet type header. The only difference is the 678 value of the TYPE field which is 2 for delta state packets. 680 6.4. RTP/I State Query Packet Type 682 In a number of situations an application or a generic service might 683 need to get the current state of a certain sub-component. Examples 684 for these situations are: as means of resynchronization if an event 685 has been lost or received late, as access point for random-access in 686 a distributed interactive media recorder, or as an initial state for 687 a late-comer joining an ongoing session. Since this functionality is 688 universally needed for many distributed interactive media it is 689 supported directly by a state query packet type. 691 A state query packet is used by a participant to indicate that it 692 desires the transmission of a certain sub-component's state. The 693 structure of the state query packet type is the same as for all RTP/I 694 data packets. However, it does not contain any medium specific data. 696 Instead of being a regular request - as found in other protocols - a 697 state query packet is only an indication to the receivers that a 698 participant would like to get the state of the concerned sub- 700 RTP/I December 1999 702 component. A regular request/reply mechanism would be inappropriate 703 for a protocol that should scale well in a multicast environment. The 704 decision whether any given receiver of a state query packet does 705 reply is made locally by the receiver. This decision is influenced by 706 the value contained in the priority field and SHOULD be made in a way 707 that prevents a reply implosion if multicast is used. In addition, 708 state query packets SHOULD be issued in a way that avoids state query 709 implosions in a multicast environment. 711 The fields in a state query packet type are interpreted as for event 712 packets with the following exceptions: 714 end (E): 1 bit 715 This bit is always set for state query packets. 717 length: 16 bits 718 The length of a state query packet is always 28 + any 719 reliability and profile specific header extension bytes. 721 priority (PRI): 2 bits 722 The meaning of the priority contained in a state query packet is 723 as follows: 725 o Priority 3 is used when the request needs to be satisfied 726 immediately, e.g for resynchronization after errors. 728 o Priority 2 is used when a response is required, but a short 729 delay is acceptable, e.g. for a late join service. 731 o Priority 1 is used when a response is desirable but not 732 required, e.g. pre-fetching of sub-component state, which 733 might be needed later. 735 o Priority 0 is used when the state request is issued 736 periodically, e.g. for a recording service. 738 sub-component identifier (SUBID): 64 bits 739 The SUBID identifies the sub-component that the sender wants to 740 receive a state of. 742 timestamp: 32 bits 743 The timestamp of a STATE_QUERY packet specifies the time at 744 which the application generated the query. 746 6.5. Multiplexing RTP/I Sessions 748 As with RTP [Sch99] the multiplexing of multiple RTP/I streams is 749 provided by the transport destination address of the stream (network 750 address and port number). A session involving more than one 751 distributed interactive medium SHOULD transmit the data for the 752 different media to separate transport addresses. Separate media 754 RTP/I December 1999 756 streams SHOULD NOT be carried in a single RTP/I session. 758 6.6. RTP/I and ALF/ILP Oriented Reliability Mechanisms 760 Many fields of the RTP/I data packet header are directly useful for 761 ALF/ILP oriented reliability mechanisms. The information contained in 762 the RTP/I header fields SHOULD NOT be duplicated for reliability 763 purposes. Instead the reliability mechanism SHOULD link into the 764 RTP/I header and directly reuse the information of the RTP/I header 765 fields. However the reliability mechanisms MUST NOT modify any of the 766 fields besides the X flag, the RT field, the 16 bits field reserved 767 for reliability purposes, and the reliability header extension (if 768 present). 770 The X flag SHOULD only be set if the reliability mechanism specified 771 by the RT field requires more information than can be fit into the 16 772 bits reserved for reliability purposes. If the X flag is set, the 773 timestamp in the RTP/I header MUST be followed by a header extension: 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | length | additional information ... | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 The length field specifies the length of the header extension in 782 multiples of 4 octets, excluding the first 4 octets. Therefore a 783 length value of 0 is valid. The additional information for 784 reliability purposes follows the length field of the header 785 extension. 787 6.7. Profile-Specific Modifications to the RTP/I header 789 The existing RTP/I data packet header is believed to be complete for 790 the set of functions required in common across all the applications 791 that RTP/I might use. However, in keeping with the ALF design 792 principle, the header MAY be tailored to the needs of a specific 793 distributed interactive media sub-class. This tailoring MUST be done 794 in a way that allows generic services and functionality to work for 795 the new profile. Specifically a profile MUST preserve the semantics 796 of the four packet types and it MUST NOT define new RTP/I data packet 797 types. 799 Additional information that is required for a particular payload 800 format SHOULD be carried in the payload section of the packet. This 801 might be in a header that is always present at the start of the 802 payload section, or might be indicated by a reserved value in the 803 data pattern. 805 If a particular sub-class of distributed interactive media needs 806 additional information that do not fit into the 8 bits reserved for 808 RTP/I December 1999 810 this purpose and which are independent of the payload format, then 811 the profile for this sub-class SHOULD define additional RTP/I data 812 packet header fields. These fields SHOULD follow the reliability 813 extension header, if it is present. If no reliability extension 814 header is present, the additional fields SHOULD follow the timestamp 815 field of the RTP/I data packet header. This allows profile 816 independent services to work properly in the presence of profile 817 specific additional header fields. 819 If it turns out that additional information is needed in common 820 across all profiles, then a new version of RTP/I SHOULD be defined to 821 make a permanent change to the RTP/I data packet header. 823 7. RTP/I Control Protocol -- RTCP/I 825 The RTP/I control protocol (RTCP/I) is based on the periodic 826 transmission of control packets to all participants in a session, 827 using the same distribution mechanism as the data packets. Because of 828 the redundancy included in this approach, RTCP/I does not require any 829 additional reliability mechanisms. The underlying protocol MUST 830 provide multiplexing of the data and control packets, for example 831 using separate port numbers with UDP. RTCP/I provides three main 832 functions: 834 1. It provides meta information about the sub-components, e.g. 835 application level names for sub-components and whether a sub- 836 component is currently needed to display the medium to the users. 838 2. It conveys information about the participants of a session. This 839 information includes a human-readable unique participant 840 identifier (the CNAME). The CNAME can be used to let RTP/I 841 cooperate with RTP. 843 3. The first two functions require that all participants send RTCP/I 844 packets, therefore the rate must be controlled in order for RTP/I 845 to scale up to a large number of participants. By monitoring the 846 control packets of the other participants, it is possible to 847 estimate the overall number of participants and the average size 848 of RTCP/I packets. These numbers are used to calculate the rate at 849 which RTCP/I packets are sent by individual applications. 851 7.1. RTCP/I Packet Composition 853 This specification defines four packet types for the RTP/I control 854 protocol: 856 SUBREP (subcomponent report): used to report on the sub-components 857 present in a session. This includes information on the sub-component 858 status and application level names for sub-components. 860 SDES (source description): used to convey participant description 862 RTP/I December 1999 864 items, such as participant name, email, location, etc. Of particular 865 interest is the CNAME, a human readable, unique identifier which can 866 be used to identify participants across RTP and RTP/I sessions. 868 BYE: indicates the end of participation. 870 APP (application): used to carry application specific information. 872 In RTCP/I there are no packets that report on the reception quality 873 of individual participants. The reason for this is that RTP/I may be 874 used over, or in combination with, reliability mechanisms that do 875 packet retransmissions. It would therefore not be appropriate to 876 convey information about packet loss rates, latency and jitter in 877 RTCP/I packets. Instead the reliability mechanisms are expected to 878 provide this information. In the case that a given sub-class of 879 distributed interactive media does not use retransmission oriented 880 reliability (e.g battlefield simulations) an RTP/I profile MAY 881 specify reception quality reports as a profile specific extension to 882 RTCP/I. 884 RTCP/I packets are transmitted in compound packets. Each compound 885 packet MUST contain a SDES packet as the first RTCP/I packet. It MAY 886 also contain other RTCP/I packets. This structure allows to verify 887 that a correct RTCP/I packet has been received and not a mis- 888 addressed non-RTCP/I packet. 890 An implementation SHOULD ignore incoming RTCP/I packets with types 891 unknown to it. Additional RTCP/I packet types may be registered with 892 the Internet Assigned Numbers Authority (IANA) as described in 893 Section 11. 895 7.2. RTCP/I Transmission Interval 897 RTCP/I is designed to scale over session sizes ranging from only a 898 few participants to large groups of participants. As with the control 899 protocol of RTP [Sch99] this requires that the rate at which RTCP/I 900 compound packets are sent by individual applications decreases with 901 the number of participants and the average size of the RTCP/I 902 compound packets. 904 For each session we assume that the bandwidth available for RTCP/I 905 usage is set to a fixed maximum amount. This amount includes network 906 and transport headers, since this is the value that resource 907 reservation systems need to know. The available bandwidth for RTCP/I 908 usage MAY be a small and known fraction of the total bandwidth 909 available for the session, or it MAY be specified explicitly via 910 external means, such as a session announcement facility. 912 In multicast environments the transmission of RTCP/I packets MUST be 913 scheduled in a way so that the overall average RTCP/I data-rate of 914 the whole session is unlikely to exceed the amount of bandwidth 916 RTP/I December 1999 918 available for RTCP/I. Typically such a scheduling algorithm 919 calculates the transmission interval between two RTCP/I packets from 920 the same participant based on the maximum available bandwidth for 921 RTCP/I usage, the number of participants, and the average size of 922 RTCP/I packets. In addition there SHOULD be a minimum value set for 923 the transmission interval. This avoids bursty traffic when the 924 traffic generated by a small group is not smoothed according to the 925 law of large numbers. The RECOMMENDED value for this minimal 926 transmission interval is 5 seconds. Profiles MAY specify a different 927 minimal value. In unicast sessions involving only two participants 928 the applications MAY choose to transmit RTCP/I packets at a fixed 929 rate. 931 The algorithm described in Section 7.3 demonstrates how the 932 transmission of RTCP/I packet can be scheduled so that RTCP/I remains 933 scalable. It is an adaptation of the algorithm used for RTCP [Sch99] 934 and exhibits the same characteristics: 936 o The calculated interval between RTCP/I packets scales linearly with 937 the number of members in the group. It is this linear factor which 938 allows for a constant amount of control traffic when summed across 939 all members. 941 o The interval between RTCP/I packets is varied randomly over the 942 range [0.5,1.5] times the calculated interval to avoid unintended 943 synchronization of all participants [Flo93,Flo94]. The first RTCP/I 944 packet sent after joining a session is also delayed by a random 945 variation of half the minimum RTCP/I interval. 947 o A dynamic estimate of the average compound RTCP/I packet size is 948 calculated, including all those received and sent, to automatically 949 adapt to changes in the amount of control information carried. 951 o Since the calculated interval depends on the number of observed 952 group members, there may be undesirable start-up effects when a new 953 user joins an existing session, or many users simultaneously join a 954 new session. These new users will initially have incorrect 955 estimates of the group membership, and thus their RTCP/I 956 transmission interval will be too short. This problem can be 957 significant if many users join the session simultaneously. To deal 958 with this, an algorithm called "timer reconsideration" is employed. 959 This algorithm implements a simple back-off mechanism which causes 960 users to hold back RTCP/I packet transmission if the group sizes 961 are increasing. 963 o When users leave a session, either with a BYE or by timeout, the 964 group membership decreases, and thus the calculated interval should 965 decrease. A "reverse reconsideration" algorithm is used to allow 966 members to more quickly reduce their intervals in response to group 967 membership decreases. 969 RTP/I December 1999 971 o BYE packets are given different treatment than other RTCP/I 972 packets. When a user leaves a group, and wishes to send a BYE 973 packet, it may do so before its next scheduled RTCP/I packet. 974 However, transmission of BYE's follows a back-off algorithm which 975 avoids floods of BYE packets should a large number of members 976 simultaneously leave the session. 978 7.2.1. Maintaining the number of session members 980 Calculation of the RTCP/I packet interval depends upon an estimate of 981 the number of sites participating in the session. New sites are added 982 to the count when they are heard, and an entry for each SHOULD be 983 created in a table indexed by the PID to keep track of them. Entries 984 MAY be deleted from the table when an RTCP/I BYE packet with the 985 corresponding PID is received, except that some straggler data 986 packets might arrive after the BYE and cause the entry to be 987 recreated. Instead, the entry SHOULD be marked as having received a 988 BYE and then deleted after an appropriate delay. 990 A participant MAY mark another site inactive if no RTP/I or RTCP/I 991 packet has been received for a small number of RTCP/I report 992 intervals (5 is RECOMMENDED). This provides some robustness against 993 packet loss. All sites MUST have the same value for this multiplier 994 and must calculate roughly the same value for the RTCP/I report 995 interval in order for this timeout to work properly. Therefore, this 996 multiplier SHOULD be fixed for a particular profile. 998 For sessions with a very large number of participants, it may be 999 impractical to maintain a table to store the PID and state 1000 information for all of them. An implementation MAY use a sampling 1001 approach, as described for RTP in [Ros98], to reduce the storage 1002 requirements. An implementation MAY use any other algorithm with 1003 similar performance. A key requirement is that any algorithm 1004 considered SHOULD NOT substantially underestimate the group size, 1005 although it MAY overestimate. 1007 7.3. RTCP/I Packet Send and Receive Rules 1009 This section is an adaptation of Section 6.3 from Internet Draft 1010 ietf-avt-rtp-new-03.txt. The main difference is that there is no 1011 notion of active senders for distributed interactive media. The 1012 distinction between active senders and other participants is not 1013 required because in RTCP/I the PID is unique (and therefore the CNAME 1014 of active senders is not required as urgently as for RTP). 1016 The rules for how to send, and what to do when receiving an RTCP/I 1017 packet are outlined here. An implementation that allows operation in 1018 a multicast environment or a multi-point unicast environment MUST 1019 meet the scalability goals described in Section 7.2. Such an 1020 implementation MAY use an algorithm other than the one defined here 1021 so long as it provides equivalent or better performance. As mentioned 1023 RTP/I December 1999 1025 above an implementation that is constrained to two-party unicast 1026 operation MAY omit this algorithm. 1028 To execute these rules, a session participant must maintain several 1029 elements of state information: 1031 tp: the last time an RTCP/I packet was transmitted; 1033 tc: the current time; 1035 tn: the next scheduled transmission time of an RTCP/I packet; 1037 pmembers: the estimated number of session members at the time tn 1038 was last recomputed; 1040 members: the most current estimate for the number of session 1041 members; 1043 bw: The target RTCP/I bandwidth, i.e., the total bandwidth that 1044 will be used for RTCP/I packets by all members of this session, in 1045 bytes per second. 1047 avg_rtcpi_size: The average compound RTCP/I packet size, in 1048 octets, over all RTCP/I packets sent and received by this 1049 participant. 1051 initial: Flag that is true if the application has not yet sent an 1052 RTCP/I packet. 1054 Many of these rules make use of the "calculated interval" between 1055 packet transmissions. This interval is described in the following 1056 section. 1058 7.3.1. Computing the RTCP/I transmission interval 1060 To maintain scalability, the average interval between packets from a 1061 session participant should scale with the group size. This interval 1062 is called the deterministic calculated interval. It is obtained by 1063 combining a number of the pieces of state described above. The (non- 1064 deterministic) calculated interval T is then determined as follows: 1066 1. If the participant has not yet sent an RTCP/I packet (the 1067 variable initial is true), the constant Tmin is set to one half 1068 of the minimal report interval seconds (2.5 unless stated 1069 otherwise in the RTP/I profile), else it is set to the minimal 1070 report interval (5 unless stated otherwise in an RTP/I profile). 1072 2. The deterministic calculated interval Td is set to max(Tmin, 1073 members*avg_rtcpi_size/bw). 1075 3. The calculated interval T is set to a number uniformly 1077 RTP/I December 1999 1079 distributed between 0.5 and 1.5 times the deterministic 1080 calculated interval. 1082 4. The resulting value of T is divided by e-3/2=1.21828 to 1083 compensate for the fact that the unconditional reconsideration 1084 algorithm converges to an RTCP/I bandwidth value below the 1085 intended average. 1087 7.3.2. Initialization 1089 Upon joining the session, the participant initializes tp to the 1090 current time, pmembers to 1, members to 1, bw to the total amount of 1091 bandwidth available for RTCP/I, initial to true, and avg_rtcpi_size 1092 to the size of the RTCP/I compound packet that would be constructed 1093 if one where to be sent immediately. The calculated interval T is 1094 then computed, and the first packet is scheduled for time tn = T. 1095 This means that a transmission timer is set which expires at time T. 1096 Note that an application MAY use any desired approach for 1097 implementing this timer. 1099 The participant adds its own PID to the member table. 1101 7.3.3. Receiving an RTP/I or non-BYE RTCP/I packet 1103 When an RTP/I or RTCP/I packet is received from a participant whose 1104 PID is not in the member table, the PID is added to the table, and 1105 the value for members is updated. 1107 For each compound RTCP/I packet received, the value of avg_rtcpi_size 1108 is updated: avg_rtcpi_size = (1/16)*packet_size + (15/16)* 1109 avg_rtcpi_size, where packet_size is the size of the RTCP/I packet 1110 just received. 1112 7.3.4. Receiving an RTCP/I BYE packet 1114 Except as described in Section 7.3.7 for the case when an RTCP/I BYE 1115 is to be transmitted, if the received packet is an RTCP/I BYE packet, 1116 the PID is checked against the member table. If present, the entry is 1117 removed from the table, and the value for members is updated. 1118 Furthermore, to make the transmission rate of RTCP/I packets more 1119 adaptive to changes in group membership, the following "reverse 1120 reconsideration" algorithm SHOULD be executed when a BYE packet is 1121 received that reduces members to a value less than pmembers: 1123 o The value for tn is updated according to the following formula: 1124 tn = tc + (members/pmembers)(tn - tc). 1126 o The value for tp is updated according the following formula: 1127 tp = tc - (members/pmembers)(tc - tp). 1129 o The next RTCP/I packet is rescheduled for transmission at time tn, 1131 RTP/I December 1999 1133 which is now earlier. 1135 o The value of pmembers is set equal to members. 1137 This algorithm does not prevent the group size estimate from 1138 incorrectly dropping to zero for a short time due to premature time- 1139 outs when most participants of a large session leave at once but some 1140 remain. The algorithm does make the estimate return to the correct 1141 value more rapidly. This situation is unusual enough and the 1142 consequences are sufficiently harmless that this problem is deemed 1143 only a secondary concern. 1145 7.3.5. Timing Out a PID 1147 At occasional intervals, the participant MUST check to see if any of 1148 the other participants time out. To do this, the participant computes 1149 the deterministic calculated interval (without the randomization 1150 factor) Td. Any other session member who has not sent a packet since 1151 time tc - MTd (M is the timeout multiplier, and defaults to 5) is 1152 timed out. This means that its PID is removed from the member list, 1153 and members is updated. 1155 If any members time out, the reverse reconsideration algorithm 1156 described in Section 7.3.4 SHOULD be performed. 1158 The participant MUST perform this check at least once per RTCP/I 1159 transmission interval. 1161 7.3.6. Expiration of Transmission Timer 1163 When the packet transmission timer expires, the participant performs 1164 the following operations: 1166 o The transmission interval T is computed as described in Section 1167 7.3.1, including the randomization factor. 1169 o If tp + T is less than or equal to tc, an RTCP/I packet is 1170 constructed and transmitted. tp is set to tc, then another value 1171 for T is calculated as in the previous step and tn is set to tc + 1172 T. The transmission timer is set to expire again at time tn. If tp 1173 + T is greater than tc, tn is set to tp + T. No RTCP/I packet is 1174 constructed or transmitted. The transmission timer is set to expire 1175 at time tn. 1177 o pmembers is set to members. 1179 If an RTCP/I packet is transmitted, the value of initial is set to 1180 FALSE. Furthermore, the value of avg_rtcpi_size is updated: 1181 avg_rtcpi_size = (1/16)*packet_size + (15/16)* avg_rtcpi_size, where 1182 packet_size is the size of the RTCP/I packet just transmitted. 1184 RTP/I December 1999 1186 7.3.7. Transmitting a BYE Packet 1188 When a participant wishes to leave a session, a BYE packet is 1189 transmitted to inform the other participants of the event. In order 1190 to avoid a flood of BYE packets when many participants leave the 1191 session, a participant MUST execute the following algorithm if the 1192 number of members is more than 50 when the participant chooses to 1193 leave. This algorithm usurps the normal role of the members variable 1194 to count Bye packets instead: 1196 o When the participant decides to leave the session, tp is reset to 1197 tc, the current time, members and pmembers are initialized to 1, 1198 initial is set to true, and avg_rtcpi_size is set to the size of 1199 the BYE packet. The calculated interval T is computed. The BYE 1200 packet is then scheduled for time tn = tc + T. 1202 o Every time a BYE packet from another participant is received, 1203 members is incremented by 1 regardless of whether that participant 1204 exists in the member table or not, and when sampling is in use, 1205 regardless of whether or not the BYE would be included in the 1206 sample. members is NOT incremented when other RTCP/I packets or 1207 RTP/I packets are received, but only for BYE packets. 1209 o Transmission of the BYE packet then follows the rules for 1210 transmitting a regular RTCP/I packet, as above. 1212 This allows BYE packets to be sent right away, yet controls their 1213 total bandwidth usage. In the worst case, this could cause RTCP/I 1214 control packets to use twice the bandwidth as normal (10%) -- 5% for 1215 non-BYE RTCP/I packets and 5% for BYE packets. 1217 A participant that does not want to wait for the above mechanism to 1218 allow transmission of a BYE packet MAY leave the group without 1219 sending a BYE at all. That participant will eventually be timed out 1220 by the other group members. 1222 If the group size estimate members is less than 50 when the 1223 participant decides to leave, the participant MAY send a BYE packet 1224 immediately. Alternatively, the participant MAY choose to execute the 1225 above BYE backoff algorithm. 1227 In either case, a participant which never sent an RTP/I or RTCP/I 1228 packet MUST NOT send a BYE packet when they leave the group. 1230 7.4. RTCP/I Packet Formats 1232 7.4.1. RTPC/I Sub-Component Report Packet 1234 The RTCP/I sub-component report (SUBREP) packet is used to announce 1235 the sub-components present in a session, to indicate which sub- 1236 components are actively used to display the medium to the users, and 1238 RTP/I December 1999 1240 to provide information for the mapping from sub-component IDs to 1241 application level names. 1243 A report for a sub-component includes its current status: active or 1244 passive. The active sub-components of an application at any point in 1245 time are those sub-components which are required by the application 1246 to present the interactive medium at that specific time. A sub- 1247 component which is active for at least one participant should be 1248 reported as active for the session. 1250 An application level name allows an application to identify the sub- 1251 component. An application MAY use the application level name to 1252 decide whether it is interested in the sub-component without having 1253 received a state for that sub-component. A given payload type or 1254 profile MAY choose not to use the mapping for sub-component IDs to 1255 application level names. In this case the SUBREPS do not contain 1256 application level names. This can be reasonable if the state of sub- 1257 components is transmitted frequently or if the required information 1258 can be encoded in the sub-component ID. If a payload type or profile 1259 does not use the mapping as presented here it SHOULD NOT use a 1260 different algorithm for performing the mapping between application 1261 level names and sub-component IDs. This would prevent generic RTP/I 1262 based services from working properly. 1264 When a sub-component has not been reported by any participant for a 1265 certain number of report intervals, the sub-component is regarded as 1266 no longer present in the session (i.e. it timed out). This 1267 information MAY be used by generic services and applications to 1268 determine the set of sub-components present in a session. The 1269 RECOMMENDED value for the number of report intervals until a sub- 1270 component is timed out is 6. 1272 SUBREP packets SHOULD be transmitted so that each sub-component 1273 present in the session is, on average, reported once per report 1274 interval. This allows applications and generic services to get a 1275 quick overview of the sub-components, while it does not flood the 1276 network with duplicates of sub-component reports. The following 1277 algorithm is given as an example, other algorithms for sending SUBREP 1278 packets MAY be used. 1280 Every time when an RTPC/I packet is to be transmitted the participant 1281 checks whether any sub-components for which it tracks the state have 1282 not been reported by any other participant since tc-2*Td. All these 1283 unreported sub-components are then reported using a SUBREP packet. If 1284 a sub-component has been reported as passive by a remote application 1285 and that same sub-component is active for the local application, the 1286 local application reports that sub-component as active. This could 1287 result in two reports being sent for a single sub-component in a 1288 single report interval. However, this situation will not last, since 1289 the next time the remote application checks for sub-component 1290 reports, it will see the active report and will count that sub- 1292 RTP/I December 1999 1294 component as reported for the report interval. This algorithm is 1295 simple, robust, and scalable - in most cases each sub-component is 1296 reported only once per report interval, independent of the number of 1297 participants. 1299 The following brief calculation shows that the data-rate consumed by 1300 the announce/listen approach is acceptable, even with sessions that 1301 involve multiple hundrets of sub-components. Let us assume a rather 1302 large session with 1000 sub-components and with long application 1303 level names (20 bytes on average). Further we assume that at least 1304 every 60 seconds all mapping information should be available. 1305 Neglecting header information this would result in 1000*(20+8)=28000 1306 bytes that are transmitted for subcomomponent ID to application level 1307 name mapping. This is equivalent to a datarate of 28000*8/60=3.7 1308 kBit/s if this information is transmitted every 60 seconds. This 1309 seems reasonable for a large session. 1311 The format of the RTCP/I SUBREP packet is as follows: 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 |V=0|N| SC | TYPE | length | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | participant identifier (PID) | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 |A|A| ... | padding | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | subcomponent identifier 1 (SUBID) most significant word | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | subcomponent identifier 1 (SUBID) least significant word | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | name length 1 | application level name for SUBID 1 ... | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | subcomponent identifier 2 (SUBID) most significant word | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | subcomponent identifier 2 (SUBID) least significant word | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | name length 2 | application level name for SUBID 2 ... | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | ... | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 version (V): 2 bits 1338 These bits hold the RTCP/I version under which this packet was 1339 constructed. This memorandum specifies version 0 of RTCP/I. 1341 name (N): 1 bit 1342 This bit is set if and only if the sub-component IDs contained 1343 in this packet are followed by an application level name. 1345 RTP/I December 1999 1347 sub-component count (SC): 5 bits 1348 This field contains the number of reported sub-components in 1349 this packet. 1351 type: 8 bits 1352 This field identifies the type of the RTCP/I packet. For SUBREP 1353 packets the type is 70. RTCP/I type values of 80 and below are 1354 reserved for usage by future versions of RTCP/I. Profiles MAY 1355 specify additional RTCP/I packet types between 80 and 255. An 1356 example for such an additional RTCP/I packet could be reception 1357 quality reports for distributed interactive media which do not 1358 employ retransmissions in order to establish reliability. 1360 length: 16 bits 1361 The length field specifies the length of this packet in units of 1362 32 bits. It excludes the first two 32 bit words of the packet. 1364 participant identifier (PID): 32 bits 1365 This field contains the PID of the original sender of this 1366 packet. 1368 active (A): 1 bit per reported sub-component 1369 One active bit is present for each reported sub-component. The 1370 bit for a sub-component is set if and only if the sub-component 1371 is active. Following these bits are padding bits that pad the 1372 active bits to a 32 bit boundary. If the number of active bits 1373 is 32 then there are no padding bits. 1375 subcomponent identifier (SUBID): 64 bits per reported sub-component 1376 These are the subcomponent identifiers of the reported sub- 1377 components. They MUST occur in the same order as the active 1378 bits. 1380 name length: 8 bits 1381 This field is present for every reported sub-component if and 1382 only if the N bit is set. It contains the length of the 1383 application level name in octets. This length does not include 1384 any padding. 1386 application level name: size as indicated by name length 1387 This field is present for every reported sub-component if and 1388 only if the N bit is set. It contains the application level 1389 name. If the name does not end at a 32 bit boundary, then a 1390 minimal amount of padding octets are appended to the name so 1391 that a full 32 bit boundary is reached. 1393 7.4.2. RTCP/I Source Description Packet 1395 The RTCP/I source description packet (SDES) and the participant 1396 description items contained in this packet are almost identical to 1397 those used for RTCP. 1399 RTP/I December 1999 1401 0 1 2 3 1402 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 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 |V=0|R| IC | type | length | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | participant identifier (PID) | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | source description items | 1409 | ... | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 The SDES packet is a two-level structure composed of a header and 1413 items describing the source. The items are described individually in 1414 subsequent sections. 1416 version (V), length, and PID: 1417 As described for the SUBREP packet (see above). 1419 reserved (R): 1 bit 1420 This bit is reserved for use with future versions of RTP/I. 1422 item count (IC): 5 bits 1423 The number of participant description items contained in this 1424 packet. A SDES packet MUST contain at least one CNAME item. 1426 type: 8 bits 1427 Contains the constant 72 to identify this as an RTCP/I SDES 1428 packet. 1430 Each source description item consists of an 8-bit type field, an 8- 1431 bit octet count describing the length of the text (thus, not 1432 including this two-octet header), and the text itself. Note that the 1433 text can be no longer than 255 octets, but this is consistent with 1434 the need to limit RTCP/I bandwidth consumption. 1436 The text of a source description is encoded according to the UTF-8 1437 encoding specified in RFC 2279 [Yer98]. US-ASCII is a subset of this 1438 encoding and requires no additional encoding. The presence of multi- 1439 octet encodings is indicated by setting the most significant bit of a 1440 character to a value of one. 1442 Items are contiguous, i.e., items are not individually padded to a 1443 32-bit boundary. Text is not null terminated because some multi-octet 1444 encodings include null octets. Following the last item a minimal 1445 amount of padding octets MUST be appended to pad to the next 32-bit 1446 boundary. 1448 The SDES items currently defined are described in the next sections. 1449 Only the CNAME item is mandatory. Some items shown here may be useful 1450 only for particular profiles, but the item types are all assigned 1452 RTP/I December 1999 1454 from one common space to promote shared use and to simplify profile- 1455 independent applications. Additional items may be registered with the 1456 IANA. 1458 6.4.2.1 CNAME: Canonical end-point identifier participant description 1459 item 1461 0 1 2 3 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | CNAME=1 | length | user and domain name ... 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 The CNAME identifier MUST be included in each source description 1468 item, in order to ensure cooperation with distributed continuous 1469 non-interactive media that use RTP. It has the following properties: 1471 o Like the PID identifier, the CNAME identifier SHOULD be unique 1472 among all participants within one RTP/I session. It SHOULD be the 1473 same for a single participant that participates in multiple RTP and 1474 RTP/I sessions. 1476 o To provide a binding across multiple media tools used by one 1477 participant in a set of related RTP and RTP/I sessions, the CNAME 1478 SHOULD be fixed for that participant. 1480 o To facilitate third-party monitoring, the CNAME SHOULD be suitable 1481 for either a program or a person to locate the source. 1483 Therefore, the CNAME SHOULD be derived algorithmically and not 1484 entered manually, when possible. To meet these requirements, the 1485 following format SHOULD be used unless a profile specifies an 1486 alternate syntax or semantics. The CNAME item SHOULD have the format 1487 "user@host", or "host" if a user name is not available as on single- 1488 user systems. For both formats, "host" is either the fully qualified 1489 domain name of the host from which the real-time data originates, 1490 formatted according to the rules specified in RFC 1034 [Moc87a], RFC 1491 1035 [Moc87b] and Section 2.1 of RFC 1123 [Bra89]; or the standard 1492 ASCII representation of the host's numeric address on the interface 1493 used for the RTP/I communication. For example, the standard ASCII 1494 representation of an IP Version 4 address is "dotted decimal", also 1495 known as dotted quad. Other address types are expected to have ASCII 1496 representations that are mutually unique. The fully qualified domain 1497 name is more convenient for a human observer and may avoid the need 1498 to send a NAME item in addition, but it may be difficult or 1499 impossible to obtain reliably in some operating environments. 1500 Applications that may be run in such environments SHOULD use the 1501 ASCII representation of the address instead. 1503 Examples are "doe@sleepy.megacorp.com" or "doe@192.0.2.89" for a 1504 multi-user system. On a system with no user name, examples would be 1506 RTP/I December 1999 1508 "sleepy.megacorp.com" or "192.0.2.89". 1510 The user name SHOULD be in a form that a program such as "finger" or 1511 "talk" could use, i.e., it typically is the login name rather than 1512 the personal name. The host name is not necessarily identical to the 1513 one in the participant's electronic mail address. 1515 This syntax will not provide unique identifiers for each source if an 1516 application permits a user to generate multiple sources from one 1517 host. Such an application would have to rely on the PID to further 1518 identify the source, or the profile for that application would have 1519 to specify additional syntax for the CNAME identifier. 1521 If each application creates its CNAME independently, the resulting 1522 CNAMEs may not be identical as would be required to provide a binding 1523 across multiple media tools belonging to one participant in a set of 1524 related RTP/I and RTP sessions. If cross-media binding is required, 1525 it may be necessary for the CNAME of each tool to be externally 1526 configured with the same value by a coordination tool. 1528 6.4.2.2 NAME: User name participant description item 1530 0 1 2 3 1531 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 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | NAME=2 | length | common name of source ... 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 This is the real name used to describe the source, e.g., "John Doe, 1537 Bit Recycler, Megacorp". It may be in any form desired by the user. 1538 For applications such as conferencing, this form of name may be the 1539 most desirable for display in participant lists, and therefore might 1540 be sent most frequently of those items other than CNAME. Profiles MAY 1541 establish such priorities. The NAME value is expected to remain 1542 constant at least for the duration of a session. It SHOULD NOT be 1543 relied upon to be unique among all participants in the session. 1545 6.4.2.3 EMAIL: Electronic mail address participant description item 1547 0 1 2 3 1548 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 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | EMAIL=3 | length | email address of source ... 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 The email address is formatted according to RFC 822 [21], for 1554 example, "John.Doe@megacorp.com". The EMAIL value is expected to 1555 remain constant for the duration of a session. 1557 6.4.2.4 PHONE: Phone number participant description item 1559 RTP/I December 1999 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.2.5 LOC: Geographic user location participant description 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.2.6 TOOL: Application or tool name participant description 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 app. ... 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 A string giving the name and possibly version of the application 1597 generating the stream, e.g., "whiteboard 1.2". This information may 1598 be useful for debugging purposes and is similar to the Mailer or 1599 Mail-System-Version SMTP headers. The TOOL value is expected to 1600 remain constant for the duration of the session. 1602 6.4.2.7 NOTE: Notice/status SDES item 1604 0 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | NOTE=7 | length | note about the source ... 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 The following semantics are suggested for this item, but these or 1612 RTP/I December 1999 1614 other semantics MAY be explicitly defined by a profile. The NOTE item 1615 is intended for transient messages describing the current state of 1616 the source, e.g., "on the phone, can't talk". Or, during a seminar, 1617 this item might be used to convey the title of the talk. It should be 1618 used only to carry exceptional information and SHOULD NOT be included 1619 routinely by all participants because this would slow down the rate 1620 at which SUBREPs are sent, thus impairing the performance of the 1621 protocol. In particular, it SHOULD NOT be included as an item in a 1622 user's configuration file nor automatically generated as in a quote- 1623 of-the-day. 1625 Since the NOTE item may be important to display while it is active, 1626 the rate at which other non-CNAME items such as NAME are transmitted 1627 might be reduced so that the NOTE item can take that part of the 1628 RTCP/I bandwidth. When the transient message becomes inactive, the 1629 NOTE item SHOULD continue to be transmitted a few times at the same 1630 repetition rate but with a string of length zero to signal the 1631 receivers. However, receivers SHOULD also consider the NOTE item 1632 inactive if it is not received for a small multiple of the repetition 1633 rate, or perhaps 20-30 RTCP/I report intervals. 1635 6.4.2.8 PRIV: Private extensions participant description item 1637 0 1 2 3 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | PRIV=8 | length | prefix length | prefix string ... 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 This item is used to define experimental or application-specific 1645 participant description extensions. The item contains a prefix 1646 consisting of a length-string pair, followed by the value string 1647 filling the remainder of the item and carrying the desired 1648 information. The prefix length field is 8 bits long. The prefix 1649 string is a name chosen by the person defining the PRIV item to be 1650 unique with respect to other PRIV items this application might 1651 receive. The application creator might choose to use the application 1652 name plus an additional subtype identification if needed. 1653 Alternatively, it is RECOMMENDED that others choose a name based on 1654 the entity they represent, then coordinate the use of the name within 1655 that entity. 1657 Note that the prefix consumes some space within the item's total 1658 length of 255 octets, so the prefix should be kept as short as 1659 possible. This facility and the constrained RTCP/I bandwidth SHOULD 1660 NOT be overloaded; it is not intended to satisfy all the control 1661 communication requirements of all applications. 1663 SDES PRIV prefixes will not be registered by IANA. If some form of 1664 the PRIV item proves to be of general utility, it SHOULD instead be 1666 RTP/I December 1999 1668 assigned a regular SDES item type registered with IANA so that no 1669 prefix is required. This simplifies use and increases transmission 1670 efficiency. 1672 7.4.3. BYE: Goodbye RTCP/I packet 1674 0 1 2 3 1675 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 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 |V=0| reserved | type | length | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | participant identifier (PID) | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | reason length | reason for leaving ... | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 The BYE packet indicates that a participant is leaving a session. 1686 version (V), reserved, length, PID: 1687 As described for the source description packet (see above). 1689 type: 8 bits 1690 Contains the constant 71 to identify this as an RTCP/I BYE 1691 packet. 1693 reason length: 8 bits 1694 The reason length is optional and only present if a reason for 1695 leaving is included in the packet. It defines the length of the 1696 reason excluding any padding octets. 1698 reason for leaving: length as specified in reason length 1699 The reason field may contain an application specific description 1700 for the reason why a participant has left the session. It is 1701 followed by a minimal amount of padding octets that are 1702 necessary to pad the packet to a full 32 bit boundary. 1704 7.4.4. APP: Application-defined RTCP/I 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=0|R| subtype | type | length | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | participant identifier (PID) | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | name (ASCII) | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | application-dependent data ... 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 RTP/I December 1999 1720 The APP packet is intended for experimental use as new applications 1721 and new features are developed, without requiring packet type value 1722 registration. APP packets with unrecognized names SHOULD be ignored. 1723 After testing and if wider use is justified, it is RECOMMENDED that 1724 each APP packet be redefined without the subtype and name fields and 1725 registered with IANA using an RTCP/I packet type. 1727 version (V), reserved (R), length, participant identifier PID: 1728 As described for the source description packet (see above). 1730 subtype: 5 bits 1731 May be used as a subtype to allow a set of APP packets to be 1732 defined under one unique name, or for any application-dependent 1733 data. 1735 packet type (PT): 8 bits 1736 Contains the constant 73 to identify this as an RTCP/I APP 1737 packet. 1739 name: 4 octets 1740 A name chosen by the person defining the set of APP packets to 1741 be unique with respect to other APP packets this application 1742 might receive. The application creator might choose to use the 1743 application name, and then coordinate the allocation of subtype 1744 values to others who want to define new packet types for the 1745 application. Alternatively, it is RECOMMENDED that others choose 1746 a name based on the entity they represent, then coordinate the 1747 use of the name within that entity. The name is interpreted as a 1748 sequence of four ASCII characters, with uppercase and lowercase 1749 characters treated as distinct. 1751 application-dependent data: variable length 1752 Application-dependent data may or may not appear in an APP 1753 packet. It is interpreted by the application and not RTP/I 1754 itself. It MUST be a multiple of 32 bits long. 1756 7.5. Allocation of RTCP/I bandwidth 1758 As explained above, this specification defines several source 1759 description items in addition to the mandatory CNAME item. It also 1760 provides a means to define new application-specific RTCP/I packet 1761 types. Applications should exercise caution in allocating control 1762 bandwidth to this additional information because it will slow down 1763 the rate at which sub-component reports are sent, thus impairing the 1764 performance of the protocol. It is RECOMMENDED that no more than 20% 1765 of the RTCP/I bandwidth allocated to a single participant be used to 1766 carry the additional information. Furthermore, it is not intended 1767 that all source description items will be included in every 1768 application. Those that are included SHOULD be assigned a fraction of 1769 the bandwidth according to their utility. Rather than estimate these 1770 fractions dynamically, it is recommended that the percentages be 1772 RTP/I December 1999 1774 translated statically into report interval counts based on the 1775 typical length of an item. 1777 For example, an application may be designed to send only CNAME, NAME 1778 and EMAIL and not any others. NAME might be given much higher 1779 priority than EMAIL because the NAME would be displayed continuously 1780 in the application's user interface, whereas EMAIL would be displayed 1781 only when requested. At every RTCP/I interval, an SDES packet with 1782 the CNAME item would be sent. For a small session operating at the 1783 minimum interval, that would be every 5 seconds on the average. Every 1784 third interval (15 seconds), one extra item would be included in the 1785 ParticipantDescription packet. Seven out of eight times this would be 1786 the NAME item, and every eighth time (2 minutes) it would be the 1787 EMAIL item. 1789 When multiple applications operate in concert using cross-application 1790 binding through a common PID for each participant, for example in a 1791 multimedia conference composed of multiple RTP and RTP/I sessions for 1792 more than one medium, the additional participant description 1793 information MAY be sent in only one RTP or RTP/I session. The other 1794 sessions would carry only the CNAME item. In particular, this 1795 approach SHOULD be applied when a single distributed interactive 1796 medium is transmitted over multiple RTP/I sessions (e.g. a 1797 distributed virtual environment which is partitioned into several 1798 regions). 1800 8. Security 1802 Lower layer protocols may eventually provide all the security 1803 services that may be desired for applications of RTP/I, including 1804 authentication, integrity, and confidentiality. These services have 1805 been specified for IP in [Ken98]. An application MAY rely on these 1806 lower layer protocols to provide the required security. 1808 Alternatively, other services, other implementations of services and 1809 other algorithms MAY be defined for RTP/I in the future if warranted. 1810 Specifically, a profile MAY specify which services and algorithms 1811 should be offered by applications, and MAY provide guidance as to 1812 their appropriate use. 1814 9. RTP/I over Network and Transport Protocols 1816 This section describes issues specific to carrying RTP/I packets 1817 within particular network and transport protocols. The following 1818 rules apply unless superseded by protocol-specific definitions 1819 outside this specification. 1821 RTP/I relies on the underlying protocol(s) to provide demultiplexing 1822 of RTP/I data and RTCP/I control streams. For UDP and similar 1823 protocols, RTP/I SHOULD use an even port number and the corresponding 1824 RTCP/I stream SHOULD use the next higher (odd) port number. If an 1826 RTP/I December 1999 1828 application is supplied with an odd number for use as the RTP/I port, 1829 it SHOULD replace this number with the next lower (even) number. 1831 In a unicast session, applications SHOULD be prepared to receive 1832 RTP/I data and control on one port pair and send to another. 1834 It is RECOMMENDED that distributed interactive media that require 1835 more than one RTP/I session (e.g. for spatial partitioning in 1836 military battlefield simulations) use a set of contiguous port 1837 numbers. The port numbers MUST be distinct because of a widespread 1838 deficiency in existing operating systems that prevents use of the 1839 same port with multiple multicast addresses, and for unicast, there 1840 is only one permissible address. Thus for layer n, the data port is 1841 P + 2n, and the control port is P + 2n + 1. When IP multicast is 1842 used, the addresses MUST also be distinct because multicast routing 1843 and group membership are managed on an address granularity. However, 1844 allocation of contiguous IP multicast addresses cannot be assumed 1845 because some groups may require different scopes and may therefore be 1846 allocated from different address ranges. 1848 10. Summary of Protocol Constants 1850 This section contains a summary listing of the constants defined in 1851 this specification. 1853 The RTP/I payload type (PT) constants are defined in profiles rather 1854 than this document. However, the octet of the RTP/I header which 1855 contains the last bit of the type field and the payload type MUST 1856 avoid the reserved value 72 to distinguish RTP/I packets from the 1857 RTCP/I SDES packet type. This restriction means that payload type 72 1858 is reserved. 1860 RTP/I packet types 1862 abbrev. name value 1863 EVENT event 0 1864 STATE state 1 1865 DELTA_STATE delta state 2 1866 STATE_QUERY state query 3 1868 Additional RTP/I packet types MAY be specified in future versions of 1869 RTP/I. 1871 RTCP/I packet types 1873 abbrev. name value 1874 SUBREP sub-component report 70 1875 BYE goodbye 71 1876 SDES source description 72 1877 APP application-defined 73 1879 RTP/I December 1999 1881 Additional RTCP/I packet types may be registered through IANA (see 1882 Section 11). 1884 SDES types 1886 abbrev. name value 1887 CNAME canonical name 1 1888 NAME user name 2 1889 EMAIL user's electronic mail address 3 1890 PHONE user's phone number 4 1891 LOC geographic user location 5 1892 TOOL name of application or tool 6 1893 NOTE notice about the source 7 1894 PRIV private extensions 8 1896 Additional RTCP/I packet types may be registered through IANA (see 1897 Section 11). 1899 RTP/I reliability types (RT) 1901 no reliability 0 1902 reliable transport 1 1904 Additional RT values may be registered through IANA (see Section 11). 1906 11. IANA Considerations 1908 Additional RTCP/I packet types, SDES types and RT values may be 1909 registered through the Internet Assigned Numbers Authority (IANA). 1910 Since these number spaces are small, allowing unconstrained 1911 registration of new values would not be prudent. To facilitate review 1912 of requests and to promote shared use of new types among multiple 1913 applications, requests for registration of new values must be 1914 documented in an RFC or other permanent and readily available 1915 reference such as the product of another cooperative standards body 1916 (e.g., ITU-T). Other requests may also be accepted, under the advice 1917 of a "designated expert." (Contact the IANA for the contact 1918 information of the current expert.) 1920 12. Full Copyright Statement 1922 Copyright (C) The Internet Society (1999). All Rights Reserved. 1924 This document and translations of it may be copied and furnished to 1925 others, and derivative works that comment on or otherwise explain it 1926 or assist in its implementation may be prepared, copied, published 1927 and distributed, in whole or in part, without restriction of any 1928 kind, provided that the above copyright notice and this paragraph are 1929 included on all such copies and derivative works. However, this 1930 document itself may not be modified in any way, such as by removing 1931 the copyright notice or references to the Internet Society or other 1933 RTP/I December 1999 1935 Internet organizations, except as needed for the purpose of 1936 developing Internet standards in which case the procedures for 1937 copyrights defined in the Internet Standards process must be 1938 followed, or as required to translate it into languages other than 1939 English. 1941 The limited permissions granted above are perpetual and will not be 1942 revoked by the Internet Society or its successors or assigns. 1944 This document and the information contained herein is provided on an 1945 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1946 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1947 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1948 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1949 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1951 13. Addresses of Authors 1953 Martin Mauve 1954 Volker Hilt 1955 Christoph Kuhmuench 1956 Juergen Vogel 1957 Werner Geyer 1958 Wolfgang Effelsberg 1960 Praktische Informatik IV 1961 University of Mannheim 1962 L15, 16 1963 68131 Mannheim 1964 Germany 1966 e-mail: 1967 {mauve,hilt,cjk,jvogel,geyer,effelsberg}@pi4.informatik.uni-mannheim.de 1969 Acknowledgements 1971 We are especially greatful to Colin Perkins for very important 1972 discussions about all aspects of RTP/I and for his effort to review 1973 this draft. 1975 This work is supported by the European MECCANO Telematics for Research 1976 Project 4007 and by the German BMBF (Bundesministerium fuer Forschung 1977 und Technologie) with the "V3D2 Digital Library Initiative". 1979 RTP/I December 1999 1981 Bibliography 1983 [Bra89] R. Braden, "Requirements for internet hosts - application 1984 and support," STD 3, RFC 1123, Internet Engineering Task 1985 Force, Oct. 1989. 1987 [Bra97] S. Bradner, "Key words for use in RFCs to indicate requirement 1988 levels," Request for Comments (Best Current Practice) 2119, Internet 1989 Engineering Task Force, Mar. 1997. 1991 [Cla90] D. D. Clark and D. L. Tennenhouse, "Architectural 1992 considerations for a new generation of protocols," in Proc. 1993 of the ACM Symposium on Communications Architectures and 1994 Protocols, Philadelphia, Pennsylvania, Sept. 1990, 1995 pp 200-208. 1997 [Flo93] S. Floyd and V. Jacobson, "The synchronization of periodic 1998 routing messages," in Proc. of the ACM Symposium on 1999 Communications Architectures and Protocols, San Francisco, 2000 California, USA, Sept. 1993, pp. 33-44. 2002 [Flo94] S. Floyd and V. Jacobson, "The synchronization of periodic 2003 routing messages," IEEE/ACM Transactions on Networking, 2004 Vol. 2, No. 2, Apr. 1994, pp. 122-136. 2006 [Flo97] S. Floyd, V. Jacobson, C. Liu, S. McCanne, L. Zhang, 2007 "A reliable multicast framework for leight-weight sessions 2008 and application level framing," in: IEEE/ACM Transactions 2009 on Networking, Vol. 5, No. 6, Dec. 1997, pp. 784-803. 2011 [Ken98] S. Kent and R. Atkinson, "Security Architecture for the 2012 Internet Protocol," Internet Draft, Internet Engineering 2013 Task Force, July 1998. Work in progress. 2015 [Mil92] D. L. Mills, "Network Time Protocol (Version 3) 2016 specification, implementation and analysis," DARPA 2017 Network Working Group Report RFC-1305, University of 2018 Delaware, 1992. 2020 [Moc87a] P. Mockapetris, "Domain names - concepts and facilities," 2021 STD 13, RFC 1034, Internet Engineering Task Force, 2022 Nov. 1987. 2024 RTP/I December 1999 2026 [Moc87b] P. Mockapetris, "Domain names - implementation and 2027 specification," STD 13, RFC 1035, Internet Engineering 2028 Task Force, Nov. 1987. 2030 [Per99] C. Perkins and J. Crowcroft, "On the use of RTP for shared 2031 workspace applications," UCL-CS research note RN/99/108, 2032 University College London, Dec. 1999. 2034 [Pos81] J. Postel, "Internet protocol," RFC 791, Internet 2035 Engineering Task Force, Sept. 1981. 2037 [Ros98] J. Rosenberg and H. Schulzrinne, "Sampling of the Group 2038 Membership in RTP," Internet Draft, Internet Engineering 2039 Task Force, November 1998. Work in progress. 2041 [Sch99] H. Schulzrinne, S. Casner, R. Frederick, V. Jacoson, "RTP: 2042 A Transport Protocol for Real-Time Applications," Internet 2043 Draft, Internet Engineering Task Force, Aug. 1999, Work in 2044 progress, revision of RFC 1889. 2046 [Yer98] F. Yergeau, "UTF-8, a transformation format of ISO 10646," 2047 RFC 2279, Internet Engineering Task Force, Jan. 1998.