基于IP电话的留言业务处理方法及装置

摘要

本发明提供了一种基于IP电话的留言业务处理方法及装置，其中，该方法包括：监测第一终端和第二终端在呼叫过程中的媒体传输状态；在监测到所述第二终端与业务服务器的媒体传输状态中断时，通过所述业务服务器继续接收所述第一终端传输的留言内容；通过所述业务服务器将接收的所述留言内容发送给所述第二终端。采用本发明提供的上述技术方案，解决了相关技术中，在通话双方的一端通话中断时，中断方无法继续接收对端传输的留言内容等问题，能够有效提高应用可靠性，同时提高系统资源利用率。

说明书

技术领域

本发明涉及通信领域，具体而言，涉及一种基于互联网协议(Internet Protocol，简称为IP) 电话的留言业务处理方法及装置。

背景技术

IP电话是一种通过互联网或其他使用IP技术的网络，来实现新型的电话通讯。随着互联 网日渐普及，以及跨境通讯数量大幅飙升，IP电话亦被应用在长途电话业务上。由于世界各 主要大城市的通信公司竞争加剧，以及各国电信相关法令松绑，IP电话也开始应用于固网通 信，其低通话成本、低建设成本、易扩充性及日渐优良化的通话质量等主要特点，被目前国 际电信企业看成是传统电信业务的有力竞争者。

IP电话通常的形式是利用Internet网络进行的语音通信，很多运营商都部署了多媒体子 系统(Multimedia subsystem，简称为IMS)网络用来支持IP通话。IP多媒体子系统是第3 代移动通信伙伴组织(3rd Gerneration Partnership Project,简称为3GPP)Release5版本标准中 提出的支持IP多媒体业务的子系统。它基于会话初始协议(Session Initiation Protocol,简称为 SIP)的体系，SIP是按客户端/服务器方式工作的基于文本的信令协议，IMS使用SIP呼叫 控制机制来创建、管理和终结各种类型的多媒体业务，这其中就包含了IP通话业务。

现有的IP通话方案中存在以下问题：用户A和B在通话建立后进行媒体传输的过程中， 如果因为网络的问题导致通话一方(假设B)掉网了，此时通话就中断了，B无法再获取A 后续传输的媒体内容。如果A后续(即B掉网后)需要传输的媒体内容对A和B都非常重要 并且具有实时性特征(即错过了就不可复制)，就会给A和B带来极大的不便。

针对相关技术中的上述问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中，在通话双方的一端通话中断时，中断方无法继续接收对端传输的留言 内容等问题，本发明提供了一种基于IP电话的留言业务处理方法及装置，以至少解决上述问 题。

根据本发明的一个方面，提供了一种基于互联网协议IP电话的留言业务处理方法，包括： 监测第一终端和第二终端在呼叫过程中的媒体传输状态；在监测到上述第二终端与业务服务 器的媒体传输状态中断时，通过上述业务服务器继续接收上述第一终端传输的留言内容；通 过上述业务服务器将接收的上述留言内容发送给上述第二终端。

优选地，通过上述业务服务器继续接收上述第一终端传输的留言内容之前，包括：通过 上述业务服务器向上述第一终端发送通知消息，其中，上述通知消息中携带有用于提示上述 第一终端是否进行留言的提示信息；根据上述提示信息确定上述第一终端是否继续传输上述 留言内容，其中，在确定为是的情况下，上述第一终端向上述业务服务器传输上述留言内容。

优选地，通过上述业务服务器继续接收上述第一终端传输的留言内容之前，包括：通过 上述第二终端向上述业务服务器发送通知消息，其中，上述通知消息中携带有用于提示上述 第一终端是否进行留言的提示信息；根据上述提示信息确定上述第一终端是否继续传输上述 留言内容，其中，在确定为是的情况下，上述第一终端向上述业务服务器传输上述留言内容。

优选地，通过上述业务服务器继续接收上述第一终端传输的留言内容，包括：通过上述 业务服务器保存接收的上述留言内容；在确定上述第一终端传输结束时，将接收的上述留言 内容封装成指定格式的信息；将封装得到的上述信息发送给上述第一终端。

优选地，将接收的上述留言内容封装成指定格式的信息，包括：将接收的上述留言内容 保存为文件并生成统一资源定位符URL的链接信息，其中，上述链接信息为需要向上述第二 终端发送的信息。

优选地，通过上述业务服务器保存接收的上述留言内容，包括：通过上述业务服务器保 存上述第二终端在发送最后1个保活报文后接收的所有上述留言内容，其中，上述保活报文 是指上述第二终端在媒体传输过程中每隔预定时间段向业务服务器发送的业务信令，该业务 信令用于通知上述业务服务器上述第二终端处于在线状态。

根据本发明的另一个方面，提供了一种基于互联网协议IP电话的留言业务处理装置，包 括：监测模块，用于监测第一终端和第二终端在呼叫过程中的媒体传输状态；接收模块，用 于在监测到上述第二终端与业务服务器的媒体传输状态中断时，通过上述业务服务器继续接 收上述第一终端传输的留言内容；第一发送模块，用于通过上述业务服务器将接收的上述留 言内容发送给上述第二终端。

优选地，上述装置包括：第二发送模块，用于通过上述业务服务器向上述第一终端发送 通知消息，其中，上述通知消息中携带有用于提示上述第一终端是否进行留言的提示信息； 第一确定模块，用于根据上述提示信息确定上述第一终端是否继续传输上述留言内容，其中， 在确定为是的情况下，上述第一终端向上述业务服务器传输上述留言内容。

优选地，上述装置包括：第三发送模块，用于通过上述第二终端向上述业务服务器发送 通知消息，其中，上述通知消息中携带有用于提示上述第一终端是否进行留言的提示信息； 第二确定模块，用于根据上述提示信息确定上述第一终端是否继续传输上述留言内容，其中， 在确定为是的情况下，上述第一终端向上述业务服务器传输上述留言内容。

优选地，上述接收模块，包括：保存单元，用于通过上述业务服务器保存接收的上述留 言内容；封装单元，用于在确定上述第一终端传输结束时，将接收的上述留言内容封装成指 定格式的信息；发送单元，用于将封装得到的上述信息发送给上述第一终端。

通过本发明，采用在监测到第二终端的媒体传输状态中断时，通过业务服务器继续接收 第一终端传输的留言内容，进而通过业务服务器将留言内容发送给第二终端，解决了相关技 术中，在通话双方的一端通话中断时，中断方无法继续接收对端传输的留言内容等问题，能 够有效提高应用可靠性，同时提高系统资源利用率。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示 意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为根据本发明实施例的基于IP电话的留言业务处理方法的流程图；

图2为根据本发明实施例的基于IP电话的留言业务处理装置的结构框图；

图3为根据本发明实施例的基于IP电话的留言业务处理装置的另一结构框图；

图4为根据本发明优选实施例的终端间呼叫建立的流程示意图；

图5为根据本发明优选实施例的基于IP电话的留言业务处理方法的流程示意图；

图6为根据本发明优选实施例的基于IP电话的留言业务处理方法的另一流程示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下， 本申请中的实施例及实施例中的特征可以相互组合。

以下实施例可以应用到计算机中，例如应用到PC中。也可以应用到目前采用了智能操作 系统中的移动终端中，并且并不限于此。对于计算机或移动终端的操作系统并没有特殊要求。 例如，以下实施例可以应用到Windows操作系统中。

图1为根据本发明实施例的基于IP电话的留言业务处理方法的流程图。如图1所示，该 方法包括以下处理步骤：

步骤S102，监测第一终端和第二终端在呼叫过程中的媒体传输状态；

步骤S104，在监测到第二终端与业务服务器的媒体传输状态中断时，通过业务服务器继 续接收第一终端传输的留言内容；其中，该留言内容可以包括但不限于：文字、语言、视频、 图像；

在本实施例中，在通过业务服务器继续接收上述第一终端传输的留言内容之前，需要取 得第一终端的授权以使得第一终端继续向第二终端发送留言内容，具体可以通过以下两种实 现方式：

第一种实现方式

通过业务服务器向第一终端发送通知消息，其中，上述通知消息中携带有用于提示第一 终端是否进行留言的提示信息；根据上述提示信息确定第一终端是否继续传输上述留言内容， 其中，在确定为是的情况下，第一终端向业务服务器传输上述留言内容。

事实上，该种实现方式可以对应于但不限于以下场景：因为网络环境的原因，第二终端 失去了网络连接。

第二种实现方式

通过第二终端向业务服务器发送通知消息，其中，上述通知消息中携带有用于提示第一 终端是否进行留言的提示信息；根据上述提示信息确定第一终端是否继续传输上述留言内容， 其中，在确定为是的情况下，第一终端向业务服务器传输上述留言内容。

事实上，该种实现方式可以对应于但不限于以下场景：第二终端主动结束通话，并且， 第二终端又希望收到第一终端后续传输的留言内容。

步骤S106，通过业务服务器将接收的上述留言内容发送给第二终端。

步骤S106可以通过以下处理过程实现：通过上述业务服务器保存接收的上述留言内容； 在确定上述第一终端传输结束时，将接收的上述留言内容封装成指定格式的信息；将封装得 到的上述信息发送给上述第一终端。具体地，可以将接收的上述留言内容保存为文件并生成 统一资源定位符URL的链接信息，上述链接信息为需要向上述第二终端发送的信息。

在本实施例中，通过上述业务服务器保存接收的上述留言内容可以包括但不限于以下处 理过程：通过上述业务服务器保存在第二终端发送最后1个保活报文后接收的所有上述留言 内容，其中，上述保活报文是指第二终端在媒体传输状态中断每隔预定时间段向业务服务器 发送的业务信令，该业务信令用于通知业务服务器第二终端处于在线状态。

在本实施例中还提供了一种基于IP电话的留言业务处理装置，用于实现上述实施例及优 选实施方式，已经进行过说明的不再赘述，下面对该装置中涉及到的模块进行说明。如以下 所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述 的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。 图2为根据本发明实施例的基于IP电话的留言业务处理装置的结构框图。如图2所示，该装 置包括：

监测模块20，用于监测第一终端和第二终端在呼叫过程中的媒体传输状态；

接收模块22，连接至监测模块20，用于在监测到第二终端与业务服务器的媒体传输状态 中断时，通过业务服务器继续接收第一终端传输的留言内容；

第一发送模块24，连接至接收模块22，用于通过业务服务器将接收的上述留言内容发送 给第二终端。

可选地，在本实施例中，如图3所示，上述装置还可以包括以下处理模块：

第二发送模块26，用于通过业务服务器向第一终端发送通知消息，其中，上述通知消息 中携带有用于提示第一终端是否进行留言的提示信息；第一确定模块28，连接至第二发送模 块26，用于根据上述提示信息确定第一终端是否继续传输上述留言内容，其中，在确定为是 的情况下，第一终端向业务服务器传输上述留言内容。

可选地，如图3所示，上述装置还可以包括：第三发送模块30，用于通过第二终端向业 务服务器发送通知消息，其中，上述通知消息中携带有用于提示第一终端是否进行留言的提 示信息；第二确定模块32，连接至第三发送模块30，用于根据上述提示信息确定第一终端是 否继续传输上述留言内容，其中，在确定为是的情况下，第一终端向业务服务器传输上述留 言内容。

在本实施例的一个优选实施方式中，如图3所示，接收模块22，包括：保存单元220， 用于通过业务服务器保存接收的上述留言内容；封装单元222，连接至保存单元220，用于在 确定第一终端传输结束时，将接收的上述留言内容封装成指定格式的信息；发送单元224，连 接至封装单元222，用于将封装得到的上述信息发送给第一终端。

需要说明的是，上述各个模块是可以通过硬件来实现的。例如：一种处理器，包括上述 各个模块，或者，上述各个模块分别位于一个处理器中，也可以两个或多个模块位于同一处 理器中。

为了更好地理解上述实施例，以下结合一个优选实施例详细说明。

首先，说明一下本实施例涉及的呼叫建立流程：

本实施例涉及到的IP通话信令可以采用任和一种现有的实现技术，在具体实施过程中， 以SIP以及会话描述协议(Session Description Protocol，简称为SDP)作为会话交互以及媒体 协商使用到的协议，本实施例涉及到的实时媒体传输技术可以采用任何一种现有的实现技术， 在具体实施过程中采用的是实时传输协议(Real-time Transport Protocol，简称为RTP)。本文 设计到的文件下载技术可以采用任何一种现有的实现技术，在具体实施过程中采用的超文本 传输协议(Hypertext Transfer Protocol，简称为HTTP)。本实施例的呼叫建立流程如图4所示：

本实施例采用SIP协议进行呼叫信令的建议，步骤S402～S412完成呼叫建立流程，依据 SIP协议发送请求和响应建立终端A、B以及业务服务器之间的呼叫关系。步骤S402～S412的 关键点在于终端A在步骤S402中的携带的报文如表1所示：

表1

服务器收到A的呼叫请求报文后通过步骤S404转发给终端B。终端B通过步骤S406发 送如表2所示的应答报文给A。

表2

服务器通过步骤S402～S406记录下了终端A和终端B各自需要的会话保活时间。

服务器通过步骤S408将B的应答转发给A，A通过步骤S410发送如下的应答响应给服 务器。

表3

服务器将此应答响应通过步骤S412转发给终端B。

至此，终端A和终端B通过服务器建立起了IP媒体通话。开始进行步骤S414的双向媒 体传输。

当呼叫刚建立后，业务服务器通过S416A和S416B开始分别保存A和B发送的媒体流。

当呼叫建立后30秒开始的时候，A和B分别通过步骤S418A和S418B向服务器发送会 话保活请求报文，当服务器收到A和B的保活请求报文后，开始通过步骤S420A和步骤S420B 覆盖保存之前A和B发送的媒体流，即正常情况下，服务器分别保存A和B各30秒左右的 媒体内容。

下面说明基于IP电话动态留言业务的方案。该方案包括了涉及通话和留言业务的终端和 业务服务器。主要内容是：当终端A和B进行基于IP的语音或视频通话以及基于IP的视频 共享的过程中(A和B已经完成呼叫建立的流程并且已经开始媒体数据的传输了)，通信的一 方(假设B)发生了中断媒体传输的情况，这种情况分为以下两种场景：

场景1：因为网络环境的原因，B失去了网络连接。业务服务器监测到B失去了网络连接 后，发送结束通话的信令给A，该信令中包含了提示A是否继续进行留言的信息。A收到该 信令后决定是否进行留言，如果A决定进行留言，那么A继续传输媒体，业务服务器保存A 发送的媒体，当A结束发送媒体后(发送结束通话的信令到业务服务器)，业务服务器将A给 B的留言保存成文件并生成一个URL的链接信息通过短信和电子邮件发送给B，由B根据 URL下载业务服务器上A的留言。

场景2：B因为私人原因主动结束了通话，但是B又希望能收到A后续传输的媒体。于 是B发送结束通话的信令给服务器，该信令中包含了提示A是否继续进行留言的信息。服务 器在收到该信令后，发现了该信令中包含了B希望留言的信息，那么服务器在转发该信令的 同时保存A发送的媒体。当A收到该信令后的流程和场景1相同。

在以下处理过程中，为了保证服务器能够完整保存B掉线后A传输的所有媒体内容，业 务服务器会保存A和B在会话保活时长内的所有媒体数据。会话保活是指，A和B的通话关 心建立好之后，A和B分别会定时向业务服务器发送一条业务信令，该信令被称之为会话保 活信令，其目的是告诉服务器自己仍然在线。例如，如果A和B的保活时长是1分钟(即A 和B每隔一分钟都会向服务器发送一条业务信令(保活信令))，业务服务器会实时的刷新保 存A和B在1分钟内(保活时长)的媒体数据，即每个一分钟，业务服务器都会用最新保存 的1分钟的媒体内容替换掉其前一分钟保存的内容。这样做的目的是，如果B在发送保活报 文后30s内掉线了，由于服务器保存了B在发送上一次保活报文后一分钟内A发送的数据， 这样A在这30s内的传输内容就不会丢失，保证了A在B掉线1分钟内上传的数据是完整的。 后续业务服务器将一直保存B掉线后A发送的所有媒体数据，及业务服务器保存的A的媒体 数据的时长是：60s(B发送最后一个保活报文后开始计时)+Ns(B掉线1分钟后)。

以下详细说明场景1的实施步骤。

用户场景1：终端B由于某种原因失去了网络连接，A继续传输媒体流到服务器，服务器 将A传输的媒体保存成文件并生成URL通过短信和电子邮件的方式发送给B，该场景实施流 程如图5所示：

说明如下：

业务服务器在60s内没有收到B的保活报文，业务服务器通过步骤S502发送结束呼叫 请求给终端A，报文如表4所示：

表4

业务服务器发送的呼叫结束报文其中携带Alert-Info字段，内容为“leaving Message”， 终端A收到该请求后，解析出Alert-Info字段，提示用户是否继续发送媒体，如果用户选择同 意，那么A通过步骤S502发送结束呼叫请求响应，报文如表5所示：

表5

由于A的响应中携带了Alert-Info并且内容为“leaving Message”,因此业务服务器并结 束接收A传输的媒体流，而是继续保存A的媒体流，并进入对终端A的“留言模式”。

在完成上述步骤后，终端A通过步骤S506向业务服务器执行单向媒体传输，业务服务 器继而通过步骤S508保存终端A所发送的媒体。

终端A继续通过步骤S510发送保活报文维持本次的呼叫，由于业务服务器进入了对终 端A的留言模式，因此业务服务器在收到A的保活报文后不再覆盖更新A的媒体流保存。

当终端A需要结束留言的时候通过步骤S514发送结束呼叫的请求，该请求不再携带 Alert-Info字段。业务服务器收到后通过S516发送结束呼叫请求的响应，该响应也不携带 Alert-Info字段。

业务服务器通过步骤S518生成一个URL链接，该链接是A针对B的留言的下载地址。

A通过步骤S520发送短信和电子邮件给B，短信和电子邮件的内容包含该URL的连接。

B收到短信或邮件后，可以通过该URL链接下载A的留言。

以下详细说明场景2的实施步骤。

用户场景2：终端B在和A的IP通话过程中因为某种原因需要结束通话，但又希望能收 到A后续传输的通话内容，该场景实施流程如图6所示：

用户B通过步骤S602发送结束呼叫请求，该请求的报文内容如表6所示：

表6

服务器收到该请求后立即通过步骤S604发送对该请求的响应给终端B，响应不携带 Alert-Info。终端B正常结束会话。业务服务器针对终端A开始和场景1相同的业务流程实施。 此处不再赘述。

现有的通话留言的方案都是基于用户无法建立呼叫的基础上实施的，而上述实施例的重 点在“动态”二字上。上述实施例可以通过服务器和客户端的信令交互可以动态检测到用户 在通话过程中需要进行留言的需求从而进行留言业务的实施。

此外上述实施例中，和客户端进行通话本地保存也是有区别和优势的。

通话内容本地保存占用用户客户端的空间，特别是视频内容，后续如果需要发送本地通 话内容文件还需要消耗用户的网络流量。本业务中所有的通话留言内容都是保存在服务器上， 并且可以进行业务流量包月的方式一方面吸引用户另一方面也不消耗用户网络流量；当用户 发现对端掉线了再去进行通话内容本地保存时，或许已经有一些重要的内容已经错过了，本 发明通过服务器自动保存通话双方在有效会话保活时长内的内容避免出现以上的问题。

综上所述，本发明实施例实现了以下有益效果：

用户在进行IP通话业务(无论是语音、视频通话或是视频共享业务)的时候，当通话中某 一用户网络不可用的时候，不会再错过重要的实时性的信息。因此本发明实施例有效的保障 了IP通话业务信息的完整性；目前大多数运营商都部署了基于IMS的IP通话业务，特别是 一些运营商已经开始运营了基于IMS的VoLTE的4G网络通话业务。本发明实施例可以给运 营商提供一种保持通话连续性的方案，作为一种IP通话业务的增强型功能，提升运营商的IP 通话业务的竞争力。

在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施方式 中描述的技术方案。

在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储 介质包括但不限于：光盘、软盘、硬盘、可擦写存储器等。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算 装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上， 可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置 中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步 骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个 集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说， 本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、 改进等，均应包含在本发明的保护范围之内。