CN101656727A - 一种实现区分振铃业务的方法及设备 - Google Patents

Abstract

本发明公开了一种实现区分振铃业务的方法及设备，涉及IMS技术领域。本发明公开的方法包括：区分振铃系统接收到第一用户设备对第二用户设备发起的呼叫时，若判断第一用户设备配置有区分振铃业务，则向第二用户设备发送携带有第一用户设备的区分振铃业务信息的呼叫请求；第二用户设备接收到该呼叫请求后，从中读取第一用户设备的区分振铃业务信息，并根据第一用户设备的区分振铃业务信息选择相应的振铃，进行播放。与现有技术相比，本发明技术方案克服了现有SIP消息中不能控制播放铃音类型的问题。

Description

一种实现区分振铃业务的方法及设备

技术领域

本发明涉及IP多媒体系统(IMS，IP Multimedia Subsystem)技术领域，尤其涉及一种实现区分振铃业务的方法及设备。

背景技术

IMS系统，是一种全新的多媒体业务形式，它能够满足现在的终端客户更新颖、更多样化的多媒体业务的需求。目前，IMS被认为是下一代网络的核心技术，也是解决移动与固网融合，引入语音、数据、视频三重融合等差异化业务的重要方式。但是，目前全球IMS网络多数处于初级阶段，应用方式也处于业界探讨当中。

区分振铃业务有良好的应用空间，被叫终端振铃时，可以根据振铃音的不同知道是谁打来的电话。越来越多的用户希望在SIP(Session InitiationProtocal，会话初始协议)网络电话上能够实现区分振铃(很多手机已经具备分组振铃功能，不过一般是在终端上配置实现的，并非软交换通过SIP信令控制业务)。

发明内容

本发明所要解决的技术问题是，提供一种实现区分振铃业务的方法及设备，从而可以由网络侧控制在SIP终端上实现区分振铃。

为了解决上述问题，本发明公开了一种实现区分振铃业务的方法，包括：

区分振铃系统接收到第一用户设备对第二用户设备发起的呼叫时，若判断所述第一用户设备配置有区分振铃业务，则向所述第二用户设备发送携带有所述第一用户设备的区分振铃业务信息的呼叫请求；

所述第二用户设备接收到所述呼叫请求后，从中读取所述第一用户设备的区分振铃业务信息，并根据所述第一用户设备的区分振铃业务信息选择相应的振铃，进行播放。

进一步地，上述方法中，所述第一用户设备的区分振铃业务信息至少包括所述第一用户设备的区分振铃音的模板参数。

其中，所述第二用户设备与所述区分振铃系统还预先约定区分振铃音的各种模板参数分别对应的振铃音，其中，区分振铃音的各种模板参数分别对应于所述第二用户设备本地存储的各种振铃音，或者区分振铃音的各种模板参数分别对应于指定网络上的各种音频文件。

所述呼叫请求为邀请INVITE消息，所述区分振铃系统通过在所述INVITE消息中增加Alert-Info头部以携带所述第一用户设备的区分振铃业务信息，其中，所述Alert-Info头部符合RFC3261协议规定。

所述第二用户设备为SIP终端。

本发明还公开了一种实现区分振铃业务的网络侧设备，至少包括判断模块以及处理模块，其中：

所述判断模块，用于判断发起呼叫请求的主叫用户设备是否配置有区分振铃业务，并将所述主叫用户设备的区分振铃业务信息发送到所述处理模块；

所述处理模块，用于接收所述呼叫请求以及所述判断模块发送的区分振铃业务信息，并将所述区分振铃业务信息增加到所述呼叫请求后发送给被叫用户设备。

进一步地，上述网络侧设备中，所述区分振铃业务信息至少包括所述主叫用户设备的区分振铃音的模板参数。

其中，所述呼叫请求为邀请INVITE消息，所述处理模块通过在所述INVITE消息中增加Alert-Info头部以携带所述主叫用户设备的区分振铃业务信息，其中，所述Alert-Info头部符合RFC3261协议规定。

本发明还公开了一种实现区分振铃业务的用户设备，至少包括解析模块以及处理模块，其中：

所述解析模块，用于解析网络侧下发的呼叫请求，从中获取区分振铃业务信息，并将所述区分振铃业务信息发送到所述处理模块；

所述处理模块，用于接收所述解析模块发送的区分振铃业务信息，并根据所述区分振铃业务信息选择相应的振铃，进行播放。

进一步地，上述用户设备中，所述区分振铃业务信息至少包括区分振铃音的模板参数。

上述用户设备还包括与处理模块相连的配置模块，

所述配置模块，用于与区分振铃系统预先约定区分振铃音的各种模板参数分别对应的振铃音，其中，区分振铃音的各种模板参数分别对应于所述用户设备本地存储的各种振铃音，或者区分振铃音的各种模板参数分别对应于指定网络上的各种音频文件。

与现有技术相比，本发明技术方案提供相应的SIP消息扩展来实现区分振铃，从而克服了现有SIP消息中不能控制播放铃音类型的问题，并且SIP消息的扩展也符合RFC3261的格式。

附图说明

图1是本实施例中网络侧设备的结构示意图；

图2是本实施例中UE的结构示意图；

图3是本实施例中实现区分振铃业务的流程图；

图4是UE A未配置区分振铃业务时呼叫处理的流程图；

图5是UE A配置有标准区分振铃音时呼叫处理的流程图；

图6是UE A配置有2号区分振铃音时呼叫处理的流程图。

具体实施方式

本发明的主要构思是：可以通过对SIP消息的扩展以实现在SIP终端上区分振铃的功能，具体地：区分振铃系统可以在INVITE(邀请)消息中扩展Alert-Info头部以携带用户设备(UE)的区分振铃业务信息，例如，区分振铃音模板参数等，这样，被叫用户设备收到该INVITE消息后，则根据其中的区分振铃业务信息来控制放音类型和属性，其中，放音类型可能是振铃音中的任一种，如回铃音或者呼叫等待音等等；属性则指具体的放音标识，不同放音标识对应不同的长短音组合。

下面结合附图及具体实施例对本发明技术方案作进一步详细说明。

一种实现区分振铃业务的系统，至少包括网络侧设备和UE。其中，网络侧设备在本实施例中即为软交换机，而UE又可以分为主叫UE(后文简称为UE A)和被叫UE(后文简称为UE B)。下面介绍这两部分的功能。

软交换机，如图1所示，包括彼此相互连接的收发模块、判断模块以及处理模块。

其中，收发模块，用于接收UE A针对UE B发起的呼叫请求(本实施例中即为INVITE消息)，并将UE A发起的INVITE消息分别发送到判断模块和处理模块，以及用于将处理模块处理后的INVITE消息发送给UE B；

判断模块，用于接收收发模块发送的INVITE消息，根据该INVITE消息中UE A的信息判断UE A是否配置有区分振铃业务，并将判断结果发送给处理模块，其中，当UE A配置有区分振铃业务时，判断模块还将UE A的区分振铃业务信息发送给处理模块；；

在本实施例中，判断模块判断UE A是否配置有区分振铃业务是指判断模块判断运营商是否为UE A配置了区分振铃业务，其中，运营可以根据UEA的用户信息等为其配置区分振铃业务，例如，UE A与UE B为不同网络的终端时，运营商可以为UE A配置区分振铃业务。

处理模块，用于接收判断模块发送的判断结果，当判断结果是UE A配置有区分振铃业务，则将判断模块发送的UE A的区分振铃业务信息添加到INVITE消息中，发送给收发模块；当判断结果是UE A未配置有区分振铃业务，则按照现有技术对INVITE消息进行相应处理后发送给收发模块；

其中，处理模块在INVITE消息中增加Alert-Info头部以携带UE A的区分振铃业务信息(例如振铃音的模板参数)，Alert-Info头部符合RFC3261协议规定。

UE，如图2所示，包括相互连接的接收模块、解析模块、处理模块和配置模块，其中，接收模块还与处理模块相连。

接收模块，用于接收网络侧下发的呼叫请求(本实施例中即为INVITE消息)，并将该INVITE消息分别发送到解析模块和处理模块；

解析模块，用于解析接收模块发送的INVITE消息，若解析后获取到区分振铃业务信息，则将该区分振铃业务信息发送到处理模块；

其中，解析模块解析获取区分振铃业务信息指，解析INVITE消息从中读取Alert-Info头部，该Alert-Info头部中包含有区分振铃业务信息。

处理模块，用于接收接收模块发送的INVITE消息，若还接收到解析模块发送的该INVITE消息的Alert-Info头部，则根据该Alert-Info头部中的区分振铃业务的信息ring-type查找本地所配置的与该ring-type相对应的振铃，并进行播放；若仅接收到INVITE消息，则按照本地默认的铃音参数播放振铃。

上述网络侧设备与UE需要预先约定好区分振铃业务中各振铃音模板参数ring-type一一对应的播放振铃，其中，与各ring-type一一对应的播放振铃可以是UE本地保存的振铃，也可以是指定位置的音频文件等，例如，SIP终端可以根据用户选择将本地的任一个播放振铃与ring-type的标准铃音相对应，此时，实现区分振铃业务的过程，如图3所示，包括以下步骤：

步骤301：UE A向软交换机发起针对UE B的INVITE消息；

步骤302：软交换机收到INVITE消息后，判断UE A是否配置有区分振铃业务，如果有，则进入步骤303，否则按照现有技术对INVITE消息进行相应处理后发送给UE B；

步骤303：软交换机在所接收到的INVITE消息中增加区分振铃业务的信息，并发送给UE B；

该步骤中，软交换机在INVITE消息中增加Alert-Info头部以携带区分振铃业务的信息，例如，振铃音的模板参数；

本实施例中，扩展的Alert-Info头部符合RFC3261协议的规定，具体定义如下：

Alert-Info＝″Alert-Info″HCOLON alert-param*(COMMA alert-param)

alert-param＝LAQUOT absoluteURI RAQUOT*(SEMI generic-param)

其中，generic-param是通用参数，适合进行扩展。定义如下：

alert-param＝ring-type

ring-type＝token，表示ring-type的取值是没有引号的字符串

ring-type的具体取值可以由运营商和设备商确定，以表示特定的模板，例如：

Standard Ring：标准振铃音；

Distinctive Ring 1：1号振铃音；

Distinctive Ring 2：2号振铃音；

Distinctive Ring 3：3号振铃音。

步骤304：UE B收到该INVITE消息后，解析INVITE消息，从中读取区分振铃业务信息，并判断自身是否支持该区分振铃业务，如果是，进入步骤305，否则按照自身的振铃配置播放振铃；

该步骤中，UE B判断自身是否支持该区分振铃业务，是判断UE B是否已配置了与区分振铃业务信息ring-type相对应的振铃，如果配置了，则认为自身支持该区分振铃业务，否则认为自身不支持该区分振铃业务；

在其他实施例中，UE B还可以根据当前播放振铃的优先级来判断自身是否支持该区分振铃业务，即UE B即便已经配置了与区分振铃业务的信息ring-type相对应的振铃，但该振铃的使用优先级低于当前播放振铃，则UE B依然认为自身不支持该区分振铃业务。

步骤305：UE B根据解析得到的区分振铃业务的信息ring-type查找本地所配置的与该ring-type相对应的振铃，并进行播放。

在其他实施例中，尤其对于支持网络音频文件播放的智能终端，软交换机还可以通过扩展的Alert-Info头部中的absoluteURI(绝对格式的URI)来携带区分振铃业务信息，即用URI格式直接描述一个网络上存放的音频文件，例如：Alert-Info：http://www.example.com/sounds/moo.wav，该音频文件就是区分振铃业务信息中UE A所配置的区分振铃音，此时，收到INVITE消息的UE B，直接播放该INVITE消息中Alert-Info头部的URI指定的网络音频文件即可。

下面详细介绍UE A未配置区分振铃业务时的操作过程，如图4所示，包括以下步骤：

步骤401：UE A向软交换机发起针对UE B的INVITE消息；

步骤402：软交换机收到INVITE消息，发现UE A没有配置区分振铃业务；

步骤403：软交换机则按照现有技术将INVITE消息经过处理后转发给UE B，即软交换机并未在该INVITE消息中添加Alert-Info头部；

步骤404：UE B收到上述INVITE消息后，解析该INVITE消息，发现该INVITE消息中并没有Alert-Info头部，则按照本地默认的铃音参数播放振铃。

下面详细介绍UE A配置有标准振铃音的区分振铃业务时的操作过程，如图5所示，包括以下步骤：

步骤501：UE A向软交换机发起针对UE B的INVITE消息；

步骤502：软交换机收到INVITE消息，发现UE A配置了区分振铃业务，其中，UE A的区分振铃为标准振铃音(Standard Ring)；

步骤503：软交换机在所接收到的INVITE消息中增加Alert-Info头部后发给UE B，其中，新增的Alert-Info表示UE A的区分振铃为Standard Ring；

步骤504：UE B收到上述INVITE消息后，解析该INVITE消息，发现该INVITE消息的Alert-Info头部中区分振铃的模板参数是标准振铃音，则则查找与标准振铃音相对应的振铃进行播放。

下面详细介绍UE A配置有2号振铃音的区分振铃业务时的操作过程，如图6所示，包括以下步骤：

步骤601：UE A向软交换机发起针对UE B的INVITE消息；

步骤602：软交换机收到INVITE消息，发现UE A配置了区分振铃业务为2号振铃音；

步骤603：软交换机在所接收到的INVITE消息中增加Alert-Info头部后发给UE B，其中，新增的Alert-Info中表示UE A配置了Distinctive Ring 2；

本实施例中，INVITE消息扩展示例如下：

    INVITE sip:69601@10.40.41.36；user＝phone SIP/2.0

    Via:SIP/2.0/UDP 10.40.41.36:5060；branch＝z9hG4bK4cf232792a464f53

    To:<sip:69601@10.40.41.36；user＝phone>

    From:

    69600<sip:69600@10.40.41.36；user＝phone>；tag＝017a47c30df1603e

    -33f2319e

    Call-ID:69075164-972220219@10.40.41.36

    CSeq:20874 INVITE

    Contact:69600<sip:69600@10.40.41.36:5060>

    Allow:

INVITE，ACK，OPTIONS，BYE，CANCEL，INFO，REGISTER，PRACK，

UPDATE，MESSAGE

Alert-Info:Distinctive Ring 2

Max-Forwards:70

Content-Type:application/sdp

Content-Length:137

步骤604：UE B收到上述INVITE消息后，解析该INVITE消息，发现该INVITE消息的Alert-Info头部中区分振铃音的模板参数是2号振铃音，则查找与2号振铃音相对应的振铃进行播放。

从上述实施例可以看出，本发明技术方案对目前SIP协议的标准消息进行合理的扩展，从而由网络侧控制在SIP终端上实现区分振铃的功能，这样在增强功能的基础上又保持了较好的互通性。

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

Claims (10)

1、一种实现区分振铃业务的方法，其特征在于，包括：

区分振铃系统接收到第一用户设备对第二用户设备发起的呼叫时，若判断所述第一用户设备配置有区分振铃业务，则向所述第二用户设备发送携带有所述第一用户设备的区分振铃业务信息的呼叫请求；

所述第二用户设备接收到所述呼叫请求后，从中读取所述第一用户设备的区分振铃业务信息，并根据所述第一用户设备的区分振铃业务信息选择相应的振铃，进行播放。

2、如权利要求1所述的方法，其特征在于，

所述第一用户设备的区分振铃业务信息至少包括所述第一用户设备的区分振铃音的模板参数。

3、如权利要求2所述的方法，其特征在于，

所述第二用户设备与所述区分振铃系统还预先约定区分振铃音的各种模板参数分别对应的振铃音，其中，区分振铃音的各种模板参数分别对应于所述第二用户设备本地存储的各种振铃音，或者区分振铃音的各种模板参数分别对应于指定网络上的各种音频文件。

4、如权利要求1、2或3所述的方法，其特征在于，

所述呼叫请求为邀请INVITE消息，所述区分振铃系统通过在所述INVITE消息中增加Alert-Info头部以携带所述第一用户设备的区分振铃业务信息，其中，所述Alert-Info头部符合RFC3261协议规定。

5、如权利要求4所述的方法，其特征在于，

所述第二用户设备为SIP终端。

6、一种实现区分振铃业务的网络侧设备，其特征在于，至少包括判断模块以及处理模块，其中：

所述判断模块，用于判断发起呼叫请求的主叫用户设备是否配置有区分振铃业务，并将所述主叫用户设备的区分振铃业务信息发送到所述处理模块；

所述处理模块，用于接收所述呼叫请求以及所述判断模块发送的区分振铃业务信息，并将所述区分振铃业务信息增加到所述呼叫请求后发送给被叫用户设备。

7、如权利要求6所述的网络侧设备，其特征在于，

所述呼叫请求为邀请INVITE消息，所述处理模块通过在所述INVITE消息中增加Alert-Info头部以携带所述主叫用户设备的区分振铃业务信息，其中，所述Alert-Info头部符合RFC3261协议规定。

8、一种实现区分振铃业务的用户设备，其特征在于，至少包括解析模块以及处理模块，其中：

所述解析模块，用于解析网络侧下发的呼叫请求，从中获取区分振铃业务信息，并将所述区分振铃业务信息发送到所述处理模块；

所述处理模块，用于接收所述解析模块发送的区分振铃业务信息，并根据所述区分振铃业务信息选择相应的振铃，进行播放。

9、如权利要求8所述的用户设备，其特征在于，

所述区分振铃业务信息至少包括区分振铃音的模板参数。

10、如权利要求9所述的用户设备，其特征在于，还包括与处理模块相连的配置模块，

所述配置模块，用于与区分振铃系统预先约定区分振铃音的各种模板参数分别对应的振铃音，其中，区分振铃音的各种模板参数分别对应于所述用户设备本地存储的各种振铃音，或者区分振铃音的各种模板参数分别对应于指定网络上的各种音频文件。

Images