计算机毕业论文参考文献(中英文对照)

附录

英文原文资料

RTP: A Transport Protocol for Real-Time

Applications

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

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

application. Storage of continuous data, interactive distributed

parts:

[1]. The real-time transport protocol (RTP), to carry data that has

real-time properties.

[2]. 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

RTP represents a new style of protocol following the principles

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

[1]. 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

[2]. Payload format specification documents, which define how a

particular payload, such as an audio or video encoding, is to be

carried in RTP.

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

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

packets. This address and port information is distributed to the

intended participants. If privacy is desired, the data and control

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