RTP-----------实时软件传输协议外文翻译(一)-通信

1、RTP-实时软件传输协议 外文翻译(一)-通信 2013-07-03 01:06导读：通信工程论文毕业论文，RTP-实时软件传输协议 外文翻译(一)-通信在线阅读，教你怎么写，格式什么样，提供各种参考范例：附录 英文原文资料 RTP: A Transport P导读：ion 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 modifica

2、tions to RTP that are specific toion 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 o

3、perate 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 fo

4、r 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 t

5、ools 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

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

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

8、 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 mechan

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

10、e 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 s

11、mall 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

12、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, occasiona 2013-07-03 01:06导读：ayed out the speaker every 20 ms. This timing reconstruction is perf

13、ormed separately for each source of RTP packets in the conference. The sequence number can also be used by the receiver to estimateayed 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 us

14、ed 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

15、 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 ma

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

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

18、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 sources audio and video can be achieved using timi

19、ng 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-spe

20、ed 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 pack

21、ets 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 s

22、ingle 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 confere

23、nce 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 call

24、ed a translator may be used. Two translator 2013-07-03 01:06导读：ork. 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 viork.Mixers and translators may be des

25、igned 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 g

26、roup 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-实时软件传输协议1 介绍 实时传输协议RTP，可以对于那些具有实时特征的数据，比如交互式的音频、视频提供端

27、到端的传输服务。提供的服务包括对传输数据类型的鉴别，顺序的排列以及传输时间及过程的监控。一般应用程序运行RTP多与UDP来实现多路传输和checksum的服务，虽然两种协议都提供了传输功能，但是RTP 可以用在某些与之相适配的底层网络和传输协议中。RTP可以在网络的允许下利用多点传送功能向多个目标发送数据。 但是要注意到，RTP本身不能对传输的及时性及传输的质量提供保证，这些是依靠它的下层服务来实现的。它也不能保证在传输过程中传输顺序都是有序的，就像他不能确定基层的网络是可靠的，其在网络上传送的包是按顺序的一样。RTP中对包都进行了编号，那样就允许接受者重建包的顺序，而且这些编码可以用来测定包

28、所在的位子，比如一个视频，完全依次进行编码是没有必要的。 RTP最初设计是为了满足多人视频会议，但现在已经不仅仅局限在这个方面了，数据的连续存储，互动的分布式模拟，以及控制和测量部门都能找RTP的身影。 本文对RTP的定义包括两个方面： 1.实时传输协议，用来传输具有实时特征的数据；2.实施传输控制协议RTCP，用来监测服务的质量以及传达某个正在进行的会议中各个成员的信息。对于RTCP第二个方面的应用，在一些不是非常严格的会议我们已经得到了应用：一般这些会议没有复杂的成员控制和建立，那么对所有应用程序控制的交流是没有必要的。这种情况也许会被部分或者全部的包含在一个独立的会议控制中，这个已经超出

29、了本文的讨论范围。 RTP是继应用层框架原理以后新的协议类型，他整合层的处理。也就是说RTP对于一个应用程序所要求得信息处理已经不再是作为一个单独的层去进行，而是随着整合进该程序的进行过程中，同时处理。RTP有意成为一个不完整的协议框架。本文阐述这些功能，希望在那些适合RTP的应用程序中RTP能得到充分的发挥。而不像一些传统的协议那样，需要通过推广或者是机构的授权来增加附加功能。此外，如果想要知道对于某一个特定程序的RTP的描述，你可以在一些相关的书中寻找（见12章）：1.一个概括地说明文档，定义一系列载荷类型编码和相对应的载荷格式。同时也说明了在某些特定的类型的应用程序中RTP的扩展和修改。

30、以及各一个具有代表性的应用程序的炒作过程。一个为视频和音频数据做的概要说明可以在RFC TBD里找到。2.在和类型的描述文档，定义了一个特定的载荷，比如音频和视频编码是如何通过RTP来传输的。对于实时服务的讨论，对于RTP设计及其运行时所遵循的算法和背景的讨论我们可以在第二节找到。 一些RTP程序，不管是试验性质的还是商业性质的从设计阶段上升到了实践阶段。这些程序包括音频和视频工具以及一些诊断工具比如交通监视器。这些工具的用户数量已有成千上万。但是现在的英特网还无法支持实时服务全部潜在的需求，利用RTP的高速宽带服务，比如视频，将会严重的降低网络其他服务的质量。所以，执行者应该采取合适的防范措

31、施来限制那些次要的宽带利用。应用程序文件会清楚的略述这些限制以及在英特网和其他网络服务中高速宽带的实时服务可能会带来的影响。 2 RTP 使用环境 这个章节我们将讨论RTP的使用方面。我们将会通过实例来说明使用RTP程序的一些基本操作，但不限制使用的是什么样的RTP。在这些举例中，RTP运载于IP和UDP之上，在其之后是一些为了视频和音频而已经确立的协议，这些协议可以在同类书籍中找到。2.1 简单的多点音频会议 一个工作组要讨论一个最近的工作草案，他们可以通过英特网的多点服务来进行语音交流。通过一些机制分配，工作组组长获得一个多点传送的地址以及两个端口，一个是用来传输语音数据，一个是用来控制包的传输，这个地址同时也被分送到每个成员那里。如果有保密的需要，数据及控制包可以被加密（详见9.1章），当然这样的话解密钥匙也必须要发布出去，关于机制的具体分布与安排不在RTP的讨论范围之内。 参加音频会议的人以包的形式传输语音数据，平均20毫秒一个。每个包有一个RTP报头。RTP 报头及其数据依次放入UDP包中。RTP报头用来说音频编码的类型（比如PCM ,ADPCM, LPC）,这样的方式可以让数据发送者在会议中改变编码方式，这样的话，我们可以单独的为一个低速会议成员安排接入方式，同时我们也可以对网络的拥堵做出反应。 英特网，