Internet Engineering Task Force M. Mauve Internet Draft V. Hilt draft-mauve-rtpi-00.txt C. Kuhmuench March 1, 2000 J. Vogel Expires: August 31, 2000 W. Geyer W. Effelsberg University of Mannheim RTP/I: An Application Level Real-Time Protocol for Distributed Interactive Media STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT This document specifies RTP/I, an application level real-time protocol for distributed interactive media. Typical examples of distributed interactive media are shared whiteboards, networked computer games and distributed virtual environments. RTP/I defines a standardized framing for the transmission of data and provides mechanisms that are universally needed for this media class. Thereby RTP/I enables the development of reusable functionality and generic services that can be employed for multiple distributed interactive media. Examples for this kind of functionality are the ability to record sessions, to support late coming participants, and to provide security services. RTP/I is a protocol that follows the ideas of application level framing and integrated layer processing. It has been designed to be independent of the underlying network and transport layers. To a large extend RTP/I Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 1]
RTP/I December 1999 has been inspired by the real-time transport protocol (RTP), which is used for continuous non-interactive media. This document is intended to stimulate the discussion on how to transport distributed interactive media over the Internet. There exists an RTP/I mailing list. Instructions on how to subscribe to this list can be found at the RTP/I homepage (http://www.informatik.uni-mannheim.de/informatik/pi4/projects/ RTPI/index.html). Feedback on this document should be addressed to the RTP/I mailing list or directly to the authors. Table of Contents 1. Terminology .................................................... 3 2. Introduction ................................................... 3 3. RTP/I Scope .................................................... 6 4. Model for Distributed Interactive Media ........................ 6 4.1. States and Events ......................................... 6 4.2. Partitioning the Medium - Sub-Components .................. 7 4.3. Environment ............................................... 8 5. Byte Order, Alignment, and Time Format ......................... 8 6. RTP/I Data Transfer Protocol ................................... 9 6.1. RTP/I Event Packet Type ................................... 9 6.2. RTP/I State Packet Type ................................... 12 6.3. RTP/I Delta State Packet Type ............................. 13 6.4. RTP/I State Query Packet Type ............................. 13 6.5. Multiplexing RTP/I Sessions ............................... 14 6.6. RTP/I and ALF/ILP Oriented Reliability Mechanisms ......... 15 6.7. Profile-Specific Modifications to the RTP/I header ........ 15 7. RTP/I Control Protocol -- RTCP/I ............................... 16 7.1. RTCP/I Packet Composition ................................. 16 7.2. RTCP/I Transmission Interval .............................. 17 7.2.1. Maintaining the number of session members .......... 19 7.3. RTCP/I Packet Send and Receive Rules ...................... 19 7.3.1. Computing the RTCP/I transmission interval ......... 20 7.3.2. Initialization ..................................... 21 7.3.3. Receiving an RTP/I or non-BYE RTCP/I packet ........ 21 7.3.4. Receiving an RTCP/I BYE packet ..................... 21 7.3.5. Timing Out a PID ................................... 22 7.3.6. Expiration of Transmission Timer ................... 22 7.3.7. Transmitting a BYE Packet .......................... 23 7.4. RTCP/I Packet Formats ..................................... 23 7.4.1. RTPC/I Sub-Component Report Packet ................. 23 7.4.2. RTCP/I Source Description Packet ................... 26 7.4.3. BYE: Goodbye RTCP/I packet ......................... 32 7.4.4. APP: Application-defined RTCP/I packet ............. 32 7.5. Allocation of RTCP/I bandwidth ............................ 33 8. Security ....................................................... 34 9. RTP/I over Network and Transport Protocols ..................... 34 10. Summary of Protocol Constants ................................. 35 11. IANA Considerations ........................................... 36 12. Full Copyright Statement ...................................... 36 13. Addresses of Authors .......................................... 37 Acknowledgements .................................................. 37 Bibliography ...................................................... 38 Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 2]
RTP/I December 1999 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BRA97] and indicate requirement levels for compliant RTP/I implementations. 2. Introduction Distributed interactive media, i.e. media involving user interac- tions, have received increasing interest over the past decade. Typi- cal representatives of this media class are shared whiteboards, networked computer games, and distributed virtual environments. The application level real-time protocol for distributed interactive media (RTP/I) captures and supports the common aspects of this media class. RTP/I thereby allows the development of services and func- tionality that are reusable for different distributed interactive media. There have been suggestions to use the real-time transport protocol (RTP) [Sch99] as an application level protocol for this media class. However, RTP has been developed to fit the media model of continuous non-interactive media, e.g. audio and video. These media have an ephemeral state which is frequently and redundantly transmitted. In addition the state of the medium is influenced only by a single entity - the sender of the stream. In contrast distributed interac- tive media require managing the shared state of a medium. All parti- cipants are potentially able to change this state. The key problem of this media class is to keep the shared state reasonably similar for all participants of a session, i.e. to maintain consistency. These fundamental differences in the media models prevent RTP from being an optimal fit for distributed interactive media. For a more detailled discussion on why RTP is not appropriate as an application level pro- tocol for distributed interactive media see [Per99]. RTP/I has been designed to reuse aspects of RTP when appropriate while it is thoroughly adapted to meet the demands of the new media class. Throughout this memorandum original and slightly modified pas- sages from Internet Draft ietf-avt-rtp-new-03.txt [Sch99] are fre- quently used. RTP/I consists of two main parts, both reside on the application level and are independent of the underlying network and transport layers: o the framing protocol (RTP/I). RTP/I is used to frame the data transmitted for distributed interactive media. This framing contains the information that is common to media of that class. It makes it possible to understand the semantics of the transmitted data to a large extent without any medium specific knowledge. This allows the development of meaningful functionality and services Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 3]
RTP/I December 1999 that are independent of the media specific data encapsulated by the framing information. o the RTP/I control protocol (RTCP/I). RTCP/I is used to convey meta information about the medium and information about the participants of a session. RTP/I supports the principles of Application Level Framing (ALF) and Integrated Layer Processing (ILP) as proposed by Clark and Tennenhouse [Cla90]. To this end the RTP/I framing provides all the information required to identify Application Data Units (ADUs) and to process them independently. Even though RTP/I provides the application level framing of ADUs it does not define any specific way to realize reliability. This would not be appropriate since the reliability requirements of different distributed interactive media vary widely. For this reason RTP/I allows different reliability mechanisms to cooexist and cooperate with the framing specified by this memorandum. Specifically, RTP/I may also be used by applications that do not follow the principle of ILP and that realize reliability by means of a reliable transport protocol (e.g. TCP). Up to today this approach is used by the vast majority of applications in this area. The applications following this approach trade efficiency for simplicity and a clean application architecture. This may be appropriate for some applications. For those applications RTP/I simply provides a standardized application level protocol, so that generic functionality and services can be used. Nevertheless we consider approaches that do not rely on a reliable transport service as more efficient for distributed interactive media. For those approaches RTP/I can be regarded as a specialization of the ADU framing, as it is used by ALF/ILP oriented reliability mechanisms, such as SRM [Flo97]. RTP/I extends the framing of these mechanisms to the specific needs of distributed interactive media. In order to allow for additional information required by reliability mechanisms RTP/I lets these mechanisms link into the RTP/I header. It specifically grants the reliability mechanisms the right to place additional flags and fields into the RTP/I framing information. This leads to the typical benefits of ILP, namely the avoidance of redundant header information as well as a reduction of copy operations. Furthermore RTP/I also allows reliability mechanisms to transmit additional messages that might be required, e.g. to detect tail loss. With this approach RTP/I provides support for applications following the ALF/ILP principles in addition to enabling the development of generic services and functionality. An ALF/ILP oriented reliability mechanism that is used together with RTP/I is specified in an RTP/I reliability mapping document. This document completely defines the employed mechanism and its Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 4]
RTP/I December 1999 cooperation with RTP/I. It MAY do so by referencing an existing specification of the reliability mechanism and by providing information on how it cooperates with RTP/I. This includes the mapping of the information provided by RTP/I to the information required by the reliability mechanism, the specification of any additional information that is to be stored in the RTP/I framing, and the definition of any additional packet types that may be required. Each RTP/I reliability mapping MUST be assigned a unique number in the range of 2-63 by IANA. There exist two special reliability mechanisms that can be used with RTP/I. The first one is no reliability (e.g. for battlefield simulations or telepointers) and the second one is the usage of a reliable transport protocol which is transparent to the application. These mechanisms are assigned the numbers 0 and 1, respectively. RTP/I is not a complete protocol. It needs to be adapted to the requirements of a specific medium or a group of media. This is done using two additional types of documents besides the reliability mapping: o a payload type definition is a specification document that defines how a particular medium is transported using the framework provided by RTP/I. Essentially a payload type definition describes how the medium specific data is encoded. It MAY also define how consistency is ensured if this is not done by a profile under which the payload type operates. o a profile adapts RTP/I to the needs of a group of distributed interactive media. It MAY provide additional fields for the framing of the data as well as new control packet types. A profile is usually defined for media that share a common way to achieve consistency. Examples of media that may belong to the same class are military battlefield simulations and networked action games. Another profile could be defined for a sub-class of shared workspace applications. With this flexibility, generic services and functionality can be developed on three levels. They can be fully generic services usable for all RTP/I based applications, they can be services that are useful for certain RTP/I profiles or they may be defined for a number of RTP/I payloads. The remainder of this document is structured as follows. Section Three defines the scope of this document by identifying the distributed media class for which it should be used. Section Four contains a definition of the media model upon which RTP/I is based. Here the main concepts of distributed interactive media are discussed. The byte order and timestamp format is given in Section Five. In Section Six the RTP/I data protocol is specified. The RTP/I data protocol is used to transport the information that is required to distribute the medium itself. The RTP/I control protocol (RTCP/I) Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 5]
RTP/I December 1999 is defined in Section Seven. It is used to transport meta information about the medium and the participants of a session. Section Eight deals with security for RTP/I. How to transport RTP/I over transport services is described in Section Nine. Sections Ten to Thirteen contain an overview over the protocol constants, IANA considerations, the copyright statement, and the authors addresses. 3. RTP/I Scope In order to define the scope of RTP/I, we separate distributed media types by means of two criteria. The first criterion distinguishes whether the medium is discrete or continuous. The characteristic of a discrete medium is that its state is independent of the passage of time. Examples of discrete media are still images or digital whiteboard presentations. While discrete media may change their state, they do so only in response to external events, such as a user drawing on a digital whiteboard. The state of a continuous medium, however, depends on the passage of time and can change without the occurrence of external events. Video and animations belong to the class of continuous media. The second criterion distinguishes between interactive and non- interactive media. Non-interactive media change their state only in response to the passage of time and do not accept external events. Typical representations of non-interactive media are video, audio and images. Interactive media are characterized by the fact that their state can be changed by external events such as user interactions. Whiteboard presentations and distributed virtual environments represent interactive media. While the real time protocol RTP is a suitable protocol for the transportation of continuous non-interactive media, it is not appropriate to support distribute interactive media [Per99]. RTP/I is therefore defined as an application level protocol for distributed interactive media, both continuous and discrete. RTP/I reuses aspects of RTP whenever possible, however, it is specifically tailored to the needs of distributed interactive media. 4. Model for Distributed Interactive Media 4.1. States and Events A distributed interactive medium has a state. For example, at any given point in time the state of a shared whiteboard is defined by the content of all pages present in the shared whiteboard. In order to perceive the state of a distributed interactive medium a user needs an application, e.g. a shared whiteboard application is Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 6]
RTP/I December 1999 required to see the pages of a shared whiteboard presentation. This application generally maintains a local copy of (parts of) the medium's state. For all applications participating in a session the local state of the medium should be at least reasonably similar. It is therefore necessary to synchronize the local copies of the distributed interactive medium's state among all participants, so that the overall state of the medium is consistent. The state of a distributed interactive medium can change for two reasons, either by passage of time or by events. The state of the medium between two successive events is fully deterministic and depends only on the passage of time. Generally, a state change caused by the passage of time does not require the exchange of information between applications, since the application of each user can calculate the required state changes independently. An example of a state change caused by the passage of time is the animation of an object moving across the screen. Any state change that is not a fully deterministic function of time is caused by an event. Events can be separated into external events and internal events. External events are (user) interactions with the medium, e.g. the user makes an annotation on a shared whiteboard page. Internal events are non-deterministic state changes of the medium, such as generating a random number. Whenever events occur, the state of the medium is in danger of becoming inconsistent because the local copies of the state could run out of synchronization with the remote copies. Therefore, an event usually requires that the applications exchange information - either about the event itself or about the updated state after the event has taken place. 4.2. Partitioning the Medium - Sub-Components In order to provide for a flexible and scalable handling of state information, it is often desirable to partition an interactive medium into several sub-components. In addition to breaking down the complete state of an interactive medium into more manageable parts, such partitioning allows participants of a session to track only the states of those sub-components they are actually interested in. Examples of sub-components are 3D objects (e.g. a house, a car, a room) in a distributed virtual environment or the pages of a shared whiteboard. Events, external as well as internal, have a target sub- component which they affect. Other sub-components than the target are not affected by an event. It is important to notice that sub-components must be independent of each other, since some applications might track only the state of a subset of all available sub-components. Sub-component A is said to be independent of sub-component B if the state of B does influence the state of A only by means of events. While the independence of sub- components is usually guaranteed for a medium like a shared whiteboard, other media require the generation of pseudo events in Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 7]
RTP/I December 1999 order to ensure that sub-components are independent of each other. For example, in a distributed car race where the cars are the sub- components of the medium, pseudo events would occur if cars bump into each other. As for internal and external events, pseudo events generally require that the applications exchange either information about the event itself, or about the updated state after the event has taken place. Otherwise the consistency of the overall medium might be damaged. 4.3. Environment While it would be conceivable to declare all information which is required by the application to display the distributed interactive medium, to be part of the medium's state, this is generally not desirable. Usually a substantial part of this information remains constant over the course of a session. We call this part of the information the environment of a distributed interactive medium. Examples for environments are the base world descriptions of distributed virtual environments, or the postscript slides of shared whiteboard presentations. Since the environment stays constant, there are no mechanisms required to synchronize it among the participants of a session - the environment information just needs to be received once by each participant. It is therefore a good idea to make the environment part of the medium data as large as possible and to minimize the amount of state information. The distinction between state and environment information is situation dependent - a participant might choose to introduce a new postscript slide into an ongoing shared whiteboard presentation, which makes this page part of the medium's state. It is therefore the task of the application designer to distinguish between state and environment information. Since the environment is a discrete non-interactive medium we do not further investigate how the environment is shared between participants. For the remainder of this memorandum we merely assume that the environment is present for all participant's applications (e.g. by using multi-destination file transfer or by means of an off-line distribution on CD or DVD). 5. Byte Order, Alignment, and Time Format All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in [Pos81]. Numeric constants are given in decimal representation. All header data is aligned to its natural length, i.e., 16-bit fields are aligned on even offsets, 32-bit fields are aligned at offsets divisible by four, etc. Octets designated as padding have the value zero. The timestamps of RTP/I are 32 bit fields. They represent the milliseconds passed since 0h UTC on 1 January 1900. Timestamp values may wrap. Participants of an RTP/I session SHOULD have a sufficiently synchronized clock, so that they can identify the current timestamp cycle. Further constraints on the synchronization of the Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 8]
RTP/I December 1999 participants' clocks may be made in a profile or a payload type specification. 6. RTP/I Data Transfer Protocol The bulk of data for a distributed interactive medium - states, events and requests for state information - are carried in RTP/I data packets. Essentially RTP/I data packets contain medium specific information which is framed by common header fields. In RTP/I there are four distinct data packet types: event, state, delta state, and state query. All four share the same packet header. A particular RTP/I payload or an RTP/I profile may specify that only a subset of these data packet types is to be used for a given medium or a group of media. 6.1. RTP/I Event Packet Type The event packet type is used by an application to transmit events to peer applications. The RTP/I event packet type has the following fixed header: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|E|X| TYPE | PT | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RT |PRI| PI | RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | participant identifier (PID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subcomponent identifier (SUBID) most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subcomponent identifier (SUBID) least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sequence number | fragment count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits This field holds the version number. The version defined by this specification is version 0. end (E): 1 bit This bit is set, if and only if the packet is the last packet of an ADU. reliability header extension (X): 1 bit If this bit is set, the fixed RTP/I header, as shown above, MUST be followed by exactly one header extension that is used for reliability purposes. The format of this extension is specified Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 9]
RTP/I December 1999 in Section 6.5. The extension mechanism MUST NOT be used for other purposes than to convey reliability information. If additional information is required for a subclass of distributed interactive media, then a profile SHOULD be used to extend the framing information. If the additional information is relevant to all distributed interactive media, then a new RTP/I version SHOULD be specified which includes this information. type (TYPE): 4 bits This field identifies the type of the ADU the packet belongs to. RTP/I specifies four packet type values: 0 for event packets, 1 for state packets, 2 for delta state packets, and 3 for state query packets. Future versions of RTP/I MAY define additional types for the values 4, 5, 6, and 7. The values 8 - 15 MAY be used by ALF/ILP oriented reliability approaches to identify additional packets. They MUST NOT be used for the transmission of media related packets. The type field MUST carry the same value for all packets belonging to one ADU. payload type (PT): 8 bits This field identifies the format of the RTP/I payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP/I means. The payload type of a medium MAY change during a session. The payload type field SHOULD NOT be used for multiplexing the streams of separate media. A receiver MUST ignore packets with payload types that it does not understand. The payload type field MUST carry the same value for all packets belonging to one ADU. length: 16 bits The length field specifies the length of this packet in octets, excluding the 28 octet fixed RTP/I header, including any reliability or profile specific header extensions. It can be used to stack multiple RTP/I data packets in one transport packet. If the length is no multiple of 4, then a minimal amount of padding octets MUST be appended to the packet so that the total length of the packet including the padding octets is a multiple of 4. These padding octets MUST NOT be included in the size of the packets as expressed in the length field. The last RTP/I packet contained in a transport packet MAY choose not to use padding octets, even if it does not have a size which is a multiple of 4 octets. reliability type (RT): 6 bits This field identifies how reliability is established for the packet. Reliability type 0 is used when the data transmission is unreliable. Reliability type 1 is used when the packet is transmitted over a reliable transport protocol. The meaning of other RT values is defined in RTP/I reliability mapping Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 10]
RTP/I December 1999 documents. RT values are assinged by IANA. A profile specification SHOULD specify which reliability types are usable with the profile. The reliability type MAY change during a session. The reliability type field MUST carry the same value for all packets belonging to one ADU. priority (PRI): 2 bits This field is not used for events. reserved for profile information (PI): 8 bits This field MAY be used to transport profile specific information. The usage of this field is specified in profile specification documents. It MUST NOT be used by reliability mechanisms. reserved for reliability information (RI): 16 bits This field MAY be used by reliability mechanisms to hold additional information. The use of this field is specified in RTP/I reliability mapping documents. This field MUST NOT be used for other purposes. participant identifier (PID): 32 bits The participant identifier MUST uniquely identify a participant. This participant is the original sender of the packet. How to choose PIDs is outside the scope of RTP/I. A PID MUST be persistent for the lifetime of a session. In particular, the restart of an application MUST NOT change the PID of the participant. If an application requires multiple RTP/I sessions (e.g. because multiple distributed interactive media are involved, or because a single medium is distributed across multiple sessions) then the PID SHOULD be the same for the participant in all these RTP/I sessions. sub-component identifier (SUBID): 64 bits The sub-component identifier MUST uniquely identify a sub- component. In event packets the SUBID identifies the target sub-component of the event. How to choose SUBIDs is outside the scope of RTP/I. A SUBID MUST be persistent for the lifetime of a session. If an application requires multiple RTP/I sessions (e.g. because a single medium is distributed across multiple sessions) then the SUBID SHOULD be the same for the same sub- component in all these RTP/I sessions. sequence number: 16 bits There are independent sequence numbers for each sub-component and packet type (i.e. events, state, delta states and state queries). For each transmitted full ADU the appropriate sequence number is incremented by one. The sequence number field MUST carry the same value for all packets belonging to one ADU. fragment count: 16 bits Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 11]
RTP/I December 1999 In the case that an ADU does not fit into a single network layer packet, the application SHOULD fragment the data, in order to avoid inefficient network-level fragmentation. A single ADU may therefore consist of more than one packet. The fragment count for each ADU starts with 0 and is incremented by one for each packet sent for this ADU by a participant. A receiver knows that it has received all parts of a fragmented ADU when it has received a packet with the fragment count 0, a packet with the E bit set and all fragments in between the fragment count of both packets. A single ADU MUST NOT consist of more than (2^16-1) fragments. timestamp: 32 bits The timestamp value is expressed as milliseconds that have passed since 0h UTC on 1 January 1900 modulo 2^32. For an event the timestamp specifies the time at which an event is applied to the target sub-component. The timestamp MUST be based on a physical clock. The physical clocks of all participants SHOULD be synchronized via external means such as NTP [Mil92] or GPS. A profile or payload type specification MAY limit the maximal allowed time offset between any two participants in a session and the resolution of the clock. The timestamp MAY be used to establish a global ordering on the ADUs transmitted by all participants of a session. For each medium transported over RTP/I a profile or the payload type definition SHOULD therefore specify the interpretation of ADUs that bear the same timestamp. The timestamp field MUST carry the same value for all packets belonging to one ADU. The RTP/I header (including reliability header extension and profile specific extensions) is followed by the payload type specific data describing the event. 6.2. RTP/I State Packet Type The state packet type is used by an application to transmit the full state of a sub-component. The RTP/I state packet type header has the same structure as the event packet type header. The following fields are interpreted in a different way than for the event packet type: priority (PRI): 2 bits This field identifies the priority of the state transmission. A state transmitted with priority 3 MUST be adopted by the recipients. A state transmitted with priority 0 MAY be adopted by the recipients. The meaning of the values 1 and 2 MAY be specified in a profile or a payload type definition. This field is required because setting the state of a sub-component can be costly and might not always be reasonable for all participants. Situations where priority 3 is recommended are re- synchronization after errors or packet loss. A state transmission with priority 3 forces every participant to discard its information about the sub-component and requires the Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 12]
RTP/I December 1999 adoption of the new state. A state transmitted with priority 0 can be ignored at will by any participant. This is useful if only a subset of communication partners is interested in the state. An example of this case are late joins where only applications joining the session might be interested in certain state transmission. All state packets belonging to the same ADU MUST carry the same priority. sub-component identifier (SUBID): 64 bits The SUBID identifies the sub-component to which the state contained in the packet belongs. timestamp: 32 bits For a STATE packet the timestamp specifies the time at which the state was extracted from the sub-component. All STATE packets belonging to the same ADU MUST carry the same timestamp. 6.3. RTP/I Delta State Packet Type In cases where a complex sub-component state of an interactive medium is transmitted frequently by an application, it may be desirable to be able to send only those parts of a state that have changed since the last state transmission. This is similar to the concept of P frames in an MPEG encoded video stream. RTP/I supports this by providing a delta state packet type. A delta state ADU (possibly consisting of more than one packet) can only be interpreted if the preceding state ADU is also available. The main advantages of delta state ADUs are their smaller size and that they can be calculated faster than state ADUs. The RTP/I delta state packet type header is the same as the state packet type header. The only difference is the value of the TYPE field which is 2 for delta state packets. 6.4. RTP/I State Query Packet Type In a number of situations an application or a generic service might need to get the current state of a certain sub-component. Examples for these situations are: as means of resynchronization if an event has been lost or received late, as access point for random-access in a distributed interactive media recorder, or as an initial state for a late-comer joining an ongoing session. Since this functionality is universally needed for many distributed interactive media it is supported directly by a state query packet type. A state query packet is used by a participant to indicate that it desires the transmission of a certain sub-component's state. The structure of the state query packet type is the same as for all RTP/I data packets. However, it does not contain any medium specific data. Instead of being a regular request - as found in other protocols - a state query packet is only an indication to the receivers that a participant would like to get the state of the concerned sub- Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 13]
RTP/I December 1999 component. A regular request/reply mechanism would be inappropriate for a protocol that should scale well in a multicast environment. The decision whether any given receiver of a state query packet does reply is made locally by the receiver. This decision is influenced by the value contained in the priority field and SHOULD be made in a way that prevents a reply implosion if multicast is used. In addition, state query packets SHOULD be issued in a way that avoids state query implosions in a multicast environment. The fields in a state query packet type are interpreted as for event packets with the following exceptions: end (E): 1 bit This bit is always set for state query packets. length: 16 bits The length of a state query packet is always 28 + any reliability and profile specific header extension bytes. priority (PRI): 2 bits The meaning of the priority contained in a state query packet is as follows: o Priority 3 is used when the request needs to be satisfied immediately, e.g for resynchronization after errors. o Priority 2 is used when a response is required, but a short delay is acceptable, e.g. for a late join service. o Priority 1 is used when a response is desirable but not required, e.g. pre-fetching of sub-component state, which might be needed later. o Priority 0 is used when the state request is issued periodically, e.g. for a recording service. sub-component identifier (SUBID): 64 bits The SUBID identifies the sub-component that the sender wants to receive a state of. timestamp: 32 bits The timestamp of a STATE_QUERY packet specifies the time at which the application generated the query. 6.5. Multiplexing RTP/I Sessions As with RTP [Sch99] the multiplexing of multiple RTP/I streams is provided by the transport destination address of the stream (network address and port number). A session involving more than one distributed interactive medium SHOULD transmit the data for the different media to separate transport addresses. Separate media Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 14]
RTP/I December 1999 streams SHOULD NOT be carried in a single RTP/I session. 6.6. RTP/I and ALF/ILP Oriented Reliability Mechanisms Many fields of the RTP/I data packet header are directly useful for ALF/ILP oriented reliability mechanisms. The information contained in the RTP/I header fields SHOULD NOT be duplicated for reliability purposes. Instead the reliability mechanism SHOULD link into the RTP/I header and directly reuse the information of the RTP/I header fields. However the reliability mechanisms MUST NOT modify any of the fields besides the X flag, the RT field, the 16 bits field reserved for reliability purposes, and the reliability header extension (if present). The X flag SHOULD only be set if the reliability mechanism specified by the RT field requires more information than can be fit into the 16 bits reserved for reliability purposes. If the X flag is set, the timestamp in the RTP/I header MUST be followed by a header extension: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | additional information ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length field specifies the length of the header extension in multiples of 4 octets, excluding the first 4 octets. Therefore a length value of 0 is valid. The additional information for reliability purposes follows the length field of the header extension. 6.7. Profile-Specific Modifications to the RTP/I header The existing RTP/I data packet header is believed to be complete for the set of functions required in common across all the applications that RTP/I might use. However, in keeping with the ALF design principle, the header MAY be tailored to the needs of a specific distributed interactive media sub-class. This tailoring MUST be done in a way that allows generic services and functionality to work for the new profile. Specifically a profile MUST preserve the semantics of the four packet types and it MUST NOT define new RTP/I data packet types. Additional information that is required for a particular payload format SHOULD be carried in the payload section of the packet. This might be in a header that is always present at the start of the payload section, or might be indicated by a reserved value in the data pattern. If a particular sub-class of distributed interactive media needs additional information that do not fit into the 8 bits reserved for Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 15]
RTP/I December 1999 this purpose and which are independent of the payload format, then the profile for this sub-class SHOULD define additional RTP/I data packet header fields. These fields SHOULD follow the reliability extension header, if it is present. If no reliability extension header is present, the additional fields SHOULD follow the timestamp field of the RTP/I data packet header. This allows profile independent services to work properly in the presence of profile specific additional header fields. If it turns out that additional information is needed in common across all profiles, then a new version of RTP/I SHOULD be defined to make a permanent change to the RTP/I data packet header. 7. RTP/I Control Protocol -- RTCP/I The RTP/I control protocol (RTCP/I) is based on the periodic transmission of control packets to all participants in a session, using the same distribution mechanism as the data packets. Because of the redundancy included in this approach, RTCP/I does not require any additional reliability mechanisms. The underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP/I provides three main functions: 1. It provides meta information about the sub-components, e.g. application level names for sub-components and whether a sub- component is currently needed to display the medium to the users. 2. It conveys information about the participants of a session. This information includes a human-readable unique participant identifier (the CNAME). The CNAME can be used to let RTP/I cooperate with RTP. 3. The first two functions require that all participants send RTCP/I packets, therefore the rate must be controlled in order for RTP/I to scale up to a large number of participants. By monitoring the control packets of the other participants, it is possible to estimate the overall number of participants and the average size of RTCP/I packets. These numbers are used to calculate the rate at which RTCP/I packets are sent by individual applications. 7.1. RTCP/I Packet Composition This specification defines four packet types for the RTP/I control protocol: SUBREP (subcomponent report): used to report on the sub-components present in a session. This includes information on the sub-component status and application level names for sub-components. SDES (source description): used to convey participant description Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 16]
RTP/I December 1999 items, such as participant name, email, location, etc. Of particular interest is the CNAME, a human readable, unique identifier which can be used to identify participants across RTP and RTP/I sessions. BYE: indicates the end of participation. APP (application): used to carry application specific information. In RTCP/I there are no packets that report on the reception quality of individual participants. The reason for this is that RTP/I may be used over, or in combination with, reliability mechanisms that do packet retransmissions. It would therefore not be appropriate to convey information about packet loss rates, latency and jitter in RTCP/I packets. Instead the reliability mechanisms are expected to provide this information. In the case that a given sub-class of distributed interactive media does not use retransmission oriented reliability (e.g battlefield simulations) an RTP/I profile MAY specify reception quality reports as a profile specific extension to RTCP/I. RTCP/I packets are transmitted in compound packets. Each compound packet MUST contain a SDES packet as the first RTCP/I packet. It MAY also contain other RTCP/I packets. This structure allows to verify that a correct RTCP/I packet has been received and not a mis- addressed non-RTCP/I packet. An implementation SHOULD ignore incoming RTCP/I packets with types unknown to it. Additional RTCP/I packet types may be registered with the Internet Assigned Numbers Authority (IANA) as described in Section 11. 7.2. RTCP/I Transmission Interval RTCP/I is designed to scale over session sizes ranging from only a few participants to large groups of participants. As with the control protocol of RTP [Sch99] this requires that the rate at which RTCP/I compound packets are sent by individual applications decreases with the number of participants and the average size of the RTCP/I compound packets. For each session we assume that the bandwidth available for RTCP/I usage is set to a fixed maximum amount. This amount includes network and transport headers, since this is the value that resource reservation systems need to know. The available bandwidth for RTCP/I usage MAY be a small and known fraction of the total bandwidth available for the session, or it MAY be specified explicitly via external means, such as a session announcement facility. In multicast environments the transmission of RTCP/I packets MUST be scheduled in a way so that the overall average RTCP/I data-rate of the whole session is unlikely to exceed the amount of bandwidth Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 17]
RTP/I December 1999 available for RTCP/I. Typically such a scheduling algorithm calculates the transmission interval between two RTCP/I packets from the same participant based on the maximum available bandwidth for RTCP/I usage, the number of participants, and the average size of RTCP/I packets. In addition there SHOULD be a minimum value set for the transmission interval. This avoids bursty traffic when the traffic generated by a small group is not smoothed according to the law of large numbers. The RECOMMENDED value for this minimal transmission interval is 5 seconds. Profiles MAY specify a different minimal value. In unicast sessions involving only two participants the applications MAY choose to transmit RTCP/I packets at a fixed rate. The algorithm described in Section 7.3 demonstrates how the transmission of RTCP/I packet can be scheduled so that RTCP/I remains scalable. It is an adaptation of the algorithm used for RTCP [Sch99] and exhibits the same characteristics: o The calculated interval between RTCP/I packets scales linearly with the number of members in the group. It is this linear factor which allows for a constant amount of control traffic when summed across all members. o The interval between RTCP/I packets is varied randomly over the range [0.5,1.5] times the calculated interval to avoid unintended synchronization of all participants [Flo93,Flo94]. The first RTCP/I packet sent after joining a session is also delayed by a random variation of half the minimum RTCP/I interval. o A dynamic estimate of the average compound RTCP/I packet size is calculated, including all those received and sent, to automatically adapt to changes in the amount of control information carried. o Since the calculated interval depends on the number of observed group members, there may be undesirable start-up effects when a new user joins an existing session, or many users simultaneously join a new session. These new users will initially have incorrect estimates of the group membership, and thus their RTCP/I transmission interval will be too short. This problem can be significant if many users join the session simultaneously. To deal with this, an algorithm called "timer reconsideration" is employed. This algorithm implements a simple back-off mechanism which causes users to hold back RTCP/I packet transmission if the group sizes are increasing. o When users leave a session, either with a BYE or by timeout, the group membership decreases, and thus the calculated interval should decrease. A "reverse reconsideration" algorithm is used to allow members to more quickly reduce their intervals in response to group membership decreases. Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 18]
RTP/I December 1999 o BYE packets are given different treatment than other RTCP/I packets. When a user leaves a group, and wishes to send a BYE packet, it may do so before its next scheduled RTCP/I packet. However, transmission of BYE's follows a back-off algorithm which avoids floods of BYE packets should a large number of members simultaneously leave the session. 7.2.1. Maintaining the number of session members Calculation of the RTCP/I packet interval depends upon an estimate of the number of sites participating in the session. New sites are added to the count when they are heard, and an entry for each SHOULD be created in a table indexed by the PID to keep track of them. Entries MAY be deleted from the table when an RTCP/I BYE packet with the corresponding PID is received, except that some straggler data packets might arrive after the BYE and cause the entry to be recreated. Instead, the entry SHOULD be marked as having received a BYE and then deleted after an appropriate delay. A participant MAY mark another site inactive if no RTP/I or RTCP/I packet has been received for a small number of RTCP/I report intervals (5 is RECOMMENDED). This provides some robustness against packet loss. All sites MUST have the same value for this multiplier and must calculate roughly the same value for the RTCP/I report interval in order for this timeout to work properly. Therefore, this multiplier SHOULD be fixed for a particular profile. For sessions with a very large number of participants, it may be impractical to maintain a table to store the PID and state information for all of them. An implementation MAY use a sampling approach, as described for RTP in [Ros98], to reduce the storage requirements. An implementation MAY use any other algorithm with similar performance. A key requirement is that any algorithm considered SHOULD NOT substantially underestimate the group size, although it MAY overestimate. 7.3. RTCP/I Packet Send and Receive Rules This section is an adaptation of Section 6.3 from Internet Draft ietf-avt-rtp-new-03.txt. The main difference is that there is no notion of active senders for distributed interactive media. The distinction between active senders and other participants is not required because in RTCP/I the PID is unique (and therefore the CNAME of active senders is not required as urgently as for RTP). The rules for how to send, and what to do when receiving an RTCP/I packet are outlined here. An implementation that allows operation in a multicast environment or a multi-point unicast environment MUST meet the scalability goals described in Section 7.2. Such an implementation MAY use an algorithm other than the one defined here so long as it provides equivalent or better performance. As mentioned Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 19]
RTP/I December 1999 above an implementation that is constrained to two-party unicast operation MAY omit this algorithm. To execute these rules, a session participant must maintain several elements of state information: tp: the last time an RTCP/I packet was transmitted; tc: the current time; tn: the next scheduled transmission time of an RTCP/I packet; pmembers: the estimated number of session members at the time tn was last recomputed; members: the most current estimate for the number of session members; bw: The target RTCP/I bandwidth, i.e., the total bandwidth that will be used for RTCP/I packets by all members of this session, in bytes per second. avg_rtcpi_size: The average compound RTCP/I packet size, in octets, over all RTCP/I packets sent and received by this participant. initial: Flag that is true if the application has not yet sent an RTCP/I packet. Many of these rules make use of the "calculated interval" between packet transmissions. This interval is described in the following section. 7.3.1. Computing the RTCP/I transmission interval To maintain scalability, the average interval between packets from a session participant should scale with the group size. This interval is called the deterministic calculated interval. It is obtained by combining a number of the pieces of state described above. The (non- deterministic) calculated interval T is then determined as follows: 1. If the participant has not yet sent an RTCP/I packet (the variable initial is true), the constant Tmin is set to one half of the minimal report interval seconds (2.5 unless stated otherwise in the RTP/I profile), else it is set to the minimal report interval (5 unless stated otherwise in an RTP/I profile). 2. The deterministic calculated interval Td is set to max(Tmin, members*avg_rtcpi_size/bw). 3. The calculated interval T is set to a number uniformly Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 20]
RTP/I December 1999 distributed between 0.5 and 1.5 times the deterministic calculated interval. 4. The resulting value of T is divided by e-3/2=1.21828 to compensate for the fact that the unconditional reconsideration algorithm converges to an RTCP/I bandwidth value below the intended average. 7.3.2. Initialization Upon joining the session, the participant initializes tp to the current time, pmembers to 1, members to 1, bw to the total amount of bandwidth available for RTCP/I, initial to true, and avg_rtcpi_size to the size of the RTCP/I compound packet that would be constructed if one where to be sent immediately. The calculated interval T is then computed, and the first packet is scheduled for time tn = T. This means that a transmission timer is set which expires at time T. Note that an application MAY use any desired approach for implementing this timer. The participant adds its own PID to the member table. 7.3.3. Receiving an RTP/I or non-BYE RTCP/I packet When an RTP/I or RTCP/I packet is received from a participant whose PID is not in the member table, the PID is added to the table, and the value for members is updated. For each compound RTCP/I packet received, the value of avg_rtcpi_size is updated: avg_rtcpi_size = (1/16)*packet_size + (15/16)* avg_rtcpi_size, where packet_size is the size of the RTCP/I packet just received. 7.3.4. Receiving an RTCP/I BYE packet Except as described in Section 7.3.7 for the case when an RTCP/I BYE is to be transmitted, if the received packet is an RTCP/I BYE packet, the PID is checked against the member table. If present, the entry is removed from the table, and the value for members is updated. Furthermore, to make the transmission rate of RTCP/I packets more adaptive to changes in group membership, the following "reverse reconsideration" algorithm SHOULD be executed when a BYE packet is received that reduces members to a value less than pmembers: o The value for tn is updated according to the following formula: tn = tc + (members/pmembers)(tn - tc). o The value for tp is updated according the following formula: tp = tc - (members/pmembers)(tc - tp). o The next RTCP/I packet is rescheduled for transmission at time tn, Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 21]
RTP/I December 1999 which is now earlier. o The value of pmembers is set equal to members. This algorithm does not prevent the group size estimate from incorrectly dropping to zero for a short time due to premature time- outs when most participants of a large session leave at once but some remain. The algorithm does make the estimate return to the correct value more rapidly. This situation is unusual enough and the consequences are sufficiently harmless that this problem is deemed only a secondary concern. 7.3.5. Timing Out a PID At occasional intervals, the participant MUST check to see if any of the other participants time out. To do this, the participant computes the deterministic calculated interval (without the randomization factor) Td. Any other session member who has not sent a packet since time tc - MTd (M is the timeout multiplier, and defaults to 5) is timed out. This means that its PID is removed from the member list, and members is updated. If any members time out, the reverse reconsideration algorithm described in Section 7.3.4 SHOULD be performed. The participant MUST perform this check at least once per RTCP/I transmission interval. 7.3.6. Expiration of Transmission Timer When the packet transmission timer expires, the participant performs the following operations: o The transmission interval T is computed as described in Section 7.3.1, including the randomization factor. o If tp + T is less than or equal to tc, an RTCP/I packet is constructed and transmitted. tp is set to tc, then another value for T is calculated as in the previous step and tn is set to tc + T. The transmission timer is set to expire again at time tn. If tp + T is greater than tc, tn is set to tp + T. No RTCP/I packet is constructed or transmitted. The transmission timer is set to expire at time tn. o pmembers is set to members. If an RTCP/I packet is transmitted, the value of initial is set to FALSE. Furthermore, the value of avg_rtcpi_size is updated: avg_rtcpi_size = (1/16)*packet_size + (15/16)* avg_rtcpi_size, where packet_size is the size of the RTCP/I packet just transmitted. Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 22]
RTP/I December 1999 7.3.7. Transmitting a BYE Packet When a participant wishes to leave a session, a BYE packet is transmitted to inform the other participants of the event. In order to avoid a flood of BYE packets when many participants leave the session, a participant MUST execute the following algorithm if the number of members is more than 50 when the participant chooses to leave. This algorithm usurps the normal role of the members variable to count Bye packets instead: o When the participant decides to leave the session, tp is reset to tc, the current time, members and pmembers are initialized to 1, initial is set to true, and avg_rtcpi_size is set to the size of the BYE packet. The calculated interval T is computed. The BYE packet is then scheduled for time tn = tc + T. o Every time a BYE packet from another participant is received, members is incremented by 1 regardless of whether that participant exists in the member table or not, and when sampling is in use, regardless of whether or not the BYE would be included in the sample. members is NOT incremented when other RTCP/I packets or RTP/I packets are received, but only for BYE packets. o Transmission of the BYE packet then follows the rules for transmitting a regular RTCP/I packet, as above. This allows BYE packets to be sent right away, yet controls their total bandwidth usage. In the worst case, this could cause RTCP/I control packets to use twice the bandwidth as normal (10%) -- 5% for non-BYE RTCP/I packets and 5% for BYE packets. A participant that does not want to wait for the above mechanism to allow transmission of a BYE packet MAY leave the group without sending a BYE at all. That participant will eventually be timed out by the other group members. If the group size estimate members is less than 50 when the participant decides to leave, the participant MAY send a BYE packet immediately. Alternatively, the participant MAY choose to execute the above BYE backoff algorithm. In either case, a participant which never sent an RTP/I or RTCP/I packet MUST NOT send a BYE packet when they leave the group. 7.4. RTCP/I Packet Formats 7.4.1. RTPC/I Sub-Component Report Packet The RTCP/I sub-component report (SUBREP) packet is used to announce the sub-components present in a session, to indicate which sub- components are actively used to display the medium to the users, and Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 23]
RTP/I December 1999 to provide information for the mapping from sub-component IDs to application level names. A report for a sub-component includes its current status: active or passive. The active sub-components of an application at any point in time are those sub-components which are required by the application to present the interactive medium at that specific time. A sub- component which is active for at least one participant should be reported as active for the session. An application level name allows an application to identify the sub- component. An application MAY use the application level name to decide whether it is interested in the sub-component without having received a state for that sub-component. A given payload type or profile MAY choose not to use the mapping for sub-component IDs to application level names. In this case the SUBREPS do not contain application level names. This can be reasonable if the state of sub- components is transmitted frequently or if the required information can be encoded in the sub-component ID. If a payload type or profile does not use the mapping as presented here it SHOULD NOT use a different algorithm for performing the mapping between application level names and sub-component IDs. This would prevent generic RTP/I based services from working properly. When a sub-component has not been reported by any participant for a certain number of report intervals, the sub-component is regarded as no longer present in the session (i.e. it timed out). This information MAY be used by generic services and applications to determine the set of sub-components present in a session. The RECOMMENDED value for the number of report intervals until a sub- component is timed out is 6. SUBREP packets SHOULD be transmitted so that each sub-component present in the session is, on average, reported once per report interval. This allows applications and generic services to get a quick overview of the sub-components, while it does not flood the network with duplicates of sub-component reports. The following algorithm is given as an example, other algorithms for sending SUBREP packets MAY be used. Every time when an RTPC/I packet is to be transmitted the participant checks whether any sub-components for which it tracks the state have not been reported by any other participant since tc-2*Td. All these unreported sub-components are then reported using a SUBREP packet. If a sub-component has been reported as passive by a remote application and that same sub-component is active for the local application, the local application reports that sub-component as active. This could result in two reports being sent for a single sub-component in a single report interval. However, this situation will not last, since the next time the remote application checks for sub-component reports, it will see the active report and will count that sub- Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 24]
RTP/I December 1999 component as reported for the report interval. This algorithm is simple, robust, and scalable - in most cases each sub-component is reported only once per report interval, independent of the number of participants. The following brief calculation shows that the data-rate consumed by the announce/listen approach is acceptable, even with sessions that involve multiple hundrets of sub-components. Let us assume a rather large session with 1000 sub-components and with long application level names (20 bytes on average). Further we assume that at least every 60 seconds all mapping information should be available. Neglecting header information this would result in 1000*(20+8)=28000 bytes that are transmitted for subcomomponent ID to application level name mapping. This is equivalent to a datarate of 28000*8/60=3.7 kBit/s if this information is transmitted every 60 seconds. This seems reasonable for a large session. The format of the RTCP/I SUBREP packet is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|N| SC | TYPE | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | participant identifier (PID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|A| ... | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subcomponent identifier 1 (SUBID) most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subcomponent identifier 1 (SUBID) least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name length 1 | application level name for SUBID 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subcomponent identifier 2 (SUBID) most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subcomponent identifier 2 (SUBID) least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name length 2 | application level name for SUBID 2 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits These bits hold the RTCP/I version under which this packet was constructed. This memorandum specifies version 0 of RTCP/I. name (N): 1 bit This bit is set if and only if the sub-component IDs contained in this packet are followed by an application level name. Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 25]
RTP/I December 1999 sub-component count (SC): 5 bits This field contains the number of reported sub-components in this packet. type: 8 bits This field identifies the type of the RTCP/I packet. For SUBREP packets the type is 70. RTCP/I type values of 80 and below are reserved for usage by future versions of RTCP/I. Profiles MAY specify additional RTCP/I packet types between 80 and 255. An example for such an additional RTCP/I packet could be reception quality reports for distributed interactive media which do not employ retransmissions in order to establish reliability. length: 16 bits The length field specifies the length of this packet in units of 32 bits. It excludes the first two 32 bit words of the packet. participant identifier (PID): 32 bits This field contains the PID of the original sender of this packet. active (A): 1 bit per reported sub-component One active bit is present for each reported sub-component. The bit for a sub-component is set if and only if the sub-component is active. Following these bits are padding bits that pad the active bits to a 32 bit boundary. If the number of active bits is 32 then there are no padding bits. subcomponent identifier (SUBID): 64 bits per reported sub-component These are the subcomponent identifiers of the reported sub- components. They MUST occur in the same order as the active bits. name length: 8 bits This field is present for every reported sub-component if and only if the N bit is set. It contains the length of the application level name in octets. This length does not include any padding. application level name: size as indicated by name length This field is present for every reported sub-component if and only if the N bit is set. It contains the application level name. If the name does not end at a 32 bit boundary, then a minimal amount of padding octets are appended to the name so that a full 32 bit boundary is reached. 7.4.2. RTCP/I Source Description Packet The RTCP/I source description packet (SDES) and the participant description items contained in this packet are almost identical to those used for RTCP. Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 26]
RTP/I December 1999 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|R| IC | type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | participant identifier (PID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source description items | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SDES packet is a two-level structure composed of a header and items describing the source. The items are described individually in subsequent sections. version (V), length, and PID: As described for the SUBREP packet (see above). reserved (R): 1 bit This bit is reserved for use with future versions of RTP/I. item count (IC): 5 bits The number of participant description items contained in this packet. A SDES packet MUST contain at least one CNAME item. type: 8 bits Contains the constant 72 to identify this as an RTCP/I SDES packet. Each source description item consists of an 8-bit type field, an 8- bit octet count describing the length of the text (thus, not including this two-octet header), and the text itself. Note that the text can be no longer than 255 octets, but this is consistent with the need to limit RTCP/I bandwidth consumption. The text of a source description is encoded according to the UTF-8 encoding specified in RFC 2279 [Yer98]. US-ASCII is a subset of this encoding and requires no additional encoding. The presence of multi- octet encodings is indicated by setting the most significant bit of a character to a value of one. Items are contiguous, i.e., items are not individually padded to a 32-bit boundary. Text is not null terminated because some multi-octet encodings include null octets. Following the last item a minimal amount of padding octets MUST be appended to pad to the next 32-bit boundary. The SDES items currently defined are described in the next sections. Only the CNAME item is mandatory. Some items shown here may be useful only for particular profiles, but the item types are all assigned Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 27]
RTP/I December 1999 from one common space to promote shared use and to simplify profile- independent applications. Additional items may be registered with the IANA. 6.4.2.1 CNAME: Canonical end-point identifier participant description item 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CNAME=1 | length | user and domain name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The CNAME identifier MUST be included in each source description item, in order to ensure cooperation with distributed continuous non-interactive media that use RTP. It has the following properties: o Like the PID identifier, the CNAME identifier SHOULD be unique among all participants within one RTP/I session. It SHOULD be the same for a single participant that participates in multiple RTP and RTP/I sessions. o To provide a binding across multiple media tools used by one participant in a set of related RTP and RTP/I sessions, the CNAME SHOULD be fixed for that participant. o To facilitate third-party monitoring, the CNAME SHOULD be suitable for either a program or a person to locate the source. Therefore, the CNAME SHOULD be derived algorithmically and not entered manually, when possible. To meet these requirements, the following format SHOULD be used unless a profile specifies an alternate syntax or semantics. The CNAME item SHOULD have the format "user@host", or "host" if a user name is not available as on single- user systems. For both formats, "host" is either the fully qualified domain name of the host from which the real-time data originates, formatted according to the rules specified in RFC 1034 [Moc87a], RFC 1035 [Moc87b] and Section 2.1 of RFC 1123 [Bra89]; or the standard ASCII representation of the host's numeric address on the interface used for the RTP/I communication. For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad. Other address types are expected to have ASCII representations that are mutually unique. The fully qualified domain name is more convenient for a human observer and may avoid the need to send a NAME item in addition, but it may be difficult or impossible to obtain reliably in some operating environments. Applications that may be run in such environments SHOULD use the ASCII representation of the address instead. Examples are "doe@sleepy.megacorp.com" or "doe@192.0.2.89" for a multi-user system. On a system with no user name, examples would be Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 28]
RTP/I December 1999 "sleepy.megacorp.com" or "192.0.2.89". The user name SHOULD be in a form that a program such as "finger" or "talk" could use, i.e., it typically is the login name rather than the personal name. The host name is not necessarily identical to the one in the participant's electronic mail address. This syntax will not provide unique identifiers for each source if an application permits a user to generate multiple sources from one host. Such an application would have to rely on the PID to further identify the source, or the profile for that application would have to specify additional syntax for the CNAME identifier. If each application creates its CNAME independently, the resulting CNAMEs may not be identical as would be required to provide a binding across multiple media tools belonging to one participant in a set of related RTP/I and RTP sessions. If cross-media binding is required, it may be necessary for the CNAME of each tool to be externally configured with the same value by a coordination tool. 6.4.2.2 NAME: User name participant description item 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME=2 | length | common name of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is the real name used to describe the source, e.g., "John Doe, Bit Recycler, Megacorp". It may be in any form desired by the user. For applications such as conferencing, this form of name may be the most desirable for display in participant lists, and therefore might be sent most frequently of those items other than CNAME. Profiles MAY establish such priorities. The NAME value is expected to remain constant at least for the duration of a session. It SHOULD NOT be relied upon to be unique among all participants in the session. 6.4.2.3 EMAIL: Electronic mail address participant description item 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EMAIL=3 | length | email address of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The email address is formatted according to RFC 822 [21], for example, "John.Doe@megacorp.com". The EMAIL value is expected to remain constant for the duration of a session. 6.4.2.4 PHONE: Phone number participant description item Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 29]
RTP/I December 1999 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHONE=4 | length | phone number of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The phone number SHOULD be formatted with the plus sign replacing the international access code. For example, "+1 908 555 1212" for a number in the United States. 6.4.2.5 LOC: Geographic user location participant description item 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOC=5 | length | geographic location of site ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Depending on the application, different degrees of detail are appropriate for this item. For conference applications, a string like "Murray Hill, New Jersey" may be sufficient, while, for an active badge system, strings like "Room 2A244, AT&T BL MH" might be appropriate. The degree of detail is left to the implementation and/or user, but format and content MAY be prescribed by a profile. The LOC value is expected to remain constant for the duration of a session, except for mobile hosts. 6.4.2.6 TOOL: Application or tool name participant description item 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOOL=6 | length | name/version of source app. ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A string giving the name and possibly version of the application generating the stream, e.g., "whiteboard 1.2". This information may be useful for debugging purposes and is similar to the Mailer or Mail-System-Version SMTP headers. The TOOL value is expected to remain constant for the duration of the session. 6.4.2.7 NOTE: Notice/status SDES item 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NOTE=7 | length | note about the source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following semantics are suggested for this item, but these or Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 30]
RTP/I December 1999 other semantics MAY be explicitly defined by a profile. The NOTE item is intended for transient messages describing the current state of the source, e.g., "on the phone, can't talk". Or, during a seminar, this item might be used to convey the title of the talk. It should be used only to carry exceptional information and SHOULD NOT be included routinely by all participants because this would slow down the rate at which SUBREPs are sent, thus impairing the performance of the protocol. In particular, it SHOULD NOT be included as an item in a user's configuration file nor automatically generated as in a quote- of-the-day. Since the NOTE item may be important to display while it is active, the rate at which other non-CNAME items such as NAME are transmitted might be reduced so that the NOTE item can take that part of the RTCP/I bandwidth. When the transient message becomes inactive, the NOTE item SHOULD continue to be transmitted a few times at the same repetition rate but with a string of length zero to signal the receivers. However, receivers SHOULD also consider the NOTE item inactive if it is not received for a small multiple of the repetition rate, or perhaps 20-30 RTCP/I report intervals. 6.4.2.8 PRIV: Private extensions participant description item 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRIV=8 | length | prefix length | prefix string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This item is used to define experimental or application-specific participant description extensions. The item contains a prefix consisting of a length-string pair, followed by the value string filling the remainder of the item and carrying the desired information. The prefix length field is 8 bits long. The prefix string is a name chosen by the person defining the PRIV item to be unique with respect to other PRIV items this application might receive. The application creator might choose to use the application name plus an additional subtype identification if needed. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity. Note that the prefix consumes some space within the item's total length of 255 octets, so the prefix should be kept as short as possible. This facility and the constrained RTCP/I bandwidth SHOULD NOT be overloaded; it is not intended to satisfy all the control communication requirements of all applications. SDES PRIV prefixes will not be registered by IANA. If some form of the PRIV item proves to be of general utility, it SHOULD instead be Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 31]
RTP/I December 1999 assigned a regular SDES item type registered with IANA so that no prefix is required. This simplifies use and increases transmission efficiency. 7.4.3. BYE: Goodbye RTCP/I packet 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0| reserved | type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | participant identifier (PID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reason length | reason for leaving ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The BYE packet indicates that a participant is leaving a session. version (V), reserved, length, PID: As described for the source description packet (see above). type: 8 bits Contains the constant 71 to identify this as an RTCP/I BYE packet. reason length: 8 bits The reason length is optional and only present if a reason for leaving is included in the packet. It defines the length of the reason excluding any padding octets. reason for leaving: length as specified in reason length The reason field may contain an application specific description for the reason why a participant has left the session. It is followed by a minimal amount of padding octets that are necessary to pad the packet to a full 32 bit boundary. 7.4.4. APP: Application-defined RTCP/I packet 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|R| subtype | type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | participant identifier (PID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application-dependent data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 32]
RTP/I December 1999 The APP packet is intended for experimental use as new applications and new features are developed, without requiring packet type value registration. APP packets with unrecognized names SHOULD be ignored. After testing and if wider use is justified, it is RECOMMENDED that each APP packet be redefined without the subtype and name fields and registered with IANA using an RTCP/I packet type. version (V), reserved (R), length, participant identifier PID: As described for the source description packet (see above). subtype: 5 bits May be used as a subtype to allow a set of APP packets to be defined under one unique name, or for any application-dependent data. packet type (PT): 8 bits Contains the constant 73 to identify this as an RTCP/I APP packet. name: 4 octets A name chosen by the person defining the set of APP packets to be unique with respect to other APP packets this application might receive. The application creator might choose to use the application name, and then coordinate the allocation of subtype values to others who want to define new packet types for the application. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity. The name is interpreted as a sequence of four ASCII characters, with uppercase and lowercase characters treated as distinct. application-dependent data: variable length Application-dependent data may or may not appear in an APP packet. It is interpreted by the application and not RTP/I itself. It MUST be a multiple of 32 bits long. 7.5. Allocation of RTCP/I bandwidth As explained above, this specification defines several source description items in addition to the mandatory CNAME item. It also provides a means to define new application-specific RTCP/I packet types. Applications should exercise caution in allocating control bandwidth to this additional information because it will slow down the rate at which sub-component reports are sent, thus impairing the performance of the protocol. It is RECOMMENDED that no more than 20% of the RTCP/I bandwidth allocated to a single participant be used to carry the additional information. Furthermore, it is not intended that all source description items will be included in every application. Those that are included SHOULD be assigned a fraction of the bandwidth according to their utility. Rather than estimate these fractions dynamically, it is recommended that the percentages be Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 33]
RTP/I December 1999 translated statically into report interval counts based on the typical length of an item. For example, an application may be designed to send only CNAME, NAME and EMAIL and not any others. NAME might be given much higher priority than EMAIL because the NAME would be displayed continuously in the application's user interface, whereas EMAIL would be displayed only when requested. At every RTCP/I interval, an SDES packet with the CNAME item would be sent. For a small session operating at the minimum interval, that would be every 5 seconds on the average. Every third interval (15 seconds), one extra item would be included in the ParticipantDescription packet. Seven out of eight times this would be the NAME item, and every eighth time (2 minutes) it would be the EMAIL item. When multiple applications operate in concert using cross-application binding through a common PID for each participant, for example in a multimedia conference composed of multiple RTP and RTP/I sessions for more than one medium, the additional participant description information MAY be sent in only one RTP or RTP/I session. The other sessions would carry only the CNAME item. In particular, this approach SHOULD be applied when a single distributed interactive medium is transmitted over multiple RTP/I sessions (e.g. a distributed virtual environment which is partitioned into several regions). 8. Security Lower layer protocols may eventually provide all the security services that may be desired for applications of RTP/I, including authentication, integrity, and confidentiality. These services have been specified for IP in [Ken98]. An application MAY rely on these lower layer protocols to provide the required security. Alternatively, other services, other implementations of services and other algorithms MAY be defined for RTP/I in the future if warranted. Specifically, a profile MAY specify which services and algorithms should be offered by applications, and MAY provide guidance as to their appropriate use. 9. RTP/I over Network and Transport Protocols This section describes issues specific to carrying RTP/I packets within particular network and transport protocols. The following rules apply unless superseded by protocol-specific definitions outside this specification. RTP/I relies on the underlying protocol(s) to provide demultiplexing of RTP/I data and RTCP/I control streams. For UDP and similar protocols, RTP/I SHOULD use an even port number and the corresponding RTCP/I stream SHOULD use the next higher (odd) port number. If an Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 34]
RTP/I December 1999 application is supplied with an odd number for use as the RTP/I port, it SHOULD replace this number with the next lower (even) number. In a unicast session, applications SHOULD be prepared to receive RTP/I data and control on one port pair and send to another. It is RECOMMENDED that distributed interactive media that require more than one RTP/I session (e.g. for spatial partitioning in military battlefield simulations) use a set of contiguous port numbers. The port numbers MUST be distinct because of a widespread deficiency in existing operating systems that prevents use of the same port with multiple multicast addresses, and for unicast, there is only one permissible address. Thus for layer n, the data port is P + 2n, and the control port is P + 2n + 1. When IP multicast is used, the addresses MUST also be distinct because multicast routing and group membership are managed on an address granularity. However, allocation of contiguous IP multicast addresses cannot be assumed because some groups may require different scopes and may therefore be allocated from different address ranges. 10. Summary of Protocol Constants This section contains a summary listing of the constants defined in this specification. The RTP/I payload type (PT) constants are defined in profiles rather than this document. However, the octet of the RTP/I header which contains the last bit of the type field and the payload type MUST avoid the reserved value 72 to distinguish RTP/I packets from the RTCP/I SDES packet type. This restriction means that payload type 72 is reserved. RTP/I packet types abbrev. name value EVENT event 0 STATE state 1 DELTA_STATE delta state 2 STATE_QUERY state query 3 Additional RTP/I packet types MAY be specified in future versions of RTP/I. RTCP/I packet types abbrev. name value SUBREP sub-component report 70 BYE goodbye 71 SDES source description 72 APP application-defined 73 Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 35]
RTP/I December 1999 Additional RTCP/I packet types may be registered through IANA (see Section 11). SDES types abbrev. name value CNAME canonical name 1 NAME user name 2 EMAIL user's electronic mail address 3 PHONE user's phone number 4 LOC geographic user location 5 TOOL name of application or tool 6 NOTE notice about the source 7 PRIV private extensions 8 Additional RTCP/I packet types may be registered through IANA (see Section 11). RTP/I reliability types (RT) no reliability 0 reliable transport 1 Additional RT values may be registered through IANA (see Section 11). 11. IANA Considerations Additional RTCP/I packet types, SDES types and RT values may be registered through the Internet Assigned Numbers Authority (IANA). Since these number spaces are small, allowing unconstrained registration of new values would not be prudent. To facilitate review of requests and to promote shared use of new types among multiple applications, requests for registration of new values must be documented in an RFC or other permanent and readily available reference such as the product of another cooperative standards body (e.g., ITU-T). Other requests may also be accepted, under the advice of a "designated expert." (Contact the IANA for the contact information of the current expert.) 12. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 36]
RTP/I December 1999 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Addresses of Authors Martin Mauve Volker Hilt Christoph Kuhmuench Juergen Vogel Werner Geyer Wolfgang Effelsberg Praktische Informatik IV University of Mannheim L15, 16 68131 Mannheim Germany e-mail: {mauve,hilt,cjk,jvogel,geyer,effelsberg}@pi4.informatik.uni-mannheim.de Acknowledgements We are especially greatful to Colin Perkins for very important discussions about all aspects of RTP/I and for his effort to review this draft. This work is supported by the European MECCANO Telematics for Research Project 4007 and by the German BMBF (Bundesministerium fuer Forschung und Technologie) with the "V3D2 Digital Library Initiative". Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 37]
RTP/I December 1999 Bibliography [Bra89] R. Braden, "Requirements for internet hosts - application and support," STD 3, RFC 1123, Internet Engineering Task Force, Oct. 1989. [Bra97] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [Cla90] D. D. Clark and D. L. Tennenhouse, "Architectural considerations for a new generation of protocols," in Proc. of the ACM Symposium on Communications Architectures and Protocols, Philadelphia, Pennsylvania, Sept. 1990, pp 200-208. [Flo93] S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," in Proc. of the ACM Symposium on Communications Architectures and Protocols, San Francisco, California, USA, Sept. 1993, pp. 33-44. [Flo94] S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," IEEE/ACM Transactions on Networking, Vol. 2, No. 2, Apr. 1994, pp. 122-136. [Flo97] S. Floyd, V. Jacobson, C. Liu, S. McCanne, L. Zhang, "A reliable multicast framework for leight-weight sessions and application level framing," in: IEEE/ACM Transactions on Networking, Vol. 5, No. 6, Dec. 1997, pp. 784-803. [Ken98] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol," Internet Draft, Internet Engineering Task Force, July 1998. Work in progress. [Mil92] D. L. Mills, "Network Time Protocol (Version 3) specification, implementation and analysis," DARPA Network Working Group Report RFC-1305, University of Delaware, 1992. [Moc87a] P. Mockapetris, "Domain names - concepts and facilities," STD 13, RFC 1034, Internet Engineering Task Force, Nov. 1987. Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 38]
RTP/I December 1999 [Moc87b] P. Mockapetris, "Domain names - implementation and specification," STD 13, RFC 1035, Internet Engineering Task Force, Nov. 1987. [Per99] C. Perkins and J. Crowcroft, "On the use of RTP for shared workspace applications," UCL-CS research note RN/99/108, University College London, Dec. 1999. [Pos81] J. Postel, "Internet protocol," RFC 791, Internet Engineering Task Force, Sept. 1981. [Ros98] J. Rosenberg and H. Schulzrinne, "Sampling of the Group Membership in RTP," Internet Draft, Internet Engineering Task Force, November 1998. Work in progress. [Sch99] H. Schulzrinne, S. Casner, R. Frederick, V. Jacoson, "RTP: A Transport Protocol for Real-Time Applications," Internet Draft, Internet Engineering Task Force, Aug. 1999, Work in progress, revision of RFC 1889. [Yer98] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 2279, Internet Engineering Task Force, Jan. 1998. Mauve, Hilt, Kuhmuench, Vogel, Geyer, Effelsberg [Page 39]