CN101106521A - 具有增强的业务过滤规则的分组网络及其实现方法 - Google Patents
具有增强的业务过滤规则的分组网络及其实现方法 Download PDFInfo
- Publication number
- CN101106521A CN101106521A CNA2006101093901A CN200610109390A CN101106521A CN 101106521 A CN101106521 A CN 101106521A CN A2006101093901 A CNA2006101093901 A CN A2006101093901A CN 200610109390 A CN200610109390 A CN 200610109390A CN 101106521 A CN101106521 A CN 101106521A
- Authority
- CN
- China
- Prior art keywords
- service
- message
- filtering rule
- user
- trigger
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提供了一种具有增强的业务过滤规则的分组网络,包括:用户签约数据库,用于保存用户的业务过滤规则;业务控制点,用于为用户提供业务;以及业务触发点,从用户签约数据库获取业务过滤规则,并根据业务过滤规则决定当前处理的SIP通信是否需要触发到业务控制点或是否要进行本地处理,其中,业务过滤规则至少包括以下之一:SIP消息会话描述外的消息体内容、会话状态、SIP请求消息外的消息事件、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址。本发明还提供了一种业务触发方法,用于实现分组网络的业务触发。
Description
技术领域
本发明涉及通信领域,更具体而言,涉及一种具有增强的业务过滤规则的分组网络及其实现方法。
背景技术
IMS(IP Multimedia Subsystem,IP多媒体子***)是一个基于SIP(Session Initiation Protocol,会话初始化协议)的体系,它的会话层和业务层是分离的,IMS为业务的调用提供必要的方法,IMS中业务的提供包含以下三个基本步骤:
1)定义可能的业务或业务集合;
2)当用户定购/修改业务订购关系时,以初始过滤规则的形式创建用户专有的业务数据;以及
3)将到达的初始请求传递给应用服务器。
当用户从运营商处得到一个IMS订购关系时,运营商需要给他分配一个用户配置。用户配置至少包含一个私有的用户身份和单个业务配置,它被永久地存放在HSS(Home Subscriber Server,归属用户服务器)上。可以通过两种用户数据处理操作SAA(Server-Assignment-Answer)或者PPR(Push-Profile-Request),将用户配置从HSS传送到为该用户分配的S-CSCF(Serving-CallSession Control Function,服务呼叫会话控制功能)上。
为了实现IMS中业务提供所涉及的业务触发,现有技术3GPPTS 29.228(IP Multimedia(IM)Subsystem Cx and Dx Interfaces;Signaling flows and message contents)中以及MSF(MultiServiceForum,多业务论坛)的文稿msf.2006.004(Implementation Agreementfor the ISC interface)中,分别给出了相应的技术方案,下面将结合附图1至8对此予以详细描述。
图1至图4示出了3GPP TS 29.228中定义的用户配置的总体结构。
图1示出了其中用户档案(User Profile)的结构,图2示出了其中业务档案(Service Profile)的结构,图3示出了其中初始过滤规则的结构,以及图4示出了其中业务点触发器(Service PointTrigger)的结构。
Service Point Trigger设置的是业务触发判断条件,可以包括以下类型:
Request-URI(Uniform resource identifier,统一资源标识):标识该请求所指向的资源;
SIP Method:表示该SIP请求的类型;
SIP Header:包含与该请求相关的信息,一个SPT(Service pointTrigger,业务点触发器)可以基于任何SIP头域是否出现,或者基于任何SIP头域的内容;
Session Case:有三个可能的值,即起始、终止或终止未注册,指明过滤器是否应该被处理起始、终止或者终止未注册的终端用户的S-CSCF所使用;以及
Session Description:针对SIP方法内的任何SDP(SessionDescription Protocol,会话描述协议)字段内容。
图5示出了MSF中提出的R3架构ISC(IP multimedia ServiceControl,IP多媒体业务控制)接口。
如图5所示,在MSF的文稿msf.2006.004中提出了如下的业务架构:
S-CSC(Serving Call Session Controller,服务呼叫会话控制器)可以直接触发到业务层,业务层实体可以是开放业务接入网关、AS(Application Server,应用服务器)、以及与传统业务网络对接的业务逻辑网关。S-CSC也可以通过SB/SCIM(Service Broker,业务代理/Service Capability Interaction Manager,业务能力交互管理)将呼叫触发到业务层,SB/SCIM与S-CSC以及业务层实体间使用ISC接口,SB/SCIM与HSS间使用Sh接口来获取SCIM业务档案。
MSF SB/SCIM业务档案采用了类似3GPP(3rd GenerationPartnership Project,第三代移动通信标准化伙伴项目)业务档案的描述方式,图6至图8示出了MSF SB/SCIM业务档案的总体结构,其中,图6示出了SCIM业务档案的结构,图7示出了SCIM过滤规则的结构,以及图8示出了SCIM业务点触发器的结构。
从图6、7、8中可以看到MSF SB/SCIM中新增了两种SPT,它可以根据基本呼叫状态触发或者是根据日程触发,呼叫状态可以取值试呼、忙、无应答、挂机,日程根据RFC 2445可以取值FREE、BUSY、BUSY-UNAVAILABLE、BUSY-TENTATIVE,还可以取值UNOBTAINABLE。
目前业务触发点的触发主要依赖于它收到的SIP消息,而RFC3261 SIP:Session Initiation Protocol中定义的SIP消息格式为:
generic-message=start-line
*message-header
CRLF
[message-body]
start-line=Request-Line/Status-Line
Request-Line=Method SP Request-URI SP SIP-Version CRLF
Status-Line=SIP-Version SP Status-Code SP Reason-Phrase CRLF
然而,根据上述定义,在应用3GPP iFC(Initial Filter Criteria,初始过滤规则)过滤规则以及MSF SCIM过滤规则进行业务触发时,发现存在以下问题:
1、现有技术无法根据SIP消息体中除SDP信息(会话描述信息)以外的其它部分来触发业务;
2、现有技术可以根据SIP请求消息触发业务,SIP请求消息为RFC 3261中定义的起始行为SIP请求行的SIP消息,例如INVITE等消息,初始过滤规则指的就是对这些SIP请求消息(即SIP初始消息)的过滤规则,但现有技术无法根据SIP请求消息以外的SIP消息,如SIP响应消息触发业务,包括根据状态码触发、SIP响应中的消息头触发以及SIP响应中的消息体触发等。
因此现有标准中根据SIP消息的触发能力是不完备的,且上述问题也是有实际需求的,例如移动网络增强逻辑的客户化应用(CAMEL(Customised Applications for Mobile network EnhancedLogic,移动网络增强逻辑的客户化应用))用户通过IMS域发短消息,消息体中承载了短消息信令的SIP消息需要触发到业务控制点上以进行计费控制或者对虚拟专用网(VPN)被叫短号进行变换一类的处理。
3、MSF对于3GPP的过滤规则进行了扩展,引入了根据基本呼叫状态触发以及根据日程触发,但MSF定义的根据基本呼叫状态仅支持试呼、忙、无应答、挂机四种;
4、现有技术的触发机制不支持根据当前时间信息触发业务,而根据时间信息触发业务是一种比较重要的业务触发要求;
5、MSF的根据日程触发可以根据用户的状态触发,但它仅仅取了RFC 2445中定义的闲/忙时间类型(Free/Busy Time Type),不能提供更加丰富的信息,且RFC 2445发布时间为1998年,时间已经比较久远了,显然它不能满足用户需要的更强和更个性化的业务触发能力要求;
6、不能根据用户漫游状态触发,而根据用户漫游状态触发业务是一种比较重要的业务触发要求;
7、不能指定业务调用消息,现有技术中,S-CSCF/MSF SB/SCIM等收到一个SIP请求消息,该SIP请求消息匹配一个业务过滤规则,只能将该SIP请求消息发向指定的应用服务器,即对指定应用服务器的业务调用消息就是该业务过滤规则的触发消息,而在实际应用中,业务过滤规则的触发消息和对指定应用服务器的调用消息可以不是同一种SIP消息;
8、不能描述其它过滤规则,而一个业务过滤规则中引用另一个过滤规则也是一种比较重要的业务触发要求;
9、现有技术只能根据过滤规则发送消息到应用服务器而不能在触发条件匹配后进行流程化的处理。例如现有技术不能主动获取业务触发数据,也无法实现带有流程性的触发判断,如触发被叫侧业务前先判断主叫用户是否在被叫用户的黑名单中。
因此现有技术的缺点可以总结如下:
1、不支持根据SIP消息消息体中除了SDP信息外的其它部分触发业务;
2、基本呼叫状态非常有限,仅有试呼、忙、无应答、挂机四种,状态划分不够细,例如无法区分通话后挂机还是通话前挂机;
3、不支持根据SIP请求消息外的SIP消息事件触发;
4、不能按时间触发;
5、MSF根据日程触发仅提供有限的根据用户信息触发能力,无法提供如根据用户所处场所触发等更多的触发方式;
6、不能根据用户漫游状态触发;
7、不能指定业务调用消息;
8、不能引用其它过滤规则;
9、不能在触发条件匹配后进行流程化的处理。
因此,人们需要一种用于IMS网络的业务触发解决方案,能够解决上述相关技术中的问题。
发明内容
本发明旨在提供本发明提供了一种具有增强的业务过滤规则的分组网络及其实现方法,业务触发点能够根据SIP消息会话描述外的消息体内容、SIP请求消息外的SIP消息事件、会话状态、时间段、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址中的一种或者多种将当前处理的SIP通信触发到业务控制点或进行本地处理。
根据本发明的一个方面,提供了一种具有增强的业务过滤规则的分组网络,包括:用户签约数据库,用于保存关于用户的业务过滤规则的数据;业务控制点,用于为用户提供业务;以及业务触发点,从用户签约数据库获取业务过滤规则,并根据业务过滤规则决定当前处理的SIP通信是否需要触发到业务控制点或是否要进行本地处理,其中,业务过滤规则至少包括以下之一:SIP消息会话描述外的消息体内容、会话状态、SIP请求消息外的消息事件、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址。
根据本发明的另一方面,提供了一种业务触发方法,用于实现分组网络的业务触发,分组网络包括:用户签约数据库,用于保存关于用户的业务过滤规则的数据;业务控制点,用于为用户提供业务,该业务触发方法包括以下步骤:步骤a,业务触发点从用户签约数据库获取业务过滤规则;以及步骤b,业务触发点根据业务过滤规则决定当前处理的SIP通信是否需要触发到业务控制点或是否要进行本地处理,其中,业务过滤规则至少包括以下之一:SIP消息会话描述外的消息体内容、会话状态、SIP请求消息外的SIP消息事件、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址。
需要说明的是,现有技术中SIP Method业务点触发器表面上可以根据所有的SIP方法触发业务,但S-CSCF在会话信令路径建立后SIP路由集就固定下来了,这样如果有业务需要在会话信令路径建立以后触发,例如根据BYE消息触发,应用层服务器因为无法加入到已经建立的SIP路由集从而导致实际上S-CSCF不能支持任意SIP请求消息的触发,实际上它只能支持对INVITE、MESSAGE、SUBSCRIBE等作为会话发起请求、用于请求建立会话信令路径的SIP方法的触发。本发明中对业务触发点有特殊的要求,业务触发点可以修改会话信令路径,可以支持所有类型的SIP消息包括SIP请求消息、SIP响应消息以及本发明中所述的所有会话状态触发,即SIP Method业务点触发器在本发明中可以根据所有的SIP方法(Method)触发业务。
通过上述技术方案,本发明实现了如下技术效果:
本发明提供了一种增强的业务触发机制,业务触发点可以根据SIP消息会话描述外的消息体内容、SIP请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址将当前处理的SIP通信触发到业务控制点或进行本地处理,从而提高了触发的有效性,减轻了业务控制点的负荷。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1示出了3GPP TS 29.228中定义的用户配置的用户档案的结构;
图2示出了3GPP TS 29.228中定义的用户配置的业务档案的结构;
图3示出了3GPP TS 29.228中定义的用户配置的初始过滤规则的结构;
图4示出了3GPP TS 29.228中定义的用户配置的业务点触发器的结构;
图5示出了MSF中提出的R3架构ISC接口;
图6示出了SCIM业务档案的结构;
图7示出了SCIM过滤规则的结构;
图8示出了SCIM业务点触发器的结构;
图9示出了根据本发明的一种典型分组网络的网络逻辑结构图;
图10示出了根据本发明的一种典型的业务触发流程的流程图;以及
图11示出了根据本发明的业务触发流程的流程图。
具体实施方式
下面将参考附图并结合实施例,来详细说明本发明。
图9示出了根据本发明的一种典型分组网络的网络逻辑结构图。
本发明提出,在业务触发机制中,如图9所示,分组网络900的网络逻辑包括用户签约数据库902、业务控制点904、和业务触发点906。
其中:
1、用户签约数据库902保存用户的业务过滤规则;
2、业务触发点906提供与业务控制点904交互的能力,业务触发点与业务控制点之间存在E3接口,该接口协议可以采用但不限于SIP协议,业务触发点根据业务过滤规则,决定当前处理的SIP通信是否需要触发到特定的业务控制点或是否需要进行本地处理;
3、业务触发点与用户签约数据库之间存在E2接口,该接口可以采用但不限于Diameter协议等,业务触发点可以通过E2接口从用户签约数据库获得用户业务过滤规则,业务触发点还可以从业务控制点获得业务过滤规则,业务触发点可以是S-CSCF或ServiceBroker(业务代理)等;
4、业务控制点是提供业务的功能实体,一个业务控制点可以提供一个或者多个业务。业务控制点和用户签约数据库之间存在E1接口,该接口可以采用但不限于Diameter协议等,业务控制点通过该接口从用户签约数据库获得用户数据,业务控制点也可以更新用户签约数据库上的用户业务数据。业务控制点可以是IMS中的SIPAS、OSA SCS(Open Service Access-Service Capability Server,开放业务接入-业务能力服务器)、IM-SSF(IP Multimedia ServiceSwitching Function,IP多媒体业务交换功能)等。
简言之,分组网络900包括:
用户签约数据库902,用于保存用户的业务过滤规则;
业务控制点904,用于为用户提供业务;以及
业务触发点906,从用户签约数据库或业务控制点获取业务过滤规则,并根据该业务过滤规则决定当前处理的SIP通信是否需要触发到业务控制点或是否要进行本地处理,其中,过滤规则至少包括以下之一:SIP消息会话描述外的消息体内容、会话状态、SIP请求消息外的SIP消息事件、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址。
根据图9所示的本发明的典型分组网络逻辑结构,本发明中提出了一种典型的业务触发流程。
图10示出了根据本发明的一种典型的业务触发流程的流程图,其包括以下步骤:
上述流程解释如下:
步骤S1002:业务触发点收到终端的注册请求;
步骤S1004-S1006:业务触发点向发送注册消息的用户所在的用户签约数据库请求下载用户业务过滤规则,用户签约数据库响应并发送用户的业务过滤规则,所述业务过滤规则为本发明中增强的业务过滤规则。该流程对应的例子如当业务触发点是ServiceBroker,用户签约数据库是HSS,两者间的通讯接口采用3GPP Sh接口的时候:所述的下载请求为Diameter协议用户数据请求(User-Data-Request)消息,其中携带用户标识属性-值对(User-Identity AVP)以及数据参考属性-值对(Data-Reference AVP)以及业务指示属性-值对(Service-Indication AVP),其中使用User-Identity AVP用于定位某一个用户的数据,Data-Reference AVP取值透明数据(RepositoryData)表示所请求的数据位于HSS的用户透明数据区,Service-Indication AVP取值为业务过滤规则对应的特定的透明数据标识;所述的下载响应为Diameter协议用户数据响应(User-Data-Answer)消息,其中携带用户数据属性-值对(User-Data AVP),其中的数据为业务触发点请求的该用户的业务过滤规则。具体来说,增强的业务触发方式包括:根据SIP消息会话描述外的消息体内容、SIP请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址等触发,稍后本文将针对所述增强的业务过滤规则一一描述;
步骤S1008-S1010:业务触发点保存收到的用户业务过滤规则并向终端发送响应;
步骤S1012:终端发送SIP邀请(SIP INVITE)消息;以及
步骤S1014-S1016:业务触发点根据该用户的增强的业务过滤规则进行触发的判断,所述的增强的业务过滤规则包括根据SIP消息会话描述外的消息体内容、SIP请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址触发,当触发条件满足的时候如果所述的业务过滤规则描述的服务器地址为业务控制点的地址,业务触发点向业务过滤规则中指定的业务控制点发送INVITE消息以请求调用业务;如果所述的业务过滤规则描述的服务器地址为虚拟服务器地址,业务触发点调用虚拟服务器地址对应的本地处理。
上述过程简言之,如图11所示,包括以下步骤:
步骤S1102,业务触发点从用户签约数据库获取业务过滤规则;以及
步骤S1104,业务触发点根据该业务过滤规则决定当前处理的SIP通信是否需要触发到业务控制点或是否要进行本地处理,其中,过滤规则至少包括以下之一:SIP消息会话描述外的消息体内容、会话状态、SIP请求消息外的SIP消息事件、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联指示、虚拟应用服务器地址。
此外,在业务处理过程中,业务控制点也可以向业务触发点返回业务过滤规则,业务触发点可以据此进行后续的相应处理,业务触发点可以在收到该业务过滤规则后立即匹配处理,也可以先保存并在收到后续的SIP消息再匹配处理。一般的,和来自用户签约数据库获取的业务过滤规则不同,来自业务控制点的业务过滤规则只在当前通信中有效,当前通信结束后,业务触发点可以删除此前记录的来自业务控制点的业务过滤规则,即这是一种“临时”业务过滤规则。
如前所述,本发明要提供的是一种增强的业务触发实现方法,其中,提出了一种增强的业务过滤规则,该增强的业务过滤规则可以解决现有技术中的问题。
1、根据SIP消息会话描述外的消息体内容触发业务
如上所述,现有技术存在问题1,不支持根据SIP消息消息体中除了SDP信息外的其它部分触发业务。即,根据SIP消息会话描述外的消息体内容触发是3GPP以及MSF现有标准中不支持的。为了解决这个问题,本发明提出了定义新的SIP消息体业务点触发器(SIP Body SPT)类型:
定义该SPT包含消息体类型(Message Body Type)以及消息体内容(Message Body Content)元素,其中Message Body Type对应SIP消息中内容类型(Content-Type)的取值,按照RFC 3261中的定义它表示指定消息体的媒体类型;Message Body Content表示Content-Type指示的消息体的内容,一般的,消息体类型采用MIME(Multipurpose Internet Mail Extensions,多用途网络邮件扩展)媒体类型(media type),对应的,消息体内容即为MIME体(MIMEbody)。
Message Body Content中又包括实体标签(Body Tag)以及实体内容(Body Content)两类元素。其中Body Tag表示上述消息体内容中包含的单元数据的标签名或标签值,消息体内容采用文本编码方式下它可以对应某个元素的标签名,例如消息体内容采用可扩展标记语言(XML)编码方式下的它对应XML元素的标签名;消息体内容采用二进制编码方式下它可以对应消息体内容中包含的数据单元的标签值,例如封装ISUP(Integrated Services DigitalNetwork User Par,综合业务数字网用户部分)的SIP(SIP-I)消息中的消息类型编码(Message Type Code)值或者参数名编码(Parameter Name Code)值。Body Content对应所述Body Tag标记的标签对应的数据单元内容,例如SIP-I方式下Body Content可以对应Body Tag标记的参数名编码对应的参数内容(ParameterContent)。SIP Body SPT中Message Body Type是必备的,用于识别不同的内容类型,SIP Body SPT中可以带0到多个Message BodyContent。以上元素均可采用但不限于使用正则表达式的形式指示进行部分匹配或者精确匹配。
上述SIP Body SPT定义采用表格形式描述为:
表1
Data type | Tag | Compound of | ||
Tag | Type | Cardinality | ||
tSIPBody | SIPBody | MessageBodyType | tString | 1 |
MessageBodyContent | tMessageBodyContent | (0 ton) | ||
tMessageBodyContent | MessageBodyContent | BodyTag | tString | 1 |
BodyContent | tString | 1 |
以上仅为了说明业务触发点可以根据SIP消息message-body内容触发,实际的SPT定义方式可以是不限于上述方式,本发明中其它的SPT也是类似的,后面不再一一说明。
下面针对message-body采用文本编码以及二进制编码两种方式,具体对根据SIP消息会话描述外的消息体内容触发的SPT描述进行说明。
实施例1:主叫用户为IMS预付费用户,该用户发送的短消息采用XML方式封装到SIP MESSAGE消息的消息体中,业务触发点收到该用户的SIP MESSAGE消息发现消息体中携带的短消息消息类型指示为请求递交的时候将当前会话触发到业务控制点。
短消息采用XML封装到SIP MESSAGE消息的消息体中的方式如下:
MESSAGE sip:[email protected],SIP/2.0
Content-Type:multipart/related;type=″application/message+xml″;
start=″<[email protected]>″;
boundary=″=_005A0428C1257165_=″
--=_005A0428C1257165_=
Content-Type:application/message+xml
Content-ID:<[email protected]>
<?xml version=″1.0″encoding=″UTF-8″?>
<message xmlns=″urn:ietf:params:xml:ns:message″>
<message-type-indicator> message submit request
</message-type-indicator>
<message-class>personal</message-class>
<delivery-report>Yes</delivery-report>
<read-reply>Yes</read-reply>
<content>This is a test message!</content>
</message>
这种情况下对应的根据SIP消息会话描述外的消息体内容触发SPT描述为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<SIPBody>
<MessageBodyType>application/message+xml</MessageBodyType>
<MessageBodyContent>
<BodyTag>message-type-indicator</BodyTag>
<BodyContent>message submit
request</BodyContent>
</MessageBodyContent>
</SIPBody>
</SPT>
其中MessageBodyType取值application/message+xml表示用户的短消息采用的是XML封装的方式,业务触发点匹配的字段是SIP消息中的Content-Type中包含application/message+xml的情况;BodyTag取值message-type-indicator,BodyContent取值messagesubmit request表示业务触发点需要匹配application/message+xml方式封装的SIP消息体中的XML标签为message-type-indicator取值为message submit request的内容。
实施例2:当一个IMS VPN用户发短信,该短信消息采用短消息业务转发层(SMS TL)封装的方式放到SIP消息的message-body中,业务触发点将该SIP通信触发到业务控制点,业务控制点对短信进行进一步的处理,例如当短信中的被叫号码为一个VPN短号的时候翻译该号码。
SMS TL层封装的方式可以参见欧洲电信标准协会(ETSI(European Telecommunications Standards Institute,欧洲电信标准协会))发布的标准文档DES/AT-030036,例如:
MESSAGE sip:1234567890@domain SIP/2.0
From:
<sip:0987654321@domain>;tag=c0a80103-13c4-7e84-1ee41f1-223
9
To:<sip:1234567890@domain>
Call-ID:
CSeq:1 MESSAGE
Via:SIP/2.0/UDP
192.168.1.3:5060;branch=z9hG4bK-7e84-1ee41f1-207e
Content-Encoding:base64
Max-Forwards:70
Content-Type:application/vnd.3gpp.sms-t1
Content-Length:32
EQMKgWBmhABAAACnDNTynA5ql+fz8LkM
上诉例子中封装了一条TL递交短消息(SMS-SUBMIT)消息,消息中携带文本″Test message″。
这种情况下对应的根据SIP消息会话描述外的消息体内容触发SPT描述为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<SIPBody>
<MessageBodyType>application/vnd.3gpp.sms-t1</MessageBodyType>
<MessageBodyContent>
<BodyTag>TL-SMS-SUBMIT</BodyTag>
</MessageBodyContent>
</SIPBody>
</SPT>
上述SPT表示业务触发点匹配条件为采用DES/AT-030036中application/vnd.3gpp.sms-t1封装方式且SIP消息内容部分的短消息转发层(SM-TL)的协议数据单元(PDU(Protocol Data Unit,协议数据单元))类型为SMS-SUBMIT。
这类二进制封装方式下的SPT描述对业务触发点有要求,需要它理解实体标签(Body Tag)的含义,并据此查找解析的二进制内容中对应的数据单元。
这里的SPT描述仅为了说明业务触发点可以根据二进制方式封装的SIP消息体内容来触发,实际的SPT描述方式可以不限于此。
2、根据业务触发点的会话状态触发业务
如上所述,现有技术存在问题2,基本呼叫状态非常有限。即,MSF目前支持试呼、忙、无应答、挂机4种基本会话状态,对于实际的应用这4种状态是不够的。为此考虑对MSF定义的基本会话状态进行扩展,3GPP TS 23.278中定义了一套IM-SSF使用的检测点(DP)状态模型。本发明提出了,业务触发点的状态模型可以借鉴3GPP TS 23.278中的定义以支持更完整的会话状态触发能力。
为此定义会话状态业务点触发器(Session State SPT),业务触发点Session State SPT支持的会话状态包括:
收集信息、分析信息、路由选择失败、发端忙、发端无应答、发端应答、发端拆线、发端放弃、终端试呼鉴权、终端忙、终端无应答、终端应答、终端拆线、终端放弃
上述DP点完全照搬3GPP TS 23.278,具体每个DP点的定义参照3GPP TS 23.278。
上述Session State SPT定义采用表格形式描述为:
表2
Data type | Tag | Base type | Comments |
tSessionState | SessionState | enumerated | Possible values:2(collectedInfo)3(analyzedInformation)4(routeSelectFailure)5(oCalledPartyBusy)6(oNoAnswer)7(oAnswer)9(oDisconnect)10(oAbandon)12(termAttemptAuthorized)13(tBusy)14(tNoAnswer)15(tAnswer)17(tDisconnect)18(tAbandon) |
由于IM-SSF根据DP点触发已经是一种标准,所以下面不一一对上述会话状态举例证明其有效性,业务触发点根据会话状态触发的实施例如下:
实施例3:主叫用户有自动重复试呼业务,当到被叫的会话路由失败的时候业务触发点将会话触发到业务控制点上
对应的会话状态SPT为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<SessionState>4</SessionState>
</SPT>
上述SessionState标签表示要求业务触发点匹配会话状态,SessionState标签后的取值4表示匹配的条件为业务触发点上的会话状态为路由选择失败。
3、根据SIP请求消息外的SIP消息事件触发业务
如上所述,现有技术存在问题3,不支持根据SIP请求消息外的SIP消息事件触发业务,下面以SIP响应消息为例描述本发明对SIP请求消息外的SIP消息事件触发业务的支持。
SIP响应消息的格式为:
Response-message = Status-Line
*message-header
CRLF
[message-body]
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
由于3GPP iFC机制目前已经支持根据消息头和SDP触发,而本发明前面也已经支持了根据除SDP外的其它形式的SIP消息内容触发,且初始过滤规则(iFC)描述本身已经支持多种SPT的组合,所以下面只需要考虑支持根据SIP消息Status-Code(状态码)触发,原因(Reason-Phrase)中是对Status-Code的简单文本描述,而且具体实现时SIP实体可以在Reason-Phrase中填充RFC 3261规定外的文本描述,可选地,支持Reason-Phrase。
可以为Status-Code定义一种SIP响应业务点触发器(SIPResponse SPT),里面只包含SIPResponse一个元素,SIPResponse取值类型为string,SIPResponse可以取满足SIP协议的任意响应码的值,SIPResponse可以支持通配和/或多值描述,以满足某些情况下业务控制点需要对一类响应码进行处理的情况,通配和多值描述的表示方法可以采用正则表达式或者为了描述简单起见也可以采用如4XX,5XX的形式表示,其中4XX表示通配,只要SIP响应码为4系列的就认为SPT发生匹配,而用逗号连接4XX,5XX表示这是一个多值描述,只要逗号分隔的多个值之一发生了匹配就认为SPT发生了匹配。以上仅为了说明SIP Response SPT可以支持通配和/或多值描述,SPT的描述形式可以不限于上述形式。
上述SIP Response SPT定义采用表格形式描述为:
表3
Data type | Tag | Base type | Comments |
tSIPResponse | SIPResponse | tString |
业务触发点根据Status-Code触发举例如下:
实施例4:主叫用户有一种业务,在收到所有类型的会话失败时会话将触发至业务控制点进行进一步的处理,例如根据不同的响应码播放不同的语音通知
相应的SIP Response SPT表示方式为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<SIPResponse>4XX,5XX,6XX</SIPResponse>
</SPT>
上述SPT中4XX,5XX,6XX表示只要业务触发点收到的SIP响应只要为4系列或者5系列或者6系列之一就匹配了本SPT。
根据上述方法,还可以对其它的SIP请求消息外的任何SIP消息进行匹配触发,这里不再赘述。
4、根据时间触发业务
如上所述,现有技术存在问题4,不能按时间触发业务。
实际的应用场景如用户有按时间免打扰业务,在00:00到06:00之间的休息时间不希望被打扰,在这段时间呼入的呼叫被接入到语音邮箱。
本发明提出,定义一种时间业务点触发器(Time SPT):
表4
Data type | Tag | Base type | Comments |
tTime | Time | tString |
其中tTime可以采用字符串描述,时间的描述方式可以参照但不限于采用国际标准化组织(ISO)8601中的格式,时间信息可以包括年、月、日、时、分、秒中的一种或者多种,时间段中的起止时间可以采用但不限于用字符“/”进行分隔,例如20:00/24:00。
业务触发点根据时间触发举例如下:
实施例5:用户有按时间免打扰业务,在00:00到06:00之间的休息时间不希望被打扰,在这段时间呼入的呼叫被接入到语音邮箱
相应的Period SPT表示方式为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Time>00:00/06:00</Time>
</SPT>
上述SPT表示只要业务触发点当前时间落在00:00到06:00区间范围内就发生了Time SPT匹配。
5、根据用户呈现信息触发业务
如上所述,现有技术存在问题5,MSF根据日程触发仅提供有限的根据用户信息触发能力。相对而言,现在流行的PRESENCE规范能够提供更多用户相关的信息,例如可以提供用户所在的场所、用户当前进行的活动。本发明提出,根据用户的Presence信息触发业务能够提供更加强劲和更加个性化的业务触发能力。
根据用户呈现信息触发的应用场景如用户希望上班的时候可以接受任意的呼叫,但是到家以后激活来话筛选业务。所述用户呈现信息以及格式在因特网工程任务组(IETF)有定义,相关的主要标准有RFC 3863、因特网草案“RPID:Rich Presence Extensions tothe Presence Information Data Format”、因特网草案“CIPID:ContactInformation in Presence Information Data Format”、因特网草案“Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Status Information for Past and Future TimeIntervals”、因特网草案“Session Initiation Protocol(SIP)User AgentCapability Extension to Presence Information Data Format(PIDF)”,用户呈现信息还包括用户的位置信息,相关的主要标准有RFC 4119、因特网草案“GEOPRIV PIDF-LO Usage Clarification,Considerationsand Recommendations”、因特网草案“A Document Format forFiltering and Reporting Location Noticatiohs in the PresenceInformation Document Format Location Object(PIDF-LO)”、因特网草案“Revised Civic Location Format for PIDF-LO”。目前标准中多采用通过SIP消息的消息体部分携带XML方式描述的呈现信息,为了适应呈现信息数据的灵活性和扩展性,业务触发点的呈现业务点触发器(Presence SPT)借鉴SIP Body SPT的定义方式。
上述Presence SPT定义采用表格形式描述为:
表5
Data type | Tag | Compound of | ||
Tag | Type | Cardinality | ||
tPresence | Presence | PresenceType | tString | 1 |
PresenceContent | tPresenceContent | (1 to n) | ||
tPresenceContent | PresenceContent | ElementTag | tString | 1 |
ElementContent | tString | 1 |
其中呈现类型(PresenceType)对应可能的不同的SIP内容类型(SIP Content Type)。Presence SPT的描述形式可以不限于采用上述方式。
用户呈现信息的内容比较丰富,例如RFC 3863定义了设备状态(basic);因特网草案“RPID:Rich Presence Extensions to thePresence Information Data Format”中定义了比较丰富的状态呈现信息类型,如用户活动(activities)、用户情绪(mood)、场所类型(place-type)、场所属性(place-is)、私密程度(privacy)、用户的当前状态和角色(sphere);因特网草案“Session Initiation Protocol(SIP)User Agent Capability Extension to Presence Information DataFormat(PIDF)”中定义了设备的通信能力。
下面针对业务触发点收到的呈现信息采用上述呈现信息数据格式的丰富呈现扩展(RPID)格式携带举例如下:
实施例6:用户希望在家的时候才激活来话筛选业务
业务触发点收到的携带用户呈现信息的SIP消息示例为:
NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0
Via:SIP/2.0/UDP ps.home2.net;branch=z9hG4bK348923.1
……
Event:presence
Content-Type:application/pidf+xml
……
<?xml version=″1.0″encoding=″UTF-8″?>
<presence xmlns=″urn:ietf:params:xml:ns:pidf″
xmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″
xmlns:dm=″urn:ietf:params:xml:ns:pidf:data-model″
xmlns:rpid=″urn:ietf:params:xml:ns:pidf:rpid″
xsi:schemaLocation=″urn:ietf:params:xml:ns:pidfpidf:xsd
urn:ietf:params:xml:ns:pidf:daa-model data-model.xsd
urn:ietf:params:xml:ns:pidf:rpid rpid.xsd″
entity=″pres:[email protected]″>
……
<rpid:place-type>
<rpid:residence/>
</rpid:place-type>
……
</presence>
其中<rpid:residence/>表示用户在住地,该住地可以是用户自己的居住场所也可以是其它人的家里。
相应的Presence SPT表示方式为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Presence>
<PresenceType>application/pidf+xml</PresenceType>
<PresenceContent>
<ElementTag>rpid:residence/</ElementTag>
</PresenceContent>
</Presence>
</SPT>
上面的Presence SPT中成分标签(ElementTag)为rpid:residence/表示当业务触发点得到的呈现信息中包含XML标签rpid:residence/的时候就发生了Presence SPT的匹配。
上面的实施例中举的例子是根据用户当前场所触发,PresenceSPT还可以根据上述用户活动、用户情绪、场所属性、私密程度、用户的当前状态和角色、设备状态、设备通信能力触发,描述方式是类似的,这里不再一一列举了。
另外上面的实施例中呈现信息用IETF RPID的格式携带,呈现信息也可以不采用RPID的格式携带,如采用其它形式的文本格式或者二进制格式携带,此时可通过PresenceType来区分不同的呈现信息表示类型,呈现信息中不同的呈现类型通过ElementTag来区分。例如
业务触发点收到的携带用户呈现信息的SIP消息为:
NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0
Via:SIP/2.0/UDP ps.home2.net;branch=z9hG4bK348923.1
……
Event:presence
Content-Type:application/presence+text
……
place-type:residence
相应的Presence SPT表示方式为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Presence>
<PresenceType>application/presence+text</PresenceType>
<PresenceContent>
<ElementTag>place-type</ElementTag>
<ElementContent>residence</ElementContent>
</PresenceContent>
</Presence>
</SPT>
以上举例仅为了说明呈现信息可以使用非RPID格式描述,实际的描述格式可以不限于上述方式。
用户的呈现信息还包括用户的位置信息,下面再针对业务触发点根据用户的位置信息触发举例说明:
实施例7:用户为纽约百老汇某剧院的贵宾客户,当用户到剧院附近的时候可以享受呼叫费用的优惠,以吸引用户经常到剧院去
业务触发点收到的携带用户位置信息的SIP消息示例为:
NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0
Via:SIP/2.0/UDP ps.home2.net;branch=z9hG4bK348923.1
……
Content-Type:application/pidf+xml
……
<?xml version=″1.0″encoding=″UTF-8″?>
<presence xmlns=″urn:ietf:params:xml:ns:pidf″
xmlns:gp=″urn:ietf:params:xml:ns:pidf:geopriv 10″
xmlns:cl=″urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc″
entity=″pres:[email protected]″>
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>New York</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
<cl:LOC>Suite 75</cl:LOC>
<cl:PC>10027-0401</cl:PC>
</cl:civicAddress>
</gp:location-info>
</gp:geopriv>
</status>
</presence>
具体的Presence SPT描述实例为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Presence>
<PresenceType>application/pidf+xml</PresenceType>
<PresenceContent>
<ElementTag>cl:A3</ElementTag>
<ElementContent>New York</ElementContent>
<ElementTag>cl:A6</ElementTag>
<ElementContent>Broadway</ElementContent>
<ElementTag>cl:HNO</ElementTag>
<ElementContent>123</ElementContent>
</PresenceContent>
</Presence>
</SPT>
上述Presence SPT中用户位置信息采用城市地址位置描述,其中cl:A3表示该位置对应的城市,cl:A6表示该位置对应的街区,cl:HNO表示该位置对应的门牌号。
上面的实施例中采用的是的城市地址方式描述的行政地理位置信息,Presence SPT也可以根据采用但不限于用经纬度方式描述的自然地理位置信息触发,也可以根据采用但不限于用终端接入网络的地理位置如接入设备编号、接入网络编号一类方式描述的网络地理位置信息触发,这里不再举例说明。
同实施例6类似,用户位置信息描述格式可以不限于RFC 4119中定义的方式,这里不再一一举例说明。
6、根据用户漫游状态触发业务
如上所述,现有技术存在问题6,不能根据用户漫游状态触发业务。根据用户漫游状态触发的例子,如用户在漫游的时候限制其它用户的呼入而不限制该用户的呼出,用户漫游状态的获得方式依赖于业务触发点的具体实现,实现方式可以采用但不限于如业务触发点根据SIP消息中的P-Visited-Network-ID头域中的拜访网络标识判断用户是否漫游。
为此定义一种漫游状态业务点触发器(Roaming State SPT):
表6
Data type | Tag | Base type | Comments |
tRoamingState | RoamingState | enumurated | 0(roamingState)1(non-roamingState) |
实施例8:用户在漫游的时候限制其它用户的呼入
相应的Roaming State SPT表示方式为:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<RoamingState>0</RoamingState>
</SPT>
上述SPT表示只要业务触发点发现用户处于漫游状态就发生了Roaming State SPT的匹配,使用该SPT配合Session Case SPT(如取值INVITE)和SIP Method SPT(如取值TERMINATING_REGISTERED)就可以实现被叫用户在漫游的时候将来话触发到业务控制点上的功能。
7、业务过滤规则中可以指定业务调用消息
如上所述,现有技术存在问题7,只能将业务过滤规则的触发消息,作为该规则被匹配后对特定业务控制点的调用消息。为解决该问题,可以在业务过滤规则中指定对业务控制点的调用消息。
实施例9:业务触发点收到一个SIP响应消息,如200响应码,该SIP响应消息匹配一个业务过滤规则,需要调用一个特定的业务控制点,业务控制点名为“sip:[email protected]”,从业务触发点发向该业务控制点的调用消息为SIP BYE(再见)消息,如下所示:
<SPT>
<SIPResponse>200</SIPResponse>
</SPT>
……………………
<ApplicationServer>
<ServerName>sip:[email protected]</ServerName>
<InvokingMessage>BYE</InvokingMessage>
</ApplicationServer>
在对ApplicationServer的描述中,增加了相应的InvokingMessage标签的设置,其取值可以是任一SIP消息。
实施例10:在业务过滤规则中指定对业务控制点的调用消息还有一个重要的应用,业务点触发器SPT中可能无法描述触发消息,如当采用前述的会话状态业务点触发器时,可以看到,一些会话状态并不是由业务触发点收到的一个SIP消息引发的,如会话状态为“终端_无应答”,显然,此时将必须在业务过滤规则中指定从业务触发点发向特定业务控制点的调用消息,示例如下:
<SPT>
<SessionState>14</SessionState>
</SPT>
……………………
<ApplicationServer>
<ServerName>sip:[email protected]</ServerName>
<InvokingMessage>INVITE</InvokingMessage>
</ApplicationServer>
8、业务过滤规则中可以描述其它规则关联信息
如上所述,现有技术存在问题8,不能使一个以上的业务过滤规则相互关联起来,要解决该问题,首先要能标识出一个业务过滤规则,即给业务过滤规则命名编号;其次要定义一个业务过滤规则被匹配的业务控制点的业务执行结果,如“1”表示“成功”,“0”表示“失败”等。
实施例11:对其它业务过滤规则的关联指示的描述可以出现在上一条业务过滤规则中,示例如下:
<ApplicationServer>
<ServerName>sip:[email protected]</ServerName>
<Relation>
<Result>0</Result>
<RelatingFilterCriteria>FC00abc</RelatingFilterCriteria>
</Relation>
</ApplicationServer>
对其它业务过滤规则的关联指示的描述可以出现在对业务控制点的设置中,例如在特定的业务控制点名称之后,给出该业务控制点的执行结果对其它业务过滤规则的关联(标签为Relation),当执行结果Result为0(失败)时,调用关联的业务过滤规则,标签RelatingFilterCriteria给出了关联规则的名称FC00abc。即在本业务过滤规则中给出特定业务控制点对应的其它关联规则,根据该业务控制点的执行结果引用其它关联规则。
当然,对其它业务过滤规则的关联指示的描述也可以出现在下一条业务过滤规则中,即在本业务过滤规则的业务点触发器SPT中引用其它关联规则的执行结果,作为一种匹配条件,如下所示:
<SPT>
<Relation>
<RelatingFilterCriteria>FC11xyz</RelatingFilterCriteria>
<Result>1</Result>
</Relation>
</SPT>
在业务点触发器SPT中,要求检查名称为FC11xyz的业务过滤规则的执行结果。此外,如前所述,业务控制点可以向业务触发点返回业务过滤规则,业务触发点可以立即匹配处理该业务过滤规则,此时,业务过滤规则可以不出现RelatingFilterCriteria的名称,而认为Result的取值就是来自该业务控制点的执行结果,即RelatingFilterCriteria可以显式取值、也可以是缺省取值。
除了可以根据本规则的执行结果引用其它关联规则、或将其它关联规则的执行结果作为本规则的匹配条件,还可以在一个业务过滤规则中预置其它的过滤规则,预置规则可能会被执行,也可能不会被执行,取决于业务触发点后续是否能获得相应的触发条件。
可以看到,业务过滤规则中描述的其它规则关联信息至少包括业务执行结果、或其它过滤规则。
9、业务过滤规则中可以描述虚拟应用服务器地址
如上所述,现有技术存在问题9,不能在触发条件匹配后进行流程化的处理。为解决该问题在业务过滤规则中引入虚拟应用服务器地址。
虚拟服务器地址对应业务触发点上的一段程序或一段脚本,虚拟服务器地址不用SIP URL表述,但可以采用类似的方式描述,例如虚拟服务器地址的域描述部分对应业务触发点的本机地址,用户部分对应业务触发点上的一段程序或者一段脚本。虚拟的服务器地址可以带参数以做为相应的程序段或者脚本的输入,它携带的参数可以不是SIP协议中的参数。
虚拟服务器地址的描述可以位于业务过滤规则中对业务控制点的描述中,例如可以放在过滤规则数据中服务器地址描述部分。
实施例12:业务触发点地址为triggerPoint1.home.net,它上面有脚本localScript3用于向一个呈现服务器发送消息,localScript3这个脚本有一个呈现服务器地址的输入参数用于表示要向哪个呈现服务器发送消息。它得到的一条过滤规则数据中服务器地址描述为:
<ServerName>[email protected];
presenceServer=presenceServer10.home.net</ServerName>
上面的例子中[email protected]表示triggerPoint1.home.net上对应的脚本或程序为localScript3,其后的presenceServer=presenceServer10.home.net为脚本localScript3的输入,表示这个脚本可以向presenceServer10.home.net这个地址请求用户的呈现数据。即当这条过滤规则的触发条件满足后业务触发点triggerPoint1.home.net调用其上的脚本localScript3,调用的脚本根据虚拟服务器地址中的presenceServer 参数向presenceServer10.home.net这个地址请求用户的呈现数据。
从以上的描述中,可以看出,本发明实现了如下技术效果:
本发明提供了一种增强的业务触发机制,业务触发点可以根据SIP消息会话描述外的消息体内容、SIP请求消息外的SIP消息事件、会话状态、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址将当前处理的SIP通信触发到业务控制点或进行本地处理,从而提高了触发的有效性,减轻了业务控制点的负荷。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。应该明白,这些具体实施中的变化对于本领域的技术人员来说是显而易见的,不脱离本发明的精神保护范围。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (32)
1.一种具有增强的业务过滤规则的分组网络,其特征在于,包括:
用户签约数据库,用于保存用户的业务过滤规则;
业务控制点,用于为所述用户提供业务;以及
业务触发点,从所述用户签约数据库获取所述业务过滤规则,并根据所述业务过滤规则决定当前处理的SIP通信是否需要触发到所述业务控制点或是否要进行本地处理,其中,所述业务过滤规则至少包括以下之一:SIP消息会话描述外的消息体内容、会话状态、SIP请求消息外的消息事件、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址。
2.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述SIP消息会话描述外的消息体内容包括文本编码格式或二进制编码格式。
3.根据权利要求2所述的具有增强的业务过滤规则的分组网络,其特征在于,所述业务过滤规则包括SIP消息会话描述外的消息体内容,通过以下方法建立所述业务过滤规则:创建SIP消息体业务点触发器,使其包括消息体类型和/或消息体内容。
4.根据权利要求3所述的具有增强的业务过滤规则的分组网络,其特征在于,所述消息体类型为多用途网络邮件扩展MIME媒体类型,所述消息体内容为多用途网络邮件扩展MIME体。
5.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述会话状态至少包括以下之一:收集信息、分析信息、路由选择失败、发端_忙、发端_无应答、发端_应答、发端_拆线、发端_放弃、终端试呼鉴权、终端_忙、终端_无应答、终端_应答、终端_拆线、终端_放弃。
6.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述SIP消息请求外的消息事件包括SIP响应消息。
7.根据权利要求6所述的具有增强的业务过滤规则的分组网络,其特征在于,所述业务过滤规则包括所述SIP请求消息外的消息事件,通过以下方法建立所述业务过滤规则:创建SIP响应业务点触发器,使其包括SIP响应元素,其值取符合SIP协议的任意状态码的值。
8.根据权利要求7所述的具有增强的业务过滤规则的分组网络,其特征在于,所述SIP响应元素的值支持通配和/或多值描述。
9.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述用户呈现信息至少包括以下之一:用户活动、用户情绪、场所类型、场所属性、私密程度、用户的当前状态和角色、设备状态、设备通信能力、用户位置信息。
10.根据权利要求9所述的具有增强的业务过滤规则的分组网络,其特征在于,所述的用户位置信息至少包括以下之一:自然地理位置信息、行政地理位置信息、网络地理位置信息中的一种。
11.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述业务过滤规则包括用户漫游状态,通过以下方法建立所述业务过滤规则:创建用户漫游状态触发器,使其包括用户是否漫游的信息。
12.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述其它规则关联信息至少包括以下之一:业务执行结果、或其它过滤规则。
13.根据权利要求12所述的具有增强的业务过滤规则的分组网络,其特征在于,所述其它规则关联信息位于业务点触发器描述中、或位于对业务控制点的描述中。
14.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述业务调用消息指定业务触发点向业务控制点发送的SIP消息。
15.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述虚拟应用服务器地址指定业务触发点上的一段程序或脚本。
16.根据权利要求1所述的具有增强的业务过滤规则的分组网络,其特征在于,所述业务触发点至少包括以下之一:服务呼叫会话控制实体、业务代理实体。
17.一种业务触发方法,用于实现分组网络的业务触发,所述分组网络包括:用户签约数据库,用于保存用户的业务过滤规则;业务控制点,用于为所述用户提供业务;业务触发点,用于将SIP通信触发到业务控制点或进行本地处理。所述业务触发方法特征在于,包括以下步骤:
步骤a,业务触发点从所述用户签约数据库获取业务过滤规则;以及
步骤b,所述业务触发点根据业务过滤规则决定当前处理的SIP通信是否需要触发到所述业务控制点或是否要进行本地处理,其中,所述业务过滤规则至少包括以下之一:SIP消息会话描述外的消息体内容、会话状态、SIP请求消息外的消息事件、时间、用户呈现信息、用户漫游状态、业务调用消息、其它规则关联信息、虚拟应用服务器地址。
18.根据权利要求17所述的业务触发方法,其特征在于,所述SIP消息会话描述外的消息体内容包括文本编码格式或二进制编码格式。
19.根据权利要求17所述的业务触发方法,其特征在于,所述业务过滤规则包括SIP消息会话描述外的消息体内容,通过以下方法建立所述业务过滤规则:创建SIP消息体业务点触发器,使其包括消息体类型和/或消息体内容。
20.根据权利要求17所述的业务触发方法,其特征在于,所述消息体类型为多用途网络邮件扩展MIME媒体类型,所述消息体内容为多用途网络邮件扩展MIME体。
21.根据权利要求17所述的业务触发方法,其特征在于,所述会话状态至少包括以下之一:收集信息、分析信息、路由选择失败、发端_忙、发端_无应答、发端_应答、发端_拆线、发端_放弃、终端试呼鉴权、终端_忙、终端_无应答、终端_应答、终端_拆线、终端_放弃。
22.根据权利要求17所述的业务触发方法,其特征在于,所述SIP请求消息外的消息事件包括SIP响应消息。
23.根据权利要求22所述的业务触发方法,其特征在于,所述业务过滤规则包括所述SIP请求消息外的消息事件,通过以下方法建立所述业务过滤规则:创建SIP响应业务点触发器,使其包括SIP响应元素,其值取符合SIP协议的任意状态码的值。
24.根据权利要求23所述的业务触发方法,其特征在于,所述SIP响应元素的值支持通配和/或多值描述。
25.根据权利要求17所述的业务触发方法,其特征在于,所述用户呈现信息至少包括以下之一:用户活动、用户情绪、场所类型、场所属性、私密程度、用户的当前状态和角色、设备状态、设备通信能力、用户位置信息。
26.根据权利要求25所述的业务触发方法,其特征在于,所述的用户位置信息至少包括以下之一:自然地理位置信息、行政地理位置信息、网络地理位置信息中的一种。
27.根据权利要求17所述的业务触发方法,其特征在于,所述业务过滤规则包括用户漫游状态,通过以下方法建立所述业务过滤规则:创建用户漫游状态触发器,使其包括用户是否漫游的信息。
28.根据权利要求17所述的业务触发方法,其特征在于,所述业务触发点至少包括以下之一:服务呼叫会话控制实体、业务代理实体。
29.根据权利要求17所述的业务触发方法,其特征在于,所述其它规则关联信息至少包括以下之一:业务执行结果、或其它过滤规则。
30.根据权利要求29所述的业务触发方法,其特征在于,所述其它规则关联信息位于业务点触发器描述中、或位于对业务控制点的描述中。
31.根据权利要求17所述的业务触发方法,其特征在于,所述业务调用消息指定业务触发点向业务控制点发送的SIP消息。
32.根据权利要求17所述的业务触发方法,其特征在于,所述虚拟应用服务器地址指定业务触发点上的一段程序或脚本。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006101093901A CN101106521A (zh) | 2006-07-14 | 2006-08-16 | 具有增强的业务过滤规则的分组网络及其实现方法 |
PCT/CN2007/001726 WO2008009197A1 (fr) | 2006-07-14 | 2007-05-29 | Réseau par paquets et procédé permettant de réaliser ce réseau |
EP07721299A EP2043307A4 (en) | 2006-07-14 | 2007-05-29 | PACKET NETWORK AND METHOD FOR REALIZING THIS NETWORK |
US12/353,103 US20090122794A1 (en) | 2006-07-14 | 2009-01-13 | Packet network and method implementing the same |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200610098776.7 | 2006-07-14 | ||
CN200610098776 | 2006-07-14 | ||
CNA2006101093901A CN101106521A (zh) | 2006-07-14 | 2006-08-16 | 具有增强的业务过滤规则的分组网络及其实现方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101106521A true CN101106521A (zh) | 2008-01-16 |
Family
ID=39000206
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2006101093901A Pending CN101106521A (zh) | 2006-07-14 | 2006-08-16 | 具有增强的业务过滤规则的分组网络及其实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101106521A (zh) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101917446A (zh) * | 2010-08-26 | 2010-12-15 | 成都市华为赛门铁克科技有限公司 | 多媒体会话控制方法和相关设备及通信*** |
CN101997716A (zh) * | 2009-08-19 | 2011-03-30 | 阿瓦雅公司 | 增强的呼叫追踪 |
CN102271135A (zh) * | 2011-08-16 | 2011-12-07 | 大唐移动通信设备有限公司 | 一种初始过滤规则集的匹配方法及*** |
CN102316425A (zh) * | 2011-09-23 | 2012-01-11 | 中兴通讯股份有限公司 | 一种用于ims与智能网的信令交互方法及im-ssf |
CN101631174B (zh) * | 2009-08-14 | 2012-01-11 | 苏州普适通科技有限公司 | 基于会话发起协议的网络电话实时识别和过滤方法 |
WO2012055070A1 (en) * | 2010-10-28 | 2012-05-03 | Intel Corporation | Cooperated approach to network packet filtering |
CN102752315A (zh) * | 2012-07-25 | 2012-10-24 | 烽火通信科技股份有限公司 | 一种灵活适应ims***业务标签的业务解析方法 |
CN104580073A (zh) * | 2013-10-14 | 2015-04-29 | 阿里巴巴集团控股有限公司 | 一种用于在异构***之间实现消息传递的方法和装置 |
WO2015196819A1 (zh) * | 2014-06-25 | 2015-12-30 | 中兴通讯股份有限公司 | Ivpn平台短消息收发的方法及业务控制节点 |
CN108293042A (zh) * | 2015-11-05 | 2018-07-17 | 瑞典爱立信有限公司 | 在互联网协议多媒体子***中控制服务的方法和设备 |
CN108616489A (zh) * | 2016-12-13 | 2018-10-02 | 中国电信股份有限公司 | 按时间动态调用业务的方法、装置和*** |
-
2006
- 2006-08-16 CN CNA2006101093901A patent/CN101106521A/zh active Pending
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101631174B (zh) * | 2009-08-14 | 2012-01-11 | 苏州普适通科技有限公司 | 基于会话发起协议的网络电话实时识别和过滤方法 |
CN101997716B (zh) * | 2009-08-19 | 2014-09-24 | 阿瓦雅公司 | 用于消息处理的方法和设备 |
CN101997716A (zh) * | 2009-08-19 | 2011-03-30 | 阿瓦雅公司 | 增强的呼叫追踪 |
CN101917446A (zh) * | 2010-08-26 | 2010-12-15 | 成都市华为赛门铁克科技有限公司 | 多媒体会话控制方法和相关设备及通信*** |
WO2012055070A1 (en) * | 2010-10-28 | 2012-05-03 | Intel Corporation | Cooperated approach to network packet filtering |
US9276875B2 (en) | 2010-10-28 | 2016-03-01 | Intel Corporation | Cooperated approach to network packet filtering |
CN102271135A (zh) * | 2011-08-16 | 2011-12-07 | 大唐移动通信设备有限公司 | 一种初始过滤规则集的匹配方法及*** |
CN102271135B (zh) * | 2011-08-16 | 2013-09-11 | 大唐移动通信设备有限公司 | 一种初始过滤规则集的匹配方法及*** |
CN102316425B (zh) * | 2011-09-23 | 2017-12-19 | 中兴通讯股份有限公司 | 一种用于ims与智能网的信令交互方法及im‑ssf |
CN102316425A (zh) * | 2011-09-23 | 2012-01-11 | 中兴通讯股份有限公司 | 一种用于ims与智能网的信令交互方法及im-ssf |
CN102752315A (zh) * | 2012-07-25 | 2012-10-24 | 烽火通信科技股份有限公司 | 一种灵活适应ims***业务标签的业务解析方法 |
CN102752315B (zh) * | 2012-07-25 | 2015-03-18 | 烽火通信科技股份有限公司 | 一种灵活适应ims***业务标签的业务解析方法 |
CN104580073A (zh) * | 2013-10-14 | 2015-04-29 | 阿里巴巴集团控股有限公司 | 一种用于在异构***之间实现消息传递的方法和装置 |
CN104580073B (zh) * | 2013-10-14 | 2018-11-13 | 阿里巴巴集团控股有限公司 | 一种用于在异构***之间实现消息传递的方法和装置 |
WO2015196819A1 (zh) * | 2014-06-25 | 2015-12-30 | 中兴通讯股份有限公司 | Ivpn平台短消息收发的方法及业务控制节点 |
CN108293042A (zh) * | 2015-11-05 | 2018-07-17 | 瑞典爱立信有限公司 | 在互联网协议多媒体子***中控制服务的方法和设备 |
CN108293042B (zh) * | 2015-11-05 | 2020-12-04 | 瑞典爱立信有限公司 | 在互联网协议多媒体子***中控制服务的方法和设备 |
CN108616489A (zh) * | 2016-12-13 | 2018-10-02 | 中国电信股份有限公司 | 按时间动态调用业务的方法、装置和*** |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101106521A (zh) | 具有增强的业务过滤规则的分组网络及其实现方法 | |
Poikselkä et al. | The IMS: IP multimedia concepts and services | |
CN103220323B (zh) | 用于服务控制的装置 | |
CN101569154B (zh) | 用于为非登记订户的gsm与ims之间的重叠 | |
CN101297531B (zh) | 经由电路交换接入提供ims服务 | |
CN101635772B (zh) | 一种呼叫信息管理的方法及其*** | |
CN103477618B (zh) | 用于在电信***中建立不给出主叫方身份的通信的方法和服务器 | |
CN102187637B (zh) | Ip多媒体子***用户标识处理 | |
US20090122794A1 (en) | Packet network and method implementing the same | |
CN103763446A (zh) | 使用既有设备的ims网络接入 | |
CN101321400B (zh) | 通信*** | |
CN102037749A (zh) | 用于在ims以及电路交换网络中进行消息路由的方法以及*** | |
CN101132401A (zh) | 业务交互处理方法和*** | |
CN101030931B (zh) | 一种业务数据的传输方法及其所应用的分组终端 | |
CN101529883B (zh) | 向匿名呼叫者提供组合服务的***和方法 | |
CN101076198B (zh) | 多媒体彩像业务实现方法 | |
CN101132560A (zh) | 业务交互处理方法和*** | |
CN102017588A (zh) | 用于通信网络中交互式呼叫方信息服务的方法和装置 | |
CN100486367C (zh) | 一种实现彩像业务的***和方法 | |
CN101106565B (zh) | 具有增强的业务过滤规则的分组网络及其实现方法 | |
CN100459628C (zh) | 一种彩名业务实现方法 | |
CN101160992A (zh) | 一种在半双工通话中实现语音数据记录的方法、***及装置 | |
CN1921482B (zh) | 一种基于会话发起协议的业务处理方法和装置 | |
US20100306349A1 (en) | Method and System for Configuring Service on Terminal | |
CN101437093B (zh) | 在ims网络中实现呼叫地址传送 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20080116 |