CN1104142C - 访问用于电信系统中的业务资源项的方法 - Google Patents

Abstract

用于电话系统中呼叫建立的业务资源项(49)存储在连接于计算机网络的服务器(58)上，计算机网络与电话系统基础设施在逻辑上分开；例如，这个计算机网络可以使用国际互连网。每个业务资源项(49)可定位在网络上相应的URI处并且关联于特定的电话号码。在电话号码和有关业务资源项的URI之间提供一个映射。当需要访问关联于特定电话号码的业务资源项(49)时，将这个映射用于获取相应的URI(步骤55)，然后，将URI用于访问所需的业务资源项(56、57、59)。

Description

访问用于电信系统中的业务资源项的方法

                          技术领域

本发明涉及访问业务资源项的方法，这些业务资源项是用于建立经过交换电信系统的承载信道。

这里所使用的术语“交换电信系统”是指包括带有交换机的承载网络以便通过网络建立一条承载信道的系统。术语“交换电信系统”用于不仅包括现有的公用和专用电话系统(使用模拟电话或基于ISDN的电话)，也包括宽带(ATM)及其它基于交换机的承载网络，它们可能是目前已实现的或是将来会出现的。为了方便起见，术语“交换电信系统”有时在这里简称为电信系统。

在交换电信系统的环境中提到“呼叫”应理解为通过承载网络上建立的一条承载信道而进行的通信，同时提到呼叫建立、维持和拆除是指建立、保持和拆除一条通过承载网络的承载信道的过程。诸如“呼叫处理”和“呼叫操作”这样的术语做类似的解释。

术语“通信系统”当在这里使用时应该理解为比交换电信系统具有更广泛的含义，而且意图包括基于数据报(datagram)的通信系统，在这种系统中每个数据分组通过承载网络独立地进行路由选择不需要遵循预定的承载信道。

                          背景技术

运行PSTN(公用交换电话网)和PLMN(公用陆地移动网)的电信公司从事提供 电信业务的经营，并以诸如800号业务和呼叫转发这样的“IN业务”形式提供增值的内建智能。相反，当前爆炸性发展的WorldWide Web(WWW)，即万维网是提供复杂 信息业务的基于国际互连网的全球网的一个例子。这两个世界，一个具有很大的通信能力而另一个具有高动态、领先精神的WWW信息文化，是不稳定的集团，彼此都计划侵蚀对方已经占据的领域；因此将通过WWW提供电话业务并通过公用通信设施提供信息业务。

本发明建议使这两个世界关系更和谐的技术，而不是目前所面临的状态，以便将本发明置于其中，首先对这两个世界中的每一个做概述。

带有IN业务的电话网络

基本PSTN。PSTN(公用交换电话网)所提供的基本业务是根据主叫方话机输入的被叫方电话号码将两个话机互连(即，在话机间建立一条承载信道)。图1是提供这种业务的PSTN的简单表示。特别是，客户所有设备CPE10(例如标准的模拟话机、以及目前越来越多的ISDN终端)通过接入网络11连接到交换节点SP 12。SP 12构成交换网络13中的节点，交换网13由互连中继线14和SP中的控制实体15所控制的SP组成。控制实体15所实现的控制由从CPE和其它SP所接收的信令输入来确定，并包括呼叫建立、保持和拆除以便提供主叫CPE和被叫CPE之间所需要的承载信道。在概念上，PSTN可以认为是承载网络和控制(信令)网络，后者的功能实现通过承载网络的呼叫控制，即建立、保持和拆除承载网络上承载信道的控制；实际上，承载和信令网络可以使用相同的物理线路，甚至是相同的逻辑信道。

因此，当CPE是传统的傻电话时，CPE及其本地SP之间的控制信令是带内信令，即，用于话音的同样信道上传输的信令；这种信令在SP 12翻译并转换成使用专用共路信令网16的SP之间的信令(现在使用SS7协议组实现)。当CPE是ISDN终端时，信令在直接来自CPE的单独信道上作端到端的传输。现代的SP使用ISUP(ISDN用户部分)SS7协议做交换呼叫控制信令，无论CPE是标准电话还是ISDN终端。

电话编号方案-因为本发明的某些方面受电话号码结构的影响，现在将给出这种号码结构的简要描述。电话号码构成基于十进制数字组的国际的、层次的寻址方案。该层次的顶层由ITU-T管理，为主要的地理地带分配单个十进制数码(例如“1”为北美，“2”为非洲、“3”为欧洲，“4”为欧洲、“5”为南美洲和古巴，等等)。在每个地带中，国家分配2或3个数字码，这样在地带3中法国为“33”，在地带4中UK为“44”。一个国家内编号方案的管理委托给国家团体，例如UK的电信局(“Oftel”)。下面的其它描述基于UK编号方案，但是所描述的方案应该认为是具有广泛的应用性。

在UK中，所有国内号码都前缀以从01-09的码(国际拨号时去掉“0”前缀)。目前分配的号码是“01”用于地理区域码，“02”用于附加地理区域码，“04”用于移动业务，“07”用于个人号码，“08”用于特殊业务(免费电话、信息)。一般的有线PSTN用户电话号码从地理区域码开始分配，目前只有前缀为“01”的码被分配。地理区域码目前为3或4个数字(除了前面的“0”)，目前有638个地理区域有自己的码。完整的国内UK拨号码有两种形式：

0    171    634 8700

地区码     本地码(7个数字)

0    1447  456 987

地区码  本地码(6个数字)

第一种情况有“0”前缀、3位地区码和7位本地号码，第二种情况有“0”前缀、4位地区码和6位本地号码。本地号码的进一步解释在地区交换机内进行，因为甚至6位地址空间对于单个交换机来说都太大了，而且对于典型的本地区域，可能需要几个交换机控制用户线所需的号码。这种解释是不透明的而且与地区业务提供者有关。

在当前PSTN中，电话号码固有的层次和地理解释是网络物理结构的映射。电话号码按照很容易将呼叫沿着网络路由选择的方式的构成。在每一步骤中，号码的前缀都提供了有关当前路由选择步骤的信息，而且后缀(可能是不透明地)提供了随后路由选择步骤的信息；只要交换机知道如何分析前缀并实现路由选择步骤，它就不需要理解后缀的内容，后缀留给随后的路由选择步骤。为此，国际和国内交换结构也是按层次组织的。

智能网络。现在回过来考虑当前电话网络基础设施，除了基本呼叫处理，SP也可以用于提供所谓IN(智能网络)业务；在这种情况下，SP称为业务交换点SSP。SSP 25被设计为根据所满足的特定判据来暂缓所规定的呼叫点上的呼叫处理，并将继续呼叫处理的任务委托给提供业务控制功能(SCF)的业务控制子系统(这种提供，或以业务控制点SCP 17(见图2)的形式、或以附件18的形式来实现)。附件18直接关联于SSP25，而SCP 17和SSP 25通过可能包括信令传输点(STP)19的扩展共路信令(CCS)网16彼此通信。SCP 17可以关联于多个SSP 25。SCP 17和附件18提供业务逻辑执行环境(SLEE)20，在其中可以执行一个或多个逻辑程序(SLP)21的实例。SLEE 20和SLP 21共同为给SSP 25提供业务而提供业务控制功能。

运行在SCP或附件中的业务逻辑一般使用存储在业务数据功能(SDF)22中的用户信息，SDF可以与SCP/附件集成在一起，或者部分或整个地分开。业务数据功能(SDF)，类似业务控制功能(SCF)构成PSTN业务控制子系统的一部分。应该注意到一些或全部业务控制功能可以植入PSTN交换机本身中。

除了SCP 17和附件18，图2网络包括了智能外设(IP)23。IP 23为SSP 25提供资源，例如话音通告和DTMF数字采集能力。网络也将包括一个操作系统(未表示)，它总体监督网络及其业务并执行诸如网络监控这样的功能。

在操作中，当SSP 25接收到呼叫时，它检查内部触发器状态以及可能的用户信息(例如拨出的号码)，以便确定该呼叫是否需要由业务控制子系统17、18来提供一种业务；触发器状态的检查可以在呼叫处理的各个不同点上实现。在SSP 25确定需要一种业务的地方，它发送消息通知业务控制子系统(SCP 17或附件18)，请求所需要的业务和根据连接情况和呼叫处理状态将该呼叫的逻辑表示发送给业务控制子系统(或者SCP 17或附件18)。然后业务控制子系统提供所请求的业务，这可能包括SSP和业务控制子系统之间的一次单一相互作用、或者一次相互作用的会话。典型的业务是呼叫转发，这是一种被叫方业务，它对端用户设备简单表示为“如果你以号码X呼叫我并振铃10次，那么尝试呼叫号码Y”。在这种情况下，被叫端用户的本地的SSP触发了有关的SCP(或附件)从而来提供这种业务；当然，将会理解的是，SSP必须预先知道为被叫号码X提供该业务。

上述在PSTN中提供IN业务的模型也可以映射到PLMNs(公用陆地移动网)中，例如GSM和其它移动网。移动用户情况下的控制信令比较复杂，因为除了所有通常的信令要求外，也需要确定应该向哪里对移动用户的呼叫路由选择；但是，作为在PSTN中的大量的被叫方IN业务，所以这并不是很不同的问题。因此，在GSM中，业务数据功能(SDF)大多处于被称为归属位置寄存器(HLR)的系统中，业务控制功能处于被称为访问位置寄存器(VLR)的系统中，VLR一般与每个SSP(在GSM术语中称为移动交换中心，MSC)具有一对一的关系。

因为用户是移动的，因此，用户档案要从HLR传递到恰好功能上最接近移动用户的那个VLR，并从那里VLR使用用户档案来操作该(固定的)业务并与SSP交互作用。HLR和VLR因此组成了类似于带有它们的有关数据库的SCP或附件的业务控制子系统。

当然，也可能在专用电话系统中提供IN业务，而且在这种情况下，业务控制功能和业务数据功能一般或者集成到PABX(专用自动小交换机)中，或者由本地计算机提供。同时提供的业务控制子系统因此也可以不必在物理上与PABX分离。

上述提供IN业务的一般结构框架有其优点和缺点。它的主要长处是可行而且已经成功实现了很多业务，例如800号业务、信用卡呼叫、语音邮件、以及各种呼叫等待和重定向业务。但是，尽管经过了很多年的标准化，这些业务还是每次都在专用的平台上实现，不能很好地统一。该方法基于很大的、容错的、为几十万甚至上百万用户服务的系统，需要很多年来实现。此外，由于用于支持这些业务的网络也构成了基本的电话基础设施，任何附加到这些网络上的东西必须严格地加以检查。此外，每个国家和运营者常对所谓标准进行本地化的改变，使提供标准化产品变得相当困难而且阻挡了竞争的机制。

目前，有很多增加公共IN系统灵活性的建议。以下文件描述了很多这样的建议：

“Method and system for controlling the operation of atelephone exchange from a subscriber connection(控制来自用户连接的电话交换的操作的方法和系统)”WO/9423523 Nokia 13.10.94

这个文件描述了如何通过用户连接给SCP提供命令宏(commandmacros)。

“Mediation of Open Advanced Intelligent Network Interfacefor Public switched Telephone Network(用于公共交换电话网的开放式先进智能网接口的协调)”US 5,438,568 Bellsouth Corporation1.8.95

一个协调SCP监视到达及来自运行在例如第三方SCP上的、第三方业务逻辑程序的所有消息。

“Customers in Driver’s Seat：Private Intelligent NetworkControl Point(驾驶员座位上的用户：专用智能网控制点)”

M.Sevcik；R.Lueder(Siemens)23.4.95 ISS Symposium

这个文件描述了通过TCP/IP连接而连接到网络SCP(NSCP)的专用SCP(PSCP)。NSCP将所翻译的INAP消息直接转发PSCP。所示PSCP作为资源在专用TCP/IP LAN上连接，以便访问数据库信息。

“Distributed intelligence and data in public and privatenetworks(公共和专用网中的分布智能和数据)”

R.P.SWale & D.R.Chesterton BT TechnologyJournal，13(1995)April No.2

这个文件讨论了第一和第三方CTI，后者称为“专用IN”。然后在专用和公用IN之间进行比较，注意到它们常常是补充的。最后，讨论了将专用和公用IN互连的可能性，包括通过公用网络SCP访问专用数据库。

World Wide Web

与电话基础设施缓慢审慎的前进相反，WWW从1989开始爆炸性发展起来，在信息内容的广度、可用性和丰富性上成为主要的电子信息传播业务。任何人都可以用不高的费用，在高度互连的信息结构中成为全球范围听众的信息提供者。

WWW是运行在国际互连网上的客户机-服务器应用，使用客户机-服务器协议，在客户机和服务器之间只要求最简单的交换。这个协议是HTTP(超文本传输协议)，该协议对于诸如国际互连网这样的TCP/IP网络上的使用是最佳的；但是HTTP协议也可以用于使用不同通信协议栈的网络。

由于有关WWW的文献提供已经和WWW本身一样发展很快，因此WWW、HTTP和国际互连网的详细描述这里就不给出了。但是将给出一个简单的注重与本发明有关的某些特性的描述。

WWW使用国际互连网提供互连。国际互连网是将世界范围的网络连接在一起的系统。国际互连网基于TCP/IP协议族并提供对也使用TCP/IP的网络的连接。一个实体要在国际互连网上出现，需要接入连接到国际互连网的网络并有一个IP地址。IP地址是层次结构的。一般一个实体在用户级上通过一个名字来标识，该名字可以通过国际互连网的域名系统(DNS)解释成相应的IP地址。因为DNS或它的变形对于这里所描述发明的至少一些实施例是很基本的，因此下面将给出DNS的一般形式及其操作。

域名系统-DNS是全球性的、分布式的数据库，如果没有它的性能、灵活性和标准性，国际互连网的大部分将不是现在这个样子。DNS响应客户请求，用于将国际互连网主机域名与一个或多个不同类型的注册记录(RR)相关联，最常见的是地址(A)记录(例如15.144.8.69)和邮件交换器(MX)记录(用于标识配置为接收一个域的电子邮件的域主机)。RR在世界范围的DNS名字服务器上分布，这些服务器联合运行以用于提供域名翻译服务；没有一个DNS服务器包括比全球数据库的一小部分更多的东西，但是每个服务器知道如何定位与数据“最接近”的DNS服务器。为此，有关的DNS主要特性是：

——主机名字空间按照节点的树状层次组织，每个主机有一个相应的叶节点；每个节点有一个标号(除了根节点)而且每个标号以一个字母开始，后面跟着一串字母或数字。完整的、或“完整合法的”主机名是一串节点标号，每个以“.”分隔，从相应的叶节点一直到层次的根节点，后者在名字最后用“.”来表示。因此英国Bristol的Hewlett-Packard实验室的主机“Fred”的完整合法域名是“fred.hpl.hp.com.”(注意如果主机名不以“.”结束，被解释为相对于名字层次的当前节点)。

——每个主机有一个或多个有关的注册记录(RR)。

——有多个DNS服务器，每个负责名字空间的一个子树。DNS服务器将保存其子树的所有或部分的RR——在后一种情况，它将子树其余部分的责任委托给一个或多个其它的DNS服务器。DNS服务器知道它委托以责任的任何服务器的地址，而且也知道将它所管理的子树的责任交给它的服务器的地址。因此DNS服务器在反射名字层次的结构中彼此指向。

——希望利用DNS的应用通过一个至少知道一个DNS服务器地址的有关“解析器”来实现其目的。当这个解析器询问DNS服务器有关特定主机的RR时，DNS服务器将返回所请求的RR或最接近于存储有根据所有名字层次的RR的服务器的DNS服务器的地址。实际上，服务器的层次是递升的，直到到达也负责解析该域名的服务器；此后，DNS服务器的层次递减到存储所解析域名的RR的服务器。

——DNS使用预定的消息格式(实际上，对于查询和响应是相同的)并使用IP协议。

DNS的这些特性可以认为是定义一个总是考虑最小变化的“DNS类型”的系统，例如在标号语法中，标号是如何合成的(排序、分隔器)、消息格式细节、IP协议的演变等。

由于层次命名结构，可以递归地委派管理名字空间域(子树)的责任。因此，顶层域由InterNic(这些顶层域包括熟悉的’com’、’edu’、’org’、’int’、’net’、’mil’域以及由标准双字母码规定的顶层国家域，例如’us’、’uk’、’fr’等)管理。下一层，例如，Hewlett-Packard公司负责以“hp.com”结尾的所有名字，BritishUniversity一起负责以“ac.uk”结尾的所有名字。再递减，再举例而言，“hpl.hp.com”域的管理是Hewlett-Packard实验室的责任，而且“newcastle.ac.uk”子树(域)的管理是University of Newcastle-upon-Tyne的责任。

图3表示从Hewlett-Packard实验室内部进行的示范查询的过程。被解析的主机域名为“xy.newcastle.ac.uk”，是University ofNewcastle，United Kingdom的一个假想机器。查询递交给负责“hpl.hp.com”子树的DNS服务器。这个服务器没有存储所请求的RR并因此以“hp.com”DNS服务器的地址响应；然后查询这个服务器并以“com”DNS服务器的地址响应，后者再以“.”(根)DNS服务器的地址响应。然后查询重复地沿“uk”分支向下进行直到“newcastle.ac.uk”服务器用其子树中的名字“xy”的RR记录来响应。

这看起来极其低效，但是DNS服务器的设计是用于建立动态的超高速缓存，而且以几个根服务器的地址来初始化，所以实际上大多数重复查询都是不会发生的。在这种情况下，“hpl.hp.com”DNS服务器将知道几个根服务器的地址，而且很可能在它的超高速缓存中有“uk”和“ac.uk”服务器的地址。对“hpl.hp.com”服务器的第一次查询将返回“ac.uk”服务器的地址。对“ac.uk”服务器的第二次查询将返回“newcastle.ac.uk”服务器的地址，第三次查询将返回所要的RR。将来任何以“newcastle.ac.uk”为前缀的查询将直接到达newcastle DNS服务器，因为该地址已经保留在“hpl.hp.com”DNS服务器的超高速缓存中。。实际上，本地子树内的名字在一次查询中解析，本地子树外的名字在两次或三次查询中解析。

与其由解析器负责实现解析域名所需的一系列重复查询，不如由解析器将它的第一次查询定义为递归的，在这种情况下接收DNS服务器负责解析该查询(如果它不能直接返回所请求的RR，它本身将发出递归的查询给“最接近的”DNS服务器，依次类推)。

同样应该注意的是实际上每个DNS服务器将是备份的，即，按照主服务器和一个或多个副服务器来组织。主DNS名字服务器从本地文件系统中维护的数据库对其本身初始化，而副服务器通过从主传递信息对其本身初始化。一个子树一般有一个主名字服务器和多达10个副服务器——该限制接近副服务器从主服务器更新它们的数据库所需的时间。主数据库是子树信息的主源并由域DNS管理员来维护。副服务器不是简单的备用副服务器，而是每个副服务器主动地参与到具有指向它而不是相应的主服务器的独立服务器的DNS中。

具体实现的DNS(例如BIND)广泛作为多数UNIX系统的标准部分而提供，而且可以说是现有最强壮、最广泛使用的分布式应用。

WWW的操作现在参考附图4，接入国际互连网30可以通过直接连接到其本身直接或非直接与国际互连网相连的网络实现；这样一种设计由图4中的终端31来代表(例如这个终端可以是Unix工作站或一台PC)。具有这种到国际互连网的连接称之为具有“网络接入”。任何具有到国际互连网的网络接入的实体可以作为国际互连网的一个服务器，只要它具有足够的有关功能；在图4中，带有文件存储37的实体32作为一个服务器。

很多WWW用户不具有到国际互连网的网络接入，而是通过具有网络接入的国际互联网服务提供者ISP 33接入国际互连网。在这种情况下，用户终端34一般通过公用电话系统、使用调制解调器并运行SLIP(串行线路接口协议)或PPP(点对点协议)来与ISP 33通信。这些协议允许国际互连网分组跨过普通的电话线传送。这种形式接入国际互连网称之为“拨号IP”接入。用这种接入方法，用户终端34在每次用户会话中临时分配一个IP地址；但是，由于这个IP地址可能在会话之间变化，所以对于作为服务器的实体34是不可行的。

WWW的基础是通过统一资源标识符(URI)寻址特定信息资源的能力，URI一般是一个通过位置来标识资源的统一资源定位器(URL)、或者一个可以解析到URL的统一资源名(URN)。举例而言，完整的或“绝对”的URL将包括如下成分：

方案——用于接入所要资源的接入方案；

主机——国际互连网主机域名或IP地址；

端口——用于(TCP)连接的主机端口；

绝对路径——主机上资源的绝对路径。

实际上，“端口”可以在假设为端口80的情况下被忽略。

附图5标识了Hewlett-Packard产品欢迎页的示范URL。在这种情况下，成分是：

方案——http

主机——www.hp.com

端口——省略(假设为端口80)

绝对路径——Products.html

HTTP协议基于请求/响应原语。再参考附图4，假设要访问一个特定的标识为资源30的URI，客户机建立与对应于URI的“主机”成分的服务器31的连接并向该服务器发送一条请求。这个请求包括请求方法、以及“Request-URI”(它一般只是服务器上资源的绝对路径，通过URI的“绝对路径”成分来标识)；该请求可以包括附加的数据成分。然后服务器31访问资源36(这里存储在存储器37中)并响应，这个响应可以包括也包括在该响应中的MIME(Multipurpose Internet MailExtensions即，多用途国际互联网邮件扩展)类型所标识类型的实体。

两个主要请求方法是：

GET——这个方法产生由Request-URI所标识的任何信息(以实体形式)的获取。重要的是注意如果Request-URI指向数据产生过程，它就是在响应中作为实体返回的所产生的数据而不是过程的源文本。

POST——这个方法用于请求：目标服务器作为Request-URI所标识资源的新下属而接受包括在请求中的实体。POST方法可用于现有资源的注释，向布告栏提供消息，向数据处理过程提供数据(例如，由于提交一份表格而产生的数据)，并通过附加操作扩展数据库。

总的来说，GET方法可以用于直接获取数据，或触发任何将返回一个实体(可能或者是数据或者简单地是一个运行过程的结果指示)的过程。POST方法用于注册数据，并规定这个方法也对触发服务器中的一个过程以便恰当地处理所传递的数据是有效的。

使用GET或POST方法，将信息传递到所触发的在服务器上运行的过程目前是根据称为Common Gateway Interface(CGI，公共网关接口)的接口来完成的。接收过程常常写入脚本语言(scripting language)，尽管这不是本质的。一般，所触发的服务器脚本(script)用于与数据库接口，以对包括在GET请求中的查询进行服务。已经提到的另一种用法，是向数据库添加与POST请求有关的数据。

WWW成功的其它重要因素是使用HyperText Markup Language(HTML，超文本标志语言)来表示通过WWW传递的文件组合，以及提供强大的图形Web浏览器，例如Netscape和Mosaic，用于在客户终端解释这种文件，以便将其提供给用户。基本上，HTML用于标识文件的每一部分，例如题目、或一个图形，而且由客户终端上运行的浏览器决定如何显示每个文件部分。但是，HTML不止是这些——它也使URI和请求方法与文件的任何成分(例如一个特定的单词或一个图象)能够相关联，这样当用户指向该成分并在其上点击，通过URI标识的资源就可以根据方案(协议)以及所规定的请求方法来访问。这种设计提供了从一个文件到另一个的超链接。使用这种超链接，客户终端的用户可以不费力地从世界一端的服务器上下载的文件跳到处于世界另一端的服务器上的另一个文件。由于一个作者产生的文件可能包括到另一个作者所产生文件的超链接，可以在没有中央集中控制的情况下产生极其强大的文本交叉检索系统。

超链接不是置入HTML文本的唯一智能。另一个强大的特性是在屏幕上能够添入所下载“表格”文件，然后激活“提交(commit)”图形按钮以便将输入的信息传递到设计为收集这种信息的资源(例如一个数据库)。这可通过使POST请求方法与“提交”按钮以及数据库资源的URI相结合来实现；激活“提交”按钮导致所输入信息被传递到所标识的资源，在那里它将被恰当地处理。

另一个强大的可能是程序代码(一般是要被翻译的正本)与特定文件成分的关联，例如图形按钮，这个代码在按钮被激活时执行。这会开发用户从一个资源下载程序代码然后运行该代码的可能性。

本领域技术人员将会理解的是HTML只是实现上面概述功能的目前可用的脚本语言的一种，可以期望任何严谨的Web浏览器都将内置地支持多脚本语言。例如，Netscape2.0支持HTML 3.0、Java和LiveScript(后者是Netscape专用的脚本语言)。

图形Web浏览器本身作用的重要性不应被忽视。除了能够支持多脚本语言，Web浏览器在其它特性中应该提供对标准媒体类型的内置支持，以及在客户机中装载和执行程序的能力。这些浏览器可以看作是WWW交互的操作系统。

WWW和电话网

通过数字化语音输入并将其通过国际互连网以离散分组形式发送以便在接收终端重新组装，从而可以通过国际互连网在所连接的终端之间提供电话业务。这是国际互连网上通信业务的一个例子。可逆地，可以指向电话系统上提供的各种信息业务，例如在法国广泛使用的Minitel系统。但是，这些对彼此传统领地的侵犯并不造成对国际互连网或公共电话系统的真正威胁。

更感兴趣的是国际互连网和电话系统的协作使用领域。实际上，这样一个领域已经存在了相当一段时间而且上面参考图4已经做了概述，即从用户计算机34通过使用PSTN上的调制解调器链路到国际互连网业务提供者33，以便获得对国际互连网的拨号IP接入。这种协作使用具有非常简单的性质，即通过PSTN建立一条承载信道用于随后产生的国际互连网业务；国际互连网和PSTN之间没有真正的交互作用。

另一个已知的国际互连网和PSTN协作使用的例子是一种最近刚开始的业务，通过它，带有声卡的国际互连网用户在他/她的终端计算机上可以对世界上任何地方的标准电话进行话音通话。这要通过将数字化语音通过国际互连网传递到接近目标话机的业务提供者来实现；这种业务提供者可以连接到本地PSTN以便接入所要的电话并将国际互连网上接收的话音业务流传递到本地PSTN。来自被叫话机的语音输入用相反方式处理。这种业务的关键是要能够识别目标话机本地(考虑电话计费)的业务提供者。这种设计，虽然提供了对长途电话电信经营者的竞争前景，也是使国际互连网和PSTN简单串联在一起。但是，可能会注意到在这种情况下，在通过目标话机本地的PSTN向目标话机呼叫过程中，必须提供起码最少的反馈给国际互连网呼叫方；这种反馈只在关于呼叫是否成功方面是必要的。

从前述可见，目前国际互连网和电话系统的协作使用处于非常简单的水平。

本发明的目的是提供一种在电信网络上访问业务资源项以便利于集成PSTN和WWW的方法。

                           发明内容

根据本发明，提供了一种访问业务资源项的方法，用于建立经过交换电信系统的承载信道方面，该方法包括如下步骤：

(a)——提供带多个业务资源项的连接到计算机网络的至少一个服务器，随后使用相应的已知URI可以在所述计算机网络上对其定位，所述计算机网络在逻辑上与电信系统分开，而且所述业务资源项涉及为通过所述电信系统的承载信道建立控制，每个业务资源项关联于各自的预定码，所述预定码与所述URI不同，并且用来标识所述承载信道的端点实体；

(b)——在每个所述预定码和关联于该预定码的业务资源项的所述已知URI之间提供一个映射；以及

(c)——利用所述预定码访问相应的所述业务资源项，通过使用所述映射确定对应于该资源项的URI，然后使用这个URI访问所述计算机网络上的业务资源项。

本发明提供的超越现有技术的优点在于：使得诸如电话系统的交换电信系统能够通过使用业务资源项来控制，该业务资源项被存储在诸如公共互联网的分离的计算机网络上；这允许在提供和使用业务资源项中的高度灵活性，导致更容易适应于最终用户需要的新业务。

在一个实施例中，至少一些URI是通过根据所述映射规定的功能操作，从它们对应的所述预定码得到的。在另一个实施例中，至少一些URI是从它们相应的所述预定码中得到，通过根据所述映射而将并联着所述预定码和URI的关联表中查找。这个关联表可以优选地存储于连接到计算机网络的至少一个数据库服务器上，步骤(c)包括通过计算机网络访问数据库服务器以便确定对应于所述预定码的URI。优选地，所述至少一个数据库服务器由DNS类型的分布式数据库系统提供，其中URI以关联于在此称为域名的各自名字的记录形式存储，通过域名可以获取记录。在这种情况下，步骤(c)包括将所述预定码翻译成相应域名并使用这个域名从DNS类型分布式数据库系统中获取所需业务资源项的URI。

一个以上的业务资源项可以在相同的URI上定位；在这种情况下，这些业务资源项的预定码将包括各自的相对资源标识符值，这些值用于在存储业务资源项的服务器上在相同URI的业务资源项中识别所需的业务资源项。

电信系统可以是电话系统，每个所述预定码是呼叫方电话号码或者是被叫方电话号码(这些号码可以是特定话机的号码，或个人号码)。在一个优选实施例中，至少一些所述预定码是被叫方电话号码，相应的业务资源项是被叫方的当前电话号码。

在业务资源的性质方面，一般有如下类型：

——要由相应的服务器在被访问时去执行的业务逻辑，该执行结果返回到访问实体；

——可下载业务数据，当被访问时要将其下载到访问实体；

——可下载业务逻辑，当被访问时要将其下载到访问实体，以供其执行。

优选地，在前面提到URI的场合，这些URI是URL及/或URN。此外，所提到的服务器优选地是HTTP服务器。

可以理解的是，前面提到的在逻辑上与电信系统分开的计算机网络并不是意指二者物理上分离——实际上，二者常常是结合使用同一物理基础设施。此外，在电信系统中建立的承载信道不仅可以和计算机网络共享相同的传输介质，而且承载信道可以作为计算机网络上业务流的管道。要求计算机网络在逻辑上与电信系统分开的目的，是排除那些专用于承载网络管理或监视并有效地构成电信系统本身一部分的计算机。

优选地，计算机网络是电信系统的用户一般可接入的，因为这将给用户提供后面将会明显看到的很多好处。措辞“一般可接入”不应该理解为电信系统的所有用户具有对该计算机网络的这种接入或者可以得到这种接入，而是应该理解的含义是，这些用户的主要部分具有或可以得到该计算机网络的接入。

例如，在发明的一个优选实施例中，电信系统的用户一般可接入的、逻辑上与之分开的计算机网络是国际互连网，电信系统是公用电话系统。在另一个实施例中，电信系统是包括PABX的专用系统，计算机网络是LAN。

                         附图说明

现在将通过非限制性的例子，参考所附的示意性图描述本发明的实施例，其中：

图1是标准PSTN的简化图；

图2是带IN业务能力的已知PSTN的简化图；

图3是说明国际互连网的DNS所进行的主机域名解析的图；

图4是说明World Wide Web功能的图；

图5是说明标准URL格式的图；

图6是发明第一实施例的图，其中存储在HTTP服务器上的业务资源项是PSTN的业务控制子系统和Web用户都可访问的；

图7是说明图6的SCP所进行的业务请求处理的图；

图8是说明图6的SCP访问业务资源项时所使用的资源码格式的图；

图9是说明在业务码不包括RRI部分的情况下访问业务资源的过程图；

图10是说明在业务码包括RRI部分的情况下访问业务资源的过程图；

图11是说明根据本发明通过解析输入电话号码得到业务资源URI的图；

图12A是描述域名所组成的名字空间(“电话名字空间”)的图，通过解析电话号码的预定集合来得到该域名；

图12B是描述不将DNS分隔的电话名字空间组合的图；

图12C是将DNS分隔的电话名字空间组合的图；

图13是说明图6实施例在响应标准话机所拨的电话号码从而提供漫游号码业务的整体操作图；

图14是说明当Web用户利用图6实施例通过集成到用户Web终端的电话接口来建立呼叫的整体操作的图；

图15是说明发明另一个实施例的整体操作的图，其中在PSTN和国际互连网之间提供接口用于电话业务；

图16是说明发明又一个实施例的整体操作的图，其中在国际互连网和PSTN之间提供呼叫建立网关；

图17是说明发明的再一个实施例的整体操作的图，其中为Web用户实现免费电话业务；以及

图18是类似于图6的图，说明为PSTN的业务控制子系统的互连部件提供分布式处理环境。

                     具体实施方式

图6说明在PSTN中提供业务的设计，PSTN一般包括内部交换网络13(包括中继线和交换机，其至少一些是带有相关的IP的SSP 41)、将客户私人设备(这里表示为电话机40)连接到网络13的接入网络11、以及业务控制子系统42，后者包括至少一个SCP用于在请求时对SSP提供服务。将会理解的是PSTN的图6表示是高度概略的。

SCP 43可以响应来自SSP 41的业务请求以常规方式操作，根据业务请求中包含的信息在特定数据上运行特定的业务逻辑，并向请求SSP送回恰当的指示以实现呼叫建立。业务请求由SSP根据预定的触发条件在触发检查点得到满足而产生，在处理一次呼叫过程中存在一个或多个这样的检查点(注意到在触发条件已经从SCP下载到SSP的场合，于是可以说，当由于触发条件满足而联系SCP时，SSP响应SCP的信息请求——但是，在本说明中，这种从SSP到SCP的初始通信将被称为“业务请求”)。

SCP 43也提供了到国际互连网50的网络接入接口44，以便在处理来自SSP 41的至少一些业务请求的过程中利用某些业务资源项49(下面也简称“业务资源”)。这些业务资源49在HTP服务器51上以WWW页存储(更具体地，在这些服务器51的业务资源数据库52上)。包含这些业务资源的WWW页在下面称为“电话”页。服务器51连接到国际互连网，使用各自的URL或URN可读取这些电话页(为方便起见，以下使用更一般的名词URI表示电话页位置的国际互连网可解析的指示器)。

业务资源可能是业务逻辑或业务数据，而且可以被运行在SCP上的其他标准业务逻辑程序所使用，为此，需要借助于通过使用恰当的URI接入所需资源的电话页。在某些情况下，业务资源49实际上可以提供所有与特定业务有关的的业务控制和数据。在这种情况下，运行在SCP 43上的业务逻辑程序是纲要的形式，在接收到业务请求时被加以实例化，然后用于启动业务资源访问并将这种访问的结果返回到进行业务请求的实体。实际上，根据这种方法，SCP可以简单地作为获取得和执行电话页业务逻辑的平台来实现，而且当标准SCP平台需要这种逻辑时不需要为此具有复杂的设备和管理系统；然后SCP可以变得更为普遍存在，可能与每个SSP都是相关联的。

图7是表示当SCP 43通过访问电话页业务资源来处理业务请求的情况下的事件过程流程图。在收到INAP消息(步骤100)中的业务请求时，SCP 43以标准方式对TCAP/INAP消息结构解码(步骤101和102)，这些方式是本领域技术人员非常理解的。然后，SCP 43将业务逻辑程序SLP实例化，以处理该请求(步骤103)。然后这个SLP负责查找所请求的业务资源的URL，从业务请求中所含信息来进行确定(步骤104、105)。例如，如果业务请求涉及被叫方业务，那么所需资源将由所拨号码表示，以及将后者用于获得资源的URL。一旦所需业务资源的URL已经确定，资源请求(例如，以HTTP请求消息的形式)通过国际互连网发送到相应的存储所需业务资源的服务器(步骤106)；一个有关的ID随着该资源请求传递，以便来自后者的响应能够与恰当的SLP实例链接。并且还启动一个定时器(步骤107)。

如果在超时周期到期(在步骤108进行检查)之前从所访问的资源收到一个响应，那么该响应(一般是以目标号码的形式)将被提供给根据使用随着该响应传递的相关ID来识别的恰当的SLP(步骤109)。然后准备INAP/TCAP响应消息并发送到进行最初业务请求的实体(步骤110和111)，此后SLP实例结束(113)。

如果收到响应之前在步骤108出现超时，那么在客户记录中查找缺省的响应值(一般是缺省的目标号码)并放入INAP/TCAP消息中，然后发送回请求实体(步骤114到116)。然后结束SLP实例(113)。

定位和接入业务资源

与访问电话页资源有关的功能在图6中通过资源访问块46示意性地表示。块46包括URI确定块47，用来基于传递到块46的参数确定包含所需资源的电话页的URI。通过使用块47返回的URI，资源访问块46通过接口44访问国际互连网上的所需业务资源49的电话页。

资源码——可能有超过一个的业务资源关联于特定的电话号码；在这种情况下，资源访问块46需要知道附加信息(例如当前通话点，pic)以便识别恰当的业务资源。如果关联于一个号码的业务资源处于不同的电话页上，那么附加信息也要传递到URI确定块47，以便使之返回恰当电话页的URI。也可能所有业务资源关联于处于相同电话页上的一个号码。在这种情况下，资源访问块46使用附加信息随访问请求向有关电话页传递资源标识参数；然后进行与电话页有关的功能，访问正确的业务资源。

因此，每个业务资源可以认为是由各自的资源码54来标识(见图8)，该资源码54由用于识别资源在国际互连网上所处位置的URI的第一部分UI(“URI标识符”)、和用于在相同URI处的多个资源中识别该资源的第二部分RRI(“相对资源标识符”)组成。

资源访问——当只有一个业务资源49处于由唯一URI所标识的电话页58上时，资源码54就简单地包括UI，一般是只有电话号码或者电话号码加上pic参数(见图9)。在这种情况下，访问一个资源简单地包括将整个资源码54映射到相应的URI(处理55)，然后将请求57发向相应的电话页58，后者本身组成所需的业务资源49。然后将访问资源49的结果在响应消息59中返回。

相反，在多个业务资源49处于同一电话页58上时(图10)，资源码54包括UI和RRI，UI一般是电话号码，RRI是pic或用于分辨处于相同位置的资源的其他参数。在这种情况下，访问一个资源包括将资源码54的UI部分映射到相应的URI(处理55)，然后将请求57发向相应的电话页(处理56)，该请求包括资源码的RRI。电话页58包括用于基于请求消息中的RRI访问所需的资源的功能64。然后访问所需资源49的结果在响应消息59中返回。

另一种与图10的访问与其他资源共处一个电话页上的业务资源的方法不同的方法是：简单地使用从资源码的UI部分得到的URI通过国际互连网获取整个页，然后基于RRI来提取所需的资源。

从资源码确定URI——下面将考虑执行处理55的URI确定块47的实现方式。块47可以用不同方式实现，其中四种如下所述：

直接输入

尽管不一定方便，但是可以设计为被叫方直接输入所需的URI。被叫方因此可以输入所需URI的主机id成分(或以主机域名或以主机IP地址的形式)加上URI的路径成分。例如，在要访问被叫方电话页的情况下，呼叫方可以输入被叫方的URI，甚至这个输入可以取代电话号码的正常输入。前导输入串(例如“999”)可以用来表示输入是URI。对于输入装置，在用户只有标准的12键电话时，输入数据域名和需要字母符号的其他URI成分将必须使用一种标准的从电话键盘输入字母的技术来完成(例如，这种技术已经用于使呼叫方“拼写”出被叫方的名字)。将全字母数字键盘提供给用户以便有利于URI输入也是可能的。

计算

通过国际互连网访问的业务资源可以限制为一组被拨打的号码，从其中可以计算相应的URI；在这种情况下，这种计算是块47的责任。

关联表查找

块47最简单的实现可能是一个关联表(或者在存储器中或者保存在数据库磁盘存储48上)，该表将URI与每个资源码的UI部分相关联。这种方法可能存在的问题是世界另一端的被叫方号码可能需要业务资源，这意味着世界各地的PSTN运营者之间要有严格的更新制度，以便保持关联表是最新的。(注意：关于把被叫方号码标志为一个触发业务请求所需的号码，同样的含义不一定是可行的，因为号码可能设计为触发一个恰当业务请求的一组号码中的一个，这是以类似于800号的方式)。

DNS类型的查找表

另一种类型的查找方法是使用层次结构的分布式数据库系统，类似于国际互连网的(或甚至为其一部分)域名系统(DNS)，以便将资源码的UI部分解析为相应的URI。这种方法(下面将更详细地描述)一般包括每个PSTN运营者为URI所关联的号码所维护的数据库。这些数据库是所有PSTN通过诸如国际互连网这样的网络可访问的，其解析请求以类似于域名系统的方式指向恰当的数据库。在这种情况下，块47由设计为通过接口44经由国际互连网请求UI解析的恰当的解析程序所构成。

在描述URI确定块47的DNS类型的查找实现方式之前，需要另外一些一般的说明。无论何种方法用于确定URI，如果在允许的URI上做一些有限的限制，一些简化就是可能的。特别是，在如下情况下不必确定URI的所有成分：

(i)URI的路径成分的一部分对于所有业务请求是标准的，一旦URI的其余部分确定以后，这个标准部分简单地由块47添加。例如，当查找漫游号码时，习惯上总是将其存储在特定服务器上用户目录的“tel”子目录中的“roam”文件中。在这种情况下，URI主机成分和路径成分的用户唯一部分首先确定，然后添加其余的路径部分“/tel/roam”。

(ii)URI路径成分可以设计为与资源码的预定部分相同，块47只需确定主机成分，然后添加路径。例如，可以允许路径总是以有关的电话号码结束，或者在主机上很大可能是唯一的足够的终结号码。路径也可以包括标准的由块47添加的成分。

(iii)电话号码块可以在相同的主机服务器上有其相应的业务资源，这样只需使用电话号码的一部分来确定URI的主机部分；在这种情况下，路径成分可以方便地包括每个电话号码的全部或部分。这种情况意味着电话运营者所控制的一个严格等级并且不给电话用户提供选择将他们的电话页放在哪个主机服务器上的自由。

另一个通常值得注意点是，不管用何种方式确定URI，URI的主机成分或者是以主机域名、或者是以主机IP地址的形式来提供。当主机以域名来标识时，URI主机名到IP地址的进一步解析随后将以标准方式由接口44使用国际互连网的域名系统来实现。如果主机标识直接以IP地址提供，可以避免这种进一步的解析。

当使用数据库查找为URI翻译提供号码时，这个数据库可能独立于一个包含其它与客户有关信息的客户数据库、或与其相结合。影响这种选择的因素一方面包括可能希望该号码到URI翻译信息被广泛提供，另一方面可能希望限制对其它与客户有关信息的访问。

DNS类型URI查找

现在更详细地描述URI确定块47的DNS类型查找方法，在此，资源码的UI部分是一个电话号码而且不对URI进行限制，因而需要通过查找返回URI的完整主机和路径成分。整个过程的关键部分是从有关电话号码构成等效的主机域名；这种等效域名通过查找机制解析为相应的URI，在本例中，这种查找机制类似于DNS所使用的(实际上，该查找机制可以结合到DNS中，尽管它也可能是独立实现的)。

在上面当引入术语“DNS类型”系统时，已经参考图3描述了DNS的性质。为了方便起见，在如下的DNS类型系统中(该系统用于为URI翻译设备提供电话号码)将称其为“Duris”系统(代表“DNS-type URIServer(DNS类型的URI服务器)”系统)。

围绕Duris系统操作的基本原则是：

-每个电话号码可以转换成主机域名(包含所关心的电话号码这种主机域名的名字空间在下面称为“电话名字空间”)；而且

-对于主机域空间中的每个主机域名，由包含相应URI的Duris系统为其存储一个注册记录。

因此，在本情况下，构成资源码54(见图11)的UI部分的输入电话号码首先被解析，以便构成主机域名(步骤120)，然后传递到Duris系统(图11中表示为由DNS本身提供)，以便获得具有相应的URI的RR(步骤121)。从URI查找继续下去，如果返回的URI具有作为域名的主机成分，接下来就使用DNS获得主机IP地址(步骤122)；当然，如果主机成分在RR中以IP地址方式存储，这个步骤就不需要了。然后URI用于向恰当的服务器进行资源请求，以传递资源码54的任何RRI部分(步骤123)。

关于可以如何实现Duris系统，在顶层有以下多种可能：

(a)独立于DNS。在这种可选方案中，电话名字空间构成以电话名字空间的根为“.”名字空间根来管理的整个名字空间(见图12A，阴影表示了所设计的电话名字空间)。在这种情况下，Duris系统独立于DNS本身。当然，Duris系统可以使用与DNS相同的基本基础设施(即，国际互连网)或完全独立的网络。在电话名字空间包括与世界上所有公用电话号码对应的所有域名的情况下，解析完整的国际电话号码将给出完全合法的域名。当然，电话名字空间可能是一个较小的名字集合，例如从世界范围经营的公司内的内部转接号码中得到的那些。

(b)DNS内的不分段的电话名字空间。在这个可选方案中，电话名字空间是DNS名字空间的域，Duris系统由DNS本身提供。因此，当电话名字空间包括从世界范围的公用电话号码得到的所有域名时，电话名字空间可以放在ITU的域名内，在特定的子域“tel”中，电话名字空间的根为“tel.itu.int.”(再次参见图12B，阴影区域代表名字空间)。管理域“tel.itu.int.”的责任归于ITU。在后面这个例子中，为了从输入电话号码构成完全合法的域名，在解析了号码以构成对应于电话名字空间内的结构的域名部分之后，添加尾“tel.itu.int.”。然后给DNS提供完全合法的域名并获得保存所需URI的相应RR记录。作为另一个例子，电话名字空间可以是从Hewlett-Packard中内部转接号码得到的所有名字，在这种情况下，电话名字空间的根是“tel.hp.com.”，Hewlett-Packard将完全负责这个域的管理。

(c)DNS内分段的电话名字空间。在这个可选方案中，电话名字空间在DNS名字空间的多个域之间分开，Duris系统由DNS本身提供。因此当电话名字空间包括从世界范围的公用电话号码得到的所有域名时，电话名字空间可以在每个国家域的各个“tel”子域之间分开；因此如图12C所示，对应于法国电话号码的电话名字空间部分的根为“tel.fr.”，对应于UK电话号码的电话名字空间部分的根为“tel.uk.”。管理每个“tel”子域的责任归于每个国家。在后面这个例子，为了从输入电话号码构成完全合法的域名，在解析国家码之后的电话号码部分构成国家“tel”子域内的域名部分，然后添加有关国家的合适的主机域名尾。因此，对于法国电话号码，在号码被解析并用于添加“tel.fr.”尾之前去掉“33”国家码。每个国家合适的尾可存储在本地查找表中。作为另一个例子，各自带有DNS域“xco.com.”和“yco.com.”的两个商业组织(X公司和Y公司)可能同意运行一个共同的Duris系统，并且使电话名字空间在“tel.xco.com.”和“tel.yco.com.”之间分开。在这种情况下，从X公司输入的任何Y公司电话号码将被解析为以“tel.yco.com.”结尾的完全合法的域名，反之亦然。

下面将考虑将电话号码解析为域名——换句话说，将“.”字符插入该号码以提供域名结构。当然，正如已经解释的，电话号码是根据每个国家的编号方案所做的层次结构。因此一种方法可能是遵从这种将电话号码分开而结构的编号方案以构成域名。例如，电话号码“441447456987”，是带四位数字区域码(“1447”)和六位数字本地号码(“456987”)的一个UK号码(国家码是“44”)，可以分开构成456987.1447.44的域名(注意出现逆标号顺序，是因为DNS标号是按最低有效位在先而设计的)。如果电话名字空间是DNS的子域，其安排如图12B所示，从该电话号码得到的完全合法的域名应该是：

           456987.1447.44.tel.itu.int.

但是，当将电话号码解析为主机号码时试图匹配编号方案层次存在固有的困难。首先，为了正确地解析国际号码，必须为每个实体安排这样的操作任务：知道每个国家编号方案的结构，并且当例如在UK，区域码可能有不同长度时，所需的知识可能必须具有查找表的形式。同时这不是一个复杂的计算任务，它主要是管理性的琐事，因为它意味着每个国家将必须通知所有其它国家有关它的编号方案和任何更新。第二个问题是六或七位数字本地号码是个非常大的域；为了维护和统一的原因最好是产生子域，但是没有明显的方法来完成它。

这些问题可以通过放弃这样的限制而得到克服，该限制就是：电话号码到域名的解析应该匹配国家编号方案的结构。事实上，没有很强的理由去遵循这样一个方案，因为DNS服务器对名字空间的含义一无所知。因此可以使用确定的算法解析电话号码，例如，每次取4个数字以限制每个子域的大小，并且使得无需知道有关的编号方案就可以“插入点”。只要正确地产生DNS域和DNS服务器所服务的地带，就都能有效。

对于国际号码，分开国家码似乎是恰当的，因此一种混合的解析方案是：根据已知的国家码来解析拨号号码的初始部分，然后使用确定的方案(例如3，7或4，6或3，3，4)将数字分开。当然，如果使用分段的电话名字空间，如图UC所示，那么就可使用国家码查找主机名尾，并且将要进行解析的只有号码的国家部分。

最后，有关如何建立DNS服务器以便存储带URI的RR记录的细节，可以参考例如Paul Albitz和Criket Liu的“DNS and BIND”，O’Reilly& Associates，1992，它描述了如何使用Unix的BIND方法建立DNS服务器。RR记录的类型例如是文本。

应该注意的是DNS标号在理论上不应以数字开头。如果保持这个传统，在解析电话号码时插入标准字符作为每个标号的第一字符当然只是个小操作。因此，一个4位数字标号2826则变成“t2826”，这里“t”用作标准的开始字符。

应该理解的是对于域名来说，在输入的电话号码不是完整号码的场合(例如，一个本地呼叫不需任何国际或地区码前缀)，应该解析为本地域中的域名。

前面已经就将电话号码翻译成URI讨论了Duris系统实现，这里电话号码构成资源码的完整UI而且Duris系统返回完整的URI。应该理解的是，所描述的Duris实现，在关于UI形式和URI的哪个部分需要查找方面，都可以很容易地适应于包容上面讨论的各种修改。例如，在多种不同业务资源关联它自身文件中的一个用户、而且所需的资源由资源码的pic部分标识的场合下，那么输入电话号码将不是被用于查找完整的URI，而是被用于查找主机成分和直到有关子目录的路径成分部分，然后将UI的pic部分附加上，以标识所需的资源文件。

对于小型本地Duris的实现方案，可以用单个服务器；但是只要具有其它有关的特性，该实现方案应该仍然被认为是DNS类型的。

业务资源的性质

现在转到考虑业务资源49，下面将更完整地、但是以举例方式描述这些业务资源如何提供给服务器51，而与特定PSTN用户(个人或组织，无论呼叫或被叫方)有关的业务资源或多个资源可以从一个用户终端53通过国际互连网放置在服务器51上，在一或多个WWW页上。

考虑简单情况，其中业务资源是例如电话号码这样的业务数据项(例如，如果对应于呼叫方所拨号码的用户电话占线，则尝试的另一个号码)。这个转移号码可以是用户电话页的唯一业务资源。电话页URI可以是带有设置为HTTP的方案的URL，在这种情况下，可以使用GET方法获得转移号码。如果电话页只用于转移号码的功能性获取，这样一种设计就是合适的。但是，如果转移号码要在用户终端53上可见地提供，那么就希望给该号码附加解释性材料(当转移号码可以设计为返回到已经提供环境信息的现有显示页中时，这常常是不必要的)。然而，在电话页包括解释材料以及转移号码时，一个只希望功能性使用电话页的实体可以设计为获取该电话页，然后提取转移号码(当然，这会需要将信息标识为从电话页提取的标准方式)。

对资源提供浏览和功能性访问来说需要解释性材料以便浏览，为此另一种而且是优选的设计是使用面向对象的方法进行资源设计。在这种情况下，资源对象有两种不同的访问方法与之关联，一个是纯功能性的使用资源，另一个允许对有关的解释材料进行浏览。然后，使用恰当的对象方法访问实体以便访问资源对象。

另一种为转移号码的浏览和功能性使用作准备的设计将提供为每个用途恰当配置的单独资源，每个资源有自己的资源码(一般，这种资源放在同一电话页上而且在这种情况下每个资源码的UI部分是相同的)。

用于人类用户的电话页的获取一般不象用于PSTN操作的获取那样在时间上很严格。因此，人们使用的业务资源的URL中所规定的方案可以是HTTP，这对定义特殊“电话”方案(访问协议)的操作使用是有好处的，这种方案会导致服务器51使用最佳的接入程序来访问所需的资源(在本例中是转移号码)并在尽可能短的时间内响应访问实体。

除了数据项，其它可能类型的业务资源包括在适当位置(在服务器)执行的业务逻辑(这种执行的结果返回到访问该资源的实体)；可从服务器下载到访问实体以供在实体处执行业务逻辑；以及供访问实体登录传递给它的信息的登录资源(或简单地登录已经被访问这样的事实)。将会理解的是，登录资源确实只是属于在适当位置可执行的业务逻辑的特殊情况。

举例来说，在适当位置执行的业务逻辑所构成的业务资源可以被设计为实现每天每时的日程，执行该业务逻辑的结果是这样一个电话号码，根据每天每时被叫方的位置应该将呼叫路由选择到该电话号码。由可下载业务逻辑所构成的业务资源的例子是使用IP提供的设施来控制呼叫方选择查询的业务逻辑。对于登录资源，可以用于记录访问特定号码的呼叫号码。

在每个资源有它自己的电话页、而且资源只以来修饰的功能形式提供的情况下，可以使用HTTP方案，以便使用GET方法访问可下载的业务逻辑和在适当位置执行的业务逻辑，以及使用POST方法访问登录资源。如果需要为每个业务资源提供解释性材料，那么上面讨论的任何与数据项关联的方法都可使用。

当一个以上的业务资源关联于一个号码时，每个这样的资源可以放置在各自的电话页上并且带有自己的URI。但是，优选的方法是将所有这样的业务资源放置在相同页上并使用相应资源码的RRI部分，以允许访问恰当的资源。所访问的资源根据其形式来对待(如果是在适当位置执行的业务逻辑就执行，如果是可下载业务数据或逻辑就返回)。

因此如果转移号码业务数据资源和每天每时在适当位置执行的业务逻辑资源都放置在相同的电话页上，转移号码资源码可能具有“1”的RRI，而每天每时资源码可能具有“2”的RRI值。

当要将呼叫/被叫方选项包括在业务资源中以提供给他们时，则如已经表示过的那样，这可以通过将业务资源组成可下载的业务逻辑来方便地完成，并且该业务逻辑带有可能启动搜索业务资源的请求的可选选项。

应该理解的是，业务资源常常是复杂的类型，它组合着业务数据及/或可下载业务逻辑及/或在适当位置执行的业务逻辑。特别强有力的组合是两种类型业务逻辑的组合，在此可下载业务逻辑被设计为与在适当位置执行业务逻辑相互作用；使用这种设计，可以提供用户复杂的客户机-服务器类型的应用。

业务资源使用例子

图13说明了使用服务器51上的资源的业务操作。这个业务等效于“个人号码”业务，用户可以通过一个单一的不变号码被访问，甚至当其在具有不同的实际号码的电话机之间移动时也可以。为了实现它，需要这种业务的用户(在本例中是用户B)被从一组号码中分配一个唯一的个人号码(这里是称为B的“Webtel”号码)，所有这些号码都具有相同的前导号码串，使SSP很容易识别被叫号码是Webtel号码。用户B在HTTP服务器51上的专用电话页上具有业务资源49，这个电话页处于这里称为“URL(B电话页)”的URL处。当被访问时B的电话页返回可以找到B的该当前漫游号码(“B-telNb”)。在最简单情况下，B的电话号码页只是当B转移到不同话机时可由B修改的单个号码(例如，从终端53修改)。最可能的是，B的电话页是提供每天每时日程的在适当位置执行的业务逻辑。

在本例中，将B的Webtel号码和B的电话页URL之间的关联存储在SCP 43可访问的关联表中。

当用户A通过拨打B的Webtel号码试图联系用户B时，A所使用的电话机4 0建立到SSP 41的呼叫请求(注意在图13中通过电话网的承载路径用粗线60表示，其它深线表示信令流)。SSP 41检测到所拨号码为Webtel号码，向SCP 43发送带有B的Webtel号码的业务请求。SCP 43收到这个业务请求时，启动业务逻辑程序以便控制将B的Webtel号码翻译成B的当前漫游号码；实际上，在本例中，这个程序简单地请求资源访问块46去访问B的Webtel号码所标识的业务资源(即，B的电话页49)并返回这次访问的结果。为此，块46首先将B的Webtel号码翻译成B的电话页URL，然后使用这个URL通过国际互连网访问B的电话页(例如，使用已经提到的“电话”方案，其方法对应于HTTP GET方法)。其结果是使B的当前漫游号码B-telNb返回到块46并及时地将这个号码返回到SSP 41，后者再启动到对应于B-telNb的电话机40的呼叫建立的完成。

图13例子涉及被叫方业务；当然，应该理解的是，通过国际互连网访问业务资源的原则可以应用于所有类型的业务，包括呼叫方和被叫方业务及其混合。因此，标准的800号业务可以这样实现，所拨的800号产生对一个由适当位置执行的业务逻辑组成的电话页资源的访问，它返回最恰当的号码以便控制前向呼叫路由选择。

应该理解的是，尽管在图13例子中来自SSP的业务请求是由所拨号码的前导号码串来触发的，但是业务请求也可以由不同的触发器触发，包括呼叫方号码、被叫方号码、或一些其它的用户输入，这样的触发器可能由呼叫建立过程规定(例如，被叫方号码由占线状态或振铃超过一定时间来规定)。

对于上面提到的登录业务资源，这种资源的一个可能的应用是电话投票。在这种情况下，拨打投票号码可以使接收呼叫的SSP向SCP 43传递一个业务请求，SCP 43再通过国际互连网联系恰当的登录资源，在呼叫结束前记录一次投票。为了使瓶颈最小，登录资源可以在不同URL为每个SCP提供，通过国际互连网收集并比较来自所有这些登录资源的投票是一件简单的事。如果带国际互连网接入的SCP在每个SSP被提供，那么阻塞的危险就大大降低了。

已经注意到了，用户电话页可以存储多种业务资源，这样，来自访问SCP的访问请求需要包含恰当的RRI为标识所需的资源。

在SCP为一些用户提供传统的IN业务、而对其它用户则使用国际互连网可访问的业务资源提供等效业务的情况下，可能需要在SCP中提供查找表以保证业务请求被恰当处理；这样的查找表可以方便地与客户记录数据库相结合。

一旦一个用户(例如用户B)建立了一个或多个电话页来指定他所需的业务资源(特别是定义个人化业务的业务逻辑)，用户B要让任何他所希望的PSTN运营者使用、访问并利用这样的业务资源显然是合逻辑的。如果Webtel到URI数据库对所有运营者提供，这就是可能的。因此多个运营者可以设置成为去访问B的电话页(一页或多页)。如果一个运营者谢绝使用B的电话页，B显然可以选择不使用该运营者(至少在该运营者针对用户选择提供了长期的传输业务的场合下)。因此会出现这样的可能性，业务提供将停止支配运营者的利润，而是运营者对电话页使用的提供将成为PSTN运营者必要的基本特性。

提供并更新业务资源

下面考虑如何对服务器51提供业务资源49并随后进行更新。

只要考虑提供时，需要两个基本动作：首先，业务资源必须放置在服务器51上，其次，业务资源的URI以及访问该资源所需的触发条件(号码加上任何其它条件，例如呼叫点)必须通知给PSTN的运营者；如果多个资源在同一URI上提供，那么针对特定触发条件获取恰当资源所需的RRI值也必须通知。这个通知过程此后将称为向PSTN运营者“注册”业务资源；当然注册是必须的，以便建立SCP 43所使用的关联表并在SSP 43中设置触发条件。对于某些业务(例如上面参考图13所描述的)，不是用户提供触发号码(图13例子中的Webtel号码)，而是PSTN运营者作为注册过程的一部分向用户提供恰当的号码。

对于将业务资源放置在服务器51上的过程，其如何实现将依赖于PSTN运营者对于这种业务资源对PSTN运作的可能影响的态度。在业务资源简单地向访问实体返回数据项的场合下，运营者可能不太关心实现该业务资源可能会出的错误(偶然的或故意的)。但是，运营者可能非常关心资源可能返回的任何业务逻辑的正确操作；实际上，一个运营者可能不允许这样的业务资源。

暂时假设运营者不关心业务资源的性质或实现，那么如何将资源放置在服务器51上将很大程度依赖于所关心的服务器的性质。例如，如果用户具有带国际互连网网络接入的计算机、而且这个计算机用作服务器51，那么用户可以简单地将所需资源装载到服务器上作为外部访问的WWW电话页。如果服务器是一个用户通过内部LAN访问的机构的服务器，会出现类似情况。在后两种情况下，作为WWW电话页来装载资源，其本身不需要国际互连网访问。但是，如果服务器51是由外部国际互连网业务提供者运行的，那么用户可以安排将所需业务资源下载到服务器上用户所分配的Web站点空间中；这可能包括也可能不包括国际互连网访问。后一种情况的一个特殊方案是PSTN运营者为包含业务资源的用户电话页提供特殊服务器。

除了用户自己的计算机作为服务器51的场合，将业务资源放置在服务器上一般都包括清除一个或多个级别的口令保护。

关于用户装载到服务器51的业务资源的来源，可以由用户产生，或者特别是在资源包括业务逻辑的场合，它可以由第三方提供(包括PSTN运营者)。

如果PSTN运营者希望控制业务资源49以避免任何对PSTN运作的负面影响，可以有两种方法。首先，运营者可以要求每个资源(或可能是一个特定子集)必须在使用前接受一个验证过程，然后采取恰当措施避免用户对资源的随后改变(可能除了特定的数据项之外)；在这方面，运营者可能要求将资源放置在运营者控制的服务器上而且用户对其不进行写访问(如上所述，可能除了改变特定的数据项之外)。使业务资源49的负面影响最小的第二种更引人注意的方法是，运营者提供标准的业务资源，用户可以对其添加用户自己的数据(而且在资源包括业务逻辑的情况下，可能进行有限的功能选择)；然后将定制好的资源装载到受运营者控制的服务器51上。这个过程可以使用HTML“表格”很方便地针对特定资源而实现，用户可以通过WWW从运营者控制的服务器上下载该表格。在完成表格并激活了表格的“提交”图形键之后，输入的信息可以“粘贴”回到服务器，在那里使用该信息产生将来放置在该服务器上的定制好的业务资源，以便通过国际互连网访问。这种方法的一个好处是对运营者注册业务资源可同时实现。(可以注意到，如果注册需要作为一个与业务资源在服务器上的装载相独立的动作来完成，那么使用HTML表格是实现该注册过程的非常方便的方法)。

从前面可见，尽管提供过程不一定需要通过国际互连网传递信息，但在很多情况下这是最佳的办法，特别是如果通过WWW交换的HTML表格可用于产生定制的业务资源。应该注意到使用HTML表格产生定制的业务资源不限于PSTN运营者控制服务器这样的情况。

关于更新业务资源，很可能需要非常频繁地更新某些数据项(例如，漫游号码)。当PSTN运营者不对业务资源49进行任何控制时，更新是相对简单的事，只需要对有关的服务器进行写访问(正如已经指出的，这一般包括一或多级口令保护)。但是，当PSTN运营者例如通过只允许定制标准业务资源从而在业务资源上实行控制时(这种定制的资源被装载在运营者所控制的服务器上)，那么对业务资源的写访问可能就是严格受控的。然而，HTML表格可以方便地用作在这种情况下修改数据项的媒介；对于运营者，这样具有限制可能的修改的好处，对用户也是如此，一个表格接口应该提供资源修改的简单路由。

对于更复杂的更新，有必要通过类似于最初提供所需的一样的过程。

特别在业务资源存储在受PSTN运营者所控制的服务器51上的情况，资源更新通常包括通过国际互连网的通信。

Web用户交互作用

下面考虑服务器51上电话页中存储的业务资源的其它可能的使用。例如，如果用户B的电话页包含转移号码，那么假设这个电话页是从用户A的终端53通过国际互连网可读取的，用户A可以使用终端53上运行的图形Web浏览器来浏览B的电话页并发现B的转移号码。正如前面所讨论的，转移号码可以传递到用户A以供显示在已有的提供该号码含义的可视环境中，或者可以随同附加的解释文字传递到用户A。

更有用的例子是用户B的当前漫游号码业务。假设B在服务器51上的电话页49(见图14)在被访问时可用于返回一个可以找到B的当前漫游号码。再假设用户B具有一个Web站点，带有写在HTML中的几个Web页，每页都包含图形的“电话”按钮，该铵钮当激活时使用GET方法通过URL访问B的电话页。现在如果用户A正在从用户A的终端53通过WWW浏览(箭头66)B的Web站点，他决定想呼叫用户B来讨论关心的一些项目，用户A简单地激活当前所浏览的B的页上的电话按钮65。这将引起使用HTTP请求“GET URL(B电话页)”来访问B的电话页——见箭头67。

然后确定被呼叫的B的当前号码并传递给用户A的终端53(见箭头68)，以便在那里显示。有关号码的解释性文字一般也要显示；例如可以显示文字“请按如下号码呼叫我”，这段文字或者通过与电话按钮关联的HTML脚本提供，或者当返回当前号码时从电话页得到。实际上，可能对用户A更有用的是不仅提供用于去找到用户B的当前号码，而且提供有可能找到B的所有号码，以及B最可能处在每个号码的时间。由于这个额外信息很可能经常改变，提供该信息唯一明智的方式是来自电话页。因此，B的电话页不仅提供用来找到B的当前号码，也提供包括会被改变的号码和时间的文字；当然写B电话页的脚本时要以保证可变数据只需在一个地方进行更改的方式完成。

在另一个例子中，B的电话页可能包括在用户A终端处可以执行的可下载业务逻辑。在要将选项提供给用户的场合下这是有用的，每个选项产生随后的动作，例如获取另一个电话页。例如，首先访问的电话页可能是家庭电话页，给出家庭的一般电话号码，但是也对用户给出选择每个家庭号码上其它电话信息的可能性，例如每天每时有关的号码；在这种情况下，每个家庭号码具有自己的随后的电话页。

在上述情况中，用户A被提供了一个通过PSTN呼叫的号码。用户A可以摘下他的标准电话机并拨打给出的号码。实际上，如果A只有通过普通的、非ISDN的、PSTN线路的SLIP/PPP连接的国际互连网接入，会出现复杂因素，因为此时当网关90试图建立一个到A电话机呼叫时，A的电话线已经占线进行国际互连网接入；在ISDN连接中，由于提供两个信道，就不会出现这个问题。克服这个问题的一个方法是让用户A的终端53在得到来自B电话页的呼叫号码之后，通过存储任何所需的状态信息(例如，被访问的当前WWW URL)自动挂起它的国际互连网会话，然后结束SLIP/PPP连接，藉此释放电话线。然后A可以给B打电话。在这次呼叫结束，A可恢复挂起的国际互连网会话，使用所存储的状态信息返回A呼叫B时所离开的点。另一种方法是在连接到A的电话线上操作一个合适的复接调制方案，以允许话音和数据同时传输。已经存在很多这类方案。在一些点上PSTN需要分离来自A的合并的数据和话音流并分别传递到合适的目的地(国际互连网数据被转发到提供用户A的SLIP/PPP连接的ISP，话音流被传递到B)；当然，相反方向上的数据和话音业务流在一些点上也必须合并，以便通过最后的通路发送到A的终端。

如果不采取A使用标准电话手动地拨打B的方案，另一种可能性是给用户A的终端提供使A从他的终端通过PSTN进行呼叫的功能；这个功能一般包括连接到电话线的硬件接口70(图14)以及电话驱动软件71，后者用于响应来自诸如Web浏览器73这样的应用软件的输入以驱动接口70。A可以呼叫它的电话软件并输入所需的号码，或者优选地，A只需在屏幕上“选择”从B电话页返回的号码并将其传递到A的电话软件。实际上，假设用户B已知道在A终端上提供拨号功能的软件71的软件接口，B的电话页可以返回到A的终端程序码，以便在A确定他希望继续进行呼叫时自动拨打B的号码。作为另一种进行话音呼叫的方法，如果A终端配备了合适的调制解调器以及控制软件，A可以选择通过PSTN向B发送传真或数据，或者是B的常用号码、或者B电话页中规定的号码作为用于这种传输的号码。当然，在不是ISDN线而且A通过SLIP/PPP连接获得国际互连网接入的场合，从A终端通过PSTN进行呼叫可能出现已经讨论的电话线使用的冲突问题。

但是，进行呼叫时，如果对应于A所尝试号码的B电话占线，则会存在很多可能性。因此，如果B有一规定转移号码的电话页，而且B已经向PSTN注册了这个业务资源，那么转移号码应该由PSTN来自动尝试。但是，如果转移号码资源没有向PSTN注册，将会向A返回占线信号。在A已经通过标准话机进行呼叫的场合，A必须决定如何继续下去，A可以选择放弃或者再次参考B的电话页，以便查找转移号码并使用这个号码重拨。如果A使用他的终端53进行最初的呼叫，那么后者可以编程以便检测占线信号的返回，然后自动查找B的转移号码并使用这个号码重拨。这个功能可以包括在从B电话页下载的业务逻辑中并运行在A终端上。

如果A必须结束国际互连网会话以便释放电话线而用于话音，那么返回到再次参考B电话页需要启动新的国际互连网会话(实际上，如果提供拨打B的最初号码时B的转移号码已经传递到A终端，这种不方便可以避免)。

当B电话机占线时，在B电话页上访问的业务资源当然可以比只有转移号码更复杂。特别是，可以给用户A提供一定范围的选择，例如包括B的传真或语音信箱号码，选择一种选项潜在地启动恰当访问的软件的运行。另一种可能的选择是当A选择这个选项时使用从B电话页下载的的表格给B留下回话消息；完成的表格将贴回到服务器51并被记录以便B及时检查。

当然，可能出现用户A希望访问B的电话页以便找到例如B的当前漫游号码，但是用户A不知道B的Web站点的URI而只有B的Webtel号码。A可以只通过PSTN呼叫B，在这种情况下，B的Webtel号码到漫游号码的翻译将自动实现(假设B仍然注册了这个业务)；但是，A不希望立即呼叫B，只是记下他的当前漫游号码。为了解决A的问题，以前描述的Webtel到URI关联表优选地使得在已知地址(例如，在已知的Web站点)的国际互连网上可访问。A现在需要做的只是访问这个Web站点，传递B的Webtel号码；然后B的电话页URI将返回给A，他可以用它来访问B的电话页。当然，这个过程可以从A向关联表Web站点发送B的Webtel号码时自动进行。

国际互连网/PSTN呼叫接口

在图14的情况下，A对PSTN的接入通过标准电话接口，即使由于被集成到A计算机终端53中而使A的实际电话形式与标准的不同。图15表示一种情况，其中在同图14情况一样地将B的当前漫游号码提供给A之后，A通过一条从国际互连网开始然后通过用户网络接口80进入PSTN的路由去呼叫B。接口80被设计为可在PSTN上的ISDN类型电话信令和国际互连网上以IP分组形式传输的相应信令表示之间进行转换；此外，接口80将来自IP分组的话音数据传递到中继线60上，反之亦然。

因此，当A开始呼叫B时，A终端中的国际互连网电话软件81通过国际互连网向接口80发送呼叫启动信令，其地址是A终端已知的。在接口80，信令被转换为ISDN类型的信令并传递到SSP 41。然后以一般方式建立呼叫，返回信令则通过接口80、经由国际互连网回传到A终端内的软件81。这个软件将呼叫建立过程信息传递到WWW浏览器73以便显示给A。当呼叫建立后，A可以通过他的电话机与B通话，而且A的话音输入首先在电话硬件接口83中数字化，然后由软件81将其插入IP分组，经过国际互连网到接口80(见箭头84)；来自B的话音业务流沿着相反路径走。

IN业务可以由SCP根据来自SSP 41的业务请求而提供给这个呼叫。因此，如果B话机占线，而且B注册了呼叫转移，那么SCP 43在收到业务请求后将访问B的恰当的电话页以用于呼叫转移和获取转移号码。如果SSP 41没有设置为当B话机占线时启动业务请求，那么就向A终端返回占线指示，在那里以参考图14所描述的方式处理。

实际上，可以提供接口80以类似于SSP的功能，以便设置触发条件并在这些条件满足时向SCP 43产生业务请求。

第三方通话建立网关

图16表示了另一种设计，藉此A可以在收到B的当前漫游号码之后呼叫B。在这种情况下，提供一个第三方呼叫建立网关90，它既与国际互连网50接口也与SSP 41接口。方便地，网关90可以与SCP 43在一起(尽管这并不重要)。网关90能够命令SSP 41在指定的话机之间建立呼叫。

因此，当A希望呼叫B时，第三方通话建立请求从A终端通过国际互连网发送到网关90(见箭头91)。这个建立请求包括A的电话号码和B的当前漫游号码。网关90首先试图建立到A话机的呼叫(这一般应该是成功的)，然后建立到B所标识的电话的呼叫。一旦呼叫建立，A和B就通过PSTN以标准方式通信。

如果B话机占线，那么前面描述的情景就不会发生了。

网关90也可以设计为当满足预定触发条件时向SCP 43进行业务请求。因此，网关90可以设置为可采集B话机上的占线条件并向SCP 43启动转移号码的业务请求。但是优选的是将占线指示通过网关90传回A终端，因为，这样可以给A提供进一步动作的灵活性。

正如已经结合图14所做的一般讨论那样，如果A只有通过普通、非ISDN的PSTN线路的SLIP/PPP连接的国际互连网接入，会出现复杂性，在这种情况下，当网关90试图建立到A话机的呼叫时，A的电话线已经被国际互连网接入所占用。关于图14所讨论的解决办法(终止国际互连网会话；在同一电话线上复接话音和国际互连网数据)也可以在这里使用。如果用户A的终端可以将话音呼叫处理为通过国际互连网传递的数字化语音，既针对图14也针对图16情况的另一种方法也是可能的。在这种情况下，话音呼叫可以通过图15形式的接口80进行，而且话音业务流和与B电话页及/或网关90的国际互连网通信都可以在国际互连网分组中载送，这些分组通过去/自A终端53的SLIP/PPP连接来传送，但是，是作为传送到终端53上运行的独立应用中的逻辑上不同的流来进行传送的。

可能会注意到，A终端向网关90所做的第三方通话建立请求可以同样地由B电话页中存储的业务逻辑来进行并由服务器51执行(当然这种设计需要将A的电话号码传递到B电话页业务逻辑，并可以设计为自动产生或者通过一个在终端A提供给用户A、然后贴回服务器51的表格)。

也可能注意到的是，图15的接口80以及图16的网关90提供了业务请求通过SSP 41以外的实体传递到业务控制子系统的例子。

基于WWW的“免费电话”(800号)业务

可以使用WWW和PSTN的组合来实现“免费电话”或“800号”类型的业务。从下面参考图17对这种业务的描述来看，WWW/PSTN实现方案不必依赖于从呼叫方向被叫方传递通话计费或者使用特殊的“800”号这两种标准的“免费电话”方案的特性。但是，WWW/PSTN实现方案确实拥有更一般的特性，即将查询方和查询方所针对的一方置于由后一方付费的电话联系中。

在图17的设计中，用户D(诸如大百货公司)在服务器51上有web站点；为了简单起见，假设服务器处在用户D的控制之下，用户D具有通过线路125对服务器直接的计算机接入。例如，D的Web站点可以包括很多类似目录的Web页，表示D提供的所售商品。此外，D具有免费电话页124，以供处理基于免费电话的查询；这页的URL与放置在每个Web站点目录页上的“免费电话”图形钮122相关联。

假设终端53的用户A正浏览D的Web站点以查找目录页(箭头121)。如果A看到感兴趣的项目并希望向D查询有关该项目的情况，那么A可以在终端53激活与所关心目录页有关的图形免费电话钮122。这次激活可以引起当前装载在A终端的目录页中所嵌的码向用户提示输入他们的电话号码，并可选择地输入他们的名字，随后使用POST方法向D的免费电话页发送HTTP请求并封装所输入的数据(箭头123)。D的免费电话页在收到这个请求时执行业务逻辑，以便将新查询(包括A的名字和电话号码)输入查询控制系统126中所保持的查询队列127。在本例中，查询控制系统通过国际互连网外部的线路125连接到服务器51；但是，使服务器51通过国际互连网与查询控制系统通信也是可能的，而且确实这可能是最实际的设计，在此，D的Web站点在ISP服务器上而不是在D控制的服务器上。实际上，当激活免费电话图形钮122时，A终端中运行的码可以设计成直接将查询请求通过国际互连网转发到查询控制系统，而不是将其通过服务器51传递回来。

查询控制系统126管理传递给它的查询以便保证以顺序方式处理它们。在收到新查询时系统126优选地大致估计需要多长时间才能处理该查询，这种估计基于目前排队的查询数目以及处理一个查询所需的平均时间。等待时间的估计值将放在对POST请求消息的响应之中通过服务器51传递回用户A。

查询控制系统126负责将查询分配给多个代理人，其每一个配备一个电话40和显示器129。一旦A的查询到达队列127的头就被进行处理，一个被检测到是处于空闲的代理人将处理该查询(因此，例如，该系统可以设计为检测代理人的电话何时挂机)。当这些条件满足时，分配和建立控制单元128取得A的查询，并在可用代理人的显示器129上显示A的名字和电话号码(为了清楚起见，这里称之为代理人D’)；如果用户D保持一个D的过去客户或客户信贷分类数据的数据库，那么单元128也将查找并显示已知的任何有关A的其它信息。同时，单元128通过国际互连网向网关90进行第三方通话建立请求(箭头130)，请求在可用代理人D’的电话和用户A的电话之间建立呼叫，两个电话都用它们各自的号码来标识。如果D’和A摘机通话，查询就进行了，通话费用由D付款，如同D通过PSTN发起呼叫一样。如果，因为任何原因，呼叫在预定的超时间隔仍然未结束，那么单元128可以设计为自动进行到队列127头上的下一个查询。

当然，可以省略让单元128通过网关90请求呼叫建立，或者让代理人D’手动拨打A的号码或者让单元126启动D电话的自动拨打(例如，代理人D’具有计算机集成的电话，类似于图14中A的那个)。这些方法的好处是可以不作修改而且无需任何业务装置地使用现有PSTN，实现基于WWW的免费电话业务。

正如联系图11和13所讨论的，如果A只具有通过普通、非ISDN的PSTN线路的SLIP/PPP连接的国际互连网接入，在对A进行呼叫时会出现复杂性，因为在这种情况下，当用户D试图建立到A电话的呼叫时，A的电话线已经被国际互连网接入所占用。关于图11和13所讨论的解决办法也可以在这里使用(终止国际互连网会话；在同一电话线上复接话音和国际互连网数据；以及通过国际互连网向A终端进行呼叫)。对于基于结束国际互连网会话的解决办法，这种结束可以延迟到A的查询将要处理的时候；但是，为此，必须从控制系统126通过国际互连网向A终端53提供反馈，并使导致国际互连网会话结束的码来与这种反馈相关联。实现它的一种方法是：使服务器51响应来自A的最初POST请求消息而发送的响应消息中包括一个相关码；任何传递给A的来自系统126的随后反馈中也包括这个码(服务器A也将该码传递到控制系统126)，藉此允许A终端正确地识别这种反馈。实际上，可以使用相同的机制为用户A提供关于用户A可能要等待多长时间得到回话的更新资料，无论是否存在用户电话线使用的冲突问题这种机制都是可用的。

在用户A只有电话40而且没有终端53的场合，还可能的是利用图17的基本结构提供用户A以免费电话业务而避开通话费用传递的复杂性。更具体的是，A可以拨打用户D的免费电话业务的特殊号码(典型的是800号)，而且SSP 41将以标准方式识别这个特殊号码并向包括这个特殊号码和A的号码的SCP 43进行业务请求。SCP 43通过进行号码到URL的翻译来确定D的免费电话页URL，并使用类似于请求123的POST方法的HTTP请求来接入D的免费电话页。一旦这个请求已经被D的免费电话页124注册为一次查询，后者就可以向SCP 43发送一个响应，请求它发出通告，例如“你的免费电话查询已经注册；请挂机，很快将与您联系”等。这个通告可以由IP以标准方式向A发出。然后A可以挂机并准备接收来自D的呼叫。

上述使用WWW的免费电话方案的显著好处是，用户D在查询被排入队列、等待处理的期间不会积累使用PSTN的费用。

各种变化方案

当然上述设计的很多变化方案是可能的，而且下面将描述很多这样的变化方案。

分布式处理环境。如图18所示，SCP 43可以通过分布式处理环境DPE 98接入HTTP服务器51，该环境至少在逻辑上与国际互连网分开。在这种情况下优选的是服务器51受PSTN运营者控制并因此在数目上有所限制。

DNS类型服务器上的业务资源。在上述例子中，业务资源项已经被放置在连接到国际互连网的服务器51上，而且所需的业务资源就可以通过国际互连网由PSTN的业务控制子系统和/或由国际互连网用户通过使用从标识所需业务资源项的资源码得到的URI来访问。在一种用于从电话号码形式的资源码得到URI的优选设计中，有关的全部及部分电话号码被解析成域名形式，然后使用DNS类型的分布式数据库系统分解成URI，该系统实际上可以集成到DNS本身中(见图11和12，以及有关的描述)。实际上，可以将业务资源项直接放入DNS类型分布式数据库系统所存储的注册记录中，这样，不是将被解析的电话号码分解成URI然后用于访问所需的资源，而是将解析的电话号码直接分解成所需的业务资源项。这个过程中使用的机制与已经描述的用于将解析的电话号码分解成URI的方法精确地相同。为此使用的DNS类型的分布式数据库系统将优选地是可通过国际互连网或DNS本身进行访问的，从而为国际互连网用户以及PSTN的业务控制子系统提供对业务资源项的访问(用上面参考图18描述的相同方法，存储业务资源项的DNS类型服务器可以由业务控制子系统通过一个非国际互连网的网络来访问)。尽管业务资源项在DNS类型服务器上所存储的RR中的放置可能不适合所有类型的业务资源项，但是这对诸如电话号码这样的不经常改变的项目是很适合的。因此，合适的用法是提供号码的便携性；在这种情况下，所拨的个人号码用首先解析的个人号码的全部或一部分去触发DNS类型系统中的一次查找，然后提供给DNS类型系统以返回当前号码用于呼叫的路由选择。所有拨出的号码都可以作为个人号码对待或者简单地作为这种号码的子集，这个子集包括那些例如通过在SSP上的本地查找或预定前导数字串的出现而很容易识别为个人号码的号码。可以使用全部或部分地解析电话号码(或类似号码)以构成供在DNS类型分布式数据库系统中进行分解的域名的一般概念，以便获取除URI和业务资源项以外的其它信息项。

反馈机制。在讨论图17中基于WWW的免费电话设计时，提到可以向用户A提供关于可能要等待多长时间才会给A回话的反馈。这是使用国际互连网向潜在或实际的电话用户提供反馈通道的例子。另一个联系图16提供的例子中，呼叫建立过程由呼叫建立网关向用户A的终端返回报告。实际上，一般当知道一个用户使用国际互连网上激活的终端时，就具有在呼叫建立过程通过电话系统向用户提供反馈的机会。为此，当然必须保证反馈可以传递到终端A上所运行的恰当应用中，而且这一般需要该应用提供恰当的链接信息。除了呼叫建立过程信息，其它信息也可以例如在呼叫保持阶段中反馈。因此，例如可以在国际互连网上提供特殊的服务器，以便保存可以在呼叫保持阶段输出给用户A的多媒体材料剪辑或甚至视频信息。

在所描述的设计中，服务器51保存了主要与呼叫建立控制有关的业务资源项。可能注意到在某些不同应用中，国际互连网服务器可以设计为保存可以由电话系统响应用户启动的电话请求而访问的数据，并返回给那个电话用户。例如可以响应当输入特定电话号码时触发业务请求的SSP来提供一种业务，该业务请求提示一个SCP，从而引起智能外设访问特定的国际互连网服务器(不必是HTTP服务器)并取得所需数据返回呼叫方。智能外设可能包括文本到语音转换器，以便将数据以声音形式重播给用户。

在与业务资源项本身有关的情况下，另一种反馈处理也是值得注意的。举例而言，电话用户G可以租用一种业务，藉此通过G话机的呼叫将按X分钟的最小值分割，X是用户设置的。为了实现这种业务，G在服务器51上有一电话页，它包括“占线”状态指示。当结束一次到G的成功呼叫时，G的本地SSP触发有关的SCP通过国际互连网向G电话页发送一条消息。这条消息使得设置G的占线指示，表示G正忙；该消息还启动一个定时器，它在时间X之后超时并使占线状态指示复位。对G的呼叫企图或者在G的SSP被拒绝(因为G线路确实占线)，或者将触发SSP以便通过SCP查询G电话页的占线状态指示是否设置。如果占线状态指示已设置(在一次成功呼叫结束后的X时间内它是这样的)，呼叫尝试就被拒绝，反之如果占线状态指示处于复位状态，就允许呼叫尝试继续。通过在G电话页上放置占线状态指示信息，可以使G能够容易地改变X的值。

更一般的变化方案。尽管PSTN的业务控制子系统已经作为一个SCP在前面例子中体现，应该理解的是，业务控制子系统的功能可以作为SSP的一部分来提供或设置在有关附件中。此外，业务请求的触发可以通过非SSP的设备来实现，例如通过SS7信令链路中插入的截取盒（interceptboxes)。

应该理解的是，术语“国际互连网”应理解为不仅包括用于国际互连网的TCP/IP协议的当前规范以及当前的寻址方案，而且也包括这些特性的发展，例如可能需要用于处理同步媒质的那些特性。此外，有关WWW和HTTP协议的参考资料应该同样理解为包括它们所发展的后代。

本发明也可以适用于PSTN以外的电话系统，例如PLMN或其它移动网络、以及使用PABX的专用系统。在后一种情况下，LAN或校园计算机网一般为与PABX相同的内部用户服务，起到所描述实施例中国际互连网的作用。

此外，本发明有这样的应用场合，其中任何交换电信系统(例如，宽带ATM系统)需要业务控制，而且计算机网络可以用于将业务资源传递到电信系统的业务控制子系统去。

Claims (18)

1.一种访问用于在交换电信系统上建立承载信道(60)的业务资源项(49)的方法，所述方法包括如下步骤：

(a)—提供带多个业务资源项(49)的连接到计算机网络(50)的至少一个服务器(51)，此后通过相应的已知URI可以在所述计算机网络(50)上对这些资源项定位，所述计算机网络在逻辑上与电信系统分开，而且所述业务资源项(49)涉及对通过所述电信系统的承载信道(60)建立控制，每个所述业务资源项关联于各自的预定码(54)，所述预定码与所述URI不同，并且用于标识所述承载信道的端点实体；

(b)—在每个所述预定码(54)和关联与该预定码的业务资源项(49)的所述已知URI之间提供一种映射(55)；以及

(c)—利用所述预定码(54)访问相应的所述业务资源项，通过使用所述映射(55)确定对应于该资源项的URI，然后使用这个URI访问所述计算机网络(50)上的业务资源项(49)。

2.根据权利要求1的方法，其特征在于至少一些所述的URI是通过按所述映射规定的功能进行操作、从而从它们相应的所述预定码(54)得到的。

3.根据权利要求1的方法，其特征在于至少一些所述的URI是通过按所述映射在将所述预定码和URI关联起来的关联表中进行查找、从而从它们相应的所述预定码得到的。

4.根据权利要求3的方法，其特征在于所述关联表存储在与所述计算机网络连接的至少一个数据库服务器上，步骤(c)包括访问计算机网络(50)上的所述数据库服务器、以便确定对应于所述预定码(54)的所述URI。

5.根据权利要求4的方法，其特征在于所述至少一个数据库服务器由DNS类型的分布式数据库系统所提供，其中所述URI存储在与这里称为域名的各自名字关联的记录中，记录通过域名获取，步骤(c)包括将所述预定码(54)翻译成相应的所述域名、并使用这个域名从所述DNS类型的分布式数据库系统获取所需业务资源项(49)的URI。

6.根据权利要求1的方法，其特征在于至少两个所述业务资源项(49)处于相同的URI，这些业务资源项的所述预定码(54)包括各自的相对资源标识符RRI值，这些值用于在存储业务资源项的服务器(51)中从相同URI的业务资源项中识别所需的资源项。

7.根据前面任何一个权利要求的方法，其特征在于所述交换电信系统是电话系统而且所述预定码包括来自下类中至少一个的号码：

——呼叫方电话号码；

——被叫方电话号码。

8.根据权利要求1的方法，其特征在于所述交换电信系统是电话系统，至少一些所述预定码(54)是被叫方电话号码并用于获取作为被叫方当前电话号码的业务资源项(49)。

9.根据权利要求1到6中任何一个的方法，其特征在于至少一个所述业务资源项(49)是相应服务器(51)在被访问时所执行的业务逻辑，这个执行结果返回访问实体，以用于承载信道建立控制。

10.根据权利要求1到6中任何一个的方法，其特征在于至少一个所述业务资源项(49)是可下载的业务数据，该业务数据当被访问时下载到访问实体，藉此进行承载信道建立控制。

11.根据权利要求1到6中任何一个的方法，其特征在于至少一个所述业务资源项(49)是可下载的业务逻辑，该业务资源项当被访问时下载到访问实体，以便在承载信道建立控制中执行。

12.根据权利要求1的方法，其特征在于所述计算机网络(50)是电信系统的用户一般可接入的。

13.根据权利要求1到6中任何一个的方法，其特征在于所述计算机网络(50)是国际互连网。

14.根据权利要求1到6中任何一个的方法，其特征在于所述交换电信网络是PSTN。

15.根据权利要求1到6中任何一个的方法，其特征在于所述电信系统是包括PABX的专用系统，所述业务控制系统(42)与之相关联，而且所述计算机网络(50)是LAN。

16.根据权利要求1到6中任何一个的方法，其特征在于所述URI是URL及/或URN，而且所述服务器(51)是HTTP服务器。

17.一种访问用于在交换电信系统上建立承载信道(60)的业务资源项(49)的方法，所述方法包括如下步骤：

(a)—在已知URL提供带多个业务资源项(49)的、连接到计算机通信系统(50)的HTTP服务器(51)，通过URL可以在所述计算机通信系统(50)上对所述项定位，所述计算机网络在逻辑上与电信系统分开，而且所述业务资源项(49)涉及对通过所述电信系统的承载信道(60)建立控制，每个所述业务资源项关联于各自的预定码(54)，所述预定码(54)与所述已知URL不同并包括各自的相对资源标识符RRI值，这些值可用于从相同URL的业务资源项中识别所需的所述业务资源项(49)；

(b)—在每个所述预定码(54)和关联于该预定码的业务资源项(49)的所述已知URL之间提供一个映射(55)；以及

(c)—通过如下子步骤，利用所述预定码(54)访问相应的所述业务资源项：

    (i)—使用所述映射(55)确定对应于该资源项的URL，

    (ii)—使用在子步骤(i)中确定的URL在所述计算机通信

系统(50)上访问存储所需业务资源项(49)的HTTP服务器

(51)；以及

    (iii)—使用预定码(54)的相对资源指示器RRI部分，

从相同URL上存储的业务资源项中识别所需的业务资源项。

18.根据权利要求17的方法，其特征在于所述电信系统是电话系统而且所述预定码(54)是与单独的电话用户关联的个人号码，所述业务资源项(49)是可能找到所述单独的电话用户的当前电话号码。

Images