用于在多媒体通信中使用压缩并行编解码器的方法和装置与流程

本公开内容涉及编解码器协商领域，具体地说，本公开内容涉及分散式多媒体会议和通信中的压缩并行编解码器协商。
背景技术：
：能够将数字视频和音频能力并入到各种各样的设备中，其包括数字电视、数字直接广播系统、无线广播系统、个人数字助理(pda)、膝上型计算机或桌面型计算机、数码相机、数字记录装置、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或卫星无线电话、视频电话会议设备等等。数字视频和音频设备实现视频和音频压缩技术，例如，由运动图像专家组2(mpeg-2)、mpeg-4、国际电报联盟电信标准化部门(itu-t)h.263、itu-th.264/mpeg-4、第10部分所规定的标准、高级视频编码(avc)、高效率视频编码(hevc)标准、以及这些标准的扩展里所描述的那些技术。视频和音频设备可以通过实现这些视频和音频编码技术，来更有效地发送、接收、编码、解码和/或存储数字视频和音频信息。诸如可伸缩hevc(shvc)和多视角hevc(mv-hevc)的视频和音频编码标准提供用于定义解码器能力的层级(level)定义。在下文中，基于在进行发明时shvc的现有层级定义和其他上下文来描述问题和解决方案，但这些解决方案也适用于mv-hevc以及其它多层编解码器。技术实现要素：落入所附权利要求的保护范围内的系统、方法和设备的各种实施方式各具有一些方面，这些方面中没有单个方面单独地对本文描述的所期望的属性负责。在不限制所附权利要求的保护范围的情况下，本文描述了一些突出的特征。在附图和下文的描述中，阐述了本说明书中描述的主题的一个或多个实施方式的细节。通过这些描述、附图和权利要求，其它特征、方面和优点将变得显而易见。应当注意，附图中的相对尺寸可能没有按比例进行描绘。在一个方面中，公开了一种用于多方之间进行通信的方法。该方法包括：在第一设备处，生成第一消息以向第二设备传输。该方法还包括：在该第一设备处，接收第二消息以建立会议。该第二消息包括该第二设备支持的一个或多个并行编解码器能力的列表。该第二设备支持的一个或多个并行编解码器能力的该列表包括如下指示：可用于第一列出的编解码器的一个或多个并行实例的一个或多个资源，是否可以替代地用于第二列出的编解码器的一个或多个并行实例。本公开内容的另一方面是一种用于发起采用多个编解码器的多方、多流会议的装置。该装置包括处理器和接收机。该处理器被配置为生成第一消息以向第一设备传输。该接收机被配置为，从该第一设备接收第二消息以建立会议。该第二消息包括该第一设备支持的一个或多个并行编解码器能力的列表。该第一设备支持的一个或多个并行编解码器能力的该列表包括如下指示：可用于第一列出的编解码器的一个或多个并行实例的一个或多个资源，是否可以替代地用于第二列出的编解码器的一个或多个并行实例。本公开内容的另一方面是一种用于发起采用多个编解码器的多方、多流会议的装置。该装置包括：用于生成第一消息以向第一设备传输的单元以及用于从该第一设备接收第二消息以建立会议的单元。该第二消息包括该第一设备支持的一个或多个并行编解码器能力的列表。该第一设备支持的一个或多个并行编解码器能力的该列表包括如下指示：可用于第一列出的编解码器的一个或多个并行实例的一个或多个资源，是否可以替代地用于第二列出的编解码器的一个或多个并行实例。本公开内容的额外的方面是一种包括指令的非暂时性计算机可读介质，当执行该指令时，该指令使处理器执行方法。该方法包括：在第一设备处，生成第一消息以向第二设备传输。该方法还包括：在该第一设备处，接收第二消息以建立会议。该第二消息包括该第二设备支持的一个或多个并行编解码器能力的列表，其中，该第二设备支持的一个或多个并行编解码器能力的该列表包括如下指示：可用于第一列出的编解码器的一个或多个并行实例的一个或多个资源，是否可以替代地用于第二列出的编解码器的一个或多个并行实例。附图说明图1示出了用于多个参与方的会议架构的示例。图2示出了用于多个参与方的分散式会议架构的示例。图3示出了用于多个参与方的分散式会议架构的另一示例。图4示出了在终端用作混合器的情况下，用于多个参与方的混合会议架构的示例。图5示出了在终端用作混合器和参与方的情况下，用于多个参与方的混合会议架构的示例。图6是用于会议中的编解码器协商的另一示例性方法的流程图。图7是用于使用压缩并行编解码器以发起会议会话的示例性方法的流程图。图8是用于使用压缩并行编解码器以发起会议会话的示例性方法的另一流程图。具体实施方式下面结合附图阐述的具体实施方式旨在作为对本发明的某些实施方式的描述，而不是要表示可以实践本发明的唯一实施方式。遍及本描述所使用的术语“示例性”意味着“用作示例、实例或说明”，并且不应被解释为对于其它示例性实施方式是优选的或有优势的。具体实施方式包括出于提供对所公开的实施方式的透彻理解目的的具体细节。在一些实例中，以方块图的形式示出了一些设备。视频编码标准包括itu-th.261、iso/iecmpeg-1视频、itu-th.262或iso/iecmpeg-2视频、itu-th.263、iso/iecmpeg-4视频和itu-th.264(其还称为iso/iecmpeg-4avc)，包括其可伸缩视频编码(svc)扩展和多视角视频编码(mvc)扩展。此外，itu-t视频编码专家组(vceg)的视频编码联合协作小组(jct-vc)和iso/iecmpeg已经开发一种视频编码标准，即高效率视频编码(hevc)。针对hevc草案10的全文引用是bross等人于2013年1月14日至2013年1月23日在瑞士日内瓦的itu-t视频编码联合协作小组(jct-vc)sg16wp3和iso/iecjtc1/sc29/wg11，第12次会议上的题为“highefficiencyvideocoding(hevc)textspecificationdraft10”的文档jctvc-l1003。此外，jvc-3v(itu-t/iso/iec三维视频编码扩展开发联合协作小组)和jct-vc也分别正在开发hevc多视角扩展，即mv-hevc，和hevc可伸缩扩展，即shvc。mv-hevc的最新工作草案(wd)将在下文中称为mv-hevcwd7。shvc的最新wd将在下文称为shvcwd5。层级定义的现有方法有时不能提供足够的信息以定义解码器能力来高效解码多层比特流。例如，为了对多于4个的各具有720p分辨率的信噪比(snr)可伸缩层(具有等同分辨率的层)进行解码，将需要层级5解码器或者更高层级的解码器。因此，亮度编码树块(ctb)大小将等于32x32或64x64(即，不能使用诸如16x16的更小的编码大小)。但是，对于一些层，例如具有720p或更低的分辨率的那些层，这种限制可能导致次优的编码效率。在一些实例中，可以通过重用多个现有的单层解码器来制造解码器。在示例中，由4个单层hevc层级3.1解码器组成的shvc解码器将必须符合层级4或者更高层级，以根据现有的层级定义来解码720p的4个snr层。通过该定义，解码器将必须能够对任何层级4比特流进行解码。然而，除非对解码器硬件进行改变，否则这样的解码器将不能解码具有1080p分辨率的2个snr层的shvc层级4比特流。现有hevc层级定义的另一问题是，以能够解码1080p的单层hevc比特流和720p的双层shvc比特流两者的方式实现的解码器将被标记为层级3.1。但是，层级3.1标记并不表示对1080p的单层比特流进行解码的能力。在另一示例中，对于根据现有的层级定义，能够对720p的4个snr层进行解码的使用4个单层hevc3.1解码器实现的解码器来说，该解码器将必须符合层级4或者更高层级。因此，将需要解码器能够对具有多于3个并联(tile)行和多于3个并联(tile)列的比特流进行解码，每个并联具有256个亮度样本的宽度和144个亮度样本的高度。但是，解码器的层级3.1限制将不能对一些这样的比特流进行解码。在shvc的现有设计下，将hevc文本的a.4.1节中的所有项目指定为适用于每个层。但是，一些项目不能直接适用于每个层。例如，针对解码图像缓冲区(dpb)大小上的项目d，序列参数集(sps)语法元素不适用于增强层。此外，shvcwd5中的dpb是共享子dpb设计，因此不能直接将项目d应用于每个层。作为另一示例，针对编码图像缓冲区(cpb)大小上的项目h和i，针对比特流特定的cpb操作，不能将参数应用于每个层。需要对cpb大小(按照hevc文本的a.4.1节中的项目h和i)进行比特流特定的限制。然而，不能将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)mpeg1视频、itu-th.262或iso/iecmpeg-2视频、itu-th.263、iso/iecmpeg4视频和itu-th.264(其还称为iso/iecmpeg-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、宏块等等)、切片(slice)、帧等的任何适当的视频单元来使用。视频编码标准诸如视频图像、tv图像、静止图像或者由视频记录器或计算机生成的图像的数字图像，可以由以水平和垂直线排列的像素或样本组成。单个图像中的像素数量通常为数万。每个像素通常包含亮度和色度信息。在不压缩的情况下，要从图像编码器传送到图像解码器的全量的信息将使得实时图像传输变得不可能。为了减少要发送的信息量，已经开发了许多不同的压缩方法，例如jpeg、mpeg和h.263标准。视频编码标准包括本文先前所描述的那些。多流多方会议在一些实施例中，在多流多方会议中，期望支持多流视频、至少两个视频内容(例如，一个主要内容和一个演示内容)、多流音频、至少2个音频内容、以及其它额外的能力。在一些方面中，中央处理器或者网桥可以用于支持这些功能。中央处理器或网桥可以接收多流视频/音频数据、对视频/音频数据进行混合并将混合后的数据流发送给参与方中每一个参与方。图1是用于多个参与方的示例性会议架构100的图。会议架构100包括终端110a-d和中央处理器125。在一些方面中，中央处理器125可以包括服务器或者会议网桥提供器。中央处理器125可以从终端110a-d中的每一个终端接收数据流、解码、混合并向终端110a-d发送混合后的数据流。在一些方面中，中央处理器125可以使用多播传输来发送混合后的数据流。在一些实施例中，数据流可以包括一个或多个音频、视频和/或媒体流。在一些方面中，终端110a-d各可以包括处理器、接收机、发射机、收发机、天线、存储器、数据库和用户接口中的一者或多者。在一些实施例中，可能期望建立不具有中央处理器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可能对于其能够并行操作的解码器实例的数量具有计算限制。这限制了能够与终端进行会议的参与方的数量，或者要求终端具有优先解码某些数据流并忽略其它数据流的能力。例如，如果终端没有忽略其接收的任何数据流，则参与方的数量必须小于或等于解码器的最大数量加1(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考虑会议中的每个参与终端能够并行运行的解码器的最大数量，并能够确保参与方的数量不超过各解码器最大数量中的最小值加1。类似地，采用终端内混合的会议可能需要终端对发送给其它参与终端的多个数据流进行并行编码。当发起方针对数据类型提供多于一种类型的编解码器，并且其它参与方选择使用不同的编解码器时，就可能发生这种情形。在一些方面中，数据类型可以包括音频类型、视频类型或者其它媒体类型。在图1和图2中描述的集中式或分散式会议架构中，在向参与会议的一个或多个终端传送会话描述协议(sdp)要约(offer)消息之前，中央处理器或发起方终端(取决于架构的类型)可以经由sdp前的协商阶段，确定将什么信息包括在sdp要约消息中。在该协商阶段期间，中央处理器或发起方终端可以请求形成适用的会议架构的其它终端的编码和解码能力。可以在离散的协商消息中传送针对其它终端的编码和解码能力的请求。协商消息可以被配置为包括发送终端或者处理器的能力的信息，以及关于将作为会议的一部分传送的一个或多个媒体流的信息。在一些实施例中，协商消息可以用作并行编解码器能力交换(cccex)。在一些实施例中，要约消息和应答消息也可以用作cccex，如本文所描述的。因此，可以将协商消息实现为包括，关于发送设备的编码和解码能力的属性和/或鉴于会议中可能涉及的媒体流的编码和解码要求。可以将这些能力和需求信息中的大部分信息包括在终端和中央处理器之间传输的sdp要约消息和响应消息中。但是，通过在传送sdp要约消息和响应消息之前执行能力的协商或者交换，可以对sdp要约消息和响应消息进行精简和简化，以只包括对于在会议架构的设备之间建立会议有用的信息。对于会议发起方能够建立不超过任何一个参与方的并行编码和解码能力的会议而言，先前的通信和能力交换也是必需的。因此，被传送以交换并行编解码器能力的协商消息可以包括sdp要约消息和响应消息将包括的信息中的至少一些信息。协商消息可以被配置为包括级联形式的必要的sdp要约信息和响应信息，使得可以有效地在终端和/或处理器之间传送协商消息，并且不会对网络和/或处理资源造成压力。例如，在协商消息中，可以可选地包括各种参数，同时它们可以始终保持在sdp要约消息和响应消息中。在一些实施例中，协商消息可以在单行消息中，传送包括在sdp要约消息和响应消息中的超过40行信息。在一些实施例中，本文描述的协商消息可以是作为请求一个或多个终端提供它们的并行编解码器能力的协商请求消息发送的。在一些实施例中，本文描述的协商消息可以是作为响应于协商请求消息的协商响应消息发送的。在一些实施例中，协商请求消息可以包括发送请求的终端或处理器的能力。在一些实施例中，协商响应消息可以包括与请求终端或处理器的能力有关的响应终端或处理器的能力，或者独立于请求终端或处理器的能力的响应终端或处理器的能力。在一些实施例中，协商消息，作为请求消息或者作为响应消息，可以包括编解码器能力的列表的指示，如本文更详细描述的。例如，可以将从发起方终端传送的协商消息规定为包括如下所述的期望的属性和/或信息。应当注意，下面是协商消息结构的增强型backus-naur形式(abnf)表示：因此，上面的abnf代码对应于如何可以生成包括并行编解码器能力信息的协商消息以进行传送。协商消息可以包括发送消息的实体能够使用的编解码器的列表(例如，由发送消息的实体支持的编解码器的列表)。在一些实施例中，发送协商消息(作为响应或者请求)的任何实体能够接收相应的协商(请求或者响应)消息。为了减少与sdp要约消息和响应消息有关的协商消息的大小，可以在协商消息中排除或者调整各种参数和/或信息。例如，在一些实施例中，可以将能够标识视频编解码器分辨率的编解码器层级参数可选地包括在协商消息中，因为不是所有编解码器都可以包括编解码器层级和/或编解码器层级信息。类似地，可以可选地包括各种其它参数，因此与sdp要约消息和响应消息相比，协商消息能够在大小上减小。此外，协商消息可以被配置为指示一个或多个编解码器可以何时或者如何由其它编解码器替代(例如，用于一个或多个编解码器的资源可以替代地由其它编解码器使用)。例如，协商消息可以指示中央终端能够经由多个编解码器对通信进行解码。例如，中央终端可以指示其能够解码增强型语音服务(evs)、自适应多速率(amr)和自适应多速率宽带(amr-wb)，同时指示根据需要，在处理器上运行的evs的实例可以由amr-wb的实例替代，amr-wb的实例可以由amr的实例替代。额外地，协商消息还可以被配置为要求与<codec>实例的数量相同的<num>实例(如本文的消息定义中所示出的)。在一些实施例中，尽管一个或多个参数被包括在sdp要约消息和/或响应消息中，但是可以从协商消息中排除该一个或多个参数。在一些实施例中，如上面的协商消息定义中指示的，<codec>项对应于如在实时协议(rtp)有效载荷格式中针对编解码器规定的该编解码器的媒体类型名称。在一些实施例中，<codec>项的示例可以分别地包括对应于h.264视频压缩编解码器的“video/h264”和/或对应于h.265视频压缩编解码器的“video/h265”。由<codec>项标识的编解码器可以对应于发送协商消息的终端或处理器被配置为用于对媒体流进行编码和/或解码的编解码器。协商消息可以包括由<codec>项标识的一个或多个编解码器；例如，如<codec>项标识的编解码器，本文示出的协商消息#1包括evs、amr和arm-wb。如上所述，<level>项是可选的。<level>项可以指定编解码器的层级，该层级针对视频编解码器标识支持什么分辨率。例如，当<codec>项指示h.264或h.265编解码器时，<level>项可以分别等于level_idc或者level-id。当<codec>项指示evs编解码器时，<level>项可以等于1、2、3和/或4，它们分别指定窄带(nb)、wb、超宽带(swb)和全频段(fb)。额外地，<profile>项在协商消息中也是可选的。<profile>项可以指定编解码器的简档(profile)，该简档针对视频编解码器标识视频编码器使用什么标准化的工具。例如，针对<codec>项指示的编解码器h.264和h.265，<profile>项可以分别指示或者等于profile_idc和profile-id。如果在协商消息中包括<profile>项，则也必须包括<level>项。另一方面，准许协商消息在不包括<profile>项的情况下，包括<level>项。协商消息的<rule>项可以指定用于编解码器的并行实例的资源是否可以替代地由在该编解码器之前或者之后列出的编解码器的并行实例使用。例如，在本文描述的协商消息#1中，<codec>项标识amr、amr-wb和evs编解码器(但不必以该顺序)。基于<rule>项，下一个列出的编解码器可以是计算复杂度更低的，并因此可以与先前列出的编解码器在相同的处理器上运行。例如，当<rule>项等于“，”时，则<codec>项的一个或多个实例可以由接下来的一个或多个列出的编解码器替代。但是，<rule>项还可以指示下一个列出的编解码器是计算复杂度更大的，或者是在单独的处理器上实现的，并因此不能与先前列出的编解码器在相同的处理器上运行。例如，当<rule>项等于“；”时，则<codec>项的一个或多个实例可能不由下一个列出的编解码器替代。因此，<rule>项可以被配置为向接收协商消息的终端和/或处理器显示解码处理器比编码处理器更灵活。在本文的协商消息#1中示出的<num>项可以指定所支持的并行编码器或并行解码器的最大数量。例如，当<num>项在协商消息中跟着文本“enc”时，<num>项指示所支持的由<codec>项(当存在时，在指定的层级和简档处)指定的编解码器中的每一个编解码器的并行编码器的最大数量。类似地，当<num>项在协商消息中跟着文本“dec”时，<num>项指示由<codec>项(当存在时，在指定的层级和简档处)指定的编解码器的所支持的并行解码器的最大数量。由紧跟着文本“enc”的<num>项标识的实例数量，以及由紧跟着文本“dec”的<num>项标识的实例的数量两者都应当与由<codec>项标识的实例的数量相同。此外，在一些实施例中，可以以相同的顺序，将由<num>项标识的实例映射到由<codec>项标识的实例上。在一些实施例中，终端和/或处理器可以具有修剪其实际解码的接收到的媒体流的数量(m行)的能力。因此，终端和/或处理器可以通告具有指示以下内容的值的<num>项：与终端和/或处理器实际具有的进行解码的并行解码能力相比，该终端和/或处理器能够解码更大数量的媒体流。根据本文的描述，协商消息可以在单个sdp行中，提供由终端和/或处理器支持的并行编解码器能力(其包括编码器能力和解码器能力两者)的通信和/或协商。例如，下面的表1描述了典型的sdp要约消息。该sdp要约消息可以对应于被配置成msmtsi终端的发起方终端的配置“a”，如结合表2描述的。表1如上所示，sdp要约消息包括超过40个sdp行。这些sdp行中的大部分sdp行可以包括在本文描述的协商消息中包括的信息。但是，虽然这些行可以包括sdp要约消息中的将近40个单独的sdp行，但本文描述的协商消息可以将这40行减少到单个行。这种可扩展sdp要约消息的减少，降低了每一个终端和/或处理器进行接收、处理以及对于sdp要约消息和响应消息进行响应本该需要的通信和计算资源的数量。例如，本文描述的协商消息将上面的表1中的以“**”偏移的sdp要约消息行(等于38个sdp行)减少到单个行的协商消息#1：协商消息#1a＝codec_list:evs；amr-wb；amr:enc:1；1；1:dec:3,1,1此外，当在协商消息中进行传送时，下面的表2中示出的针对配置“b”和“c”的sdp要约消息也可以进行类似地减少。例如，用于下面的组合“b”的sdp要约消息的42个sdp行，可以通过协商消息#2的单个sdp行来替代：协商消息#2a＝codec_list:evs；amr-wb；amr:enc:1；1；0:dec:4,1,0类似地，下面的组合“c”的sdp要约消息的44个sdp行，可以通过协商消息#3的单个sdp行来替代：协商消息#3a＝codec_list:evs；amr-wb；amr:enc:1；0；0:dec:5,0,0表2：msmtsi终端中的示例性并行编解码器能力配置因此，总之，使用如本文描述的协商消息可以在三个sdp行中传送124个sdp行，同时维持具有六个参与方的cccex(如表2中所述)，其等于通信开销的大于41：1的减少。因此，使用本文描述的协商消息，通常可以根据下面的压缩比来减少sdp行。压缩比1≥(5*(n-2)+4):1,其中·n是并行解码器(例如，用户)的数量；以及·m是支持并行解码器的编解码器的组合的数量。因此，可以提供显著的通信和处理开销和资源的节省。在一些实施例中，为了进一步减少通信和计算资源，终端可以被配置为在对接收到的流进行解码之前，“修剪”接收到的流的数量。修剪可以涉及减少将被解码的接收到的流的数量并且修剪可以节省终端处的解码计算资源。这种“修剪”能力可以通过以下方式来指示：终端通过列出与该终端能够并行解码的媒体流相比更多的媒体流(例如，m行)来广播sdp要约。因此，该终端可以被配置为生成新的压缩sdp属性以包括上至12个或更多个并行解码器，从而将压缩比增加到≥54:1。在一些实施例中，如本文进一步描述的，一旦如上所述地交换了协商消息，则终端或处理器中的一个或多个终端或处理器就可以生成和传送一个或多个要约消息和/或数据流，以传送给一个或多个其它终端或设备。在一些实施例中，可以使用编解码器能力的列表的指示以选择用于通信的编解码器的类型，如本文更详细描述的。例如，协商响应消息可以指示终端被配置为处理哪个编解码器，并且处理器(或者发起方终端)可以基于协商响应消息的指示来选择编解码器类型。在一些实施例中，可以将针对任何给定处理器或终端的编解码器能力的列表的指示符或指示存储在数据库或其它存储位置，和/或可以从数据库或其它存储位置获取针对任何给定处理器或终端的编解码器能力的列表的指示符或指示。在一些实施例中，会议支持的编解码器能力的列表可以是至少部分地基于两个或更多个设备中的每一个设备支持的编解码器能力的列表的指示。图3示出了用于多个参与方的分散式会议架构300的另一示例。在一些实施例中，发起方终端110a可以向终端110b和110c要约提供(offer)多个编解码器。可以在使用上面描述的协商消息的协商完成之后传送这些要约(offer)。例如，如图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和110c选择amr-wb，因为终端110b不支持evs。如从图3能够看到的，终端110a和110c必须在evs和amr-wb格式两者中并行地编码其内容，而终端110b只需要在amr-wb格式中进行编码/解码。图4是在终端/媒体网关450用作混合器的情况下，用于多个参与方的示例性混合会议架构400的图。如图4中所示，终端110a-c各可以向终端/媒体网关450发送数据流，该终端/媒体网关450随后向终端110a-c发送多个数据流。例如，终端/媒体网关450可以从终端110b和110c接收数据流，对这些数据流进行解码并将这些数据流发送给终端110a。在一些方面中，终端/媒体网关450可以对来自终端110b和110c的数据流进行混合，向终端110a发送混合后的数据流。在一个实施方式中，终端110a可以基于某些限制或者会议参数来调整该终端110a从终端/媒体网关450接收的数据流的数量。例如，终端110a可以使用终端/媒体网关450(或者图1的中央处理器125)处理能力以减少或者卸载其自己的处理，或者确保会议架构(无论集中式、分散式还是混合的)限制内的高效通信。在一个方面中，终端110a可以请求终端/媒体网关450只发送一个混合后的数据流，因为终端110a可能仅能够解码一个数据流，或者因为终端110a具有有限的处理能力。额外地，可能的是，图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可以切换到作为终端/媒体网关450进行操作，如图4(和下面的图5)中描述的。在一些方面中，终端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还可以通过采用上面描述的针对终端110b和终端/媒体网关450的refer方法，结合对终端110d和110e的带外通信来发起会议，以使这些终端经由终端/媒体网关450加入会议。在其它方面中，终端110a可以通过宣告会议的开始的轮询消息来发起该会议，并且终端110b和110d-110e和终端/媒体网关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能够各对三个数据流进行解码。在一些方面中，与终端110d和110e相比，可以将终端110a和110b认为是新型的或者更高效的终端。在一些方面中，与终端110a和110b相比，可以将终端110d和110e认为是传统的或者更旧的设备。在一个实施例中，终端/媒体网关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确定所有终端都已经进行了切换，以减少潜在的中断或者延时问题。在一些实施例中，在要提供的信息的粒度以及用于指示能够支持更多并行操作的能力的功能(ability)之间，可能存在某种平衡。可能存在下面的场景或者设备：供应商或运营商希望传送关于能够支持的并行会话的细节信息，例如，为多方会议专门设计的高端商业终端。另一方面，可能存在没有被设计为在会话中支持多于3-4个参与方的中端或者低端终端，对于这些终端供应商或运营商只希望暴露非常基本的功能。由于要传送的信息的合适的量可能取决于场景和设备，因此可能期望适应不同的情况。不是选择上面描述的格式中的一种格式，而是在一些方面中，终端(例如，终端110a-e或者终端/媒体网关450)可以能够选择所描述的格式中的任何格式。必须从会议参与方接收所有编解码器能力信息的发起方终端(例如，终端110a)，应当能够对所有格式进行解码和理解。满足针对编解码器能力信息的上面格式要求的一个示例是传送每一个数据类型(例如，音频或视频)或者每一个编解码器的并行实现的最大数量。每数据类型的限制例如，能够如下地规定新的会话级sdp属性：a＝max_dec_audio:<num_instances>a＝max_dec_video:<num_instances>a＝max_enc_audio:<num_instances>a＝max_enc_video:<num_instances>在一些方面中，<num_instances>是位于包括性的1到16的范围内的整数，其指定由终端支持的该数据类型(例如，针对第一和第三的音频，或者针对第二和第四的视频)的并行解码器(针对前两个)或者编码器(针对后两个)的最大数量。或者，能够如下地规定新的数据级sdp属性：a＝max_dec:<num_instances>a＝max_enc:<num_instances>在一些方面中，<num_instances>是位于包括性的1到16的范围内的整数，其指定由终端支持的(在“m＝”行上的最后项的)数据类型的并行解码器的最大数量(针对a＝max_dec)或者并行编码器的最大数量(针对a＝max_enc)。在一些实施例中，这种示例性解决方案可能不能满足上面描述的对编解码器能力信息的格式要求。在一些方面中，可以通过最计算密集的编解码器来约束并行实例的最大数量。在示例性实施例中，针对其中终端支持h.265编解码器并宣称其能够支持多达两个视频编码器事件(h.264和h.265)且知道其必须针对这两个视频编码器预留足够的资源的视频电话会话，终端可能在其能够处理的数据(例如，视频或语音)的解码器实例的数量上受限制。在一些方面中，对于解码器实例的数量的限制，可能阻止终端被包括在具有更大数量的使用较不复杂解码器的参与方的会议中，或者阻止会议中的所有参与方在该会话中使用更高级的可选的编解码器。每编解码器类型的限制额外地，能够如下地规定新的sdp参数：a＝max_dec:<codec><num_instances>a＝max_enc:<codec><num_instances>在一些方面中，<codec>是如针对编解码器的rtp有效载荷格式中规定的该编解码器的数据类型名称，例如分别地，如ietfrfc6184中规定的用于h.264的“video/h.264”(在https://tools.ietf.org/html/rfc6184可获得)，以及如h.265rtp有效载荷格式中规定的用于h.265的“video/h.265”(其最新版本位于：https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14)。在一些方面中，<num_instances>是位于包括性的1到16的范围内的整数，其指定：指定的编解码器的并行解码器的最大数量(针对a＝max_dec)或者并行编码器的最大数量(针对a＝max_eec)。在其它实施方式中，为了考虑不同层级的视频编解码器可能具有不同的能力，能够如下地规定新的数据级sdp属性：a＝max_dec:<codec><level><num_instances>[<profile>]a＝max_enc:<codec><level><num_instances>[<profile>]在一些方面中，<codec>与上面的相同。在一些方面中，<level>指定编解码器的层级，例如，针对h.264和h.265，该值分别等于如itu-th.264规范中规定的level_idc和如h.265rtp有效载荷格式(其最新版本位于：https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14)中规定的level-id，并且当编解码器是evs时，该字段的值为1、2、3和4分别指定nb、wb、swb和fb。在一些方面中，<num_instances>是位于包括性的1到16的范围内的整数，其指定：在指定的层级和简档(当存在时)处的指定的编解码器的并行解码器的最大数量(针对a＝max_dec)或者并行编码器的最大数量(针对a＝max_enc)。在一些方面中，<profile>是可选的，其指定编解码器的简档，例如，针对h.264和h.265，该值分别等于如itu-th.264规范中规定的profile-idc和如h.265rtp有效载荷格式(其最新版本位于：https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14)中规定的profile-id。在一些实施例中，对于所有上面的替代方案，针对<num_instances>也可以允许0的值，值0指定终端能够对数据流进行挑选和修剪。在一些方面中，能够对数据流进行挑选和修剪的终端能够处理无限数量的数据流。在其它实施方式中，用于视频编解码器的另一替代方案可以是要规定新的sdp属性，如下所述：a＝max_vdec_cap:<codec><max_block_ps>a＝max_venc_cap:<codec><max_block_ps>在一些方面中，<codec>与如上所述的相同。在一些方面中，<max_block_ps>指定：指定的视频编解码器的所有并行视频解码器能够处理的每秒8x8亮度块的最大数量(针对a＝max_vdec_cap)或者所有并行编码器能够处理的每秒8x8亮度块的最大数量(针对a＝max_venc_cap)。在一些实施例中，该示例性解决方案可能不满足上面描述的针对编解码器能力信息的格式要求。在一些方面中，可能不清楚的是，当存在编解码器的混合时，会议发起方终端(例如，图2-5的终端110a)如何能够准确地确定能够支持多少并行编码器和解码器。在一些实施例中，用于估计能够支持多少并行编码器和解码器的方式，是使用正在使用的计算最为繁重的编解码器的编码器/解码器限制。在一些方面中，编码器/解码器限制可以通过最复杂编解码器来约束，该最复杂编解码器可以限制终端能够处理的数据(例如，视频或语音)的解码器实例的数量。例如，在一些方面中，对解码器实例的数量的限制，可能阻止终端被包括在具有更大数量的使用较不复杂解码器的参与方的会议中，或者可以阻止会议中的所有参与方在该会话中使用更高级的可选的编解码器。满足上面的针对编解码器能力信息的格式要求的另一示例，是描述针对每个编码/解码功能可用的或者分配的处理器资源的百分比。这允许发起方终端混合并匹配编解码器(包括不同数据类型的那些编解码器)以及它们的编码器和解码器，只要其保持总复杂度负荷不大于给定处理器中的所分配资源的100％。描述上面的信息的一种方式，可以是引入两个新的sdp属性：a＝enc_use:<codec><alloc_factor><proc_idx>a＝dec_use:<codec><alloc_factor><proc_idx>其中，<alloc_factor>的范围从0到1.0，并且描述当使用具有处理器索引<proc_idx>的处理器以进行编码(针对a＝enc_use)或者解码(针对a＝dec_use)时，用于指定的编解码器的资源分配因子。在其它实施例中，描述上面的信息的另一方式可以是引入两个新的sdp属性：a＝enc_use:<codec><level><alloc_factor><proc_idx>[<profile>]a＝dec_use:<codec><level><alloc_factor><proc_idx>[<profile>]在一些方面中，<codec>、<level>和<profile>与如上所述的相同。在一些方面中，<alloc_factor>的范围从0到1.0，并且描述当使用具有处理器索引<proc_idx>的处理器以进行编码(针对a＝enc_use)或者解码(针对a＝dec_use)时，用于指定的层级处的指定的编解码器的资源分配因子。在一些实施例中，发起方终端可以使用上面的来自每个参与方的信息以确保所提议的会议不超过参与方的并行编解码器能力中的任何并行编解码器能力。能够如下面的表3来将信息概念化：表3列出编解码器的并行编解码器组合简档满足上面的用于编解码器能力信息的格式要求的另一示例性解决方案，是列出终端能够同时处理的编解码器操作的所有组合。这可以具有不需要传送由每个编解码器功能消耗的处理器负载的优点。下面的表4给出了基于在先前部分中描述的处理器负载因子的所支持的简档的非详尽列表。例如，处理器负载因子可以包括上面参照表3描述的资源分配因子。在一些方面中，终端对于编解码器类型或者数据类型的选择可以是基于处理器负载因子或者资源分配因子的。在一些实施例中，(在增强型backus-naur形式(abnf)中)规定了两个新的sdp属性：a＝enc_list和a＝dec_list，如下所述：在一些方面，num指定列表的条目中的指定的层级和简档(当存在时)处的指定的编解码器的所支持的并行编码器的最大数量(针对a＝enc_list)或者并行解码器的最大数量(针对a＝enc_list)。在一些方面中，上面的列表的条目中给定的codec、level和profile分别与<codec>、<level>和<profile>具有相同的语义。替代地，可以在abnf中规定新的sdp属性，如下所述：在一些方面中，num指定列表的条目中的指定的层级和简档(当存在时)处的指定的编解码器的所支持的并行编码器(当function＝“enc”时)或者并行解码器(当function＝“dec”时)的最大数量。在一些实施例中，上面给定的codec、level和profile分别与<codec>、<level>和<profile>具有相同的语义。在其它实施例中，可以在abnf中规定新的sdp属性，如下所述：在一些方面中，上面给定的codec、level和profile分别与<codec>、<level>和<profile>具有相同的语义。在一些方面中，num指定在指定的层级和简档(当存在时)处的指定的编解码器的所支持的并行编码器(当“combination”跟随“enc”时)或者并行解码器(当“combination”跟随“dec”时)的最大数量。在一些方面中，codec_idx指定在指定的层级和简档(当存在时)处的指定的编解码器的列表编解码器列表的索引。在一些实施例中，可以将num规定为num＝％d0-16。除了上面的描述和等式之外，值0指定该终端能够对数据流进行挑选和修剪。在一些方面中，能够对数据流进行挑选和修剪的终端能够处理无限数量的数据流。在其它实施例中，在上面的替代方案中，其中，num位于包括性的1到16的范围内，如下地规定一个或多个新的sdp属性：a＝stream_trimming在一些方面中，该属性的存在指定该终端能够对数据流进行挑选和修剪。在一些方面，能够对数据流进行挑选和修剪的终端可以处理无限数量的数据流。组合中的num的值仍然指定特定的编解码器、简档和层级实际支持的并行编码器或并行解码器的最大数量。在该情况下，终端能够接收任意数量的数据流，并且能够将数据流修剪成针对每个编解码器/简档/层级组合的a＝codec_list属性允许的数量。在一些方面中，可能存在多个编解码器组合，其随着所支持的编解码器的数量增加而指数地增加。这能够增加消息大小，例如，sdp/sip。例如，能够通过应用诸如以复杂度的降序来列出编解码器功能的额外的规则来实现信令的某种减少。随后，应当理解，如果更高复杂度的编解码器功能的实例的数量减少一个，则相同处理器上的较不复杂的编解码器功能中的一个功能的实例能够增加至少一个。虽然在一些方面中，当实例数量减少的编解码器处理比其它编解码器处理更复杂时，这可能给出次最优的限制，但其可以允许省略多个简档。在一些方面中，如果终端需要生成与完全分辨率图像进行联播的缩略图，则相同视频编解码器的并行操作可能是必需的。表4所支持的并行编解码器组合的简档表4中列出的简档不能很好地应用于需要使用相同编解码器的视频联播的使用情形(即，低和高分辨率图像)，因为在一个时间只支持一个编码器。这可能是处理器负载而不是简档方案本身的限制。在一些实施例中，表4中的简档a到d能够被认为是以不允许使用evs为代价来使用h.265的“hdvideo”简档。虽然简档a到c可以处理四个h.264流的解码，但它们可能不能用于典型的多点单播(multi-unicast)视频会议，因为它们可能只能够对一个视频流进行编码。在一些方面中，该终端的用户可能希望只向其它参与方中的一个参与方发送视频，例如，用于传送符号语言的视频侧栏对话。除了简单的两方视频会话之外，简档a到d可能更适用于多播或者“基于聚焦的多播(focused-basedmulticast)”会议，其中已知所有终端都支持h.265编解码器。应当注意，如果amr-nb是用于正在提供的服务的强制性编解码器，则简档c可以认为是无效的，因为不支持amr-nb解码。在一些方面中，简档f能够被认为是要用于只有语音的会议中的“hdvoiceonly”简档。由于还要识别需要使用相同的编码器来同时编码语音的使用情形，所以只有语音的简档可以只需要考虑并行操作每个语音编码器的一个实例。这可以简化针对只有语音的会议需要列出的简档的数量，并且简档f呈现为是仅有的相关的只有语音的简档，因为支持多于13个参与方的会议是不可能的，并且非常可能超过终端的rtp流处理限制(下面将进一步描述)。针对在不需要解码所有接收到的媒体流的情况下，对接收到的媒体流执行修剪或者减少的终端而言(如下面进一步描述的)，如以下表5中所示，能够将解码器功能的实例的数量指示为“无限(infinity)”。表5示出了针对能够向下修剪到三个接收到的音频数据流的终端的示例性实施例：表5如上面参照图1-5描述的，接收终端或者设备(例如，终端110b、终端/媒体网关450等)能够对特定的数据流进行优先化和忽略，以减少其必须并行操作/解码的解码器实例的数量。如果终端采用这种“修剪”算法，并能够限制其必须解码的数据流的数量以匹配其并行解码能力，则该终端不需要会议发起方基于该终端的解码能力来限制呼叫中的参与方的数量。在该情况下，终端能够指示与这些数据流相对应的0的资源分配因子，如下面的表6的示例中所示：表6rtp流处理限制支持并行解码很多数据流的能力，使得解码可能不是设置会议的大小的限制因素成为可能。终端的协议栈能够处理的实时传输协议(rtp)数据流的数量变成限制因素。因此，传送该信息也可能是有益的。此外，能够规定两个新的会话级sdp属性，以指定对并行rtp栈的数量的限制：a＝rtp_tx_limit:<rtp_instances>a＝rtp_rx_limit:<rtp_instances>在一些方面中，<rtp_instances>是位于包括性的1到32的范围内的整数，其指定所支持的并行rtp会话的最大数量。在一些方面中，会议发起方终端(例如，图2-5的终端110a)使用来自于会议中的每个参与方的上述信息以确保提议的会议不超过参与方的编解码器或rtp处理能力。在一些实施例中，发起方终端可以基于其并行编解码器能力以及预先知道其并行能力的其它参与方的并行编解码器能力来发送要约消息。在接收到该要约消息之后，每个参与方的终端可以检查要约消息以确定n和所要约提供的编解码器的最大数量，以确定其是否能够满足在先前部分中描述的约束。如果终端能够参与，则其可以用经选择的编解码器进行响应。在另一实施例中，其它参与终端(例如，终端110b和110c)也能够在响应消息中，包括它们的并行编解码器能力。这允许发起方终端存储并保证针对相同的发起方终端发起的任何未来的会议恰当地考虑了终端的能力。在一些方面中，发起方终端可以将这些能力存储在数据库中。如果参与终端确定其不能够参与，则其在响应消息中指示该情况，并发送其并行编解码器能力。随后，发起方终端可以对来自其它参与终端的响应进行处理，如下所述：(1)如果发起方终端未接收到否定响应，则其允许会议继续；(2)如果发起方终端接收到否定响应，则其使用所有接收到的并行编解码器能力来构建可行的要约消息，并在新的消息(例如，sipre-invite/update消息)中向参与方中的一些参与方或全部参与方发送该可行的要约消息。在一些实施例中，每个终端可以将其地址簿或者数据库中的每一个终端的并行编解码器能力简档进行存储。该简档能够包括针对每个终端的每种数据类型的maxenc和maxdec。在其它方面中，该简档能够包括针对所有数据类型的终端的编解码器的列表，以及编解码器的每个实例使用的资源分配因子或者处理器复杂度的百分比。例如，下面的表7示出了针对所有数据类型的终端的编解码器的示例性列表，以及编解码器的每个实例使用的处理器复杂度的百分比。表7数据类型编解码器名称编码器复杂度解码器复杂度音频amr-nb10％2％音频amr-wb20％4％音频evs60％20％视频h.264/avc60％15％视频h.265/hevc90％23％在一些方面中，发起方终端能够随后使用每个参与方的上面简档以确定在使用本文描述的约束考虑的情况下每个参与方都能够满足的要约消息。在传送它们的并行编解码器能力时，终端还能够指示它们能够处理更多数据流的接收，因为它们能够对特定数据类型的数据流进行优先化和忽略。例如，终端110a可以指示其能够并行地解码多达三个evs数据流(每个使用其处理器的20％)，之后，其将会忽略接收到的任何额外的数据流。在一些方面中，终端还能够在发起会议之前，交换并行编解码器能力信息，以更好地保证将可行的要约消息包括在第一个发起消息(例如，第一个sipinvite)中。能够如下所述地执行这种并行编解码器能力信息的交换：当用户向终端上的其地址簿或者目录增加另一用户时，地址簿应用进行彼此联系以交换并行编解码器能力以及任何其它个人信息(家庭地址等)，或者当终端的编解码器能力发生改变时(经由下载或者终端硬件的交换)。能够使用在用户之间提供的任意联系信息标识符(id)，来执行信息/简档的这种交换。例如，如果id是电子邮件地址，则经由电子邮件交换中的嵌入的简档多目的互联网邮件扩展(mime)类型；如果id是电话号码，则经由通过短消息服务(sms)发送的可扩展标示语言(xml)方案；经由某种其它消息发送协议发送的xml方案。能够以多种方式来更新简档信息。例如，用户彼此之间或者经由先前描述的协议进行呼叫，来建立采用终端内混合的会议，即，能够在响应中发送并行编解码器能力。在另一示例中，存储该简档的终端可以设置定时器，以自主地和定期地(例如，每月)检查其它用户的终端，以查看能力是否发生了改变。因为用户的软件更新或者软件下载或者改变了他们的手持装置，所以这些能力可能发生改变。在一些方面中，每当已经提供简档的终端自身的能力发生变化时，其可以更新其地址簿中的所有用户。替代地，当会议中的两个或更多个参与方(它们不是发起方)在其之间建立数据会话时，该会议中的两个或更多个参与方能够交换其并行编解码器能力。在一些方面中，能够使用options请求以通过如下方式来查询另一终端的编解码器能力：要求终端发送用于描述终端的编解码器能力的终端将要约提供的会话描述协议(sdp)的副本。该sdp将包含如上所述的并行编解码器能力信息。能够在会议呼叫的很长时间之前来进行options请求，并且可以将sdp响应存储在用于受查询的终端的简档中。在一些实施例中，在紧邻建立会议之前，会议发起方能够查询其计划邀请的、会议发起方对其没有预先存储的信息的所有终端的编解码器能力。图6是用于会议中的编解码器协商的另一示例性方法的流程图。图10中所示出的方法600可以经由会议架构100、200、300和/或400中的一个或多个设备来实现。在一些方面中，方法可以由类似于图1-4中的用户终端110a-d和/或中央处理器125的设备或者任何其它适当的设备来实现。在方块605处，终端或者处理器可以向两个或更多个设备发送请求消息，该请求消息请求两个或更多个设备中的每一个设备支持的编解码器能力的列表。消息可以包括终端或者处理器支持的编解码器能力的列表的指示。在一些方面中，消息可以是基于发起方终端或者处理器的并行编解码器能力的。在一些实施例中，消息还可以是基于预先知道其并行能力的其它参与方的编解码器能力的。在方块610处，终端从两个或更多个设备中的每一个设备接收响应消息，该响应消息包括两个或更多个设备中的每一个设备支持的编解码器能力的列表的指示。在一些方面中，在接收到响应之后，终端或处理器可以对接收到的消息进行处理，以确定多个参与方的编解码器能力的经过指示的列表。在一些实施例中，可以使用压缩cccspd要约和应答，在多流多方会议媒体处理(mmcmh)会话建立中类似地减少sdp参数。本文描述的压缩cccsdp参数的abnf定义可以应用于针对mmcmh会话建立的压缩cccex和ccc两者。但是，虽然使用针对cccex的压缩ccc允许将ccc压缩到单个sdp行，但使用压缩ccc进行mmcmh会话发起可能会受到以下内容的限制：针对sdp要约的需要是要符合sdp要约/应答模型或期望的。例如，在mmcmh会话建立中，sdp要约可以包含足够的媒体行，以允许sdp应答选择终端(例如，要约方(offeror)终端和应答终端)支持的编解码器配置的任意组合。例如，在要约中必须存在至少r个媒体行，其中r是要约方终端能够并行地接收和解码的最大数量的流。如本文演示的，能够执行针对mmcmh会话建立的压缩cccsdp要约参数。在一些实施方式中，要约方终端(例如，寻求创建mmcmh会话的终端)可以获得三种音频编解码器(amr-nb、amr-wb和evs)。“a”对应于并行amr-nb编解码器的最大数量，而“b”对应于并行amr-wb编解码器的最大数量，并且“c”对应于并行evs编解码器的最大数量，其中由于a、b和c的相对复杂性，因此a>＝b>＝c。因此，当生成要约消息时，要约方终端可以列出总共a个媒体行，其中这a个媒体行中的每一个媒体行包括amr-np作为编解码器。类似地，要约方终端可以列出总共b个媒体行，其中b个媒体行将包括amr-wb作为编解码器，接收到与amr-nb的联播。额外地，要约方终端可以列出将包括evs作为编解码器的总共c个媒体行，接收到与amr-wb和amr-nb两者的联播。当指示要约方终端的发送/编码能力时，上面的媒体行中的一个或多个媒体行还可以在联播发送配置中包括所有编解码器。上面的a个媒体行可以覆盖能够在sdp应答中进行选择的所有可能的媒体配置。为了对于选择一个或多个可接受配置的要约进行响应，应答终端可以在依赖于也包括在该要约中的压缩cccsdp行的情况下，传送其应答。如本文所描述的，不使用压缩cccsdp行的sdp要约可以包括以下媒体行的集合以传送基本相同的信息：·“a”个媒体行，其指示支持最大数量的可解码流时的配置。这可以对应于使用压缩ccc，除了在联播接收配置中将至少存在具有两个编解码器的b个媒体行和具有三个编解码器的c个媒体行。这些额外的编解码器中的每一个编解码器将在媒体行中增加两个更多的sdp行；及·用于能够支持并行解码的流的不同数量和集合的每个配置的媒体行集合。例如，如果要约方终端支持单个evs解码器，则要约方终端将amr-nb流的最大数量从a减少到要约消息中的a1evs。额外地，要约消息可以包括列出多个amr-nb编解码器的a1evs+1个接收媒体行的单独集合以及一个包含evs编解码器的行。此外，当未使用压缩cccsdp行时，媒体行集合中的每一个将需要不同的媒体配置，如在mediacapneg框架中指定的。在下面的表中，示出了当未使用压缩cccsdp参数时，可以传送的不同的配置集合的示例。该表包括针对n＝6的三个配置(a、b和c)。但是，针对n的不同值可能存在不同的配置集合，其中n是会议中的参与方的数量，包括要约方终端和所有应答终端。表8但是，通过实现具有要约消息和应答消息的压缩cccsdp参数，可以避免列出除了a个媒体行之外的任何配置，并因此可以避免使用mediacapneg框架。通过实现具有mmcmh会话建立的压缩cccsdp参数所节省的sdp行的数量，可以取决于每一个编解码器之间的相对复杂度。相对复杂度的变化越大，非压缩cccsdp参数要约中将会需要的媒体行的集合就越多，因为将一个编解码器实例替换为另一个编解码器实例可能对并行解码器的数量具有更大的影响。例如，假定编解码器c的复杂度是编解码器b的复杂度的两倍，编解码器b的复杂度是编解码器a的复杂度的两倍，并且其中编解码器a代表能够运行的最简单编解码器的实例的最大数量。当针对要约消息使用压缩cccsdp参数时，在sdp要约消息中将只有a个媒体行的一个集合，该要约消息将包含以下数量的sdp行：·用于公共sdp方面的7行·用于包括编解码器a的a个媒体行中的每一个媒体行的2行·用于包括编解码器b的b个媒体行中的每一个媒体行的2行·用于包括编解码器c的c个媒体行中的每一个媒体行的2行·用于压缩cccsdp参数的1行因此，针对sdp要约消息，将存在总共8+2a+2b+2c＝8+2a+a+0.5a＝8+3.5a个sdp行。但是，当针对要约消息未使用压缩cccsdp参数时，可能存在以下媒体行的集合：扩展上面的模式，能够看到，当未使用压缩cccsdp参数时，指示所有的可能配置所需要的sdp行的总数量是a(1+2+3+…a/4)x(2a+mi)，其中mi是针对独立于a的特定媒体行集合的常数。至少，上面的下限是媒体行的数量至少为0.25a4+a3。因此，在sdp要约中使用压缩cccsdp格式的增益，以近似(0.25a4+a3)/(3.5a+8)～＝0.0714a3+0.286a2的因子减少sdp要约中的sdp行的数量。因此，对于a＝4，存在5.81的压缩增益因子；对于a＝8，存在42.67的压缩增益因子；对于a＝16，存在320的压缩增益因子。这表明减少sdp要约的大小获得的压缩增益可能是巨大的，特别是对于具有支持大量的不同计算复杂度的并行编解码器的能力的要约方终端。在一些实施例中，如本文描述的使用压缩cccsdp参数来压缩sdp要约中的媒体行的数量，可能需要将应答方终端配置为理解压缩cccsdp参数，使得应答方终端知道不是所有的在压缩cccsdp要约中描述的媒体配置都被支持。如果应答方终端不理解压缩cccsdp参数，则其可能不恰当地选择要约方终端不支持的并行编解码器的集合。因此，只要要约方使用压缩cccsdp参数以及a个媒体行的单个媒体配置，则要约方终端可以知道应答方终端能够恰当地理解压缩cccsdp参数。例如，要约方终端可能先前已经使用任何方法(例如，option方法)查询了应答方终端的ccc，并接收到包括压缩cccsdp参数的响应，要约方终端以此为基础来记录应答方终端理解压缩ccc格式，并当发起mmcmh会话时，能够使用该格式。替代地，要约方终端可以防止未理解压缩ccc格式的应答方终端选择不支持的配置。例如，要约方终端能够通过定义针对ccc的新标签来完成该目标，该标签填充在sipinvite(邀请)的require报头以及主体中的压缩cccsdp参数中。如果应答方终端理解ccc标签，则其相应地将对invite进行响应。如果应答方终端不理解ccc标签，则其将拒绝invite，并且要约方终端将必须发送不具有该ccc的并且具有所有相关联的媒体行配置的更详细要约的re-invite。在一些实施例中，要约方终端可以向一个或多个应答方终端发送压缩cccsdp要约参数。压缩cccsdp要约参数可以包括要约方终端支持的一个或多个ccc。要约方终端可以随后从一个或多个应答方终端中的至少一个应答方终端接收到响应。响应可以包括：对要约方终端支持且该至少一个应答方终端也支持的一个ccc的选择。基于该响应，要约方终端可以向该至少一个应答方终端发送数据流。图7是用于使用压缩并行编解码器以发起会议会话的示例性方法700的流程图。图7中示出的方法700可以经由会议架构100、200、300和/或400中的一个或多个设备来实现。在一些方面中，方法700可以由类似于图1-4中的用户终端110a-d和/或中央处理器125的设备或者任何其它适当的设备来实现。在方块705处，终端或者处理器可以向一个或多个设备发送要约消息以建立会议。要约消息可以包括会议支持的并行编解码器能力的列表的指示。在一些方面中，消息可以是基于发起方终端或者处理器的并行编解码器能力的。在一些实施例中，消息还可以是基于预先知道其并行能力的其它参与方的编解码器能力的。在方块710处，终端从一个或多个设备接收应答消息。应答消息可以包括从并行编解码器能力的列表的指示中进行的选择。在方块715处，终端基于应答消息，向一个或多个设备选择性地发送数据流。图8是用于使用压缩并行编解码器来发起会议会话的示例性方法800的另一流程图。图8中示出的方法800可以经由会议架构100、200、300和/或400中的一个或多个设备来实现。在一些方面中，方法800可以由类似于图1-4中的用户终端110a-d和/或中央处理器125的设备或者任何其它适当的设备来实现。在方块805处，第一设备的终端或者处理器可以生成第一消息以向第二设备传输。第一消息可以包括要约消息或者请求消息。第一消息可以包括终端或者处理器支持的并行编解码器能力的列表的指示，或者可以请求第二设备支持的并行编解码器能力的列表的指示。在一些实施例中，通过用于生成第一消息以向第二设备传输的单元可以生成第一消息。在一些实施例中，用于生成第一消息的单元可以包括，会议架构100、200、300和/或400中的一个或多个设备。在一些方面中，用于生成第一消息的单元，可以由类似于图1-4中的用户终端110a-d和/或中央处理器125的设备或者任何其它适当的设备来实现。在方块810处，终端接收第二消息以在终端和第二设备之间建立会议。第二消息可以包括第二设备支持的一个或多个并行编解码器能力的列表。第二设备支持的一个或多个并行编解码器能力的列表可以包括如下指示：可用于第一列出的编解码器的一个或多个并行实例的一个或多个资源，是否可以替代地用于第二列出的编解码器的一个或多个并行实例。在一些实施例中，通过用于接收第二消息以在终端和第二设备之间建立会议的单元可以接收第二消息。在一些实施例中，用于接收第二消息的单元可以包括：会议架构100、200、300和/或400中的一个或多个设备。在一些方面中，用于生成第一消息的单元，可以由类似于图1-4中的用户终端110a-d和/或中央处理器125的设备或者任何其它适当的设备来实现。在一些实施例中，第二消息可以包括第二设备响应于要约消息而发送的响应消息。在一些实施例中，第二消息可以包括应答消息。上面描述的方法的各种操作，可以由能够执行这些操作的任何适当的单元来执行，例如，各种硬件和/或软件组件、电路和/或模块。通常，在附图中示出的任何操作，可以由能够执行这些操作的相应功能单元来执行。例如，用于向两个或更多个设备发送要约消息的单元，可以包括终端110a-d的发射机或天线。额外地，用于接收响应消息的单元，可以包括终端110a-d的接收机或天线。额外地，用于确定两个或更多个设备是否可以继续参与会议的单元，可以包括用户终端110a-d的处理器。此外，用于从设备接收要约消息的单元，可以包括终端110a-d的接收机或天线。此外，用于发送响应消息的单元，可以包括终端110a-d的发射机或天线。信息和信号可以使用多种不同的技术和技艺中的任意一种来表示。例如，遍及上面的描述可能提及的数据、指令、命令、信息、信号、比特、符号和码片可以由电压、电流、电磁波、磁场或磁粒子、光场或光粒子或者其任意组合来表示。结合本文公开的实施例描述的各种示例性逻辑方块、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或二者的组合。为了清楚地表示硬件和软件之间的这种可交换性，上文已经以其功能的用语总体描述了各种示例性的组件、方块、模块、电路和步骤。这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束。可以针对每个特定应用，以不同的方式实现所描述的功能，但是，这种实现决策不应当解释为导致偏离本发明的实施例的范围。利用被设计为执行本文所述功能的通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或其它可编程逻辑器件、分立门或者晶体管逻辑、分立硬件组件或者其任意组合，可以实现或执行结合本文公开的实施例描述的各种示例性方块、模块和电路。通用处理器可以是微处理器，但是在替代方案中，处理器可以是任何传统处理器、控制器、微控制器或者状态机。处理器还可以实现为计算设备的组合，例如，dsp和微处理器的组合、多个微处理器、一个或多个微处理器与dsp内核的结合，或者任何其它此种配置。结合本文所公开的实施例描述的方法或者算法的步骤和功能可直接体现为硬件、由处理器执行的软件模块或二者的组合。当利用软件实现时，可以将这些功能存储在有形、非暂时性计算机可读介质上，或者作为有形、非暂时性计算机可读介质上的一个或多个指令或代码进行传输。软件模块可以位于随机存取存储器(ram)、闪存、只读存储器(rom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)、寄存器、硬盘、移动硬盘、cdrom、或者本领域已知的任何其它形式的存储介质。存储介质耦合到处理器，使得处理器能够从存储介质读取信息，以及向存储介质写入信息。在替代方案中，可以将存储介质整合到处理器。如本文使用的，磁盘和光盘包括压缩光盘(cd)、激光光盘、光盘、数字通用光盘(dvd)、软盘和和蓝光光盘，其中磁盘通常磁性地复制数据，而光盘则利用激光来光学地复制数据。上面的组合也应当包括在计算机可读介质的范围之内。处理器和存储介质可以位于asic中。出于概括本公开内容的目的，本文已经描述了本发明的某些方面、优点和新颖特征。应当理解的是，根据本发明的任何特定实施例不一定可以获得所有这些优点。因此，本发明可以以实现或者优化如本文所教导的一个优点或者一组优点的方式来体现或者执行，而不必实现如本文可能教导或者建议的其它优点。对上面所描述的实施例的各种修改将是显而易见的，并且，本文定义的总体原理可以在不脱离本发明的精神或保护范围的情况下适用于其它实施例。因此，本发明并不是要限于本文所示出的实施例，而是要符合与本文所公开的原理和新颖特征的相一致的最广范围。当前第1页12