CN103283205B - 本地媒体再现 - Google Patents

Abstract

本发明涉及由客户端用户设备(1)执行的多方呼叫的本地媒体再现。媒体由呼叫中的每方编码，并作为媒体流发送到媒体服务器(2)，并且媒体服务器从每个客户端用户设备接收对于媒体流的请求，请求中的每个媒体流与客户端优先级相关联。媒体服务器基于该请求选择媒体流要发送到每个客户端用户设备，并且还使得流数量不超过所确定的最大数量，最大数量例如基于可用带宽。

Description

本地媒体再现

技术领域

本发明涉及用于将媒体流传递到客户端用户设备以便本地再现的媒体服务器的方法以及用于从媒体服务器接收媒体流以便本地再现的客户端用户设备的方法。本发明还涉及媒体服务器和客户端用户设备。

背景技术

常规上，多方呼叫(例如语音会议)的技术实现通常会包括中央混合装置，所述中央混合装置用于将始发自会议中参与方的媒体流仅混合到每媒体类型一个媒体流中，以传递到每一个参与的客户端。对于语音会议，这对应于一个单媒体流或一个人工立体声媒体流。向每个参与方仅传递一个媒体流的一个原因是有限的访问带宽。

然而，在最近的技术中，诸如例如在VDSL2(超高速数字订户线2)中，更大的访问带宽可用，这消除了带宽限制，至少在具有低等或中等带宽要求的应用(诸如例如语音会议)中消除了带宽限制。

为了向多方呼叫中的每个参与方提供真实的立体声或3D(三维)位置语音(positionalaudio)，必须基于客户端的方向和位置，并基于呼叫中其它参与方的位置和方向，对于每个客户端再现唯一的媒体流。因而，中央再现框架需要有关每个参与方的位置和方向的信息，并且必须为每个客户端实现一个再现引擎。另外，这些再现引擎必须不断地用每个参与方的位置和方向更新。这在大型且高度动态的会议呼叫中(诸如在虚拟世界游戏中)特别具有挑战性。在这种高级音频混合情形中，在多方呼叫中涉及大量参与方，中央语音混合将导致复杂的系统架构用于媒体再现，其在中央语音混合装置中需要非常大的处理容量。

在常规中央再现中，媒体服务器(通常是包括混合器的会议桥)基本上处置每件事情，包含音频处理、3D位置音频再现、以及对为每个客户端创建的3D位置音频信号进行编码。属于每个参与方的客户端用户设备将仅解码每个相应的已编码信号，并且有可能向用户呈现GUI(图形用户界面)。对于每个参与的客户端用户设备，会议桥将创建3D位置音频信号，其要求将从所有参与方进来的语音信号进行3D位置音频再现。由于为每个参与方都创建唯一3D位置音频信号，因此要编码的输出信号数量将对应于参与方的数量。

另外，在常规中央再现中，高度交互应用中位置信息中的等待时间可使得可靠的语音再现不可能，并由此破坏用户体验。

相反，在本地再现中，中央媒体服务器的主要任务是判定多方呼叫的哪些媒体流应该被重新定向到哪个客户端设备以便本地再现，诸如例如来自所有参与方的媒体流或备选地仅来自几个主动讲话的参与方的媒体流。在从媒体服务器接收到所选择媒体流时，每个参与方的客户端用户设备都将执行本地媒体再现。如果在媒体服务器中不需要代码转换，即，如果所有客户端用户设备支持每个其它客户端用户设备的编解码器，则媒体服务器仅必须重新定向入局媒体流，并且不执行任何编码或音频再现。

WO2009/092060描述了用于在客户端中本地再现媒体的系统。3D位置音频的本地再现在中央装置(即媒体服务器)中需要较少的处理容量，并且减少了位置信息中的等待时间。在WO2009/092060中描述的系统中，每个媒体流含有媒体数据(即语音)和位置信息(即媒体分量的位置和能量)。而且，WO2009/092060公开了每个参与方的“滤波器组件”(例如见图1中的111)，其访问所有参与方的位置信息和媒体流，以及与参与方相关的本地信息。然而，系统实现比较复杂。

发明内容

下文描述的实施例的目的是解决上面概括的至少一些问题，并且这个目的和其它目的通过根据所附独立权利要求的方法和装置以及根据从属权利要求的实施例实现。

根据第一方面，提供一种用于媒体服务器在电信网络中将从多方呼叫接收的媒体流传递到参与的客户端用户设备以便本地音频或视频媒体再现的方法。所述方法包括：媒体服务器基于与所述客户端用户设备的协商来确定要同时传递的媒体流最大数量。另外，媒体服务器将定期从所述客户端用户设备接收对于媒体流的已更新请求，所述请求指示每个媒体流的客户端优先级。媒体服务器将基于所请求媒体流的客户端优先级，并且基于所选择媒体流的数量不应超过所确定的媒体流最大数量，从所述请求中选择媒体流，并将所选择媒体流发送到客户端用户设备以便本地再现多方呼叫。

根据第二方面，提供一种用于客户端用户设备在电信网络中从媒体服务器接收媒体流以便本地再现多方呼叫的音频或视频媒体的方法。所述方法包括客户端用户设备定期将对于媒体流的已更新请求发送到所述媒体服务器，所述请求指示每个媒体流的客户端优先级。另外，客户端用户设备将从所述媒体服务器接收媒体流，所述媒体流由所述媒体服务器基于所请求媒体流的客户端优先级并且基于媒体流的数量不应超过所确定的媒体流最大数量来选择。

根据第三方面，提供一种可连接到电信系统并配置成将从多方呼叫接收的媒体流传递到参与的客户端用户设备以便本地音频或视频媒体再现的媒体服务器。所述媒体服务器包括：确定单元，所述确定单元用于基于与客户端用户设备的协商来确定要同时传递的媒体流最大数量；以及接收单元，接收单元用于定期从所述客户端用户设备接收对于媒体流的已更新请求，所述请求指示每个所请求媒体流的客户端优先级。另外，媒体服务器包括：选择单元，选择单元用于从所接收的请求中选择媒体流，所述选择基于所请求媒体流的客户端优先级，并且基于所选择媒体流的数量不应超过所确定的流最大数量。媒体服务器还包括：发送单元，用于将所选择媒体流发送到客户端用户设备以便本地再现多方呼叫。

根据第四方面，提供一种可连接到电信网络并配置成从媒体服务器接收媒体流以便本地再现多方呼叫的音频或视频媒体的客户端用户设备。客户端用户设备包括：请求单元，用于创建对于媒体流的请求，所述请求指示每个媒体流的客户端优先级；以及发送单元，用于定期向媒体服务器发送已更新请求。客户端用户设备还包括：第一接收单元，用于从所述媒体服务器接收媒体流，所述媒体流由所述媒体服务器基于所请求媒体流的客户端优先级并且基于所接收媒体流的数量不应超过所确定的媒体流最大数量来选择。

示范实施例的优点是通过利用低成本且未充分利用的客户端资源来代替高成本的中央资源，并与其它信息分开传送媒体流，来提供大型且高度动态的会议的相对不复杂的本地再现。

附图说明

现在将参照附图更详细地描述本发明的示范实施例，附图中：

-图1示意性例证了用于本地媒体再现的示范架构；

-图2是示意性例证用于媒体服务器的示范方法的流程图；

-图3是示意性例证用于客户端用户设备的示范方法的流程图；

-图4和5示意性例证了示范媒体服务器；以及

-图6和7示意性例证了示范客户端用户设备。

具体实施方式

在如下描述中，将参考某些实施例和附图更详细地描述本发明。为了说明而非限制的目的，阐述了特定细节，诸如具体情形、技术等，以便提供对本发明的全面理解。然而，本领域技术人员要明白，本发明可以在脱离这些特定细节的其它实施例中实践。

此外，本领域技术人员将认识到，本文下面说明的功能和构件可使用结合编程的微处理器或通用计算机起作用的软件和/或使用专用集成电路(ASIC)实现。还将认识到，虽然当前发明主要以方法和装置的形式描述，但是本发明还可实施在计算机程序产品以及包括计算机处理器和耦合到处理器的存储器的系统中，其中存储器编码有可执行本文公开的功能的一个或多个程序。

根据下文描述的示范实施例的概念提供了多方呼叫的高度动态本地媒体再现，其中所述再现信息与媒体流分开传送。根据示范实施例，参与的客户端用户设备从数据服务器中的媒体应用接收有关位于附近的其它参与的客户端用户设备的再现信息，例如地理属性。因而，媒体服务器不必具有该信息。

相反，每个参与的客户端用户设备都请求媒体服务器传递所选择媒体流，通常来自位于合理距离内的其它参与的客户端用户设备。该请求还包含用于每个媒体流的优先级，下文称为客户端优先级，并且客户端优先级例如可基于媒体流的“源”位置，每个源对应于另一个参与的客户端用户设备。媒体服务器例如基于所请求媒体流的客户端优先级，判定向每个客户端用户设备传递哪些媒体流，但是媒体流也可被加权并由媒体服务器给出优先级。这个优先级基于媒体流的一个或多个属性(例如信号强度)，并且在下文称为媒体优先级。另外，媒体流数量必须不超过可同时传送到客户端用户设备的媒体流最大数量，并且在与客户端用户设备协商时，正常情况下在会话开始时，确定最大数量。

图1示意性例证了上面描述的本地再现的示范架构，该示范架构包括运行媒体应用的若干客户端用户设备，媒体应用由数据服务器3控制。然而，在图1中仅例证了一个客户端用户设备2。在客户端用户设备2中，还例证了对终端用户输入到客户端用户设备的媒体进行编码21的步骤、再现22媒体以便输出给终端用户的步骤以及向媒体服务器1请求23媒体流的步骤，该请求在信号S15中被传递给媒体服务器。媒体应用包含诸如例如实时语音或视频等媒体，并且该媒体被媒体服务器1用于客户端。在步骤22，根据在信号S16中从数据服务器接收的再现信息，在客户端用户设备中本地再现包含在媒体应用中的媒体。再现信息例如可包括参与的客户端用户设备的地理属性，因为该信息将是3D再现所需要的。

如上面所提到的，客户端用户设备2和媒体服务器1在建立会话时协商，以便确定可从媒体服务器向客户端用户设备同时传输的媒体流最大数量。例如基于可用带宽和/或客户端用户设备处理所接收媒体流的能力，来确定这个媒体流最大数量。然而，可在会话期间重新协商所确定的媒体流数量(如果媒体服务器或客户端用户设备需要这样做的话)。

在会话期间，在请求步骤23中，客户端用户设备基于与媒体流(即与每个媒体流的源客户端用户设备)相关联的请求信息(元数据)继续判定它希望在可用媒体流上从媒体服务器接收哪些媒体流。元数据31在信号S16中由数据服务器3提供给客户端用户设备2，然而，元数据31也可由终端用户提供(图1中未例证)。因而，请求信息可包括例如由数据服务器所提供的与源客户端用户设备相关联的位置信息、终端用户的人工输入、由数据服务器提供的应用特定信息和/或也由数据服务器提供的与每个参与的客户端用户设备相关联的优先级。基于与每一个其它参与的客户端用户设备(它们是媒体流的源)相关联的元数据，客户端用户设备定期在信号S15中向媒体服务器发送已更新请求以接收所选择媒体流。媒体流在请求中例如可指示为客户端用户设备希望从中接收媒体流以便本地再现的源(即客户端用户设备)的身份列表。另外，该列表包括与每个媒体流相关联的客户端优先级，客户端优先级指示媒体流的加权，所述加权基于上面描述的请求信息(元数据)。

在信号S14中，媒体服务器从多方呼叫中的所有参与的客户端用户设备接收已编码媒体流，不过在图1中仅例证了一个客户端和一个信号。基于来自客户端用户设备的请求，媒体服务器1在媒体选择步骤11中继续判定向每个客户端用户设备传递哪些媒体流，并且在信号S13中在媒体服务器与客户端用户设备之间在可用媒体流上发送到客户端用户设备2。媒体服务器的这个判定基于在信号S15中从客户端用户设备接收的请求中指示的客户端优先级，但它也可基于在媒体加权步骤12中由媒体服务器确定的媒体优先级。这个媒体加权可基于媒体流的一个或多个属性，例如基于信号强度。另外，选择传递哪些媒体流也基于所确定的、可同时传送到客户端用户设备的媒体流最大数量。

因而，在图1中，由实线例证媒体流S13和S14，而由虚线例证信息信号S15和S16，以便强调媒体流与媒体再现所需的信息分开传送。

根据一示范实施例，该媒体服务器可通过以下方式来实现该选择：将每个媒体流的媒体优先级加到从客户端用户设备接收的请求中的对应客户端优先级并选择具有最高总优先级的媒体流并且还界定媒体流数量不超过所确定的媒体流最大数量。

源客户端用户设备可在请求中由(客户端用户设备已知的)任意全球标识符标识(例如由RTP(实时协议)中的SSRC标识)，并且该请求利用适当协议(例如BFCP(二进制地板控制协议)的扩展)从客户端用户设备传递到媒体服务器。

全球标识符在相应客户端用户设备之间的传递通常利用数据服务器3来执行。

图2是例证用于媒体服务器1将来自多方呼叫的媒体流传递到客户端用户设备2以便本地再现的方法的示范实施例的流程图。在步骤24中开始会话之后，在步骤25，媒体服务器确定可同时传送到客户端用户设备的媒体流最大数量。在与客户端用户设备的协商时执行该确定，并且该确定例如可基于可用带宽和客户端用户设备的能力。

在步骤26，媒体服务器从客户端用户设备接收请求，该请求指示客户端用户设备想要从媒体服务器接收的媒体流。该请求中的每个媒体流与指示媒体流加权的客户端优先级相关联，使得与较高优先级相关联的媒体流将被选择用于传送到客户端用户设备，之后是与较低优先级相关联的媒体流。在该请求中指示的客户端优先级例如可基于源客户端用户设备的地理属性、从数据服务器接收的优先级、应用特定信息和/或终端用户进行的选择。

在步骤27，媒体服务器通过从请求中选择若干流来判定哪些媒体流要发送到客户端用户设备。该选择基于在请求中指示的媒体流的客户端优先级，并且基于媒体流数量不应超过所确定的可传送到客户端用户设备的媒体流最大数量。根据另一实施例，媒体服务器例如基于信号强度对媒体流执行加权，并将权重与每个媒体流相关联来作为媒体优先级，以便包含在判定中。接下来，在步骤28，媒体服务器向客户端用户设备发送所选择媒体流。

由于客户端用户设备定期向媒体服务器发送已更新请求，因此重复步骤26-28，直到在步骤29终止会话为止。

图3是例证用于客户端用户设备从媒体服务器接收媒体流以便本地再现的方法的示范实施例的流程图。

在步骤32开始会话之后，在步骤33，客户端用户设备与媒体服务器协商以便确定它可从媒体服务器同时接收的媒体流最大数量，例如基于可用带宽和客户端用户设备的能力来确定。

在步骤34，客户端用户设备将请求发送到媒体服务器，该请求指示客户端用户设备想要从媒体服务器接收的媒体流。该请求中的每个媒体流与指示媒体流加权的客户端优先级相关联，使得客户端用户设备优先接收具有较高优先级的媒体流，之后是具有较低优先级的媒体流。在请求中指示的优先级例如可基于源客户端用户设备的地理属性、从数据服务器接收的优先级和/或终端用户进行的选择。

在步骤35，客户端用户设备从媒体服务器接收由媒体服务器从请求中选择的媒体流。该选择基于在请求中指示的媒体流的客户端优先级，并且基于媒体流的数量不应超过所确定的可同时传送到客户端用户设备的媒体流最大数量。根据另一实施例，媒体服务器例如基于信号强度对媒体流执行加权，并作为媒体优先级包含在判定中。

在接收到媒体流时，客户端用户设备基于作为来自数据服务器3的元数据、与媒体流分开接收的适当再现信息(诸如例如源客户端用户设备的地理属性)，对多方呼叫的媒体执行本地再现。

客户端用户设备在会话期间定期向媒体服务器发送已更新请求，并且重复步骤34-36，直到在步骤37终止会话为止。

图4示意性例证了根据示范实施例的媒体服务器1。该媒体服务器包括确定单元41，确定单元41用于确定可同时传递到客户端用户设备的媒体流最大数量。在与客户端用户设备的协商时执行该确定，并且该确定例如基于可用带宽和/或客户端用户设备的能力。

另外，媒体服务器配备有用于与客户端用户设备通信的通信单元，该通信单元包括用于定期从客户端用户设备接收请求的接收单元42，该请求包括客户端用户设备想要接收的媒体流的指示，其中每个媒体流与指示媒体流加权的客户端优先级相关联。接收单元42还可配置成从参与的客户端用户设备接收已编码媒体流。然而，由于媒体流是与这些请求分开接收的，因此它们优选由单独的接收单元(图中未例证)接收。

另外，媒体服务器包括：选择单元43，选择单元43用于从请求中选择要发送到客户端用户设备的媒体流，所述选择基于在请求中指示的客户端优先级，并且还将所传送的媒体流数量不应超过所确定的媒体流最大数量考虑进去。上面提到的通信单元还包括用于将所选择媒体流发送到客户端用户设备的发送单元44。

根据另一实施例，选择单元还配置成使媒体流的选择基于由媒体服务器对媒体流执行的加权，所述加权基于媒体流的属性(例如基于信号强度)，并且所述加权与每个媒体流相关联来作为媒体优先级。

图5示意性例证了媒体服务器的实施例，该实施例是公开图4中所例证实施例的备选方式。媒体服务器1包括处理单元51，处理单元51可以是单个单元或多个单元。而且，媒体服务器1包括以非易失性存储器(例如EEPROM(电可擦除可编程只读存储器))、闪存或盘驱动器形式的至少一个计算机程序产品52。计算机程序产品52包括计算机程序53，计算机程序53包括当运行在媒体服务器1上时使媒体服务器中的处理单元51执行早先结合图2描述的过程步骤的代码构件。

因此，在图5中例证的实施例中，媒体服务器1的计算机程序53中的代码构件包括确定模块53a、接收模块53b、选择模块53c和发送模块53d。模块53a-53d实质上执行图2中的流程步骤以仿真在图4中描述的媒体服务器。换句话说，当不同的模块53a-53d运行在处理单元51上时，它们对应于图4的单元41、42、43和44，在上文结合与图4相关联的描述文本对它们进行了进一步说明。

尽管上文结合图5公开的实施例中的代码构件被实现为当运行在媒体服务器1上时使节点执行上文结合图2所描述步骤的计算机程序模块，但在备选实施例中，其中一个或多个代码构件可至少部分实现为硬件电路。

图6示意性例证了根据一示范实施例的客户端用户设备。该客户端用户设备配备有用于对媒体(例如来自本地用户的语音)进行编码的编码单元61和再现单元66，再现单元66用于例如使用从媒体服务器1接收的媒体流以及与媒体流分开接收的再现信息来再现多方呼叫。因而，客户端用户设备配备有用于从媒体服务器接收媒体流以便再现的第一接收单元65，由媒体服务器从自客户端用户设备接收的请求中选择媒体流。从而，客户端用户设备还包括用于创建到媒体服务器的请求的请求单元64，该请求指示客户端用户设备想要接收的媒体流，每个媒体流与媒体流的客户端优先级相关联。确定每个流的客户端属性例如可基于从数据服务器3接收的位置信息应用特定信息，而且基于终端用户进行的选择。已更新请求由发送单元62定期发送到媒体服务器，发送单元62还可用于将已编码媒体发送到媒体服务器。然而，由于媒体流是与这些请求分开传送的，因此客户端用户设备优选配备有用于媒体流的单独发送单元(该图中未例证)。

根据另一示范实施例，客户端用户设备包括第二接收单元63，第二接收单元63用于从数据服务器与媒体流分开地接收元数据，诸如例如与参与多方呼叫的其它客户端用户设备相关联的地理属性。元数据由请求单元64用于创建该请求并用于确定所请求媒体流的客户端属性，而且由再现单元66用于执行媒体再现。因而，从数据服务器接收的元数据可由客户端用户设备用作请求信息和再现信息。

图7示意性例证了客户端用户设备2的实施例，该实施例是公开图6中所例证实施例的备选方式。客户端用户设备2包括处理单元71，处理单元71可以是单个单元或多个单元。而且，客户端用户设备2包括以非易失性存储器(例如EEPROM(电可擦除可编程只读存储器))、闪存或盘驱动器形式的至少一个计算机程序产品72。计算机程序产品72包括计算机程序73，计算机程序73包括当运行在客户端用户设备2上时使处理单元71执行早先结合图3描述的过程步骤的代码构件。

因此，在图7中例证的实施例中，客户端用户设备2的计算机程序73中的代码构件包括编码模块73a、发送模块73b、第二接收模块73c、请求模块73d、第一接收模块73e和再现模块73f。因而，代码构件可实现为在计算机程序模块中构造的计算机程序代码。模块73a-73f实质上执行图3中的流程步骤以仿真在图6中描述的客户端用户设备2。换句话说，当不同的模块73a-73f运行在处理单元71上时，它们对应于图6的单元61、62、63、64、65和66，在上文结合与图6相关联的描述文本对这些单元进行了进一步说明。

尽管上文结合图7公开的实施例中的代码构件被实现为当运行在客户端用户设备2上时使节点执行上文结合图3描述的步骤的计算机程序模块，但在备选实施例中，其中一个或多个代码构件可至少部分实现为硬件电路。

因而，如上文表明的，应该注意，图4和5中所例证的媒体服务器1和图6和7中所例证的客户端用户设备2可由物理实体或逻辑实体使用结合编程的微处理器或通用计算机起作用的软件和/或使用专用集成电路(ASIC)实现。它们还可包含适当的内部存储装置和外部存储装置，以及适当的通信接口，其包含能够执行必要的调制、编码、滤波等以及解调和解码以处理这种信号的硬件和软件。

上面提到和描述的实施例仅作为示例给出，并不应该限制本发明。在所附专利权利要求书中所要求权利的本发明范围内的其它解决方案、用途、目的和功能对于本领域技术人员应该是显而易见的。

Claims (20)

1.一种用于媒体服务器(1)在电信网络中将从多方呼叫接收的媒体流传递到参与的客户端用户设备以便本地音频或视频媒体再现的方法，所述方法包括：

-基于与所述客户端用户设备的协商来确定(25)要同时传递的媒体流最大数量；

-定期从所述客户端用户设备接收(26)对于媒体流的已更新请求，所述请求指示每个媒体流的客户端优先级；

-从所述请求中选择(27)媒体流，所述选择基于所请求媒体流的所述客户端优先级，并且基于所选择媒体流的数量不应超过所确定的媒体流最大数量；以及

-将所选择的媒体流发送(28)到所述客户端用户设备以便对所述多方呼叫进行本地再现，其中所述再现基于与所述媒体流分开传送的再现信息。

2.如权利要求1所述的用于媒体服务器的方法，还包括所述媒体服务器将媒体优先级与每个媒体流相关联，其中媒体流的所述选择(27)还基于所述媒体优先级。

3.如权利要求2所述的用于媒体服务器的方法，其中与媒体流相关联的所述媒体优先级基于所接收媒体流的至少一个属性。

4.如以上权利要求中任一项所述的用于媒体服务器的方法，其中所述媒体流最大数量的所述确定基于可用带宽。

5.如权利要求1-3中任一项所述的用于媒体服务器的方法，其中所述媒体流最大数量的所述确定基于所述客户端用户设备的能力。

6.如权利要求1-3中任一项所述的用于媒体服务器的方法，其中所述客户端优先级基于如下项中的至少一项：位置信息、应用特定信息或终端用户进行的选择。

7.一种用于客户端用户设备(2)在电信网络中从媒体服务器(1)接收媒体流以便本地再现多方呼叫的音频或视频媒体的方法，所述方法包括：

-定期将对于媒体流的已更新请求发送(34)到所述媒体服务器，所述请求指示每个媒体流的客户端优先级；

-从所述媒体服务器接收(35)媒体流，所述媒体流由所述媒体服务器基于所请求媒体流的所述客户端优先级并且基于所述媒体流数量不应超过确定的媒体流最大数量来选择；以及

基于与所述媒体流分开接收的再现信息来在所述客户端用户设备(2)中本地再现(36)所述多方呼叫的媒体流。

8.如权利要求7所述的用于客户端用户设备的方法，其中所接收媒体流由所述媒体服务器还基于由所述媒体服务器确定并与所述媒体流相关联的媒体优先级来选择。

9.如权利要求7-8中任一项所述的用于客户端用户设备的方法，其中在与所述媒体服务器协商(33)时基于可用带宽来确定所述媒体流最大数量。

10.如权利要求7-8中任一项所述的用于客户端用户设备的方法，其中在与所述媒体服务器协商(33)时基于所述客户端用户设备的能力来确定所述媒体流最大数量。

11.如权利要求7-8中任一项所述的用于客户端用户设备的方法，其中所述客户端优先级基于如下项中的至少一项：位置信息、应用特定信息或终端用户进行的选择。

12.一种可连接到电信系统并配置成将从多方呼叫接收的媒体流传递到参与的客户端用户设备(2)以便本地音频或视频媒体再现的媒体服务器(1)，所述媒体服务器包括：

-确定单元(41)，用于基于与所述客户端用户设备的协商来确定要同时传递的媒体流最大数量；

-接收单元(42)，用于定期从所述客户端用户设备接收对于媒体流的已更新请求，所述请求指示每个所请求媒体流的客户端优先级；

-选择单元(43)，用于从所接收的请求中选择媒体流，所述选择基于所述所请求媒体流的所述客户端优先级，并且基于所选择媒体流的数量不应超过确定的媒体流最大数量；以及

-发送单元(44)，用于将所述所选择媒体流发送到所述客户端用户设备以便本地再现多方呼叫，其中所述再现基于与所述媒体流分开传送的再现信息。

13.如权利要求12所述的媒体服务器，其中所述选择单元还配置成基于与每个媒体流相关联并由所述媒体服务器确定的媒体优先级来选择媒体流。

14.如权利要求13所述的媒体服务器，其中所述媒体优先级基于所接收媒体流的至少一个属性。

15.如权利要求12-14中任一项所述的媒体服务器，其中所述确定单元还配置成使所述媒体流最大数量基于可用带宽。

16.如权利要求12-14中任一项所述的媒体服务器，其中所述确定单元还配置成使所述媒体流最大数量基于所述客户端用户设备的能力。

17.一种可连接到电信网络并配置成从媒体服务器(1)接收媒体流以便本地再现多方呼叫的音频或视频媒体的客户端用户设备(2)，所述客户端用户设备包括：

-请求单元(64)，用于创建对于媒体流的请求，所述请求指示每个媒体流的客户端优先级；

-发送单元(62)，用于定期向所述媒体服务器发送已更新请求；

-第一接收单元(65)，用于从所述媒体服务器接收媒体流，所述媒体流由所述媒体服务器基于所请求媒体流的所述客户端优先级并且基于所接收媒体流的数量不应超过确定的媒体流最大数量来选择；以及

-再现单元(66)，所述再现单元(66)用于基于与所述媒体流分开接收的再现信息来本地再现所述多方呼叫的媒体流。

18.如权利要求17所述的客户端用户设备，包括：第二接收单元(63)，所述第二接收单元(63)用于从数据服务器(3)接收元数据。

19.如权利要求17-18中任一项所述的客户端用户设备，还包括：编码单元(61)，所述编码单元(61)用于对所述客户端用户设备中的媒体输入进行编码。

20.如权利要求17-18中任一项所述的客户端用户设备，其中所述请求单元(64)还配置成使所述客户端优先级基于如下项中的至少一项：位置信息、应用特定信息和终端用户进行的选择。