CN101110756A - 应用服务器分配方法和装置 - Google Patents
应用服务器分配方法和装置 Download PDFInfo
- Publication number
- CN101110756A CN101110756A CNA2006100990986A CN200610099098A CN101110756A CN 101110756 A CN101110756 A CN 101110756A CN A2006100990986 A CNA2006100990986 A CN A2006100990986A CN 200610099098 A CN200610099098 A CN 200610099098A CN 101110756 A CN101110756 A CN 101110756A
- Authority
- CN
- China
- Prior art keywords
- application server
- user
- service
- filter criteria
- initial filter
- 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
Abstract
本发明提供了一种应用服务器分配方法和装置,该方法包括:S902,呼叫会话控制功能实体从用户签约信息中的初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务;S904,呼叫会话控制功能实体将业务请求消息转发至所选择的应用服务器;S906,所选的应用服务器接收到业务请求消息后为用户服务。该装置包括:接收模块,用于接收业务请求消息;选择模块,用于从用户签约信息中的初始过滤规则中选择一个或多个应用服务器中的一个应用服务器为用户服务;消息转发模块,用于将业务请求消息转发至所选择的应用服务器。通过使用本发明的方法和装置,降低了网管配置工作量,提高了系统效率。
Description
技术领域
本发明涉及通信领域,更具体地,涉及一种应用服务器分配方法和应用服务器分配装置。
背景技术
IP多媒体子系统(IP Multimedia Subsystem,简称IMS)是3GPP(第三代移动通信标准化的伙伴项目)R5阶段增加的WCDMA网络中的叠加在已有分组交换域之上的一个子系统,采用分组交换域为其上层控制信令和媒体传输的承载通道,引入会话发起协议(Session Initiation Protocol,简称SIP)作为业务控制协议,利用SIP简单、易扩展、媒体组合方便的特点,通过将业务控制与承载控制分离,提供丰富的多媒体业务;IMS中主要的功能实体包括控制用户注册、会话控制等功能的呼叫会话控制功能(Call SessionControl Function,简称CSCF)、提供各种业务逻辑控制功能的应用服务器(Application Server,简称AS),集中管理用户签约数据的归属签约用户服务器(Home Subscriber Server,简称HSS)以及用于实现与电路交换网互通的媒体网关控制功能(Media gatewaycontrol Function,简称MGCF)/IMS媒体网关(IMS Media gateway,简称IM-MGW),用户通过当前所在地代理节点P-CSCF接入IMS,会话和业务触发控制及与应用服务器的业务控制交互则由其注册地的归属域服务节点S-CSCF完成,IMS网络系统架构如图1所示。
其中,CSCF是呼叫会话控制功能,在IMS核心网中处于核心的控制地位,负责对用户设备(User Equipment,简称UE)的注册鉴权和会话控制,执行针对主叫端及被叫端IMS用户的基本会话路由功能,并根据用户签约的IMS初始过滤规则(Initial Filter Criteria,简称iFC),在条件满足时进行到应用服务器的增值业务路由触发及业务控制交互。
HSS是用户数据库服务器,存储运营商开户时设定的IMS签约信息,同时支持通过与业务管理系统的接口由运营商或终端用户对签约数据进行的定制和修改。HSS通过与S-CSCF间基于Diameter协议的Cx接口实现IMS注册过程中对S-CSCF域名路由信息的登记,并支持通过该接口将基本IMS签约信息下载到S-CSCF;HSS提供与SIP应用服务器间基于Diameter协议的Sh接口,为增值业务SIP应用服务器或OSA SCS提供签约数据、业务逻辑脚本的远程数据库访问接口,HSS仅负责对特定签约用户应用服务器增值业务数据的透明存储,语义上不做解析。
AS是应用服务器,该实体为IMS网络的用户提供IP多媒体业务,应用服务器可以位于用户的归属网络,也可以位于第三方,第三方可以是一个网络,也可以是一个单独的应用服务器。
在网络中存在一个共享的数据库,其中保存有网络为用户提供业务服务时所需要的业务数据。网络中的应用服务器可以根据各个应用服务器的权限来对共享数据库中的用户业务数据进行读、写、增加、删除等操作。这些可以对共享数据库中所保存的用户业务数据进行操作的应用服务器,可以是完成同一业务的应用服务器,也可以是完成不同业务的应用服务器。应用服务器与共享数据库的连接关系如图2所示。
应用服务器通过与HSS的Sh接口获得或更新用户业务相关的数据和用户状态信息,S-CSCF通过与HSS的Cx接口获得用户的签约信息。
在IMS网络中,会话建立时是通过S-CSCF中的初始过滤规则将会话路由到相应的应用服务器为用户提供各种业务的。初始过滤规则本身只包含了特定业务的触发条件,而业务的实现是在应用服务器完成的。初始过滤规则的数据内容如图3所示。
初始过滤规则数据中,Application Server这一项包含了ServerName字段,该字段以SIP URL的形式(Application@example.com)来保存应用服务器的地址/名称信息。一旦S-CSCF收到的SIP请求消息符合某条初始过滤规则触发条件,则S-CSCF就会按照该初始过滤规则中ServerName字段所保存的应用服务器地址,将SIP请求消息转发至该应用服务器来为用户作业务服务。应用服务器收到该SIP消息后,就会按其业务逻辑来为用户提供业务服务,以及后续的处理。
具体的IMS网络中SIP请求消息触发路由机制如图4所示。
在IMS网络建设初期,用户比较少,可以使用一个应用服务器来为IMS网络中的所有用户提供某个业务服务。当网络中的用户增加后,如果还是一个应用服务器为全网络用户提供业务,那么该应用服务器可能会存在负载过重的情况。于是,就需要增加提供同一业务服务的应用服务器的数量,同时也引发如何实现将网络中的用户分配到不同应用服务器的问题。现有技术中给出目前已经公开的两种实现应用服务器上用户分配的方法。
将网络中的用户分配到提供同一业务的若干个应用服务器的方法可以是利用现有初始过滤规则机制,通过针对单个用户的某项业务的初始过滤规则中的ServerName字段不同,实现将用户分配到实现同一业务的不同应用服务器。如目前IMS网络中有多个应用服务器:Application_1@example.com、Application_2@example.com、Application_3@example.com来为用户提供相同的基本呼叫业务。则可以通过设定不同用户的基本呼叫业务的初始过滤规则中的ServerName字段来实现将不同用户的基本呼叫业务分配到不同的应用服务器来处理。比如:用户甲的基本呼叫初始过滤规则中的ServerName字段设置为Application_1@example.com;用户乙的基本呼叫初始过滤规则中的ServerName字段设置为Application_2@example.com;用户丙的基本呼叫初始过滤规则中的ServerName字段设置为Application_3@example.com。
这样,当用户甲使用基本呼叫业务时,为其服务的S-CSCF会根据其初始过滤规则中的ServerName字段取值,来将该呼叫业务触发到Application_1这个应用服务器来处理。同样用户乙和用户丙的基本呼叫业务也会分别被转至Application_2和Application_3处理。通过这种方法来实现对网络中应用服务器负荷进行分担的目的。
在现有技术一中,初始过滤规则的修改需要通过网管操作来实现,这样当需要从一个应用服务器上将大量用户移到另一个应用服务器时,就会引发浩大的网管配置工作,这种低效率的分配方法无疑会增加运营商的运营费用。
在现有技术二中,如图5所示,将应用服务器分为representativeAs(代理应用服务器)和processing As(处理应用服务器)两级,并在用户签约信息中的初始过滤规则中记录的应用服务器地址设置为代理应用服务器,当业务请求消息经由S-CSCF触发到处理应用服务器后,代理应用服务器来决定将该业务请求消息分配到某个处理应用服务器来真正实现业务处理,以达到合理分配应用服务器业务负载的目的。
在代理应用服务器选择好处理应用服务器后,可以选择保存所选择的处理应用服务器信息,也可以不保存。同时,代理应用服务器也可以选择自己是否保存在后续的SIP消息路径中。如图6所示,当代理应用服务器决定不将自己保存在后续的SIP消息路径时,S-CSCF直接与处理应用服务器交互。
在现有技术二中,在IMS中增加一个与业务提供无关的特定应用服务器用于分配提供同一业务的各个应用服务器的负载,这个代理应用服务器可能会成为新的负载过重的瓶颈节点。
发明内容
本发明的目的在于解决现有技术中存在的网管配置工作量大,效率低的问题,以及代理应用服务器成为新的负载过重的瓶颈节点的问题。
根据本发明的一个方面,提出了一种应用服务器分配方法,包括以下步骤:步骤S902,呼叫会话控制功能实体从用户签约信息中的初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务;步骤S904,呼叫会话控制功能实体将业务请求消息转发至所选择的应用服务器;以及步骤S906,所选择的应用服务器在接收到业务请求消息后为用户服务。
上述的步骤S902还包括以下步骤:步骤S902-2,呼叫会话控制功能实体接收到业务请求消息或发现用户需要进行第三方注册;步骤S902-4,呼叫会话控制功能实体确定与业务请求消息匹配的用户签约信息中的初始过滤规则;以及步骤S902-6,呼叫会话控制功能实体在初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务。
上述的步骤S906还包括以下步骤:步骤S906-2,所选择的应用服务器在接收到来自呼叫会话控制功能实体的业务请求消息后回复响应消息;以及步骤S906-4,所选择的应用服务器为用户提供服务。
上述的初始过滤规则包括:一个或多个应用服务器项中包括的服务器名称。一个或多个应用服务器项可以包括对应于一个或多个应用服务器的服务器选择权重。
上述的初始过滤规则包括:一个应用服务器项中包括的一个或多个应用服务器的服务器名称列表。一个应用服务器项可以包括以下至少一种信息:对应于一个或多个应用服务器的服务器选择权重和服务器名称数量。
上述的呼叫会话控制功能实体根据其上配置的策略或规则从初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务。上述的策略或规则通过以下至少一种方式来确定:通过运营商来制定,通过用户签约时设定的个人喜好来确定,通过各服务器的选择权重来确定,以及通过应用服务器的负载来确定。
在呼叫会话控制功能实体中没有用户签约信息的情况下,呼叫会话控制功能实体从用户的归属签约用户服务器获取用户签约信息。
在用户签约信息中不存在初始过滤规则的情况下,呼叫会话控制功能实体根据用户签约信息选择缺省的应用服务器为用户服务。
在应用服务器拒绝业务请求的情况下,响应消息中包括拒绝业务请求的原因。在应用服务器拒绝业务请求的情况下,呼叫会话控制功能实体从初始过滤规则中重新选择一个应用服务器为用户服务。
在呼叫会话控制功能实体在一定时间内没有接收到来自应用服务器的响应消息的情况下,呼叫会话控制功能实体从初始过滤规则中重新选择一个应用服务器为用户服务。
上述的业务请求消息是会话发起协议注册消息和会话发起协议请求消息中的至少一个。
根据本发明的另一方面,提供了一种应用服务器分配装置,位于呼叫会话控制功能实体侧,包括:接收模块,用于接收业务请求消息;选择模块,用于从用户签约信息中的初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务;以及消息转发模块,用于将业务请求消息转发至所选择的应用服务器。
上述的选择模块包括:初始过滤规则确定单元,用于确定与业务请求消息匹配的初始过滤规则;以及应用服务器选择单元,用于在初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务。选择模块还包括签约信息获取模块,用于从用户的归属签约用户服务器获取用户签约信息。
上述的初始过滤规则包括:一个或多个应用服务器项中包括的服务器名称。一个或多个应用服务器项还包括对应于一个或多个应用服务器的服务器选择权重。
上述的初始过滤规则包括:一个应用服务器项中的一个或多个应用服务器的服务器名称列表。该一个应用服务器项还包括以下至少一种信息:对应于一个或多个应用服务器的服务器选择权重和服务器名称数量。
上述的选择模块根据呼叫会话控制功能实体上配置的策略或规则从初始过滤规则中选择一个或多个应用服务器中的一个应用服务器为用户服务。策略或规则通过以下方式中的至少一个来确定:通过运营商来制定,通过用户签约时设定的个人喜好来确定,通过一个或多个服务器的选择权重来确定,以及通过应用服务器的负载来确定。
在用户签约信息中不存在初始过滤规则的情况下,选择模块根据用户签约信息选择缺省的应用服务器为用户服务。
在接收到来自应用服务器的包括拒绝原因的响应消息的情况下,选择模块从初始过滤规则中重新选择一个应用服务器为用户服务。在一定时间内没有接收到来自应用服务器的响应消息的情况下,选择模块从初始过滤规则中重新选择一个应用服务器为用户服务。
上述的业务请求消息是会话发起协议注册消息和会话发起协议请求消息中的至少一个。
通过使用本发明的应用服务器分配方法和装置,降低了网管配置工作量,提高了系统效率。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。
附图说明
结合到说明书中并构成说明书一部分的附图示出了本发明的实施例,并与上面给出的一般描述和下面给出的实施例的详细描述一起,用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是示出了IMS网络系统架构的示意图;
图2是示出了应用服务器与共享数据库的连接关系的示意图;
图3是示出了初始过滤规则的数据内容的示意图;
图4是示出了IMS中SIP请求消息路由流程的流程图;
图5是示出了现有技术中应用服务器分级架构的示意图;
图6示出了现有技术中路由优化后SIP消息路由路径的示意图;
图7示出了根据本发明的初始过滤规则中扩展的第一种数据格式;
图8示出了根据本发明的初始过滤规则中扩展的第二种数据格式;
图9示出了根据本发明的应用服务器分配方法的流程图;
图10示出了根据本发明的应用服务器分配装置的方框图;
图11示出了根据本发明的实施例的当用户需要第三方注册时应用服务器分配的流程图;
图12示出了根据本发明的实施例的用户始呼业务实现应用服务器分配的流程图;
图13示出了根据本发明的实施例的用户终叫业务实现应用服务器分配的流程图;
图14示出了根据本发明的实施例的首次分配的应用服务器回绝请求后重新分配应用服务器的流程;以及
图15示出了根据本发明的实施例的首次分配应用服务器超时无响应而重新分配应用服务器的流程图。
具体实施方式
下面将参照附图详细描述本发明的优选实施例。
如图7所示,本发明在用户签约信息中的初始过滤规则中增加了多个应用服务器(Application Server)项的内容,在必要时还在多个应用服务器项中添加了服务器选择权重(ServerWeight字段),ServerWeight字段取值可以为百分比或1-N的整数,用于表明在选择时服务器时,该服务器在服务器列表中所占的权重,以表示该服务器在服务器列表中所处的被选择的优先级。若该字段用百分比表示,则各个服务器的权重之和为1。
如图8所示,本发明还可以修改用户签约信息中的初始过滤规则iFC数据中应用服务器(Application Server)这一项的内容,删除原有的服务器名称(ServerName字段),增加服务器名称列表(ServerNameList字段),还可以添加服务器名称数量(ServerNameNumber字段)和对应于列表中的应用服务器的服务器权重列表(ServerWeightList)两个字段。
ServerNameNumber字段取值为1-N的整数,用于表明该应用服务器项中记录有多少个应用服务器的地址/名称。
ServerWeightList字段包括对应于服务器名称列表中的一个或多个应用服务器的服务器权重。
ServerNameList字段为多个应用服务器地址/名称信息,并以SIP URL的形式记录,比如:Application_A@example.com,Application_B@example.com等。当S-CSCF收到的SIP请求消息符合某条iFC触发条件,则S-CSCF就会从该iFC中ServerNameList字段所保存的多个应用服务器地址列表中挑选一个,并将SIP请求消息转发至该AS来为用户做业务服务。当被挑选的应用服务器收到该业务请求消息后,就会按其上保存的业务逻辑来为用户提供业务服务,以及后续的处理。
网络中发生针对某个用户的每一次会话业务请求(这些会话业务请求可以是SIP Register和SIP Invite消息),业务请求消息被路由至呼叫会话控制功能实体后,呼叫会话控制功能实体则将该业务请求与其上保存的该用户签约信息初始过滤规则iFC作比较,以找到符合本次业务请求的初始过滤规则。如果这时该S-CSCF还没有该用户的签约信息,则呼叫会话控制功能实体可以从该用户的归属签约用户服务器中获取该用户的签约信息。
当呼叫会话控制功能实体找到与本次业务请求所匹配的初始过滤规则iFC后,便从该条初始过滤规则iFC中ServerNameList字段或多个应用服务器(Application Server)项的内容所记录的若干个SIP URL所对应的应用服务器中,根据一定策略选择是由地址信息列表中那个应用服务器来处理本次业务请求。
应用服务器AS1接收到来自呼叫会话控制功能S-CSCF的业务请求后,可以根据自己的负载情况来判断是否为该用户提供服务。比如如果某个应用服务器AS1的负载上限设定为80%,则当其负荷达到这个域值时,就可以拒绝接受这次业务请求,而给呼叫会话控制功能实体回复失败响应消息,并可以在该失败响应消息中携带失败原因码,来指示本次业务请求被拒绝的原因是本应用服务器AS1的当前负载过高,无法为用户提供业务。
呼叫会话控制功能实体可以根据应用服务器AS1回复的失败消息,得知该应用服务器AS1已经达到负载上限不能再接受用户服务请求。这样,呼叫会话控制功能实体就可以从该用户本次业务请求所匹配的初始过滤规则iFC中ServerNameList字段或多个应用服务器(Application Server)项的内容所记录的若干个SIP URL中,根据一定策略重新选择一个应用服务器AS2,并将本次业务请求转发给该应用服务器AS2。
图9示出了根据本发明的应用服务器分配方法的流程图。如图9所示,应用服务器分配方法包括如下步骤:步骤S902,呼叫会话控制功能实体从用户签约信息中的初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务;步骤S904,呼叫会话控制功能实体将业务请求消息转发至所选择的应用服务器;以及步骤S906,所选择的应用服务器在接收到业务请求消息后为用户服务。
其中,步骤S902还包括以下步骤:步骤S902-2,呼叫会话控制功能实体接收到业务请求消息或发现用户需要进行第三方注册;步骤S902-4,呼叫会话控制功能实体确定与业务请求消息匹配的用户签约信息中的初始过滤规则;以及步骤S902-6,呼叫会话控制功能实体在初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务。
步骤S906还包括以下步骤:步骤S906-2,所选择的应用服务器在接收到来自呼叫会话控制功能实体的业务请求消息后回复响应消息;以及步骤S906-4,所选择的应用服务器为用户提供服务。
一种方式为:初始过滤规则包括一个或多个应用服务器项中包括的服务器名称。一个或多个应用服务器项可以包括对应于一个或多个应用服务器的服务器选择权重。
另一种方式为:初始过滤规则包括一个应用服务器项中包括的一个或多个应用服务器的服务器名称列表。一个应用服务器项可以包括以下至少一种信息:对应于一个或多个应用服务器的服务器选择权重和服务器名称数量。
其中,呼叫会话控制功能实体根据其上配置的策略或规则从初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务。策略或规则通过以下至少一种方式来确定:通过运营商来制定,通过用户签约时设定的个人喜好来确定,通过各服务器的选择权重来确定,以及通过应用服务器的负载来确定。
在呼叫会话控制功能实体中没有用户签约信息的情况下,呼叫会话控制功能实体从用户的归属签约用户服务器获取用户签约信息。
在用户签约信息中不存在初始过滤规则的情况下,呼叫会话控制功能实体根据用户签约信息选择缺省的应用服务器为用户服务。
在应用服务器拒绝业务请求的情况下,响应消息中包括拒绝业务请求的原因。在应用服务器拒绝业务请求的情况下,呼叫会话控制功能实体从初始过滤规则中重新选择一个应用服务器为用户服务。
在呼叫会话控制功能实体在一定时间内没有接收到来自应用服务器的响应消息的情况下,呼叫会话控制功能实体从初始过滤规则中重新选择一个应用服务器为用户服务。
上述的业务请求消息是会话发起协议注册消息和会话发起协议请求消息中的至少一个。
图10是示出了根据本发明的网络中应用服务器分配装置的方框图。如图10所示,应用服务器分配装置包括如下模块:接收模块1002,用于接收业务请求消息;选择模块1004,用于从用户签约信息中的初始过滤规则中选择一个或多个应用服务器中的一个应用服务器为用户服务;以及消息转发模块1006,用于将业务请求消息转发至所选择的应用服务器。
选择模块1004包括:初始过滤规则确定单元1004-2,用于确定与业务请求消息匹配的初始过滤规则;以及应用服务器选择单元1004-4,用于在初始过滤规则中选择一个或多个应用服务器中的一个应用服务器为用户服务。选择模块1004还包括签约信息获取单元1004-6,用于从用户的归属签约用户服务器获取用户签约信息。
一种方式为:初始过滤规则一个或多个应用服务器项中包括的服务器名称。一个或多个应用服务器项可以包括对应于一个或多个应用服务器的服务器选择权重。
另一种方式为:初始过滤规则包括一个应用服务器项中的一个或多个应用服务器的服务器名称列表。该一个应用服务器项可以包括以下至少一种信息:对应于一个或多个应用服务器的服务器选择权重和服务器名称数量。
其中,选择模块根据呼叫会话控制功能实体上配置的策略或规则从初始过滤规则中选择一个或多个应用服务器中的一个应用服务器为用户服务。策略或规则通过以下方式中的至少一个来确定:通过运营商来制定,通过用户签约时设定的个人喜好来确定,通过一个或多个服务器的选择权重来确定,以及通过应用服务器的负载来确定。
在用户签约信息中不存在初始过滤规则的情况下,选择模块根据用户签约信息选择缺省的应用服务器为用户服务。
在接收到来自应用服务器的包括拒绝原因的响应消息的情况下,选择模块从初始过滤规则中重新选择一个应用服务器为用户服务。在一定时间内没有接收到来自应用服务器的响应消息的情况下,选择模块从初始过滤规则中重新选择一个应用服务器为用户服务。
上述的业务请求消息是会话发起协议注册消息和会话发起协议请求消息中的至少一个。
第一实施例
图11示出了本发明的实施例的当用户需要第三方注册时应用服务器分配的流程图。如图11所示,用户需要第三方注册时应用服务器分配包括如下步骤:
步骤S1102,进行正常IMS网络UE注册流程。
步骤S1104,用户注册成功后,S-CSCF根据从HSS那里下载得到的初始过滤规则,进行业务逻辑控制发现需要进行第三方注册。
步骤S1106,而与第三方注册所匹配的初始过滤规则中记录的是若干个应用服务器的SIP URL,S-CSCF根据其上的配置的策略或规则,在应用服务器地址列表中选择一个应用服务器。其中这些策略和规则可以是运营商所制定,也可以是用户签约的个人选择喜好,也可以通过一个或多个服务器的选择权重来确定,也可以根据应用服务器地址列表中这些应用服务器的负载情况,或者是以上因素的组合。
步骤S1108,S-CSCF向选择好的应用服务器发起第三方注册。
步骤S1110,被选定的应用服务器收到第三方注册请求后,如果注册成功,回复200OK给S-CSCF作为成功响应。
第二实施例
图12示出了本发明的实施例的用户始呼业务实现应用服务器分配的流程图。如图12所示,包括以下步骤:
步骤S1202,用户发起始呼请求,发送SIP Invite消息给其所连接的P-CSCF。
步骤S1204,P-CSCF将从用户那里接收到的SIP Invite消息路由至该用户注册时所选定的S-CSCF,如果该用户没有注册,但该用户签约了未注册业务,则可以通过现有的未注册业务流程,由网络来为该用户选择一个S-CSCF处理用户的业务请求。
步骤S1206,S-CSCF收到SIP Invite消息后,根据其上保存的用户签约信息中的初始过滤规则来做业务逻辑控制,寻找与本次业务请求所匹配的初始过滤规则。
步骤S1208,当S-CSCF找到一个匹配的初始过滤规则后,发现该初始过滤规则中ServerNameList字段或多个应用服务器(Application Server)项的内容所保存的若干个应用服务器SIPURL。S-CSCF根据其上的配置的策略或规则,在DNS返回的应用服务器地址列表中选择一个应用服务器来。这些策略和规则可以是运营商所制定,也可以是用户签约的个人选择喜好,也可以通过一个或多个服务器的选择权重来确定,也可以根据应用服务器地址列表中这些应用服务器的负载情况,或者是以上因素的组合。S-CSCF根据其上的配置选择是否保存DNS返回的应用服务器地址列表以备后续业务处理时使用。
如果S-CSCF没有找到匹配的初始过滤规则,则会根据签约信息来由一个缺省的应用服务器为用户处理本次业务。
步骤S1210,S-CSCF将本次业务请求消息SIP Invite路由至所选定的应用服务器。
步骤S1212,应用服务器收到SIP Invite后,根据其上的业务逻辑来做后续的业务处理。
第三实施例
图13示出了根据本发明的实施例的用户终叫业务实现应用服务器分配的流程。如图13所示,用户终叫业务实现应用服务器分配的流程包括如下步骤:
步骤S1302,对端发起一次向本用户的业务请求,SIP Invite消息被路由至为该用户提供服务的S-CSCF。
步骤S1304,S-CSCF收到SIP Invite消息后,可以根据该消息的头域内容得知本次业务请求是一个始呼请求,并根据其上保存的该用户签约信息中的初始过滤规则来做业务逻辑控制,寻找与本次业务请求所匹配的初始过滤规则。
步骤S1306,当S-CSCF找到一个匹配的初始过滤规则后,发现该初始过滤规则中ServerNameList字段或多个应用服务器(Application Server)项的内容所保存的若干个应用服务器SIPURL。S-CSCF根据其上的配置的策略或规则,在DNS返回的应用服务器地址列表中选择一个应用服务器来。这些策略和规则可以是运营商所制定,也可以是用户签约的个人选择喜好,也可以通过一个或多个服务器的选择权重来确定,也可以根据应用服务器地址列表中这些应用服务器的负载情况,或者是以上因素的组合。
如果S-CSCF没有找到匹配的初始过滤规则,则会根据签约信息来由一个缺省的应用服务器为用户处理本次业务。
步骤S1308,S-CSCF将本次业务请求消息SIP Invite路由至所选定的应用服务器。
步骤S1310,应用服务器收到SIP Invite后,根据其上的业务逻辑来做后续的业务处理。
第四实施例
图14示出了根据本发明的实施例的首次分配的应用服务器回绝请求后重新分配应用服务器的流程图。如图14所示,首次分配的应用服务器回绝请求后,重新分配应用服务器的流程包括以下步骤:
步骤S1402,用户发起始呼请求,发送SIP Invite消息给其所连接的P-CSCF。
步骤S1404,P-CSCF将从用户那里接收到的SIP Invite消息路由至该用户注册时所选定的S-CSCF。如果该用户没有注册,但该用户签约了未注册业务,则可以通过现有的未注册业务流程,由网络来为该用户选择一个S-CSCF处理用户的业务请求。
步骤S1406,S-CSCF收到SIP Invite消息后,根据其上保存的用户签约信息中的初始过滤规则来做业务逻辑控制,寻找与本次业务请求所匹配的初始过滤规则。
步骤S1408,当S-CSCF找到一个匹配的初始过滤规则后,发现该初始过滤规则中ServerNameList字段或多个应用服务器(Application Server)项的内容所保存的若干个应用服务器SIPURL。S-CSCF根据其上的配置的策略或规则,在DNS返回的应用服务器地址列表中选择一个应用服务器来。这些策略和规则可以是运营商所制定,也可以是用户签约的个人选择喜好,也可以通过一个或多个服务器的选择权重来确定,也可以根据应用服务器地址列表中这些应用服务器的负载情况,或者是以上因素的组合。S-CSCF根据其上的配置选择是否保存DNS返回的应用服务器地址列表以备后续业务处理时使用。
如果S-CSCF没有找到匹配的初始过滤规则,则会根据签约信息来由一个缺省的应用服务器为用户处理本次业务。
步骤S1410,S-CSCF将本次业务请求消息SIP Invite路由至所选定的应用服务器1。
步骤S1412,应用服务器1收到SIP Invite后,由于其负载超过限定值,通过SIP消息回绝本次业务请求,并可以在该SIP消息中携带拒绝业务请求原因值——“过载”。
步骤S1414,S-CSCF收到来自应用服务器1的拒绝响应后,S-CSCF从步骤4的应用服务器地址列表中根据策略和规则重新选择一个应用服务器2来为用户提供业务服务。
步骤S1416,S-CSCF发送SIP Invite消息给应用服务器2。
步骤S1418,应用服务器2收到来自S-CSCF的业务请求后,如果可以接受本次业务请求,则会按照其上的业务逻辑为用户的本次业务请求提供后续业务处理。
第五实施例
图15示出了根据本发明第五实施例的首次分配应用服务器超时无响应而重新分配应用服务器的流程图。如图14所示,首次分配应用服务器超时无响应,重新分配应用服务器的流程包括如下步骤:
步骤S1502,用户发起始呼请求,发送SIP Invite消息给其所连接的P-CSCF。
步骤S1504,P-CSCF将从用户那里接收到的SIP Invite消息路由至该用户注册时所选定的S-CSCF。如果该用户没有注册,但该用户签约了未注册业务,则可以通过现有的未注册业务流程,由网络来为该用户选择一个S-CSCF处理用户的业务请求。
步骤S1506,S-CSCF收到SIP Invite消息后,根据其上保存的用户签约信息中的初始过滤规则来做业务逻辑控制,寻找与本次业务请求所匹配的初始过滤规则。
步骤S1508,当S-CSCF找到一个匹配的初始过滤规则后,发现该初始过滤规则中ServerNameList字段或多个应用服务器(Application Server)项的内容所保存的若干个应用服务器SIPURL。S-CSCF根据其上的配置的策略或规则,在DNS返回的应用服务器地址列表中选择一个应用服务器。这些策略和规则可以是运营商所制定,也可以是用户签约的个人选择喜好,也可以通过一个或多个服务器的选择权重来确定,也可以根据应用服务器地址列表中这些应用服务器的负载情况,或者是以上因素的组合。S-CSCF根据其上的配置选择是否保存DNS返回的应用服务器地址列表以备后续业务处理时使用。
如果S-CSCF没有找到匹配的初始过滤规则,则会根据签约信息来由一个缺省的应用服务器为用户处理本次业务。
步骤S1510,S-CSCF将本次业务请求消息SIP Invite路由至所选定的应用服务器1。
步骤S1512,S-CSCF一直没有收到来自应用服务器1的响应消息,S-CSCF上的定时器超时后,S-CSCF从步骤S508的应用服务器地址列表中根据策略和规则重新选择一个应用服务器2来为用户提供业务服务。
步骤S1514,S-CSCF发送SIP Invite消息给应用服务器2。如果后续S-CSCF收到了来自应用服务器1的响应消息,则S-CSCF丢弃该响应消息。
步骤S1516,应用服务器2收到来自S-CSCF的业务请求后,如果可以接受本次业务请求,则会按照其上的业务逻辑为用户的本次业务请求提供后续业务处理。
综上所述,本发明提出了一种实现网络中应用服务器分配方法及装置,解决了现有技术中存在的网管配置工作量大,效率低的问题。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (26)
1.一种应用服务器分配方法,其特征在于包括以下步骤:
步骤S902,呼叫会话控制功能实体从用户签约信息中的初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务;
步骤S904,所述呼叫会话控制功能实体将业务请求消息转发至所选择的应用服务器;以及
步骤S906,所选择的应用服务器在接收到所述业务请求消息后为所述用户服务。
2.根据权利要求1所述的应用服务器分配方法,其特征在于,所述步骤S902还包括以下步骤:
步骤S902-2,所述呼叫会话控制功能实体接收到业务请求消息或发现用户需要进行第三方注册;
步骤S902-4,所述呼叫会话控制功能实体确定与所述业务请求消息匹配的用户签约信息中的初始过滤规则;以及
步骤S902-6,所述呼叫会话控制功能实体在所述初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为所述用户服务。
3.根据权利要求2所述的应用服务器分配方法,其特征在于,所述步骤S906还包括以下步骤:
步骤S906-2,所选择的应用服务器在接收到来自所述呼叫会话控制功能实体的所述业务请求消息后回复响应消息;以及
步骤S906-4,所选择的应用服务器为所述用户提供服务。
4.根据权利要求1至3中任一项所述的应用服务器分配方法,其特征在于,所述初始过滤规则包括:一个或多个应用服务器项中包括的服务器名称。
5.根据权利要求4所述的应用服务器分配方法,其特征在于,所述一个或多个应用服务器项还包括对应于所述一个或多个应用服务器的服务器选择权重。
6.根据权利要求1至3中任一项所述的应用服务器分配方法,其特征在于,所述初始过滤规则包括:一个应用服务器项中包括的一个或多个应用服务器的服务器名称列表。
7.根据权利要求6所述的应用服务器分配方法,其特征在于,所述一个应用服务器项还包括以下至少一种信息:对应于所述一个或多个应用服务器的服务器选择权重和服务器名称数量。
8.根据权利要求4或6所述的应用服务器分配方法,其特征在于,
所述呼叫会话控制功能实体根据其上配置的策略或规则从所述初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务。
9.根据权利要求8所述的应用服务器分配方法,其特征在于,所述策略或规则通过以下至少一种方式来确定:通过运营商来制定,通过用户签约时设定的个人喜好来确定,通过各服务器的选择权重来确定,以及通过所述应用服务器的负载来确定。
10.根据权利要求8所述的应用服务器分配方法,其特征在于,在所述呼叫会话控制功能实体中没有所述用户签约信息的情况下,所述呼叫会话控制功能实体从所述用户的归属签约用户服务器获取所述用户签约信息。
11.根据权利要求8所述的应用服务器分配方法,其特征在于,在所述用户签约信息中不存在所述初始过滤规则的情况下,所述呼叫会话控制功能实体根据所述用户签约信息选择缺省的应用服务器为所述用户服务。
12.根据权利要求8所述的应用服务器分配方法,其特征在于,在所述应用服务器拒绝所述业务请求的情况下,所述响应消息中包括拒绝所述业务请求的原因。
13.根据权利要求8所述的应用服务器分配方法,其特征在于,在所述应用服务器拒绝所述业务请求的情况下,所述呼叫会话控制功能实体从所述初始过滤规则中重新选择一个应用服务器为所述用户服务。
14.根据权利要求8所述的应用服务器分配方法,其特征在于,在所述呼叫会话控制功能实体在一定时间内没有接收到来自所述应用服务器的响应消息的情况下,所述呼叫会话控制功能实体从所述初始过滤规则中重新选择一个应用服务器为所述用户服务。
15.一种应用服务器分配装置,位于呼叫会话控制功能实体侧,其特征在于包括:
接收模块,用于接收业务请求消息;
选择模块,用于从用户签约信息中的初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为用户服务;以及
消息转发模块,用于将业务请求消息转发至所选择的应用服务器。
16.根据权利要求15所述的应用服务器分配装置,其特征在于,
所述选择模块包括:
初始过滤规则确定单元,用于确定与所述业务请求消息匹配的初始过滤规则;以及
应用服务器选择单元,用于在所述初始过滤规则中记录的一个或多个应用服务器中选择一个应用服务器为所述用户服务。
17.根据权利要求16所述的应用服务器分配装置,其特征在于,
还包括签约信息获取模块,用于从所述用户的归属签约用户服务器获取所述用户签约信息。
18.根据权利要求15至17中任一项所述的应用服务器分配装置,
其特征在于,所述初始过滤规则包括:一个或多个应用服务器项中包括的服务器名称。
19.根据权利要求18所述的应用服务器分配装置,其特征在于,
所述一个或多个应用服务器项还包括对应于所述一个或多个应用服务器的服务器选择权重。
20.根据权利要求15至17中任一项所述的应用服务器分配装置,
其特征在于,所述初始过滤规则包括:一个应用服务器项中的一个或多个应用服务器的服务器名称列表。
21.根据权利要求20所述的应用服务器分配装置,其特征在于,
所述一个应用服务器项还包括以下至少一种信息:对应于所述一个或多个应用服务器的服务器选择权重和服务器名称数量。
22.根据权利要求18或20所述的应用服务器分配装置,其特征在于,所述选择模块根据所述呼叫会话控制功能实体上配置的策略或规则从所述初始过滤规则中选择一个或多个应用服务器中的一个应用服务器为用户服务。
23.根据权利要求22所述的应用服务器分配装置,其特征在于,
所述策略或规则通过以下方式中的至少一个来确定:通过运营商来制定,通过用户签约时设定的个人喜好来确定,通过所述一个或多个服务器的选择权重来确定,以及通过所述应用服务器的负载来确定。
24.根据权利要求22所述的应用服务器分配装置,其特征在于,
在所述用户签约信息中不存在所述初始过滤规则的情况下,所述选择模块根据所述用户签约信息选择缺省的应用服务器为所述用户服务。
25.根据权利要求22所述的应用服务器分配装置,其特征在于,
在接收到来自所述应用服务器的包括拒绝原因的响应消息的情况下,所述选择模块从所述初始过滤规则中重新选择一个应用服务器为所述用户服务。
26.根据权利要求22所述的应用服务器分配装置,其特征在于,
在一定时间内没有接收到来自所述应用服务器的响应消息的情况下,所述选择模块从所述初始过滤规则中重新选择一个应用服务器为所述用户服务。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006100990986A CN101110756A (zh) | 2006-07-18 | 2006-07-18 | 应用服务器分配方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006100990986A CN101110756A (zh) | 2006-07-18 | 2006-07-18 | 应用服务器分配方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101110756A true CN101110756A (zh) | 2008-01-23 |
Family
ID=39042657
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2006100990986A Pending CN101110756A (zh) | 2006-07-18 | 2006-07-18 | 应用服务器分配方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101110756A (zh) |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101946481A (zh) * | 2008-02-14 | 2011-01-12 | 汤姆森许可贸易公司 | 将内容流传输到远程位置的系统和方法 |
CN101448244B (zh) * | 2008-04-09 | 2011-04-20 | 中兴通讯股份有限公司 | Ip多媒体子系统集中业务中用户终端配置业务的方法 |
CN102185900A (zh) * | 2011-04-18 | 2011-09-14 | 北京新媒传信科技有限公司 | 一种应用服务平台系统和一种开发应用服务的方法 |
CN102215266A (zh) * | 2011-06-20 | 2011-10-12 | 中兴通讯股份有限公司 | 持久化服务的实现方法及持久化服务系统 |
CN101459533B (zh) * | 2008-04-16 | 2011-10-26 | 中兴通讯股份有限公司 | 一种下一代网络中改进的应用服务器容灾的系统及方法 |
CN101447890B (zh) * | 2008-04-15 | 2011-11-30 | 中兴通讯股份有限公司 | 一种下一代网络中改进的应用服务器容灾的系统及方法 |
CN102413022A (zh) * | 2011-12-31 | 2012-04-11 | 北京新媒传信科技有限公司 | 一种应用调试方法和系统 |
CN102546544A (zh) * | 2010-12-20 | 2012-07-04 | 中兴通讯股份有限公司 | 一种ims网络中应用服务器的组网结构 |
CN102571699A (zh) * | 2010-12-20 | 2012-07-11 | 中兴通讯股份有限公司 | 在应用服务器池中选择应用服务器的方法及装置 |
CN101645825B (zh) * | 2008-08-04 | 2012-10-17 | 华为技术有限公司 | 过载处理方法及系统、过载处理的sip实体 |
WO2012142854A1 (zh) * | 2011-04-18 | 2012-10-26 | 北京新媒传信科技有限公司 | 一种应用服务平台系统及其实现方法 |
CN103067906A (zh) * | 2012-12-07 | 2013-04-24 | 大唐移动通信设备有限公司 | Ims架构中s-cscf对用户签约信息的保存方法 |
CN103176790A (zh) * | 2011-12-26 | 2013-06-26 | 阿里巴巴集团控股有限公司 | 应用发布方法和系统 |
CN103209165A (zh) * | 2012-01-17 | 2013-07-17 | 阿尔卡特朗讯 | Ims中的应用服务器框架以及转发会话控制逻辑的方法 |
CN103336721A (zh) * | 2013-07-08 | 2013-10-02 | 北京奇虎科技有限公司 | 数据库操作请求分配方法、设备和系统 |
CN103780578A (zh) * | 2012-10-22 | 2014-05-07 | 腾讯科技(深圳)有限公司 | 一种帐号生成方法、系统和装置 |
CN105282254A (zh) * | 2015-11-05 | 2016-01-27 | 厦门游力信息科技有限公司 | 一种识别应用分发渠道的方法及系统 |
CN106549901A (zh) * | 2015-09-16 | 2017-03-29 | 大唐移动通信设备有限公司 | 一种业务触发方法和装置 |
CN108616576A (zh) * | 2018-04-08 | 2018-10-02 | 网宿科技股份有限公司 | 一种调度应用服务器的方法和装置 |
CN108989284A (zh) * | 2018-06-07 | 2018-12-11 | 深圳震有科技股份有限公司 | 一种业务触发方法、存储介质以及应用服务器 |
US20190320044A1 (en) * | 2014-05-07 | 2019-10-17 | TreSensa Inc. | Coordinating services across multiple providers |
-
2006
- 2006-07-18 CN CNA2006100990986A patent/CN101110756A/zh active Pending
Cited By (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101946481A (zh) * | 2008-02-14 | 2011-01-12 | 汤姆森许可贸易公司 | 将内容流传输到远程位置的系统和方法 |
CN101946481B (zh) * | 2008-02-14 | 2013-09-25 | 汤姆森许可贸易公司 | 将内容流传输到远程位置的系统和方法 |
CN101448244B (zh) * | 2008-04-09 | 2011-04-20 | 中兴通讯股份有限公司 | Ip多媒体子系统集中业务中用户终端配置业务的方法 |
CN101447890B (zh) * | 2008-04-15 | 2011-11-30 | 中兴通讯股份有限公司 | 一种下一代网络中改进的应用服务器容灾的系统及方法 |
CN101459533B (zh) * | 2008-04-16 | 2011-10-26 | 中兴通讯股份有限公司 | 一种下一代网络中改进的应用服务器容灾的系统及方法 |
CN101645825B (zh) * | 2008-08-04 | 2012-10-17 | 华为技术有限公司 | 过载处理方法及系统、过载处理的sip实体 |
CN102571699A (zh) * | 2010-12-20 | 2012-07-11 | 中兴通讯股份有限公司 | 在应用服务器池中选择应用服务器的方法及装置 |
CN102546544A (zh) * | 2010-12-20 | 2012-07-04 | 中兴通讯股份有限公司 | 一种ims网络中应用服务器的组网结构 |
CN102185900A (zh) * | 2011-04-18 | 2011-09-14 | 北京新媒传信科技有限公司 | 一种应用服务平台系统和一种开发应用服务的方法 |
WO2012142854A1 (zh) * | 2011-04-18 | 2012-10-26 | 北京新媒传信科技有限公司 | 一种应用服务平台系统及其实现方法 |
CN102185900B (zh) * | 2011-04-18 | 2013-07-17 | 北京新媒传信科技有限公司 | 一种应用服务平台系统和一种开发应用服务的方法 |
CN103283209A (zh) * | 2011-04-18 | 2013-09-04 | 北京新媒传信科技有限公司 | 一种应用服务平台系统及其实现方法 |
CN103283209B (zh) * | 2011-04-18 | 2015-12-09 | 北京新媒传信科技有限公司 | 一种应用服务平台系统及其实现方法 |
CN102215266A (zh) * | 2011-06-20 | 2011-10-12 | 中兴通讯股份有限公司 | 持久化服务的实现方法及持久化服务系统 |
CN103176790B (zh) * | 2011-12-26 | 2016-04-20 | 阿里巴巴集团控股有限公司 | 应用发布方法和系统 |
CN103176790A (zh) * | 2011-12-26 | 2013-06-26 | 阿里巴巴集团控股有限公司 | 应用发布方法和系统 |
CN102413022B (zh) * | 2011-12-31 | 2014-04-16 | 北京新媒传信科技有限公司 | 一种应用调试方法和系统 |
CN102413022A (zh) * | 2011-12-31 | 2012-04-11 | 北京新媒传信科技有限公司 | 一种应用调试方法和系统 |
CN103209165A (zh) * | 2012-01-17 | 2013-07-17 | 阿尔卡特朗讯 | Ims中的应用服务器框架以及转发会话控制逻辑的方法 |
CN103209165B (zh) * | 2012-01-17 | 2016-04-13 | 阿尔卡特朗讯 | Ims中的应用服务器框架以及转发会话控制逻辑的方法 |
CN103780578A (zh) * | 2012-10-22 | 2014-05-07 | 腾讯科技(深圳)有限公司 | 一种帐号生成方法、系统和装置 |
CN103067906B (zh) * | 2012-12-07 | 2015-08-12 | 大唐移动通信设备有限公司 | Ims架构中s-cscf对用户签约信息的保存方法 |
CN103067906A (zh) * | 2012-12-07 | 2013-04-24 | 大唐移动通信设备有限公司 | Ims架构中s-cscf对用户签约信息的保存方法 |
CN103336721A (zh) * | 2013-07-08 | 2013-10-02 | 北京奇虎科技有限公司 | 数据库操作请求分配方法、设备和系统 |
US20190320044A1 (en) * | 2014-05-07 | 2019-10-17 | TreSensa Inc. | Coordinating services across multiple providers |
US10965782B2 (en) * | 2014-05-07 | 2021-03-30 | Tresensa Technologies, Inc. | Coordinating services across multiple providers |
CN106549901A (zh) * | 2015-09-16 | 2017-03-29 | 大唐移动通信设备有限公司 | 一种业务触发方法和装置 |
CN106549901B (zh) * | 2015-09-16 | 2020-04-17 | 大唐移动通信设备有限公司 | 一种业务触发方法和装置 |
CN105282254A (zh) * | 2015-11-05 | 2016-01-27 | 厦门游力信息科技有限公司 | 一种识别应用分发渠道的方法及系统 |
CN105282254B (zh) * | 2015-11-05 | 2018-05-04 | 厦门游力信息科技有限公司 | 一种识别应用分发渠道的方法及系统 |
CN108616576A (zh) * | 2018-04-08 | 2018-10-02 | 网宿科技股份有限公司 | 一种调度应用服务器的方法和装置 |
CN108616576B (zh) * | 2018-04-08 | 2022-05-27 | 网宿科技股份有限公司 | 一种调度应用服务器的方法和装置 |
CN108989284A (zh) * | 2018-06-07 | 2018-12-11 | 深圳震有科技股份有限公司 | 一种业务触发方法、存储介质以及应用服务器 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101110756A (zh) | 应用服务器分配方法和装置 | |
CN103220323B (zh) | 用于服务控制的装置 | |
CN100596076C (zh) | 个人网管理中用户设备登记、激活系统、方法及装置 | |
CN102857891B (zh) | 一种被叫用户的域选择方法和系统,以及系统中的hss | |
CN101094442B (zh) | 一种电路交换域终呼锚定方法 | |
CN102239481B (zh) | 具有负载平衡的ims diameter路由器 | |
CN100382503C (zh) | 一种在用户注册过程中注册异常的处理方法 | |
CN102035798B (zh) | 一种实现容灾的业务处理方法、系统及装置 | |
CN101132401A (zh) | 业务交互处理方法和系统 | |
US20070171851A1 (en) | Method for the control and evaluation of a message traffic of a communication unit by means of a first network unit within a mobile radio system, pertaining communication unit and first network unit | |
WO2009059637A1 (en) | Method and system for providing communication party related information | |
CN101106521A (zh) | 具有增强的业务过滤规则的分组网络及其实现方法 | |
CN101796794B (zh) | 用于在使用数据库的ims网络中获得计费和服务质量控制实体的地址的方法和数据库 | |
CN101170611A (zh) | 实现音视频信箱服务的方法及系统 | |
CN101202797B (zh) | Cs域/ims语音fmc业务方案 | |
CN101193068A (zh) | 一种应答请求的方法和设备 | |
CN101192920A (zh) | 一种应答请求的方法和设备 | |
CN101076198B (zh) | 多媒体彩像业务实现方法 | |
CN101217806B (zh) | 一种用户设备漫游情况下媒体路由的选择方法 | |
CN101529883B (zh) | 向匿名呼叫者提供组合服务的系统和方法 | |
CN101132560A (zh) | 业务交互处理方法和系统 | |
CN100442714C (zh) | 通信指纹系统及通信指纹采集、管理方法 | |
CN101242655B (zh) | 一种漫游情况下归属网选择媒体路由模式的方法 | |
CN101459533B (zh) | 一种下一代网络中改进的应用服务器容灾的系统及方法 | |
JP5061101B2 (ja) | 回線交換ネットワークを介した複数のユーザ間の呼を処理する方法、及び当該方法とともに用いるための通信端末装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20080123 |