利用实时传输协议和实时传输控制协议传输数据包的方法

摘要

一种传输数据包的方法，特别是在网际协议(IP)网上，利用关于媒体数据包的实时协议(RTP)和关于控制数据包的实时控制协议(RTCP)来传输实时或准实时数据的方法，为各个协议分配可用的传输带宽的份额。根据有关的专用媒体会话的已知链路参数来确定需要的RTCP带宽，利用需要的RTCP带宽传输控制数据包，以及利用剩余的可用带宽传输媒体数据包。

说明书

技术领域

本发明涉及数据包传输，特别是涉及利用标准化协议在网际协议(IP)网上的实时或准实时的数据传输。

背景技术

实时传输协议(RTP)广泛地用于在IP网上传输实时或准实时数据。随着名为实时传输控制协议(RTCP)的相似协议的出现，它广泛用于监视按正向传输方向或从接收端反馈到发送端的方向的数据传输、收集统计数据和发送控制数据。

通常，RTP通过两个规则来限制反馈数量：第一，分配给RTCP的RTP会话带宽一定的份额(推荐5％)。在发送反馈期间，所有的接收端共享该带宽并用该值计算持续时间。第二个规则是，两个反馈传输之间必须有至少五秒的间隔时间(五秒为推荐值)。

虽然这些规则使RTP稳定并可用于大的多信道广播群，但它并不是最适用于单路传输或小信道广播传输。在这些广播群中，每个用户的反馈越多越有利于发送这些反馈。已经发现了一个问题。即在一种新RTP协议的扩展版本中，忽略了在两个反馈传输之间必须有最少五秒间隙的规则。因此，该接收端可以依靠会话参数来发送更多的反馈。不能超过所分配的RTCP会话带宽的规则仍然有效。

如上所述，通常将分配给RTCP的用于控制数据传输的RTP带宽的份额值固定为所推荐的5％。然而，目前将标准化解决方案以使份额改变为其他值。位速设置为零，以断开RTCP反馈。

发明内容

本发明的目的是提供一种利用可以提高传输效率的RTP和RTCP协议来传输数据包的方法。

通过如权利要求1中阐明的方法来实现该目的。从属权利要求中描述了该方法的最佳实施例。

本发明的基础是，即，考虑到特定媒体会话的规定环境给予RTCP带宽更大的弹性。由于控制数据本身不会提高媒体流的质量，因此，就必须优化用于传输媒体数据包的RTP带宽，而不是用有关控制数据传输的固定带宽量。另一方面，媒体数据包的传输需要发送一定量的控制数据。对于分配固定RTP带宽份额的传统解决方案，或者由于两个连续RTCP数据包之间的最小时间间隔超过五秒，因而，使RTCP带宽太小，或者，使带宽超过需要的带宽。

例如，在单路传输媒体会话中，分配给RTCP的5％的RTP会话带宽导致用于控制数据包的传输持续时间仅有数毫秒。根据发送端位速率，延续时间也不会超过几秒钟。因此，浪费了所分配的带宽，并且，特别是用于链路的带宽是珍贵的资源，例如，将大大减小无线电通信链路的传输效率。另一方面，特别是无线电通信链路需要快速反馈，例如，修改编解码器以改变链路条件并发信号给发送端需要媒体数据的中继。

本发明方法的重点是确定实际需要的RTCP带宽，该RTCP带宽是根据单个媒体会话的已知链路参数来确定的。然后，在利用剩余的可用带宽传输媒体数据包时，将所确定的带宽用于传输控制数据包。这样，利用媒体数据包传输的最大效率可以获得优化的带宽配置，并且，可以以充足的方式配置RTCP带宽，以适当的速率提供控制数据。因此各个不同的链路可以按最大效率传输而实现不同的优化带宽配置。

具体实施方式

根据本方法的最佳实施例，确定需要的RTCP带宽的步骤包括计算平均速率和/或控制数据包大小的步骤。大多数情况下，控制数据包的大小是固定的，但它也可能是变量。这些情况下，平均大小有利于计算需要的RTCP带宽。

最好将媒体数据包从发送端传输到接收端而将控制数据包作为反馈在相反方向上发送。

根据另一最佳实施例，用反馈数据包大小和反馈速率的乘积来计算所需要的RTCP带宽(以位/秒计)。

最好将RTCP带宽除以RTP带宽来计算所需要的RTCP带宽份额(fraction)。例如在会话描述协议中，最好在会话建立期间确定或议定该份额。换句话说，如果已经建立了会话，正在进行的会话会被丢弃并建立新的会话。此外，作为一个变量，也可以在正在进行的(ongoing)的传输期间将其发送。

以下将更详细的阐明本发明。

首先，将说明如何根据已知链路和应用参数来确定所需的RTCP带宽。如前所述，RTCP带宽规定到(be specific to)媒体对话及其网络链路环境。以下将阐明一些实例方案，其中每一个方案都要求从接收端反馈到发送端的控制数据。

控制数据最好包括与从接收端报告给发送端的有关事件类型的信息。将被报告得事件的典型实例是累积的数据包丢失或其它由接收端发送的统计数据。该信息可作为输入用在媒体编解码器中，以确定或调整编码算法，并且一般被定期报告，例如每往返一次进行一次报告。对于这类经常事件，已经由使用了反馈的应用程序给出了反馈速率。或许还需要考虑另外的链路特性(例如往返时间)。

例如，不同类的事件是在损失检测之后应该尽快发送到发送端的特有数据包丢失。如果报告了数据包丢失，发送端就可以提高错误恢复能力，例如，通过在视频编码器内发送内部帧刷新或启动媒体数据包的再发送。对于这种事件，它有利于确定平均包速率和平均损失率。

另一类事件是正反两方面确认已接收数据包。也应尽快用信号通知该事件，以便提供发送端的输入，以减小/增加媒体编解码器的错误恢复能力，并调整传输效率，例如，通过减小/增加冗余或改变传输速率。对于这种事件，仅需要知道平均数据包到达率即可。

为了适当计算所需的RTCP带宽，最好能知道反馈数据包的大小。然而对于大多数应用程序而言，数据包大小在会话期间是固定的，它也可能是变量，例如在丢失事件的情况中，在一个反馈数据包中可能报告有超过一个丢失事件。因此，应该使用反馈数据包大小的平均值。

利用反馈数据包的大小，s_fb[位]，和反馈速率，r_fb[1/s]，可以由bw_rtcp＝s_fb*r_fb计算需要的平均RTCP带宽(以位/秒计)。

整个会话时期，RTP会话带宽bw_rtp是固定的。通过以下公式获得RTCP带宽份额：f_rtcp＝bw_rtcp/bw_rtp

在会话建立期间，在接收端和发送端之间确定或者议定所计算的带宽份额，在这种情况下，用部分描述协议(SDP)发送通知带宽份额的信号。如果已经建立了会话，可以丢弃它并建立新的会话。换句话说，可以在正在进行的传输期间命令(signal)计算的RTCP带宽为“空闲”。

新的RTP协议要求以固定间隔安排反馈消息。然而，除非可以以“早期数据包(Early Packets)”的形式出现，即，如果最后发送得反馈数据包是定期排定的反馈数据包，就允许立即发送一个早期数据包。这样的话，下一个所排定的反馈数据包就必须延期到更迟的时间点，以不致于超过所确定的RTCP带宽的平均值。

早期数据包的机制提供良好的配置系统，以便几乎无延迟地发送反馈。一般以确定的反馈速率来发送反馈，在此通过早期数据包(即事件本身)或按规律排定的反馈来确定实际的时间点。以这种方式，使开销保持在最小限度。