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-----------实时软件传输协议
1 介绍
实时传输协议RTP，可以对于那些具有实时特征的数据，比如交互式的音频、视频提供端到端的传输服务。提供的服务包括对传输数据类型的鉴别，顺序的排列以及传输时间及过程的监控。一般应用程序运行RTP多与UDP来实现多路传输和checksum的服务，虽然两种协议都提供了传输功能，但是RTP 可以用在某些与之相适配的底层网络和传输协议中。RTP可以在网络的允许下利用多点传送功能向多个目标发送数据。
但是要注意到，RTP本身不能对传输的及时性及传输的质量提供保证，这些是依靠它的下层服务来实现的。它也不能保证在传输过程中传输顺序都是有序的，就像他不能确定基层的网络是可靠的，其在网络上传送的包是按顺序的一样。RTP中对包都进行了编号，那样就允许接受者重建包的顺序，而且这些编码可以用来测定包所在的位子，比如一个视频，完全依次进行编码是没有必要的。
RTP最初设计是为了满足多人视频会议，但现在已经不仅仅局限在这个方面了，数据的连续存储，互动的分布式模拟，以及控制和测量部门都能找RTP的身影。
本文对RTP的定义包括两个方面：
[1].实时传输协议，用来传输具有实时特征的数据；
[2].实施传输控制协议RTCP，用来监测服务的质量以及传达某个正在进行的会议中各个成员的信息。对于RTCP第二个方面的应用，在一些不是非常严格的会议我们已经得到了应用：一般这些会议没有复杂的成员控制和建立，那么对所有应用程序控制的交流是没有必要的。这种情况也许会被部分或者全部的包含在一个独立的会议控制中，这个已经超出了本文的讨论范围。
RTP是继应用层框架原理以后新的协议类型，他整合层的处理。也就是说RTP对于一个应用程序所要求得信息处理已经不再是作为一个单独的层去进行，而是随着整合进该程序的进行过程中，同时处理。RTP有意成为一个不完整的协议框架。本文阐述这些功能，希望在那些适合RTP的应用程序中RTP能得到充分的发挥。而不像一些传统的协议那样，需要通过推广或者是机构的授权来增加附加功能。此外，如果想要知道对于某一个特定程序的RTP的描述，你可以在一些相关的书中寻找（见12章）：
[1].一个概括地说明文档，定义一系列载荷类型编码和相对应的载荷格式。同时也说明了在某些特定的类型的应用程序中RTP的扩展和修改。以及各一个具有代表性的应用程序的炒作过程。一个为视频和音频数据做的概要说明可以在RFC TBD里找到。
[2].在和类型的描述文档，定义了一个特定的载荷，比如音频和视频编码是如何通过RTP来传输的。
对于实时服务的讨论，对于RTP设计及其运行时所遵循的算法和背景的讨论我们可以在第二节找到。
一些RTP程序，不管是试验性质的还是商业性质的从设计阶段上升到了实践阶段。这些程序包括音频和视频工具以及一些诊断工具比如交通监视器。这些工具的用户数量已有成千上万。但是现在的英特网还无法支持实时服务全部潜在的需求，利用RTP的高速宽带服务，比如视频，将会严重的降低网络其他服务的质量。所以，执行者应该采取合适的防范措施来限制那些次要的宽带利用。应用程序文件会清楚的略述这些限制以及在英特网和其他网络服务中高速宽带的实时服务可能会带来的影响。
2 RTP 使用环境
这个章节我们将讨论RTP的使用方面。我们将会通过实例来说明使用RTP程序的一些基本操作，但不限制使用的是什么样的RTP。在这些举例中，RTP运载于IP和UDP之上，在其之后是一些为了视频和音频而已经确立的协议，这些协议可以在同类书籍中找到。
2.1 简单的多点音频会议
一个工作组要讨论一个最近的工作草案，他们可以通过英特网的多点服务来进行语音交流。通过一些机制分配，工作组组长获得一个多点传送的地址以及两个端口，一个是用来传输语音数据，一个是用来控制包的传输，这个地址同时也被分送到每个成员那里。如果有保密的需要，数据及控制包可以被加密（详见9.1章），当然这样的话解密钥匙也必须要发布出去，关于机制的具体分布与安排不在RTP的讨论范围之内。
参加音频会议的人以包的形式传输语音数据，平均20毫秒一个。每个包有一个RTP报头。RTP 报头及其数据依次放入UDP包中。RTP报头用来说音频编码的类型（比如PCM ,ADPCM, LPC）,这样的方式可以让数据发送者在会议中改变编码方式，这样的话，我们可以单独的为一个低速会议成员安排接入方式，同时我们也可以对网络的拥堵做出反应。
英特网，和其他的封宝试的网络一样，有时候会丢失包或者发生不可预知的时间延迟，为了处理这种情况，RTP报头包含了一个时间信息，和一个序列号码，那样就允许接受者重新排序，在这个例子中，音频包每隔20毫秒发出一个，会议中对于这些RTP包时序的重组一直在独立的进行着。序列号码还可以用来估计有多少包在传输中丢失了。
鉴于工作组成员会在开会时进入或者离开，那么清楚的知道到底谁在参加会议以及到底他们接受的音频数据质量如何是很有用的。于是每一个远程应用程序会定时的往RTCP发送一个接收报告，报告里会附上他们的名字。这个报告会指出现在对于讲话者数据接收如何从而用来控制合适的编码。除了用户的名字之外，我们还会用到其他的鉴别信息来控制款待限制。一个节点会发送一个“BYE”包（见6.5章）当他离开的时候。
2.2音频和视频会议
如果在一个会议中同时要用到视频和音频的话，他们在传输的过程中，用的是互相独立的RTP