中文幽默王

RTP--实时软件传输协议 毕业论文外文翻译

网站:中文幽默王   来源:网络收集

英文原文资料 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, timestamping 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 multiparticipant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed 第1 页

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 realtime properties. [2]. The RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an ongoing 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. 第2 页

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 carr 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. 第3 页

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 carr on top of IP and UDP, and follows the conventions established by the profile for audio and video specif 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 specif 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. 第4 页

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. 第5 页

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 carr 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 lowbandwidth 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 第6 页

相关内容
  • 英文文献和中文翻译{RTP-实时软件传输协议}

    英文文献和中文翻译{RTP-实时软件传输协议}

    英文文献和中文翻译{RTP-实时软件传输协议}...

  • 多媒体实时传输协议RTP

    多媒体实时传输协议RTP

    多媒体实时传输协议RTP...

  • 实时传输协议(RTP)

    实时传输协议(RTP)

    实时传输协议(RTP)...

  • RTP 实时传输协议

    RTP 实时传输协议

    RTP 实时传输协议...

  • RTP实时传输协议和实时控制协议

    RTP实时传输协议和实时控制协议

    RTP实时传输协议和实时控制协议...

  • RTP实时传输协议规范

    RTP实时传输协议规范

    RTP实时传输协议规范...

  • RTP实时应用程序传输协议

    RTP实时应用程序传输协议

    RTP实时应用程序传输协议...

  • RTP实时传输协议

    RTP实时传输协议

    RTP实时传输协议...

  • 实时传输协议、实时传输控制协议(RTP、RTCP)简介

    实时传输协议、实时传输控制协议(RTP、RTCP)简介

    实时传输协议、实时传输控制协议(RTP、RTCP)简介...

  • 实时传输协议(RTP)和实时控制协议(RTCP

    实时传输协议(RTP)和实时控制协议(RTCP

    实时传输协议(RTP)和实时控制协议(RTCP...

  • 网友在搜
  • 毕业论文外文翻译要求
  • 毕业论文外文翻译格式
  • 通信毕业论文外文翻译
  • 毕业论文外文翻译网站
  • 毕业论文外文文献翻译
  • php毕业论文外文翻译
  • 土木毕业论文外文翻译
  • 本科毕业论文外文翻译
  • 毕业论文外文翻译模板
  • java论文外文翻译
  • 创业论文外文翻译
  • 艺术论文外文翻译
  • 论文外文翻译范例
  • 毕业论文外文翻译评语
  • 毕业论文外文翻译范文
  • 美少女战士猥琐水 xbox one 分屏双人 我们遇见松花湖 电影 iphone调日历语言 Arc glass 怎么进入pccad系统 惠普cp4025驱动 goodbuy to romance 抠鼻表情什么意思 ios 版权怎么填写 芒果台的美女主持们 arttemplate table ve may bay vietjet skybad攻略 ps4 slim用什么接口 ubuntu alt f2 西班牙包税转运 optiplex 7050 tower mhxX太刀推荐 奥迪sport广告 优酷 女神异闻录5 看书地点 诺姆.乔姆斯基 巴黎圣母院下载 怎样去掉顽固的黑头 动感单车花式动作图解 曼谷dr.bj salon停业了 nis.exe 第八关百目魔君打法 唱歌怎么发出颤音视频 boot disk suju bg 文 南瓜怎么炖好吃 word mac 文档0字节 狗眼白有褐色斑块 绝色的老板娘全文阅读 greatwall一体机开机 sql server sp who2 ansys壳单元实例 one two three i be 长安cs75原厂轮胎 friday杂志 新垣结衣 民乐打击乐 超神学院之大圣系统 学生家法制定

    All Right Reserved 中文幽默王

    声明:本站内容源于网络,出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。文章内容仅供参考,请咨询相关专业人士。

    如果无意之中侵犯了您的版权,或有意见、反馈或投诉等情况 网站地图 网站栏目