正如由因特网工程部(IETF)在“TCP友好速率控制(TCP Friendly Rate Control，TFRC)：协议规范”RFC 3448中所定义的，TCP友好速率控制(TFRC) 是一种拥塞控制机制(congestion control mechanism)，该机制是为操作于因特 网环境中并与TCP通信量竞争的单播(unicast)数据流而设计的。TFRC仅仅定 义一种拥塞控制机制而没有定义完整的协议，这种机制可以在应用层中包含 端到端拥塞控制的应用程序中的传输协议当中使用，或者在端点拥塞控制的 上下文中使用。TFRC并未详述分组格式或可靠性。
当与TCP数据流竞争带宽时，TFRC被设计得相当公平，其中如果数据 流的传输数据速率一般取决于同等条件下TCP数据流的两种TCP传输数据速 率的因素时，这种数据流是“相当公平”的。然而与TCP相比，TFRC拥有 随时间变化量较小的吞吐量，这使得它更适合于需要相对平稳的传输数据速 率的应用程序，诸如电话或流媒体等。
TFRC是一种基于接收端的机制，它计算数据接收端的而不是数据发送 端的拥塞控制信息(即丢失事件率)。这就非常适合于这样的应用程序，其中发 送端是操纵很多并发连接的大型服务器；而接收端具有可用于计算的更多存 储器和CPU周期。另外，基于接收端的机制更适合作为多播(multicast)拥塞 控制的基本组件(building block)。
对于拥塞控制机制，TFRC直接使用所允许的传输数据速率的吞吐量公 式，作为丢失事件率和往返时间的函数。为了与TCP公平竞争，TFRC使用 TCP吞吐量公式，该公式将TCP的传输数据速率大致描述为丢失事件率、往 返时间和分组大小的函数。
丢失事件(loss event)被定义为来自数据窗口的一个或多个丢失分组或标 记分组，这里标记分组指的是显示拥塞通知(ECN)的拥塞指示(参见 Ramakrishnan等人的“The Addition of Explicit Congestion Notification(ECN) to IP”，RFC 3168，IETF)。
一般来讲，TFRC的拥塞控制机制按如下步骤工作：接收端测算丢失事 件率，并将此信息反馈给发送端。接着，发送端也使用这些反馈消息来测算 往返时间(tRTT)。然后将丢失事件率p和tRTT代入到TFRC的吞吐量公式，从 而得出可接受的传输速率。最后，发送端调整传输速率以匹配所计算的速率。
给出TCP吞吐量作为丢失事件率和tRTT的函数的任何实际公式，都适用 于TFRC。然而，所使用的TCP吞吐量公式必须反映出TCP的重传超时行为， 因为它以更高的丢失率来支配TCP吞吐量。吞吐量公式中暗示丢失事件率参 数的这种假定，必须是实际上如何测算丢失率或丢失事件率的合理匹配。虽 然这种匹配对于以下给出的吞吐量公式和丢失率测算机制匹配并不完美，但 实际上这种假定原本是足够充分的。该吞吐量公式为：
$X_{\mathrm{calc}}=\frac{s}{t_{\mathrm{RTT}}·\sqrt{\frac{2·b·p}{3}}+t_{\mathrm{RTO}}·3\sqrt{\frac{3·b·p}{8}·p·(1+32·p^2)}}$
此式中，Xcalc是以字节/秒为单位的传输数据速率，s代表以字节为单位 的分组大小，tRTT是以秒为单位的往返时间，p是介于0至1.0之间的丢失事 件率，即丢失事件的数量与所传送的分组数量之比。获得丢失事件率p的测 算，对TFRC来说是至关重要的。接收端根据到达分组的顺序号来检测丢失 分组或标记分组，从而执行丢失率测算。
b是由单个TCP的确认应答所确认的分组数量。由于多数TCP实现不使 用延迟确认，该数量取值为1，而延迟确认将导致b值为2。tRTO是以秒为单 位的TCP重传超时(RTO)值。设置tRTO＝4·tRTT可以进一步简化该表达式。更 精确地计算出tRTO是有可能的，但是对于现有的TCP实现来说，使用当前设 置的实验已经产生合理的公平。其他可能的情况是设置tRTO＝max(4·tRTT，1秒)， 从而在重传超时上匹配所建议的1秒最小值。
图1示出流应用程序的常规使用情况：媒体服务器位于诸如UMTS网络 等网络中，并且它为请求流服务的例如UMTS客户端(移动终端)提供流服务。 在TFRC速率控制机制中，从媒体服务器发送到目的地终端或客户端的数据 分组包括如下信息：服务器的估计往返时间tRTT，用以识别发送数据分组的顺 序的序号SNi以及表示发送分组的时间的时间戳tsi。
图2示出TFRC的示例性实现中媒体服务器21和目的地终端26的实体。 媒体服务器21包括TFRC与速率控制部件24、RTP实体22和相应的RTCP 实体23，举例说明这二者以便示范通信端点之间的数据流。目的地终端26 包括这些实体的对应方：RTP实体27和RTCP实体28。另外，目的地终端 还包括用来存储接收数据分组的缓冲器29。
反馈分组在目的地终端26的TFRC实体25中形成，包含以下参数：测 量和计算的丢失事件率p、目的地终端的估计接收数据速率Xrecv、服务器中的 处理延迟tdelay以及从媒体服务器接收的最后一个数据分组的时间戳trecvdata。
在媒体服务器21中，在TFRC与速率控制部件24中，将反馈分组中包 含的参数值代入吞吐量公式，并该结果表示媒体服务器21所使用的新的发送 数据速率。为了防止数据速率变得过高，在每次确定新的传输数据速率时， 使用本公式中没有的另一个参数。这个参数就是前面提到的目的地终端的估 计接收数据速率Xrecv。最后，媒体服务器21调整其传输速率，以便匹配在 RTP实体24中计算出的速率。
TFRC以如下方式对通过像RTP这种不可靠的传输协议来提供例如视频 流等流服务的服务器的位速率进行控制，这种方式对于共享同一个连接的其 它TCP来说是公平的，而且不会产生严重降低接收流媒体的质量的突变速率 和延迟变化。
然而，TFRC唯一地定义了这样一种实现，这种实现需要服务器端和客 户端利用非标准的信息和，目前为止，非现存的消息，来执行一些处理任务 并且交换其结果。
在拥有瘦客户机的流情况下，客户机花费额外的资源来实施如TFRC所 建议的速率控制方案是不希望的，所述瘦客户机就是拥有有限的算能力、有 限存储容量和有限电源的客户机。另外，例如，当在具有诸如无线链路等低 位速率有损链路的流环境中实施TFRC时，由TFRC所暗含的信令开销也是 不希望的。

因此，本发明的目的是以对从媒体服务器接收多媒体数据流的目的地终 端透明的方式，来提供媒体流环境中的速率控制。
如独立权利要求所述的本发明实现了上述目的。优选实施例体现了其从 属权利要求的主题。
有利的是，对于利用上述定义的吞吐量公式来计算传输数据速率所使用 的参数的所有必要的处理和确定，都是由媒体服务器来收集或确定的，这就 减轻了客户端的处理负荷，也就是说，使得速率控制对目的地终端变得透明。 因此，目的地终端不再需要计算并且与媒体服务器交换往返时间tRTT和丢失 事件率p等参数，而且，由于在本发明中，媒体服务器采用现有的协议消息 就能够得出计算传输数据速率的必要参数，所有不必对用于数据传送的标准 多媒体流协议和用于控制数据传送的会话控制协议进行扩展。
本发明的一个实施例提供了一种在基于会话流环境中控制多媒体数据流 的传输数据速率的方法，所述流环境包括媒体服务器和目的地终端，其中会 话控制协议用于控制多媒体数据流。该方法在所述媒体服务器中执行，并且 包括以下步骤：根据多媒体流协议，将多媒体数据流从媒体服务器传送到目 的地终端；从目的地终端接收会话控制数据；根据会话控制数据，来计算多 媒体数据流的数据速率值；并且依据所计算的数据速率值，来控制多媒体数 据流的数据速率。
为了能够确定计算数据速率值所必需的参数，会话控制数据可以包括时 间戳和/或用于报告数据分组丢失的分组丢失报告块，它们用来传送多媒体数 据流。
为了计算数据速率值，媒体服务器首先根据接收到的时间戳和分组丢失 报告块，来计算媒体服务器和目的地终端之间的丢失事件率和往返时间。媒 体服务器然后根据丢失事件率和往返时间，来计算数据速率值。
更进一步的优势是，媒体服务器使用用于传送多媒体数据流的数据分组 大小来计算数据速率值。
在向目的地终端传送多媒体数据流之前，媒体服务器初始化会话。为了 初始化会话，媒体服务器向目的地终端传送报告间隔信息，其中从目的地终 端到媒体服务器的会话控制数据传输的时间间隔是根据所述报告间隔信息来 确定的。
在本发明的另一个实施例中，会话控制数据被包括在根据RTP/RTCP规 范从目的地终端发送到媒体服务器的接收端报告中，还被包括在从目的地终 端发送到媒体服务器的用于报告分组丢失率的扩展报告中。报告间隔信息可 以包括报告比率信息，该报告比率信息确定了所述接收端报告的数量与所述 扩展报告的数量之比。
多媒体数据流和会话控制数据可以在数据分组中传送，其中所述数据分 组包括序号，并且进一步包括如下步骤：在存储器中存储传输时间和被传送 到目的地终端的数据分组的序号。
此外，本发明的实施例还允许估计目的地终端中的缓冲器的存满状态 (fill-status)，其中缓冲器用来临时存储已接收的多媒体数据流。这在所估计的 存满状态指示可能的缓冲器欠载运行时，使得媒体服务器增加多媒体数据流 的数据率；以及当所估计的存满状态指示可能的缓冲器溢出时，使得媒体服 务器减少多媒体数据流的数据率。
有利的是，多媒体流协议可以是实时传输协议(RTP)，而会话控制协议可 以是RTP控制协议(RTCP)。使用这些协议，计算数据速率值的会话控制数据， 被包含在接收端报告、丢失报告块、接收端时间戳报告块以及自最后一个接 收端报告块的延迟中的至少一个中。在本发明的该实施例中，会话控制数据 相当于根据RTCP规范传送的RTCP数据消息。
本发明的另一个实施例提供了一种用于在基于会话的流环境中控制多媒 体数据流的传输数据速率的媒体服务器，所述流环境包括媒体服务器和目的 地终端，其中会话控制协议用于控制多媒体数据流。所述媒体服务器包括： 传输装置，用于利用多媒体数据流协议，从媒体服务器向目的地终端传送多 媒体数据流；接收装置，用于从目的地终端接收会话控制数据；计算装置， 用于根据会话控制数据来计算多媒体数据流的数据速率值；控制装置，用于 根据计算的数据速率值来控制多媒体数据流的数据速率。媒体服务器适于执 行前述的速率控制方法。
本发明的另外一个实施例提供了一种与本发明的媒体服务器进行通信的 目的地终端。目的地终端还包括接收装置，用于从媒体服务器接收报告间隔 信息，其中会话控制数据的传输之间的时间间隔和/或会话控制数据的传输比 率是根据报告间隔信息来确定的；和传输装置，用于根据报告间隔来向媒体 服务器传送会话控制数据。
目的地终端还包括临时存储已接收的多媒体数据流的缓冲器。
本发明可以有利地适用于包含至少一个媒体服务器和目的地终端的媒体 流系统中。
附图说明
以下，借助附图详细地描述本发明，附图中示出了本发明的优选实施例。 附图中用相同的标号指定相同或相应的单元，其中：
图1示出流环境的常规使用情况示例。
图2示出常规TFRC在媒体服务器和目的地终端中的说明性实现。
图3示出根据本发明的流环境的使用情况的实施例。

在TFRC规范中，描述了一种默认的实现，该实现需要服务器和客户端 交换信息，以找出由媒体服务器传送的多媒体流的传输数据速率偏差的必要 参数值。本发明揭露了流应用中基于服务器的全TFRC速率控制。
将使用反馈扩展的RTP/RTCP协议来描述本发明的实施例，所述反馈扩 展是在T.Friedman等人于2002年11月提出的IETF因特网草案“RTCP Feedback Extensions”建议的。然而，本发明并不仅仅局限于这些实施例。
在本发明的实施例中，使用多媒体流协议在媒体服务器和目的地终端之 间进行多媒体数据流的传输。总体上讲，多媒体流协议提供了适用于传送实 时数据的应用程序的端到端网络传输功能，所述实时数据比如是音频、视频 或模拟数据。
可以对多媒体流协议增加交换会话控制数据的会话控制协议，以控制媒 体服务器和目的地终端之间的多媒体数据流。会话控制协议允许以可升级到 大型多播网络的方式来监控数据传输，并可提供最小的控制和识别功能。多 媒体流协议和会话控制协议可以被设计成独立于以下的传输层和网络层，并 可支持解释器和混频器的使用。
典型地，在进行多媒体数据流传输之前，例如使用实时流协议(RTSP)来 建立流会话。此协议定义了一系列用于声明、描述、建立、启动、停止和拆 卸流会话的原语。会话描述协议(SDP)可以与RTSP一同使用。SDP定义了用 于描述正在流动的媒体的语言。
会话可以被定义为在单个连接期间发生的两个通信端点之间的一系列交 互。典型地，一个端点请求与另外一个指定的端点连接，且如果另外一个端 点答复同意连接，则这两个端点就依次交换命令和数据。会话在两端建立连 接时开始，而当连接结束时终止。
现在参考附图，图3示出了本发明的流环境的使用情况的实施例。通过 例如图1中所示的UMTS网络等网络，媒体服务器31连接到目的地终端36。 更具体而言，媒体服务器31包括RTP实体32和相应的RTCP实体33，利用 这些实体来示例说明媒体服务器31和目的地终端36之间的数据流。媒体服 务器31还包括速率控制部件34和缓冲器估计部件35。媒体服务器31的速 率控制部件34指示RTP实体32使用计算的传输数据速率来向目的地终端36 传送多媒体数据流。速率控制部件34连接于RTCP实体33和缓冲器估计部 件35，以获得计算传输数据速率必要的信息。目的地终端36包括作为数据 流端点的RTP实体37和相应的RTCP实体38。另外，目的地终端还36还包 括缓冲器39，缓冲器39用于临时存储所接收的RTP分组，从而能使这些分 组在无序接收的情况下被重新排序，并且用于向更高层应用程序或解压缩器 提供相同功能。
媒体服务器31传送例如使用MPEG4、AMR等等编码的RTP封装媒体 分组。存在对于不同类型的媒体格式的有效负载格式定义，例如，RFC 3016 描述了如何以RTP分组来封装MPEG4音频和视频(参见“RTP Payload Format for MPEG-4 Audio/Visual Streams”，Y.Kikuchi等人，IETF，2000年11月)。
在下面，更加详细地描述媒体服务器31的操作。媒体服务器31在例如 列表或哈希表中存储时间戳的值tsi，该值指示媒体服务器31传送分组i的时 间；和分组i的序号SNi。这里的时间戳tsi与RTP分组本身的时间戳是不同 的，并且不可混淆。媒体服务器31的速率控制部件34利用存储的这些信息， 来决定分组丢失率p，并估计RTP数据分组的往返时间tRTT。
与TFRC的协议定义相反，根据本发明的一个实施例，p的计算是在媒 体服务器31中完成的，而并非在接收端(目的地终端36)完成的，认识这一点 是很重要的。因此，媒体服务器31可以保存丢失历史，并且将这些丢失映射 至丢失事件。这可以通过如下操作来完成：将目的地终端36报告的丢失映射 到恰当的时间间隔，利用所存储的每个分组i的传输时间tsi和分组序号SNi， 来计算TFRC中定义的丢失事件率p。这是计算丢失事件率p的较好方法， 值得一提的是还存在确定丢失事件率p的其它方法。
目的地终端36可以使用RTCP实体38来报告分组丢失。如Friedman等 人定义的对RTCP反馈的扩展，允许定义传输过程中丢失的RTP分组。例如， RLE丢失报告块允许关于单个分组接收和丢失事件的详细报告。由于丢失和 接收的RTP分组的布尔轨迹可能是冗长的，这种块类型就允许通过游程长度 编码来压缩这种轨迹。
每个块都报告单一的源，所述源是由其同步源标识符(SSRC)标识的。提 供报告的目的地终端36在RTCP分组的头部中标识。在块中指定轨迹的开始 和结尾RTP分组序号，结尾序号是轨迹序列中的最后一个序号加1。
因此，媒体服务器31能够确定在传输过程中丢失的分组的序号。通过利 用所存储的信息，媒体服务器31就能够确定如TFRC规范中使用的丢失间隔 li，这些信息使用所存储的时间戳tsi，将序号SNi映射到时间即传输时间中的 特定点。在确定了丢间间隔li后，媒体服务器31的速率控制部件34就能根 据Handley等人在RFC 3448中给出的定义和公式来计算出丢失事件率p。
另外，RTCP发送端报告(SR)和由目的地终端36的RTCP实体38传送的 接收端报告(RR)，可以用于估计用于计算所计算出的传输数据速率Xcalc的往 返时间tRTT。最后接收的两个报告间的差异可以用来估计最近的多媒体数据流 的分布质量。接收端报告和发送端报告中包含了NTP时间戳，这样就能够通 过这两个报告之间的间隔之差来计算出数据速率。而且，发送端报告和接收 端报告中的时间戳可以用来确定媒体服务器31和目的地终端36之间的往返 时间tRTT。
当结合所谓的自最后一个接收端报告块的延迟(Delay since Last Receiver Report，DLRR)报告块来使用接收端时间戳报告块时，利用Friedman等人提出 的反馈扩展，这些接收端时间戳报告块允许在目的地终端36的RTCP实体38 中提供往返时间tRTT的精确计算。这些块扩展了RTCP的时间戳报告，以便非 发送端(non-sender)也能够发送时间戳。它扼要描述了来自RTCP发送端报告 的NTP时间戳字段。需要注意的是，目的地终端36不总是需要估计出往返 时间，这是由于报告间隔能够被给出作为一个绝对的值，而不是作为从媒体 服务器31到目的地终端36的tRTT的函数。
由于媒体服务器能够知道RTP数据分组的平均分组大小s，因而媒体服 务器31就能够得到必要的参数，从而在速率控制部件34中使用上述吞吐量 公式来计算合适的传输数据速率Xcalc。因此，本发明实施例中，确定传输数 据速率Xcalc的整个处理过程都是可以在媒体服务器31中完成。因此，本发明 的实施例允许以一种对目的地终端透明的方式，来在媒体服务器31中控制多 媒体流的传输数据速率。
目的地终端36要对从媒体服务器31接收的RTP分组解封装，并将其转 发至缓冲器39，当RTP分组被无序地接收时，缓冲器39根据其序号SNi对 RTP分组重新排序，且临时存储这些RTP分组的信息，直到媒体数据被转发 到更高层中的显示应用程序或解压缩器。另外，目的地终端36的RTP实体 37通过已接收的RTP分组的序号SNi之间的间隔来检测丢失的RTP分组。
RTCP实体38可用来报告丢失分组或确认分组。媒体服务器可以利用标 准的RTCP消息(接收端报告和发送端报告)来计算如RTP中定义的tRTT(参见 Schulzrinne等人，“RTP：A Transport Protocol for Real-Time Applications”，IETF， RFC 1889，1996年1月)。报告接收分组和丢失分组的优选方法是使用如 Friedman等人定义的扩展报告(尤其是RLE丢失报告块)。然而，应注意，本 发明并不局限于这种报告方法，并且存在报告接收或丢失分组的可替换方法。
目的地终端36和媒体服务器31不必遵守如RTP/RTCP标准中规定的 RTCP分组的5秒最小值的规定。只要没有超出所分配的RTCP带宽，就能在 任何时间发送RTCP分组。
而且，目的地终端36可以被通知报告间隔，即媒体服务器31期望目的 地终端36提供反馈的间隔。因此，在以下将讨论的会话建立期间，可以传送 报告间隔。所通知的信息可以被表示为媒体服务器和目的地终端之间的tRTT 的函数或者是一个绝对值。
为了提供由TFRC定义所提出的速率控制的基于服务器实现，媒体服务 器31还计算接收速率Xrecv，该速率就是由目的地终端36接收携带多媒体数 据流的RTP分组的数据速率，并且该速率通过TFRC规范中同样的方法来计 算。在媒体服务器31中，可以通过在传送RTP分组的时间间隔期间、对所 报告的接收RTP分组进行计数，来完成Xrecv的计算。此外，也可以利用所存 储的时间戳tsi和由媒体服务器31记录的相关序号SNi，以与TFRC规范基本 类似的方式，来估计接收端数据速率Xrecv。
如前面部分所述，根据本发明实施例的媒体服务器31能够根据媒体服务 器31和目的地终端36之间的RTP/RTCP通信流来收集所有必要的信息，以 便在速率控制部件34中依照TFRC方案的原理来计算出合适的传输数据速 率。在速率控制部件34中确定了合适的多媒体数据流的传输数据速率之后， 所述速率控制部件34就指示RTP实体32根据所计算出的数据速率值来调整 传输数据速率。值得一提的是，根据本发明的实施例，无需目的地终端36中 的“TFRC对应部分”(比较图2中的TFRC实体25)来提供传输数据速率控制。
RTP实体32可以向应用层，即提供多媒体数据流的应用程序，报告传输 数据速率的变化。提供多媒体数据流的应用程序通过改变音频流和/或视频流 的位率来减小或增大传输数据速率，以便适应于新计算出的传输数据速率值。
在另一个实施例中，媒体服务器31也可以包括缓冲器估计部件35。缓 冲器估计部件35用来估计目的地终端的播放(playout)缓冲器39的存满状态。 知道目的地终端36的播放缓冲器39的状态，对于媒体服务器31的缓冲器估 计部件35是很重要的，以便媒体服务器31处的传输数据速率可以被增加从 而避免缓冲器欠载运行，或者被减小从而避免缓冲器溢出。每次RTP实体32 传输RTP分组时，该分组数据都是以其全部长度被插入缓冲器39中的。理 想情况下，每一个RTP分组在大约等于tRTT/2的时间后到达目的地终端36。
另外，需要一些时间来抵消目的地终端36处的网络抖动影响以及重新排 序和编码的延迟。这种额外的时间即指下面所述的tjit_dec。在时间tdel＝tRTT/2+ tjit_dec之后，缓冲器估计部件35就假定分组已经在目的地终端36中被处理， 并已经从缓冲器39中删除。
RTCP发送端报告中的两次到达时间间隔抖动字段(interarrival jitter field)，能够提供网络拥塞的第二种短期测量(measure)。分组丢失测量跟踪持 久拥塞，而抖动测量跟踪暂时拥塞。抖动测量可以指示导致分组丢失之前的 拥塞。由于RTCP接收端报告中的两次到达时间间隔抖动字段仅仅是报告时 抖动的瞬时反映，因而就有必要分析在一段时间期间来自一个接收端的多个 报告或者来自单一网络中的多个接收端的多个报告。
应该注意，假定没有发出丢失分组的重传，就不需要目的地终端36的大 容量播放缓冲器39。当使用重传时，tdel必须被增加trtx＝(重传数量)·tRTT，即 每个分组的最大期望重传数量乘估计往返时间。
如上所述，RTP分组大约在时间tjit_dec内被处理。目的地终端36的缓冲 器39可以进一步用来抵消网络抖动和编码器处理延迟。当使用重传时，缓冲 器39的大小相当于trecv buffer＝tjit_dec+(重传数量)·tRTT，其中tRTT是由目的地终端 36测量出的往返时间，而不是如上所述由媒体服务器31测量出的往返时间。 这种差别被认为是微小的，因此可以被忽略。
本发明的另一个实施例中，在传送多媒体数据流之前，使用实时流协议 (RTSP)来一般地建立流会话。这个协议定义了一系列用于声明、描述、建立、 启动、停止和拆卸流会话的原语。可以与RTSP一起使用会话描述协议(SDP)。 SDP定义了一种用于描述正被流动的媒体的语言。
为了使该算法正确运行，可以在会话建立时交换一些信息。目的地终端 36不必要知道反馈消息(接收端报告和丢失报告)多久被传送到媒体服务器 31一传送报告间隔以便初始化会话。在本发明的实施例中，假定发送标准 RTCP分组(用于计算tRTT的发送端报告和接收端报告)和扩展报告分组(丢失报 告的XR)。这样，就可以在标准RTCP分组和扩展报告分组(如传送的报告间 隔所给出的)之间平等地共享报告带宽。
在本发明的另外一个实施例中，例如还可以通过更少地传送接收端报告 (或发送端报告)或者用于丢失报告的扩展报告分组，来定义一种不同的带宽共 享规则。例如，可以在传送3个丢失报告之后，发送一个接收端报告。可以 使用SDP中的其他属性来实现规定带宽共享的方法，例如，以与下列描述相 类似的方式。本实施例允许规定正被发送的标准RTCP分组与扩展报告分组 的总数量之比，来定义上述报告间隔。
根据SDP协议，利用报告间隔信息，可以将报告间隔从媒体服务器31 传送到目的地终端36。以下示出了会话建立的示例。该示例中，‘DT’代表 目的地终端36，并且‘MS’代表媒体服务器31。
DT-＞MS：DESCRIBE rtsp：//foo/twister RTSP/1.0
     CSeq：1
MS-＞DT：RTSP/1.0 200 OK
     CSeq：1
     Content-Type：application/sdp
     Content-Length：164
     v＝0
     o＝-2890844256 2890842807 IN IP4 172.16.2.93
          s＝RTSP Session
          i＝An Example of RTSP Session Usage
          a＝control：rtsp：//foo/twister
          t＝0 0
          m＝audio 0 RTP/AVP 0
          a＝control：rtsp：//foo/twister/audio
--------→a＝X-reporting-interval：0 3
-------→  a＝X-repoting-ratio：0 RR＝1；XR＝1
          m＝video 0 RTP/AVP 26
          a＝control：rtsp：//foo/twister/video
--------→ a＝X-reporting-interval：26 3
-------→ a＝X-reporting-ratio：26 RR＝1；XR＝1
    DT-＞MS：SETUP rtsp：//foo/twister/audio RTSP/1.0
          CSeq：2
          Transport：RTP/AVP；unicast；client_port＝8000-8001
    MS-＞DT：RTSP/1.0 200 OK
          CSeq：2
          Transport：RTP/AVP；unicast；client_port＝8000-8001；
               server_port＝9000-9001
    Session：12345678
    DT-＞MS：SETUP rtsp：//foo/twister/video RTSP/1.0
          CSeq：3
          Transport：RTP/AVP；unicast；client_port＝8002-8003
          Session：12345678
    MS-＞DT：RTSP/1.0 200 OK
          CSeq：3
          Transport：RTP/AVP；unicast；client_port＝8002-8003；
               server_port＝9004-9005
    Session：12345678
    DT-＞MS：PLAY rtsp：//foo/twister RTSP/1.0
          CSeq：4
            Range：npt＝0-
            Session：12345678
      MS--→DT：....
可以看出，有标记的线条指示所需要的用于初始化报告间隔的报告间隔 信息。
行m＝audio 0 RTP/AVP 0
将数字零(0)映射到音频的有效负载类型(编码)，并且
行m＝video 0 RTP/AVP 26
将数字二十六零(26)映射到视频有效负载类型。以下行：
a＝X-reporting-interval：0 3和
a＝X-reporting-interval：26 3
中的数字三(3)表示音频和视频的报告间隔都是往返时间值的三倍。
包含X-reporting-ratio属性的行指示接收端报告和扩展报告之间的比率作 为报告比率信息。在这种情况下，二者平等地共享RTCP带宽。
a＝X-reporting-ratio：0 RR＝1；XR＝1
然而，在以下示例中：
a＝X-reporting-ratio：0 RR＝1；XR＝2
将以两倍于接收端报告(RR)的频繁程度来发送扩展报告(XR)。
需要注意的是，可以存在传送报告间隔的不同方法。一种方法还可以使 用RTCP带宽修改量。
RTP规范简要规定了RTCP带宽可以被划分为对于那些活动数据发送端 的共享者以及那些不是活动数据发送端的共享者的两个单独的会话参数。使 用两个参数，可以通过将非数据发送者的RTCP带宽设置为零，而使数据发 送者的带宽不为零，从而将对于特定会话的RTCP接收报告完全关闭，以便 仍然能够关于媒体间同步来发送发送端报告。这适合于在单向链路上操作的 系统，或者是不需要反馈接收质量的会话。
会话描述协议(SDP)包含具有以下语义的可选带宽属性：
b＝:
其中是给出带宽数字含义的字母数字型单词，以及 的默认单位是千比特每秒。这个属性定义了会话或媒体要 使用的建议带宽。
典型的应用是修改量为“AS”(表示应用程序定义最大值)，该修改量可 以用于规定来自媒体服务器31的单一媒体流的总带宽。还可以使用另外两个 带宽修改量，来控制目的地终端36的报告间隔：
b＝RS:
b＝RR:
这里“RS”指的是分配给活动数据发送端(如RTP规范所定义的)的RTCP 带宽，而“RR”指的是分配给RTP会话中其他共享者(即目的地终端)的RTCP 带宽。带宽分配适用于所有RTCP分组类型所消耗的总带宽，包括发送端报 告、接收端报告、SDES、BYE、APP和扩展报告(XR)以及将来定义的任何新 类型。这些修改量的以比特每秒为单位，具有整数值。
本发明另一个实施例中，这些代表报告间隔信息的带宽修改量，可以用 来限制分配给目的地终端36的RTCP通信量的RTCP带宽。这就暗示着接收 端报告和其他信息只能够以由该新值给定的频率进行发送。RTP固有的算法 能够利用该给定的RTCP带宽，并且能够自动计算报告间隔。因此，实施者 能够相应地分配RTCP带宽值，以便集中于所期望的报告间隔。