- 相關(guān)推薦
RTP-----實時軟件傳輸協(xié)議 外文翻譯(一)
附錄
英文原文資料
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 services include payload type identification, 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 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:
[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 session control protocol, 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):
[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 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 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- 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, 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 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.
中文翻譯
RTP-----------實時軟件傳輸協(xié)議
1 介紹
實時傳輸協(xié)議RTP，可以對于那些具有實時特征的數(shù)據(jù)，比如交互式的音頻、視頻提供端到端的傳輸服務(wù)。提供的服務(wù)包括對傳輸數(shù)據(jù)類型的鑒別，順序的排列以及傳輸時間及過程的監(jiān)控。一般應(yīng)用程序運行RTP多與UDP來實現(xiàn)多路傳輸和checksum的服務(wù)，雖然兩種協(xié)議都提供了傳輸功能，但是RTP 可以用在某些與之相適配的底層網(wǎng)絡(luò)和傳輸協(xié)議中。RTP可以在網(wǎng)絡(luò)的允許下利用多點傳送功能向多個目標(biāo)發(fā)送數(shù)據(jù)。
但是要注意到，RTP本身不能對傳輸?shù)募皶r性及傳輸?shù)馁|(zhì)量提供保證，這些是依靠它的下層服務(wù)來實現(xiàn)的。它也不能保證在傳輸過程中傳輸順序都是有序的，就像他不能確定基層的網(wǎng)絡(luò)是可靠的，其在網(wǎng)絡(luò)上傳送的包是按順序的一樣。RTP中對包都進行了編號，那樣就允許接受者重建包的順序，而且這些編碼可以用來測定包所在的位子，比如一個視頻，完全依次進行編碼是沒有必要的。
RTP最初設(shè)計是為了滿足多人視頻會議，但現(xiàn)在已經(jīng)不僅僅局限在這個方面了，數(shù)據(jù)的連續(xù)存儲，互動的分布式模擬，以及控制和測量部門都能找RTP的身影。
本文對RTP的定義包括兩個方面：
[1].實時傳輸協(xié)議，用來傳輸具有實時特征的數(shù)據(jù)；
[2].實施傳輸控制協(xié)議RTCP，用來監(jiān)測服務(wù)的質(zhì)量以及傳達某個正在進行的會議中各個成員的信息。對于RTCP第二個方面的應(yīng)用，在一些不是非常嚴(yán)格的會議我們已經(jīng)得到了應(yīng)用：一般這些會議沒有復(fù)雜的成員控制和建立，那么對所有應(yīng)用程序控制的交流是沒有必要的。這種情況也許會被部分或者全部的包含在一個獨立的會議控制中，這個已經(jīng)超出了本文的討論范圍。
RTP是繼應(yīng)用層框架原理以后新的協(xié)議類型，他整合層的處理。也就是說RTP對于一個應(yīng)用程序所要求得信息處理已經(jīng)不再是作為一個單獨的層去進行，而是隨著整合進該程序的進行過程中，同時處理。RTP有意成為一個不完整的協(xié)議框架。本文闡述這些功能，希望在那些適合RTP的應(yīng)用程序中RTP能得到充分的發(fā)揮。而不像一些傳統(tǒng)的協(xié)議那樣，需要通過推廣或者是機構(gòu)的授權(quán)來增加附加功能。此外，如果想要知道對于某一個特定程序的RTP的描述，你可以在一些相關(guān)的書中尋找（見12章）：
[1].一個概括地說明文檔，定義一系列載荷類型編碼和相對應(yīng)的載荷格式。同時也說明了在某些特定的類型的應(yīng)用程序中RTP的擴展和修改。以及各一個具有代表性的應(yīng)用程序的炒作過程。一個為視頻和音頻數(shù)據(jù)做的概要說明可以在RFC TBD里找到。
[2].在和類型的描述文檔，定義了一個特定的載荷，比如音頻和視頻編碼是如何通過RTP來傳輸?shù)摹?br />
對于實時服務(wù)的討論，對于RTP設(shè)計及其運行時所遵循的算法和背景的討論我們可以在第二節(jié)找到。
一些RTP程序，不管是試驗性質(zhì)的還是商業(yè)性質(zhì)的從設(shè)計階段上升到了實踐階段。這些程序包括音頻和視頻工具以及一些診斷工具比如交通監(jiān)視器。這些工具的用戶數(shù)量已有成千上萬。但是現(xiàn)在的英特網(wǎng)還無法支持實時服務(wù)全部潛在的需求，利用RTP的高速寬帶服務(wù)，比如視頻，將會嚴(yán)重的降低網(wǎng)絡(luò)其他服務(wù)的質(zhì)量。所以，執(zhí)行者應(yīng)該采取合適的防范措施來限制那些次要的寬帶利用。應(yīng)用程序文件會清楚的略述這些限制以及在英特網(wǎng)和其他網(wǎng)絡(luò)服務(wù)中高速寬帶的實時服務(wù)可能會帶來的影響。
2 RTP 使用環(huán)境
這個章節(jié)我們將討論RTP的使用方面。我們將會通過實例來說明使用RTP程序的一些基本操作，但不限制使用的是什么樣的RTP。在這些舉例中，RTP運載于IP和UDP之上，在其之后是一些為了視頻和音頻而已經(jīng)確立的協(xié)議，這些協(xié)議可以在同類書籍中找到。
2.1 簡單的多點音頻會議
一個工作組要討論一個最近的工作草案，他們可以通過英特網(wǎng)的多點服務(wù)來進行語音交流。通過一些機制分配，工作組組長獲得一個多點傳送的地址以及兩個端口，一個是用來傳輸語音數(shù)據(jù)，一個是用來控制包的傳輸，這個地址同時也被分送到每個成員那里。如果有保密的需要，數(shù)據(jù)及控制包可以被加密（詳見9.1章），當(dāng)然這樣的話解密鑰匙也必須要發(fā)布出去，關(guān)于機制的具體分布與安排不在RTP的討論范圍之內(nèi)。
參加音頻會議的人以包的形式傳輸語音數(shù)據(jù)，平均20毫秒一個。每個包有一個RTP報頭。RTP 報頭及其數(shù)據(jù)依次放入UDP包中。RTP報頭用來說音頻編碼的類型（比如PCM ,ADPCM, LPC）,這樣的方式可以讓數(shù)據(jù)發(fā)送者在會議中改變編碼方式，這樣的話，我們可以單獨的為一個低速會議成員安排接入方式，同時我們也可以對網(wǎng)絡(luò)的擁堵做出反應(yīng)。
英特網(wǎng)，和其他的封寶試的網(wǎng)絡(luò)一樣，有時候會丟失包或者發(fā)生不可預(yù)知的時間延遲，為了處理這種情況，RTP報頭包含了一個時間信息，和一個序列號碼，那樣就允許接受者重新排序，在這個例子中，音頻包每隔20毫秒發(fā)出一個，會議中對于這些RTP包時序的重組一直在獨立的進行著。序列號碼還可以用來估計有多少包在傳輸中丟失了。
鑒于工作組成員會在開會時進入或者離開，那么清楚的知道到底誰在參加會議以及到底他們接受的音頻數(shù)據(jù)質(zhì)量如何是很有用的。于是每一個遠程應(yīng)用程序會定時的往RTCP發(fā)送一個接收報告，報告里會附上他們的名字。這個報告會指出現(xiàn)在對于講話者數(shù)據(jù)接收如何從而用來控制合適的編碼。除了用戶的名字之外，我們還會用到其他的鑒別信息來控制款待限制。一個節(jié)點會發(fā)送一個“BYE”包（見6.5章）當(dāng)他離開的時候。
2.2音頻和視頻會議
如果在一個會議中同時要用到視頻和音頻的話，他們在傳輸?shù)倪^程中，用的是互相獨立的RTP層，兩種媒體的RTCP包也是用不同的UDP端口或者是不同的多點傳送地址。
在音頻和視頻兩個層之間沒有直接的連接。除非是一個成員要以同一個規(guī)范化的名字參加兩個會議層，這種情況下連個層會被連在一起。
把兩種媒體分割開來可以使會議成員自由的選擇一種或兩種媒體。盡管是分割的，但是通過RTCP包中的時間信息，我們完全可以是兩種媒體同步起來。
2.3 混頻和翻譯
到目前為止，我們一直假定所有的網(wǎng)站都是接受相同類型的媒體數(shù)據(jù)，但事實上，這種假定是不合理的�？紤]到有些成員，以低速網(wǎng)絡(luò)接入一個大部分成員是高速網(wǎng)絡(luò)的會議中，我們可以在低速網(wǎng)絡(luò)的區(qū)域放一個混頻器那樣我們就不用要求每一個成員都要以低速，低質(zhì)的音頻方式接入了。這個混頻器重新同步音頻包，以恒定的20毫秒的間隔重建發(fā)送者的音頻信號。把這些改造過的音頻流混合成一個單獨的流，這樣就把這些音頻編碼轉(zhuǎn)化成了適用于低速寬帶面下低速連接的數(shù)據(jù)包流。這些包可以被斷點傳送給一個用戶也可以被多點傳送給不同用戶的不同地址。RTP報頭包含了混合器的方法，這樣即使包被混合了，接受者還是可以正確的確認誰在發(fā)言。
音頻會議中，一些用戶雖然是通過高速寬帶連接，但他們有可能依然不可以直接通過IP被多點傳送。比如，他們運行了一個應(yīng)用層的防火墻，就會阻止任何IP包通過。對于這些站點，混頻可能會失敗，這種情況下我們可以利用另一個方法,翻譯。防火墻的兩端都裝上翻譯器，這樣防火墻的兩端好像形成了一個相連的漏斗，多點傳送包，就可以安全的從外面?zhèn)鞯嚼锩�，然后防火墻�?nèi)部的翻譯器再一次對網(wǎng)絡(luò)內(nèi)部進行多點傳送。
【RTP-----實時軟件傳輸協(xié)議 外文翻譯(一)】相關(guān)文章：
我國信息傳輸、軟件和信息技術(shù)服務(wù)行業(yè)盈利驅(qū)動因素分析05-24
通信工程中傳輸技術(shù)研究05-14
小議3D 視頻編碼傳輸技術(shù)05-07
外文專著參考文獻的格式02-23
外文譯著參考文獻格式02-23
關(guān)于通信工程傳輸技術(shù)的應(yīng)用分析（精選8篇）07-26
適應(yīng)實時多任務(wù)的微控制器高效指令支持05-29
論翻譯是文化翻譯08-23