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

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

Signaling for requests to adapt to voice communication sessions of Internet Protocol

【技术实现步骤摘要】
【国外来华专利技术】用于适配互联网协议语音通信会话的请求的信令
本专利技术涉及电信领域，并且更具体地涉及分组通信网络领域。在这种类型的网络中，可以传送与实时服务相关联的数据流。由IETF(表示互联网工程任务组)开发的互联网协议(IP)在分组通信网络中实施，以支持非实时服务(诸如数据传输服务、网站浏览服务和电子消息传递服务)和实时或会话服务(诸如IP电话、IP视频电话或者甚至IP视频流式传输)两者。本专利技术更具体地涉及适配请求的信令，该适配请求请求两个通信终端之间的实时通信会话期间的实时信号(诸如语音信号或视频信号)的编码/解码的适配。
技术介绍
参照图1描述了现有IP语音通信系统的示例。该图展示了双向IP语音(VoIP)通信系统，该系统具有通过IP分组网络(125)连接的两个电话终端(100和150)。该图中未示出“信令平面”；然而，用于建立和管理呼叫的可能解决方案可以基于各种已知的协议，诸如：·根据IETF规范RFC3261和RFC4566的SIP/SDP(表示会话发起协议/会话描述协议)，如在IMS(表示IP多媒体子系统)多媒体服务中。为了促进关于媒体容量和相关联提议/应答的信令交换，也可以使用根据IETF规范RFC5939的“SDPcapneg”。·JSEP(表示JavaScript会话建立协议)，其使用SDP语法来定义WebRTC会话描述(经由WebSocket或其他方式进行交换)。·H.323/H.245。图1是在建立呼叫时使用的“媒体平面”和音频链的简化视图。这里，仅考虑单声道音频信号的情况，环境声学信号例如在通信的每一端由麦克风(101和151)捕获。应当注意，单声道输入/输出信号的情况可以容易地推广到多声道情况。远程信号经由扬声器(102和152)呈现。所捕获和呈现的音频信号在被发送和接收时通常经历各种声学处理操作(103和153)，例如：·在发送时，经历模拟/数字转换、增益控制、降噪、回声消除等·在接收时，经历数字/模拟转换、增益控制等。在发送时，经预处理的音频信号被编码成连续的帧(典型地具有10ms到60ms范围内的(通常固定的)帧长度)并且经编码的帧被形成为IP分组(104和154)。这些分组典型地使用IETF规范RFC3550中描述的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(表示音频视频配置文件)和根据规范RFC4585的AVPF(表示具有反馈的音频视频配置文件)。不失一般性地，在这里不审查其安全版本(SAVP和SAVPF，其中前缀“S”表示“安全”)，因为这些安全方面超出了本专利技术的范围。AVP与AVPF之间的主要区别是对RTCP分组传输的时间限制：通过AVP，平均可以仅仅每5秒发送一个RTCP分组，这通常不足以在网络条件非常多变的情况下实现反应式适配。此外，通过AVFP协议，可以使用RTCPFB(FB表示反馈)消息，而在AVP中仅定义了RTCPAPP(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和timemaxptime＝240，一个分组代表20ms的信号并且每个分组最多可以复用12帧。图2a至图2d展示了每个分组发送一个或多个帧的IP分组格式的示例。默认分组生成模式被认为对应于图2a的情况，其中当前帧N被放置在分组P中，即，其中可以考虑P＝N。图2b给出了其中帧N和N-1被放置在分组P中的帧绑定示例，因此分组速率比帧速率低两倍并且可以认为P＝[N/2](表示舍入到下面的整数)。当编解码器是多速率时，也可以改变编解码器的速率。这种速率的改变可以根据由远程接收器估计并通过反馈接收的可用带宽(“基于发送器的”决定)或者根据通过反馈接收的速率改变请求(“基于接收器的”决定)来执本文档来自技高网...

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

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


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


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


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

【专利技术属性】
技术研发人员：S拉戈，J杜富尔，N马吉德，
申请(专利权)人：奥兰治，
类型：发明
国别省市：法国;FR