用于交叉参考相关应用来报告流媒体质量的方法和设备

摘要

流媒体客户端针对与应用于流媒体会话的相同级别的所有接受的质量度量相关联的每个报告参数协商单个值。这样一来，以相同的速率以及可选地相同的范围来报告应用于流媒体会话的相同级别的每个质量度量，从而减少了客户端所生成的QoE/QoS报告的数量。根据一个实施例，通过针对与应用于流媒体会话的相同级别的多个质量度量相关联的报告参数协商单个值，来指示在客户端与服务器之间建立的流媒体会话的质量。所述级别可以是会话级别或媒体级别。根据所协商的报告参数值来报告在协商期间被客户端和服务器接受的质量度量。

说明书

技术领域

本发明总体上涉及流媒体内容，特别地涉及报告流媒体内容的质量。

背景技术

流媒体是在正被内容服务器递送的同时由客户端连续接收并正常地显示给客户端的多媒体内容。“流(streaming)”指应用的在流正在通过网络而被传送至客户端的同时以连续方式播放诸如音频和视频流等之类的同步媒体流的能力。流媒体可用在诸如因特网之类的固定IP网络上，并且近来借助于3GPP的分组交换流服务(PSS)协议TS 26.234可用在无线电接入网上。

因特网工程任务组(IETF)维护着实时流协议(RTSP)标准RFC2326、实时传输协议(RTP)标准RFC 1889和实时传输控制协议(RTCP)标准RFC 4585。这些标准实现了流媒体服务。RTSP允许客户端例如通过发出诸如“播放”和“暂停”等类VCR命令对流媒体服务器进行远程控制。当客户端发出包括标识流媒体服务器的统一资源标识符(URI)(rtsp://...)的RTSP‘DESCRIBE(描述)’命令时，发起流媒体会话。DESCRIBE请求还标识了能够由客户端处理的应答数据的类型。流媒体服务器所发送的响应包括通常为采用会话描述协议(SDP)格式的表示描述。

目前，举例而言，在无线接入协议(WAP)应用中，SDP信息可以借助RTSP DESCRIBE请求或通过借助HTTP获取SDP文件来获得。当借助HTTP获得时，客户端已经以所下载的SDP文件启动。总之，SDP表示描述都声明了将被用于针对每个媒体组件使用编解码器特定的MIME媒体类型的会话中的媒体类型。每个媒体类型与标识相应媒体内容位置的URI相关联。

客户端响应于DESCRIBE请求而向内容服务器发送RTSP‘SETUP(建立)’请求。SETUP请求指定将如何传输每个媒体流。该请求包含媒体流URI和传输说明符(specifier)。传输说明符通常包括用于接收RTP数据(例如，音频、视频或文本)的本地端口和用于接收RTCP数据(元信息)的另一端口。服务器应答确认所选择的参数，并填入缺少的部分，如服务器的选定端口。在播放请求可以被从客户端发送至服务器前，使用RTSP SETUP消息来配置每个媒体流。

在配置了每个媒体流后，客户端向服务器发送‘PLAY(播放)’请求，‘PLAY’请求使一个或多个媒体流得以播放。PLAY请求中指定的URI可以是聚合URI(用于播放所有媒体流)、或单个媒体流URI(用于仅播放该流)。可以通过客户端发出‘PAUSE(暂停)’请求，使一个或多个媒体流暂停。客户端向客户端发送‘TEARDOWN(断开)’请求，以终止流媒体会话。TEARDOWN请求停止所有媒体流，并释放服务器上的所有会话相关数据。

传统上，流媒体服务器请求客户端发送服务质量(QoS)或体验质量(QoE)报告，用于指示客户端接收到的流媒体内容的质量。QoS/QoE质量报告指示特定流媒体会话的质量，并且包括针对正被报告的度量的在传输层、应用层或这两层上由客户端所测量的数据。虽然服务器请求客户端生成质量报告，但却是客户端确定在何时向服务器报告哪些质量度量。目前，定义了六种QoS/QoE度量，但提出了其他QoS/QoE度量。两种质量度量可应用于会话级别-初始缓冲持续时间和再缓冲(rebuffering)持续时间度量。RTP分组连续丢失、破坏(corruption)持续时间、帧速率偏差(deviation)以及抖动持续时间度量被应用于媒体级别，如音频、视频、语音或时控文本级别。3GPP TSG-SA工作组正在考虑的一种新的度量报告从用户切换内容的启动到接收到来自新内容或媒体流的第一媒体分组的时刻所经历的时间(3GPP 26.234变更请求0112)。

客户端还为客户端所支持的每个质量度量指定一个或多个报告参数。最低限度地，为每个所支持的度量约定报告速率(reporting rate)参数。报告速率参数表示就相应度量而言在两个连续QoS/QoE报告之间的以秒为单位的最大时间周期。可选地，还可以指定报告范围参数。报告范围参数定义了针对其报告质量度量的媒体流中的时间范围，例如媒体播放时间的前40秒。3GPP TSG-SA工作组正在考虑与上下文切换有关的新报告参数(3GPP 26.234变更请求0112)。这种正在考虑的新的上下文切换报告参数测量内容切换的持续时间。客户端和服务器协商客户端所要报告的质量度量和报告参数。例如，服务器可以建议度量的初始集合，作为响应于RTSP DESCRIBE请求被提供给客户端的SDP描述的一部分。在另一示例中，服务器首先在稍后阶段提出建议，例如作为SETUP响应的一部分。

然而，客户端最终确定根据什么参数来报告哪些度量。客户端通过例如在RTSP SETUP或PLAY请求中包含度量建议或SET_PARAMETER或者OPTIONS(选项)方法，自由地与服务器协商度量和报告参数。度量协商过程一直持续直到客户端从内容服务器接收到PLAY响应为止。可替换地，可以将协商限制于多次往返(roundtrip)。总之，在度量协商过程停止后，客户端报告客户端和服务器这二者所接受的度量和参数。当度量和参数被服务器确认接受，即服务器例如作为RTSP SETUP或PLAY响应的一部分回传(echo)客户端的建议时，认为客户端和服务器这二者都接受所述度量和参数。一旦服务器确认接受了度量，客户端就不再将相同的度量包含在发往服务器的后续请求中。例如，客户端可以针对应用于视频媒体流的破坏持续时间建议10秒的报告速率，并针对帧速率偏差建议20秒的报告速率。服务器可以确认针对破坏持续时间的10秒的报告速率，但针对帧速率偏差反建议(counter-propose)15秒的报告速率。由于服务器已经确认接受了破坏持续时间度量，所以客户端不在涉及视频媒体流的后续协商中包含破坏持续时间度量。然而，客户端可以针对帧速率偏差建议不同的报告速率或接受由服务器所建议的速率。由于帧速率偏差度量尚未达成一致，所以客户端以相同的建议(例如，速率＝15)或新建议(例如，速率＝10)向服务器发送新请求，或拒绝度量。接着，服务器在响应中对建议进行确认。只有在被内容服务器确认接受时，度量和报告参数才达成一致。

客户端性能随客户端所协商的质量度量数量的增加而下降。在最坏的情形下，客户端可能针对流媒体会话的会话级别而试图协商两个不同的质量度量，以及针对会话的多达四种不同媒体级别协商四个不同的质量度量。如果客户端试图针对每个建议的质量度量协商不同的报告参数，客户端性能会进一步下降。这样的大量的度量协商将使客户端性能下降，对于诸如移动电话等之类的资源受限的设备这尤为值得关心。此外，协商大量质量度量和不同报告参数值所消耗的带宽可能很高。

当客户端接下来根据不同的报告速率/范围报告约定一致的质量度量时，大量的带宽消耗甚至更值得关注。例如，为了生成QoE/QoS报告需要大约200字节，相应的服务器响应消息还需要另外的80字节。如果例如由于每个所支持的质量度量具有不同的报告速率和/或范围，所以需要独立报告每个所支持的质量度量，那么会消耗大量的带宽。一条70kbps链路的5％以上的上行链路可能被消耗用于以不同的报告间隔报告单独的质量度量。QoE/QoS报告所需的高带宽减少了可用于传送实际数据的带宽，这是一个重大的问题，对于诸如移动电话等之类的带宽受限设备而言尤其如此。此外，由于以完全不同的报告速率和范围报告质量度量，所以当选择多个报告参数值时，报告阶段的实现更为复杂。

发明内容

根据此处教导的方法和设备，流媒体客户端针对与应用于流媒体会话的相同级别甚至多个级别的所有质量度量相关联的每个报告参数协商单个值。例如，客户端可以针对应用于流媒体会话的会话级别的所有接受的质量度量协商单个报告速率。客户端还可以针对应用于流媒体会话的每个媒体级别的所有接受的质量度量协商单个报告速率。这样一来，以相同的速率以及可选地相同的范围报告应用于流媒体会话的相同级别或多个级别的每个质量度量，从而减少了客户端所生成的QoE/QoS报告的数量。

相应地，减少了带宽消耗并提高了客户端性能。此外，由于处理更少的参数，因此当选择单个报告参数值时，报告阶段的实现变得更加简单。当连续执行报告时，虽然协商阶段变得更加复杂，但每次会话只执行一次协商。此外，当移动电话平台正在对媒体执行译码和呈现时进行报告，这很可能对性能进行了优化。当然，随着标准的不断发展，客户端可以针对其他类型的报告参数(如与内容切换或PSS的其他方面相关联的参数)协商单个值。

根据一个实施例，通过针对与应用于流媒体会话的相同级别的多个质量度量相关联的报告参数协商单个值，来指示在客户端与服务器之间建立的流媒体会话的质量。所述级别可以是会话级别或媒体级别。根据所协商的报告参数值来报告在协商期间被客户端和服务器接受的质量度量。

当然，本发明不限于上述特征和优势。所属领域技术人员在阅读了以下详细说明和阅览了附图时将认识到其他特征和优势。

附图说明

图1是包括流媒体内容服务器和流媒体客户端的网络的实施例的框图。

图2示出了针对与应用于流媒体会话的相同级别的多个质量度量相关联的报告参数协商单个值的处理逻辑的实施例。

图3示出了在流媒体内容服务器与客户端之间交换的RTSP请求和响应序列的实施例。

图4示出了流媒体内容服务器所发送的RTSP SETUP响应的实施例。

图5示出了用于针对应用于流媒体会话的相同级别的多个质量度量协商单个报告速率的、由流媒体客户端发送的RTSP请求的实施例。

图6示出了流媒体客户端所发送的QoS/QoE报告的实施例。

图7示出了针对与应用于流媒体会话的相同级别的多个质量度量相关联的报告参数协商单个值的处理逻辑的另一实施例。

具体实施方式

图1示出包括流媒体内容服务器102和多个流媒体客户端104、106、108的网络环境100的实施例。内容服务器102根据请求向客户端104、106、108提供诸如视频、音频、语音、时控文本等之类的流媒体。某些客户端可以是通过诸如因特网等之类的IP网络110耦合至媒体服务器102的“固定”或宽带客户端104。其他客户端是通过无线电接入网112、114或可选地通过IP网络110耦合到服务器102的移动电话106、108。每个客户端104、106、108具有用于执行客户端相关任务的处理器116，客户端相关任务包括但不限于诸如管理流媒体协议栈等之类的协议栈管理。客户端处理器116尤其支持基于RTSP、RTP和RTCP的消息的生成和处理。例如，包含在移动电话客户端106、108中的处理器116可以实现用于通过无线电接入网112、114与内容服务器102建立流媒体会话的PSS协议。客户端104、106、108还具有用于对接收自服务器102的流媒体内容进行缓冲的存储器118以及一个或多个用于对流媒体内容进行解码的编解码器120。

流媒体会话建立在客户端104、106、108与内容服务器102之间，用于将媒体内容从服务器102流送到客户端104、106、108。建立流媒体会话的一部分包括协商将由客户端104、106、108报告的关于会话的QoS/QoE度量。例如，客户端104、106、108可以同意针对流媒体会话的会话级别报告初始缓冲持续时间和/或再缓冲持续时间质量度量。客户端104、106、108还可以同意针对与流媒体会话相关联的每个媒体级别(如音频、视频、语音和/或时控文本级别)报告RTP分组的连续丢失、破坏持续时间、帧速率偏差和/或抖动持续时间度量。内容服务器102或其他实体(未示出)对接收到的QoE/QoS报告进行处理，以确定客户端104、106、108所测量的流媒体会话的质量。

在质量度量协商过程期间，客户端104、106、108确定其能够支持哪些质量度量。客户端104、106、108所支持的每个质量度量具有一个报告参数(例如速率)或多个报告参数(例如，速率和范围)。报告参数确定了客户端104、106、108生成QoS/QoE报告的频率以及可选地针对其报告质量度量的特定媒体流内的时间范围。例如，如图2的步骤200所示，客户端104、106、108针对应用于流媒体会话的相同级别的所有质量度量相关联的每个报告参数协商单个值。例如，客户端104、106、108可以针对应用于流媒体会话的视频级别的所有所支持的质量度量协商单个报告速率以及可选地单个报告范围。这样一来，如图2的步骤202所示，以相同的速率以及可选地相同的范围报告应用于流媒体会话的相同级别的每个质量度量，从而减少了由客户端104、106、108所生成的QoE/QoS报告的数量。相应地，降低了带宽消耗并改进了客户端性能。当然，随着标准的不断发展，客户端可以针对速率和范围以外的其他类型的报告参数(如与内容切换或PSS的其他方面相关联的参数)协商单个值。

图3示出了用于建立和维持流媒体会话、在流媒体客户端300与内容服务器302之间交换的示例性RTSP请求和相应响应消息的序列。在一个实施例中，例如在WAP应用中，根据由客户端300通过HTTP下载的SDP文件来发起流媒体会话。这样一来，客户端300已经具有了通过HTTP获得的本地存储的SDP文件。在另一实施例中，当客户端300传送标识期望流媒体内容的URI(如图3中的rtsp://server.com/content/baz.3gp)的RTSP DESCRIBE请求时，发起流媒体会话。对于移动客户端，DESCRIBE请求通过诸如GSM/EDGE无线电接入网(GERAN)112或UMTS陆地无线电接入网(UTRAN)等之类的无线电接入网传播至核心无线电网络122。通过核心无线电网络122例如通过服务GPRS支持节点(SGSN)124和网关GPRS支持节点(GGSN)126对DESCRIBE请求进行处理，所述GPRS支持节点(SGSN)124控制RAN 112、114与移动客户端106、108之间的连接，所述网关GPRS支持节点(GGSN)126提供RAN 112、114与IP网络110之间的网关。在DESCRIBE请求进入IP网络110后，其被路由至请求中所标识的内容服务器302。

内容服务器302响应于DESCRIBE请求而向客户端300发送包括例如SDP格式的表示描述的RTSP DESCRIBE响应。表示描述声明了将被用于针对每个媒体流使用编解码器特定的MIME媒体类型的会话中的媒体类型。表示描述的一部分可以包括所建议的质量度量和相应报告参数的初始集合。可替换地，稍后内容服务器302例如作为RTSP SETUP响应的一部分建议初始质量度量。总之，如现有技术中所公知的，在客户端300与服务器302之间交换一个或多个RTSPSETUP请求和相应响应消息的序列，或者客户端通过HTTP下载SDP文件，以最终定下(finalize)与流媒体会话和媒体内容有关的细节。

当客户端300从内容服务器302接收到建议的质量度量集合时，客户端300确定客户端300支持哪些度量以及不支持哪些度量。客户端300还确定多个质量度量是否是针对流媒体会话的相同级别而被建议的。也就是说，客户端300确定多个质量度量是否是针对流媒体会话的会话级别和媒体级别(视频、音频、语音和/或时控文本)而被建议的。对流媒体会话应用会话级质量度量，对流媒体会话的所指示的媒体组件应用媒体级质量度量。如果多个质量度量是针对相同级别而被建议的，客户端300就针对与所建议的质量度量相关联的每个报告参数建议单个值。这样一来，流媒体会话的会话级别就客户端300和内容服务器302所接受的针对会话级别的全部质量度量而言将具有单个报告速率和单个可选报告范围。同样地，还针对应用于媒体级别的所有接受的质量度量，为每个媒体级别分配单个报告速率和单个可选报告范围。

图4示出了客户端300从内容服务器302接收到的RTSP SETUP响应的实施例，所述RTSP SETUP响应包括所建议的质量度量集合。包含在SETUP响应消息中的质量度量协商首部(3GPP-QoE-Metrics)指示所建议的质量度量。在本示例中，对流媒体会话(rtsp://server.com/content/baz.3gp)的会话级别(rtsp://server.com/content/baz.3gp)应用一个质量度量(Initial_Buffering_Duration)和报告参数(速率)。还对流媒体会话的音频级别(rtsp://server.com/content/baz.3gp/audiotrack)应用一个质量度量(Corruption_Duration)和报告参数(速率)。然而，对流媒体会话的视频级别(rtsp://server.com/content/baz.3gp/videotrack)应用两个质量度量(Corruption_Duration和Framerate_Deviation)和两个报告参数(速率和范围)。

相应地，客户端300确定其是否能够支持针对所标识的级别而建议的度量和参数。如果客户端300支持所有建议的质量度量，则客户端300就针对与应用于视频级别的破坏持续时间和帧速率偏差质量度量相关联的报告速率和范围协商单个值。在本例中，这两个度量都具有相同的报告范围(0-40 npt)。优选地，如果客户端300能够支持指定的范围值，则客户端300就接受针对于两个视频级质量度量所建议的报告范围值。然而，可替换地，客户端300可以针对视频级质量度量建议不同的报告范围值。

总之，由于度量具有不同的建议速率(对于Corruption_Duration为10秒，并且对于Framerate_Deviation为20秒)，所以客户端300针对视频级质量度量建议单个报告速率值。否则，如果客户端300接受内容服务器302针对视频级别所建议的不同参数值，则客户端300生成QoS/QoE报告的频率将是针对于破坏持续时间质量度量的两倍，从而消耗额外的带宽并降低客户端性能。在一个实施例中，客户端300选择SETUP响应中所标识的第一报告速率(10秒)。在另一实施例中，客户端300选择对带宽消耗具有最小影响的报告速率(图4中的20秒)。在又一实施例中，客户端300选择与内容服务器302所建议的报告速率无关的单个报告速率。在另一实施例中，客户端300使用先前在协商阶段标识的报告速率，如包含于所下载的SDP文件中的报告速率、或已经由服务器302针对相同级别的其他度量确认接受的报告速率。

无论如何，客户端300向内容服务器302发送另一SETUP请求或PLAY请求，或使用SET_PARAMETER(设置参数)或OPTIONS(选项)方法来标识针对两个视频级质量度量而新近建议的单个报告速率(例如20秒)，如图5所示。该响应还指示客户端300接受针对视频级质量度量的0-40npt的单个报告范围。可替换地，如前所述，客户端300可以针对视频级质量度量建议不同的报告范围。还在响应中标识了音频级质量度量的报告速率，以表明被客户端300接受。

内容服务器302或者确认接受一个或多个所建议的质量度量和相应的报告参数值，或者建议不同的质量度量和相应的报告参数值。内容服务器302例如通过SET_PARAMETER或OPTIONS方法或者通过向客户端300发送诸如表明确认的SETUP或PLAY响应之类的响应，来接受特定的质量度量和报告参数值。如果发送响应，那么响应包括服务器302确认接受的在先请求中由客户端300提供的质量度量和报告参数值。由于客户端300和内容服务器302这二者已经就服务器302确认接受的质量度量达成一致，所以在后续请求中不包含服务器302确认接受的质量度量。

内容服务器302可以通过在响应中标识不同的值和相应的度量来建议不同的参数值。客户端300可以在后续请求中接受不同的值或建议新的值。总之，质量度量协商一直持续，直到内容服务器302确认接受所有度量或服务器302向客户端300发送PLAY响应为止。PLAY响应表明质量度量协商完成，并将开始递送流媒体内容。可替换地，当客户端300与服务器302之间的往返协商达到特定数量时，可以终止质量度量协商。无论如何，客户端300只基于商定的报告参数(一个或多个)来报告内容服务器302和客户端300所确认接受的质量度量。由于客户端300针对应用于流媒体会话的相同级别的全部所接受的质量度量协商单个报告速率和单个可选报告范围，所以极大的减少了客户端300发送的QoS/QoE报告的数量，从而降低了带宽消耗并提高了客户端性能。

质量度量协商结束后，客户端300发送指示所接收的流媒体内容的质量的QoS/QoE报告。针对流媒体会话的每个级别发送QoS/QoE报告的速率取决于客户端300针对每个级别而协商的单个报告速率值。客户端300可以将QoS/QoE报告作为RTSPSET_PARAMETER、PAUSE或TEARDOWN消息的一部分来发送。对于移动客户端106、108，通过无线电接入网112、114向内容服务器302发送QoS/QoE报告。图6示出了包括QoS/QoE报告的示例性SET_PARAMETER消息。该消息包括针对为流媒体会话的音频级别所报告的破坏持续时间度量(Corruption_Duration)的、由客户端300(200和1300)获得的两个测量。本例中参考的流媒体会话是基于图4所示的SETUP请求消息而被建立的。包含在SET_PARAMETER消息中的质量度量反馈首部(3GPP-QoE-Feedback)指示了包含在消息中的质量度量数据。根据图6，针对于流媒体会话的音频级别的破坏持续时间质量度量被报告。总的来说，客户端300根据针对每个级别协商的单个报告速率，针对流媒体会话的每个级别生成单个QoS/QoE报告。这样一来，就流媒体会话的相同级别而言客户端不会以不同速率生成多个报告。

图7示出了针对与应用于流媒体会话的相同级别的所有接受的质量度量相关联的每个报告参数协商单个值的示例性处理逻辑的实施例。该处理逻辑起始于客户端104、106、108从内容服务器102接收质量度量建议，例如作为RTSP DESCRIBE或SETUP响应消息或SDP文件的一部分(步骤700)。质量度量可以是例如包括在由服务器102发送的RTSP DESCRIBE响应或SETUP响应或SDP文件中的从内容服务器102接收的质量度量建议的初始集合。可替换地，质量度量可以是稍后在质量度量协商过程期间，例如作为从服务器102接收到的RTSP SETUP或PLAY响应的一部分或者通过SET_PARAMETER或OPTIONS方法，从内容服务器102接收到的经重新协商的度量建议的集合。总之，客户端104、106、108拒绝不支持的质量度量和参数(步骤702)。除非质量度量协商已经结束，客户端104、106、108尝试针对应用于流媒体会话的相同级别的所有所支持的质量度量来协商单个报告速率和可选地单个报告范围(步骤704)。在一个实施例中，客户端300在发送至服务器302的请求中仅包含尚待客户端300和服务器302这二者接受的度量。

客户端104、106、108确定内容服务器102是否已经针对流媒体会话的每个级别确认接受了所有支持的质量度量(步骤706)。客户端104、106、108针对应用于流媒体会话的相同级别的所有支持的质量度量协商单个报告速率以及可选地单个报告范围。这样一来，如果内容服务器102确认接受了由客户端104、106、108提出的所有质量度量建议，则客户端104、106、108就接受所有度量(步骤708)。客户端104、106、108此后根据针对流媒体会话的每个级别所商定的报告速率以及可选的报告范围，报告所接受的质量度量(710)。

然而，如果内容服务器102没有确认接收所有支持的质量度量，则客户端104、106、108确定服务器102是否已经确认接受了应用于流媒体会话的特定级别的质量度量(步骤712)。由于度量具有至少相同的报告速率，所以客户端104、106、108接受针对流媒体会话的特定级别所确认接受的所有质量度量(步骤714)。客户端104、106、108接着针对尚未被内容服务器102确认接受的质量度量建议相同的单个报告速率和相同的单个可选报告范围。在一个实施例中，内容服务器102确认接受针对应用于流媒体会话的特定级别的质量度量的第一子集而先前建议的报告速率，但针对其他质量度量建议不同的报告速率。

例如，客户端104、106、108可以针对应用于流媒体会话的视频级别的破坏持续时间、抖动持续时间和帧速率偏差度量，建议20秒的报告速率。内容服务器102针对破坏持续时间和抖动持续时间度量确认接受20秒的报告速率，但针对帧速率偏差度量建议10秒的报告速率。根据该实施例，客户端104、106、108针对破坏持续时间和抖动持续时间度量接受20秒的报告速率，但由于针对帧速率偏差度量的10秒的报告速率不同于客户端104、106、108先前建议的速率，拒绝针对帧速率偏差度量的10秒的报告速率。相应地，客户端104、106、108例如作为RTSP SETUP或PLAY请求的一部分或通过SET_PARAMETER或OPTIONS方法，针对应用于流媒体会话的视频级别的全部质量度量，建议单个报告速率(步骤716)。优选地，在本例中，由于内容服务器102针对破坏持续时间和抖动持续时间度量先前确认接受了20秒的速率，所以客户端104、106、108建议20秒的报告速率。这样一来，客户端104、106、108仅需针对帧速率偏差度量建议20秒的报告速率。

在另一实施例中，内容服务器102针对应用于流媒体会话的特定级别的所有支持的质量度量建议不同的报告速率。例如，客户端104、106、108可以针对应用于流媒体会话的视频级别的破坏持续时间、抖动持续时间和帧速率偏差度量而建议20秒的报告速率。内容服务器102针对应用于视频级别的每个质量度量反建议10秒的报告速率。根据该实施例，由于虽然不同于客户端104、106、108所建议的初始速率，但内容服务器102建议了单个报告速率，所以客户端104、106、108接受针对破坏持续时间、抖动持续时间和帧速率偏差度量的10秒的报告速率。相应地，客户端104、106、108例如作为RTSP SETUP或PLAY请求的一部分或通过SET PARAMETER或OPTIONS方法，针对应用于流媒体会话的视频级别的所有质量度量，建议10秒的报告速率(步骤716)。

根据任一实施例，客户端104、106、108针对应用于流媒体会话的相同级别的所有支持的质量度量协商单个报告速率以及可选地单个报告范围(或其他报告参数)。从内容服务器102接收到的质量度量建议可以不是按级别适当地组织的。也就是说，内容服务器102可能将会话级和媒体级质量度量与流媒体会话的一个级别(如会话级别)相关联。当这种情况发生时，客户端104、106、108可以对流媒体会话的适当级别再次应用质量度量。例如，内容服务器102可以将会话级质量度量(例如初始缓冲持续时间和/或再缓冲持续时间)和媒体级质量度量(例如RTP分组连续丢失、破坏持续时间、帧速率偏差和/或抖动持续时间度量)这二者应用于流媒体会话的会话级别。相应地，客户端104、106、108对适当的媒体级别再次应用媒体级质量度量。在一个实施例中，客户端104、106、108例如作为RTSP SETUP或PLAY请求或通过SET_PARAMETER或OPTIONS方法，通过将媒体级质量度量与标识流媒体会话的适当媒体组件的相应URI进行关联，对适当的媒体级别再次应用媒体级度量。接着，客户端104、106、108针对与应用于会话级别和每个媒体级别的质量度量相关联的每个报告参数协商单个值。

了解了上述变型和应用的范围，应当理解本发明既不限于前述说明，也不受限于附图。而是本发明仅由以下权利要求以及权利要求的等价物来限定。