用于使用单源多单播的多媒体会议的方法和装置

摘要

公开了用于使用单源多单播架构的会议中的通信的方法和装置。在一个方面中，提供了一种用于会议中的参与者之间的通信的方法。所述方法包括：从第一设备接收用于建立会议的第一消息，所述第一消息包括用于在所述会议中使用的编解码器类型列表。所述方法进一步包括：在第二设备处向第三设备发送第二消息，所述第二消息提供来自所述编解码器类型列表的一个或多个编解码器类型。所述方法进一步包括：在所述第二设备处对具有来自所述一个或多个编解码器类型的第一编解码器类型的第一数据流进行处理。

说明书

技术领域

本公开内容涉及编解码器协商的领域，具体地说，本公开内容涉及多媒体会议中的多播通信。

背景技术

数字视频和音频能力可以被并入范围广泛的设备，这样的设备包括数字电视机、数字直接广播系统、无线广播系统、个人数字助理(PDA)、膝上型或者桌面型计算机、数字照相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或者卫星无线电话、视频远程会议设备等。数字视频和音频设备实现视频和音频压缩技术，这样的技术诸如是在由移动图片专家组2(MPEG-2)、MPEG-4、国际电报联盟-电信标准化部门(ITU-T)H.263、ITU-T H.264/MPEG-4部分10、高级视频编码(AVC)、高效视频编码(HEVC)标准定义的标准和这样的标准的扩展中描述的那些技术。视频和音频设备可以通过实现这样的视频和音频编码技术来更高效地发送、接收、编码、解码和/或存储数字视频和音频信息。

视频和音频编码标准(诸如可伸缩HEVC(SHVC)和多视图HEVC(MV-HEVC))提供用于定义解码器能力的层定义。在下面，基于作出本发明时的现有的层定义和SHVC的其它上下文描述了问题和解决方案，但解决方案也适用于MV-HEVC和其它的多层编解码器。

发明内容

落在所附权利要求的范围内的系统、方法和设备的各种实现各自具有若干方面，这些方面中没有任何单个方面唯一地负责本文中描述的可取的属性。在本文中描述了一些突出的特征，而不限制所附权利要求的范围。

在附图和下面的描述内容中阐述了本说明书中描述的主题的一种或多种实现的细节。从描述内容、附图和权利要求中，其它的特征、方面和优点将变得显而易见。应当指出，以下附图的相对尺寸可以不是按比例绘制的。

本公开内容中描述的主题的一个方面提供了一种用于会议中的参与者之间的通信的方法。所述方法包括：从第一设备接收用于建立会议的第一消息，所述第一消息包括用于在所述会议中使用的编解码器类型列表。所述方法进一步包括：在第二设备处向第三设备发送第二消息，所述第二消息提供来自所述编解码器类型列表的一个或多个编解码器类型。所述方法进一步包括：在所述第二设备处对具有来自所述一个或多个编解码器类型的第一编解码器类型的第一数据流进行处理。

本公开内容中描述的主题的另一个方面提供了一种用于在会议中进行通信的装置。所述装置包括：被配置为从第一设备接收用于建立会议的第一消息的接收机，所述第一消息包括用于在所述会议中使用的编解码器类型列表。所述装置进一步包括：被配置为向第三设备发送第二消息的发射机，所述第二消息提供来自所述编解码器类型列表的一个或多个编解码器类型。所述装置进一步包括：被配置为对具有来自所述一个或多个编解码器类型的第一编解码器类型的第一数据流进行处理的处理器。

本公开内容中描述的主题的另一个方面提供了一种用于在会议中进行通信的装置。所述装置包括：从第一设备接收用于建立会议的第一消息，所述第一消息包括用于在所述会议中使用的编解码器类型列表。所述装置进一步包括：用于在第二设备处向第三设备发送第二消息的单元，所述第二消息提供来自所述编解码器类型列表的一个或多个编解码器类型。所述装置进一步包括：用于在所述第二设备处对具有来自所述一个或多个编解码器类型的第一编解码器类型的第一数据流进行处理的单元。

另一个方面提供一种非暂时性计算机可读介质。所述介质包括在被执行时使装置执行方法的代码。所述方法包括：从第一设备接收用于建立会议的第一消息，所述第一消息包括用于在所述会议中使用的编解码器类型列表。所述方法进一步包括：在第二设备处向第三设备发送第二消息，所述第二消息提供来自所述编解码器类型列表的一个或多个编解码器类型。所述方法进一步包括：在所述第二设备处对具有来自所述一个或多个编解码器类型的第一编解码器类型的第一数据流进行处理。

另一个方面提供一种用于会议中的通信的方法。所述方法包括：在第一设备处经由同播传输从第二设备接收具有第一编解码器类型的第一数据流和具有第二编解码器类型的第二数据流。所述方法进一步包括：在所述第一设备处选择所述第一或者第二数据流，以及在所述第一设备处处理所选择的第一或者第二数据流。所述方法可以进一步包括：选择所述第一或者第二数据流是基于所述第一数据流的特性或者基于所述第二数据流的特性的。所述第一数据流的所述特性可以包括编解码器类型，并且所述第二数据流的所述特性可以包括编解码器类型。

另一个方面提供一种用于会议中的参与者之间的通信的方法。所述方法包括：从第一设备接收第一消息，所述第一消息包括用于在所述会议中使用的编解码器类型列表，所述第一消息标识所述编解码器类型列表中的哪些编解码器是强制编解码器类型和哪些是可选编解码器类型。

所述方法可以进一步包括其中所述第一消息包括标识所述编解码器类型列表中的哪些编解码器是强制编解码器类型和哪些是可选编解码器类型的分隔符的方面。

所述方法可以进一步包括其中所述分隔符在所述编解码器类型列表中的位置标识所述编解码器类型列表中的哪些编解码器是强制编解码器类型和哪些是可选编解码器类型的方面。

所述方法可以进一步包括其中所述编解码器类型列表中的所述分隔符标识所述强制编解码器类型的方面。

所述方法可以进一步包括其中所述第一消息包括标识所述编解码器类型列表中的哪些编解码器是所述强制编解码器类型和哪些是所述可选编解码器类型的参数的方面。

所述方法可以进一步包括其中所述参数是‘con_rev’的方面，并且其中，所述编解码器类型列表中的编解码器的次序标识哪些编解码器是所述强制编解码器类型和哪些是所述可选编解码器类型。

所述方法可以进一步包括其中所述参数是‘mand_recv’的方面，并且其中，被列出为具有所述参数的所述编解码器类型列表中的编解码器是所述强制编解码器类型。

另一个方面提供一种用于会议中的参与者之间的通信的方法。所述方法包括：从第一设备接收用于建立会议的第一消息，所述第一消息包括用于在所述会议中使用的编解码器类型列表，所述编解码器类型列表包括至少一个可选编解码器类型；在第二设备处向第三设备发送第二消息，所述第二消息提供包括所述至少一个可选编解码器类型和来自所述编解码器类型列表的对应的强制编解码器类型的同播流；以及从所述第三设备接收包括所述至少一个可选编解码器类型和所述对应的强制编解码器类型的所述同播流。

另一个方面提供一种用于会议中的参与者之间的通信的方法。所述方法包括：在第一设备处从所述会议的第一子集接收多个数据流；在所述第一设备处向所述会议发送所述多个数据流；在所述第一设备处从所述会议的第二子集接收第一数据流；暂停所述多个数据流中的一个数据流的传输；将所述被暂停的数据流重用于所述第一数据流的传输；用一个或多个静默指示符(SID)帧替换所述第一数据流；以及恢复所述第一数据流的传输。

另一个方面提供一种用于会议中的参与者之间的通信的方法。所述方法包括：从第一设备接收用于建立会议的第一消息，所述第一消息包括用于在所述会议中使用的编解码器类型列表；在第二设备处向第三设备发送第二消息，所述第二消息提供来自所述编解码器类型列表的所述一个或多个编解码器类型中的少于全部的编解码器类型；在所述第二设备处从所述第三设备接收列出未在所述第二消息中被列出的编解码器类型的第三消息；以及在所述第二设备处发送具有未在所述第二消息中被列出的所述编解码器类型的第一数据流。

所述方法的另一个方面是其中在所述第三消息中被列出的所述编解码器类型处在所述第一消息中的所述编解码器类型列表中。

所述方法的另一个方面是其中所述第一数据流被发送给所述第三设备。

所述方法的另一个方面是其中所述第二消息仅包括EVS。

所述方法的另一个方面是其中在所述第三消息中被列出的所述编解码器类型是AMR-WB。

附图说明

图1示出了用于多个参与者的会议架构的一个示例。

图1A示出了可以在可以于本文中公开的会议架构内被利用的终端中被使用的各种部件。

图2示出了用于多个参与者的分散式会议架构的一个示例。

图3示出了用于多个参与者的分散式会议架构的另一个示例。

图4示出了其中终端充当混合器的用于多个参与者的混合型会议架构的一个示例。

图5示出了其中终端充当混合器和参与者的用于多个参与者的混合型会议架构的一个示例。

图6是用于分散式会议中的编解码器协商的一种示例性方法的流程图。

图7是用于分散式会议中的编解码器协商的另一种示例性方法的流程图。

图8是用于会议中的编解码器协商的一种示例性方法的流程图。

图9是用于会议中的编解码器协商的另一种示例性方法的流程图。

图10是用于多个参与者的一种示例性多播架构的图。

图11是用于会议中的通信的一种示例性方法的流程图。

图12是用于会议中的通信的另一种示例性方法的流程图。

图13是使用集中式处理器或者会议焦点的用于多个参与者的一种示例性单源多单播架构的图。

图14是用于会议中的通信的一种示例性方法的流程图。

图15是可以通过执行RTP暂停、重用、替换和恢复行动减小在参与者之间被发送的提供的大小的使用集中式处理器的用于多个参与者的一种示例性单源多单播架构的图。

具体实施方式

下面结合附图阐述的详细描述内容旨在作为对本发明的特定的实现的描述，而不旨在代表可以通过其实践本发明的仅有的实现。贯穿本说明书被使用的术语“示例性”表示“充当示例、实例或者说明”，而不应当必然地被解释为是优选的或者比其它的示例性实现有利的。出于提供对所公开的实现的透彻理解的目的，详细描述内容包括具体的细节。在一些情况下，以方框图形式示出了一些设备。

视频编码标准包括ITU-T H.261、ISO/IEC MPEG-1视觉、ITU-T H.262或者ISO/IECMPEG-2视觉、ITU-T H.263、ISO/IEC MPEG-4视觉和ITU-T H.264(也被称为ISO/IEC MPEG-4AVC)(包括其可伸缩视频编码(SVC)和多视图视频编码(MVC)扩展)。

另外，视频编码标准，即，高效视频编码(HEVC)已经被ITU-T视频编码专家组(VCEG)和ISO/IEC MPEG的视频编码联合协作组(JCT-VC)开发。HEVC草案10的完整引文是文档JCTVC-L1003，Bross等人，“High Efficiency Video Coding(HEVC)Text SpecificationDraft 10”，ITU-T SG16 WP3和ISO/IEC JTC1/SC29/WG11的视频编码联合协作组(JCT-VC)，第12次会议：日内瓦，瑞士，2013年1月14日至2013年1月23日。HEVC的多视图扩展(即，MV-HEVC)和HEVC的可伸缩扩展(即，SHVC)也分别正在被JCT-3V(3D视频编码扩展开发ITU-T/ISO/IEC联合协作组)和JCT-VC开发。MV-HEVC的最近的工作草案(WD)在下文中将被成为MV-HEVC WD7。SHVC的最近的WD在下文中将被称为SHVC WD5。

用于层定义的现有的方法有时不提供用于定义用于对多层比特流的高效解码的解码器能力的足够的信息。例如，为了解码多于4个各自具有720p分辨率的信噪比(SNR)可伸缩层(具有等价的分辨率的层)，将需要层5或者以上的解码器。因此，亮度编码树块(CTB)大小将等于32x32或者64x64(即，不可以使用诸如是16x16这样的更小的编码大小)。然而，对于一些层(诸如那些具有为720p或者更低的分辨率的层)，该约束可以导致产生次优的编码效率。

在一些情况下，可以通过重用多个现有的单层解码器来制造解码器。在一个示例中，依照现有的层定义，由4个单层HEVC层3.1解码器组成的SHVC解码器为了解码4个720p的SNR层将必须符合层4或者以上。通过该定义，解码器将必须是能够解码任何层4比特流的。然而，除了对解码器硬件的变更之外，这样的解码器将不能够解码具有2个1080p分辨率的SNR层的SHVC层4比特流。

伴随现有的HEVC层定义的另一个问题在于，以为了能够解码1080p的单层HEVC比特流和720p的两层SHVC比特流的方式被实现的解码器将被加标签为层3.1。然而，层3.1标签不表述用于解码1080p的单层比特流的能力。

在另一个示例中，对于为了能够解码4个720p的SNR层而使用4个单层HEVC 3.1解码器被实现的解码器，依照现有的层定义，解码器将必需符合层4或者以上。因此，将要求解码器能够解码具有多于3个图块(tile)行和多于3个图块列的比特流，每个图块具有为256个亮度采样的宽度和为144个亮度采样的高度。然而，解码器的层3.1限制将不能够解码一些这样的比特流。

在SHVC的现有设计下，HEVC文本的分条款A.4.1中的全部项被指定为被应用于每个层。然而，一些项不是直接适用于每个层的。例如，对于关于经解码图片缓冲器(DPB)大小的项d，序列参数集(SPS)语法元素不适用于增强层。此外，SHVC WD5中的DPB是共享-子-DPB设计，因此，项d不可以被直接地应用于每个层。作为另一个示例，对于关于经编码图片缓冲器(CPB)大小的项h和i，对于特定于比特流的CPB操作，参数不可以被应用于每个层。

需要(由HEVC文本的分条款A.4.1中的项h和i施加的)对于CPB大小的特定于比特流的约束。然而，HEVC文本的分条款A.4.1中的项h和i不可以在比特流级被直接地应用，因为如果被直接地应用，则用于单层比特流的相同的CPB大小限制将也是用于多层比特流的限制。这不是可对层数伸缩的，并且在存在许多层时将仅允许低图片质量。

由HEVC文本的分条款A.4.2中的项b、c、d、g、h、i和j施加的约束被指定为是仅特定于层的。然而，应当指定由这些项施加的特定于比特流的约束，而不考虑是否指定了它们的特定于层的对应约束。

尽管在本文中在HEVC和/或H.264标准的上下文中描述了特定的实施例，但本领域的技术人员应当认识到，本文中公开的系统和方法可以是适用于任何合适的视频编码标准或者非标准视频编解码器设计的。例如，本文中公开的实施例可以是适用于以下标准中的一项或多项标准的：国际电信联盟(ITU)电信标准化部门(ITU-T)H.261、国际标准化组织/国际电工委员会(ISO/IEC)MPEG 1视觉、ITU-T H.262或者ISO/IEC MPEG-2视觉、ITU-TH.263、ISO/IEC MPEG-4视觉和ITU-T H.264(也被称为ISO/IEC MPEG-4AVC)(包括可伸缩和多视图扩展)。

在许多方面，HEVC总体上遵循之前的视频编码标准的框架。HEVC中的预测单元是与特定的之前的视频编码标准中的预测单元(例如，宏块)不同的。实际上，如在特定的之前的视频编码标准中理解的宏块的概念在HEVC中不存在。宏块被基于四叉树方案的分层结构替换，除了其它的可能的好处之外，基于四叉树方案的分层结构还可以提供高的灵活性。例如，在HEVC方案内，定义了三种类型的块：编码单元(CU)、预测单元(PU)和变换单元(TU)。CU可以指区域分割的基本单元。可以认为CU是与宏块的概念类同的，但HEVC不约束CU的最大大小，并且可以允许递归地分割成四个相等大小的CU以改进内容自适应性。可以认为PU是帧间/帧内预测的基本单元，并且单个PU可以包含用于有效地编码不规则图像模式的多个任意形状分区。可以认为TU是变换的基本单元。可以独立于PU地定义TU；然而，可以使TU的大小限于该TU属于其的CU的大小。将块结构分隔成三个不同的概念的该分隔可以允许根据单元的分别的作用优化每个单元，这可以导致产生改进了的编码效率。

仅出于说明的目的，利用包括视频和/或音频数据的仅两个层(例如，诸如是基本层这样的较低层和诸如是增强层这样的较高层)的示例描述了本文中公开的特定的实施例。视频数据的“层”可以总体上指具有至少一个公共的特性或者参数(诸如视图、帧速率、分辨率等)的图片的序列。例如，一个层可以包括与多视图视频数据的具体的视图(例如，角度)相关联的视频数据。作为另一个示例，一个层可以包括与可伸缩视频数据的具体的层相关联的视频数据。因此，本公开内容可以可互换地提到视频数据的层和视图。即，视频数据的视图可以被称为视频数据的层，并且视频数据的层可以被称为视频数据的视图。另外，多层编解码器(也被称为多层视频编码器或者多层编码器-解码器)可以联合地指多视图编解码器或者可伸缩编解码器(例如，被配置为使用MV-HEVC、3D-HEVC、SHVC或者另一种多层编码技术对视频数据进行编码和/或解码的编解码器)。视频编码和视频解码可以两者总体地被称为视频编码。应当理解，这样的示例可以是适用于包括多个基本和/或增强层的配置的。另外，为了易于解释，以下公开内容包括参考特定的实施例的术语“帧”或者“块”。然而，这些术语将不是限制性的。例如，下面描述的技术可以被用于任何合适的视频单元(诸如块(例如，CU、PU、TU、宏块等)、切片、帧等)。

视频编码标准

数字图像(诸如视频图像、TV图像、静止图像或者由录像机或者计算机生成的图像)可以由被布置在水平的和垂直的行中的像素或者采样组成。单个图像中的像素的数量通常是数以万计的。每个像素通常包含亮度和色度信息。在没有压缩的情况下，将从图像编码器向图像解码器传达的信息的绝对量将使实时图像传输是不可能的。为减少将被发送的信息的量，已经开发了一些不同的压缩方法(诸如JPEG、MPEG和H.263标准)。视频编码标准包括哪些之前在本文中被详述的视频编码标准。

多流多方会议

在一些实施例中，在多流多方会议中，支持多流视频、至少两个视频内容(例如，一个主和一个呈现)、多流音频、至少2个音频内容以及其它的额外的能力可能是可取的。在一些方面中，集中式处理器或者网桥可以采取行动以支持这些功能。集中式处理器或者网桥可以接收多流视频/音频数据、混合视频/音频数据并且向参与者中的每个参与者发送经混合的数据流。

图1是用于多个参与者的一种示例性会议架构100的图。会议架构100包括终端110A-D和集中式处理器125。在一些方面中，集中式处理器125可以包括服务器或者会议网桥提供商。集中式处理器125可以从终端110A-D中的每个终端接收数据流，解码、混合并且向终端110A-D发送经混合的数据流。在一些方面中，集中式处理器125可以使用多播传输发送经混合的数据流。在一些实施例中，一个数据流可以包括一个或多个音频、视频和/或媒体流。

图1A示出了可以在可以于本文中公开的会议架构内被使用的终端110A-D中被利用的各种部件。在一些方面中，终端110A-D可以各自包括处理器115、接收机120、发射机125、收发机130、天线135、存储器140、数据库145和用户接口150中的一项或多项。终端110A-D是可以被配置为实现本文中描述的各种方法的设备的一个示例。终端110A-D可以实现集中式处理器125。

终端110A-D可以包括控制终端110A-D的操作的处理器115。处理器115也可以被称为中央处理单元(CPU)。在一些实现中，终端110A-D可以额外地包括向处理器115提供指令和数据的存储器140，存储器140可以包括只读存储器(ROM)和随机存取存储器(RAM)两者。存储器140的部分可以还包括非易失性随机存取存储器(NVRAM)。处理器115可以基于被存储在存储器140内的程序指令执行逻辑和算术操作。存储器140中的指令可以是可执行为实现本文中描述的方法的。

处理器115可以包括利用一个或多个处理器实现的处理系统或者是这样的处理系统的部件。一个或多个处理器可以利用通用微处理器、微控制器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑设备(PLD)、控制器、状态机、门逻辑、分立的硬件部件、专用硬件有限状态机或者任何其它的可以执行对信息的计算或者其它操纵的合适实体的任意组合来实现。

处理器115和/或存储器140可以还包括包括代码的非暂时性计算机可读介质，代码在被执行时使装置或者处理器115执行本申请中描述的任何方法。软件应当被宽泛地解释为表示任何类型的指令，不论其被称为软件、固件、中间件、微代码、硬件描述语言还是其它术语。指令可以包括代码(例如，采用源代码格式、二进制代码格式、可执行代码格式或者任何其它合适的代码格式的)。指令在被一个或多个处理器执行时使处理系统执行本文中描述的各种功能。

终端110A-D可以还包括用于允许终端110A-D与集中式处理器125之间的数据发送和接收的发射机125和接收机120。可以将发射机125和接收机120组合成收发机130。可以将单个或多个收发机天线135电耦合到收发机130。因此，在一些实现中，发射机125可以包括或者构成用于发送消息的单元的至少一部分。同样地，接收机120可以包括或者构成用于接收消息的单元的至少一部分。

终端110A-D可以还包括数据库145和用户接口150。终端110A-D的各种部件可以被总线系统155耦合在一起，除了数据总线之外，总线系统155可以还包括电力总线、控制信号总线和状态总线。

在一些实施例中，在没有集中式处理器125的情况下建立多流多方会议可能是可取的。例如，集中式处理器125可能需要可能增加成本和/或复杂度的单独的基础设施和服务。额外地，可以要求参与者在多流多方会议之前进行建立或者向集中式处理器125进行注册。相应地，对于参与者来说，在不使用集中式处理器125的情况下在他们的终端(例如，计算机、平板型计算机、智能电话或者其它的用户设备等)上建立多流多方会议(例如，分散式会议)可能是可取的。

图2是用于多个参与者的分散式会议架构200的一个示例的图。如图2中所示，分散式会议架构200可以包括终端110A、110B和110C。终端110A、110B和110C可以与彼此交换数据流，并且可以解码、编码和/或混合其接收和/或发送的数据流。例如，如图2中所示，终端110A从终端110B和110C接收数据流，并且向终端110B和110C发送数据流。数据流可以包括媒体流、音频流、视频流或者这样的流的任意组合。这多个数据流可以被独立地并且并发地解码，然后在每个终端处被混合在一起，在向观看者或者收听者渲染经混合的数据流之前，优选地具有某种知觉的空间分隔。终端110A、110B和110C中的每个终端可以具有对它们可以并发地操作的解码器/编码器实例的数量的计算上的限制。在一些方面中，由会议发起者在建立具有终端内混合的多流多方会议(例如，分散式会议)时将这些限制考虑在内可能是可取的。

如在上面就图2描述的，可以要求终端110A、110B和110C中的每个终端并发地解码从其它的会议参与者接收的多个数据流。每个终端110可以具有对其可以并发地操作的解码器实例的数量的计算上的限制。这限制可以处在与终端的会议中的参与者的数量，或者要求终端具有用于优先化对特定的数据流进行解码并且忽略其它的数据流的能力。例如，如果终端不忽略其接收的任何数据流，则参与者数量必须小于或者等于解码器的最大数量加一(N<＝MaxDec+1)。其中，N是会议中的参与者(包括会议发起者)的数量，并且MaxDec是可以被终端并发地运行的解码器的最大数量。在一些实施例中，终端110A可以通过与终端110B和110C连接来发起会议，并且然后终端110B和110C可以与彼此连接来完成会议。

参考图2，如果终端110A是会议发起者，则终端110A可以使用上面的计算来确定要将多少呼叫者/终端邀请到会议(即，N-1)。此外，如果其它的终端(例如，终端110B和110C)中的每个终端不优先化或者忽略其接收的数据流，则每个终端可以也是能够解码N-1个数据流的。因此，对于发起者终端110A来说，考虑以下限制可能是可取的：N<＝Min[每个终端的MaxDec]+1。因此，终端110A作为会议发起者将可以被会议中的每个参与终端并发地运行的解码器的最大数量计算在内，并且可以确保参与者的数量不超过最小的解码器最大数量加一。

类似地，具有终端内混合的会议可以要求终端并发地编码被发送给其它的参与终端的多个数据流。这可以在发起者为一种数据类型提供多于一种类型的编解码器并且其它的参与者选择使用不同的编解码器时发生。在一些方面中，数据类型可以包括音频类型、视频类型或者其它的媒体类型。

图3示出了用于多个参与者的分散式会议架构300的另一个示例。在一些实施例中，终端110A作为发起者终端可以向终端110B和110C提供一个或多个编解码器。例如，如图3中所示，终端110A向终端110B和110C提供增强语音服务(EVS)编解码器和自适应多速率宽带(AMR-WB)两者。在一些方面中，提供可以包括会话描述协议(SDP)提供消息或者第一消息。如所示的，终端110C支持EVS，并且以选择EVS的消息作出响应。终端110B可以仅支持AMR-WB，并且在其对终端110A的响应中选择AMR-WB。在一些方面中，终端110B和110C响应于来自终端110A的提供而发送的消息可以包括SDP应答消息。终端110B和110C可以还执行它们自己的编解码器协商(例如，经由来自终端110A的会话发起协议(SIP)REFER方法建立的)，由于终端110B不支持EVS，所以该编解码器协商导致选择AMR-WB。如从图3中可见，终端110A和110C两者必须都并发地用EVS和AMR-WB格式对它们的内容进行编码，而终端110B仅需要用AMR-WB格式进行编码/解码。

如上面描述的，在一些实施例中，终端可以通过使用SIP REFER方法在没有集中式处理器或者中央焦点的情况下建立会议会话。在一些方面中，发起者终端(例如，终端110A)首先建立与其它的(N-1)个参与者(终端110B和110C)中的每个参与者的一对一SIP对话。一旦建立了对话，则终端110A然后向其它的参与者中的每个参与者发出请求他们建立与其它的(N-2)个参与者中的每个参与者的会话的多个SIP REFER消息(第一消息、第二消息、第三消息等)。这通过作为“参考URI”包括指示去往其它的终端110B和110C的SIP INVITE消息的SIP统一资源标识符(URI)来完成。

例如，终端110A可以向终端110B发出请求终端110B向终端110C发送INVITE消息的REFER消息。为了冗余度和最小化会议建立延迟，终端110A可以还向终端110C发送请求终端110C向终端110B发送INVITE消息的相互REFER消息。如果存在更多的参与者(例如，第四终端110D)，则终端110A将向终端110B和终端110C各自发送请求他们也向终端110D发送INVITE消息的至少一个额外的REFER消息。在一些方面中，为了引入冗余度和最小化会议建立延迟，终端110A应当还向终端110D发送请求其也向终端110B和110C发送INVITE消息的REFER。

在一些实施例中，在由发起者终端110A经由REFER消息请求冗余的INVITE消息时，接收REFER消息的终端不再应当向该终端发送INVITE消息，所述REFER消息请求所述终端向其已经从之接收INVITE消息的终端发送INVITE消息。

在一些方面中，为减少网络中的总的SIP信令负载，以潜在地增加会议建立时间为代价，发起者终端110A可以决定不请求冗余的INVITE消息在参与者之间被发送。例如，如果参与者被编号为1到N，其中，1是发起者终端110A，则发起者终端110A发送以下消息：

●去往终端2的、请求其向终端3到N发送INVITE消息的REFER消息

●去往终端3的、请求其向终端4到N发送INVITE消息的REFER消息

.

.

.

●去往终端M的、请求其向终端M+1到N发送INVITE消息的REFER

.

.

.

●去往终端N-1的、请求其向终端N发送INVITE消息的REFER消息。

在一些实施例中，在发出REFER请求时，终端110A可以不向会议中的每个参与者(例如，终端110B和110C)发送给予他们各自其它的(N-2)个参与者的身份的REFER消息。在一些方面中，可以遵循以下过程：

1.发起者终端(例如，终端110A)构造会议参与者(例如，终端110B和110C)的经排序的列表，并且根据其在该列表中的位置识别每个参与者终端。在一些方面中，列表包括与每个参与者相关联的URI的列表。假设会议包含N个参与者(包括发起者终端)，则可以将发起者终端定位在列表的顶部(位置1)处。在一些方面中，发起者终端已经具有与(N-1)个参与者中的每个参与者的1-1会话。

2.发起者终端(例如，终端110A)向被编号为2，3，…，(N-1)的(N-2)个参与者发送REFER消息。例如，如图3中所示，终端110A将向参与者终端110B(例如，对于被编号为2的终端110B和被编号为3的终端110C)发送一个REFER消息(即，3-2)。在一些方面中，每个REFER消息可以包含不同的长度的URI列表。被发送给参与者终端i(其中，2<＝i<＝(N-1))的URI列表包含(N-i)个条目。URI列表可以包括被编号为(i+1),(i+2),…N的参与者终端的URI。例如，如图3中所示，被发送给终端110B(即，终端2)的URI列表可以包括终端110C(即，终端3)的URI。

3.在接收REFER消息时，每个参与者终端可以向由发起者终端向其提供的参与者终端的列表发送INVITE消息，并且会话建立正常地继续进行。继续来自图3的示例，终端110B(即，终端2)可以向在由终端110A(发起者终端)发送的REFER消息中被列出的终端110C(即，终端3)发送INVITE消息。

在上面的过程中，将为建立N方会话所生成的信令的总量从(N-1)*(N-1)最小化到N*(N-1)/2可以是可能的。在一些方面中，参与者N(例如，图3的终端110C)不接收任何REFER消息，而仅接收来自其它的(N-2)个参与者(例如，图3的终端110B)的INVITE消息。在一些实施例中，如果期望冗余度，则可以延长REFER消息中的URI列表以允许一些重叠。在REFER消息中的URI列表的长度对于全部参与者是相同的时，完全冗余度可以存在。例如，在上面的场景中，可以使被发送给参与者i的URI列表是(N-i+1)个终端。在这样的实施例中，每个参与者将获得完整的URI列表以使得其知道全部其它的参与者的身份。然而，其仅向那些在列表中出现在其自己的身份之后的终端发出INVITE消息，并且等待从那些身份在列表中出现在其自己的身份之前的终端接收INVITE消息。在未从这样的终端接收任何INVITE消息的情况下，该终端可以向那个终端发送INVITE消息。

对于终端110A(发起者终端)，考虑以下限制可能是可取的：其提供的编解码器的类型的数量和N-1的值中的最小值应当小于或者等于可以被终端110A并发地运行的编码器的最大数量(Min[提供中的编解码器的类型的数量,(N-1)]<＝MaxEnc)。其中，MaxEnc是可以被终端110A并发地运行的编码器的最大数量。例如，如果终端110A可以提供3种类型的编解码器，并且存在总共3个参与者，则其提供的编解码器的类型的数量和N-1的值中的最小值将等于2，2将小于或者等于可以被终端110A并发地运行的编码器的最大数量。

额外地，如在上面就伴随多个终端的编码讨论的，对于终端110A来说，认为编解码器的类型的数量还应当小于会议中涉及的每个终端的MaxEnc可能是可取的。因此，应当遵循以下限制：Min[提供中的编解码器的类型的数量,(N-1)]<＝Min[每个终端的MaxEnc]。

在一些实施例中，对于终端110A(发起者终端)来说，考虑额外的约束可能是可取的。例如，对于给定的数据类型，不同类型的编解码器可以具有不同的计算复杂度要求。例如，EVS编解码器是比AMR-WB编解码器更复杂的。这可以要求会议发起者(终端110A)对于其包括在提供消息中的每个编解码器考虑以下各项：每个编解码器的可以被终端110A并发地运行的编码器的最大数量的最小值和每个编解码器的可以被终端110A并发地运行的解码器的最大数量的最小值。以上各项也可以被表述为：Min[每个编解码器的MaxEnc]和Min[每个编解码器的MaxDec]。在一些方面中，每个终端可以传送针对其支持的编解码器中的每个编解码器的其MaxEnc和MaxDec。

在分散式会议中，终端执行编码和解码两者。如果这些过程在相同的处理器上运行，则MaxEnc和MaxDec可以取决于每个操作(编码/解码)的多少个实例正在运行。在概念上，可以如下地一般化该限制：复杂度[操作的编码器+操作的解码器]<＝复杂度限制。即，操作的编码器的复杂度加操作的解码器的复杂度应当小于或者等于终端的复杂度限制。

在一个实施例中，终端可以对其对于编码和解码允许的复杂度的量作出折中。例如，如果终端110A将要发起为数据提出仅一种编解码器类型(即，强制编解码器)的会议，则其知道其将不需要多于一个编码器实例，并且可以将其处理器资源中的更多处理资源用于解码。这可以允许其增大N，只要其知道其它的终端(例如，终端110B和110C)也具有对于所选择的编解码器来说必要的解码能力就行。替换地，终端110A可以在其仅计划发起小型会议时选择提出更多编解码器类型，其中，N等于小的值。

在一些多流多方会议中，终端执行音频和视频编码两者。如果这些过程在相同的处理器上运行，则MaxEnc和MaxDec可以取决于对于每个数据类型，每个操作的多少个实例正在运行。在概念上，可以如下地一般化该限制：复杂度[操作的音频编解码器+操作的视频编解码器]<＝复杂度限制。即，操作的音频编解码器的复杂度加操作的视频编解码器的复杂度应当小于或者等于终端的复杂度限制。

在一个实施例中，终端可以还在不同的数据类型之间对其对于编码和解码允许的复杂度的量作出折中。例如，如果终端110A将要发起为视频提出仅一种编解码器类型(即，像H.264这样的强制视频编解码器)的会议，则可以知道其将不需要多于一个视频编码器实例，并且可以将其处理器资源中的更多处理器资源用于对视频进行解码和音频编码/解码。这可以允许终端110A增大N或者为音频数据类型提出更多的语音编解码器(例如，EVS、AMR-WB、AMR)。

在一些实施例中，即使N>Min[每个终端的MaxDec]+1，终端也可以扩展其处置具有N个用户的会议的能力，只要该终端和会议中的全部其它的终端不解码它们接收的数据流中的全部数据流就行。这要求终端具有用于基于数据流的特定的参数选择要优先化哪些数据流和忽略哪些数据流的单元。如下面描述的，参数可以包括传输模式、音量水平、复杂度水平、活跃度水平、分组大小等。

在一个示例实施例中，终端可以检查从会议参与者和/或媒体网关(例如，下面讨论的图4和5的终端/媒体网关450)接收的多个RTP流。例如，取决于RTP分组长度和参与者ID，终端可以在活跃的语音(通常以较高的比特率(例如，13.2kb/s)被编码)与非活跃的/背景部分(通常使用非连续传输(DTX)(例如，2.4kb/s)被编码)；以及参与者ID 2或者3或者..(N-1)之间进行区分。终端可以在每个RTP分组实例处跟踪参与者的列表中的活跃的说话者。可以存储并且分析活跃的说话者信息以选择最近的活跃参与者RTP流中的哪个RTP流的优先级可以被解码和非活跃的流中的哪个流不被发送以便进行解码。

基于过去的活跃说话者的优先级划分

在语音的情况下，可以基于哪些数据流处在或者不处在特定的模式(例如，DTX模式)下作出该选择。在多数情况下，由于同时收听多于两个说话者是困难的，所以谈话者可以自然地发言或者向彼此让出控制。因此，可以解码多达两个或三个并发的数据流的终端可以处置多数的音频会议配置。然而应当指出，由于终端必须检查来自数据流的语音分组(至少针对大小)以确定哪些是活跃的，所以随着渐增的N，将仍然存在一些操作复杂度增长。

基于RTP水平限制的优先级划分

在另一个实施例中，终端(终端110A)可以搜遍其正在接收的数据流，并且选择混合(优先化)活跃的最先MaxDec个数据流。在找到MaxDec个活跃的数据流之后，其停止搜遍其它的数据流，因此节省一些计算复杂度。

对于终端110A来说，还有可能尝试优先化具有最响亮的音量的数据流。该优先级划分可能要求解码来自每个数据流的数据以确定最响亮的MaxDec个数据流。如果采样/选择不是对于每个语音帧(例如，以较长的间隔定期地)被执行的，则终端110A可以节省一些复杂度。

对于视频，由于不存在与模式(例如，DTX模式)和音量相同的概念，所以动态地选择要优先化和忽略哪些数据流可能不是那么简单的。查看其它的标准(诸如移动的量)可以涉及大量复杂度。其它的标准(诸如查看数据分组的大小)可以被用于获得对具体的数据流中的运动/新信息的看法。

视频可以还具有额外的挑战，这在于，数据流中的帧中的多数帧是就数据流中的之前的视频帧而言被不同地编码的。如果数据流被忽略，则其不可以被简单地再次解码，直到可独立解码的(例如，IDR)帧或者其参考帧已经被预存储的帧被接收为止。在一个实施例中，对要解码的数据流的选择可以是基于对应的音频分组长度的。例如，如果与视频分组相关联的音频是经DTX的(最小分组大小)，则终端110A可以确定不对视频进行解码并且显示最后的帧(冻结图片)。因此，基于最后的三个活跃谈话者，接收者(例如，终端110A)可以优先化要解码哪些数据流。在接收者接收给定的数据流中的视频IDR帧时，其可以选择解码该帧、显示它和/或者作为参考帧保存它。如果不存在很多运动，则IDR帧可以被较不频繁地接收，并且显示IDR帧可以是足够的。在一些方面中，如果会议参与者不谈话(不是活跃谈话者)，但移动得很多，则接收者(例如，终端110A)可以转而使用音频分组长度来对视频进行解码。

在一些方面中，通过分散式架构(诸如图2和3的分散式架构200和300)的通信可以使产生终端的上行链路传输期间的增加了的处理。例如，如图2和3中所示，每当终端110A发送数据流时，其必须向终端110B和110C中的每个终端发送数据流的副本，则可能需要大量资源。在一些实施例中，利用多播会议架构来解决多单播架构中的对上行链路传输的增加了的需求中的一些需求可能是有益的。

在一些实施例中，上面就分散式会议架构描述的解码能力中的一些或全部解码能力可以被应用于集中式或者混合式会议架构。回头参考图1，集中式处理器125可以从终端110A-D中的每个终端接收数据流、解码、混合并且向终端110A-D发送经混合的数据流。在其它的方面中，集中式处理器125可以从终端110A-D中的每个终端接收数据流、解码、混合并且向一些终端发送该数据流，并且可以向其它的终端发送多个数据流。在其中终端110A-D中的一个或多个终端接收多个数据流的一些方面中，接收多个数据流的终端110A-D可以依赖于上面描述的参数来忽略、选择或者优先化要解码哪些数据流。例如，如图1中所示，终端110A-D可以向集中式处理器125发送数据流。集中式处理器125然后可以解码并且将所接收的数据混合成经混合的数据流，并且向终端110A-C发送经混合的数据流。集中式处理器125还可以向终端110D发送多个数据流(例如，来自终端110A-C的三个数据流)。

在一些方面中，终端110D和/或集中式处理器125可以是在它们可以并发地处理和/或编码/解码的数据流的数量上受限的。在上面参考图1描述的示例中，终端110D可以从终端110A-C接收三个数据流，但可以仅是能够解码两个数据流的。类似地，集中式处理器125可以接收四个数据流(例如，来自终端110A-D中的每个终端的一个数据流)，但可以仅是能够解码三个数据流的。相应地，终端110D和/或集中式处理器125可以基于特定的参数优先化、选择和/或忽略特定的数据流。例如，终端110D和/或集中式处理器125可以优先化所接收的数据流以解码两个或三个最响亮音量的数据流并且忽略最低音量的数据流。

额外地，如就图2和3的分散式架构讨论的，发起会议的终端110(例如，终端110A)应当考虑参与会议的其它终端110(例如，终端110B-D)的编码/解码限制以及集中式处理器125编码/解码限制。例如，发起者终端110A可以考虑上面对会议中的参与者的数量的限制中的一个或多个限制，例如：N<＝Min[每个终端/集中式处理器的MaxDec]+1；Min[提供中的编解码器的类型的数量,(N-1)]<＝Min[每个终端/集中式处理器的MaxEnc]；对于被提供的编解码器，Min[每个编解码器的MaxEnc]和Min[每个编解码器的MaxDec]；复杂度[操作的编码器+操作的解码器]<＝复杂度限制；和/或复杂度[操作的音频编解码器+操作的视频编解码器]<＝复杂度限制。

图4是其中终端/媒体网关450充当混合器的用于多个参与者的一种示例性混合型会议架构400的图。如图4中所示，终端110A-C可以各自向终端/媒体网关450发送数据流，终端/媒体网关450然后向终端110A-C发送多个数据流。例如，终端/媒体网关450可以从终端110B和110C接收数据流，解码并且向终端110A发送那些数据流。在一些方面中，终端/媒体网关450可以混合来自终端110B和110C的数据流，并且向终端110A发送经混合的数据流。

在一种实现中，终端110A可以基于特定的限制或者会议参数调整其从终端/媒体网关450接收的数据流的数量。例如，终端110A可以利用终端/媒体网关450(或者图1的集中式处理器125)处理能力来减少或者卸载其自己的处理或者确保会议架构(集中式、分散式或者混合型的)限制内的高效的通信。在一个方面中，因为终端110A可以仅是能够解码一个数据流的或者因为终端110A具有有限的处理能力，所以终端110A可以请求终端/媒体网关450仅发送一个经混合的数据流。

额外地，对于图1-4(和下面的图5)中的终端110A-D、集中式处理器125和/或终端/媒体网关450来说，对能力进行切换可能是可能的。例如，终端110A-D和集中式处理器125可以是正在图1的会议架构100中操作的，并且集中式处理器125可以丢失功率或者失去混合能力。在一些方面中，终端110D可以从作为会议参与者进行操作切换到作为图4的非参与的终端/媒体网关450进行操作，特别是替换集中式处理器125功能。额外地，图4的终端/媒体网关450也可以通过向会议中的一个或多个参与者(例如，终端110A-D)发送其自己的数据流来作为会议中的参与的终端/媒体网关450进行操作。相应地，终端110A-D、集中式处理器125和/或终端/媒体网关450中的每项可以被配置为在图1的集中式会议架构100、图2和3的分散式会议架构200和300和图4的混合型会议架构400中的一项或多项中进行操作。

在一个示例中，会议(例如，会议架构100、200、300、400和500[在下面被讨论])可以具有包括第一持续时间和第二持续时间的会议持续时间。在一些方面中，在第一持续时间期间，终端110D可以如图1中示出的那样作为会议参与者进行操作。在一些方面中，在第二持续时间期间，终端110D可以切换到如图4(和下面的图5)中描绘的那样作为终端/媒体网关450进行操作。在一些方面中，终端110D可以向集中式处理器125、向终端110A-C中的一个或多个终端(如图1中示出的)或者向另一个控制器或者设备请求切换操作功能。在其它的方面中，集中式处理器125或者终端110A-C中的一个或多个终端(如图1中示出的)可以确定终端110D是能够切换到作为终端/媒体网关450进行操作的。

在一些方面中，会议发起或者关联可以在第一持续时间期间发生，并且会议数据的交换可以在第二持续时间期间发生。例如，就图2和3而言，在第一持续时间期间，终端110A可以向终端110B和110C发送包括被终端110A支持的编解码器能力的列表的第一或者提供消息。终端110A可以从终端110B和110C中的每个终端接收响应消息。第二或者响应消息可以包括分别的终端110B或者110C的编解码器能力的列表和被终端110B和110C选择的编解码器类型。终端110A可以基于第二或者响应消息中的每个第二或者响应消息中的编解码器能力的列表来确定是否终端110B和110C中的每个终端可以参与会议。在第二持续时间期间，终端110A-C可以在彼此之间交换数据流。

在一些方面中，集中式处理器125或者终端110A-C中的一个或多个终端可以请求终端110D切换到作为终端/媒体网关450进行操作。在一些实施例中，请求可以是基于终端110D的编码/解码能力和/或基于集中式处理器125或者终端110A-C中的一个或多个终端编码/解码能力的。例如，终端110A可以确定其可以仅接收两个数据流，并且可以请求终端110D切换操作。该请求可以包括请求终端110D处理并且混合来自终端110B和110C的通信和终端110D向终端110A发送经混合的数据流。在一些方面中，可以从终端110A、110D或者集中式处理器125中的一项向终端110B和110C发送请求，请求指示新的会议标识符或者终端110B和110C的会议统一资源标识符(URI)是终端110D的地址。在一些方面中，可以经由带外通信发送对用于为终端110B和110C处理和混合数据流的新目的地(即，终端110D)的请求或者指示。响应于请求，终端110B和110C然后可以从向集中式处理器125发送数据流切换到向终端110D发送数据流。为了减少切换所涉及的潜在的等待时间问题，终端110B和110C可以向集中式处理器125和终端110D两者发送数据流，直到集中式处理器125和/或终端110D确定切换完成了的时间为止。

图5是其中终端/媒体网关450充当混合器和参与者的用于多个参与者的一种示例性混合型会议架构500的图。如图5中所示，终端110A可以发起与作为会议中的参与者的终端110B、终端/媒体网关450和终端110D-E的会议。终端110A可以通过任何使得参与者(终端110B、终端/媒体网关450和终端110D-E)加入会议的方法发起会议。例如，终端110A可以使用与参与者的带外通信(例如，指示会议的电子邮件通信和/或会议网桥)发起会议。在一些方面中，终端110A也可以通过结合去往终端110D和110E的带外通信使用上面针对终端110B和终端/媒体网关450描述的REFER方法对于要经由终端/媒体网关450加入会议的那些终端发起会议。在其它的方面中，终端110A可以通过通告会议的开始的轮询消息发起会议，并且终端110B和110D-E和终端/媒体网关450可以发送具有它们的编解码器能力的消息来加入会议。如上面描述的，其它的用于发起会议的方法也是可能的。

如上面就图1-4讨论的，终端110A可以在发起会议时考虑参与者中的每个参与者的编码/解码能力。在图5中，终端110A可以向终端110B发送数据流516、向终端/媒体网关450发送数据流519和分别从终端110B和终端/媒体网关450接收数据流517和521。终端110B还可以向终端/媒体网关450发送数据流518，并且从终端/媒体网关450接收数据流520。终端/媒体网关450还可以分别从终端110D和110E接收数据流524和525，并且分别向终端110D和110E发送数据流522和523。数据流516-525中的每个数据流可以包括一个或多个音频和/或视频(媒体)流。

在一些实施例中，终端/媒体网关450充当混合器和会议中的参与者两者。例如，终端/媒体网关450可以接收来自终端110A的数据流519、来自终端110B的数据流518、来自终端110D的数据流524和来自终端110E的数据流525。在一些方面中，终端110D和110E可以各自仅是能够解码一个数据流的，而终端110A和110B可以各自是能够解码三个数据流的。在一些方面中，终端110A和110B可以被看作与终端110D和110E相比的新的或者高效的终端。在一些方面中，终端110D和110E可以被看作与终端110A和110B相比的遗留的或者较旧的设备。在一个实施例中，终端/媒体网关450可以向终端110D发送单个经混合的数据流522和向终端110E发送单个经混合的数据流523。在一些方面中，终端/媒体网关450可以向终端110D和110E发送多播经混合数据流，同时向终端110A和110B并发地发送单播数据流521和520。额外地，终端/媒体网关450可以向终端110A发送数据流521，数据流521可以包括来自终端110B的数据流、来自终端/媒体网关450的数据流和来自终端110D和110E的经混合的数据流。

在其它的方面中，终端/媒体网关450可以发送来自会议中的其它的参与者的数据流的其它的组合。例如，终端/媒体网关450可以忽略来自终端110E的数据流，并且向终端110A发送仅来自终端110B、110D和终端/媒体网关450的数据流。终端/媒体网关450(和终端110A、110B、110D和110E中的任意终端)可以根据本文中描述的实现或者组合中的任意实现或者组合优先化、选择和/或忽略特定的数据流。在另一个示例实施例中，终端/媒体网关450可以从终端接收数据流，并且识别是活跃的语音(例如，110B、110C)和是背景/非活跃的语音(例如，110D、110E)的流。终端/媒体网关450可以选择解码并且混合DTX/非活跃帧，并且作为一个非活跃帧随多个活跃帧一起(例如，向终端110A)进行发送。在具有大量参与者(例如，N>10)的多方会议中，上面讨论的在终端/媒体网关450处对DTX/非活跃帧的有选择的预解析和混合可以减少在终端处被接收以便进行处理的多个流的数量。接收方终端(例如，110A)现在可以具有要对于解码进行检查和优先化的较少的流。在另一个示例实施例中，终端/媒体网关450可以确定与DTX/非活跃帧相关联的对应的视频流，并且执行将那些视频/图像数据流图块化/重新编码为一个视频流，因此减少在终端处被接收以便进行处理的多个视频流的数量。

如上面就图4讨论的，在一些方面中，图5的终端110A、110B、110D、110E和终端/媒体网关450中的任意项可以以多种方式切换操作功能。例如，终端110B和终端/媒体网关450可以确定(例如，经由带外通信或者通过对编解码器能力的分析)将终端/媒体网关450的混合操作转移到终端110B。在一些方面中，终端/媒体网关450和/或终端110B可以直接地或者间接地(例如，在带外或者通过另一个终端)向其它的会议参与者广播终端110B正在接管终端/媒体网关450的处理和混合操作。尽管终端110B被讨论为正在接管终端/媒体网关450的处理操作，但在其它的实施例中，终端110A、110D或者110E或者另一个设备中的任意项可以类似地替换终端/媒体网关450的处理和/或混合操作。

在其它的实施例中，终端/媒体网关450可以采用REFER方法来向要传输会议参与者正在向终端/媒体网关450发送的会议数据流的其它的会议参与者广播现在向终端110B发送会议数据流。另外，会议参与者可以在一个时段内向终端/媒体网关450和终端110B两者发送它们分别的数据流，直到全部会议参与者正在向终端110B发送它们的数据流为止。类似地，终端/媒体网关450和终端110B可以在一个时段内两者并发地处理并且混合它们从其它的会议参与者接收的多个数据流，直到终端/媒体网关450和/或终端110B已经确定全部终端已经切换为止，以减少潜在的中断或者等待时间问题。

图6是分散式多媒体会议中的编解码器协商的一种示例性方法600的流程图。图6中所示的方法600可以经由会议架构200和/或300中的一个或多个设备来实现。在一些方面中，方法可以被与图1-3的用户终端110A-110D类似的设备或者任何其它合适的设备实现。

在方框605处，发起者终端(终端110A)可以向两个或更多个设备发送用于建立会议的第一或者提供消息。第一消息可以包括被发起者终端支持的编解码器能力的列表。在一些实施例中，第一消息可以还是基于其并发能力是提前已知的其它参与者(终端110B和110C)的编解码器能力的。

在方框610处，发起者终端从两个或更多个设备中的每个设备接收第二或者响应消息。第二消息包括两个或更多个设备的被发送方设备支持的编解码器能力的列表和由两个或更多个设备中的一个设备从被第一设备支持的编解码器能力的列表中选择的编解码器类型。被包括在第一消息和/或第二消息中的编解码器能力信息可以指示每编解码器的能力、独立地指示每个编解码器的编码器和解码器的能力、指示是否不同的编解码器的编码器和/或解码器的并发的操作共享相同的计算资源和/或指示由于终端能够智能地裁剪或者减少(例如，通过如上面讨论的那样优先化特定的数据流)数据流的数量以匹配其并发解码能力，所以终端解码能力不构成约束。

满足上面对于编解码器能力信息的格式要求的一个示例将描述对于每个编码/解码功能可用的或者已分配的处理器资源的百分比。这允许发起者终端对包括不同的数据类型的那些编解码器的编解码器以及它们的编码器和解码器进行混合和匹配，只要其保持总复杂度负载不大于给定的处理器中的已分配的资源的100％就行。一种用于描述上面的信息的方法可以是引入两个新的编解码器级SDP属性：

a＝enc_use:percent,proc_num

a＝dec_use:percent,proc_num

其中，“percent(百分比)”的范围从0到1.0，并且描述对于编码/解码功能可用的处理器“proc_num”的资源分配因子。可以如下地在表1中概念化所述信息：

表1

如在上面参考图1-5指出的，接收方终端或者设备(例如，终端110B、终端/媒体网关450等)可以优先化和忽略具体的数据流以减少其必须并发地操作/解码的解码器实例的数量。如果终端使用这样的“裁剪”算法并且能够限制其必须解码的数据流的数量以匹配其并发解码能力，则终端不需要会议发起者基于终端的解码能力限制呼叫中的参与者的数量。在这种情况下，终端可以如下面的表2的示例中示出的那样指示与这样的流相对应的为0的处理器资源分配因子：

表2

支持对许多数据流的并发解码的能力使得很可能解码可以不是在设置会议的大小时的限制因素。可以被终端的协议栈处置的实时传输协议(RTP)数据流的数量变成限制因素。因此，也传送该信息可以是有益的。此外，可以定义两个新的会话级SDP属性以指定对并发的RTP栈的数量的限制：

a＝rtp_tx_limit:rtp_instances

a＝rtp_rx_limit:rtp_instances

其中，“rtp_instances”指示所支持的并发RTP实例的数量。在一些方面中，会议发起者终端(例如，图2-5的终端110A)使用来自会议中的每个参与者的上面的信息来确保所提出的会议不超过参与者的编解码器或者RTP处理能力。

在方框615处，发起者终端可以基于编解码器能力的列表确定是否两个或更多个设备中的全部设备可以参与(或者继续参与)会议(即，在前面的小节中描述的约束全部被满足)。在一些方面中，如果发起者未发现任何问题，则其允许会议如已协商的那样被建立，并且将全部所接收的信息存储在终端中的每个终端的单个简档中。在其它的方面中，如果发起者发现问题，则其可以尝试通过向参与者中的一些或全部参与者发送具有可行的提供(基于全部已接收的参与者的并发编解码器能力所构造的)的新消息(例如，SIP Re-INVITE/UPDATE消息)来纠正问题。

在一些实施例中，发起者终端可以基于其并发编解码器能力和其并发能力是提前已知的的其它参与者的那些并发编解码器能力发送第一或者提供消息。在接收第一消息之后，每个参与者的终端可以检查第一消息以确定N和被提供的编解码器的最大数量，以确定其是否可以满足前面的小节中描述的约束。如果终端可以参与，则其可以利用所选择的编解码器作出响应。

图7是分散式多媒体会议中的编解码器协商的一种示例性方法700的流程图。图7中所示的方法700可以经由会议架构200和/或300中的一个或多个设备来实现。在一些方面中，方法可以被与图1-3的用户终端110A-D类似的设备或者任何其它合适的设备实现。

在方框705处，终端(终端110B)可以从第一设备接收用于建立会议的第一或者提供消息。第一消息可以包括被第一设备支持的编解码器能力的列表。在一些方面中，第一消息可以是基于发起者终端的并发编解码器能力的。在一些实施例中，第一消息可以还是基于其并发能力是提前已知的的其它参与者(终端110B和110C)的编解码器能力的。

在方框710处，终端有选择地发送第二或者响应消息，第二消息包括从被第一设备支持的编解码器能力的列表中选择的编解码器类型，并且包括被终端支持的编解码器能力的列表。在一些方面中，在接收第一消息之后，终端可以对第一消息进行处理以确定参与者的数量和被提供的编解码器的最大数量，以确定是否其可以满足本文中描述的约束。如果终端可以参与，则其可以利用包括从被第一设备支持的编解码器能力的列表中选择的编解码器和其自己的编解码器能力的列表的第二消息作出响应。如果终端确定其不可以参与，则其不可以利用第二消息作出响应。

在另一个实施例中，其它的参与终端(例如，终端110B和110C)也可以将它们的并发编解码器能力包括在第二消息中。这允许发起者终端存储终端的能力并且保证对于由同一个发起者终端发起的任何未来的会议恰当地考虑终端的能力。在一些方面中，发起者终端可以将能力存储在数据库中。

如果参与终端确定其不可以参与，则其在第二消息中对此作出指示，并且发送其并发编解码器能力。发起者终端然后可以如下地处理来自其它的参与终端的第二消息：(1)如果发起者终端未接收任何否定响应，则其允许会议继续；(2)如果发起者终端接收否定响应，则其使用全部已接收的并发编解码器能力来构造新的提供消息，并且在新的第三消息(例如，SIP Re-INVITE/UPDATE消息)中向参与者中的一些或全部参与者发送该提供消息。

在一些实施例中，每个终端可以将终端中的每个终端的并发编解码器能力简档存储在其地址簿或者数据库中。该简档可以包括用于每个终端的每个数据类型的MaxEnc和MaxDec。在其它的方面中，该简档可以包括用于全部数据类型的终端的编解码器的列表以及被编解码器的每个实例使用的资源分配因子或者处理器复杂度的百分比。例如，下面的表3示出了用于全部数据类型的终端的编解码器的示例性列表以及被编解码器的每个实例使用的处理器复杂度的百分比。

表3

在一些方面中，发起者终端然后可以使用参与者中的每个参与者的上面的简档来确定可以由每个参与者使用本文中描述的约束考虑来满足的第一或者提供消息。

在传送它们的并发编解码器能力时，终端可以还指示由于它们能够优先化和忽略具体的数据类型的数据流，所以它们可以处置对更多的数据流的接收。例如，终端110A可以指示其可以并发地解码多达三个EVS数据流(每个使用其处理器的20％)，在这三个EVS数据流之后其将忽略任何已接收的额外的数据流。

在一些方面中，终端还可以在会议被发起之前交换并发编解码器能力信息以更好地保证可行的提供消息被包括在第一发起消息(例如，第一SIP INVITE)中。可以如下地执行对并发编解码器能力信息的该交换：在用户将另一个用户添加到终端上的它们的地址簿或者目录时，地址簿应用联系彼此以交换并发编解码器能力以及任何其它的个人信息(家庭地址等)，或者在终端的编解码器能力变更(经由下载或者终端硬件的交换)时。可以使用在用户之间被提供的任何联系人信息标识符(ID)来执行对信息/简档的该交换。例如：如果ID是电子邮件地址则经由电子邮件交换中的嵌入式简档多用途互联网邮件扩展(MIME)类型；如果ID是电话号码则经由通过短消息服务(SMS)被发送的可扩展标记语言(XML)方案；经由通过某种其它的消息传送协议被发送的XML方案。可以以多种方式更新简档信息。例如，用户作出去往彼此的呼叫或者经由早先描述的用于建立具有终端内混合的会议的协议，即，可以在响应中发送并发编解码器能力。在另一个示例中，存储简档的终端可以设置定时器以自治地并且定期地(例如，每个月)与另一个用户的终端再联系以查看是否能力已经变更。这些能力可能由于由用户作出的软件更新或者下载或者变更他们的手机而变更。在一些方面中，已经提供简档的终端可以每当其自己的能力已经变更时在其地址簿中更新全部的用户。替换地，会议中的两个或更多个参与者(不是发起者的)可以在建立它们之间的数据会话时交换它们的并发编解码器能力。

在一些方面中，OPTIONS请求可以被用于通过要求终端发送其将提供的描述其编解码器能力的会话描述协议(SDP)的副本来查询另一个终端的编解码器能力。该SDP将包含如上面描述的并发编解码器能力信息。可以完全提前于会议呼叫地作出OPTIONS请求，并且可以将SDP响应存储在被查询的终端的简档中。在一些实施例中，紧接在建立会议之前，会议发起者可以查询其计划邀请的全部终端的编解码器能力(对于这些终端来说，其还未预存所述信息)。

图8是多媒体会议中的编解码器协商的一种示例性方法800的流程图。图8中所示的方法800可以经由图1-5中的会议架构100、200、300、400和500中的一个或多个设备来实现。在一些方面中，方法800可以被与图1-5的用户终端110A-D、集中式处理器125和/或终端/媒体网关450类似的设备或者任何其它合适的设备实现。

在方框805处，终端(例如，图5的终端/媒体网关450)可以从第一设备接收用于建立会议的第一或者提供消息。第一消息可以包括被第一设备支持的编解码器能力的列表。

在方框810处，终端有选择地发送第二消息。第二消息可以包括从被第一设备支持的编解码器能力的列表中选择的编解码器类型，并且包括被第二设备支持的编解码器能力的列表。

在方框815处，终端基于被第一设备支持的编解码器能力的列表有选择地向第三设备发送数据流。在方框820处，终端接收请求数据流被发送给第四设备的第三消息。在方框825处，终端向第四设备发送数据流。

图9是多媒体会议中的编解码器协商的一种示例性方法900的流程图。图9中所示的方法900可以经由图1-5中的会议架构100、200、300、400和500中的一个或多个设备来实现。在一些方面中，方法800可以被与图1-5的用户终端110A-D、集中式处理器125和/或终端/媒体网关450类似的设备或者任何其它合适的设备实现。

在方框905处，终端(例如，图5的终端110A)可以向两个或更多个设备发送用于建立会议的第一或者提供消息。第一消息可以包括被终端支持的编解码器能力的列表。

在方框910处，终端从两个或更多个设备中的每个设备接收第二消息，第二消息包括编解码器能力的列表和由两个或更多个设备中的一个设备从被第一设备支持的编解码器能力的列表中选择的编解码器类型。在一些方面中，第二消息中的编解码器能力的列表包括被发送第二消息的两个或更多个设备中的第一设备支持的编解码器能力的列表。

在方框915处，终端基于第二消息中的每个第二消息中的编解码器能力的列表确定是否两个或更多个设备中的每个设备可以参与会议。在方框920处，终端基于被第一设备支持的编解码器能力的列表有选择地向两个或更多个设备中的第二设备发送数据流。在方框925处，终端接收请求数据流被发送给第二设备的第三消息。在方框930处，终端向第二设备发送数据流。

在多播会议架构中，每个参与者加入公共的多播组，并且每个参与者向该组发送其数据流的单个副本。底层多播基础设施(例如，网络路由器和交换机)然后分发数据流，以使得每个参与者获得一个副本。该多播分发模型超过多单播(如图2和3中所示的)的一个非限制性的优点在于，其不要求发送方终端(例如，终端110A)向其它的(N-1个)参与者(例如，终端110B和110C)中的每个参与者发送媒体的单个副本。这对于具有大的N个参与者的会议可以提供对上行链路容量或者带宽、上行链路覆盖和/或终端电池寿命的节省。

在多播会议架构中，发起者终端(例如，图2和3的终端110A)可以使用多种方法建立会议数据会话。例如，发起者终端(例如，图2和3的终端110A)可以在上面讨论的集中式或者分散式架构(例如，100、200、300、400和500)中的一种或多种架构中以及在其它的多播、单源多播和多单播场景中建立会议数据会话。在一些方面中，为了在没有中央焦点或者图1的集中式处理器125的情况下建立会话，发起者终端110A可以邀请其它的参与者(例如，终端110B和110C)加入具有将通过其传递数据流的多播IP地址的多播组。一旦全部参与者加入多播组，则它们全部可以使用多播IP地址发送和从该组接收数据流。发起者终端110A可以选择和分配与强制的和可选的编解码器相关联的多播IP地址(例如，公共的或者受运营商控制的私有IP地址)。如果发起者终端110A希望为具体的数据类型提供对多个编解码器的使用，则发起者终端110A可以为将被使用的编解码器中的每个编解码器建立多播组。此外，可以将这些多播组中的至少一个多播组分配给被全部终端支持的编解码器(即，强制编解码器)。这可以确保全部被邀请的参与者(例如，终端110B和110C)将具有它们可以解码来自其的数据流的至少一个多播组。

如果在多播会议会话的会话建立中涉及了会议焦点或者集中式处理器125(或者下面描述的1325)，则集中式处理器125将传达与上面描述的发起者终端110相同的信息，虽然利用了可能不同的信令方法。例如，集中式处理器125可以发起与N个参与者的对话以建立会议，但与对话相关联的会话描述可以允许经由多播向全部参与者分发数据。由集中式处理器125选择和分配与用于强制的和可选的编解码器中的每项的多播组相关联的多播IP地址(公共的或者私有的)。在一些方面中，由集中式处理器125通过SIP认证机制处置安全性考虑。

在多播会议架构的一些方面中，发起者终端110A不可以获得对是否全部被邀请的参与者(例如，终端110B和110C)准备好了接收数据流的确认。在一些实施例中，可能有可能通过使其它的参与者(例如，终端110B和110C)发回对它们被附着到多播组的确认来解决该问题。例如，终端110B和110C可以通过直接向发起者终端110A发回单播消息或者直接向发起者终端110A和多播组中的每个其他人发回多播消息来进行确认。

在一些实施例中，其它的参与者(不是会议发起者的参与者)不知道是否全部其它的参与者能够经由多播组接收数据流。如果这需要被知道，则其它的参与者(例如，终端110B和110C)可以以多种方式对此作出确定。例如，其可以通过依赖于会议发起者终端110A发送数据流和/或对每个人是处在呼叫中的的口头提及或者使每个被附着到多播组的参与者向多播组发送“谁在这里？”请求并且然后监听来自其它的参与者的响应来确定终端110B和110C中的哪些终端能够经由多播组接收数据流。在一些方面中，查询方参与者除非其接收邀请列表否则可能不知道是否全部被邀请的参与者在场。然而，查询方参与者将至少知道谁在场并且准备好了接收数据流。在一些实施例中，发起者终端110A可以在带外或者在会议建立期间向其它的会议参与者(例如，终端110B和110C)发送邀请列表。

在一些方面中，可以在使用多播会议架构时指定一些额外的数据(例如，媒体)。在一些方面中，在会议焦点或者集中式处理器125缺失时，如果终端支持多于一个强制编解码器并且希望通过一个可选编解码器接收数据流，则如上面描述的，其可以对接收携带可选编解码器的多播组和携带强制编解码器的多播组中的数据流进行注册。如果多于一个强制编解码器被会议发起者(例如，终端110A)提供，则其它的参与者(例如，终端110B和110C)可以使用多种方法对接收数据流进行注册。例如，终端110B和110C可以各自对监听携带来自强制编解码器的数据流的全部多播组进行注册。在一些方面中，在发送数据流时，终端110B和110C可以仅使用强制编解码器中的一个强制编解码器对数据流进行编码，并且可以仅通过对应的多播组发送这些数据流。

在另一个示例中，参与终端110B和110C可以仅必须针对携带来自强制编解码器中的一个强制编解码器的数据流的一个多播组进行注册。在发送数据流时，终端110B和110C可以使用强制编解码器中的全部强制编解码器对数据流进行编码，并且向它们对应的多播组发送数据流。使用强制编解码器中的全部强制编解码器对数据流进行编码可以增加发送方终端的编码负载，而减少接收方终端的解码负载，并且可能是比上面的在其中终端110B和110C使用强制编解码器中的一个强制编解码器对数据流进行编码的第一示例更不可取的(因为编码可能是比解码在计算上更费力的)。

在一些方面中，由于可以总是通过强制的多播组发送数据流，并且全部终端将监听这些组，所以可以不要求任何终端使用可选编解码器和它们的多播组发送数据流。在一些实施例中，甚至会议发起者(例如，终端110A)也不必使用其已经为之建立多播组的可选编解码器发送数据流。然而，终端110A-C仍然可以使用可选编解码器进行编码(如果它们提供更好的质量的话)。

图10是一种示例性多播架构1000的图。示例性多播架构1000包括终端110A-F和终端/媒体网关450。图10示出了示例性会议会话建立和数据流交换。如图10中所示，终端110A通过向终端110B-110F中的每个终端发送邀请消息1001发起多播会议。在一些方面中，邀请消息可以包括上面描述的SIP INVITE消息。在一些实施例中，邀请消息可以包括一个或多个多播组的一个或多个多播IP地址。在图10中，邀请消息可以包括多播组1005的多播IP地址和多播组1050的多播IP地址。在一些方面中，可以将多播组1005分配给被全部终端110A-F支持的编解码器(即，强制编解码器)。如图10中所示，可以将多播组1050分配给被终端110A和110D和终端/媒体网关450支持的编解码器(即，可选编解码器)。

终端110A-D加入或者注册到多播组1005，并且终端110A和110D和终端/媒体网关450加入或者注册到多播组1050。在一些方面中，终端110E和110F可以不是能够执行混合操作的或者不可以支持多播组1005或者多播组1050中的一个多播组的编解码器，并且可以利用终端/媒体网关450来混合经由多播组1005或者1050接收的数据流。如所示的，终端110E和110F通过终端/媒体网关450向多播组1005、多播组1050或者这两者通信。一旦终端110A-F和终端/媒体网关450已经加入(直接地或者通过终端/媒体网关450间接地)多播组1005、多播组1050或者这两者，则终端110A-F和终端/媒体网关450可以(直接地或者通过终端/媒体网关450间接地)发送和/或从分别的多播组接收数据流。

例如，终端110A-D和终端/媒体网关450可以分别向多播组1005发送数据流1011、1012、1013、1014和1015。额外地，终端110A-D和终端/媒体网关450可以从多播组1005接收数据流1020。在一些方面中，数据流1020可以包括来自终端110A-D和终端/媒体网关450中的一项或多项的一个或多个数据流。此外，终端110A、110D和终端/媒体网关450分别向多播组1050发送数据流1031、1032和1033。终端110A和110D和终端/媒体网关450可以从多播组1050接收数据流1036。在一些方面中，数据流1036可以包括来自终端110A-D和终端/媒体网关450中的一项或多项的一个或多个数据流。终端110E可以向终端/媒体网关450发送数据流1041以便终端/媒体网关450向多播组1005和1050中的一个或多个多播组进行发送。类似地，终端110F可以向终端/媒体网关450发送数据流1042以便终端/媒体网关450向多播组1005和1050中的一个或多个多播组进行发送。终端/媒体网关450然后可以对所接收的数据流1020和1036进行处理并且向终端110E发送经混合的数据流1043和/或向终端110F发送经混合的数据流1044。

在一些实施例中，对于被终端监听的每个多播组(例如，多播组1005和1050)，终端(例如，终端110D)可以检查数据流的源(例如，源IP地址)以确定哪些业务是来自同一个参与者的，并且避免解码来自同一个源的数据流的多个版本。终端可以将源信息与从其正在监听的其它的多播组接收的任何数据流进行比较。如果存在数据流表示的重复(例如，来自同一个源的数据流)，则终端可以选择一个编解码器来对数据流进行解码(优选地选择最佳质量的编解码器)。在一些方面中，在对于遍历不同的多播树的分组来说经历了一些损失的情况下，选择可以按照每时间戳地变更。在一些方面中，对解码哪些多播组分组的选择可以是基于终端内的处理器资源分配因子的。例如，多播组1005可以使用与比在1050中的多播数据流中被使用的编解码器低的资源分配因子相对应的编解码器。

一旦选择了数据流，则终端可以对该数据流执行去抖动缓冲，所述去抖动缓冲是关于之前已选择的来自同一个参与者的为该数据类型(但不必然是为同一个编解码器类型)选择的数据流的。去抖动缓冲可以被实现为由在分组交换网络中进行排队引入的计数器抖动。在一些方面中，被馈入去抖动缓冲器的编解码器类型的该切换可能要求在去抖动缓冲器操作中也维护编解码器信息以确保去抖动之后的正确的解码。例如，终端(例如，110A-D和终端/媒体网关450)可能必须为与强制多播组1005数据流相关联的每个参与者以及为潜在地使用可选多播组1050的参与者维护去抖动缓冲器。在一个示例实施例中，终端110A可以维护四个去抖动缓冲器以填充与来自多播组1005的数据流相对应的来自终端110B、110C、110D和终端/媒体网关450的数据，并且额外地为与来自多播组1050的数据流相对应的终端110D和终端/媒体网关450维护另外两个去抖动缓冲器。在一个示例实施例中，终端110A可以暂停为非活跃参与者维护去抖动缓冲器(例如，基于来自给定的参与者的RTP分组长度)，并且稍后在参与者开始发送活跃的帧时创建或者重用去抖动缓冲器。可以处置对去抖动缓冲器的重用以使得来自新的谈话者的第一个活跃的帧分组可以被放置在(被分配给不同的谈话者的)去抖动缓冲器中，第一个活跃的帧分组的分组之后跟随用于解码的非活跃帧，以使得语音解码器记忆过渡被更好地处置。这实现为到来的数据流动态地分配去抖动缓冲器，并且可以减少需要在终端中维护的持久的去抖动缓冲器的数量。

在一些实施例中，监听多播组的终端可以还检查所接收的数据流的源以在终端也在向多播组发送数据流时避免解码其自己的数据流。使用多个编解码器类型并发地发送数据流的终端可以在同一个时间帧边界期间对数据流进行编码并且使用相同的时间戳和/或顺序号，以允许监听多播组的终端识别数据类型的重复的表示。

已经针对3GPP网络中的经由多播的媒体分发识别了一些限制。例如，总体上由移动网络运营商(MNO)为3GPP终端分配私有IP地址，这可以防止跨树的多播跨不同的私有IP地址域。由于3GPP分组数据网络(PDN)网关PGW当前不支持使多播树跨不同的私有IP地址域的能力，所以这将使用多播分发的会议限于同一个运营商的私有IP地址域(即，在其中，私有IP地址分配是唯一的)中的终端。额外地，由于不对跨树的多播的加入进行认证，允许攻击者在任何多播组会议上进行监听，所以3GPP网络中可能存在安全性风险。此外，3GPP网络中可能不存在任何使终端能够为其使用请求对可用的多播IP地址的分配的标准化的机制。

图11是用于多媒体会议中的通信的一种示例性方法1100的流程图。图11中所示的方法1100可以经由图1-5和10中的会议架构100、200、300、400、500和1000中的一个或多个设备来实现。在一些方面中，方法1100可以被与图1-5、10的用户终端110A-F、集中式处理器125和/或终端/媒体网关450类似的设备或者任何其它合适的设备实现。

在方框1105处，终端(例如，图10的终端110A)可以经由第一多播组向两个或更多个设备发送用于建立会议的第一消息。第一消息可以包括第一多播组的第一多播地址和被第一设备支持的第一编解码器类型。在方框1110处，终端使用第一编解码器类型对具有第一多播地址的第一数据流进行处理。

图12是多媒体会议中的编解码器协商的一种示例性方法1200的流程图。图12中所示的方法1200可以经由图1-5和10中的会议架构100、200、300、400、500和1000中的一个或多个设备来实现。在一些方面中，方法1100可以被与图1-5、10的用户终端120A-F、集中式处理器125和/或终端/媒体网关450类似的设备或者任何其它合适的设备实现。

在方框1205处，终端(例如，图10的终端/媒体网关450)可以经由第一多播组从第一设备接收用于建立会议的第一消息。第一消息包括多播组的第一多播地址和被第一设备支持的第一编解码器类型。在方框1210处，终端使用第一编解码器类型对具有第一多播地址的第一数据流进行处理。

在一些方面中，可以通过将简单的焦点(例如，集中式处理器125或者终端/媒体网关450)用于数据处置来缓解上面描述的多播分发的可能的限制。可以被描述为单源多单播的该会议架构配置可以使用集中式处理器125、终端110或者终端/媒体网关450来实质上执行多播路由器的功能，即，复制数据并且将其向下发送给合适的终端。

图13是使用集中式处理器1325的用于多个参与者的一种示例性单源多单播(SSMU)架构1300的图。示例性SSMU架构1300包括终端110A-D和集中式处理器1325。集中式处理器1325可以包括单播单元1305、同播单元1350和控制逻辑1355。单播单元1305可以被配置为接收单播流并且生成包括强制编解码器数据流的副本以便向会议参与者传输。例如，如果终端110A使用基于编解码器协商在会议中被使用的强制编解码器(例如，自适应多速率(AMR)语音编解码器或者H.264视频编解码器)向集中式处理器125发送单播流，则集中式处理器制作或者产生单播流的三个副本并且向终端110B、110C和110D进行发送。同播单元1350可以被配置为接收同播流并且生成包括强制编解码器数据流和可选编解码器数据流中的一项或者全部两项的同播传输。例如，如果终端110A使用强制编解码器(例如，AMR)和可选编解码器(例如，EVS)向集中式处理器1325发送同播流，则取决于终端110B、110C和110D的能力，集中式处理器向终端110B-D发送强制编解码器数据流和可选编解码器数据流中的一项或者全部两项。

控制逻辑1355可以被配置为确定要使用单播单元1305还是同播单元1350来从终端接收数据流以及识别要向终端110A-D发送传输中的哪些传输。在一些方面中，集中式处理器1325可以被配置为实质上执行多播路由器的功能。例如，集中式处理器1325可以被配置为从终端110A-D中的一个终端(例如，终端110A)接收数据流(例如，数据流1310)、复制所接收的数据流以产生一个或多个副本(第一副本、第二副本、第三副本等)并且向会议中的其它的终端(例如，终端110B-D)发送数据流的经复制的副本(例如，数据流1315B-D)。

在单源多单播拓扑1300(例如，图13)中，会议发起者(诸如终端110A)可以向集中式处理器1325发送提供。在特定的实施例中，终端110A在确定提供时考虑其自己的编码/解码能力，并且可以基于其自己的编码/解码能力中的一些或全部编码/解码能力对提供进行配置。这些能力可以包括对于编解码器的具体的组合可以被终端110A执行的并发编码和解码的最大数量。在通过发送应答对提供作出响应之前，集中式处理器1325可以考虑其它的会议参与者——终端110B-D的编码/解码能力，并且可以基于其它的会议参与者中的一些或全部会议参与者的编码/解码能力中的一些或全部编码/解码能力配置对提供的响应。这些能力可以包括对于编解码器的具体的组合可以被每个终端110B-D执行的并发编码和解码的最大数量。

在一些方面中，提供可以包括会话描述协议(SDP)提供消息或者第一消息。在一些方面中，由集中式处理器1325响应于来自终端110A的提供发送的消息可以包括SDP应答消息。

在多单播拓扑1000(例如，图10)中，会议发起者或者终端110A可以在向会议参与者或者终端110B-110F发送提供之前考虑其自己的编码/解码能力，并且可以基于其自己的编码/解码能力中的一些或全部编码/解码能力对提供进行配置。这些能力可以包括对于编解码器的具体的组合可以被终端110A执行的并发编码和解码的最大数量。在一些实现中，终端110A在发送提供之前考虑其它的会议参与者或者终端110B-110F的编码/解码能力，并且可以基于其它的会议参与者中的一些或全部会议参与者的编码/解码能力中的一些或全部编码/解码能力对提供进行配置。这些能力可以包括对于编解码器的具体的组合可以被每个终端110B-110F执行的并发编码和解码的最大数量。

在单源多单播拓扑1300和多单播拓扑1000两者中，可以基于提供和应答交换并发编码/解码能力。

可以使用会话描述协议(SDP)属性(诸如同播属性)来描述并发编码器能力。对于可以被并发地操作的每个编解码器，在发送方向上列出这些编解码器中的每个编解码器的SDP格式令牌(通常与实时传输协议(RTP)有效载荷相对应)，指示它们可以被源同播。

可以使用多个m行来描述并发解码器能力。例如，如果终端110可以接收并且解码多达N-1个AMR-NB或者AMR-WB音频流，则提供将列出N-1个m行，其中，每个m行列出或者AMR-NB或者AMR-WB可以被接收。

如果终端110具有将所接收的媒体流的数量裁剪为其实际解码的媒体流的数量的能力，则终端110可以通告比其实际可以并发地解码的m行多的m行。

如果终端110具有对其可以并发地发送或者接收的RTP流的数量的限制，则终端110可以分别通过限制其在SDP同播属性中列出的编解码器的数量和限制其可以接收的m行的数量来对此作出指示。

表4示出了来自诸如图13中的集中式处理器1325或者来自诸如图10中的会议发起者或者终端110A的一个示例SIP OPTION请求。表5示出了从会议参与者或者终端110B-D去往集中式处理器1325或者会议发起者或者终端110A的一个示例SIP OPTION响应。SIPOPTION响应包括会议参与者的SDP提供。从表5中，会议参与者或者终端110可以允许对音频流的三个并发的编码和三个并发的解码。

为了最小化对于对任何媒体进行转码的需求以及还有实现参与者或者终端110中的对媒体的终端内混合而不超过它们的并发编解码器能力，终端110和集中式处理器1325可以使用并发编解码器能力格式和交换协议。

表4：示例SIP OPTION请求

表5：示例SIP OPTION响应

在一些实施例中，在建立与呼叫参与者(例如，终端110B-D)的单个会话时，集中式处理器1325提供由发起者终端110A在去往集中式处理器1325的第一消息中提供或者预先选择的一个或多个编解码器类型。在一些方面中，被集中式处理器1325提供的编解码器类型可以例如是被会议会话中的全部终端支持的一个或多个强制编解码器类型和被终端110A-D的子集支持的一个或多个可选编解码器类型。进一步地，被提供的编解码器类型对于不同的数据流(例如，音频或者视频)可以是不同的。在一些方面中，集中式处理器1325可以选择仅提供由发起者终端110A提供的一个或多个强制编解码器，这可以保证全部终端110B-D使用这些强制编解码器和可以不需要任何转码。

在一些实施例中，集中式处理器1325还可以选择提供一些可选编解码器以改进会议质量或者性能。为了避免转码和支持对可选编解码器的使用，集中式处理器1325可以对于同一个数据类型作为对应的强制编解码器流的同播提供可选编解码器(例如，希望接收可选编解码器数据流的参与者可以还监听强制编解码器数据流)。例如，如果终端(例如，终端110B)支持H.264(强制编解码器)和H.265(可选编解码器)两者，则集中式处理器1325可以发送包括H.264数据流和H.265数据流的同播传输。类似地，使用可选编解码器H.265发送数据的参与者终端(例如，终端110B)可以还对于该数据类型(例如，音频或者视频)使用强制编解码器H.264同播相同的数据的表示。这是为了以防万一参与者中的一个参与者不能够使用可选编解码器数据流编码或者解码其数据。

在一些实施例中，对于具体的会话，是强制的和可选的的编解码器将取决于所涉及的终端110的能力。在其中存在多于两个可以被用于编码具体的媒体类型的编解码器的情况下，可以存在可选的和强制的编解码器的分层。例如，考虑在其中AMR-NB、AMR-WB和EVS编解码器全部可以被会议中的一些参与者(例如，终端110B-D)使用而其它的参与者可以仅支持AMR-WB+AMR-NB并且又其它的参与者仅支持AMR-NB的情况。如果终端110选择发送仅经AMR-NB编码的内容，则其能够与全部其它的参与者110通信而不需要由集中式处理器1325进行的任何转码。如果终端110选择发送AMR-WB内容，则其必须还发送AMR-NB内容以确保与全部终端110的通信。最后，希望发送EVS的终端110必须还至少发送经AMR-NB编码的内容。然而，为了还最大化其与可以解码AMR-WB的终端110的通信的语音质量，发送EVS的终端110可以还选择发送经AMR-WB编码的内容。

在特定的实施例中，中央处理器1325可以使用SDP指示哪些编解码器是强制的和哪些编解码器是可选的。在一个示例性实施例中，定义新的SDP参数(例如，‘con_recv’)来使用被逗号或者分号分隔的编解码器ID的列表(例如，RTP有效载荷类型‘PT’或者‘RID’的列表)描述编解码器的状态。在一些实施例中，‘con_recv:97,98,99’被用于指示中央处理器1325可以并发地接收三个媒体流，三个媒体流按照递减的偏好的次序被列出(即，97提供最佳质量，之后跟随98和99)，并且最后的ID(‘99’)是必须被任何参与者或者终端110B-D发送的强制流。

在特定的实施例中，多个编解码器可以是可选的和/或多个编解码器可以是强制的。可以通过在编解码器ID的列表中使用一个或多个分隔符项来描述多个编解码器的状态。例如，如果编解码器ID的列表包括每个编解码器之间的相同的分隔符(例如，逗号或者其它合适的分隔符项)，则所列出的编解码器中的每个编解码器是强制编解码器。例如，如果编解码器ID的列表是‘con_recv:97,98,99’，则流97、98和99是强制的。在另一个示例中，如果编解码器ID的列表包括与其它的分隔符项(例如，逗号或者其它合适的分隔符项)不同的一个唯一的分隔符项(例如，分号或者其它合适的分隔符项)，则位于唯一的分隔符项的第一侧的编解码器全部是强制的，而位于相反侧的编解码器全部是可选的，或者反之。例如，如果编解码器ID的列表是‘con_recv:97；98,99’，则流97是可选的，而流98和99是强制的。

在特定的实施例中，定义新的SDP参数(例如，‘mand recv’)来识别强制的流的编解码器ID。在一些实施例中，‘mand recv:99’被用于指示ID(‘99’)是必须被任何参与者或者终端110B-D发送的强制的流。

在特定的实施例中，中央处理器1325使用特殊字符(诸如*或者#字符)将列表中的编解码器ID中的一个编解码器ID明确地标记为强制的，例如，‘同播:recv 97；98；#99’，其中，这个#指示具有ID 99的编解码器必须作为强制的在同播中被发送。

在一个示例实施例中，集中式处理器1325可以被建立为会议焦点，并且终端110A是发起者终端。如图13中所示，终端110A向集中式处理器1325发送数据流1310。数据流1310可以包括一个或多个数据流。例如，数据流1310可以包括强制编解码器数据流和可选编解码器数据流。在一些实施例中，终端110A发送包括强制编解码器数据流和可选编解码器数据流的同播数据流1310，相同的源(例如，相同的视频或者音频数据)的多个表示。在一些方面中，集中式处理器1325接收同播数据流1310，并且集中式处理器1325或者控制逻辑1355可以向支持强制编解码器和可选编解码器两者的终端(例如，终端110B)发送数据流1315B，数据流1315B包括经由使用单播单元1305的单播传输的强制编解码器数据流和经由使用同播单元1350的同播传输的强制编解码器数据流和可选编解码器数据流两者。额外地，集中式处理器1325或者控制逻辑1355可以向仅支持强制编解码器的终端(例如，终端110C)发送包括仅经由使用单播单元1305的单播传输的强制编解码器数据流的数据流1315C。在一些方面中，集中式处理器1325或者控制逻辑1355可以向支持强制编解码器和可选编解码器两者的终端(例如，终端110D)发送包括仅上面讨论的同播传输的数据流1315D。

在一些方面中，在集中式处理器1325与终端110B-D之间的全部单个会话被建立之后，如果不存在或者存在非常有限的数量的可以解码或者编码可选编解码器流的参与者，则集中式处理器1325可以重新协商编解码器以禁用对可选编解码器数据的发送和接收。例如，发起者集中式处理器1325可以与终端110B-D协商以确定每个终端可以支持哪些编解码器(例如，强制的和/或可选的编解码器)。在稍后的时间处(例如，在会议会话期间)，集中式处理器1325可以确定仅发起者终端110A可以支持可选编解码器。相应地，集中式处理器1325可以向发起者终端110A发送消息以重新协商哪些编解码器被会议支持。在一些方面中，集中式处理器1325可以请求发起者终端仅发送强制编解码器数据流并且停止发送可选编解码器。在一些实施例中，集中式处理器1325可以还确定可选编解码器不是正在被足以证明支持可选编解码器是必要的地使用的，或者可以确定为了节省带宽或者等待时间要求，可选编解码器不应当被会议支持。在一些方面中，在重新协商期间，集中式处理器1325可以基于终端的编解码器能力和使用确定额外的或者替换的可选编解码器应当被使用。额外地，在建立会议会话之后，集中式处理器1325可以向终端110B-D发送数据流1315。

在一些方面中，集中式处理器1325可以使终端110的发射机125能够使用更好质量的可选编解码器而不同播利用强制编解码器被编码的媒体，因为这将超过发射机125的并发编码能力。为了实现与可以仅解码强制编解码器的其它终端110的通信，集中式处理器1325必须将媒体从可选编解码器格式转码为强制编解码器格式，并且向可以仅解码强制编解码器的终端110发送该经转码的流。

在一些方面中，集中式处理器1325可以选择混合一些内容以使得一些终端110不必并发地对流进行解码。

RTP流暂停、重用、替换和恢复

图15是用于多个参与者P1-P10的一个示例性单源多单播架构1500的图。单源多单播架构1500使用集中式处理器或者会议焦点1325。集中式处理器1325被配置为通过执行RTP暂停、重用、替换和恢复行动来减小在参与者P1-P10之间被发送的提供的大小。如上面阐述的，表5中示出的SIP OPTION响应包括会议参与者的提供。

如上面阐述的，终端110可以使用SDP参数来与集中式处理器1325暗含地交换(例如，基于多个m行和使用‘同播’参数)并发编码/解码能力。在会议包括大量终端或者参与者P1-P10时，使用上面的参数列出并发编解码器能力(CCC)的提供的大小可以大幅度增长。例如，在解码器侧，所需的SDP行的数量是基于会议终端或者参与者P1-P10的数量和被会议参与者P1-P10中的每个会议参与者支持的编解码器的。由于不同的解码复杂度水平，哪些编解码器可以被并发地操作可以随对编解码器的选择而改变。有可能如果更复杂的解码器中的一个解码器正在被使用，则参与者P1-P10将不能够并发地解码编解码器类型中的全部编解码器类型。每个编解码器类型的不同的解码复杂度的另一个结果在于，被并发地支持的解码器的总数可以随编解码器选择而改变。例如，参与者P1-P10可以是能够并发地解码6个EVS流或者多达10个AMR-NB流的。如果参与者P1-P10具有在使用最不复杂的解码器时解码多达NMAX个流和在使用最复杂的解码器时解码多达NMIN个流的能力，则其将必须描述针对NMIN、NMIN+1、NMIN+2、NMIN+3、……NMAX个被并发地解码的流的单独的替换的媒体流规范。

为了减小会议包括大量参与者P1-P10时的提供的大小，集中式处理器1325可以执行RTP暂停、重用、替换和恢复行动。例如，在提供中，即使呼叫中存在10个参与者P1-P10或者终端110，集中式处理器1325也可以使用仅三个m-音频行(对于a＝发送)。参与者P1直到P10将从集中式处理器1325接收提供，并且利用接受提供的应答作出响应。对于在其中在给定的时间处存在仅一个谈话者(例如，P1)的情况，集中式处理器1325将把来自P1的RTP分组路由到其它的参与者(P2-P10)。对于在给定的时间处两个谈话者正在谈话(例如，P1、P2)或者三个谈话者(例如，P1、P2、P3)谈话时的情况，集中式处理器1325将分组路由到其它的参与者P4-P10。对于谈话者中的一个谈话者(例如，P3)停止并且另一个新的谈话者(P4)发言并且开始谈话时的情况，集中式处理器1325可以暂停与P3相关联的RTP流，并且将同一个RTP流重用于P4谈话者。

然而，如果来自P3的合成记忆被延续到当前的谈话者流P4，则与P4相关联的RTP的开头可以包括不可取的声音和假象。在特定的实施例中，通过集中式处理器1325简单地用一个或多个帧替换将被P4使用的RTP流来减少或者消除这些不可取的声音和假象。在特定的实施例中，一个或多个帧是静默指示符(SID)帧、非连续传输(DTX)帧、一系列SID帧、一系列DTX帧或者关于谈话者P3正在于同一个RTP流内切换到谈话者P4的去往参与者的唯一模式信令。对一个或多个帧的使用改进解码器的刷新其合成记忆的能力。如果合成记忆不被充分地刷新，则不可取的声音和假象可能由于来自之前的谈话者P3的合成记忆被延续到当前的用于P4的谈话者流而出现。在特定的实施例中，在“替换”操作的随后，集中式处理器1325在之前被用于P3的第三RTP指示符内恢复P4的分组传输。

集中式处理器处的媒体类型交换

在特定的实施例中，为了最小化提供中的SDP行的数量，集中式处理器1325可以仅包括特定的编解码器(诸如增强型语音服务(EVS))。对于利用带有它们的较低质量的能力(诸如AMR-WB)的SDP作出应当的参与者，集中式处理器1325可以接受，但可以在向参与者终端110A-D进行发送之前将分组的EVS媒体类型交换为较低质量的AMR-WB。

此外，对于支持EVS和AMR-WB两者的参与者终端110A-D，集中式处理器1325可以替换地取决于信道状况和参与者终端110A-D的并发编解码器能力发送如具有媒体类型AMR-WB或者EVS的AMR-WB RTP分组。

在一些方面中，会议参与者终端110A-D中的每个会议参与者可以对于数据类型使用至少一个强制编解码器对数据进行编码。如果参与者选择使用可选编解码器进行编码，则其可以随同一数据类型的强制编解码器数据流一起同播该可选编解码器数据流。在对数据流进行同播时，发送方终端110可以对于相同的源内容的不同的表示使用相同的RTP时间戳和顺序号。

在一些实施例中，单源多单播架构1300可以提供特定的非限制性的超过其它的分散式会议架构的好处。在一个非限制性的示例中，发送数据的终端(例如，终端110A)仅必须向集中式处理器1325发送每个经编码的分组的一个副本，最小化上行链路带宽。额外地，被发送到集中式处理器1325和从集中式处理器1325被发送的单播业务可以穿过为MNO的私有IP地址域提供服务的网络地址转换器(NAT)盒，因此使会议能够跨多个私有IP地址域。此外，在被提供了合适的凭证和密钥的情况下，集中式处理器1325可以对尝试收听会议和向会议发送数据的用户进行认证。在一些方面中，可以不需要预留或者被分配用于会议的多播IP地址。使用在运营商的网络中被支持的标准分配协议(例如，动态主机配置协议(DHCP))为集中式处理器1325分配其自己的唯一的(可能私有的)IP地址。在一些方面中，集中式处理器1325不必执行任何转码，仅执行对数据业务的复制。这不仅是在计算上较不昂贵的，由于集中式处理器1325不必对数据进行解码以便复制和向全部终端发送它，所以这将还允许被发送数据业务被端到端地加密。

在一个示例实施例中，被终端(例如，终端110A)发送的同播数据流可以包括使用1)强制编解码器和可选编解码器或者2)以两个不同的比特率使用仅强制编解码器或者3)使用具有嵌入式层间预测的可伸缩编码来编码或者代表同一个源的两个或更多个流。例如，终端(例如，终端110A)可以使用强制编解码器(例如，AMR)和可选编解码器(例如，EVS)两者对语音帧进行编码，并且生成用于向集中式处理器1325传输的同播数据流。在接收同播数据流时，集中式处理器1325可以识别同播数据，并且基于终端110B-D的解码能力发送强制和可选编解码器数据流中的一个或者全部两个数据流。

在另一个实施例中，在终端110B正在接收可选编解码器数据流并且已经决定切换到接收仅强制编解码器数据流时，则必须由终端110B向集中式处理器1325信号通知从接收可选编解码器到强制编解码器的过渡。在数据流切换发生时，终端110B必须是能够通过对经解码的数据流的后处理(例如，在从超宽带过渡到宽带或者窄带时的带宽补偿，以使得不存在任何引起感知的认为现象的信号带宽的突然变更)来处置任何编解码器记忆重置或者无缝过渡的。

在另一个示例实施例中，终端(例如，110A)可以以不同的比特率(例如，13.2kbps和24.4kpbs)或者带宽(例如，SWB或者WB)使用相同的编解码器(例如，EVS)对语音帧进行编码，并且生成用于向集中式处理器1325传输的同播数据流。集中式处理器1325可以识别同播数据，并且发送数据流中的一个或者全部两个数据流以在帧擦除的情况下提供信道冗余；或者允许集中式处理器1325决定在不进行转码的情况下要向终端发送哪个流。这样，在一些方面中，集中式处理器1325可以向具有充足的网络带宽的终端发送较高比特率数据流，并且向处在拥塞状态下的终端发送较低比特率数据流。

在另一个示例实施例中，终端(例如，终端110A)可以以渐增的质量使用可伸缩编码来对输入信号进行编码，并且生成用于向集中式处理器1325传输的同播数据流。在接收具有嵌入式可伸缩编码的同播数据流时，集中式处理器1325可以基于在先的经协商的带宽/比特率或者基于提供信道状况的网络反馈决定需要被发送给终端中的每个终端的层的数量。可伸缩编码可以是使用H.265的视频编码(其具有基本层编码，基本层编码具有改进质量的额外的层)或者使用32kbps作为基线编码的ITU-T G.718语音编解码器(其中每个4kbps改进质量和错误恢复力)。

图14是用于多媒体会议中的通信的一种示例性方法1400的流程图。图14中所示的方法1400可以经由图1-5、10和13中的会议架构100、200、300、400、500、1000、1300中的一个或多个设备来实现。在一些方面中，方法1400可以被与图1-5、10、13的用户终端110A-F、集中式处理器125、1325和/或终端/媒体网关450类似的设备或者任何其它合适的设备实现。

在方框1405处，集中式处理器(例如，图13的集中式处理器1325)可以从第一设备接收用于建立会议的第一消息，第一消息包括用于在会议中使用的编解码器类型列表。在方框1410处，集中式处理器1325可以在第二设备处向第三设备发送第二消息，第二消息提供来自编解码器类型列表的一个或多个编解码器类型。在方框1415处，集中式处理器1325可以在第二设备处对具有来自一个或多个编解码器类型的第一编解码器类型的第一数据流进行处理。

上面描述的方法的各种操作可以被任何能够执行所述操作的合适单元(诸如各种硬件和/或软件组件、电路和/或模块)执行。总体上，任何在附图中被说明的操作可以被对应的能够执行所述操作的功能单元执行。例如，用于向两个或更多个设备发送第一或者提供消息的单元可以包括终端110A-D的发射机125或者天线135。额外地，用于接收第二或者响应消息的单元可以包括终端110A-D的接收机120或者天线135。额外地，用于确定是否两个或更多个设备可以继续参与会议的单元可以包括用户终端110A-D的处理器115。进一步地，用于从设备接收第一或者提供消息的单元可以包括终端110A-D的接收机120或者天线135。此外，用于发送第二或者响应消息的单元可以包括终端110A-D的发射机125或者天线135。

可以使用多种不同的技术和工艺中的任一种技术和工艺来代表信息和信号。例如，可以由电压、电流、电磁波、磁场或者粒子、光场或者粒子或者其任意组合来代表可以贯穿上面的描述内容被引用的数据、指令、命令、信息、信号、比特、符号和码片。

结合本文中公开的实施例描述的各种说明性的逻辑方框、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或者这两者的组合。为了清晰地说明硬件与软件的该可互换性，已经在上面总体上按照它们的功能描述了各种说明性的部件、方框、模块、电路和步骤。这样的功能被实现为硬件还是软件取决于具体的应用和被强加于总体系统的设计约束。可以针对每个具体的应用以不同的方式实现所描述的功能，但这样的实现决策不应当被解释为使脱离本发明的实施例的范围。

结合本文中公开的实施例描述的各种说明性的方框、模块和电路可以利用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑设备、分立的门或者晶体管逻辑、分立的硬件部件或者被设计为执行本文中描述的功能的其任意组合来实现或者执行。通用处理器可以是微处理器，但替换地，处理器可以是任何常规的处理器、控制器、微控制器或者状态机。处理器还可以被实现为计算设备的组合，例如，DSP与微处理器的组合、多个微处理器、结合DSP核的一个或多个微处理器或者任何其它这样的配置。

结合本文中公开的实施例描述的方法或者算法的步骤和功能可以直接地用硬件、用被处理器执行的软件模块或者用这两者的组合来体现。如果用软件来实现，则功能可以作为有形的非暂时性计算机可读介质上的一个或多个指令或者代码被存储或者发送。软件模块可以驻留在随机存取存储器(RAM)、闪存、只读存储器(ROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)、寄存器、硬盘、可移除磁盘、CD ROM或者本领域中已知的任何其它形式的存储介质中。将存储介质耦合到处理器以使得处理器可以从存储介质读信息和向存储介质写信息。替换地，存储介质可以是处理器的构成部分。如本文中使用的磁盘和光盘包括压缩盘(CD)、激光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光盘，其中，磁盘通常磁性地复制数据，而光盘利用激光在光学上复制数据。以上各项的组合也应当被包括在计算机可读介质的范围内。处理器和存储介质可以驻留在ASIC中。

出于概述本公开内容的目的，已经在本文中描述了本发明的特定的方面、优点和新颖特征。应当理解，不必可以根据本发明的任何具体的实施例达到全部这样的优点。因此，可以以使得达到或者最优化如本文中教导的一个优点或者优点的组而不必达到如可以在本文中被教导或者建议的其它的优点的方式来体现或者实现本发明。

对上面描述的实施例的各种修改将是显而易见的，并且本文中定义的一般原理可以被应用于其它的实施例，而不脱离本发明的精神或者范围。因此，本发明不旨在限于本文中所示的实施例，而将符合与本文中公开的原理和新颖特征一致的最宽范围。