`415.561.6767
`415.840-0391 c-fax
`
`Internet Archive
`300 Funston Avenue
`San Francisco, CA 94118
`
`AFFIDAVIT OF CHRISTOPHER BUTLER
`
`1. I am the Office Manager at the Internet Archive, located in San Francisco,
`California. I make this declaration of my own personal knowledge.
`2. The Internet Archive is a website that provides access to a digital library of
`Internet sites and other cultural artifacts in digital form. Like a paper library, we provide
`free access to researchers, historians, scholars, and the general public. The Internet
`Archive has partnered with and receives support from various institutions, including the
`Library of Congress.
`3. The Internet Archive has created a service known as the Wayback Machine. The
`Wayback Machine makes it possible to surf more than 450 billion pages stored in the
`Internet Archive's web archive. Visitors to the Wayback Machine can search archives
`by URL (i.e., a website address). If archived records for a URL are available, the visitor
`will be presented with a list of available dates. The visitor may select one of those
`dates, and then begin surfing on an archived version of the Web. The links on the
`archived files, when served by the Wayback Machine, point to other archived files
`(whether HTML pages or images). If a visitor clicks on a link on an archived page, the
`Wayback Machine will serve the archived file with the closest available date to the page
`upon which the link appeared and was clicked.
`4. The archived data made viewable and browseable by the Wayback Machine is
`compiled using software programs known as crawlers, which surf the Web and
`automatically store copies of web files, preserving these files as they exist at the point of
`time of capture.
`5. The Internet Archive assigns a URL on its site to the archived files in the format
`http://web.archive.org/web/[Year
`in yyyy][Month in mm][Day in dd][Time code in
`hh:mm:ss]/[Archived URL]. Thus, the Internet Archive URL
`http://web.archive.org/web/l 9970126045828/http://www.archive.org/ would be the
`URL for the record of the Internet Archive home page HTML file
`(http://www.archive.org/) archived on January 26, 1997 at 4:58 a.m. and 28 seconds
`(1997/01/26 at 04:58:28). A web browser may be set such that a printout from it will
`display the URL of a web page in the printout's footer. The date assigned by the Internet
`Archive applies to the HTML file but not to image files linked therein. Thus images that
`appear on a page may not have been archived on the same date as the HTML file.
`Likewise, if a website is designed with "frames," the date assigned by the Internet
`Archive applies to the frameset as a whole, and not the individual pages within each
`frame.
`6. Attached hereto as Exhibit A are true and accurate copies of printouts of the
`Internet Archive's records of the HTML files or txt files for the URLs and the dates
`specified in the footer of the printout.
`7. I declare under penalty of perjury that the foregoing is true and correct.
`
`Christopher Butler
`
`EX 1045 Page 1
`
`
`
`CALIFORNIA JURA T
`
`See Attached Document.
`
`State of California
`County of San Francisco
`
`A notary public or other officer completing this
`certificate verifies only the identity of the
`individual who signed the document to which this
`certificate is attached , and not the truthfulness,
`accuracy, or validity of that document.
`
`Subscribed and sworn to ( or affirmed) before me on
`this
`-~-:::;-~ day of No~
`
`, ;;up 11 , by
`
`Christopher Butler,
`
`proved to me on the basis of satisfactory evidence to be
`the person who app ed
`
`Signature :
`
`\7
`
`EX 1045 Page 2
`
`
`
`
`Exhibit A
`
`Exhibit A
`
`EX 1045 Page 3
`
`EX 1045 Page 3
`
`
`
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`
`11/5/2019
`
`
`
`
`
`
`Network Working Group Audio-Video Transport Working Group
`Request for Comments: 1889 H. Schulzrinne
`Category: Standards Track 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. Introduction ........................................ 3
` 2. RTP Use Scenarios ................................... 5
` 2.1 Simple Multicast Audio Conference ................... 5
` 2.2 Audio and Video Conference .......................... 6
` 2.3 Mixers and Translators .............................. 6
` 3. Definitions ......................................... 7
` 4. Byte Order, Alignment, and Time Format .............. 9
` 5. RTP Data Transfer Protocol .......................... 10
` 5.1 RTP Fixed Header Fields ............................. 10
` 5.2 Multiplexing RTP Sessions ........................... 13
`
`
`
`Schulzrinne, et al Standards Track [Page 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]
`
`RFC 1889 RTP January 1996
`
`
` A.8 Estimating the Interarrival Jitter .................. 71
` B. Security Considerations ............................. 72
` C. Addresses of Authors ................................ 72
` D. 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
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`
`1/33
`
`EX 1045 Page 4
`
`
`
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`11/5/2019
` 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]
`
`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]
`
`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
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`
`2/33
`
`EX 1045 Page 5
`
`
`
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`11/5/2019
` 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]
`
`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]
`
`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.
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`
`3/33
`
`EX 1045 Page 6
`
`
`
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`
`11/5/2019
`
`
`
`Schulzrinne, et al Standards Track [Page 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]
`
`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]
`
`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
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`
`4/33
`
`EX 1045 Page 7
`
`
`
`https://web.archive.org/web/19980530055800if_/http://www.nic.it:80/mirrors/rfc/rfc1889.txt
`11/5/2019
` bits. In some fields where a more compact representation is
` appropriate, only the middle 32 bits are used; that is, the low 16
` bits o