IMS固话用户拨打VOLTE用户的放音方法和装置与流程

本发明涉及通信领域，尤其涉及一种ims固话用户拨打volte用户的放音方法和装置。

背景技术：

ims(ipmultimediasubsystem，ip多媒体子系统)是3gpp在r5中提出的一个全新的ip多媒体子系统，是在基于ip的网络上提供多媒体业务的通用网络架构，能为使用不同接入手段的用户提供融合的多媒体业务和互联网应用。volte(voice-over-lte，长期演进语音承载)俗称高清通话，是一种lte下解决语音的方案，其采用ip数据传输技术，即运行在ims系统中。

早媒体放音是指被叫摘机前，主叫侧等待被叫摘机期间，主叫侧听到的提示音。例如，彩铃业务，即当被用户叫签约彩铃业务时，主叫用户拨打被叫电话，在被叫用户摘机前，主叫用户将听到被叫用户开通的彩铃提示音；对于没有签约彩铃业务的被叫用户，主叫用户拨打被叫电话，在被叫用户摘机前，主叫用户将根据临时响应消息中的媒体放音参数指示，确定由主叫侧本地放音或被叫侧放音，并等待被叫接听电话。

根据目前rfc5009标准规范定义，早期媒体放音有gateway模式、app模式，国内三个运营商实际应用中都采用gateway模式。gateway模式是指整个早期媒体放音的控制全部集中在网络中作为网关的网元设备，使得终端不会感知到远端到底有多少个媒体源。标准中要求，一旦被叫侧返回的18*消息或update(更新)消息中带有p-early-media(p-早媒体)参数，就意味着被叫侧网络提供媒体资源，国内三个运营商实际应用中暂不考虑rfc5009中p-early-media取值为“inactive(去激活)”/“gated”的情况。p-early-media取值为sendonly(仅发送)为通用场景。

18*信息中p-early-media和sdp(sessiondescriptionprotocol，会话描述协议)的sendonly/sendresv区别：18*中p-early-media里面的sendonly等头域值和sdp中sendonly不同，不代表收发模式的意思，它们表示的是传输方向，sendonly表示从被叫侧到主叫侧方向的媒体，即后向早期媒体。同时，早期媒体头域与sdp同时出现时，也不会有冲突，早期媒体协带sendonly，仅仅告诉终端将自身的rtp(real-timetransportprotocol，实时传输协议)接收线程准备好，要想终端发送，而sdp中的sendonly是告诉终端的sdp，当终端什么时候准备发送数据时，按被告知的收发模式来处理。

ims域下固话用户和volte用户的核心网均基于ims架构，但两套ims系统完全独立。ims域下固话用户的承载设备(以下简称sip接入网关)和volte手机终端均集成了sip(sessioninitiationprotocol，会话初始协议)栈，以sip客户端的角色与ims系统间采用sip协议进行互通。作为sip客户端，按协议要求，需要具备放音能力(如回铃音、拨号音、拥塞音、保持音等)。

相关技术中，固网ims下挂固网网关用户发起呼叫时网关时，网关只对被叫侧返回的sip协议中的18*消息中是否携带带有媒体信息的sdp进行判断。若被叫侧返回的18*消息中有带媒体的sdp时，在被叫摘机接听之前，网关侧不对主叫用户进行放音，而是等待被叫侧播放的放音，即透传被叫侧的后向放音。若被叫侧返回的18*没有携带sdp信息，在被叫摘机接听之前，网关侧就给主叫用户播放网关本地的回铃音，网关不对被叫侧回的18*中是否携带p-early-media进行判断。目前大部分的网关都是采用这种处理机制。对于该类判断方式的网关用户拨打同一运营商没有签约被叫彩铃业务的volte用户时，在被叫用户摘机接听之前，主叫用户均听不到回铃音。

在相关协议规范中均有对ims域下固话用户发起呼叫的放音要求做了明确的规定。但不同网元对于协议规范的理解不完全一致，导致有部分ims核心网网元、业务平台不完全按规范要求对被叫侧返回的后向放音要求进行处理，例如个别网元启用p-early-media为gated的放音场景、个别网元针对彩铃放音中180ringing中不携带p-early-media头域、等等。如果网关严格按sip协议规范要求处理早媒体的放音处理，就会导致ims域下固话用户发起呼叫时，有些呼叫场景下主叫侧听不到正确的被叫侧的后向放音(如彩铃、回铃音、异常放音等)。此时ims域下的用户接入网关发起呼叫时，为了适配呼叫现网各种形态的被叫用户，只能在不完全符合sip协议规范放音要求的基础上以最大化的来适配、满足各种网元、各种被叫用户的后向放音处理要求。

另外，在volte用户入网后，volte侧相关网元严格按sip协议规范进行放音处理。没有被叫彩铃的volte用户发起呼叫时，volte侧返回给主叫侧的第一个183带媒体信息的sdp头域、没有带p-early-media头域，且不给主叫侧播放回铃音。例如，同一运营商下的固网ims下挂固网网关用户发起呼叫拨打没有被叫彩铃的volte用户时，在被叫摘机接听之前，按网关现有的处理机制是要听被叫侧播放的回铃音，但实际上此时volte侧不给主叫侧播放回铃音，导致主叫侧听不到任何声音。

技术实现要素：

本发明要解决的一个技术问题是提供ims固话用户拨打volte用户的放音方法和装置，能够解决ims域下固话用户拨打同一运营商下的volte用户听不到回铃音的问题。

根据本发明一方面，提出一种ip多媒体子系统ims固话用户拨打长期演进语音承载volte用户的放音方法，包括：判断被叫侧返回的呼叫请求响应消息是否携带早媒体参数；若被叫侧返回的呼叫请求响应消息携带早媒体参数，则根据被叫侧是否在第一预定时间内返回实时传输协议rtp媒体流信息确定对主叫侧的放音处理方式。

可选地，根据被叫侧是否在第一预定时间内返回rtp媒体流信息确定对主叫侧的放音处理方式包括：若被叫侧在第一预定时间内返回rtp媒体流信息，则透传被叫侧放音；若被叫侧在第一预定时间内未返回rtp媒体流信息，则向主叫侧播放网关本地的回铃音。

可选地，判断被叫侧返回的呼叫请求响应消息是否携带早媒体参数包括：判断被叫侧返回的呼叫请求响应消息是否携带早媒体头域或会话描述协议sdp头域。

可选地，呼叫请求响应消息包括180振铃消息和183会话过程消息，放音方法还包括：若180振铃消息中没有携带早媒体头域或sdp头域，或者183会话过程消息中的早媒体参数为inactive状态，则向主叫侧播放网关本地的回铃音。

可选地，该放音方法还包括：若183会话过程消息中没有携带早媒体头域或sdp头域，则不进行处理，等待第二预定时间后再次接收被叫侧返回的18*信息。

根据本发明的另一方面，还提出一种ims固话用户拨打volte用户的放音装置，包括：早媒体参数判断单元，用于判断被叫侧返回的呼叫请求响应消息是否携带早媒体参数；放音处理单元，用于若被叫侧返回的呼叫请求响应消息携带早媒体参数，则根据被叫侧是否在第一预定时间内返回实时传输协议rtp媒体流信息确定对主叫侧的放音处理方式。

可选地，放音处理单元用于若被叫侧在第一预定时间内返回rtp媒体流信息，则透传被叫侧放音；若被叫侧在第一预定时间内未返回rtp媒体流信息，则向主叫侧播放网关本地的回铃音。

可选地，早媒体参数判断单元用于判断被叫侧返回的呼叫请求响应消息是否携带早媒体头域或会话描述协议sdp头域。

可选地，呼叫请求响应消息包括180振铃消息和183会话过程消息，其中，放音处理单元用于若180振铃消息中没有携带早媒体头域或sdp头域，或者183会话过程消息中的早媒体参数为inactive状态，则向主叫侧播放网关本地的回铃音。

可选地，放音处理单元用于若183会话过程消息中没有携带早媒体头域或sdp头域，则不进行处理，等待第二预定时间后再次接收被叫侧返回的18*信息。

根据本发明的另一方面，还提出一种实现ims固话用户拨打volte用户的放音装置，包括：存储器；以及耦接至存储器的处理器，处理器被配置为基于存储在存储器的指令执行如上述的实现ims固话用户拨打volte用户的放音方法。

根据本发明的另一方面，还提出一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现上述的实现ims固话用户拨打volte用户的放音方法的步骤。

与现有技术相比，本发明ims域下固话用户的接入网关侧通过对呼叫请求响应消息中的早媒体参数携带情况，以及在预定时间内参考被叫侧rtp媒体流的发送情况来确定对主叫侧的放音处理方式，能够在不对现有sip协议放音规范进行修改、又能适配现网相关网元的放音处理机制的前提下，能够解决ims域下固话用户拨打同一运营商下的volte用户听不到回铃音的问题。

通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得清楚。

附图说明

构成说明书的一部分的附图描述了本发明的实施例，并且连同说明书一起用于解释本发明的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本发明，其中：

图1为本发明ims固话用户拨打volte用户的放音方法的一个实施例的流程示意图。

图2为本发明ims固话用户拨打volte用户的放音方法的另一个实施例的流程示意图。

图3为一个实施例中某次呼叫中180ringing消息同时携带了p-early-media头域或sdp头域的信令示意图。

图4为一个实施例中某次呼叫中183sessionprogress消息同时携带了p-early-media头域或sdp头域的信令示意图。

图5为一个实施例中某次呼叫中180ringing消息只携带sdp头域的信令示意图。

图6为一个实施例中某次呼叫中183sessionprogress消息只携带p-early-media头域为sendonly的信令示意图。

图7为一个实施例中某次呼叫中183sessionprogress消息只携带sdp头域的信令示意图。

图8为本发明ims固话用户拨打volte用户的放音装置的一个实施例的结构示意图。

图9为本发明ims固话用户拨打volte用户的放音装置的另一个实施例的结构示意图。

图10为本发明ims固话用户拨打volte用户的放音装置的再一个实施例的结构示意图。

具体实施方式

现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

图1为本发明ims固话用户拨打volte用户的放音方法的一个实施例的流程示意图。该实施例可以由网关执行。

在步骤110，判断被叫侧返回的呼叫请求响应消息是否携带早媒体参数。即判断被叫侧返回的18*信息中是否携带p-early-media头域或sdp头域。

ims域下固话用户拨打同一运营商下的volte用户时，在被叫侧未摘机接听前，网关侧会接收到被叫侧返回的18*信息，根据18*信息可以确定是否携带p-early-media头域或sdp头域。

在步骤120，若被叫侧返回的呼叫请求响应消息中携带早媒体参数，则根据被叫侧是否在第一预定时间内返回rtp媒体流信息确定对主叫侧的放音处理方式。

例如，若被叫侧在预定时间内返回rtp媒体流信息，则透传被叫侧放音；若被叫侧在第一预定时间内未返回rtp媒体流信息，则向主叫侧播放网关本地的回铃音。其中，第一预定时间可以根据实际情况进行设定，例如，设定为3秒。

在该实施例中，ims域下固话用户的接入网关侧通过对呼叫请求响应消息中的早媒体参数携带情况，以及在预定时间内参考被叫侧rtp媒体流的发送情况来确定对主叫侧的放音处理方式，能够在不对现有sip协议放音规范进行修改、又能适配现网相关网元的放音处理机制的前提下，能够解决ims域下固话用户拨打同一运营商下的volte用户听不到回铃音的问题。

图2为本发明ims固话用户拨打volte用户的放音方法的另一个实施例的流程示意图。

在步骤210，下挂在固网ims域下的网关用户做主叫发起呼叫时，在被叫侧未摘机接听前，网关接收被叫侧返回的18*信息。

在步骤220，判断被叫侧返回的18*信息是否携带p-early-media头域或sdp头域，若是，则执行步骤230，否则，执行步骤240。

在一个实施例中，如图3所示，某次呼叫中180ringing消息携带了p-early-media头域或sdp头域的信令，其中携带的p-early-media头域为sendonly参数，sdp头域的mediaattribute(媒体属性)为sendrecv(发送和接收)参数。

在另一个实施例中，如图4所示，某次呼叫中183sessionprogress消息同时携带了p-early-media头域或sdp头域的信令，其中携带的p-early-media头域为sendonly，sdp头域的mediaattribute为sendrecv。

在步骤230，判断被叫侧是否在第一预定时间内返回rtp媒体流信息，若是，则执行步骤231，否则，执行步骤232。

在步骤231，透传被叫侧放音。即若网关收到被叫侧的rtp媒体流信息，则由被叫侧对应的网元给主叫侧播放放音。主叫侧听被叫侧网元播放的放音。

例如，如图5所示，某次呼叫中180ringing消息只携带sdp头域的信令举例，在1秒左右，网关就收到被叫侧返回rtp媒体流，此时网关侧透传被叫侧的放音，即主叫侧会听到rtp媒体流中所携带的放音。

在另一个实施例中，如图6所示，某次呼叫中183sessionprogress消息只携带p-early-media头域为sendonly的信令，在2秒内，网关收到被叫侧返回rtp媒体流，此时网关侧透传被叫侧的放音，即主叫侧会听到rtp媒体流中所携带的放音。

在步骤232，向主叫侧播放网关本地的回铃音。例如，若收到18*早媒体之后的3秒没有收到被叫侧返回的rtp媒体流，则网关侧就给主叫侧播放网关本地的回铃音。主叫侧听主叫网关侧播放的回铃音。

在一个实施例中，如图7所示，某次呼叫中183sessionprogress消息只携带sdp头域的信令举例，超过3秒网关仍没有收到被叫侧返回的rtp媒体流，网关则需主动给主叫侧播放网关本地的回铃音。

在步骤240，若180ringing中没有携带p-early-media头域或sdp头域，或者183sessionprogress消息中的p-early-media为inactive状态，则向主叫侧播放网关本地的回铃音。主叫侧听主叫网关侧播放的回铃音。

在步骤250，若183sessionprogress消息中没有携带p-early-media头域或sdp头域，则不进行处理，等待第二预定时间后再次接收被叫侧返回的18*信息。其中，第二预定时间可以根据实际情况具体设定，在一个实施例中，例如为60秒。

在一个实施例中，若183sessionprogress消息中没有携带p-early-media头域或sdp头域，网关需一直等待后续的18*信息，在60s定时器等待过程中，即使收到被叫侧发送的rtp媒体流，网关都不做处理、不放本地回铃音，网关收到后续18*信息时重新执行步骤220。

在该实施例中，对相关协议规范、不对现网相关网运的配置进行修改，只是在ims域下固话用户的接入网关层面通过对sip协议的相关早媒体、rtp媒体流以及相关定时器进行综合判断处理，决定是播放被叫侧放音还是播放本地回铃音，基于被叫用户的不同状态给主叫用户播放不同的回铃音。能够实现ims域下固话用户发起呼叫时，既要保持ims域下固话用户拨打非volte用户的放音现状不变，又满足ims域下固话用户拨打volte用户时能听到正常的后向放音。

图8为本发明ims固话用户拨打volte用户的放音装置的一个实施例的结构示意图。该放音装置可以为网关，包括早媒体参数判断单元810和放音处理单元820。

早媒体参数判断单元810用于判断被叫侧返回的呼叫请求响应消息是否携带早媒体参数；即判断被叫侧返回的18*信息中是否携带p-early-media头域或sdp头域。

放音处理单元820用于若被叫侧返回的18*信息携带早媒体参数，则根据被叫侧是否在第一预定时间内返回rtp媒体流信息确定对主叫侧的放音处理方式。

例如，若被叫侧在预定时间内返回rtp媒体流信息，则透传被叫侧放音；若被叫侧在第一预定时间内未返回rtp媒体流信息，则向主叫侧播放网关本地的回铃音。其中，第一预定时间可以根据实际情况进行设定，例如，设定为3秒。

在本发明的另一个实施例中，放音处理单元820用于若180振铃消息中没有携带早媒体头域或sdp头域，或者183会话过程消息中的早媒体参数为inactive状态，则向主叫侧播放网关本地的回铃音；若183会话过程消息中没有携带早媒体头域或sdp头域，则不进行处理，等待第二预定时间后再次接收被叫侧返回的18*信息。

在上述实施例中，ims域下固话用户的接入网关侧通过对18*信息中的早媒体参数携带情况，以及在预定时间内参考被叫侧rtp媒体流的发送情况来确定对主叫侧的放音处理方式，能够在不对现有sip协议放音规范进行修改、又能适配现网相关网元的放音处理机制的前提下，可以解决ims域下固话用户拨打非volte用户时可以正常听到放音，拨打同一运营商下没有被叫彩铃的volte用户在被叫摘机接听前主叫侧听不到回铃音的放音问题，给客户带来更好的业务体验。

图9为本发明ims固话用户拨打volte用户的放音装置的另一个实施例的结构示意图。该放音装置：存储器910和处理器920。其中：存储器910可以是磁盘、闪存或其它任何非易失性存储介质。存储器910用于存储图1、2所对应实施例中的指令。处理器920耦接至存储器910，可以作为一个或多个集成电路来实施，例如微处理器或微控制器。该处理器920用于执行存储器中存储的指令。

在一个实施例中，还可以如图10所示，该装置1000包括存储器1010和处理器1020。处理器1020通过bus总线1030耦合至存储器1010。该装置1000还可以通过存储接口1040连接至外部存储装置1050以便调用外部数据，还可以通过网络接口1060连接至网络或者另外一台计算机系统(未标出)，此处不再进行详细介绍。

在该实施例中，通过存储器存储数据指令，再通过处理器处理上述指令，能够解决ims域下固话用户拨打非volte用户时可以正常听到放音，拨打同一运营商下没有被叫彩铃的volte用户在被叫摘机接听前主叫侧听不到回铃音的放音问题。

在另一个实施例中，一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现图1-2所对应实施例中的方法的步骤。本领域内的技术人员应明白，本公开的实施例可提供为方法、装置、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本公开是参照根据本公开实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

至此，已经详细描述了本公开。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。

虽然已经通过示例对本发明的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本发明的范围。本领域的技术人员应该理解，可在不脱离本发明的范围和精神的情况下，对以上实施例进行修改。本发明的范围由所附权利要求来限定。