实时传输协议（RTP）
RTP在RFC1889中规定，正式名称是“RTP，⼀个⽤于实时应⽤的传输协议”。这个RFC实际上描述了两个协议：实时传输协议（RTP）和实时传输控制协议（RTCP）。这两个协议提供了可以⽀持实时应⽤（例如语⾳和影像）的⽹络传输服务。
UDP⽆法做到避免分组丢失和确保分组有序传输，运⾏在UDP之上的RTP帮助实现了这些功能。例如，RTP分组包括序列号，这样，使⽤RTP的应⽤程序⾄少能够检测到分组丢失的发⽣并确保收到的数据以正确的次序提交给⽤户。RTP分组还包含了⼀个时间戳，这个时间戳对应于分⼦从源媒体流进⾏抽样的时间。⽬的应⽤程序可以利⽤这个时间戳来确保信息同步地传递给⽬的⽤户并计算出时延和抖动。 注意：RTP本⾝并不处理这些事情，它只是提供了⼀些附加的信息给⾼层的应⽤，以便⾼层应⽤能够合理地决定数据分组或是语⾳分组如何能被最好地处理。
正如前⾯提到的，RTP有⼀个伴随协议，RTCP。这个协议为会话⽤户之间提供了⼤量的可供交换的信息和关于会话质量的反馈信息。信息的类型包括这样的⼀些细节问题，诸如丢失的RTP分组的数⽬、时延和到达间隔的抖动。RTP中包含真正的语⾳分组，⽽RTCP则是⽤于质量反馈的传输。 当⼀个RTP会话打开时，⼀个RTCP会话也被隐性地打开。换句话说，当⼀个UDP端⼝号被分配给⼀个R
TP会话⽤来传递媒体分组时，⼀个独⽴的端⼝号被分配给RTCP会话。⼀个RTP端⼝号⼀般是偶数，相应的RTCP端⼝号将是相邻的下⼀个奇数。RTP和RTCP可以使⽤介于1025到65535之间的任何UDP端⼝对；但是在端⼝号没有被显⽰分配的情况下，端⼝5004和5005将分配作为缺省端⼝。
瑞新集团
RTP携带有数字编码的语⾳信息。它通过抽取⼀个或⼏个数字编码的语⾳样本并加上⼀个RTP报头，就得到了RTP分组，RTP分组由⼀个RTP报头和语⾳抽样的净荷构成。这些RTP分组传到UDP层，加上UDP报头。然后再传给IP层，加上IP报头。最后得到的IP数据包就被路由到⽬的地。在⽬的地，不同的报头⽤来将分组沿着协议栈向上传递给相应的应⽤。 考虑到现有的许多不同的语⾳和图像编码标准，RTP必须包含⼀个机制，能够使接收⽅知道使⽤哪⼀种编码标准，这样净荷数据才能够被正确地解释。RTP通过在RTP报头中加⼊⼀个净荷类型标识符来实现这个功能。
这个机制为不同的编码模式分配了⼀个净荷类型号并且描述了它们本⾝的编码技术。表1和表2列出了各种不同的RTP⾳频和视频净荷类型。
表1 RTP⾳频和视频净荷类型（⼀）
绿故事
Payload Type Encoding Name Media Type Clock Rate（Hz）Channels
0PCMU Audio8，0001
11016Audio8，0001
2G726-32Audio8，0001
青春的起点3GSM Audio8，0001
*4G723Audio8，0001
5DV14Audio8，0001
6DV14Audio16，0001
7LPC Audio8，0001
8PCMA Audio8，0001
9G722Audio8，0001
10L16Audio44，1002
11L16Audio44，1001
*12QCELP Audio8，0001
13Reserved
14MPA Audio90，0001
15G728Audio8，0001
15G728Audio8，0001
*16DV14Audio11，0251
*17DV14Audio22，0501
*18G729Audio8，0001
19Reserved
20Unassigned1
21Unassigned1
22Unassigned1
23Unassigned1
*dyn GSM-HR Audio8，0001
*dyn GSM-EFR Audio8，0001
*dyn L8Audio Variable1
*dyn RED Audio Conditional1
*dyn VDVI Audio Variable1
表2 RTP⾳频和视频净荷类型（⼆）
角的度量教学设计
Payload Type Encoding Name Media Type Clock Rate（Hz）24Unassigned Video
25CelB Video90，000
26JPEG Video90，000
机械工程学报投稿27Unassigned Video
28nv Video90，000
29Unassigned Video
30Unassigned Video
31H261Video90，000
32MPV Video90，000
33MP2T Audio/Video90，000
*34H263Video90，000
35-71Unassigned?
72-76Reserved N/A N/A
77-95Unassigned?
96-127Dynamic？90，000
*Dyn BT656Video90，000
*Dyn H263-1998Video90，000
*Dyn MPIS Video90，000
*Dyn MP2P Video90，000
*Dyn BMPEG Video90，000
正如表1和表2看到的那样，⼀些编码模式有具体的净荷类型号。这些模式成为静态净荷类型。其他的净荷类型标记为“Dyn”，代表的是动态，并不为其分配具体的净荷类型号。因为RTP⼀开始制定的时候，还没有⽤于实时应⽤的单独的信号标准。因此，那时发送应⽤程序是不可能使接收⽅应⽤程序提前知道在会话中将使⽤哪种类型的编码的。这样某些具体的净荷类型号就被分配⼀些通⽤的编码模式。
当⼀个RTP分组到达接收⽅时，净荷类型号将明确地指出发送⽅选择的编码模式，这样，接收⽅就知道应该采取什么的⽅式对数据进⾏解码。接收⽅如果⽀持这种编码模式就没什么问题，但是，发送⽅⽆法提前知道接收⽅能够处理什么样的编码模式。
于是某些单独的信号系统出来了，可以使媒体信息流的协商成为呼叫建⽴过程的⼀部分并在实际发送任何语⾳或视频数据之前完成。例如会话初始化协议（SIP）和会话描述协议（SDP）⽀持这样的功能。因此，会话的护嗓防现在可以提前就将要使⽤的编码模式达成⼀致。作为协议的⼀部分，它们还可以决定应⽤在呼叫的编码模式上的净荷类型号。
RTP⾳频/视频⼤纲中将96到127的净荷类型号分配⽤于动态净荷类型。⽽且⼤纲规定中提到的⼀些新的编码模式并没有固定的（静态）净荷类型，它们被认为是动态的。动态净荷类型很有⽤。它们可以使许多新的编码模式被开发出来，⽽不会耗尽可⽤的净荷类型号的空间（最⼤为127）。
注意：编码的名字也是很重要的。当在RTP中使⽤⼀种新的编码模式时，特别是如果编码模式的净荷类型是动态的，那么编码的名字就必须在⼀个独⽴的净荷规定⽂件中规定并在IANA登记。这是因为外部信号系统*（⽐如说SDP）使⽤编码名，可以明确地引⽤⼀个特定的净荷规定。
在动态净荷类型中，有⼀个和其他的不太⼀样。这个类型是冗余净荷类型（RED），在RFC2198中规定。通常⼀个单独的RTP分组包括⼀个或更多的已编码语⾳或视频的抽样，分组中的每个抽样以相同
的⽅式编码。如果分组丢失了，那么接收⽅应⽤必须尽可能妥当地处理数据的丢失，例如及时重放前⼀个分组的内容填补空⽩。冗余净荷类型的概念是指⼀个分组，在像往常⼀样包括⼀个或多个语⾳抽样的基础上，再加上⼀个或更多的先前的已经发往接收⽅的抽样的副本。换句话说，⼀个分组中包含⼀个当前会话的抽样加上⼀个先前会话抽样的备份副本。如果某个分组丢失了，那么丢失分组的会话抽样的备份副本将会在下⼀个分组中到达。注意，备份副本可能使⽤与原来不⼀样的编码模式。如果备份副本使⽤⼀个更窄带宽的编码模式，那么它将提供⼀个冗余来处理分组的丢失，⽽不需要额外的带宽。
2、RTP报头
RTP实际上携带编码语⾳信息。换句话说，⼀个或更多的数字编码抽样构成了RTP的净荷。RTP报头加到这个净荷上，然后分组被传递给UDP。
RTP报头包括的信息对⽬标应⽤程序重组原先的语⾳抽样来说是很必要的（⾄少，使得使⽤的编码模式进⾏精确的匹配成为可能）。
RTP报头如下所⽰
版本【V】这部分报头是2bit的域，应该设为2，表⽰RTP的当前版本号。
填充【P】这部分报头是1bit的域，表⽰分组在净荷的结尾是否有⼀个或者多个填充字节。由于净荷需要和32bit的边界对齐，所以在净荷尾部就需要填充字节和边界对齐。如果存在这样的填充字节，那么设置P⽐特位，并且净荷的最后⼀位指出共有多少个填充字节。
扩展【X】这部分报头是1bit的域，表⽰固定长度的报头是否包含⼀个报头扩展区。如果设置了这个⽐特，那么报头后将跟有⼀个报头扩展区。
CSCR计数【CC】这部分报头是4bit的域，表⽰报头中有⽤源标志符的数量，取值范围为0到15。
标记【M】 这部分报头是1bit的域，表⽰的意义看传输的净荷类型⽽定。对⼀个应⽤程序来说，如果
截肢手术它在静⽌期不发送任何分组，那么在静⽌期后的第⼀个分组中设置这个⽐特（例如，突发对话的第⼀个分组）。不⽀持静⽌抑制的应⽤程序不应该设置这个⽐特位。
净荷类型【PT】这部分报头是7bit的域，表⽰RTP净荷的格式。总的来说，⼀个简单的RTP分组应该包含唯⼀净荷格式编码的媒体信息。
序列号【】这部分报头是16bit的域，由发送⽅在会话开始时设为⼀个随机数，然后每发送⼀个RTP分组就加1.这个标题使接收⽅可以检测到分组的丢失或是分组到达顺序的错误。
时间戳【】这部分报头是32bit的域，记录净荷中的第⼀个抽样产⽣的时间。这个抽样时间必须来⾃按时间单调性增加的时钟，这样远端应⽤程序就能以同步的⽅式打开分组，从⽽进⾏时延抖动的计算。时钟的分解应该适当，这样才能⽀持同步拆包。时钟频率取决于净荷数据的类型。典型的语⾳编码模式的频率是8000Hz。从⼀个分组到另⼀个分组的时间戳的值的增加取决于分组中抽样的数量。时间戳和⼀个分组到下⼀个分组的抽样时点的数⽬有关。例如，如果⼀个分组包括⼗个语⾳抽样和⼀个值为1的时间戳，那么下⼀个分组的时间戳为11。考虑到抽样以8000Hz的速率发⽣（每0.125s），那么时间戳中10的差别就代表了时间上1.25ms的差别。如果在静⽌期，就没有发送任何分组，那么下⼀个RTP分组可能包含⼀个明显⽐前个RTP分组⼤得多的时间戳。两者之差表⽰了第⼀个分组中包含的抽样数量和静⽌期的长度。时间戳的初始值是由发送应⽤程序选择的随机数。
同步源【SSRC】这部分报头是32bit的域，表⽰同步源。同步源是⼀个实体，，负责序列号和时间戳的值，并且通常是RTP分组的发送者。这个标识符由发送⽅随机选取，这样就不会依赖于⽹络地址。这个标题在⼀个RTP会话中是全局唯⼀的。如果⼀个RTP流来⾃混频器，那么SSRC就标志混频器，⽽不是初识的媒体源。
有⽤源【CSRC】这部分报头是32bit的域，包含⼀个会话的发起者的SSRC值。当RTP流来⾃⼀个混频器时，这个域⽤来表⽰混频器后的初识的媒体源。在⼀个RTP报头中可能存在0到15个CSRC条⽬。
RTP扩展报头
RTP报头是⽤来满⾜⼤多数的媒体流的⼀般要求。然后某些净荷的格式可能需要有附加信息。这种信息可以包含在净荷本⾝内，例如，⼤纲中规定，净荷中的前n个字节有特定的意义。同样的，你可以给RTP报头中增加扩展部分。
通过将RTP报头中的X位的值置为1，可以表⽰RTP报头中存在扩展报头。RTP扩展部分存在于CSRC域和真正的数据净荷之间。
3、RTP混频器
混频器是⼀个使来⾃不同源的多个媒体流混合成⼀个RTP流的应⽤程序。⼀个典型的例⼦就是⾳频会
议。例如有四个参与者，每⼀个都以64kbit/s的速率发送和接收⾳频数据。如果某个参与者在每个⽅向上的可⽤带宽都被限制为64kbit/s，那么该参与者将不会有⾜够的带宽来向其他的参与者发送或者从他们那⾥接收RTP信息流。这时，混频器通过将许多单个信息流组合成⼀个以64kbit/s的速率运⾏的信息流来解决这个问题。某个参与者并没有听到其他三个参数者单独说话的声⾳，却接收到所有⼈的组合的⾳频信息。另⼀个例⼦是其中的⼀个参与者通过低速连接到该会议上，⽽其他参与者使⽤⾼速连接。在这种情况下，混频器可能还会应⽤低带宽的编码模式改变低速链路的数据格式。根据RTP报头中的值，某个参与者接收到的RTP分组将包含具体的混频器的SSRC值和对应于其他三个参与者的CRSC值。混频器设置时间戳的值。
翻译器是⽤来管理不⽀持同⼀媒体格式或是⽐特速率的实体之间的通信。例如，参与者A只能⽀持64kbit/s的PCMU语⾳编码（净荷类型0），⽽参与者B只能⽀持32kbit/s的G726-32（净荷类型2），他们之间连接⼀个翻译器。根据RTP报头，参与者A收到的RTP分组会有⼀个SSRC值标志参与者B，⽽不是标志翻译器的值。混频器和翻译器的区别在于混频器将⼏个流集中为⼀个流，也许还要进⾏⼀些净荷格式的翻译，⽽翻译器只进⾏媒体格式的翻译，不集中媒体流。
混频器由于翻译器的地⽅在于如果有多个流的情况下，不需要为每个流分配额外的带宽。不⾜之处在于RTP流的接收⽅不能在连续监听来⾃⼀个源的流的同时减轻来⾃另⼀个源的流的影响。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议