1、RTP: A Transport Protocol for Real-Time Applications1 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 identific

2、ation, sequence numbering, times tamping 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 netwo

3、rk or transport protocols (see HYPERLINK /rfc/rfc1889.html l sec-10#sec-10 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 oth

4、er 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 reco

5、nstruct the senders 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 conference

6、s, 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: 1. The real-time transport prot

7、ocol (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

8、 explicit membership control and set-up, but it is not necessarily intended to support all of an applications control communication requirements. This functionality may be fully or partially subsumed by a separate session control protocol, which is beyond the scope of this document. RTP represents a

9、 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

10、 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 additiona

11、l 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 t

12、his document, a complete specification of RTP for a particular application will require one or more companion documents (see HYPERLINK /rfc/rfc1889.html l sec-12#sec-12 Section 12): 1. A profile specification document, which defines a set of payload type codes and their mapping to payload formats (e

13、.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. 2. Payload format speci

14、fication 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 appli

15、cations, 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 th

16、e 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

17、should clearly outline the limitations and possible operational impact of high-bandwidth real- 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 a

18、pplications 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 wo

19、rking 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

20、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 HYPERLINK /rfc/rfc1889.html l sec-9.1#sec-9.1 Section 9.1, in which case an encryption key must also

21、 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 RT

22、P 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 connect

23、ed 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 numb

24、er 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 als

25、o 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, each instance of the audio applica

26、tion 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 informa

27、tion may also be included subject to control bandwidth limits. A site sends the RTCP BYE packet ( HYPERLINK /rfc/rfc1889.html l sec-6.5#sec-6.5 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 s

28、eparate 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 (can

29、onical) 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 HYPERLINK /rfc/rfc1889.html l sec-5.2#sec-5.2 Section 5.2. D

30、espite the separation, synchronized playback of a sources 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 alw

31、ays 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 cal

32、led 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

33、 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

34、 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 application-level firewall that will not let any IP packets pa

35、ss. 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 transla

36、tor inside the firewall. The translator inside the firewall sends them again as multicast packets to a multicast group restricted to the sites 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

37、 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 fro

38、m individual sources without resynchronization or mixing. Details of the operation of mixers and translators are given in HYPERLINK /rfc/rfc1889.html l sec-7#sec-7 Section 7.中文翻譯RTP-實(shí)時(shí)軟件傳輸協(xié)議1 介紹 實(shí)時(shí)傳輸協(xié)議RTP，能夠關(guān)于那些具有實(shí)時(shí)特征的數(shù)據(jù)，比如交互式的音頻、視頻提供端到端的傳輸服務(wù)。提供的服務(wù)包括對(duì)傳輸數(shù)據(jù)類型的鑒不，順序的排列以及傳輸時(shí)刻及過(guò)程的監(jiān)控。一般應(yīng)用程序運(yùn)行RTP多與UDP來(lái)實(shí)現(xiàn)多路

39、傳輸和checksum的服務(wù)，盡管兩種協(xié)議都提供了傳輸功能，然而RTP 能夠用在某些與之相適配的底層網(wǎng)絡(luò)和傳輸協(xié)議中。RTP能夠在網(wǎng)絡(luò)的同意下利用多點(diǎn)傳送功能向多個(gè)目標(biāo)發(fā)送數(shù)據(jù)。 然而要注意到，RTP本身不能對(duì)傳輸?shù)募皶r(shí)性及傳輸?shù)馁|(zhì)量提供保證，這些是依靠它的下層服務(wù)來(lái)實(shí)現(xiàn)的。它也不能保證在傳輸過(guò)程中傳輸順序差不多上有序的，就像他不能確定基層的網(wǎng)絡(luò)是可靠的，其在網(wǎng)絡(luò)上傳送的包是按順序的一樣。RTP中對(duì)包都進(jìn)行了編號(hào)，那樣就同意同意者重建包的順序，而且這些編碼能夠用來(lái)測(cè)定包所在的位子，比如一個(gè)視頻，完全依次進(jìn)行編碼是沒(méi)有必要的。 RTP最初設(shè)計(jì)是為了滿足多人視頻會(huì)議，但現(xiàn)在差不多不僅僅局限在那個(gè)方

40、面了，數(shù)據(jù)的連續(xù)存儲(chǔ)，互動(dòng)的分布式模擬，以及操縱和測(cè)量部門都能找RTP的身影。 本文對(duì)RTP的定義包括兩個(gè)方面：1.實(shí)時(shí)傳輸協(xié)議，用來(lái)傳輸具有實(shí)時(shí)特征的數(shù)據(jù)；2.實(shí)施傳輸操縱協(xié)議RTCP，用來(lái)監(jiān)測(cè)服務(wù)的質(zhì)量以及傳達(dá)某個(gè)正在進(jìn)行的會(huì)議中各個(gè)成員的信息。關(guān)于RTCP第二個(gè)方面的應(yīng)用，在一些不是特不嚴(yán)格的會(huì)議我們差不多得到了應(yīng)用：一般這些會(huì)議沒(méi)有復(fù)雜的成員操縱和建立，那么對(duì)所有應(yīng)用程序操縱的交流是沒(méi)有必要的。這種情況也許會(huì)被部分或者全部的包含在一個(gè)獨(dú)立的會(huì)議操縱中，那個(gè)差不多超出了本文的討論范圍。 RTP是繼應(yīng)用層框架原理以后新的協(xié)議類型，他整合層的處理。也確實(shí)是講RTP關(guān)于一個(gè)應(yīng)用程序所要求得信息

41、處理差不多不再是作為一個(gè)單獨(dú)的層去進(jìn)行，而是隨著整合進(jìn)該程序的進(jìn)行過(guò)程中，同時(shí)處理。RTP有意成為一個(gè)不完整的協(xié)議框架。本文闡述這些功能，希望在那些適合RTP的應(yīng)用程序中RTP能得到充分的發(fā)揮。而不像一些傳統(tǒng)的協(xié)議那樣，需要通過(guò)推廣或者是機(jī)構(gòu)的授權(quán)來(lái)增加附加功能。此外，假如想要明白關(guān)于某一個(gè)特定程序的RTP的描述，你能夠在一些相關(guān)的書(shū)中查找（見(jiàn)12章）：1.一個(gè)概括地講明文檔，定義一系列載荷類型編碼和相對(duì)應(yīng)的載荷格式。同時(shí)也講明了在某些特定的類型的應(yīng)用程序中RTP的擴(kuò)展和修改。以及各一個(gè)具有代表性的應(yīng)用程序的炒作過(guò)程。一個(gè)為視頻和音頻數(shù)據(jù)做的概要講明能夠在RFC TBD里找到。2.在和類型的描

42、述文檔，定義了一個(gè)特定的載荷，比如音頻和視頻編碼是如何通過(guò)RTP來(lái)傳輸?shù)?。關(guān)于實(shí)時(shí)服務(wù)的討論，關(guān)于RTP設(shè)計(jì)及其運(yùn)行時(shí)所遵循的算法和背景的討論我們能夠在第二節(jié)找到。 一些RTP程序，不管是試驗(yàn)性質(zhì)的依舊商業(yè)性質(zhì)的從設(shè)計(jì)時(shí)期上升到了實(shí)踐時(shí)期。這些程序包括音頻和視頻工具以及一些診斷工具比如交通監(jiān)視器。這些工具的用戶數(shù)量已有成千上萬(wàn)。然而現(xiàn)在的英特網(wǎng)還無(wú)法支持實(shí)時(shí)服務(wù)全部潛在的需求，利用RTP的高速寬帶服務(wù)，比如視頻，將會(huì)嚴(yán)峻的降低網(wǎng)絡(luò)其他服務(wù)的質(zhì)量。因此，執(zhí)行者應(yīng)該采取合適的防范措施來(lái)限制那些次要的寬帶利用。應(yīng)用程序文件會(huì)清晰的略述這些限制以及在英特網(wǎng)和其他網(wǎng)絡(luò)服務(wù)中高速寬帶的實(shí)時(shí)服務(wù)可能會(huì)帶來(lái)的阻礙。 2 RTP 使用環(huán)境 那個(gè)章節(jié)我們將討論RTP的使用方面。我們將會(huì)通過(guò)實(shí)例來(lái)講明使用RTP程序的一些差不多操作，但不限制使用的是什么樣的RTP。在這些舉例中，RTP運(yùn)載于IP和UDP之上，在其之后是一些為了視頻和音頻而差不多確立的協(xié)議，這些協(xié)議能夠在同類書(shū)籍中找到。2.1 簡(jiǎn)單的多點(diǎn)音頻會(huì)議