Network Working Group
`Request for Comments: 1889
`Category: Standards Track
`
`Audio-Video Transport Working Group
`H. Schulzrinne
`GMD Fokus
`S. Casner
`Precept Software, Inc.
`R. Frederick
`Xerox Palo Alto Research Center
`V. Jacobson
`Lawrence Berkeley National Laboratory
`January 1996
`
`RTP: A Transport Protocol for Real-Time Applications
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
` This memorandum describes RTP, the real-time transport protocol. RTP
` provides end-to-end network transport functions suitable for
` applications transmitting real-time data, such as audio, video or
` simulation data, over multicast or unicast network services. RTP does
` not address resource reservation and does not guarantee quality-of-
` service for real-time services. The data transport is augmented by a
` control protocol (RTCP) to allow monitoring of the data delivery in a
` manner scalable to large multicast networks, and to provide minimal
` control and identification functionality. RTP and RTCP are designed
` to be independent of the underlying transport and network layers. The
` protocol supports the use of RTP-level translators and mixers.
`
`Table of Contents
`
`1.
`2.
` 2.1
` 2.2
` 2.3
`3.
`4.
`5.
` 5.1
` 5.2
`
`Introduction ........................................ 3
`RTP Use Scenarios ................................... 5
`Simple Multicast Audio Conference ................... 5
`Audio and Video Conference .......................... 6
`Mixers and Translators .............................. 6
`Definitions ......................................... 7
`Byte Order, Alignment, and Time Format .............. 9
`RTP Data Transfer Protocol .......................... 10
`RTP Fixed Header Fields ............................. 10
`Multiplexing RTP Sessions ........................... 13
`
`Schulzrinne, et al
`
`Standards Track
`
`[Page 1]
`
`Genius Sports Ex. 1027
`p. 1
`
`

`

`RFC 1889 RTP January 1996
`
` 5.3 Profile-Specific Modifications to the RTP Header..... 14
` 5.3.1 RTP Header Extension ................................ 14
` 6. RTP Control Protocol -- RTCP ........................ 15
` 6.1 RTCP Packet Format .................................. 17
` 6.2 RTCP Transmission Interval .......................... 19
` 6.2.1 Maintaining the number of session members ........... 21
` 6.2.2 Allocation of source description bandwidth .......... 21
` 6.3 Sender and Receiver Reports ......................... 22
` 6.3.1 SR: Sender report RTCP packet ....................... 23
` 6.3.2 RR: Receiver report RTCP packet ..................... 28
` 6.3.3 Extending the sender and receiver reports ........... 29
` 6.3.4 Analyzing sender and receiver reports ............... 29
` 6.4 SDES: Source description RTCP packet ................ 31
` 6.4.1 CNAME: Canonical end-point identifier SDES item ..... 32
` 6.4.2 NAME: User name SDES item ........................... 34
` 6.4.3 EMAIL: Electronic mail address SDES item ............ 34
` 6.4.4 PHONE: Phone number SDES item ....................... 34
` 6.4.5 LOC: Geographic user location SDES item ............. 35
` 6.4.6 TOOL: Application or tool name SDES item ............ 35
` 6.4.7 NOTE: Notice/status SDES item ....................... 35
` 6.4.8 PRIV: Private extensions SDES item .................. 36
` 6.5 BYE: Goodbye RTCP packet ............................ 37
` 6.6 APP: Application-defined RTCP packet ................ 38
` 7. RTP Translators and Mixers .......................... 39
` 7.1 General Description ................................. 39
` 7.2 RTCP Processing in Translators ...................... 41
` 7.3 RTCP Processing in Mixers ........................... 43
` 7.4 Cascaded Mixers ..................................... 44
` 8. SSRC Identifier Allocation and Use .................. 44
` 8.1 Probability of Collision ............................ 44
` 8.2 Collision Resolution and Loop Detection ............. 45
` 9. Security ............................................ 49
` 9.1 Confidentiality ..................................... 49
` 9.2 Authentication and Message Integrity ................ 50
` 10. RTP over Network and Transport Protocols ............ 51
` 11. Summary of Protocol Constants ....................... 51
` 11.1 RTCP packet types ................................... 52
` 11.2 SDES types .......................................... 52
` 12. RTP Profiles and Payload Format Specifications ...... 53
` A. Algorithms .......................................... 56
` A.1 RTP Data Header Validity Checks ..................... 59
` A.2 RTCP Header Validity Checks ......................... 63
` A.3 Determining the Number of RTP Packets Expected and
` Lost ................................................ 63
` A.4 Generating SDES RTCP Packets ........................ 64
` A.5 Parsing RTCP SDES Packets ........................... 65
` A.6 Generating a Random 32-bit Identifier ............... 66
` A.7 Computing the RTCP Transmission Interval ............ 68
`
`Schulzrinne, et al Standards Track [Page 2]
`
`Genius Sports Ex. 1027
`p. 2
`
`

`

`RFC 1889
`
`RTP
`
`January 1996
`
`A.8
`B.
`C.
`D.
`
`Estimating the Interarrival Jitter .................. 71
`Security Considerations ............................. 72
`Addresses of Authors ................................ 72
`Bibliography ........................................ 73
`
`1. Introduction
`
`This memorandum specifies the real-time transport protocol (RTP),
`which provides end-to-end delivery services for data with real-time
`characteristics, such as interactive audio and video. Those services
`include payload type identification, sequence numbering, timestamping
`and delivery monitoring. Applications typically run RTP on top of UDP
`to make use of its multiplexing and checksum services; both protocols
`contribute parts of the transport protocol functionality. However,
`RTP may be used with other suitable underlying network or transport
`protocols (see Section 10). RTP supports data transfer to multiple
`destinations using multicast distribution if provided by the
`underlying network.
`
`Note that RTP itself does not provide any mechanism to ensure timely
`delivery or provide other quality-of-service guarantees, but relies
`on lower-layer services to do so. It does not guarantee delivery or
`prevent out-of-order delivery, nor does it assume that the underlying
`network is reliable and delivers packets in sequence. The sequence
`numbers included in RTP allow the receiver to reconstruct the
`sender’s packet sequence, but sequence numbers might also be used to
`determine the proper location of a packet, for example in video
`decoding, without necessarily decoding packets in sequence.
`
`While RTP is primarily designed to satisfy the needs of multi-
` participant multimedia conferences, it is not limited to that
` particular application. Storage of continuous data, interactive
` distributed simulation, active badge, and control and measurement
` applications may also find RTP applicable.
`
` This document defines RTP, consisting of two closely-linked parts:
`
`o the real-time transport protocol (RTP), to carry data that has
`real-time properties.
`
`o the RTP control protocol (RTCP), to monitor the quality of
`service and to convey information about the participants in an
`on-going session. The latter aspect of RTCP may be sufficient
`for "loosely controlled" sessions, i.e., where there is no
`explicit membership control and set-up, but it is not
`necessarily intended to support all of an application’s control
`communication requirements. This functionality may be fully or
`partially subsumed by a separate session control protocol,
`
`Schulzrinne, et al
`
`Standards Track
`
`[Page 3]
`
`Genius Sports Ex. 1027
`p. 3
`
`

`

`RFC 1889
`
`RTP
`
`January 1996
`
`which is beyond the scope of this document.
`
` RTP represents a new style of protocol following the principles of
` application level framing and integrated layer processing proposed by
` Clark and Tennenhouse [1]. That is, RTP is intended to be malleable
` to provide the information required by a particular application and
` will often be integrated into the application processing rather than
` being implemented as a separate layer. RTP is a protocol framework
` that is deliberately not complete. This document specifies those
` functions expected to be common across all the applications for which
` RTP would be appropriate. Unlike conventional protocols in which
` additional functions might be accommodated by making the protocol
` more general or by adding an option mechanism that would require
` parsing, RTP is intended to be tailored through modifications and/or
` additions to the headers as needed. Examples are given in Sections
` 5.3 and 6.3.3.
`
` Therefore, in addition to this document, a complete specification of
` RTP for a particular application will require one or more companion
` documents (see Section 12):
`
`o a profile specification document, which defines a set of
`payload type codes and their mapping to payload formats (e.g.,
`media encodings). A profile may also define extensions or
`modifications to RTP that are specific to a particular class of
`applications. Typically an application will operate under only
`one profile. A profile for audio and video data may be found in
`the companion RFC TBD.
`
`o payload format specification documents, which define how a
`particular payload, such as an audio or video encoding, is to
`be carried in RTP.
`
` A discussion of real-time services and algorithms for their
` implementation as well as background discussion on some of the RTP
` design decisions can be found in [2].
`
` Several RTP applications, both experimental and commercial, have
` already been implemented from draft specifications. These
` applications include audio and video tools along with diagnostic
` tools such as traffic monitors. Users of these tools number in the
` thousands. However, the current Internet cannot yet support the full
` potential demand for real-time services. High-bandwidth services
` using RTP, such as video, can potentially seriously degrade the
` quality of service of other network services. Thus, implementors
` should take appropriate precautions to limit accidental bandwidth
` usage. Application documentation should clearly outline the
` limitations and possible operational impact of high-bandwidth real-
`
`Schulzrinne, et al
`
`Standards Track
`
`[Page 4]
`
`Genius Sports Ex. 1027
`p. 4
`
`

`

`RFC 1889 RTP January 1996
`
` time services on the Internet and other network services.
`
`2. RTP Use Scenarios
`
` The following sections describe some aspects of the use of RTP. The
` examples were chosen to illustrate the basic operation of
` applications using RTP, not to limit what RTP may be used for. In
` these examples, RTP is carried on top of IP and UDP, and follows the
` conventions established by the profile for audio and video specified
` in the companion Internet-Draft draft-ietf-avt-profile
`
`2.1 Simple Multicast Audio Conference
`
` A working group of the IETF meets to discuss the latest protocol
` draft, using the IP multicast services of the Internet for voice
` communications. Through some allocation mechanism the working group
` chair obtains a multicast group address and pair of ports. One port
` is used for audio data, and the other is used for control (RTCP)
` packets. This address and port information is distributed to the
` intended participants. If privacy is desired, the data and control
` packets may be encrypted as specified in Section 9.1, in which case
` an encryption key must also be generated and distributed. The exact
` details of these allocation and distribution mechanisms are beyond
` the scope of RTP.
`
` The audio conferencing application used by each conference
` participant sends audio data in small chunks of, say, 20 ms duration.
` Each chunk of audio data is preceded by an RTP header; RTP header and
` data are in turn contained in a UDP packet. The RTP header indicates
` what type of audio encoding (such as PCM, ADPCM or LPC) is contained
` in each packet so that senders can change the encoding during a
` conference, for example, to accommodate a new participant that is
` connected through a low-bandwidth link or react to indications of
` network congestion.
`
` The Internet, like other packet networks, occasionally loses and
` reorders packets and delays them by variable amounts of time. To cope
` with these impairments, the RTP header contains timing information
` and a sequence number that allow the receivers to reconstruct the
` timing produced by the source, so that in this example, chunks of
` audio are contiguously played out the speaker every 20 ms. This
` timing reconstruction is performed separately for each source of RTP
` packets in the conference. The sequence number can also be used by
` the receiver to estimate how many packets are being lost.
`
` Since members of the working group join and leave during the
` conference, it is useful to know who is participating at any moment
` and how well they are receiving the audio data. For that purpose,
`
`Schulzrinne, et al Standards Track [Page 5]
`
`Genius Sports Ex. 1027
`p. 5
`
`

`

`RFC 1889 RTP January 1996
`
` each instance of the audio application in the conference periodically
` multicasts a reception report plus the name of its user on the RTCP
` (control) port. The reception report indicates how well the current
` speaker is being received and may be used to control adaptive
` encodings. In addition to the user name, other identifying
` information may also be included subject to control bandwidth limits.
` A site sends the RTCP BYE packet (Section 6.5) when it leaves the
` conference.
`
`2.2 Audio and Video Conference
`
` If both audio and video media are used in a conference, they are
` transmitted as separate RTP sessions RTCP packets are transmitted for
` each medium using two different UDP port pairs and/or multicast
` addresses. There is no direct coupling at the RTP level between the
` audio and video sessions, except that a user participating in both
` sessions should use the same distinguished (canonical) name in the
` RTCP packets for both so that the sessions can be associated.
`
` One motivation for this separation is to allow some participants in
` the conference to receive only one medium if they choose. Further
` explanation is given in Section 5.2. Despite the separation,
` synchronized playback of a source’s audio and video can be achieved
` using timing information carried in the RTCP packets for both
` sessions.
`
`2.3 Mixers and Translators
`
` So far, we have assumed that all sites want to receive media data in
` the same format. However, this may not always be appropriate.
` Consider the case where participants in one area are connected
` through a low-speed link to the majority of the conference
` participants who enjoy high-speed network access. Instead of forcing
` everyone to use a lower-bandwidth, reduced-quality audio encoding, an
` RTP-level relay called a mixer may be placed near the low-bandwidth
` area. This mixer resynchronizes incoming audio packets to reconstruct
` the constant 20 ms spacing generated by the sender, mixes these
` reconstructed audio streams into a single stream, translates the
` audio encoding to a lower-bandwidth one and forwards the lower-
` bandwidth packet stream across the low-speed link. These packets
` might be unicast to a single recipient or multicast on a different
` address to multiple recipients. The RTP header includes a means for
` mixers to identify the sources that contributed to a mixed packet so
` that correct talker indication can be provided at the receivers.
`
` Some of the intended participants in the audio conference may be
` connected with high bandwidth links but might not be directly
` reachable via IP multicast. For example, they might be behind an
`
`Schulzrinne, et al Standards Track [Page 6]
`
`Genius Sports Ex. 1027
`p. 6
`
`

`

`RFC 1889 RTP January 1996
`
` application-level firewall that will not let any IP packets pass. For
` these sites, mixing may not be necessary, in which case another type
` of RTP-level relay called a translator may be used. Two translators
` are installed, one on either side of the firewall, with the outside
` one funneling all multicast packets received through a secure
` connection to the translator inside the firewall. The translator
` inside the firewall sends them again as multicast packets to a
` multicast group restricted to the site’s internal network.
`
` Mixers and translators may be designed for a variety of purposes. An
` example is a video mixer that scales the images of individual people
` in separate video streams and composites them into one video stream
` to simulate a group scene. Other examples of translation include the
` connection of a group of hosts speaking only IP/UDP to a group of
` hosts that understand only ST-II, or the packet-by-packet encoding
` translation of video streams from individual sources without
` resynchronization or mixing. Details of the operation of mixers and
` translators are given in Section 7.
`
`3. Definitions
`
` RTP payload: The data transported by RTP in a packet, for example
` audio samples or compressed video data. The payload format and
` interpretation are beyond the scope of this document.
`
` RTP packet: A data packet consisting of the fixed RTP header, a
` possibly empty list of contributing sources (see below), and the
` payload data. Some underlying protocols may require an
` encapsulation of the RTP packet to be defined. Typically one
` packet of the underlying protocol contains a single RTP packet,
` but several RTP packets may be contained if permitted by the
` encapsulation method (see Section 10).
`
` RTCP packet: A control packet consisting of a fixed header part
` similar to that of RTP data packets, followed by structured
` elements that vary depending upon the RTCP packet type. The
` formats are defined in Section 6. Typically, multiple RTCP
` packets are sent together as a compound RTCP packet in a single
` packet of the underlying protocol; this is enabled by the length
` field in the fixed header of each RTCP packet.
`
` Port: The "abstraction that transport protocols use to distinguish
` among multiple destinations within a given host computer. TCP/IP
` protocols identify ports using small positive integers." [3] The
` transport selectors (TSEL) used by the OSI transport layer are
` equivalent to ports. RTP depends upon the lower-layer protocol
` to provide some mechanism such as ports to multiplex the RTP and
` RTCP packets of a session.
`
`Schulzrinne, et al Standards Track [Page 7]
`
`Genius Sports Ex. 1027
`p. 7
`
`

`

`RFC 1889 RTP January 1996
`
` Transport address: The combination of a network address and port that
` identifies a transport-level endpoint, for example an IP address
` and a UDP port. Packets are transmitted from a source transport
` address to a destination transport address.
`
` RTP session: The association among a set of participants
` communicating with RTP. For each participant, the session is
` defined by a particular pair of destination transport addresses
` (one network address plus a port pair for RTP and RTCP). The
` destination transport address pair may be common for all
` participants, as in the case of IP multicast, or may be
` different for each, as in the case of individual unicast network
` addresses plus a common port pair. In a multimedia session,
` each medium is carried in a separate RTP session with its own
` RTCP packets. The multiple RTP sessions are distinguished by
` different port number pairs and/or different multicast
` addresses.
`
` Synchronization source (SSRC): The source of a stream of RTP packets,
` identified by a 32-bit numeric SSRC identifier carried in the
` RTP header so as not to be dependent upon the network address.
` All packets from a synchronization source form part of the same
` timing and sequence number space, so a receiver groups packets
` by synchronization source for playback. Examples of
` synchronization sources include the sender of a stream of
` packets derived from a signal source such as a microphone or a
` camera, or an RTP mixer (see below). A synchronization source
` may change its data format, e.g., audio encoding, over time. The
` SSRC identifier is a randomly chosen value meant to be globally
` unique within a particular RTP session (see Section 8). A
` participant need not use the same SSRC identifier for all the
` RTP sessions in a multimedia session; the binding of the SSRC
` identifiers is provided through RTCP (see Section 6.4.1). If a
` participant generates multiple streams in one RTP session, for
` example from separate video cameras, each must be identified as
` a different SSRC.
`
` Contributing source (CSRC): A source of a stream of RTP packets that
` has contributed to the combined stream produced by an RTP mixer
` (see below). The mixer inserts a list of the SSRC identifiers of
` the sources that contributed to the generation of a particular
` packet into the RTP header of that packet. This list is called
` the CSRC list. An example application is audio conferencing
` where a mixer indicates all the talkers whose speech was
` combined to produce the outgoing packet, allowing the receiver
` to indicate the current talker, even though all the audio
` packets contain the same SSRC identifier (that of the mixer).
`
`Schulzrinne, et al Standards Track [Page 8]
`
`Genius Sports Ex. 1027
`p. 8
`
`

`

`RFC 1889 RTP January 1996
`
` End system: An application that generates the content to be sent in
` RTP packets and/or consumes the content of received RTP packets.
` An end system can act as one or more synchronization sources in
` a particular RTP session, but typically only one.
`
` Mixer: An intermediate system that receives RTP packets from one or
` more sources, possibly changes the data format, combines the
` packets in some manner and then forwards a new RTP packet. Since
` the timing among multiple input sources will not generally be
` synchronized, the mixer will make timing adjustments among the
` streams and generate its own timing for the combined stream.
` Thus, all data packets originating from a mixer will be
` identified as having the mixer as their synchronization source.
`
` Translator: An intermediate system that forwards RTP packets with
` their synchronization source identifier intact. Examples of
` translators include devices that convert encodings without
` mixing, replicators from multicast to unicast, and application-
` level filters in firewalls.
`
` Monitor: An application that receives RTCP packets sent by
` participants in an RTP session, in particular the reception
` reports, and estimates the current quality of service for
` distribution monitoring, fault diagnosis and long-term
` statistics. The monitor function is likely to be built into the
` application(s) participating in the session, but may also be a
` separate application that does not otherwise participate and
` does not send or receive the RTP data packets. These are called
` third party monitors.
`
` Non-RTP means: Protocols and mechanisms that may be needed in
` addition to RTP to provide a usable service. In particular, for
` multimedia conferences, a conference control application may
` distribute multicast addresses and keys for encryption,
` negotiate the encryption algorithm to be used, and define
` dynamic mappings between RTP payload type values and the payload
` formats they represent for formats that do not have a predefined
` payload type value. For simple applications, electronic mail or
` a conference database may also be used. The specification of
` such protocols and mechanisms is outside the scope of this
` document.
`
`4. 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 [4].
` Unless otherwise noted, numeric constants are in decimal (base 10).
`
`Schulzrinne, et al Standards Track [Page 9]
`
`Genius Sports Ex. 1027
`p. 9
`
`

`

`RFC 1889 RTP January 1996
`
` 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.
`
` Wallclock time (absolute time) is represented using the timestamp
` format of the Network Time Protocol (NTP), which is in seconds
` relative to 0h UTC on 1 January 1900 [5]. The full resolution NTP
` timestamp is a 64-bit unsigned fixed-point number with the integer
` part in the first 32 bits and the fractional part in the last 32
` bits. In some fields where a more compact representation is
` appropriate, only the middle 32 bits are used; that is, the low 16
` bits of the integer part and the high 16 bits of the fractional part.
` The high 16 bits of the integer part must be determined
` independently.
`
`5. RTP Data Transfer Protocol
`
`5.1 RTP Fixed Header Fields
`
` The RTP header has the following format:
`
` 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=2|P|X| CC |M| PT | sequence number |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | timestamp |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | synchronization source (SSRC) identifier |
` +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
` | contributing source (CSRC) identifiers |
` | .... |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` The first twelve octets are present in every RTP packet, while the
` list of CSRC identifiers is present only when inserted by a mixer.
` The fields have the following meaning:
`
` version (V): 2 bits
` This field identifies the version of RTP. The version defined by
` this specification is two (2). (The value 1 is used by the first
` draft version of RTP and the value 0 is used by the protocol
` initially implemented in the "vat" audio tool.)
`
` padding (P): 1 bit
` If the padding bit is set, the packet contains one or more
` additional padding octets at the end which are not part of the
`
`Schulzrinne, et al Standards Track [Page 10]
`
`Genius Sports Ex. 1027
`p. 10
`
`

`

`RFC 1889 RTP January 1996
`
` payload. The last octet of the padding contains a count of how
` many padding octets should be ignored. Padding may be needed by
` some encryption algorithms with fixed block sizes or for
` carrying several RTP packets in a lower-layer protocol data
` unit.
`
` extension (X): 1 bit
` If the extension bit is set, the fixed header is followed by
` exactly one header extension, with a format defined in Section
` 5.3.1.
`
` CSRC count (CC): 4 bits
` The CSRC count contains the number of CSRC identifiers that
` follow the fixed header.
`
` marker (M): 1 bit
` The interpretation of the marker is defined by a profile. It is
` intended to allow significant events such as frame boundaries to
` be marked in the packet stream. A profile may define additional
` marker bits or specify that there is no marker bit by changing
` the number of bits in the payload type field (see Section 5.3).
`
` payload type (PT): 7 bits
` This field identifies the format of the RTP payload and
` determines its interpretation by the application. A profile
` specifies a default static mapping of payload type codes to
` payload formats. Additional payload type codes may be defined
` dynamically through non-RTP means (see Section 3). An initial
` set of default mappings for audio and video is specified in the
` companion profile Internet-Draft draft-ietf-avt-profile, and
` may be extended in future editions of the Assigned Numbers RFC
` [6]. An RTP sender emits a single RTP payload type at any given
` time; this field is not intended for multiplexing separate media
` streams (see Section 5.2).
`
` sequence number: 16 bits
` The sequence number increments by one for each RTP data packet
` sent, and may be used by the receiver to detect packet loss and
` to restore packet sequence. The initial value of the sequence
` number is random (unpredictable) to make known-plaintext attacks
` on encryption more difficult, even if the source itself does not
` encrypt, because the packets may flow through a translator that
` does. Techniques for choosing unpredictable numbers are
` discussed in [7].
`
` timestamp: 32 bits
` The timestamp reflects the sampling instant of the first octet
` in the RTP data packet. The sampling instant must be derived
`
`Schulzrinne, et al Standards Track [Page 11]
`
`Genius Sports Ex. 1027
`p. 11
`
`

`

`RFC 1889 RTP January 1996
`
` from a clock that increments monotonically and linearly in time
` to allow synchronization and jitter calculations (see Section
` 6.3.1). The resolution of the clock must be sufficient for the
` desired synchronization accuracy and for measuring packet
` arrival jitter (one tick per video frame is typically not
` sufficient). The clock frequency is dependent on the format of
` data carried as payload and is specified statically in the
` profile or payload format specification that defines the format,
` or may be specified dynamically for payload formats defined
` through non-RTP means. If RTP packets are generated
` periodically, the nominal sampling instant as determined from
` the sampling clock is to be used, not a reading of the system
` clock. As an example, for fixed-rate audio the timestamp clock
` would likely increment by one for each sampling period. If an
` audio application reads blocks covering 160 sampling periods
` from the input device, the timestamp would be increased by 160
` for each such block, regardless of whether the block is
` transmitted in a packet or dropped as silent.
`
` The initial value of the timestamp is random, as for the sequence
` number. Several consecutive RTP packets may have equal timestamps if
` they are (logically) generated at once, e.g., belong t