CN101601269B - 用户媒体与通告媒体之间切换的方法，***及通告服务器 - Google Patents

Abstract

为了高效地处理用户媒体与通告媒体之间的切换，一个基本步骤(S1)是首先确定用户媒体的配置。接下来基于所确定的用户媒体配置来确定(S2)将要给出的通告媒体的配置。随后根据所述通告媒体配置来配置(S3)通告媒体，并且最后把所配置的通告媒体发送(S4)到预定的用户。这样，通告的总体外观或声音将与用户媒体的总体外观或声音几乎相同或者至少与之类似，并且优选地没有失真。这就允许用户尽可能清楚地感知通告。

Description

用户媒体与通告媒体之间切换的方法，***及通告服务器

技术领域

本发明总体上涉及现代通信网络中的通告技术，更具体地涉及处理通告媒体以及和用户媒体与通告媒体之间的切换相关的问题。

背景技术

通告在诸如电话服务之类的通信服务中扮演重要的角色。通告通常是预先录制的或者机器生成的媒体。例如可以用文本到语音功能(也叫作语音合成)或者文本到图像来生成机器生成的媒体。所述通告可以在通信网络中生成，或者由远程用户的交换台或计算机生成。

来自通信网络的通告的使用实例包括：

·当用户发起的命令无法被完成时的错误消息。例如：如果主叫方抑制了电话号码的呈现并且应答方定义了其在没有看到电话号码的情况下将不会应答呼叫，则***必须向主叫方给出错误消息。

·当用户暂停会话时，***可以向其他用户播放消息或等候音乐。

·在会议呼叫中，会议服务器可以在新用户进入会话或者在用户离开会话时给出通告，例如“JohnSmithhasenteredthemeeting(JohnSmith加入了会议)”以及“JohnSmithhasleftthemeeting(JohnSmith离开了会议)”。

·用户预先付费的订购即将用尽余额。运营商可以由于余额低而限制使用，并且希望在会话起始时或者在会话期间(其可能是非常长的会话)进行通告。

·在因特网上使用的越来越多的一种方法是在网页上给出具有个人识别码(或口令)的图像。所述个人识别码的图像被失真，从而使得自动文本识别***无法检测出所述个人识别码，而聪明的人类仍然可能读出字母和数字。使用这种方式来替代用(不安全的)电子邮件发送相应的个人识别码。

应答方对通告的使用实例包括：

·用户呼叫旅行社以便订票。可能会发生下面的场景：

1、用户与旅行***人交谈以便找出最佳的旅行选项。在这一步中，讨论在两个人之间进行。

2、在决定了旅行之后，请求用户键入其信用***。这是人机通信，其中用户听到预先录制的或者机器生成的消息，并且按下电话按钮(0-9)以便输入其号码。在这一过程中可能出现下面的语句：“Keyinyourcreditcardnumber(键入您的信用***)”，“Youhaveentered：1234567890123456.Ifthisiscorrectthenpress1，ifnotthenpress2.(您输入了1234567890123456。如果此号码正确则按1，如果错误则按2。)”，“Inserttheexpirationdateofyourcreditcard(输入您***的有效日期)”，“Youhaveentered：January1，2007(您输入了2007年1月1日)”。这些语句将由所述通告服务器生成。

3、在键入信用***和其他所需数据之后，继续与旅行***人的所述会话，以便决定进一步的旅行选项。

4、可以重复多次上述步骤。

·在用户购买了新的计算机之后，其呼叫服务台或联系中心以解决某些问题。在把所述呼叫连接到技师之前，服务台使用筛选过程来对问题进行分类。在这一筛选过程中，用户必须回答诸如以下的问题：“Ifyourproblemissoftwarerelatedthenpress‘1’andhash.Ifitishardwarerelatedthenpress‘2’.Ifitisunknownthenpress‘3’(如果您的问题是与软件相关的问题则按‘1’和井号。如果是与硬件相关的问题则按‘2’。如果是未知问题则按‘3’)”。在这一筛选过程之后，所述会话将被暂停，并且向用户播放一条等待消息。技师可以应答所述呼叫并且可以在任何时间点中断所述等待消息。

传统上，诸如提示和话音通告之类信息消息的生成是由电路交换***中的相对简单的基于时分复用(TDM)的通告机器执行的，其中利用常规的脉码调制(PCM)或自适应差分PCM(ADPCM)来达到编码和解码的目的。在现代的和将来的通信***中，处理通告的条件和要求将大大改变，并且因此总体上需要提供用于高效地处理这种通信***中的通告媒体的解决方案。

发明内容

本发明克服了现有技术设置的上述和其他缺陷。

本发明的一个总体目的是改进在通信网络环境中对通告媒体的处理。

本发明的一个目的是在没有令人烦恼的过渡和/或失真的情况下高效地处理用户媒体与通告媒体之间的切换，或者至少减少由于所述切换所导致的失真。

特别地，期望使得用户能够尽可能清楚地感知通告。

特别地，一个具体目的是提供一种用于在用户媒体与通告媒体之间进行切换的改进的方法和***。

另一个具体目的是提供一种用于通信网络的改进的通告服务器。

如所附的专利权利要求书所限定的那样，本发明可以满足上述和其他目的。

本发明的发明人已经认识到，由现代的通信网络所提供的多种不同的媒体配置可能会给通告服务器带来问题，这是因为与普通的用户媒体的声音或外观相比，所述通告媒体的总体声音或外观可能最终非常不同。这可能使用户非常烦恼。

为了处理用户媒体与通告媒体之间的切换，本发明的一个基本想法是首先确定用户媒体的配置，随后基于所确定的用户媒体配置来确定将要给出的通告媒体的配置。随后根据所述通告媒体配置来配置所述通告媒体，并且把所配置的通告媒体发送到预定用户。这样，所述通告的总体外观或声音将几乎与用户媒体的总体外观或声音相同或者至少与之相似，并且优选地没有失真，从而允许用户尽可能清楚地感知所述通告。

不过应当理解，本发明不限于语音或音频，而是同样可以应用于视频。

通常来说，用户媒体来自另一个远程用户，通告媒体则来自通告服务器或处理器。然而，应当注意到，所述通告服务器可以位于网络侧以作为基于网络的通告服务器，或者可以位于与所述远程用户相关联的用户侧(例如位于用户设备中或者位于专用小交换机(PBX)中)。

在本发明的一个优选的示例性实施例中，监控所考虑的用户之间的用户媒体的通信会话的设置，以便识别出一种或多种有效用户媒体配置，从该一种或多种有效用户媒体配置中可以选择或者通过其他方式确定合适的用户媒体配置。

优选地，监控用户通信以便检测出当前所使用的用户媒体配置，从而允许把通告媒体配置与当前的用户媒体配置相匹配。随后优选地通过令通告服务器把所配置的通告媒体***到所述会话中而把所配置的通告媒体转发到预定用户。可替换地，例如通过建立用于通告媒体的新会话而与用户媒体并行地发送所述通告媒体。

优选地，确定对应于用户媒体的编解码器和/或传输格式配置，并且随后基于把通告媒体的编解码器和/或传输格式配置与所述用户媒体的编解码器和/或传输格式配置相匹配来确定通告媒体配置。

在另一个方面中，本发明涉及一种用于通信网络的通告服务器。所述通告服务器基本上被配置成在所述网络内的通信会话中获得代表用户媒体的配置的媒体配置信息，并且基于所述媒体配置信息在所述会话中***通告媒体的配置。此外，所述通告媒体能够操作用于在所述会话中***所配置的通告媒体。

在阅读下面对本发明的各实施例的描述时将会认识到本发明所提供的其他优点。

附图说明

通过参考下面结合附图做出的描述，将会最好地理解本发明以及其进一步的目的和优点，其中：

图1是示出一种示例性***概观的示意图。

图2是示出在编码器状态被重置而解码器状态未被重置时的失真的示意图。

图3是示出在解码器状态被重置而编码器状态未被重置时的失真的示意图。

图4是根据本发明一个示例性实施例的用于在用户媒体与通告媒体之间进行切换的基本方法的示意性流程图。

图5是根据本发明另一个示例性实施例的用于在用户媒体与通告媒体之间进行切换的方法的示意性流程图。

图6是根据本发明一个示例性实施例的包括网络侧和用户侧的***概观。

图7是根据本发明另一个示例性实施例的示意性概观。

图8是根据本发明又一个示例性实施例的示意性概观。

图9是根据一个可能的优选实施例的通告服务器的示意性框图。

具体实施方式

在所有的图中，相同的附图标记将被用于相应的或类似的元件。

为了更好地理解本发明，从简要的***概观开始可能是有用的。

图1是示出一种示例性***概观的示意图。所述示例性***包括经由相关联的基站20-1、20-2和基于网络的通告服务器30进行通信的两个最终用户A和B的用户设备(UE)10-1、10-2。在这种情况下，诸如实时协议(RTP)[1]媒体流之类的媒体流总是经过所述通告服务器，所述通告服务器可以是媒体资源功能处理器(MRFP)[2]。在本例中，所述通告服务器用通告来替换来自用户A的RTP流，其中所述通告被称作带内通告。

其他引入通告的方式也是可能的，例如在A和B之间直接传送媒体而不经过所述通告服务器。在这种情况下，可以利用SIPINVITE(SIP邀请)[3]把所述通告从所述通告服务器发送到UE(用户设备)B，并且UEB必须丢弃从UEA接收的媒体以便生成从所述通告服务器接收的媒体。另一种替换方案是发送一条诸如SIPINFO(SIP信息)或SIPNOTIFY(SIP通知)消息之类的消息，该消息包括到所述通告媒体的链接(URL)。因此总体来说，一种替换方案是与用户媒体并行地发送通告媒体，其中可以建立也可以不建立用于所述通告媒体的新会话。

所述通告服务器可以位于电信网络中。在诸如IP多媒体子***(IMS)之类的现代***中，所述通告服务器通常将位于媒体资源功能处理器(MRFP)中，但是其也可以位于应用服务器(比如会议服务器)中。

还有可能令通告服务器处于端点中或者与端点靠近、处于用户设备中、处于计算机中或者处于专用小交换机(PBX)中。

通过仔细地分析，本发明的发明人发现现有的解决方案存在一个或多个问题，正如下面所描述的那样。

虽然通告在当今已有的电路交换***中可以工作，但是其工作良好的原因是因为所使用的编解码器通常是PCM[4]或ADPCM[5]。这些编解码器是逐样本的编解码器，其或者不使用任何预测(PCM)，或者使用数量非常有限的预测(ADPCM)。这意味着所述解码器将非常快速地从状态失配中恢复，因此这导致可听失真的可能性低。

此外，传统的***仅仅使用一种编解码器，例如PCM或ADPCM，但是从不使用全部二者。所述***还在整个会话期间使用相同的传输格式，例如其从不适配编解码器速率、帧聚合或冗余。实际上，所述***对于所有的会话都使用相同的配置。

在现代的和将来的***中，比如所述IP多媒体子***(IMS)以及特别是对于多媒体电话(MMTel)[6]来说，情况则完全不同。有可能发送几种类型的媒体。可以利用不同的编解码器和不同的速率来对所述媒体进行编码。还可以使用不同的传输格式，即净荷格式、有或没有帧聚合、有或没有冗余等等。需要这些变化来适配所述会话，从而降低网络拥塞的风险以及即使在拥塞时段期间也可以以合理的质量保持所述会话。这对于其中无线电信道显著变化的蜂窝***来说尤其重要。然而，这些变化将给所述通告服务器带来问题。所述通告服务器不能再像从前那样仅以一个单一方式来对通告媒体进行编码并且希望接收方会满意。如果UEA与UEB之间的媒体是通常使用宽带编解码器(AMR-WB)来编码的并且随后用窄带编解码器(自适应多速率AMR)来编码通告媒体，则所述媒体听起来将完全不同，并且接收用户将质疑所述通告为什么听起来与普通媒体如此不同。在最坏的情况下，接收用户将感到烦恼，并且可能更专注于媒体质量而不是实际的通告内容，这意味着他甚至可能会误解所述通告。

此外，使用现代的基于预测的编解码器可能在通告中断普通媒体时导致状态失配，从而导致可听的失真，这也可能会使用户感到烦恼。预测对于现代的编解码器来说非常重要，例如对于AMR[7]或AMR-WB[8]。使用帧间预测是为了降低比特率(即高压缩比)，同时仍然提供良好的质量。所述帧间预测要求把状态从帧传递到帧。当通告中断普通媒体时将出现状态失配，这是因为使用了编解码器两个不同的实例，一个编解码器实例被用在UEA中以用于来自用户的语音媒体，以及一个编解码器实例被用在所述通告服务器中。UEA中的状态已经根据所使用的预测发生了演变，而所述通告服务器中的状态则从初始化状态开始。取决于当前的内容，状态失配可能会导致或多或少地可听的失真。在图2和图3中示出这种失真的两个例子。全部两种情况下的失真都清楚地可听并且很容易被收听者注意到，但是图2中的尖峰信号要恼人得多。

从图2和3还可以看出，在异步重置之后需要花费大约100-200ms来恢复合成。而诸如PCM之类的无状态编解码器则将立即恢复，这是因为不需要把所述状态“累积”到适当的内容。

传统的电路交换***通常还具有声级上的控制，并且在其不合适时调节所述网络中的音量。VoIP***与多媒体电话一样可能没有这种功能，这是因为其想法是端到端地发送VoIP分组而不进行任何转码和其他类型的修改。因此对于VoIP来说，如果另一个用户说话声音太高或太低，则最终用户可能已经多次调节了音量。如果所述通告服务器在不检验音量的情况下***所述通告媒体，则整个消息都可能被错过，这是因为所给出的音量过低，或者因为所给出的音量过高以至于收听者必须立刻把电话从其耳边移开。

这些问题不限于语音。类似的问题对于音频和视频也会出现。对于这些情况，可以预期会出现更大的问题，这是因为用于这些媒体类型的编解码器通常具有比语音编解码器更高的压缩比，为了达到这种压缩比，其更加依赖于良好质量状态。

本发明的实施例涉及到这些问题当中的一个或多个。

下面将首先描述主要针对由现代通信网络中的各种各样潜在的媒体配置所带来的问题的说明性实施例的例子。其中的问题在于，与普通用户媒体的声音或外观相比，所述通告媒体的总体声音或外观可能最终非常不同。这可能会令用户非常烦恼。

图4是根据本发明一个示例性实施例的用于在用户媒体与通告媒体之间进行切换的基本方法的示意性流程图。为了高效地处理用户媒体与通告媒体之间的切换，一个基本步骤(S1)是首先确定用户媒体的配置。接下来基于所确定的用户媒体配置来确定(S2)将要给出的通告媒体的配置。随后根据所述通告媒体配置来配置(S3)通告媒体，并且最后把所配置的通告媒体发送(S4)到预定的用户。这样，通告的总体外观或声音将与用户媒体的总体外观或声音几乎相同或者至少与之类似，并且优选地没有失真。这就允许用户尽可能清楚地感知通告。例如，所述用户媒体和通告媒体可以具有语音、音频或视频的形式。

在本发明的一个优选的示例性实施例中，确定用户媒体的编解码器配置，随后优选地把通告媒体的编解码器配置与所确定的用户媒体的编解码器配置相匹配，这意味着对于通告媒体使用相同的或者至少类似的编解码器配置。这就提高了所述两种媒体对预定用户来说听起来或看起来相似的几率。例如，所述编解码器配置可以包括编解码器类型和编解码器模式，并且可选地还包括编解码器模式切换能力。

此外还有可能确定用户媒体的传输格式配置，并且尝试把通告媒体的传输格式配置与用户媒体的传输格式配置相匹配。这样，通告媒体将很可能不会受到传输损害的严重影响。

可选地，确定用户媒体的帧聚合及冗余格式配置，以便能够把通告媒体的帧聚合及冗余格式配置与用户媒体的帧聚合及冗余格式配置相匹配。

图5是根据本发明另一个示例性实施例的用于在用户媒体与通告媒体之间进行切换的方法的示意性流程图。

优选地，监控(S11)所考虑用户的用户设备之间的用户媒体的通信会话的设置，以便识别出可以从中选择或者以其他方式确定合适的用户媒体配置的一种或多种有效用户媒体配置。随后有利地监控(S12)所述会话中的用户通信，以便检测出有效用户媒体配置中当前所使用的有效用户媒体配置。随后把通告媒体配置与当前的用户媒体配置相匹配(S13)。可选地，例如通过考虑所述通告的紧急程度而确定(S14)用于把通告媒体***在所述会话中的合适定时。最后通过令通告服务器把所配置的通告媒体***(S15)在所述会话中而把所配置的通告媒体转发给预定用户。可替换地，例如通过建立用于通告媒体的新会话或者通过简单地发送具有到所述通告媒体的链接的控制消息来与用户媒体并行地发送通告媒体。

在这种特定情况下，通常在会话设置期间例如通过使用会话初始协议(SIP)中的会话描述协议(SDP)来协商所述会话的基本定义。举例来说，可以在SDP信令中定义多种可能的有效媒体配置并且将其与对应的标识符相关联。在一个特定的示例性实施例中，通过把净荷类型编号用作标识符，RTP分组的净荷类型字段可以被用来标识媒体配置。可以把该编号与一种有效媒体配置联系起来。优选地在会话设置(例如SIPINVITE(SIP邀请))期间以及/或者在会话重新配置(SIPUPDATE(SIP更新)或所谓的SIPRE-INVITE(SIP再邀请))时执行净荷类型编号与媒体配置的关联。在后续的通信期间，在发送诸如RTP分组之类的媒体分组时，可以监控所述净荷类型字段以便提取净荷类型编号，随后可以将其与当前所使用的媒体配置相关联。

作为举例，可以通过以下信息项当中的一项或几项来定义媒体配置：

·(多种)编解码器

例如：AMR、GSM-EFR(GSM增强型全速率)、EVRC(增强型可变速率编解码器)等等。

·(多种)编解码器模式(当适用时)

例如：对于AMR可以允许全部8种编解码器模式，或者所述编解码器模式的一个子集。

·编解码器模式切换能力(当适用时)

例如：对于AMR可以指定仅仅允许在相邻的编解码器模式之间进行编解码器模式切换，也就是说，如果例如允许所述AMR编解码器模式的一个子集，比如由比特率12.2、7.4、5.9和4.75kbps定义的编解码器模式，并且期望从比特率为12.2的编解码器模式切换到比特率为4.75的编解码器模式，则这种切换必须经过编解码器模式7.4和5.9。

·净荷格式(当适用时)

例如：对于AMR有两种基本选项，即带宽高效和八位位组对准。

·每个分组的推荐帧数

这通常不是严格的要求。

·每个分组的最大数据量

这通常是严格的要求。

因此，在会话设置时，通常指定不同的可能媒体配置的范围。通过简单地选择在会话设置期间所协商的媒体配置当中的任意一种，有可能获得适宜的但是通常次最优的解决方案。如果允许几种有效媒体配置，则一种更好的解决方案可以是提供一个优先级顺序，以表明优选地应当以何种顺序来使用各种配置。举例来说，如果允许示例性配置A、B和C，则还可以在SIPINVITE(SIP邀请)中指定优选的顺序为B、C、A。

然而，通过监控当前在用户通信期间正在使用的(多种)配置，有可能优化针对通告媒体的媒体配置选择。

举例来说，如果用户客户端感测到信道差并且例如通过使用最低可能比特率及添加冗余(这通过把同一帧发送几次而实现)而适配到最高鲁棒性，那么通过使用相同的或类似的配置来处理通告则将是最好的做法。否则默认的配置通常是从用于语音编码的最高可能比特率开始，随后执行朝向更高鲁棒性的适配。然而这种适配通常比较花时间，并且存在以下风险：即在所述适配达到对于用户媒体所使用的相同的对应鲁棒性水平之前，通告已经完成。通过使用本发明以及监控当前所使用的媒体配置，可以立即把通告媒体配置匹配到用户媒体配置。

如果通告服务器出于某种原因不支持在会话设置期间所指示的其中一些或全部(多种)有效媒体配置，则可以在所述通告服务器中基于该通告服务器所允许的配置(子集)做出关于可以使用哪种媒体配置的本地决定。

一般来说，用户媒体和通告媒体是针对第一网络元件，比如第一用户的用户设备。用户媒体通常来自第二网络元件，比如另一个远程用户的用户设备。通告媒体通常来自第三网络元件，比如通告服务器。然而，应当注意到，通告服务器可以位于网络侧以作为基于网络的通告服务器，或者可以位于与所述远程用户相关联的用户侧。在后一种情况下，所述第二网络元件和第三网络元件可以重合，或者至少彼此紧密联系。下面将描述本发明的各示例性实施例。

图6是根据本发明一个示例性实施例的包括网络侧和用户侧的***概观。基本上，两个用户A和B的用户设备(UE)10-1、10-2通过通信网络进行通信。在该特定实例中，所述通信经过通告服务器30，该通告服务器30把适当配置的通告***到所述用户之间的通信中。所述通告服务器30包括：用于确定用户媒体配置和通告媒体配置的模块32；保持一条或多条预先录制的或机器生成的通告的数据库34；用于配置通告媒体的模块36；以及用于利用所配置的通告媒体来替换用户媒体流的可控切换机制38。

优选地，所述通告服务器30被配置成监控用户之间的会话设置，以便识别出一种或多种有效用户媒体配置。关于有效用户媒体配置的信息通常与相关联的标识符一起被存储在与所述通告服务器相联系的表(未示出)中。所述通告服务器30于是可以按照多种不同的方式在这些媒体配置当中进行选择。在本发明的一个优选的示例性实施例中，在所述会话期间监控用户媒体分组，以便识别出当前所使用的用户媒体配置。优选地，这是通过从一个或多个媒体分组的分组报头中提取媒体配置标识符并且把该标识符映射到存储在所述有效用户媒体配置表中的特定用户媒体配置而执行的。

基于关于所指定的用户媒体配置的信息，随后有可能确定通告媒体的合适配置。一旦确定了通告媒体配置，就可以在所述配置模块36中相应地配置从所述数据库34检索的或者通过其他方式生成的所选通告。这通常包括根据所确定的配置对通告媒体进行编码和/或格式化。随后可以把所述通告媒体***到所述通信会话中。取决于具体情况，可能必须(或者可能没有必要)确定用于***所述通告的合适定时，正如后面将更加详细地解释的那样。

还可能有利的是在用户之间的通信会话期间监控其他控制信息(特别是对应于链接适配的反馈信息)，以便识别出对用户媒体配置的任何可能改变(比如改变编解码器模式或冗余模式)，从而允许根据关于用户媒体配置的最近信息来适配通告媒体的配置。

所述监控可以由所述通告服务器30或者与该通告服务器相关联的可选单元40来执行。

图7是根据本发明另一个示例性实施例的示意性概观。在该实例中，通过网络在用户10-1、10-2之间传送用户媒体，但是不直接经过所述通告服务器30。优选地，外部监控单元40监控所述会话设置并且可选地还监控用户通信和/或控制反馈，以便提供足够的信息供所述确定模块32确定用户媒体配置和通告媒体配置。随后根据所确定的通告媒体配置在所述配置模块36中配置从所述通告数据库34检索的或者通过其他方式生成的通告。例如通过使用SIPINVITE(SIP邀请)建立用于通告媒体的新会话，随后可以把所配置的通告从输出模块38发送到预定用户。除非所述预定用户(例如用户B)的用户设备支持多个会话，否则其随后通常必须丢弃来自用户A的用户媒体以便生成通告媒体。

图8是根据本发明又一个示例性实施例的示意性概观。在该例中，所述通告服务器驻留在用户侧。除了针对用户到用户通信的普通设备之外，用户A10-1的总体用户设备(UE)***还包括通告服务器(AS)或者能够提供通告媒体的等效的通告设备。所述总体用户设备***还包括媒体配置单元(MC)。基于关于用户媒体配置的信息，所述MC单元随后可以确定合适的通告媒体配置，并且相应地配置将为另一个用户B10-2给出的通告。所述总体用户***可以从用户媒体切换到通告媒体并且切换回来。

在又一个可替换实施例中，所述通告服务器被实施在与端点相联系的专用小交换机(PBX)中。

实际上，在所考虑的网络***中可以有多于一个通告服务器，并且本发明还能够按照与前面关于用户媒体与通告媒体之间的切换所描述的相同或类似方式来处理来自第一通告服务器的通告媒体与来自第二通告服务器的通告媒体之间的切换。举例来说，可以用来自PBX中的通告服务器的通告媒体来替换来自UE的用户媒体，并且可以用来自基于网络的通告服务器的通告媒体来替换所述来自PBX中的通告服务器的通告媒体。

下面将描述关于如何能够管理来自另一个(人类)用户的媒体与来自通告服务器的媒体之间的切换的其他示例性实施例。

举例来说，用户可能被涉及在对于媒体传输使用IP、UDP和RTP以及对于会话控制使用SIP的多媒体电话呼叫中。所述通告服务器可以位于电信网络中或者可以位于远程方(位置)处。

一个总体目标是确保两个媒体源和媒体类型之间的切换不令人烦恼。优选地，这意味着应当利用具有相似比特率的相似编解码器对通告媒体进行编码，以及应当利用与UEA和UEB之间的媒体类似的传输格式来传输通告媒体。这还意味着所述切换不应当产生任何失真，或者至少具有尽可能少的失真。这可以通过下面的示例性方法来完成：

所述通告服务器：

1、监控会话设置，以便确定可以在所述会话中使用什么样的编解码器。这在会话期间通常是静态信息，但是如果在会话期间重新协商了任何会话参数，则该信息可能被修改。

2、监控媒体分组和/或质量反馈，以便确定当前所使用的编解码器和传输格式。这是通常需要相当频繁地更新的时间信息，其可能不是对于每个单一分组被更新，但是至少是定期被更新。这些更新的频率取决于***负载。对于高***负载和/或变化的信道条件，可以预期需要相当频繁地适配用户之间的媒体。然而对于低***负载来说，适配应当不那么相当频繁。

3、确定用于通告媒体的合适的编码和传输格式。

4、确定在以下情况下如何产生合适的过渡。

a、如果通告应当使用渐显和渐隐的话。

b、如果应当添加空闲时段的话(静默、空白画面)。

c、如果需要强制解码器重置的话(编解码器归位(homing)，确保CRC将失败等等)。

5、确定关于应当何时***通告的合适定时。所述定时通常取决于通告的紧急程度。

6、***通告并且丢弃来自UEA的媒体。需要调节音量以便匹配来自UEA的媒体的音量。

7、在完成通告之后还确定如何创建到来自UEA的媒体合适的过渡。

注意，并不需要按照上述严格顺序来执行所有这些步骤。在一些情况下还有可能跳过这些步骤中的一些步骤。

为了更好地理解本发明，下面将参照图9更加详细地描述根据一个可能的优选实施例的通告服务器。

在该特定实例中，可以以下面的方式概括不同块的功能：

·优选地利用SIP进行UEA与UEB之间的会话设置。这确定可以在所述会话中使用什么样的媒体、应当如何对每一项媒体进行编码以及使用什么样的传输格式。下面是一些阐明实例：

-所述媒体是否是语音和/或视频和/或文本。

-对于每一项媒体使用什么样的编解码器。对于一项媒体可以允许几种编解码器。所述会话设置例如可以推断出对于会话中的语音允许AMR和AMR-WB二者。所述编解码器还可以包括几种编解码器模式。例如，AMR定义了8种编解码器模式。每一种编解码器模式具有其自身的比特率(12.2、10.2、7.95、7.4、6.7、5.9、5.15以及4.75kbps)。替换地，一些视频编解码器定义“简档”和“等级”，其确定应当如何对视频进行编码。

-使用什么样的净荷格式。每种编解码器具有其自身的净荷格式。一些净荷格式定义所述净荷格式的几种变型。举例来说：对于AMR和AMR-WB，所述净荷格式定义了带宽高效格式和八位位组对准格式二者。

-在编码器可以在任何时间点自由切换到所协商的任何模式的情况下，如何进行编解码器模式切换。对于具有电路交换服务的互通方案(例如UTRAN和GERAN中的AMR)，可能需要限制这种编解码器模式切换，以便匹配存在于UTRAN和/或GERANCS网络中的限制。

-因此通常可以按照几种不同的方式来配置媒体。对于在所述会话中所允许的每一种配置定义一个RTP净荷类型编号。注意，对于每一项媒体可以预期几种配置。

·媒体输入是来自UEA的媒体(语音、音频、视频、文本等等)。可替换地如前所述，所述媒体可以是来自另一个通告服务器的媒体。该媒体将被通告中断。通常使用RTP来传输所述媒体。

·媒体输出是被发送到UEB的媒体。

·UEB向UEA发送质量反馈或适配请求。所述质量反馈通常是用RTCP发送的，并且通常具有量度(分组丢失率、抖动等等)的形式。适配请求的例子有：编解码器模式请求、帧聚合请求、冗余请求以及视频帧的帧内刷新。所述反馈被发送方(UEA)使用来适配比特率、分组率以及冗余，以便减轻传输损害对所述媒体的影响。

-注意，人们不知道触发所述适配的传输限制是在UEA与通告服务器之间还是在通告服务器与UEB之间。但是为了最小化所述通告被服务器与UEB之间的任何传输损害严重损坏的风险，有益的是按照与来自UEA的媒体相同的方式对所述通告进行编码和格式化。

·会话和媒体分析器对会话设置和/或媒体和/或媒体反馈进行分析，以便检测出输入媒体的属性以及当前所使用的传输格式。所检测出的属性的例子有：

-(多种)媒体类型

-(多种)编解码器、(多种)编解码器速率或(多种)编解码器模式、帧聚合、冗余等等

-(多种)净荷格式

-媒体的声级、音量。这可能要求对媒体进行解码。为了避免总是执行解码器，不应当频繁进行这一分析，优选地在会话期间仅仅执行一次或少数几次。

-所述媒体是否空闲，例如静默、背景噪声、空白画面等等。进行这一检测的一种方式是验证当前是否正传送SIDUPDATE(SIP更新)帧，这意味着需要解析RTP分组(或者至少需要检查其尺寸)，但是这并不要求对该媒体进行解码。

-所述媒体是否活跃(active)，例如活跃语音、移动的图像等等。如果是的话则进行以下检测：

·所述媒体正在累积还是最近已经开始，例如紧接在语音开始之后。

·所述媒体是否渐隐，这在语句和词语的末尾发生。

-注意，根据情况，并不需要连续执行这一分析的所有部分，或者可能根本不需要执行。一些部分仅仅适用于会话设置，并且当重新协商会话时，优选地在所述会话期间监控其他部分(频繁程度更高或更低)。这一分析的一些部分可能需要对RTP分组进行解码。

·媒体数据库包含实际的通告媒体(语音、音频、视频、画面等等)

·媒体编码器和修改器(modifier)有能力对与来自UEA的媒体类似的媒体进行编码和/或格式化，举例来说：

-其可以使用不同的编解码器(AMR、AMR-WB、H.263[9]、H.264[10]等等)。

-其可以修改声学带宽(滤波到窄带、滤波到宽带、带宽扩展、屏幕尺寸、应用渐显和渐隐等等)。

-是否应当在开头和/或末尾添加空闲时段(静默、空白画面)。

-其还可以在通告的开头和末尾添加编解码器归位信息，以便在解码器中强制重置。

-调节音量级。

-使用不同的净荷格式。

-如果由UEA使用的话则应用帧聚合及冗余。

·通告命令向通告服务器通知以下事项：

-使用什么样的通告。

-通告的紧急程度，即立刻向用户给出所述通告有多重要，或者是否可以把所述通告延迟一会儿。

·可能的媒体修改方法列表是关于适用于每一种条件的什么样的媒体修改方法的描述(其由媒体分析器确定)。下面描述适用于不同条件的不同动作的例子。

·控制器接收关于媒体当前如何在UEA与UEB之间的会话中被格式化的通告命令以及信息。

-所述控制器确定应当如何对媒体进行编码(如果应当在发送前对其以任何方式进行修改的话)，以及应当如何在RTP分组中对已编码媒体进行格式化。该信息被发送到所述媒体编码器和修改器单元。

-所述控制器还确定何时将中断来自UEA的媒体以及何时将***通告媒体。

·如果紧急程度高，则其应当立刻中断来自UEA的媒体或者以最短的可能延迟中断。

·如果紧急程度低，则其应当等待直到其在来自UEA的媒体中检测到空闲时段。

所述通告命令还触发通告。这一触发可能源自几个不同的地方，正如在背景技术部分中所例示的那样。附加的例子包括可能想要中断呼叫以便向其中一方通知有紧急呼叫正在等待的话务员，或者可能想要提供“平滑中断”的网络运营商。举例来说，当其中一方移出覆盖范围时，所述运营商可能想要***“另一人已经移出覆盖范围”之类的通告，而不是简单地中断服务。

示例性媒体编码和修改方法

编码和传输格式

所述控制器应当把所述编码和传输格式与当前在UEA与UEB之间发送的媒体的编码和传输格式相匹配。

·所述控制器应当选择与当前在会话中所使用的相同的编解码器和编解码器模式/速率。

-如果通告媒体具有更高的声学带宽，则应当对其进行带通滤波以便匹配所选的编解码器。

-如果通告媒体具有更低的声学带宽，则应当应用带宽扩展。

-如果无法选择完全相同的编解码器或编解码器模式/速率，则其应当选择具有类似属性(声学带宽、比特率、帧率、编码质量等等)的编解码器。

·所述控制器应当选择与当前在会话中所使用的相同的帧聚合(每个分组的帧数)及冗余格式(在几个RTP分组中重复一帧)。

·所述控制器应当选择与当前在会话中所使用的相同的传输格式(RTP净荷类型、净荷格式、净荷格式版本)。

选择适当的编码格式可以提高两项媒体听起来几乎相同的几率。

选择适当的传输格式可以提高通告媒体将不会受到传输损害的严重影响的几率。

切换时的平滑过渡

如果通告消息没有那么重要并且如果通告服务器把所述消息设法保持到通告服务器检测出语音中的空闲时段，则在来自不同源的媒体之间进行切换时不应当需要特别的平滑。

如果通告消息非常重要，则通告服务器通常将中断来自UEA的媒体，即使在其活跃时也是如此。在这种情况下，所述通告服务器应当：

·对来自UEA的媒体应用渐隐(可能无法总是这样做)

·对通告媒体进行格式化，从而将触发对解码器状态的重置或者对几个帧的ECU动作，以便获得对解码器的逐渐重置，这例如是通过以下步骤实现的：

-对于AMR，这可以通过在通告媒体开始之前***编解码器归位帧来实现。其他编解码器可能不具有类似特征。

-确保CRC或校验和验证将失败。并非所有净荷格式都包括这种信息。需要对于多个帧重复这一解决方案，以便确保信号被足够好地静音。

-设置坏帧指示(BFI)比特，从而这将触发接收机中的ECU动作。并非所有净荷格式都包括这种信息。需要对于多个帧重复这一解决方案，以便确保信号被足够好地静音。

-***哑帧或空闲帧(NO_DATA(无数据)、静默、空白画面)。并没有针对所有编解码器定义NO_DATA。通告服务器可能必须对静默帧进行编码以便实现这一点。需要对于多个帧重复这一解决方案，以便确保信号被足够好地静音。

-由于这些方法的存在取决于编解码器，因此所述控制器需要决定什么样的动作适用于当前所使用的编解码器。

·调节通告媒体的音量，从而使其类似于来自UEA的媒体的音量。

·对于通告媒体应用渐显。

·当通告媒体的传送已经完成时以及在切换回到来自UEA的媒体时应当执行类似的动作。

注意，在通告媒体的开头或结尾可能需要平滑，或者在通告媒体的开头和结尾都需要平滑，或者根本不需要平滑。

正如上面已经解释过的那样，本发明不仅仅限于由电信网络***的通告。类似的通告还存在于大多数商业服务台中(“按1继续订购您的票。按2更改日期。按3与我们的销售人员交谈”)。在这种情况下，通告来自远程“用户”，并且所述远程“用户”可以在预先录制的消息和说话人之间进行切换。

由于媒体之间的切换而导致的失真可以被完全去除或者至少被减少。优选地把通告媒体的格式与用在对话中的媒体格式相匹配。这样将给出来自UEA的媒体与通告媒体之间的更令人满意的过渡。

在接收UE中，在MIPS和存储器方面还有复杂性优势，这是因为其不需要并行执行几个活跃的编解码器实例。

还应当理解，本发明不限于RTP媒体流，也不限于使用UDP作为传输协议，也不限于对于会话设置使用SIP。

上面描述的实施例仅仅是作为例子给出的，应当理解本发明不限于此。保留这里所公开并要求保护的基本原理的进一步修改、改变和改进都在本发明的范围内。

缩写

ADPCM自适应差分PCM

AMR自适应多速率

AMR-WB宽带AMR

BFI坏帧指示

CRC循环冗余码

CS电路交换

ECU错误隐藏单元

EVRC增强型可变速率编解码器

GERANGSMEDGE无线接入网

GSM全球移动通信***

GSM-EFRGSM增强型全速率

IMSIP多媒体子***

IP因特网协议

MIPS每秒百万指令

MMTel多媒体电话

MRFP媒体资源功能处理器

PCM脉码调制

PBX专用小交换机

PS分组交换

RTCP实时控制协议

RTP实时协议

SDP会话描述协议

SIP会话初始协议

TDM时分复用

UDP用户数据报协议

UMTS通用移动电信***

UTRANUMTS地面无线接入网

UE用户设备

VoIPIP语音

参考文献

[1]RFC3550，“RTP：ATransportProtocolforReal-TimeApplications”，H.Schulzrinne，S.Casner，R.FrederickandV.Jacobson.

[2]3GPPTS23.228，“IPMultimediaSubsystem(IMS)，Stage2”.

[3]RFC3261，“SIP：SessionInitiationProtocol”，RFC3261，June2002.Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，andE.Schooler，

[4]ITU-TRecommendationG.711，“PulseCodeModulation(PCM)ofVoiceFrequencies”.

[5]ITU-TRecommendationG.726，“40，32，24，16kbit/sAdaptiveDifferentialPulseCodeModulation(ADPCM)”.

[6]3GPPTS26.114.“IPMultimediaSubsystem(IMS)；MultimediaTelephony；Mediahandlingandinteraction”.

[7]3GPPTS26.071，“MandatorySpeechCodecspeechprocessingfunctions；AMRSpeechCODEC；Generaldescription”.

[8]3GPPTS26.171，“Speechcodecspeechprocessingfunctions；AdaptiveMultiRate-Wideband(AMR-WB)speechcodec；Generaldescription”.

[9]ITU-TRecommendationH.263，Videocodingforlowbitratecommunication..

[10]ITU-TRecommendationH.264，Advancedvideocodingforgenericaudiovisualservices.

Claims (20)

1.一种在预计送往通信网络中的第一网络元件的通告媒体和用户媒体之间进行切换的方法，其中所述用户媒体来自第二网络元件并且所述通告媒体来自第三网络元件，其中，所述方法包括以下步骤：

-基于监控用户通信以便检测出当前所使用的所述用户媒体的配置来确定所述用户媒体的配置；

-基于所确定的用户媒体配置来确定将要向所述第一网络元件给出的所述通告媒体的配置；

-根据所述通告媒体配置来配置所述通告媒体；

-把所述配置的通告媒体发送到所述第一网络元件；以及

其中，确定所述用户媒体的配置的所述步骤包括确定所述用户媒体的编解码器配置的步骤，并且确定所述通告媒体的配置的所述步骤是基于把所述通告媒体的编解码器配置与所述用户媒体的编解码器配置相匹配。

2.根据权利要求1所述的方法，其中，确定所述用户媒体的配置的所述步骤还包括确定所述用户媒体的传输格式配置的步骤，并且确定所述通告媒体的配置的所述步骤还基于把所述通告媒体的传输格式配置与所述用户媒体的传输格式配置相匹配。

3.根据权利要求1或2所述的方法，其中，确定所述用户媒体的配置的所述步骤还包括确定所述用户媒体的帧聚合以及冗余格式配置的步骤，并且确定所述通告媒体的配置的所述步骤还基于把所述通告媒体的帧聚合以及冗余格式配置与所述用户媒体的帧聚合以及冗余格式配置相匹配。

4.根据权利要求1所述的方法，其中，确定所述用户媒体的编解码器配置的所述步骤包括确定编解码器类型和编解码器模式。

5.根据权利要求4所述的方法，其中确定所述用户媒体的编解码器配置的所述步骤还包括确定编解码器模式切换能力。

6.根据权利要求1所述的方法，其中把所述配置的通告媒体发送到所述第一网络元件的所述步骤包括把所述配置的通告媒体***在为所述第一网络元件与所述第二网络元件之间的用户媒体设置的通信会话的步骤。

7.根据权利要求1所述的方法，其中，确定所述用户媒体的配置的所述步骤包括以下步骤：

-监控对于所述第一网络元件与所述第二网络元件之间的用户媒体的通信会话的会话设置，以便识别出多种有效用户媒体配置；以及

-基于监控所述会话中各网络元件之间的通信以便检测出所述有效用户媒体配置中的当前所使用的有效用户媒体配置来确定所述用户媒体的配置。

8.根据权利要求7所述的方法，其中，监控各网络元件之间的通信的所述步骤包括检测用于适配所述用户媒体的配置的信息以便允许适当地确定所述通告媒体的所述配置的步骤。

9.根据权利要求6所述的方法，其中，基于所述通告的紧急程度确定用于在所述会话中***所述通告媒体的时机，并且根据所述确定的时机把所述配置的通告媒体***在所述会话中。

10.根据权利要求6所述的方法，还包括以下步骤：当把所述通告媒体***在所述会话中时，应用过渡程序以用于所述用户媒体与所述通告媒体之间的平滑过渡。

11.根据权利要求1所述的方法，其中，所述第一网络元件包括第一用户的用户设备，所述第二网络元件包括第二用户的用户设备，并且所述第三网络元件包括通告服务器。

12.根据权利要求11所述的方法，其中，所述通告服务器位于网络侧和用户侧的其中之一处。

13.根据权利要求11所述的方法，其中，所述用户参与到使用用于媒体传输的实时协议(RTP)以及用于会话控制的会话初始协议(SIP)的多媒体会话中。

14.一种用于在通信网络内的通信会话中在用户媒体与通告媒体之间进行切换的***，其中所述***包括：

-用于基于监控用户通信以便检测出当前所使用的所述用户媒体的配置来确定用于所述通信会话的所述用户媒体的配置的装置；

-用于基于所确定的用户媒体配置来确定将要被***在所述会话中的所述通告媒体的配置的装置；

-用于根据所述通告媒体配置来配置所述通告媒体的装置；

-用于把所述配置的通告媒体***在所述会话中的装置；以及

其中，用于确定所述用户媒体的配置的所述装置包括用于确定所述用户媒体在所述会话中的编解码器配置的装置，以及用于确定所述通告媒体的配置的所述装置被配置成把所述通告媒体的编解码器配置与所述用户媒体的编解码器配置相匹配。

15.根据权利要求14所述的***，其中，用于确定所述用户媒体的配置的所述装置还包括用于确定所述用户媒体在所述会话中的传输格式配置的装置，以及用于确定所述通告媒体的配置的所述装置被进一步配置成把所述通告媒体的传输格式配置与所述用户媒体的传输格式配置相匹配。

16.根据权利要求14所述的***，其中，用于确定所述用户媒体在所述会话中的编解码器配置的所述装置包括用于确定编解码器类型和编解码器模式的装置。

17.根据权利要求14所述的***，其中，用于确定所述用户媒体的配置的所述装置包括：

-用于监控会话设置以便识别出多种有效用户媒体配置的装置；以及

-用于监控所述会话中各用户之间的通信以便检测出所述有效用户媒体配置中的当前所使用的有效用户媒体配置的装置。

18.根据权利要求14所述的***，还包括用于基于所述通告的紧急程度来确定用于在所述会话中***所述通告媒体的时机的装置，其中用于***所述配置的通告媒体的所述装置能够操作用于根据所述确定的时机来***所述通告媒体。

19.根据权利要求14所述的***，还包括用于在把所述通告媒体***在所述会话中时应用过渡程序以用于所述用户媒体与所述通告媒体之间的平滑过渡的装置。

20.根据权利要求14所述的***，其中，所述通信会话涉及不同用户的用户设备之间的通信，并且所述通告来自位于网络侧和用户侧的其中之一处的通告服务器。