CN111164946A - 用于适配互联网协议语音通信会话的请求的信令 - Google Patents

Abstract

本发明涉及一种用于从接收器设备向发送器设备用信号通知用于适配实时通信会话的实时信号的编码/解码的适配请求的方法。该方法为使得：该适配请求涉及对帧的聚合和/或冗余的需求，该适配请求是根据从该通信会话的初始化期间的所使用的10个编解码器的协商阶段产生的信令参数的存在而生成的，并且该适配请求是经由RTP类型的实时协议来传输的。本发明还涉及一种实施所描述的方法的接收器设备以及一种包括该设备的终端。

Description

用于适配互联网协议语音通信会话的请求的信令

技术领域

本发明涉及电信领域，并且更具体地涉及分组通信网络领域。在这种类型的网络中，可以传送与实时服务相关联的数据流。

由IETF(表示互联网工程任务组)开发的互联网协议(IP)在分组通信网络中实施，以支持非实时服务(诸如数据传输服务、网站浏览服务和电子消息传递服务)和实时或会话服务(诸如IP电话、IP视频电话或者甚至IP视频流式传输)两者。

本发明更具体地涉及适配请求的信令，该适配请求请求两个通信终端之间的实时通信会话期间的实时信号(诸如语音信号或视频信号)的编码/解码的适配。

背景技术

参照图1描述了现有IP语音通信系统的示例。该图展示了双向IP语音(VoIP)通信系统，该系统具有通过IP分组网络(125)连接的两个电话终端(100和150)。该图中未示出“信令平面”；然而，用于建立和管理呼叫的可能解决方案可以基于各种已知的协议，诸如：

·根据IETF规范RFC 3261和RFC 4566的SIP/SDP(表示会话发起协议/会话描述协议)，如在IMS(表示IP多媒体子系统)多媒体服务中。为了促进关于媒体容量和相关联提议/应答的信令交换，也可以使用根据IETF规范RFC 5939的“SDPcapneg”。

·JSEP(表示JavaScript会话建立协议)，其使用SDP语法来定义WebRTC会话描述(经由WebSocket或其他方式进行交换)。

·H.323/H.245。

图1是在建立呼叫时使用的“媒体平面”和音频链的简化视图。这里，仅考虑单声道音频信号的情况，环境声学信号例如在通信的每一端由麦克风(101和151)捕获。应当注意，单声道输入/输出信号的情况可以容易地推广到多声道情况。

远程信号经由扬声器(102和152)呈现。所捕获和呈现的音频信号在被发送和接收时通常经历各种声学处理操作(103和153)，例如：

·在发送时，经历模拟/数字转换、增益控制、降噪、回声消除等

·在接收时，经历数字/模拟转换、增益控制等。

在发送时，经预处理的音频信号被编码成连续的帧(典型地具有10ms到60ms范围内的(通常固定的)帧长度)并且经编码的帧被形成为IP分组(104和154)。这些分组典型地使用IETF规范RFC 3550中描述的RTP协议(RTP代表实时协议)进行传输，该协议位于IP/UDP(表示用户数据报协议)传输协议之上。应当注意，可以用另一种传输协议来代替UDP协议，例如用TCP(表示传输控制协议)来代替，以便特别地促进通过具有NAT(表示网络地址转换)、代理或防火墙的网络。

在接收(105和155)时，分组被传递到抖动缓冲器，该缓冲器旨在补偿接收时间的变化，并且信号被解码(同时补偿任何帧的丢失)并且最后重建的信号被后处理(103和153)并被呈现。

这里假设通信是双向的并且因此通信系统形成具有反馈的闭环系统。反馈可以通过两种方式传输：

·“带外”(即包含在相对于RTP媒体流形成附加流的分组中)。典型地，RTCP协议(RTCP代表实时控制协议)被用作反馈通道。RTCP允许在与RTP流分开的分组中传输控制分组。应当记得，RTCP分组可能具有相当大的大小并因此导致不可忽略的附加比特率；此外，可能的分组丢失可能是有问题的，因为如果RTCP被用于适配目的，则所传输的请求可能会丢失。使用RTCP协议的分组传输可能是不连续的和非重复的，这可能会使适配反应性降低并取决于网络条件(分组丢失等)。

·“带内”(即在RTP媒体流中)。这种类型的反馈可以被认为比RTCP更稳健，因为可以在多个连续的分组中重复给定的请求(对于AMR、AMR-WB或EVS等编解码器，典型地每20ms，这将在下面考虑)。应当注意，在某些情况下(呼叫等待、收听语音邮件等)，可以在单个方向上发送RTP分组，但是这里假设RTP分组的传输是双向的，以使反馈起作用。

应当记得，存在各种RTP协议配置文件，其中主要的是根据规范RFC3551的AVP(表示音频视频配置文件)和根据规范RFC 4585的AVPF(表示具有反馈的音频视频配置文件)。不失一般性地，在这里不审查其安全版本(SAVP和SAVPF，其中前缀“S”表示“安全”)，因为这些安全方面超出了本发明的范围。AVP与AVPF之间的主要区别是对RTCP分组传输的时间限制：通过AVP，平均可以仅仅每5秒发送一个RTCP分组，这通常不足以在网络条件非常多变的情况下实现反应式适配。此外，通过AVFP协议，可以使用RTCP FB(FB表示反馈)消息，而在AVP中仅定义了RTCP APP(APP表示“应用定义的”)分组用于在RTCP报告(SR和RR)之外传输反馈。

一般来说，多种类型的降级可能会潜在地影响IP语音的质量：

·网络的可变带宽/拥塞

·分组的丢失、去排序、重复

·延迟、分组传输延迟的变化

·终端之间的时钟漂移

存在用于减轻这些不同类型的降级的多种解决方案，包括终端适配解决方案。在VoIP终端中，可以区分两种类型的适配：基于发送器的适配和基于接收器的适配。

为了使发送器能够适配并决定其适配(“基于发送器的”适配)，所述发送器必须接收来自远程接收器的反馈，该反馈指示例如由远程接收器估计的观察到的丢失率或可用带宽。

在“基于接收器”的适配中，由本地发送器(104)接收的反馈是由远程接收器(155)做出的适配决定(例如，选择要使用的模式或速率)，该反馈首先被传输到远程发送器(154)，然后被传输到本地接收器(105)。

在图1中，该反馈由指向从接收器155到发送器104的方向的虚线箭头指示。当然，该反馈可以在通信的另一个方向上给出，其中反馈经由块104和155从接收器105传输到发送器154；为了不使图1混乱，在该图中没有示出这个相反的方向。

在适配解决方案的一个示例中，为了控制网络的带宽变化或拥塞，可以实施下面描述的技术。

当编解码器以固定速率操作时，一种用于修改网络上的实际数据速率的适配解决方案在于改变分组中连续信号帧的数量(帧绑定)并从而改变分组速率和IP/UDP/RTP协议报头(以及较低层的协议报头)的相对速率。当呼叫协商使用SDP协议时，使用这种分组速率的适配的能力取决于参数“ptime”和“maxptime”，其分别定义了帧的最小和最大可能长度。例如，对于ptime＝20和time maxptime＝240，一个分组代表20ms的信号并且每个分组最多可以复用12帧。

图2a至图2d展示了每个分组发送一个或多个帧的IP分组格式的示例。默认分组生成模式被认为对应于图2a的情况，其中当前帧N被放置在分组P中，即，其中可以考虑P＝N。图2b给出了其中帧N和N-1被放置在分组P中的帧绑定示例，因此分组速率比帧速率低两倍并且可以认为P＝[N/2](

表示舍入到下面的整数)。

当编解码器是多速率时，也可以改变编解码器的速率。这种速率的改变可以根据由远程接收器估计并通过反馈接收的可用带宽(“基于发送器的”决定)或者根据通过反馈接收的速率改变请求(“基于接收器的”决定)来执行。

应当注意，除了编码适配以外，还有其他解决方案来避免拥塞，这些替代解决方案不在RTP级别或应用层级别操作，而是在较低级别操作。这里将不对其进行描述，因为其超出了本发明的范围。

最后应当注意，对于使用TCP协议(TCP代表传输控制协议)的非实时应用，一种适应信道条件的传统方法在于使用反馈来改变TCP速率，接收器经由该反馈发送带有未接收分组的指示的重传请求(ARQ表示Automatic ReQuest)；根据这个反馈来对TCP速率进行适配。TCP中拥塞的指示最初仅限于丢失的指示，但其后来扩展到了其他参数(对RTT(表示往返时间)随着时间的变化的分析等)。

对于因分组丢失而导致的降级，管理这种类型的降级的最简单方法是在接收器中应用帧丢失校正。这种方法仅仅是反应式的并且不能总是很好地“隐藏”解码信号中的“漏洞”(即，未接收到的丢失信息)，特别是当多个连续帧丢失时或者如果所使用的编解码器对丢失敏感(例如，预测编解码器)。还必须确保音频信号的快速恢复(恢复正常)；取决于编解码器的类型和所使用的丢失校正方法，对丢失帧的校正通常会产生或多或少听得见的瑕疵。丢失校正可以在音频解码器中实施或者在接收器中集成到抖动缓冲器的适配操作中(通过“延长”当前信号并且一旦可用并解码就将其与未来信号“缝合”)。

对抗帧丢失的更好方法是使用冗余，即重复整个或部分编码帧(例如，重要的编码参数)；然而，这种方法在数据速率和延迟方面有成本。

针对本领域技术人员已知的IETF OPUS(“inbandfec”模式)和3GPP EVS(“信道感知模式”)编解码器给出了使用部分冗余的示例。3GPP规范TS 26.114(版本15.0.0)的第10节中给出了针对AMR、AMR-WB和EVS编解码器使用完全冗余(或“应用层冗余”)的示例。在下文中，“应用层冗余”将简称为“冗余”。

图2c和图2d展示了冗余的情况，其中编码帧N以被称为“偏移量”的距离(表示为K)在后面的分组中重复，对于K＝1(如图2c所示)，分组N包含帧N和前一帧N-1，而对于K＝2(如图2d所示)，分组N包含帧N和帧N-2以及空帧(NO_DATA)。对于较大的偏移量K，索引为N的当前帧与索引为N-K的冗余帧之间“插入”的空帧(NO_DATA)的数量为K-1。应当注意，可以将帧冗余和帧聚合相结合，这里不再详细描述这种情况(请参见3GPP TS 26.114图10.12和10.13)。

当呼叫协商使用SDP协议时，当在给定编解码器的有效载荷格式中定义“max-red”参数时，这种类型的应用层冗余的使用取决于“max-red”参数。典型地，“max-red”参数给出了帧(称为主帧)的传输与冗余版本的传输之间的最大持续时间(以ms为单位)(由发送器测量)；因此，当使用冗余时，该参数允许设置最大延迟。例如，“max-red＝20”指示可以使用冗余并且冗余帧可以在原始帧之后20ms内传输。一般而言，当“max-red”设置为0时，这相当于去激活冗余的使用，并且如果“max-red”不作为信令参数(SDP属性)出现，这指示对冗余的使用没有限制，前提是要遵守根据IETF RFC 4566的SDP参数“b＝AS:”所指定的全局通带以及会话中允许的编码模式。

对于提到的其他类型的降级，用于吸收网络抖动、管理分组重复和去排序以及重新建立同步流的传统方法在于在接收时使用抖动缓冲器。静态缓冲器和自适应缓冲器是有区别的。这些缓冲器通常还允许管理时钟漂移问题。这里不审查对抖动缓冲器的管理，因为其超出了本发明的范围。

如上所述，3GPP规范TS 26.114描述了可能的编码适配方法。对于语音，其中描述了用于用信号通知反馈或适配请求的多种机制：

·使用CMR请求(CMR代表编解码器模式请求)

·使用RTCP APP(APP代表应用定义的)类型的RTCP分组

图3a至图3d展示了AMR和AMR-WB编解码器的有效载荷格式。在IETF规范RFC 4867中可以找到AMR和AMR-WB的RTP有效载荷的详细规范。被称为“带宽高效”的模式是这里描述的唯一一种模式，但是应当记得还有另一种被称为“八位位组对齐”的模式。在八位位组对齐模式下，有效载荷的所有字段(有效载荷的报头、ToC条目、编码数据)都是单独对齐的(如有必要，利用零填充)，因此这些字段的长度(以比特为单位)是8的倍数(因此这些字段的长度是整数个八位位组)；在带宽高效模式下，这种与整数个八位位组的对齐仅在整个有效载荷上使用，并且因此这种模式可以被认为是更高效的，因为其需要更少的零填充，并且因此在这两种格式中，其给出最小大小的分组。然而，八位位组对齐模式具有更多功能，诸如通过稳健性对编码数据进行排序(稳健排序)的能力、使用交织的能力、或者在帧中使用CRC码的能力，以使传输相对于帧丢失或比特错误更稳健。

图3a展示了AMR和AMR-WB的分组的有效载荷：其包括使用AMR或AMR-WB编码的PH报头(PH代表有效载荷报头)、ToC字段(ToC代表内容表)和SD数据(SD代表话音数据)。在带宽高效模式下，报头只是4比特的CMR(表示编解码器模式请求)字段，如图3b中所指示；图3c中的索引的定义是：3GPP规范TS 26.101的表1a的针对AMR编解码器的索引，其标题为“AMRSpeech Codec Frame Structure[AMR话音编解码器帧结构]”，版本14.0.0；以及3GPP规范TS 26.201的版本14.0.0的表1a的针对AMR-WB编解码器的索引，其标题为“AMR WidebandSpeech Codec；Frame Structure[AMR宽带话音编解码器；帧结构]”。

这些索引分别为AMR和AMR-WB编解码器定义了具有不同速率的不同编码模式。

ToC字段由6比特的ToC条目列表构成，其中第i条目代表当前分组中包含的第i帧。每个ToC条目具有图3d中给出的格式，其中：

·F(1比特)：F＝1指示当前帧之后是有效载荷中的另一帧；F＝0指示当前帧为分组的最后一帧。

·FT(4比特)：帧类型索引，其指示当前帧已经用特定AMR或AMR-WB模式编码或者是无声标识符(SID)或非传输帧(NO_DATA)的问题。

·Q(1比特)：帧质量指示，如果Q＝0，则帧被损坏。

因此，可以传输在AMR和AMR-WB中编码的多个帧并且ToC字段允许这些帧被明确地解复用。

应当注意，可以在有效载荷的末尾添加比特填充(八位位组的填充)。在这种情况下，RTP报头中的比特“P”(表示填充)可以可选地设置为1并添加附加比特，如RFC 3550中所规定的；该填充的最后一个八位位组包含在有效载荷末尾添加的八位位组的数量(包括这最后一个八位位组在内)。

3GPP EVS编解码器使用多模式编码。这种EVS编解码器(EVS代表增强型语音服务)在2014年底被标准化。目前在两个源代码版本中进行了定义：

·定点格式的源代码(3GPP TS 26.442)

·浮点格式的源代码(3GPP TS 26.443)

以频率8、16、32或48kHz对EVS编解码器的输入信号进行采样并且编解码器可以表示窄带(NB)、宽带(WB)、超宽带(SWP)或全带(FB)电话音频带宽。EVS编解码器的数据速率分为两种模式：

o EVS主模式，其包括

o固定比特率编码模式：7.2、8、9.6、13.2、16.4、24.4、32、48、64、96和128千比特/秒

o可变比特率(VBR)编码模式，对于活动话音平均速率接近5.9千比特/秒并且实际上使用2.8、7.2和8千比特/秒的编码模式的组合

o仅在WB和SWB中的13.2千比特/秒的信道感知模式(CAM)(其使用一种形式的部分冗余来提高对帧丢失的稳健性)

o EVS AMR-WB IO，其比特率与3GPP AMR-WB编解码器(6.6至23.85千比特/秒的9种模式)完全相同

除了以上模式之外，还有非连续传输(DTX)模式，其中被检测为非活动的帧由间歇传输(平均每8帧传输一次)的SID帧(SID主模式或SID AMR-WB IO)替代。在3GPP规范TS26.441至26.450中给出了EVS编解码器的算法细节，并且因此这里不再重复。

在规范TS 26.445的附录A中定义了用于使用RTP协议来传输使用EVS所编码的数据的有效载荷格式。在图4a至图4g中展示了这种格式。

存在用于形成EVS分组的两种不同的模式：

·默认模式：分组是紧凑格式或完整报头(header-full)格式，为了避免这两种模式之间的大小冲突，优先考虑其大小受到“保护”的紧凑模式，而完整报头模式的大小在与紧凑模式的大小冲突的情况下通过添加零填充而受到惩罚。

·完整报头模式

图4a和图4b分别给出了EVS主模式和EVS AMR-WB IO情况下的紧凑格式的RTP有效载荷的示例；具体地可以看出，对于EVS主模式，有效载荷仅仅是编码数据，没有有效载荷报头并且不可能用信号通知适配请求(图4a)；对于EVS AMR-WB IO，以紧凑模式编码的数据被重新组织(某些比特被置换)并且减少到3比特的CMR被定义为报头(图4b)。这里不详细描述这种特殊的3比特CMR的情况，因为在这个3比特信令空间中没有空闲的CMR代码，并且因此除了3比特的速率改变之外，不可能进行任何请求。

图4c和图4d给出了完整报头格式的RTP有效载荷的示例。在第一种情况下(图4c)，传输单个帧并插入ToC报头八位位组(8比特)。在第二种情况下(图4d)，在同一个分组中传输两个帧，还使用了2个ToC报头(2个八位位组)和CMR字段(1个八位位组)。与AMR和AMR-WB编解码器的有效载荷格式相比，因此可以看出，EVS编解码器的完整报头有效载荷格式也实施了CMR和ToC概念，但是这些字段是使用八位位组(8比特)定义的并且因此在完整报头模式下自然是八位位组对齐的，第一比特(MSB)对于CMR设置为1并且对于ToC设置为0。

这些字段的定义在规范TS 26.445附录A中给出。为简明起见，规范TS26.445附录A的所有细节这里不再重复。

8比特的CMR字段分为三个部分：

·H(1比特)：始终为1

·T(3比特)：指示请求类型的比特，以便区分各种NB、WB、SWB和FB主EVS模式(包括VBR和CAM模式)和EVS AMR-WB IO模式。

·D(4比特)：CMR请求

CMR字段的可能值在规范TS 26.445附录A中定义并定义了编解码器的各种模式。在图4g中回想了这些可能值。某些代码未使用。

同样，8比特的ToC字段分为3个部分：

·H(1比特)：始终为0

·F(1比特)：如果F＝1，则当前帧之后是另一帧，如果F＝0，则是分组最后一帧的问题。

·FT(6比特)：指示帧类型即EVS主模式或EVS AMR-WB IO(包括SID模式)的比特。该字段本身分为3部分：EVS模式(1比特)、取决于EVS模式比特的未用/Q比特(1比特)和EVS速率(4比特)。

应当注意，对于EVS，也可以在有效载荷的末尾添加比特填充(八位位组的填充)。在这种情况下，RTP报头中的比特“P”(表示填充)可以可选地设置为1并添加附加比特，如RFC 3550中所规定的；该填充的最后一个八位位组包含添加到有效载荷末尾的八位位组的数量(包括这最后一个八位位组在内)。

在3GPP规范TS 26.114的第10节中详细介绍了将RTCP APP用于IMS语音。在图5a展示了RTCP APP分组的格式。这里不审查RTCP报头的字段(V、P、PT、长度、SSRC/CSRC)的含义。“名称”字段按照惯例被设置为“3GM7”(表示“3GPP MTSI版本7”)。有效载荷部分与“应用相关数据”字段中添加的数据相关。这部分包含报头标识字段(ID)，后面跟着数据(图5b)。TS26.114中规定了多个ID值(4比特)。

某些ID值适用于所有编解码器：

·ID＝0 0 0 0：填充(零填充)

·ID＝0 0 0 1：冗余激活请求(“RedReq”)，在这种情况下，ID后面的数据是12比特，并且每个比特(从末尾开始i＝1到12)指示是否有必要重复分组N-i(如果该比特设置为1)或不重复(如果该比特设置为0)。

·ID＝0 0 1 0：聚合请求(“FrameAggReq”)，在这种情况下，ID后面的数据是4比特，并且只有4个值(在16个可能的值中)是预定义的，这些值与每个分组1到4个帧的传输相对应。

其他值适用于特定编解码器：

·ID＝0 0 1 1：用于改变AMR和AMR-WB的模式(编码率)的CMR请求(“AmrCmr”)

·ID＝0 1 0 0：用于EVS(EVS主模式)的模式改变请求

·ID＝0 1 0 1：用于NB、WB、SWB或FB EVS的编码音频带宽改变请求(“EvsBandwidthReq”)

·ID＝0 1 1 0：用于激活EVS信道感知模式(CAM)的请求(“EvsParRedReq”)

·ID＝0 1 1 1：用于从EVS主模式切换到EVS AMR-WB IO的请求(“EvsIoModeReq”)

·ID＝1 0 0 0：用于从EVS AMR-WB IO切换到EVS主模式的请求(“EvsPrimaryModeReq”)

应当注意，可以将多个RTCP APP请求组合在同一RTCP APP分组中(例如，冗余激活请求和聚合请求)。

因此，对于AMR、AMR-WB和EVS编解码器，RTP分组中的CMR字段所允许的当前适配请求不足以执行每一种可能类型的适配。具体地，对于AMR和AMR-WB编解码器，CMR仅限于接收器指定的速率改变，并且对于EVS编解码器，CMR仅限于速率、编码音频带宽和CAM模式控制的改变。

在IMS语音应用中，接收器对除CMR允许的适配形式以外的适配形式(诸如帧聚合或冗余)的请求要求使用RTCP APP(如规范TS 26.114所规定)。然而，为了能够使用，RTCPAPP需要AVPF配置文件。

VoLTE类型(VoLTE代表LTE(长期演进)语音，这是GSMA IR.92中规定的用于在4GLTE蜂窝电话网络上传输话音的技术)和VoWifi类型(VoWifi代表Wi-Fi语音，这是用于在Wi-Fi网络上传输话音的技术并且在GSMA IR.65中规定)的当前电话应用基于IMS语音的极简配置文件，其中对于语音不允许AVPF配置文件；仅允许RTP AVP配置文件。这意味着RTCPAPP(或RTCP FB)类型的RTCP分组不能用于这些应用。

当允许AVP配置文件时并且根据速率限制(SDP中的SR和RR字段)，RTCP的实际使用最多限于传输以下类型的“基本”报告：发送器报告(SR)和/或接收器报告(RR)，其网络功能具体地是传输保持活动消息。因此，“基于发送器的”适配受到以下事实的高度限制，即接收器在RTP中的反馈不够规则并且仅限于几个“基本”质量指标。

因此，需要一种方法，该方法允许接收器针对任何类型的音频或视频编解码器反应性地且稳健地带内(在RTP流中)指定各种类型的适配。

发明内容

本发明旨在改善这种情况。

为此，本发明提供了一种用于代表接收设备向发送设备用信号通知适配请求的方法，该适配请求请求实时通信会话的实时信号的编码/解码的适配。该适配请求为使得：其涉及帧冗余和/或聚合请求，其是根据在所使用的编解码器的协商阶段中获得的信令参数的存在而生成的，该协商阶段是在该通信会话的初始化期间发生的，并且其是经由RTP类型的实时协议来传输的。

因此，与不是实时执行的RTCP分组的传输相反，使用RTP协议来请求适配使得可以获得反应式适配。

这些适配请求涉及不同于现有技术编码模式改变的适配。因此，该请求信令允许扩大反应式适配的可能性。

下文提及的各个特定实施例可以被单独地或彼此组合地添加在上文所定义的信令方法的步骤中。

在第一实施例中，包括在CMR类型的模式改变请求中的字段用于传输请求该通信会话的适配的该适配请求。

这种类型的请求传输具有不增加IP分组的大小的优点。其允许将现有技术方法中没有使用的CMR值用于指定其他类型的适配。

在发送设备和接收设备使用AMR或AMR-WB类型的编码器/解码器的一个特定实施例中，CMR代码9至14用于对请求各种速率的聚合和冗余的聚合请求和冗余请求进行编码。

这些代码保留供将来使用并且可以有利地定义聚合或冗余类型的适配。

在发送设备和接收设备使用EVS类型的编码器/解码器的一个特定实施例中，T＝“111”且D不是“1111”的CMR代码值被用于对请求各种速率的冗余的冗余请求进行编码。

这些代码保留供将来使用并且可以有利地定义聚合或冗余类型的适配。

在第二实施例中，使用在RTP协议的信令末尾的填充请求字段来传输请求通信会话的适配的适配请求。

这种类型的请求传输还具有允许进行聚合和/或冗余适配请求和编码模式适配请求两者的优点。那么，在信令末尾的填充字段的使用对于指定另一种类型的适配变得有用。

本发明还涉及一种接收设备，该接收设备向远程发送设备传输请求实时通信会话的实时信号的编码/解码的适配的适配请求的信令。该设备为使得其包括：

-用于验证在所使用的编解码器的协商阶段中获得的信令参数的存在的模块，该协商阶段是在该通信会话的初始化期间发生的；

-适配模块，该适配模块能够确定涉及帧聚合请求和/或帧冗余请求的适配请求；以及

-用于经由RTP类型的实时协议将该请求插入到有效载荷格式中的模块。

该设备具有与其所实施的上述方法相同的优点。

本发明还涉及一种包括如所描述的接收设备的通信终端。

本发明涉及一种包含代码指令的计算机程序，当这些指令由处理器执行时，这些指令用于实施如所描述的信令方法的步骤。

最后，本发明涉及一种存储实施如上所述的信令方法的计算机程序的处理器可读存储介质(其可以或者可以不集成到接收设备中并且可以可选地是可移除的)。

附图说明

通过参照附图阅读以下仅通过非限制性示例所给出的说明，本发明的其他特征和优点将变得更加清楚，在附图中：

-图1展示了上文所述的已知的现有技术IP语音通信系统；

-图2a至图2d展示了如上所述的在帧聚合或帧冗余的情况下的IP分组格式的现有技术示例；

-图3a至图3d展示了AMR和AMR-WB编解码器的有效载荷格式；

-图4a至图4g展示了用于EVS编解码器的有效载荷格式；

-图5a至图5b展示了如上所述的RTCP APP分组的格式的现有技术示例；

-图6展示了根据本发明的IP语音通信系统和信令方法的一个实施例；

-图7展示了根据本发明的IP语音通信系统的更详细的实施例；

-图8展示了根据本发明的第一实施例用于传输适配请求的有效载荷格式；

-图9展示了根据本发明的第二实施例用于传输适配请求的有效载荷格式；

-图10展示了根据本发明的另一个实施例用于传输适配请求的有效载荷格式；并且

-图11展示了终端的硬件实施例，该终端包括实施根据一个实施例的信令方法的接收设备。

具体实施方式

图6展示了用于两个终端A和B之间的双向通信的系统的示例，实施了根据本发明一个实施例的请求信令方法。如在图1中，麦克风和扬声器(101，151，102，152)已经被示出。为了简明和清楚，声学处理操作和连接两个终端的网络没有在图6中示出。

终端A包括发送器601和接收器603，而终端B包括发送器651和接收器653。典型地，依据根据SDP协议的一个或多个提议/一个或多个应答的交换经由相应的块600和650来配置两个终端A和B。典型地，至少在发送器和接收器的实例化(初始化或重新初始化)期间采用这种SDP配置；在本发明的变型中，这种配置可以被认为是终端内部的并且允许配置终端的SDP提议及对它的应答。在本发明的变型中，用于用信号通知媒体容量/配置(会话描述)的等同于或源自SDP的其他协议将可能被等同地使用。

发送器执行以下功能：编码、通过添加协议报头并形成与编码格式和传输适配(聚合、冗余等)(如果需要)相对应的有效载荷来生成RTP分组、以及传输分组。

接收器执行以下功能：接收RTP分组、提取RTP报头的字段、对有效载荷进行解码(可能包括抖动缓冲器管理)、对接收帧进行解码、以及校正丢失帧损失。

终端A和B包括请求解码块(块607和657)。下面将参照图8至图10描述这些适配请求的提取和解码的各种实施例。块607或657读取与编解码器(AMR、AMR-WB或EVS)相关联的分组的相关部分。这里假设由块607和657对请求进行解码的结果存储在包含与发送部分(块601和651)共享的结构的“adaptation_info”存储器元素中并且该“adaptation_info”元素本身包括存储元素“adaptation_info.updated”，当已经接收到(CMR等)请求时，该存储元素等于1，否则等于0。在对每个新帧编码之前，块601或651验证“adaptation_info.updated”值是否为1，并且如果是这种情况，则其根据从块607或657接收并解码的请求中获得的补充元素(例如，关于所请求的比特率的“adaption_info.requested_bitrate”、或者关于冗余的激活与否的“adaptation_info.red”，等等)来配置根据本发明的实施例的编码和可选的传输(冗余、聚合)。

终端A和B分别包括适配块605和655，这些块实施确定将由远程发送器进行的适配的步骤。

终端A和B还分别包括请求编码块606和656，这些块实施对将由远程发送器进行的适配进行编码的步骤。对于请求解码块，对将由远程发送器进行的适配(从块605和655获得)进行编码的结果被存储在称为“cmr_request”的存储器元素中，该元素包含与发送部分(块601和651)共享的结构。

在本发明的一个实施例中，根据在所使用的编解码器的协商或配置阶段(在通信会话的初始化(或重新初始化)期间发生)中获得的在第一实施例中被称为“adapt_red”的SDP信令参数的存在与否(经由SDP信令读出块600或650)来配置(块600和650)终端A和B。这里的名称“adapt_red”是指冗余(在应用层冗余的意义上)，但是，如在下文将看到的，在不改变本发明的性质的情况下，其他名称也是可能的并且在变型中使用。在块600和650中协商的配置被存储在存储器元素(图中未示出)中，这些存储器元素包含在每个终端A和B的发送器与接收器之间共享的结构。

配置块600和650首先验证是否满足使用扩展请求所需的条件，该条件在这里是存在被称为“adapt_red”的SDP信令参数。

终端A中的块601、603、605、606和607以及终端B中的块651、653、655、656和657被认为可以访问传输(例如终端A的601和606)和接收(例如终端A的603、605、607)所共同的或者实际上在传输与接收之间分开的存储器元素。这个元素在这里被称为“adapt_enabled”并且存储是否在接收器(包括终端A中的块603、605和607以及终端B中的块653、655和657)的初始化期间定义了SDP信令参数“adapt_red”(分别是块600和650)。这里，如果参数“adapt_red”不存在，则adapt_enabled＝0，如果存在，则adapt_enabled＝1。

如上文所解释的，该信令参数的存在允许一种类型的扩展适配请求。应当注意，该信令参数也可以由一个或多个补充参数来补充，例如“red-offset”参数，该参数允许指示在100％冗余情况下要使用的偏移量(或者在200％或更高冗余的情况下要使用的偏移量)。在一个实施例中，被称为“red_offset”的另一个存储器元素也可被终端A或B的所有块访问并且允许根据SDP配置(块600和650)来配置主帧与冗余帧之间的间隔。

在附录1中，给出了传统的IMS语音SDP提议的示例。

这第一个示例与SDP提议有关，该提议允许使用以下语音编解码器之一发起音频呼叫：AMR、AMR-WB和EVS。UDP端口、AVP配置文件和有效载荷类型(PT)在媒体行“m”中指示。对于EVS、AMR-WB和AMR，有效载荷类型号分别为PT＝97、PT＝98或99、PT＝100或101。

在部分“b＝AS:”中指定的媒体的最大带宽可以根据要求进行修改并且在这里其对应于EVS支持的最大比特率，该最大比特率在Ipv4是24.4千比特/秒。

“rtpmap”和“fmtp”部分指示媒体的格式的参数。对于EVS和AMR-WB，所列编解码器的RTP时钟的频率为16kHz，对于AMR为8kHz。“mode-change-capability”参数协商模式改变频率：这里设置为2，这指示每2帧改变一次，以确保与GSM系统的最大互操作性。关于“max-red”参数，即220，后者允许使用原始帧与冗余帧之间的最大220ms的间隔。

在附录2中，针对冗余的情况给出了根据本发明的一个实施例的SDP提议的第二个示例，其中全局适配参数已经被添加到所有音频编解码器，该参数指示使用扩展的CMR字段或下面将描述的另一类型的请求(填充或RTP报头扩展)的能力。

具体地，为了使远程发送器能够进行由接收器解码的适配，其需要理解已经传输给它的适配请求。从在通信会话的初始化期间发生的编解码器协商中获得的SDP信令为相应终端的编解码器定义了这种类型的能力。

在根据本发明的终端具有遵从扩展的CMR的能力以便命令帧冗余或聚合类型的改变或特定于应用的另一种类型的适配的情况下，SDP信令包括定义的参数“adapt_red”(或在变型中具有另一个名称的参数)，该参数指示终端知道如何使用扩展的请求，在主要实施例中，该扩展的请求是通过以预定义的方式使用“保留的”和/或“未使用的”CMR代码来扩展CMR字段而形成的。

如下文所解释的，根据本发明，当指示扩展的适配能力的SDP参数“adapt_red”存在时，字段“b＝AS:”的值将可能被修改，从而可以有效地使用100％冗余。因此，为了在EVS的情况下以13.2千比特/秒的模式和偏移量K支持100％冗余，典型地将需要将在传输单个帧时针对13.2千比特/秒定义的“b＝AS:”值(对于Ipv4是30)加倍并添加用于指示NO_DATA的八位位组(即ToC的K-1个八位位组)的数量；因此，对于K＝2，b＝AS:将为61。

然而，在上面的示例中，字段“b＝AS:”被认为保持相对于以所有列出的编解码器所允许的最大速率传输每个分组的单个帧所必需的速率来定义。

在变型实施例中，SDP参数“adapt_red”将可能在“fmtp”部分中，并且因此特定于每个编解码器。

在附录3中，针对冗余和聚合的更一般的情况给出了根据本发明的一个实施例的SDP提议的第三个示例，其中全局适配参数已经被添加到所有音频编解码器，该参数指示使用扩展的CMR字段或下面将描述的另一种类型的请求(填充或RTP报头扩展)的能力。

信令参数这次称为“ext_adapt”并且存在两个补充参数：

·“red-offset”参数，其指定两个值，第一个值给出在100％冗余情况下要使用的偏移量，第二个值指示也可以用信号通知(和使用)200％冗余，并且分组中的冗余第二帧使用对应的偏移量

·“agg”参数，其指定允许的聚合的类型，这些允许的聚合以列表格式给出，这里独个“1”指示每个分组只能传输一个帧。

在其他变型中，可以使用其他信令语法：例如，可以使用信令参数作为使用扩展的适配请求的能力的主要指示符，并且然后使用不同的附加参数来激活或不激活特定请求(冗余、聚合等)的使用。

在变型实施例中，SDP参数“adapt_ext”将可能在“fmtp”部分中，并且因此特定于每个编解码器。

在本发明的一个实施例中，分别在块603和653每次接收到新的RTP分组时执行块605和655。接收器至少传递以下信息：

·RTP分组的接收时间(以ms为单位或根据媒体的RTP时钟)

·RTP分组的大小(以八位位组为单位)

·从RTP报头获得的信息：

o RTP序列号

o RTP发送时间或时间戳

根据该信息，块603和653可以估计以下指示符：

·预定范围内的丢失率τ(例如大约最后5秒)。RFC 3550的附录A.3中给出了实施例的示例，其中针对RTCP SR/RR报告计算了量“分率(fraction)”。在变型中，将使用其他估计方法。

·在IP级别以千比特/秒估计的可用带宽β。存在各种估计方法，并且这里给出了基于卡尔曼(Kalman)滤波器的估计的示例，如G.Carlucci(G.卡卢奇)等人的文章“Analysis and Design of the Google Congestion Control for Web Real-timeCommunication(WebRTC)[用于Web实时通信(WebRTC)的谷歌拥塞控制的分析和设计]”，Proc.MMSys，2016年5月中所述。这里的估计带宽被认为是以下形式：β＝β₀+β_编解码器，其中，β_编解码器是编解码器的比特率(编码模式)并且β₀＝β–β_编解码器是除编码比特率之外使用的带宽部分(由于协议报头和可能使用的扩展请求)。

下面，针对AMR和AMR-WB编解码器考虑了两种情况：

·当adapt_enabled＝0时，AMR和AMR-WB编解码器的适配仅限于采用现有CMR的“基本”操作：

每个分组传输单个帧，用于激活或去激活冗余和聚合的适配请求不可用并且适配仅限于根据SDP配置(框600和650)发送CMR以在会话允许的速率(模式)列表中改变编码率(模式)。该列表表示为{R₀，...，R_M-1}，其中M是允许模式的数量。例如，对于AMR，建议协商以下M＝4种模式{4.75，5.9，7.4，12.2}，并且对于AMR-WB，建议协商以下M＝3种模式{6.6，8.85，12.65}，以便使与3G系统的互操作性最大化，但也可以在AMR-WB中以M＝9种模式{6.6，8.85，12.65，14.25，15.85，18.25，19.85，23.05，23.85}协商公开提议/应答，因为3个最低速率{6.6，8.85，12.65}也存在于这9种模式中并且CMR可能将最大速率限制为最高12.65千比特/秒来进行互操作；然而，也存在只允许N＝1个单一模式的情况，例如，{12.2}用于AMR。

如果N＝1，则除了指示速率R_o的CMR或者实际上代码设置为15的CMR(NO_REQ)，块603和653不经由存储器元素“cmr_request”生成适配请求(块605和655的输出)。下面假设N＞1并且下面给出了适配决定算法的示例。在本发明的变型中，在不改变本发明的性质的情况下将可能使用其他标准和其他决定方法。

索引为N-1的前一帧的编码率表示为R_i(其中i表示{R₀,…,R_M-1}的元素之一的索引)，其对应于前一帧的速率。

如果丢失率太高(例如τ≥10％)，则假设可用带宽的估计不够可靠并且没有使用标准β；在这种情况下，如果除了丢失率过高的条件之外，最后一次速率改变发生在例如50帧(1秒)之前，则通过选择紧接在前速率之下的速率R_j(j为使得j＝max(i-1，0)(这里运算符max(.)用来确保速率不会下降到最小速率R₀之下))来谨慎地降低速率并且块605或655的这种模式决定由发送部分转换成指示速率R_j的CMR代码(块606或656)。

当丢失率不太高(例如τ<10％)并且最后一次速率改变发生在例如50帧(1秒)之前时，块605或655的模式决定与紧接在可用带宽β之下的编码模式R_j相对应，即，如果β₀≥E_o，则j＝arg max_k{k|R_k≤β₀}，否则j＝O。

在本发明的变型中，50帧的条件将可能被修改——其在这里用于稳定决定并防止过于频繁的改变。

块605和655经由存储元素在存储器中存储当前模式决定，该存储元素在这里被表示为“cmr_request”，其包含元素“cmr_request.updated”和元素“cmr_request.requested_bitrate”，并且这些块验证接收到的分组大小。如果远程发送器没有执行本地接收器的请求(不同于“NO_REQ”)(这是通过将所使用的编解码器的速率(从接收到的分组的大小得出)与同所发送的CMR相关联的速率进行比较来验证的)，则最后一个模式决定将被重复以便确保该决定的稳健传输。如果不需要改变当前模式的决定，则块605或655将指示必须使用设置为1的“cmr_request.updated”元素发送CMR，否则需要“updated＝0”。在本发明的变型中，决定将被重复预定义的次数(例如3次)。

在每个新帧被编码的时刻，发送器601(或651)访问(通常与块605或655并行，经由“互斥量(mutex)”或“临界区(critical section)”)存储元素“cmr_request.updated”，并且如果该元素等于1，则发送器将向当前分组添加具有对应的“cmr_request.requested_bitrate”值的CMR字段。否则，如果元素“cmr_request.updated”等于0，则发送器将针对AMR、AMR-WB或EVS指示“NO_REQ”类型的CMR(无请求)，或者如果EVS编解码器被配置为在不发送请求时不发送CMR，则不提供CMR。

·当adapt_enabled＝1时，AMR和AMR-WB编解码器的适配被扩展：

块601和651包括编码帧的缓冲(队列)，以便不必多次记录同一帧。编码帧的这个缓冲在这里被认为是根据SDP参数(块600和650)通过根据参数“max-red”和“maxptime”计算要存储的编码帧的最大数量来配置的。例如，如果max-red＝220和/或maxptime＝240，则缓冲器将可能被调整为最多存储12个编码帧。

此外，块603和653读出ToC字段并检测当前分组中的一个或多个帧，以便管理冗余或聚合的情况。如果在当前分组中检测到一个以上的帧，则块603和653将它们分开并根据传输类型将各个编码帧插入到接收端抖动缓冲器中，例如：

·如果当前分组包含帧聚合，则将这些帧分开并根据RTP分组的时间戳和分隔这些帧的时间间隔来插入这些帧

·如果当前分组包含冗余，则接收器验证对应于给定帧的主冗余帧是否已经被接收，并且如果是这种情况，则删除副本，否则该帧被插入到抖动缓冲器中。

这两种情况也可以合并。

这里不给出关于抖动缓冲器的适配以及各种类型的适配对用于管理抖动缓冲器的算法的影响的细节。例如，在冗余或聚合的情况下，抖动缓冲器考虑所使用的传输配置是很重要的，以便调整音频信号生成延迟，从而利用冗余帧或调整网络抖动的估计。

下面首先在冗余的情况下给出了扩展适配算法的示例。

模式列表将再次是{R₀，...，R_M-1}，其中M是允许模式的数量。

如果丢失率太高(例如τ≥10％)并且最后一次速率改变发生在例如50帧(1秒)之前，则适配决定在于激活100％冗余。在一个示例中，将选择紧接在当前速率之下的速率2 xR，并且如果没有速率2 x R满足该条件，则将选择最低速率2 x R。在这种情况下，“cmr_request.updated”元素设置为1并且附加元素“cmr_request.requested_bitrate”和“cmr_request.red”分别设置为R和1，以指示必须发送针对速率为R的100％冗余的请求。

如果丢失率不是太高(例如τ<10％)，则适配决定在于去激活冗余。在这种情况下，再次使用上述算法：当丢失率不太高(例如τ<10％)并且最后一次速率改变发生在例如50帧(1秒)之前时，块605或655的模式决定与紧接在可用带宽β之下的编码模式R_j相对应，即，如果β₀≥R_O，则j＝arg max_k{k|R_k≤β₀}，否则j＝O。在这种情况下，“cmr_request.updated”元素设置为1并且附加元素“cmr_request.requested_bitrate”和“cmr_request.red”分别设置为R和0，以指示必须发送传统CMR请求。

在一个示例中，适配决定因此通过包括多个元素的存储元素“cmr_request”来表示：

·“cmr_request.updated”：如果必须传输新的决定，则该值设置为1

·“cmr_request.requested_bitrate”：该值指示要使用的编码率

·在本发明的变型中，在不改变本发明的性质的情况下，将可能使用其他标准和其他决定方法。具体地，在聚合的情况下，将定义例如称为“cmr_request.agg”的存储元素以指示必须发送聚合请求。

EVS编解码器的适配决定(块605和655)类似于下面针对AMR和AMR-WB编解码器给出的描述。然而，必须考虑多种特性：

·EVS编解码器允许激活CAM模式(其为WB和SWB中13.2千比特/秒的“稳健”模式)，这种模式通常使用SDP进行配置(参数“ch-aw-recv”的细节，请参见TS 26.445的附录A)。

·并非在所有速率下都支持所有(NB、WB、FWB和FB)音频带宽(请参见TS 26.445的表A.6)。因此，为了生成CMR，如果会话允许音频带宽范围(例如bw＝nb-swb)、如果当前速率是SWB-9.6千比特/秒、并且如果适配决定下降到8千比特/秒，则将有必要生成CMR来指示WB-8千比特/秒模式，并且因此与AMR或AMR-WB相反，在EVS编解码器的情况下，速率的改变可能涉及编码音频带宽的改变。

在所描述的实施例中，块605和655将不生成请求CAM模式的适配决定以简化实施。在变型中，如果例如丢失率例如<6％并且如果估计可用带宽>13.2千比特/秒，则将可以激活CAM模式，并且100％冗余将仅用于丢失率>6％。

在本发明实施例的示例中，根据下面将描述的各种实施例，要进行的适配是帧聚合类型的，或者也根据下面描述的各种实施例，要进行的适配实际上是帧冗余类型的，或者要进行的适配甚至是特定于应用的另一种类型的适配。该适配可以包括聚合和冗余两者或者另一种特定类型的适配。

这些类型的适配例如用于修改分组速率、校正错误的接收帧或丢失帧等，这在仅限于修改编码率的适配的情况下通常是不可能的(除了EVS编解码器，其中CAM模式部分地允许解决帧丢失的问题，但是该模式特定于13.2千比特/秒的WB和SWB EVS并且在高丢失率下典型地不如100％冗余有效)。

终端A和B的块的操作原理保持相同：它们的操作取决于SDP配置和存储器元素“adapt_enabled”。

与在605和655中确定的适配相对应的适配请求由用于对该请求进行编码的相应块606和656插入到当前RTP分组中。

下面参照图8至图10描述可以插入这些适配请求的各种方式。

用于对请求进行解码的相应块607和657允许从远程接收器接收到的在RTP分组中的请求被提取和解码，以便发送器能够进行所请求的适配。具体地，这里考虑其中发送器访问存储元素“adaptation_info”和“cmr_request”以及可选的附加存储元素的实施例的示例。

因此，图6展示了在该信令方法期间实施的步骤，即：验证在所使用的编解码器的协商或配置阶段中获得的信令参数的存在的步骤(600，650)，该协商或配置阶段是在通信会话的初始化期间发生的；确定与帧聚合请求和/或帧冗余请求相关的适配请求的步骤(605，655)；以及经由RTP类型的实时协议将该请求插入到有效载荷格式中的步骤(606，656)。在本发明的变型中，将可能使用除共享结构(采用存储元素的形式)(诸如“cmr_request”、“adaptation_info”或“adapt_enabled”)之外的其他交换信息的方式。

图7展示了比上述图6的实施例更详细的实施例。在这个实施例中，图6的发送器块被分成编码块(701和751)和发送块(702和752)，它们实施RTP分组的生成和传输。图6的接收器块被分成解码块(704和754)，这些解码块可以管理抖动缓冲器、对接收到的帧进行解码、并校正丢失的帧和接收损失(703和753)。在VoIP应用中，块701和702(或751和752)以多线程方式并行执行，与编码相关的部分(701或751)依赖于与输入声卡(连接到块701)相关的事件，并且传输到网络的部分(块702或752)依赖于网络事件；以相同的方式，在接收部分中，分组(703和753)可以与音频生成(704和754)并行接收。

用于确定要进行的适配的块705和755具有与参照图6针对块605和655描述的功能相同的功能。

图7示出了可以根据这些块中的哪一个形成有效载荷来在编码块(701，751)与发送块(702，752)之间分配创建有效载荷格式的功能。本发明适用于这两种情况。

使用块706和756对如此确定的对这些适配的请求进行编码并且由编码模块701或751或者由实施封装到分组中的发送器702或752插入到RTP分组中。

块707和757具有与参照图6描述的块607和657相同的功能。根据用于传输适配请求的方法，解码的请求将被发送到发送部分的编码块或发送块。

参照图8，现在将描述使用如下定义的CMR代码的方式。

在第一实施例中，由终端的接收器确定的适配请求被编码在CMR类型的模式改变请求的字段中以便被传输到远程终端的发送器。

在该实施例中，如上所述，终端的编解码器之间的协商(在通信会话的初始化时发生)的信令定义了适配参数“adapt_red”或“adapt_ext”或标识使用扩展请求的能力的另一个名称，以便允许采用对于接收器和远程终端的发送器两者都可以理解的CMR字段。

当定义这个参数时，定义CMR代码字段来指定所需类型的适配。

根据本发明，对于如上所述的AMR、AMR-WB和EVS编解码器，采用保留供将来使用或未使用的代码来进行扩展模式改变请求。对于上述编解码器，这些代码仅限于几个值。

区分两种操作情况：

·当adapt_enabled＝1时，定义为“保留”、“未使用”或“供将来使用”的CMR代码用于进行扩展请求。

·当adapt_enabled＝0时，仅使用RFC 4867中针对AMR和AMR-WB定义的以及TS26.445Appendix A中针对EVS定义的CMR代码。接收端(块607和657)如果接收到定义为“保留”、“未使用”或“供将来使用”的CMR代码，则忽略它们。

对于一个实施例，这里描述了包括在“保留的”或未使用的CMR字段中的这些请求的编码格式。

对于AMR和AMR-WB编解码器，保留8到14(含)和9到14(含)之间的CMR值供将来使用。因此，当在编解码器协商期间定义根据本发明的信令参数时有条件地使用这些CMR值并且它们的使用专用于用信号通知冗余、聚合或其他类型的请求。

同样，如参照图4g所描述的，对于EVS编解码器，T＝“111”且D不是“1111”的值被标记为保留的，这剩下了15个可能的值。

在一个变型实施例中，也可以使用标记为未使用的值，那么这大大增加了可能的自由代码的数量；然而，这仅适用于EVS编解码器。

对于冗余适配(主要用于替换丢失的帧)，100％冗余在于在当前分组P中重复过去的帧(利用偏移量K)。当帧丢失是随机的(独立同分布(或i.i.d)值的统一定律)时，这种100％冗余允许10％的丢失率被转换成1％的丢失率。

对于其中QOS管理机制已经就位并在进行电话呼叫时对其进行协商的LTE类型的蜂窝网络，该100％冗余水平在实施例的第一示例中被认为是足够的并且认为没有必要考虑更高冗余(例如200％或300％)的情况。

在这里描述的示例中，认为没有必要将帧聚合和帧冗余两者相结合。

这里，开发了帧聚合或冗余请求的信令的约束版本。

这里针对与有效载荷格式相关联的对于AMR约为12.2千比特/秒、对于AMR-WB为12.65或23.85千比特/秒并且对于EVS为13.2或24.4千比特/秒的最大速率描述了AMR、AMR-WB和EVS编解码器的可能的冗余情况。

下表1显示，对于速率约为12.2千比特/秒的AMR编解码器，冗余仅限于3种可能的冗余情况，表示为“2 x R”，其中R是所重复的速率。这里应当注意，没有指定偏移量，并且在实践中，如果必须插入NO_DATA类型的ToC信息来指示有效载荷中的偏移量，则与有效载荷格式相关联的速率将高于R的两倍。

应当注意，当冗余被激活时，如果分组P的当前速率是12.2千比特/秒的速率并且如果2 x 5.9千比特/秒的冗余被切换到从后面的分组P+1开始，则(索引为P+1的)第一个分组通常包含速率为5.9千比特/秒的当前帧和速率为12.2千比特/秒的前一帧。只有在(索引为P+2的)后面的分组中才将存在2个5.9千比特/秒的帧。对于第一个分组，那么速率高于最大允许速率。如果SDP参数的“b＝AS:”值允许，则此方法用于第一个转变分组，否则，如果此值不允许过载，则为防止暂时过载(12.2+5.9)，分组P+1将只包含以5.9千比特/秒编码的帧。

表1

可以根据“b＝AS:”的值设想允许2 x 6.7和2 x 7.4冗余。

同样，在帧聚合适配的情况下，对于相同的最大速率限制，对于AMR编解码器，发现与上面表1中所示相同的情况是可用的。

因此，可以为AMR编解码器定义以下CMR代码(表2)，其中“RED”表示冗余：

CMR代码	AMR请求
		9	RED 2 x 4.75
10	RED 2 x 5.15
		11	RED 2 x 5.9
12	RED 2 x 6.7
		13	RED 2 x 7.4
14	保留

表2

在变型中，特别是当没有补充SDP参数允许指定冗余偏移量时，将可以使用表2a中为AMR指定的CMR代码。这允许指定要使用的冗余速率和偏移量(这里是1或3)两者。在这个示例中还将注意到5.15和6.7的速率。

CMR代码	AMR请求
		9	RED 2 x 4.75，偏移量1
10	RED 2 x 5.9，偏移量1
		11	RED 2 x 7.4，偏移量1
12	RED 2 x 4.75，偏移量3
		13	RED 2 x 5.9，偏移量3
14	RED 2 x 7.4，偏移量3

表2a

在其他变型中，也将可以将冗余和聚合相结合，每个分组两个帧，如表2b所示，其中“Agg”表示聚合。

表2b

这里应当记得，这里列出了CMR代码，以便允许独立于允许速率(AMR的SDP参数“mode-set”)的“通用”请求。当然，块605和606(以及655和656)受到针对会话协商的速率的约束，并且因此某些代码可能不会被使用。

这里假设用于冗余的偏移量是在SDP协商期间用一个参数指定的，该参数可以被命名为“red-offset”并且将典型地与允许标识要使用的CMR代码的SDP参数相关联。如果该“red-offset”参数不可用，则将可能使用例如表2a中给出的请求信令解决方案。

因此，如果adapt_enabled＝1，则块605和655(或705和755)将验证“cmr_request.updated”的值，并且如果该值被设置为1，则这些块将转换存储在“cmr_request”中的补充数据。具体地，对于表2的情况，如果cmr_request.red＝1，则元素“cmr_request.requested_bitrate”将被用于从9到13中找到CMR代码。如果cmr_request.red＝0，则元素“cmr_request.requested_bitrate”将被用于从0到7中找到与速率相对应的CMR代码。

这里假设决定块605和655已经考虑了由SDP参数(b＝AS、maxptime、max-red等)施加的约束。

在下表3中，现在针对编解码器AMR-WB针对两个最大速率说明相同的方法。

表3

取决于编解码器的最大速率是12.65千比特/秒还是23.85千比特/秒并且取决于“b＝AS:”的值和会话中允许的速率(见参数“mode-set”)，可以看出，100％冗余对于速率12.65千比特/秒仅允许一种情况(2x 6.6)或者对于速率23.85千比特/秒允许三种情况。

应当注意，12.65千比特/秒的第3种100％冗余情况稍微超过了23.85千比特/秒的标称速率，并且在这种情况下，有必要确保服务的大小被合适地确定成适合于稍微高于AMR-WB编解码器的“正常”速率的速率，这典型地通过将SDP协商的信令中的“b＝AS”的值修改为更高的值来实现。

因此，可以为AMR-WB编解码器定义以下CMR代码(表4)：

CMR代码	AMR-WB请求
		9	RED 2 x 6.6
10	RED 2 x 8.85
		11	RED 2 x 12.65
12	Agg 2 x 6.6
		13	Agg 2 x 8.85
14	Agg 2x 12.65

表4

在变型中，用信号通知扩展请求的空间将可能被限制为冗余和各种偏移量，例如如表4a所示。

CMR代码	AMR-WB请求
		9	RED 2 x 6.6，偏移量＝1
10	RED 2 x 8.85，偏移量＝1
		11	RED 2 x 12.65，偏移量＝1
12	RED 2 x 6.6，偏移量＝3
		13	RED 2 x 8.85，偏移量＝3
14	RED 2 x 12.65，偏移量＝3

表4a

在本发明的变型中，这些值的顺序将可能被修改并且某些值将可能在所有表中被删除。还将可以定义例如整合200％冗余或冗余偏移量的值的选项的额外变型。

再次，如果adapt_enabled＝1，则块605和655(或705和755)将验证“cmr_request.updated”的值，并且如果该值被设置为1，则这些块将转换存储在“cmr_request”中的补充数据。具体地，对于表4的情况，如果cmr_request.red＝1，则元素“cmr_request.requested_bitrate”将被用于从9到11中找到CMR代码。如果cmr_request.red＝0，则元素“cmr_request.requested_bitrate”将被用于从0到8中找到与速率相对应的CMR代码。

这里假设决定块605和655已经考虑了由SDP参数(b＝AS、maxptime、max-red等)施加的约束。

同样的方法可以用于EVS编解码器。然而，与AMR和AMR-WB编解码器不同，EVS编解码器包括多种操作模式：EVS-NB、EVS-WB、EVS-SWB、EVS-FB和EVS AMR-WB IO以及VBR或CAM等特定模式。

EVS AMR-WB IO的情况在这里被认为是从上面讨论的AMR-WB的情况得到的。对于“EVS主模式”部分，撇开编码音频带宽，可以定义下表(表5)：

表5

在这里，此表基于GSMA规范IR.92 V11.0(2017年6月15日)，其中为EVS定义了5种配置(配置文件)。这里仅考虑允许获得冗余或聚合类型的适配空间的四种配置(A1、A2、B1、B2)。

应当注意，在VBR模式下冗余或聚合的使用是有争议的并且潜在地使封装到分组中的实施变得复杂。由于这个原因，这里VBR模式在表5中用符号“[x]”指示。这里的考虑将限于固定速率。然而，在变型中，也将可以在根据本发明的CMR代码中包括VBR模式。

为EVS编解码器保留的CMR代码的数量是15。

对于AMR-WB编解码器，已经看到有6种情况。对于EVS编解码器，适配可能仅限于NB、WB和SWB模式，因为FB模式仅以16.4千比特/秒开始。因此，可以为EVS编解码器定义以下CMR代码(表6)：

CMR代码	EVS请求
		111 0000	RED 2x7.2-NB
111 0001	RED 2x8-NB
		111 0010	RED 2x9.6-NB
111 0011	RED 2x13.2-NB
		111 0100	RED 2x7.2-WB
111 0101	RED 2x8-WB
		111 0110	RED 2x9.6-WB
111 0111	RED 2x13.2-WB
		111 1000	RED 2x7.2-SWB
111 1001	RED 2x8-SWB
		111 1010	RED 2x9.6-SWB
111 1011	RED 2x13.2-SWB
		111 1100	RED 2x6.6
111 1101	RED 2x8.85
		111 1110	RED 2x12.65

表6

可以看出，该表不包括用于聚合适配的代码值。为了简明起见，这里没有给出从“未使用”值中进行选择以进行扩展请求的值的细节。然而，针对AMR和AMR-WB编解码器给出的示例可以扩展到EVS编解码器。

在一个可能的实施例中，在这种情况下，可以使用“未使用的”CMR值来定义聚合模式。

在本发明的变型中，这些值的顺序将可能被修改并且某些值将可能被删除或替换。具体地，在本发明的变型中，对于AMR、AMR-WB和EVS编解码器，CMR代码将可能被保留用于用信号通知除冗余和聚合之外的类型的适配。

在本发明的其他变型中，将不使用聚合，而是将可能为(有限的)200％冗余(这大约是比特率的三倍)情况保留CMR代码：AMR，4.75千比特/秒；AMR-WB，6.6千比特/秒；EVS，对于主模式(对于NB和WB带宽)，从7.2千比特/秒到8千比特/秒；对于主模式(对于NB、WB和SWB带宽)，9.6千比特/秒；以及对于EVS AMR-WB IO，6.6千比特/秒。

在AMR和AMR-WB编解码器的情况下，CMR字段总是存在，并且对于EVS，在EVS AMR-WB IO的情况下也总是存在(在紧凑模式下为3比特并且在完整报头模式下为一个八位位组)；然而，在EVS主模式的模式下，其是否存在取决于被称为“cmr”的SDP参数(相关细节请参见TS 26.445的附录A)。

CMR字段是AMR、AMR-WB和EVS编解码器的RTP有效载荷格式的有效载荷数据的报头；这些编解码器的现有字段保持不变，如图8中所指示的。但是，该字段被指定为“ext.CMR”或“扩展的CMR”的含义是，当前定义为保留供将来使用(“供将来使用”、“保留”)的值和可选的未使用的值(“未使用”)现在如上文定义的那样用于指示适配请求，只要信令参数激活该特征。

因此，采用新CMR代码的形式的适配请求被插入到由RTP报头定义的RTP分组中(见图8)。该报头包括以下字段：

·V表示版本，其标识RTP版本

·P表示填充，如果其被设置为1，则除了有效载荷之外，分组在分组的末尾包含填充八位位组

·X表示扩展，如果其被设置为1，则现有报头后面跟着扩展

·CC，表示“CSRC计数”，其指示CSRC标识符的数量

·M，表示“标记”，其指示当前数据是否与应用特别相关

·PT，表示“有效载荷类型”，其指示有效载荷的格式

·“序列号”对于每个发送的RTP分组增加1并且允许接收器检测丢失并修复分组序列

·“时间戳”用于指定每个分组的发送时间并允许接收器以适当的间隔读取接收到的样本

·SSRC，表示“同步源”，其以不同方式标识同一流的每个源

·CSRC，表示“贡献源”，其指示对分组的有效载荷有贡献的源。

应当注意，可以添加一个或多个信令参数来例如将100％冗余情况下的偏移量参数化。

本发明的这个实施例具有不增加IP分组的大小和不修改分组的RTP报头的优点。

因此，在某些使用情况下，总是可以执行RTP报头压缩，而这不会对适配请求产生影响。然而，这种解决方案的缺点是仅产生有限的信令空间并且仅适用于定义了CMR概念的编码器，对于这些编码器来说，许多自由代码就足够了。

在图9所示的第二实施例中，由终端的接收器确定的适配请求被编码到协议的信令末尾的填充请求字段中以传输到远程终端的发送器。

在该实施例中，如上所述，在通信会话的初始化时发生的终端的编解码器之间的协商信令定义了允许使用该填充字段并且对于接收器和远程终端的发送器两者都可以理解的适配参数“adapt_red”或“adapt_ext”。

当定义该参数时，定义填充字段以指定所需类型的适配。

使用一个八位位组填充字段(PAD.Req)，在其中插入如上定义的一个八位位组扩展CMR代码。

填充通常插入在有效载荷的末尾，并且为了避免降低报头压缩的有效性，RTP报头的比特“P”将不被设置为1。相比之下，根据RFC 3550，以请求后面跟着指示填充八位位组的数量的附加八位位组的方式插入填充。这种方法允许避免对现有终端的潜在影响。

在变型中，填充比特(在指示填充八位位组的数量的最后添加的八位位组之前)将使用与根据TS 26.114(第10节)的RTCP APP的请求编码格式相同的语法，并且具体地在4个“ID”比特上添加前缀。

在变型中，对于EVS编解码器，在“分组封装”期间在完整报头模式下通常默认设置为零的填充将被根据本发明的填充替换。这具有使附加八位位组的数量最小化的优点。

对于AMR和AMR-WB编解码器，仍将使用图3c中所示的现有的现有技术4比特CMR，但是将在比特流的末尾在LSB中的4比特上插入如第一实施例中定义的新“CMR代码”，如图9所示；MSB中的4个其他比特将设置为零。在变型中，LSB和MSB将被反转。

图9中所示的RTP报头包含以下字段：

·V表示版本，其标识RTP版本

·P表示填充，如果其被设置为1，则除了有效载荷之外，分组在分组的末尾包含填充八位位组。根据本发明，最好不要将填充比特设置为1，以便不降低报头压缩的有效性。在变型中，该比特将被设置为1，如在对应于图10的变型实施例中。

·X表示扩展，如果其被设置为1，则现有报头后面跟着扩展

·CC，表示“CSRC计数”，其指示CSRC标识符的数量

·M，表示“标记”，其指示当前数据是否与应用特别相关

·PT，表示“有效载荷类型”，其指示有效载荷的格式

·“序列号”对于每个发送的RTP分组增加1并且允许接收器检测丢失并修复分组序列

·“时间戳”用于指定每个分组的发送时间并允许接收器以适当的间隔读取接收到的样本

·SSRC，表示“同步源”，其以不同方式标识同一流的每个源

·CSRC，表示“贡献源”，其指示对分组的有效载荷有贡献的源。

因此，有效载荷数据包括传统CMR字段、如上定义的ToC字段、话音数据和如所定义的适配请求。

对于EVS编解码器，以相同的方式在比特流的末尾使用填充字段以插入如第一实施例中定义的CMR代码。

然而，在这种情况下，AMR和AMR-WB编解码器的CMR将不得不被设置为“NO_REQ”并且信令参数将允许理解将考虑具有一个八位位组“扩展CMR”的填充字段。

该实施例具有能够通过现有的CMR代码指定传统的模式改变并通过在有效载荷格式的不同位置使用新代码来指定不同的适配请求的优点。

这种解决方案还具有不修改分组的RTP报头的优点。

因此，在某些使用情况下，仍可以执行RTP报头压缩，而这不会对适配请求产生影响。

除了扩展请求在填充字段中传输之外，图6和图7的各个块的操作没有改变。

在一个可能的实施例中，如图10所示，将可能将如由新CMR代码定义的适配请求插入到RTP有效载荷格式的报头中。然而，这种方法的缺点是，一方面增加了RTP分组的大小，并且另一方面降低了现有报头压缩方法的有效性，因为RTP报头的扩展比特(X)必须设置为1。

除了扩展请求在填充字段中传输之外，图6和图7的各个块的操作没有改变。这里假设根据RFC 5285用“extmap”字段用信号通知报头扩展。在变型中，将使用其他扩展方法。

图11现在展示了通信终端的硬件实施例的示例，该通信终端包括能够实施根据本发明的信令方法的接收设备，特别是使用至少一个SDP类型的信令或配置参数。

终端TA包括：存储空间11，例如存储器MEM；包括处理器P的处理单元10，处理器P由存储在存储器11中并实施根据本发明的信令方法的计算机程序PG控制。

在初始化时，在程序PG的代码指令由处理单元10的处理器P执行之前，这些代码指令被例如加载到RAM(未示出)中。程序指令可以存储在存储介质上，诸如闪速存储器、硬盘或任何其他非易失性存储介质。

处理器根据程序PG的指令实施如参照图6所述的信令方法。

终端TA包括通信模块12，该通信模块能够从通信网络接收实时数据并向通信网络传输实时数据并且能够经由在网络中发送的或来自终端的存储器11的信令来读取SDP类型的信令或配置数据13。L

该终端包括接收设备，该接收设备包括：用于验证在所使用的编解码器的协商阶段中获得的信令参数的存在的模块，该协商阶段是在通信会话的初始化期间发生的；适配模块，该适配模块能够确定与帧聚合请求和/或帧冗余请求相关的适配请求；以及用于经由RTP类型的实时协议将该请求插入到有效载荷格式中的模块。这些模块如参照图6或图7所述。

术语模块可以对应于软件组件或硬件组件或一组硬件和软件组件，软件组件本身对应于一个或多个计算机程序或子程序或者更一般地对应于能够实施如针对讨论中的模块所描述的一个功能或一组功能的程序的任何元件。以相同的方式，硬件部件对应于能够实施针对讨论中的模块的一个功能或一组功能的硬件组件的任何元件(集成电路、芯片卡、存储器卡等)。

终端例如是电话、智能电话、平板电脑、计算机、住宅网关或连接的东西。

附录1

附录2

附录3

Claims (9)

1.一种用于代表接收设备向发送设备用信号通知适配请求的方法，该适配请求请求实时通信会话的实时信号的编码/解码的适配，其特征在于，该适配请求涉及帧冗余和/或聚合请求，该适配请求是根据在所使用的编解码器的协商阶段中获得的信令参数的存在而生成的，该协商阶段是在该通信会话的初始化期间发生的，并且该适配请求是经由RTP类型的实时协议来传输的。

2.如权利要求1所述的方法，其中，包括在CMR类型的模式改变请求中的字段被用于传输请求该通信会话的适配的该适配请求。

3.如权利要求2所述的方法，其中，在该发送设备和该接收设备使用AMR或AMR-WB类型的编码器/解码器的情况下，CMR代码9至14被用于对请求各种速率的聚合和冗余的聚合请求和冗余请求进行编码。

4.如权利要求2所述的方法，其中，在该发送设备和该接收设备使用EVS类型的编码器/解码器的情况下，T＝“111”且D不是“1111”的CMR代码值被用于对请求各种速率的冗余的冗余请求进行编码。

5.如权利要求1所述的方法，其中，在该RTP协议的信令末尾的填充请求的字段被用于传输请求该通信会话的适配的该适配请求。

6.一种向远程发送设备传输适配请求的信令的接收设备，该适配请求请求实时通信会话的实时信号的编码/解码的适配，其特征在于，该接收设备包括：

-用于验证在所使用的编解码器的协商阶段中获得的信令参数的存在的模块，该协商阶段是在该通信会话的初始化期间发生的；

-适配模块，该适配模块能够确定涉及帧聚合请求和/或帧冗余请求的适配请求；以及

-用于经由RTP类型的实时协议将该请求插入到有效载荷格式中的模块。

7.一种包括如权利要求6所述的接收设备的通信终端。

8.一种包含代码指令的计算机程序，当这些指令由处理器执行时，这些指令用于实施如权利要求1至5之一所述的信令方法的步骤。

9.一种处理器可读存储介质，该处理器可读存储介质存储有包含指令的计算机程序，这些指令用于执行如权利要求1至5之一所述的信令方法。

Images