用于处理电话呼叫的方法本发明涉及处理电话呼叫的方法，并涉及用于这个方法中的控
制点。具体地，本发明涉及处理电话呼叫的方法，允许在网络结构
的几个控制点分布业务逻辑。
智能网结构典型地包括业务控制点(SCP)，有大量的业务交换
点(SSP)与之连接。每个SSP是一个交换系统，能够截取电话呼叫
和探询SCP。SCP包括特定业务逻辑和数据，允许它将关于如何处理
所截取的呼叫的指令返回给SSP。
然而在一些情况下，在网络结构中提供几个SCP是有意的。当SSP
需要能够从两个不同的数据库获得数据时，会出现这种可能性，分
别通过不同的SCP访问数据库。
US专利NO.4,924,510涉及这样一种情况，其中SSP需要能够
在两个不同的SCP访问存储在两个数据库之一当中的信息。根据所
拔的号码，SSP探询第一SCP。如果相关信息未存储在与第一SCP相
关的数据库之中，第一SCP向SSP返回一条消息，包括一个特定号
码，使得始发初始探询的被叫方号码的经修改的版本有效。根据这
个经修改的号码，SSP发送一个探询给与第二数据库相关的第二控制
点，以从第二数据库获得被请求的数据。然而，这个方法的不益之
处在于，从第一控制点返回到交换点的特定号码，需要被以和初始
拨号被叫方号码完全相同的方式分析。这给SS施加了额外的处理负
载。
US专利NO.5,386,467通过定义一个新的SCP-SCP协议来避
免在US-4,924,510中出现的坏处。当第一SCP确定它不能提供
足够的信息来建立所需的连接时，它通过发送信息请求消息直接从
第二SCP请求信息。然后第二SCP直接将请求的信息发送给SSP。这
种方法的益处在于，它只需要3次消息发送以提供所请求的信息。
然而，这种所建议的方法的不利之处在于，它要求第一和第二SCP
之间有一定程度的兼容性，即它们要共享一个适合的协议。
因此在现有技术中，没有从两个不同的SCP获取信息，以处理
一个呼叫请求的方法。结果，交换点所要求的处理一个呼叫请求的
信息必须存储在一个SCP中，没有可能实现业务逻辑的分布式设置。
根据本发明，第一SCP能够向SSP返回一条消息，消息包括一
条精确指令，将一个探询指向一个特定的第二SCP。益处在于，被返
回的消息需要SSP中较少的处理。进而，被发送到第二SCP的探询
可以包括信息，允许第二SCP再将控制返回到第一SCP。这允许业务
逻辑的分布式设置。
为了更好地理解本发明，将通过例子参考附图进行描述，其中：
图1是根据本发明的网络结构的框图；和
图2是说明根据本发明的网络结构的操作部分的流程图。
如图1所示，网络包括两个业务控制点2,4，和一个业务交换
点6。当然应当理解在实际应用中，网络将包括大量业务交换点，可
能包括多于两个业务控制点，但是所示的网络部分足以说明本发明。
业务交换点(SSP)6截取从端用户8发送来的呼叫，该呼叫要传送
给其它用户，可能通过其它交换点。为了直接连接呼叫，SSP必须从
业务控制点(SCP)获得信息。这样SCP存储特定业务逻辑和数据，
允许它将关于如何处理所截取的呼叫的指令返回给SSP。在有这种基
本结构的现有技术的网络中，没有方法从两个不同的SCP获取信息，
以处理一个呼叫请求。结果，每个SCP必须存储全部所需信息，所
以没有可能实现业务逻辑的分布式设置。尽管现有技术公开了网络
结构，其中交换点能够访问两个不同的数据库，如上所述提出的这
些方法有问题，不能实现完全分布式业务逻辑。
然而，在某些情况下，以分布方式实现业务逻辑是有益处的。
例如提供大量的离其相应用户近的控制点是有益处的，包括涉及业
务的更多公共部分的业务逻辑，例如向用户探询有关被请求的特征，
评定用户访问业务的权利，或者获取出呼叫的统计。逻辑的更多特
定业务部分在集中的SCP中处理是有益的，它被大量SSP探询。这
避免了在每个位置安装和维护完整的SCP软件和数据，也避免了不
利之处，即包括所有业务逻辑和数据的一个集中式SCP，将带来大量
的远程信令业务。
同样，分布式逻辑结构的益处将是，即使用户临时位于另一个
运行者的网络中，它将能够使用同样的业务，如同呼叫始发于其自
己的网络中一样。
图2是一个流程图，表示本发明的使用，以及它对SSP的操作
的影响。
在步骤22,SSP截取来自端用户的呼叫。在步骤24，根据呼叫
SSP向第一SCP发送一个探询，例如图1中的SCP2。根据探询，在
步骤26 SSP接收来自第一SCP的指令。
在步骤28，这些指令被分析，以确定是否包括一条切换指令。
如果在业务执行过程中确定另一个SCP应当管理呼叫尝试的控
制，就从SCP发送一条切换指令。切换指令包括：一个参数，表示
发送指令的SCP的网络地址；一个参数，表示控制将被转移到的其
它SCP的网络地址；和一个计数器，在切换时递增以保证两个SCP
不会在一个无限循环中相互切换。有益地，切换指令还包括以下附
加信息：一个参数包括发送指令的SCP的相关信息；一个参数，包
括控制将被转移到的SCP的相关信息；一个参数，包括能被用在建
立面向第二SCP的TCAP对话中的信息，诸如所用协议的标识，TCAP
对话部分数据等；和一个参数包括被用在建立面向第一SCP的TCAP
对话中的信息，以允许控制被切换回到那个SCP。
在步骤28如果确定没有接收到切换指令，则在步骤30以传统
方式处理呼叫。然而，如果在步骤28确定已经接收到切换指令，则
SSP和第一SCP之间的对话就闭合，而和第二SCP的一个新的对话被
打开，例如图1中的SCP4，在步骤32作为一个探询发送给第二SCP。
这个新对话能够使用由第一SCP所指示的地址和其它的信息。根据
发送给第二SCP的探询，在34指令被接收。如同在28，在步骤36
这些指令被分析，以确定它们是否包括切换指令。如果没有，在步
骤30处理呼叫。如果接收到切换指令，表示呼叫控制应当被反送回
第一SCP，则在步骤38发送一个适当的探询。接着在步骤40，从第
一SCP接收适当的指令并且过程进行到步骤30，在这里处理呼叫。
将会理解第二SCP可以确定第三SCP应当接管呼叫尝试的控制。
如果这样，适当的切换指令可以被返回到SSP，包括例如第三SCP的
网络地址。在这种情况下，SSP将探询指向第三SCP并从它接收指令。
这样的指令可以允许呼叫被处理或者可以包括一条指令切换到另一
个SCP。
因此公开了一种呼叫处理方法，允许业务逻辑的有效分布，而
不需要新的SCP到SCP的接口。
具体地，应注意SSP可以用不同的协议和两个SCP通信。