专利名称：用于输入和输出查询存储转发业务的系统和方法
技术领域：
本发明涉及附加电信业务的提供，并且更具体地涉及一种用于促使与呼叫相关的业务扩展到与呼叫无关的存储转发业务的系统和方法。
2．相关技术的描述用户对定制电信业务的需求一直快速成长。呼叫等待、呼叫转发、缩位拨号等特殊用户功能为各位用户所提供的更多方便正变得日益重要，同样这些附加收入来源对电信业务提供商也变得日益重要。这些业务通常是通过服务特殊用户的中央局交换机的软件中的特殊编程提供的。即，对本地交换机交换软件独立编程以为连接到那里的用户提供特殊业务功能。通常交换机的硬件和软件都必须升级以能够提供特殊的用户功能。
当一个呼叫涉及连接到不同交换机的两方之间的互连时，它是通过所谓的转换交换局或汇接局完成的，汇接局形成独立的中央局交换机互连网络的一部分。在这种情况下，汇接局对双方是完全透明的，只在两个端局之间提供语音通路。任何一方请求的所有特殊业务传统上都是由用户所连接的端局提供的，独立于双方之间的网络连接。
在大多数提供简易老式电话业务(POTS)的电信系统中，主叫方(A方)和被叫方(B方)之间的通信链路在A方的控制之下。因此，A方和B方之间的通信链路一直保持到A方的电话装置“挂机”时，系统才切断通信链路和双方的端局以及用于将端局链接起来的所有汇接局。如果B方将他或她的电话装置挂机，这只会有很小的效果，直到以分钟为量级的周期后，定时器触发，切断主叫和被叫方之间的电路。在新型的电信业务中，如综合业务数字网(ISDN)，使用B方切断连接，但是实现机制与常规POTS网有很大不同。
在常规电信交换机中提供特殊用户业务要求广泛地升级每一部为用户提供这种特殊业务的独立交换机的软件。这种交换机的升级通常特别昂贵并且从成本效益观点看事实上抑制了附加用户业务所带来的附加收入。这种情况在小镇或乡村地区更是如此，那里特殊用户业务的需求相对低，而现存的交换机已经使用了相当长的时间并且能够继续充分地服务那个地区多数用户的基本电信需求。
电信业正面临着增长的竞争压力。由于多种因素，各处电信运营商的每分钟收入已经稳定地减少。反常的电信业务业界竞争者的数目已经增多。另外，象回叫业务和呼叫卡之类的新方法允许用户赚取双方国家之间双方呼叫费率的差价。同时，有线电视公司现在已经开始通过它们的有线网络提供电话业务。最后，在现在，新软件已经使通过互联网的高质量全双工呼叫成为可能。
技术上的进步也已经降低了提供基本电话业务的成本。电信公司可以不再为提供基本电话业务调整相对高的费率。技术的进步事实上已经使进行电话呼叫的实际成本降为零。按照经济术语，基本电话业务可以看成零边缘成本业。近年来台式计算机在性能价格比提高上的进展也已经推动了现代电话交换机的可靠性和效率。
局际交换连接也处于相同的境地。由于使用了光纤，电话网的容量有了极大的提高。带宽不再象几年前那样是珍贵的资源，并且，事实上已经成为频繁地按批量买进和卖出的日用品。
技术上的进步已经降低或消除了以主叫方和被叫方之间地理距离来作为提供电话呼叫成本中重要因素的影响。已经讨论过，按照网络资源，从斯德哥尔摩呼叫达拉斯(大约8,000公里的距离)并不比从达拉斯呼叫奥斯汀(大约300公里的距离)花费更多。
互联网爆炸性地增长很大程度上是由于所采用的TCP/IP协议允许与所涉及的传输距离无关地发送电子邮件和传输文件。
尽管事实上提供长途业务并不比本地基本电话业务成本更高，但是电信运营商对长途电话呼叫的收费仍然高于本地呼叫。电信业内竞争的增长很可能使这种情况日益无法维持。由于长途呼叫传统上是电信公司运营利润的重要来源，电信公司需要找到新的收入来源已变得日益明显。
电信运营商可以增加收入的一种方法是为用户提供用户愿意额外付费的高级业务。如前所述，在过去的网络结构中，网络附加的新功能要求重写核心交换软件——一个昂贵并且冗长的过程，而且要冒将新的麻烦引入系统的额外危险。另外，必须用新软件更新网络中的每一部交换机进一步提高了引入新业务的成本。电信运营商不再希望容忍这种事态。对能够首先将产品带入市场的电信设备制造商，这是一个巨大的商业机会。
电信运营商已经表明了对在他们的电信网中引入新业务的快速并且廉价的技术的需求。此外，他们希望新功能的影响只限于一部或几部交换机。同时也希望能够通过中央管理工具处理业务管理，如业务的安装或修改、添加用户指定的数据等等。
还希望新业务的设计和实施是由电信运营商完成，而不是设备制造商。这就使电信运营商能够快速反应以感知市场需求并且更有效地服务他们的用户。还发现希望在交换软件中结合更多的智能以允许不同的业务与用户交互。这样，电话装置可以成为一个高级的电信网络接口。
智能网络(IN)已经作为一种解决上述要求的方案提出来。IN技术设计成允许电信运营商设计它自己的独特业务集或用现有的业务来适应特殊的用户需求。另外，IN结构允许安装新业务的影响只限于几个控制节点。
IN结构的另一个设计特色是它的集中业务管理。这就加快了响应时间并且降低了运营网络所要求的人力资源开销。另外，IN结构允许用户控制一些用户指定的数据。
举例而言，一些电信运营商提供“个人号码”业务。个人号码业务给每个用户一个指定的电话号码，通常是一个前缀“区号”为500的号码。个人号码业务背后的设计哲学是只用一个电话号码来代替每个用户的多个联系号码。这样，当有人拨叫用户的个人号码时，交换机将查询中央数据库并获得可能到达用户的全部电话号码的列表。然后，交换机将以一个预定的顺序振铃那些号码中的每一个，直到该呼叫被应答。
在这种业务的一个变体中，可以为用户提供一种从任何一部电话装置来动态更新联系号码数据库的能力。这种用户控制可以允许用户添加他或她临时所处的饭店或其它位置的号码。
IN结构后面的设计哲学是缩短向市场提供新业务的时间，降低开发和管理成本，并且提高提供附加业务所带来的利益。IN业务最好的例子是当用户跨越很大的地理区域时使用单一被叫号码(B号码)重定向到多个本地业务中心中的一个。这样，pizza店可以只做一个pizza订购电话号码的广告。当用户拨叫这个广告的号码时，IN业务可以根据主叫用户的号码(A号码)将这个呼叫定向到最近的经销店。
IN简史智能网络的概念起源于美国。最初是想要提供一个中央数据库以便将单一被叫号码翻译为不同的端接号码。IN业务最早的应用是提供免费呼叫(“免费电话”)。
免费号码并不直接对应于物理电话线，而是需要翻译为实际终端号码。这种翻译可以根据主叫者的位置或者一天中的时间来进行。
称为7号信令系统(SS7)的新的信令系统允许呼叫建立之前或建立中在电话交换机之间高速通信。SS7协议第一次允许实现免费呼叫所需要的数据库查找。在SS7技术开发之后，就有可能通过电话网实际上瞬时交换数据。这就是智能网络的起源。
IN革命的下一步是从静态数据库迁移到允许用户来控制用户指定的数据的动态数据库。当用户可以通过用户装置的交互键盘控制呼叫过程时，就允许了附加的交互性。这种交互IN在美国称为先进智能网络(AIN)。
当前对IN结构的开发和兴趣正被几个大规模的应用所驱动。两个这样的应用就是通用用户号(UPN)业务和虚拟专用网(VPN)业务。在UPN业务中，为每个独立(用户)分配一个唯一号码而不是一部电话装置。UPN号码可以用来联系用户而不论他或她的位置或网络类型(是否是固定的或移动的)。
VPN业务允许使用公用网资源建立专用网。这样，一个公司就可以拥有一个公司电话网，允许它的所有雇员彼此通信，而不必投资提供物理专用网络所需的硬件或软件。通过使用公用网实现专用网，公司客户还可以避免维护物理网络的成本。
当前IN系统的不足之处使用智能网络(IN)结构已经被鼓吹为加速合并以及展开新的网络能力和网络业务的解决方案。但是，当前实现IN概念的连接标准还要容忍大量的缺点。
在当前受关注的IN实现方案中的用户可以有权访问多种定制的业务和功能。例如，可能允许用户使用较短的拨号代码指定频繁地被叫的号码，这种功能常常被称为“短编号”、“快速拨号”或“缩位拨号”业务。当前的标准也允许用户将出呼叫限制为特定的号码或特定的号码范围(如区号、国家代号、900号码等)，这种功能称为“呼叫限制”。
用户也可以对入呼叫进行限制，如请求自动拒绝来自一个或多个特定号码的所有呼叫或属于特定类别(例如掩蔽了主叫身份的呼叫)的所有呼叫，这种功能称为“匿名呼叫拒绝”。用户还可以将他们的呼叫从陆地线路转发到移动终端，从一个移动终端转发到另一个移动终端，等等。
IN系统中的用户还可以接收与呼叫无关的消息，如语音邮件、电子邮件(e-mail)、短消息业务(SMS)格式的消息等等。当前的IN标准通常还没有明确或建议的技术或程序以便使用与来自用户的入呼叫和到用户出呼叫所提供的功能和限制相一致的方法来限制产生、存储、重发或接收与呼叫无关的存储转发业务。
这样，如果有3个用户A、B和C是虚拟专用网的成员，其中在每个工作日的下班时间，从A到B的呼叫被自动路由到C，那么将从A到B的电子邮件在下班时间也自动重定向到C则可能更有利。同样，如果限制公司范围电信网中的部分用户从他们的部门之外拨叫电话，用类似的限制处理那些用户的语音邮件和传真邮件也可能是有用的。
业务提供商已经发现用户喜欢将他们对入呼叫和出呼叫的偏爱、优先权和权利也用于与呼叫无关的业务。由于已经将用户的偏爱作为智能网络(IN)的业务控制功能(SCF)中的配置文件或业务脚本存储，如果IN中处理与呼叫无关的存储转发消息收发业务的IP(智能外设)也有权访问存储在SCP中的业务脚本，则将是有用的。
如果电信业务提供商能够与可用或适用于用户作出的或到用户的呼叫的业务、功能和限制一致地来为用户提供与呼叫无关的消息的业务、功能和限制，那么业务提供商就能够为用户提供增值(业务)，并且因此得到额外的收入。
所以，非常希望能够在智能网络系统中提供一些手段，从而可为语音邮件、电子邮件(e-mail)、SMS消息、传真邮件等这些与呼叫无关的存储与转发业务提供与呼叫相关的业务(如建立用户特定的虚拟专用网(VPN)、缩位拨号(短编号)、入呼叫和出呼叫限制(呼叫限制，匿名呼叫拒绝)、呼叫转发等)所允许的相同等级的实施支持和操作功能。这接下来又需要一种用于在IN中查询系统控制器(如业务控制功能(SCF))以获得通常只可用于与呼叫相关的处理调用的用户特定的数据的系统和方法。
发明概要因此本发明的首要目的是促进从与呼叫相关的业务到与呼叫无关的存储与转发业务的扩展。本发明的另一个目的是综合形成限制一种或多种消息类型的产生、存储、重发或传输的能力，而与涉及到业务配置文件或偏爱的消息类型无关。本发明的另一个目的是允许在不同节点接收的不同类型的消息可根据用户指定的限制和偏爱来进行存储、重发或用某种分配的方式传送。
本发明的附加目的是提供在不同物理节点上实施的综合消息收发业务。本发明通过定义一个协议而在IN结构的基础上提供这种网络化的解决方案，从而实现综合的、与呼叫无关的存储和转发消息解决方案。
本发明打算提供一种能使与呼叫无关的存储与转发消息与那些适用于IN系统中的呼叫的业务配置相一致的解决方案，以便用户可以选择将他们的部分或全部输入和输出的消息与他们的入和出呼叫等同对待。
本发明的一个实施例已经在包括多个通过网络连接到SCP(业务控制点)的IP(智能外设)的IN(智能网络)电信系统中实现了。多个IP还通过不同的电信骨干网彼此相连。
在本发明的一个实施例中，已接收了一个消息的输入的IP接下来查询SCP以确定是否有发送方或接收方请求、选择或要求了如限制控制和号码翻译之类的IN业务。SCP通过确认该查询来作出响应，并且将所产生的结果返回IP。
在本发明的另一个实施例中，当处理出呼叫和消息的IP发送一个输出消息时，IP便查询SCP以确定是否有发送方或接收方请求、选择或要求了诸如限制控制和号码翻译之类的IN业务。SCP通过确认该查询来进行响应，并且将所产生的结果返回IP以便进一步处理，可选地，这种处理可以通过检索并分析相应于发起或终止方的业务脚本而实现的。
一个IN用户可以申请几个与呼叫无关的存储与转发业务，如语音邮件、电子邮件、SMS传真邮件等，并且可以希望将这些各种消息类型的产生、存储、重发和传输协调起来。涉及所申请的不同业务的各种消息在IN网络中通常存储在不同的物理或逻辑IP中。
本发明通过为INAP引入两个新过程来完成这些要求，这两个新过程是“Incoming Delivery Interrogation(输入的传输查询)”命令，它使接收输入消息的IP能够向SCF查询有关适用于消息的接收者发送或接收的呼叫的权利和限制；“Outgoing Delivery Interrogation(输出的传输查询)”命令，它使发送输出消息的IP能够向SCF查询有关适用于消息的发送者发送或接收的呼叫的权利和限制。
附图的简要描述参考下面优选实施例的详细描述并且结合附图，可以对本发明的方法和系统得到更彻底的理解，其中图1是表示标准智能网络(IN)概念模型的说明图；图2表示示范的简单智能网络的组件；图3表示与业务无关的结构单元(SIB)的结构；图4表示不同的IN功能实体到物理单元的映射；图5表示一个带有汇接级业务节点的IN实现的例子；图6表示在IN概念模型中实现不同业务的优选方法；图7说明面向API实现方案的两种方案；图8表示一种使用业务逻辑程序(SLP)定义个人代理的技术；图9表示一个本发明的网络化IP(NIP)系统和方法的实施例；图10是说明“Incoming Delivery Interrogation”命令操作期间SCP和输入的IP之间的交互操作的顺序图。
图11是说明“Outgoing Delivery Interrogation”命令操作期间SCP和输出的IP之间的交互操作的顺序图。
图12表示本发明的与呼叫无关的输入消息处理期间SCP的有限状态机。
图13表示本发明的与呼叫无关的输入消息处理期间IP的有限状态机。
图14表示本发明的与呼叫无关的输出消息处理期间SCP的有限状态机。
图15表示本发明的与呼叫无关的输出消息处理期间IP的有限状态机。
优选实施例的描述本发明为一组涉及从与呼叫有关的业务(如蜂窝虚拟专用网(CVPN)编号、短编号(缩位拨号)、呼叫限制、呼叫转发等)向与呼叫无关的存储与转发消息收发业务(如语音邮件、传真邮件、电子邮件(e-mail)、SMS消息等)扩展的问题提供解决方案。在本申请中揭示和描述的IN概念的扩展也可以用于其它电信环境并且也会促进为用户提供相关的附加业务。
智能网络(IN)结构智能网络是一种为促进在如公用电话交换网(PSTN)或公用陆地移动网(PLMN)中引入新能力和业务提供灵活性的电信网结构。这种新能力和业务的例子包括免费呼叫(“免费电话”)、信用卡业务和虚拟专用网(VPN)。
IN体现了未来无拘束网络的梦想，给业务提供商和用户人格化网络业务，独立地接入、交换期(switch term)技术和网络提供商提供了自由。对IN的一个国际上一致同意的观点已在ITU-TS建议Q.1200中描述。
IN结构的细节已经在国际电信联盟(ITU)建议I.312/Q.1201中作了规定，它也包括对图1所示的IN概念模型(INCM)的口头解释。ITU的IN概念模型已分析并且系统化了与呼叫处理相关的各种任务和过程并且将所提供的业务分为4个平面业务平面101，全局功能平面102，分布功能平面103和物理平面104。
迄今为止，IN已经集中在以下称为号码业务的一组业务周围，例如，免费呼叫(“免费电话”)、信用卡呼叫、个人号码业务、电话投票等。所有这些业务的关键特性是它们为不受限于访问节点中的访问端口的号码提供业务。电信网中的任意节点可以通过添加业务交换功能(SSF)和/或特殊资源功能(SRF)(二者都通过与业务无关的协议接口受控于业务控制功能(SCF))成为业务节点。SCF是由业务数据功能(SDF)支持的，它可以在物理上不受节点的约束。
IN的主要结构单元是SSF,SCF,SDF和SRF。SRF以下也称为逻辑智能外设(逻辑IP)。每个这些结构单元都是一个独立的逻辑实体，可以但是不必须在物理上与其它电话网络、逻辑或其它实体结合在一起。物理和逻辑实体在下面优选实施例的描述中是被作为一体而交换引用的。
IN结构将基本呼叫过程划分为严格定义的几个阶段，从而为电信业务提供商和用户提供了操作呼叫过程的能力。简单智能网络200的组件如图2所示。智能网络的标准结构定义了IN的不同组件以及独立组件之间的接口。
当对IN业务进行呼叫时，该呼叫首先路由到网络中称为业务交换点(SSP)的特殊节点。如果SSP识别入呼叫是一个IN呼叫，则挂起呼叫的所有进一步处理，同时SSP通知IN系统中的另一个节点(业务控制点(SCP))已经接收到一个IN呼叫。
SCP在“智能网络”中提供“智能”。SCP控制发生在IN呼叫上的每一件事并且作出所有呼叫处理决定。当SCP确定了要对呼叫进行适当的动作时，SCP就命令SSP执行所需的动作。
业务控制功能(SCF)包含IN业务逻辑并且对涉及调用那个业务的呼叫所做的决定承担完全责任。这个业务逻辑可以在任何电信平台(例如，爱立信的AXE平台或UNIX)上运行。包含SCF的节点(即，物理硬件和软件)称为业务控制点(SCP)201。
每种业务所需的数据(例如，用户电话号码列表)是由业务数据功能(SDF)提供的。在IN结构的一个实施例中，业务所需的数据存储在SCF自身内。正式地，存储业务相关数据的功能被分配给根据要求为SCF提供数据的SDF。在典型IN实现中，SDF可以是运行象Sybase这样商业可用的数据库程序的UNIX机。包含SDF的物理节点称为业务数据点(SDF)202。
交换机的一般呼叫处理和监督功能是由呼叫控制功能(CCF)完成的。当通常CCF不是标准IN结构的一部分时，CCF为IN提供SSF已经接收到的有关呼叫以及执行顺序的信息。
业务交换功能(SSF)解释SCF发出的指令并且将要执行的命令送到CCF。SSF还从CCF接收呼叫事件数据(例如，用户的挂机/摘机状态或用户线已经占用)并且将数据送到SCF。包含SSF的物理节点(即，交换机硬件和软件)称为业务交换点(SSP)204和205。
专用资源功能(SRF)提供IN业务中使用的特定资源，例如，DTMF(双音多频)数字接收、广播和语音识别。在ITU IN建议中，SRF直接与SCF通信。在IN的另一个实施例中，SRF功能可以与SSF位于同一地点。在这种情况下，SRF不与SCF直接通信，而是通过SSF。SRF在图2中未示出。
业务管理功能(SMF)207管理IN业务的维护，例如，添加或删除数据或业务的安装或修订。业务建立环境功能(SCEF)207允许开发、测试以及向SMF输入IN业务。在IN的一种实现中，SMF和SCEF结合为一体并称为业务管理应用系统(SMAS)。SMAS应用是TMOS族的一部分并且在UNIX操作系统下运行。它允许使用图形界面来设计业务并且为业务数据条目提供方便的表单。
图2表示连接到SDP 202以及SSP 204和205的示范的SCP 201。SCP还连接到SMF/SCEF 207。所有到SCP 201以及来自SCP 201的链路在图2中都用虚线表示以指明它们不是语音链路。SDP 202也通过非语音链路连接到SMF/SCEF 207。SSP 204连接到两部本地交换机(LE)223和224以及一部汇接交换机(TE)211。汇接交换机211又连接到另外两部本地交换机221和222。SSP 205连接到本地交换机225。图2中所示的本地交换机223和224连接到一个示范的发起用户T-A 231，以及一个示范的终止用户T-B 232。
如果每一个IN逻辑结构单元也是物理实体，按前面描述的符号，相应的物理节点称为业务交换点(SSP)、业务控制点(SCP)、业务数据点(SDP)和物理智能外设(IP)。按照前面的陈述，在下面的讨论中，术语IP一般是指逻辑IP和物理IP。
用户代理在SCF中是用主叫和被叫号码来识别的，并且当服务节点中所准备的触发点被命中时被调用。信令数据和呼叫状态数据可以由用户代理来操纵。SRF能够与用户或者彼此之间在带内通信以克服当前信令系统的限制。
当前的IN标准假设配置了一个用户的访问位置和原籍位置，但是可能不受接入节点和业务节点的限制。虽然分离接入节点和业务节点功能降低了引入业务的成本，却会在接入端口业务和基于号码的业务之间导致潜在的不希望的交互作用。因此要求接入节点对业务节点的增强来提供业务设计中的灵活性。
另一种情况将为接入节点添加两种远程可变更的个人电信范畴——一种为发起呼叫提供到业务节点的无条件热线连接，另一种为终止呼叫提供到业务节点的无条件呼叫转发。如果可以降低成本并且提高容量，就需要像蜂窝网络一样长期区分访问和原籍位置。
IN的一个独特的特点是业务是在基于与业务无关的结构单元(SIB)的IN业务平台上、而不是直接在网络节点上实现的。SIB是SCP的一部分。图3表示SIB的结构。每个SIB 301是业务逻辑的基本逻辑单元，它对程序员隐藏了实施细节。当现存的SIB不满足新要求时，就定义新的SIB。
在IN产品中，SIB 301执行信令信息分析、连接拓扑控制、与用户交互、读写数据、收集并输出呼叫数据等功能。其它SIB是跳转、执行子程序、循环切换等纯语言单元。每个SIB 301在业务平台中都是可用的。业务逻辑程序(SLP)是由SIB 301建立的，并且以它们的名字命名。业务逻辑可以使用业务建立环境功能(SCEF)设计。SCEF可以通过与系统无关的应用编程接口(API)使用SIB 301。如图所说明的，将一个逻辑输入送到SIB，该SIB 301产生多个逻辑输出312。SIB还接收SIB支持数据321并且接收和输出呼叫实例数据322。
图4表示不同IN功能实体到物理单元或实体的映射，其中后缀“F”代表不同的功能实体，而后缀“P”代表物理实体。图4中，首字母缩写SMF表示业务管理功能，而首字母缩写CCF表示呼叫控制功能。
图5说明一个具有汇接级业务节点的IN结构的例子。图5中的业务节点可以从任何接入节点到达，如PSTN或ISDN中的本地交换机或公用陆地移动网(PLMN)系统的MSC。业务节点可以服务个人电话和其它基于号码的业务。用户身份和授权信息可以在带内发送到SRF或嵌入信令系统的主叫和被叫号码域中。
个人代理具有在呼叫控制功能CCF(即，触发点数据)、业务控制功能SCF(即，业务逻辑)、和业务数据功能SDF(即，业务数据)中的组件。图5中说明的IN平台组件可以集成在接入节点中或独立于业务节点而实现。
业务交换功能(SSF)的作用是识别调用IN业务的呼叫，然后通知SCF接收如何处理该呼叫的指令。SCF是IN的智能所在，它包含执行不同业务所要求的逻辑。SDF是一个数据库系统，提供数据附加业务所需的数据存储能力。IP是为用户交互操作(如语音广播和对话、双音多频接收(DTMF)和语音识别)提供资源的网络单元。
IN应用编程接口(API)图1所示的ITU的IN概念也定义了实现不同业务的方法，如图6所示。为了实现业务或功能601，首先在602将业务请求翻译为SIB结构。产生的SIB 603在604映射到不同的功能实体605。功能实体605再在606映射到一个或多个物理实体607。
应该注意与所有非IN标准的之间不同，IN中的业务要求不是直接翻译成业务功能。相反地，业务要求被翻译为业务平台单元(即，SIB)，然后再根据IN三级模型实现成为电信网中可复用的能力和协议单元。
面向实现应用程序接口(API)至少有两种可能的方案与图1所示的ITU IN概念模型一致。一种方案是将业务逻辑分为两部份固定逻辑部分和灵活逻辑部分。然后SIB再链接形成被固定逻辑作为子程序而调用的判决图。固定逻辑可以用C或C++等标准编程语言表达，并且在标准执行环境中编译并装载。相反，灵活逻辑部分只包括可交换的数据。
第二种方案是定义业务API，它通过各SIB之间的彼此结合获得所需的功能在逻辑的所有方面获得全面控制。在这种方案中，每个SIB可以链接到任何其它的SIB。一部分SIB执行电信功能，而其它则只在逻辑上链接单元。所有逻辑都表示为描述可以使用哪些SIB、它们是如何链接的、以及每个SIB使用什么数据完成它的功能的数据。这样，所有实施细节都对业务程序员隐藏起来。这正是爱立信的IN产品使用的主要方案。
图7说明面向实现API的两种方案。图7A表示SIB平台方案，图7B表示业务逻辑执行环境(SLEE)方案。图7A的SIB方案将所有业务逻辑表达为可以在业务平台中用来形成灵活业务配置(FSP)的基本SIB功能的结合。图7B所示的SLEE方案将SIB看作如C、C++、业务逻辑程序(SLP)等编程语言表达的固定逻辑的子程序。编译的代码使用电信平台原语，如INAP(智能网络应用部分)操作和数据库原语。
当对所有逻辑和数据使用相同数据表示时，可以依靠灵活业务配置(FSP)定义个人代理，如图8所示。这种方案具有很多优点，例如，允许在不中断业务的情况下装载并且激活不同的逻辑单元，以及在个人代理有故障的情况下，将受影响的区域只限制为激活故障功能的呼叫。
功能交互作用是IN系统开发中的主要障碍。这个问题来自每个功能通常依赖于其它功能。需要解决这种交互作用，但现在还没有达成协议的解决方案。在实践中已经发现，当引入新功能时现有功能的实施通常要受到影响，并且其中有很多必须重设计或者完全受阻。应该注意到这个问题有两种处理观点IN系统的网络中心观点和用户中心观点。
传统的网络中心观点在向现存系统中添加附加业务时，将IN看作其它技术的补充。功能交互作用曾经并且继续阻碍着这种观点成为一种现实。每一种新附加业务都包括固定业务逻辑部分和潜在的灵活逻辑部分。这样，个性化就限制为将一些预定的附加业务和各功能间相互结合可以获得什么。添加新业务可能需要长期并且昂贵的开发，与IN之前PSTN,PLMN和ISDN中的实践没有区别。这种观点的中心论点不是设计新功能，而是努力地将新功能与其它已有功能集成。
相反，IN的用户中心观点的焦点是用户而不是功能。原则上，假设各个用户的需求都是独特的，业务提供商对所有业务逻辑有完全的控制。应用FSP方案，通过重用SIB而不是重用功能可以建立大量的独特业务配置。这意味着功能交互作用不再是一个问题，因为再没有单独实现的功能。SIB之间的交互作用构成了这种方案中的业务逻辑。
在这种方案中，业务配置之间的交互作用是通过根据半呼叫模型的开放信令接口解决的。在以一种经济可行的方法逐步开发的IN平台可以提供完全控制之前，需要使用一些现有的附加业务。应该意识到，这是一个导致需要增强未来IN平台的交互作用问题的捷径。
用户中心观点的主要目标是使SIB标准化，以获得业务无关性、系统无关性和技术无关性。当这些获得以后，基于SIB的业务配置就可以在任何兼容平台上执行，无论它是交换机处理器、独立个人电脑还是工作站。不管如何接入，将相同功能赋予所有用户的旧范例被对于每个单独用户的功能透明度所替代。
IN信令IN系统中的信令使用智能网络应用部分(INAP)协议。INAP信令协议已经被欧洲电信标准协会(ETSI)和国际电信联盟(ITU)标准化，CCITT 7号信令系统(CCS7)是(但不是仅有的)一个用于支持INAP的网络协议。
今天规定的核心INAP(即，IN CS-1标准)的一个缺点是SCF和IP之间的通信能力只限为语音。当前CS-1不支持其它媒体，如电子邮件、传真、数据等。因此，当前CS-1标准不包括与呼叫无关的以及与非实时呼叫有关的业务。
网络化的IP(NIP)实现(本发明就是其中的一部分)可以看作INAP的扩展，从而包括非语音媒体的处理以及在SCF和IP之间提供与呼叫无关的通信。NIP允许SCF处于所有存储-转发(即，消息)业务(例如，语音邮件、电子邮件、SMS消息等)的完全控制之下。NIP实现方案所使用的协议在下面称为NIP-INAP。NIP-INAP是IN CS-1标准的爱立信特有的扩展。
网络化的IP图9表示本发明的一个实施例的网络化IP(NIP)系统。网络化的IP系统包括一个可以和多个智能外设(IP)911-914通信的SCP 901。如前所述，这些逻辑IP中的每一个都是IN术语中的SRF。为了说明的简单性，在图9中只示出了4个IP处理入呼叫和非呼叫消息的IP,IPi911；处理出呼叫和非呼叫消息的IP,IPo913；连接到ISDN系统960的IP,IPgisIS 912；和连接到PLMN系统950的网关IP,IPgm914。
应该强调的是，在这个说明中描述的有专用功能的IP并不符合它们的物理实现，而是与其大不相同。不同的IP 911-914之间通过通信骨干网910使用任何协议(例如，TCP/IP,X.25等)通信。
为了说明的简化，假设用户920-923通过IPi911向IN系统产生输入消息。假设用户930-932是在IN系统中不同的呼叫和与呼叫无关的存储与转发消息收发业务的接收者(或终止点)。每个用户已经选好的业务、功能和呼叫限制以用户特定的业务逻辑程序902的形式存储在SCP 901中。业务脚本可以包括对入和出呼叫的限制、建立虚拟专用网以及为这些VPN对不同的与呼叫相关的状态设定访问限制。
图9还表示了通过网关IP IPgm912和IPgm914分别连接到示范的综合业务数字网(ISDN)系统960和公用陆地移动网(PLMN)系统950的智能网络系统。图9的说明是一个示范，而IN系统还可以通过适当的网关IP连接到其它公用或专用网络，这在图中未示出。虽然所示的用户920-923和930-932在图9中直接连接到IPi911和IPo913，但是应该强调这些用户也可以通过本地交换机和/或交换中心连接到IP911和913。
图9还提供了本发明的实施例的操作的总览。例如，当用户920向输入IPi911发送消息时，IPi911查询SCP 901(如箭头941所示)以检查发送方或接收方是否已经请求、选择或要求了诸如限制控制和号码翻译之类的任何IN业务。作为响应，SCP 901确认查询并且在942将产生的结果返回给IPi911。
在本发明的另一个实施例中，当一个处理出呼叫和消息的IP IPo913接收到发送输出消息的请求时，它如945所示查询SCP 901以检查发送方或接收方是否已经请求、选择或要求了如限制控制和号码翻译之类的任何IN业务。作为响应，SCP 901确认查询并且在946将产生的结果返回给IPo913作进一步处理，可选地这是通过检索并分析相应发起或终止方的业务脚本902来处理的。
一个IN用户可以申请几个与呼叫无关的存储与转发业务，如语音邮件、电子邮件、SMS传真邮件等，并且可以希望将这些各种消息类型的产生、存储、重发和传输协调起来。涉及所申请的不同业务的各种消息在IN网络中通常存储在不同的物理或逻辑IP中。
在得知限制一种或多种消息类型的产生、存储、重发或传输的同时，这些措施至今还是该消息类型所特有的并且尚未推广到其它消息类型或呼叫业务配置或偏爱。目前，还没有有效的方法或技术允许在用户特有的限制和偏爱的基础上存储、重发或用一种分配方式传输在不同节点接收的不同类型的消息。
本发明的一个实施例提供使与呼叫无关的存储与转发消息与那些适用于IN系统呼叫的业务配置相一致的解决方案，以便用户可以选择将他们的部分或全部输入和输出消息与他们的入和出呼叫等同对待。
本发明的一个实施例通过为NIP-INAP引入两个新过程来完成这些要求，这两个新过程是“Incoming Delivery Interrogation”命令，它使接收入消息的IP能够向SCF查询有关适用于消息的接收者发送或接收的呼叫的权利和限制；“Outgoing Delivery Interrogation”命令，它使接收发送出消息请求的IP能够向SCF查询有关适用于消息的作者发送或接收的呼叫的权利和限制。
当前，还没有有效的办法提供在不同物理节点上实现的集成消息收发业务。本发明的一个实施例通过定义一个协议在IN结构的基础上提供这种网络化的解决方案，从而实现统一的与呼叫无关的存储与转发消息传送的解决方案。
NIP-INAP过程的扩展下一步考虑引入NIP-INAP以实现本发明的一个实施例的各种新过程的详细操作。在SCP命令IP使与呼叫无关的存储与转发消息的处理与用于发起方和终止方之间的呼叫的参数一致之前，需要这些过程帮助处理输入和输出消息的IP查询SCP。
“Incoming Delivery Interrogation”消息处理输入消息的IP使用“Incoming Delivery Interrogation”命令来实现SCP查询以测试发起或终止方进行的呼叫的访问限制控制。SCP与输入和输出IP 911和913之间的通信在图10和11中使用传输能力应用部分(TCAP)符号表示，消息类型表示在箭头上方，而TCAP消息的组件和参数表示在每个箭头的下方。
如图10的1001所示，一旦接收到输入消息，输入IP,IPi911就在该消息的任何存储和传输之前向SCP 901发送Incoming DeliveryInterrogation。作为响应，SCP 901查询用户的业务脚本902并且如1002所示将产生的结果返回IPi911。IPi911接收到结果后，进一步的操作由如IP 911决定。
“Outgoing Delivery Interrogation”消息和处理与呼叫无关的输入消息的IP自动产生的“Incoming DeliveryInterrogation”消息相反，“Outgoing Delivery Interrogation”消息是在处理与呼叫无关的输出消息的IP接收到发送输出消息的传输请求时产生的。
图11表示出IP,IPo913请求SCP 901有关发起和/或终止方进行的呼叫的接入限制时的顺序图。如1101所示，一旦接收到发送输出消息的请求，输出IP,IPo913就在该消息的任何存储和传输之前向SCP 901发送Outgoing Delivery Interrogation。作为响应，SCP 901查询用户的业务脚本902并且如1102所示将产生的结果返回IPo913。IPo913接收到结果后，进一步的操作由如IP 913决定。
本发明通过引入新过程允许统一对待消息和呼叫“IncomingDelivery Interrogation”命令使处理输入消息的IP能够查询接收者的与呼叫相关的业务配置和业务逻辑并且用于输入消息处理；“Outgoing Delivery Interrogation”命令使处理输出消息的IP能够查询作者的与呼叫相关的业务配置和业务逻辑并且用于输出消息处理。
在上面讨论的顺序图中，称为输入IP的特定IP IPi911用于处理所有输入消息。同样，称为输出IP的特定IP IPo913用于处理输出消息。但是，应该强调的是这些操作既可以发生在所标识的输入和输出IP，也可以发生在任何支持所需媒介的IP，或任何一个或多个拥有必要处理权力和系统资源的IP。
上述的系统和方法使IN系统可以将呼叫和与呼叫无关的消息用统一的方法对待。这是通过建立新过程查询每个用户中央存储的有关呼叫处理的偏爱和权利来实现的。本发明的一个实施例的附加优越性在于允许用户交互式地规定特定消息的处理或修改以前规定的处理偏爱。
SCP和IP有限状态机图12-15表示SCP 901和各种IP(如处理本发明的一个实施例的与呼叫无关的输入和输出存储和转发消息传送业务的IPi911和IPo913)的有限状态机。在图12-15中，状态机的状态用椭圆符号表示，而导致状态转移的事件用实线的箭头表示。功能在虚线矩形中描述，而功能所要求的动作用虚线箭头指出。
图12表示与呼叫无关的输入消息处理过程中SCP 901的有限状态机。如图所示，SCP具有两个状态空闲状态1201和活动状态1202。SCP901还有一个额外的准状态筛选和转换处理状态1221。
如1211所示，SCP接收到来自IPi911的“Incoming DeliveryInterrogation”命令，从空闲状态1201变到活动状态1202。如1212所示，一旦SCP和调用IP之间的对话正常终止，或对话由于不正常组件的出现而被拒绝，或如果对话被任何一方放弃，SCP就从活动状态1202变到空闲状态1201。应该注意到，在IN系统中，接收方从不超时一个对话。只有调用方(即，发起对话的SCP或IP)可以超时对话。
一旦IPi911执行了“Incoming Delivery Interrogation”命令，从空闲状态1201到活动状态1202的转变还伴随着执行对与呼叫无关的消息的辅助协调业务，如呼叫限制验证或个人(短)号码到标准/全局号码的翻译，如1213所示，并且随后如1214所示返回辅助处理的结果。
图13表示与呼叫无关的输入消息处理过程中IPi端的有限状态机。每个IPi有两个基本状态空闲状态1301和活动状态1302。
如图13所示，一旦如1311所示调用“Incoming DeliveryInterrogation”命令，IPi911就从空闲状态1301变到活动状态1302。从活动状态1302到空闲状态1301的状态反变化，如1312所示，将在与SCP 901之间的对话正常终止、或由于不正常组件的出现而被SCP拒绝、或SCP-IPi对话被任何一方放弃、或操作超时的情况下发生。
图14表示与呼叫无关的输出消息处理过程中SCP的有限状态机。如图所示，SCP具有两个状态空闲状态1401和活动状态1402。还有一个额外的准状态筛选和转换处理状态1421。
如1411所示，当SCP接收了到IPi911的“Outgoing DeliveryInterrogation”命令，从空闲状态1401变到活动状态1402。如1414所示，一旦SCP和IP之间的对话正常终止、或对话由于不正常组件的出现而被拒绝、或如果对话被任何一方放弃，SCP就从活动状态1402变到空闲状态1401。
一旦IPi911调用了“Outgoing Delivery Interrogation”命令，从空闲状态1401到活动状态1402的转变还伴随着执行对与呼叫无关的消息的辅助协调业务，如呼叫限制验证或个人(短)号码到标准/全局号码的翻译，如1413所示，并且随后如1414所示返回辅助处理的结果。
图15表示与呼叫无关的输出消息处理过程中IPi端的有限状态机。每一个IPi具有两个状态空闲状态1501和活动状态1502。
如图15所示，一旦如1511所示调用“Outgoing DeliveryInterrogation”命令，IPi911就从空闲状态1501变到活动状态1502。从活动状态1502到空闲状态1501的状态反变化，如1512所示，在与SCP 901之间的对话正常终止，或由于不正常组件的出现而被SCP拒绝，或SCP-IPi对话被任何一方放弃，或操作超时的情况下发生。
如前所述，在本发明的一个实施例中建立了虚拟专用网(VPN)，如图9中的业务脚本902所示。典型VPN的标准功能是VPN拥有用户组(UG)的能力。这种用户组，根据系统要求，典型地是在逻辑上独立的组，拥有自己的容量、计费和编号方案。在一个VPN中，用户能够使用短分机号码与他们自己的组或公司内部的其他用户联系。换句话说，用户不必拨完整的号码，而是只需拨分机号码，由业务来完成它们之间的翻译。
同样，封闭的用户组(CUG)是带有更多业务限制的用户组，即，CUG的成员只允许呼叫同组的成员或属于开放用户组的成员，并且只能够接收来自同组成员或属于开放用户组的成员的呼叫。
用户有时可以绕过这个CUG限制，例如通过录下一个语音消息并且将它发送到接收者的目的地。为了限制这类“后端(back-end)”方法，发明的一个实施例给出了一种对存储转发业务进行出入查询的方法。这种方法也可以扩展用于呼叫相关的业务。
另外，上面描述的方法提供了对存储转发业务的号码查询和翻译机制，因此用户可以在使用这些存储转发业务时，使用相同的编号方案/扩展号码来寻址其它用户。
虽然已经结合
并用上面的详细叙述描述了本发明方法和装置的优选实施例，但是应该理解本发明并不限于所揭示的实施例，而是可以在不脱离以下权利要求所阐述和定义的本发明的精神的前提下，容纳大量的重新安排、修改、置换。
权利要求
1．在包括多个通过网络连接到SCP(业务控制点)的IP(智能外设)的IN(智能网络)电信系统中，一种使适用于输入的与呼叫无关的存储和转发IN消息的业务配置与适用于IN系统中的输入呼叫的类似业务配置相一致的方法，所述方法包括以下步骤在输入IP接收对已知用户的输入消息；对与呼叫相关的IN业务集进行确定并且分析所述输入消息的发起方或终止方是否已经请求、选择或利用了任何IN业务；响应与呼叫相关的IN业务的确定和分析，构造一组适用于所述输入消息的IN业务(例如限制控制和号码翻译)；将所述构造的与呼叫无关的IN业务集应用于所述输入消息；将应用所述构造的与呼叫无关的IN业务的结果返回所述输入IP；和向所述输入IP委派所述接收消息的下一步处理控制。
2．权利要求1的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的方法，其特征在于所述构造适用于所述输入消息的IN业务的步骤还包括查询SCP的步骤。
3．权利要求1的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的方法，其特征在于所述将所述构造的与呼叫无关的IN业务应用于所述输入消息的步骤还包括检索并分析存储在所述SCP中对应于发起方或终止方的业务脚本的步骤，所述存储的业务脚本包含用户特有的呼叫和消息处理偏爱。
4．权利要求1的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的方法，其特征在于所述确定和分析与呼叫相关的IN业务集的步骤是使用INCOMING DELIVERY INTERROGATION命令执行的。
5．在包括多个通过网络连接到SCP(业务控制点)的IP(智能外设)的IN(智能网络)电信系统中，一种使适用于输出的与呼叫无关的存储和转发IN消息的业务配置与适用于IN系统中的输出呼叫的类似业务配置相一致的方法，所述方法包括以下步骤在输出IP接收来自已知用户的发送输出消息的请求；对与呼叫相关的IN业务集进行确定并且分析所述输出消息的发起方或终止方是否已经请求、选择或利用了任何IN业务；响应与呼叫相关的IN业务的确定和分析，构造一组适用于所述输出消息的IN业务(例如限制控制和号码翻译)；将所述构造的与呼叫无关的IN业务集应用于所述输出消息；将应用所述构造的与呼叫无关的IN业务的结果返回所述输出IP；和向所述输出IP委派所述接收消息的下一步处理控制。
6．权利要求5的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的方法，其特征在于所述构造适用于所述输出消息的IN业务的步骤还包括查询SCP的步骤。
7．权利要求5的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的方法，其特征在于所述将所述构造的与呼叫无关的IN业务应用于所述输出消息的步骤还包括检索并分析存储在所述SCP中对应于发起方或终止方的业务脚本的步骤，所述存储的业务脚本包含用户特有的呼叫和消息处理偏爱。
8．权利要求5的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的方法，其特征在于所述确定和分析与呼叫相关的IN业务集的步骤是使用OUTGOING DELIVERY INTERROGATION命令执行的。
9．在包括多个通过网络连接到SCP(业务控制点)的IP(智能外设)的IN(智能网络)电信系统中，一种使适用于输入的与呼叫无关的存储与转发输入IN消息的业务配置与适用于IN系统中的输入呼叫的类似业务配置相一致的系统，所述系统包括在输入IP接收对已知用户的输入消息的装置；对与呼叫相关的IN业务集进行确定并且分析所述输入消息的发起方或终止方是否已经请求、选择或利用了任何IN业务的装置；响应与呼叫相关的IN业务的确定和分析、构造一组适用于所述输入消息的IN业务(例如限制控制和号码翻译)的装置；将所述构造的与呼叫无关的IN业务集应用于所述输入消息的装置；将应用所述构造的与呼叫无关的IN业务的结果返回所述输入IP的装置；和向所述输入IP委派所述接收消息的下一步处理控制的装置。
10．权利要求9的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的系统，其特征在于所述构造适用于所述输入消息的IN业务的装置还包括查询SCP的装置。
11．权利要求9的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的系统，其特征在于所述将所述构造的与呼叫无关的IN业务应用于所述输入消息的装置还包括检索并分析存储在所述SCP中对应于发起方或终止方的业务脚本的装置，所述存储的业务脚本包含用户特有的呼叫和消息处理偏爱。
12．权利要求9的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的系统，其特征在于所述确定和分析与呼叫相关的IN业务集的装置还包括INCOMING DELIVERY INTERROGATION命令。
13．在包括多个通过网络连接到SCP(业务控制点)的IP(智能外设)的IN(智能网络)电信系统中，一种使适用于与呼叫无关的存储转发输出IN消息的业务配置与适用于IN系统中的输出呼叫的类似业务配置相一致的系统，所述系统包括在输出IP接收来自已知用户的发送输出消息的请求的装置；对与呼叫相关的IN业务集进行确定并且分析所述输出消息的发起方或终止方是否已经请求、选择或利用了任何IN业务的装置；响应与呼叫相关的IN业务的确定和分析、构造一组适用于所述输出消息的IN业务(例如限制控制和号码翻译)的装置；将所述构造的与呼叫无关的IN业务集应用于所述输出消息的装置；将应用所述构造的与呼叫无关的IN业务的结果返回所述输出IP的装置；和向所述输出IP委派所述接收消息的下一步处理控制的装置。
14．权利要求13的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的系统，其特征在于所述构造适用于所述输出消息的IN业务的装置还包括查询SCP的装置。
15．权利要求13的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的系统，其特征在于所述将所述构造的与呼叫无关的IN业务应用于所述输出消息的装置还包括检索并分析存储在所述SCP中对应于发起方或终止方的业务脚本的装置，所述存储的业务脚本包含用户特有的呼叫和消息处理偏爱。
16．权利要求13的使与呼叫无关的IN业务和与呼叫相关的IN业务相一致的系统，其特征在于所述确定和分析与呼叫相关的IN业务集的装置还包括OUTGOING DELIVERY INTERROGATION命令。
17．在通过IN(智能网络)电信系统在发起方和终止方之间提供与呼叫相关的业务的方法中，分别依据适用于发起方和终止方中至少一方的业务配置来提供与呼叫相关的业务，该IN电信系统还允许与呼叫无关的存储和转发业务，一种用与适用于发起方和终止方中至少一方的业务配置相一致的方式在发起和终止方之间传递与呼叫无关的存储和转发IN消息的改进方法，所述方法包括以下步骤在IN电信系统的IP(智能外设)检测由发起方产生的、与呼叫无关的存储和转发IN消息的接收；确定适用于发起方和终止方中至少一方的业务配置；构造一个适用于在发起和终止方之间传递的与呼叫无关的存储和转发IN消息的IN业务集，该业务集对应于适用于发起方和终止方中至少一方的业务配置；将在所述业务集构造期间构造的IN业务集应用于与呼叫无关的存储和转发IN消息；和如果所依照的IN业务集允许，将与呼叫无关的存储和转发IN消息按照IN业务集转发到终止方。
18．在通过IN(智能网络)电信系统在发起方和终止方之间提供与呼叫相关的业务的系统中，分别依据适用于发起方和终止方中至少一方的业务配置来提供与呼叫相关的业务，该IN电信系统还允许与呼叫无关的存储和转发业务，一种用与适用于发起方和终止方中至少一方的业务配置相一致的方式在发起方和终止方之间传递与呼叫无关的存储和转发IN消息的改进装置，所述装置包括以下步骤被连接成可接收来自发起方的、与呼叫无关的存储和转发IN消息的IP(智能外设)；被连接到所述IP并且至少为了响应所述IP接收的与呼叫无关的存储和转发IN消息而运转的SCP(业务控制点)，所述SCP具有适用于发起方和终止方中至少一方的业务配置的业务脚本，所述SCP用于构造适用于在发起方和终止方之间传递的与呼叫无关的存储和转发IN消息的IN业务集，该业务集相应于适用于发起方和终止方中至少一方的业务配置；并且其中所述IP应用由所述SCP构造的IN业务，并且在允许的情况下将与呼叫无关的存储和转发IN消息按照IN业务集转发到终止方。
全文摘要
在包括几个通过网络连接到业务控制点(SCP)(901)的智能外设(IP)(911－914)的智能网络(IN)电信系统中使用于与呼叫无关的存储转发消息和那些适用于呼叫的业务配置相一致的系统和方法。当处理出呼叫和消息的IP(913)接收到一个出呼叫或处理入呼叫的IP(911)被用户(920－923和930—932)查询时,IP(913,911)查询SCP(901)以确定发送方或接收方是否已经请求、选择或利用了限制控制和号码翻译之类的IN业务。SCP(901)确认(946,942)查询(945,941)并且将产生的结果返回IP(913,911)以便进一步处理,可选地,这种处理可以是通过检索并分析相应发起(930－932)或终止(920－923)方的业务脚本(902)来实现的。
文档编号H04M3/42GK1235736SQ9719925
公开日1999年11月17日 申请日期1997年8月21日 优先权日1996年8月30日
发明者B·A·V·阿斯特伦, B·A·斯文内松, G·苏马, R·J·B·施默瑟尔 申请人:艾利森电话股份有限公司