电话系统业务的分布式体系结构的制作方法

文档序号:7570127阅读:195来源:国知局
专利名称:电话系统业务的分布式体系结构的制作方法
技术领域
本发明涉及电话,特别是在诸如因特网或其他数据网的现有网络上实现电话通信的方法和设备。实质上,本发明提出了利用诸如工作站或个人计算机之类的典型终端用户设备中的智能进行分布式呼叫处理的技术。
计算机-电话集成正在快速开发利用众所周知的现有网络(如电话网)和新的正在快速发展的数据网(如因特网)的各种应用。
电话要求用实时信道来提供所需的即时直接语音通信,这使电话具有相当的吸引力。今天,电话技术近必需提供一定的补充业务。这些补充业务按传统方式是由连接用户的称为PBX(专用小交换机)的电话交换机实现的。补充业务的一些例子有交替呼叫(Alternate Call)这种补充业务可以使用户保持当前对用户B的有效呼叫而发起对用户C的呼叫或激活先前保持着的对用户C的呼叫;回叫(Call Back)这种补充业务使用户A在呼叫用户B而发现用户B正忙时可以请求用户B回叫;保留呼叫(Camp on Call)用户A在呼叫用户B而发现用户B正忙时可以利用这种补充业务使得这个呼叫在用户B一空闲时再立即发起;转叫(Deflect Call)这种补充业务使一个用户可将入呼转至另一个用户或电话机;呼叫转移(Call Transfer)这种补充业务使用户A可将他的两个呼叫(与用户B和C)转成用户B和用户C之间的呼叫;呼叫代接(Directed Pickup Call)在用户A呼叫B而呼叫处于振铃状态时,这种补充业务使第三个用户C在不同终接位置上应答这个呼叫;多线型(Multi-line/Appearance)这种补充业务使一个呼入可在两个或更多个用户上振铃,而第一个应答的用户获得这个呼叫;以及不许呼叫打搅(Call do not Disturb)这种补充业务使用户可拒绝所有的呼入。
如上所述,这些补充业务按传统方式在交换机(或PBX)上实现。这种PBX通常位于用户的房屋内并且与公共电话网相联。
随着允许进行数字数据的交换和传输,包括可以在电话上使用的数字化语音的实时交换的新的通用的网络如因特网或ATM(异步传输模式)网的出现,传统的电话系统面临挑战。然而,当使用这些新型的传输工具时,这些通常在PBX上实现的补充业务变得不再适用了。
由于语音传输比数据传输对即使最小的延迟也更敏感,所以计算机一网络电话需要更加复杂的传输管理。在现有的电话网上的传统呼叫控制不适合于为数据网提供此业务。
此外,PBX使用集中化的方法解决如呼叫的发起及终止等基本电话业务和补充业务。由于要完成很多功能,PBX通常是复杂而且昂贵的。PBX将终端用户设备(如电话装置)当作专门用于电话的简单设备处理。随着功能强大的工作站的广泛出现,使用它们的功能提供至少这些电话业务的一部分功能及将计算机与电话集成成为越来越有吸引力。
关于计算机与电话集成的一些方法已由James Burton于1995年9月在BYTE上“标准问题(Standard Issue)”这篇论文的201页到207页中论述了。Burton提出了几种CTI(计算机一电话集成)的体系结构和其有特色的布局。由Burton所列的体系结构为语音及控制数据在至少局部相同的联接上的联合传输作准备,并且该体系结构是基于联接到电话网或PBX的连通性的。终端用户工作站的功能并不是为基本或补充电话业务而开发的。
由Hornburger等人发明的US专利4 634 812揭示了在分散的电话控制系统中的计算机之间传输包括语音在内的信息的一种方法。这个系统提供传输数据以及语音的多线型总线及二个单线型控制总线。根据Hornberger专利的电话系统包括一些被二条控制总线和一条数据/语音多线型总线所连接的相同的PBX。因此,这个系统通过多条并行信道和专门设计的PBX在电话系统中提供分布式控制。这是一个为PBX专门设计的可以说是配套(self--contained)的系统,但是没有阐述将终端用户工作站的功能用到基本电话业务和补充业务上的想法。
由Jabara等人发明的US专利4 313 036描述了分布式的计算机化的PBX系统,也可称为CBX系统,其中各CBX是由语音网和分组交换网连接的。在这些CBX之间提供了二条链路或信道一条是信令数据链路,一条是语音链路。数据链路是可以由分组交换网所提供的虚拟网络的一部分。然而,这个系统关心的是为控制目的而在PBX之间进行的通信,并没有说明最终端用户工作站用于基本电话业务和补充业务的可能性。
已经提出了各种使用因特网进行电话业务的系统。这样的一种系统已经通过统一资源定位器(Universal Resource Locator)(URL)http//www.vocaltec.com网址在万维网(WWW)上做宣传。可以在URLhttp//vvv.northcoast.com/~savetz/voice-faq.html网址上找到带有更多参考资料的这种系统的其他概述。在网上描述的为了实现功能有限的基本电话业务而开发用户工作站功能的系统既没有说明也没有提供实现补充业务的方法。
本发明的一个目标是为电话系统提供一种面向工作站的在工作站之间有多条链路的分布式体系结构,以及提供一种不仅提供如呼叫发起及终止等基本电话业务功能,而且提供复杂的补充业务功能的方法。
另外一个目标是提供非集中交换的使用已有的网络,最好是分组交换网的分布式体系结构的电话系统,实现所需的基本和/或补充业务。
本发明提供了一种使用已有的网络底层结构实现电话尤其是复杂的补充业务功能的解决方法。通过使用一种面向工作站的体系结构,本发明提供了有效并且通用的实现任何所要求的补充业务功能的工具,在任何时候只需花最小的精力,并且实际上没必要干扰已有的网络体系结构和/或已经使用的协议的前提条件下,即可改变该工具使其适应。
简单地说,实现本发明所提到的一般是在交换机(PBX)上实现的基本的和补充的电话业务功能的面向工作站的分布式体系结构包括建立传输第一信号的第一通信信道和传输第二信号的第二通信信道,这两个信道都直接连接到终端用户设备如工作站上。最好第一信号是控制信号,而第二信号是语音信号。可以直接并且独立地建立两个(或多个)连接或信道,第二或语音信道最好在第一或控制信道设置之后再设置。控制信道一旦建立,最好在通信会话期间永久地保持。因此会话可以在语音连接上有中断或暂停,只要确认需要继续电话通信。
采用本发明,电话业务可以只在工作站上实现;为了实现数量有限的功能,如地址分辨或鉴权,服务器的使用可能是需要或有利的。交换机PBX,假如真正要使用的话,则只需要提供语音和/或实时数据传输的通信信道。在业务的实现中并不涉及这些交换机。
本发明的详细信息可从以下最佳实现的一般和详细的描述中获得。


图1是使用本发明的一种可能配置的概况;图2提供了本发明的总体功能;图3例示了本发明实现的呼叫过程;图4例示了本发明实现的回叫过程;图5例示了本发明实现的呼叫转移过程;图6示出了一种实现的参考体系结构,及图7示出了基于本发明的另一种参考体系结构。
A.总的描述A.1.概述图1显示了能够应用本发明的总体配置的例子。可以是作为通常用于数据传输的现有数字网的例子的ATM网或IP(网间协议)网的网络1连接3a到3d的工作站(WS)。连接到网络1的还有电话服务器(TPS)2。为了实现与PBX 4的通信,第一个网关(GW)5连接到网络1。第二个网关7将网络1连接到ISDN(综合业务数字网)6。PBX 4及ISDN 6分别连接到普通电话8及9和/或允许接电话的合适的工作站。
图1中的不是本发明的一部分的网关,支持与ISDN和/或已有的PBX的互通。网关在技术上能够提供信令互通(ISDN/PBX信令和在分布式体系结构即面向工作站体系结构中使用的信令的映射),语音信号翻译(在ISDN/PBX中使用的语音编码格式与在分布式体系结构中使用的语音编码格式之间)和/或ISDN/PBX用户的代理功能。
图1中的虚线说明了在用户3a到3d,8和9之间的电话呼叫;实线指出与网络的连接。图2中的下列描述使得这些细节问题更明白。
图2表示了本发明的基本配置及必要的数据流程概况。本发明使用分布式的面向工作站体系结构,下面通过对本发明实施例的详细描述将使得该体系结构更明白。
新型的体系结构的一个关键是在每一个电话呼叫的工作站之间使用两个独立的首尾相接的信道。如图2所示,工作站到工作站的控制信道12是用于呼叫控制,语音信道13是用于语音通信的。工作站A和B在控制信道12上交换控制消息。这些消息可能包含呼叫以及被叫用户的名字或电话号码,符合条件的业务参数(如工作站支持的或用户认为最佳的语音编码模式),呼叫的状态信息(如呼叫是有效的还是保持的),以及用户的特殊请求(如将用户放入回叫表)。在控制信道12上传输的所有消息由工作站上的过程处理;不会被为这些信道提供方便的交换机或路由选择器(图3和图4)所中断。
本发明的另一个关键是控制信道12在呼叫的过程中要保持着,而语音信道13不必永久地保持,只在需要时才被建立。例如,当呼叫保持时语音信道13可被释放,当呼叫又被激活时重新建立语音信道13。由于在保持着的工作站到工作站的控制信道12上允许交换任何控制信号或消息,所以可以实现大量的各种补充电话业务而不需涉及到交换机或路由选择器。
电话服务器2可以执行如登记名字/电话号码,地址分辨及鉴权等功能。工作站在独立的工作站-服务器控制信道10及11上请求服务器2服务。这些控制信道在需要时才建立。总的情况就是这些。
由于上面提到的任何信道,控制信道10,11,或12及语音信道13分别可由已有的网如ATM或IP网所提供,所以本发明几乎可在任何已有的及正在发展的数据网上实现基本电话业务(如呼叫发起及终止)和补充电话业务。
下列是根据本发明实现的一组功能的更加全面的描述;对于熟悉此领域的技术人员,这就足以实现本发明。下面将更加详细地说明这些功能的子集。
A.II基本电话业务1.呼叫的发起及接收图3示出了此过程。用户A希望发起一个对用户B的呼叫;每个用户分别在图1所示工作站3a到3d中的某一个上。
步骤1用户A的工作站(WS A)将用户B的名字或电话号码地址映射到用户B的工作站(WS B)的网络地址上。这种“地址映射”功能由电话服务器2上运行的适当的服务器过程提供。
步骤2工作站A建立一个到工作站B的控制信道(如图2中的12)。
步骤3工作站A在控制信道上发送“呼叫请求”消息给工作站B。
步骤4工作站B返回“呼叫确认”消息给工作站A,告诉工作站A工作站B可以处理呼叫发起。
步骤5工作站B指示用户B有一个呼入。
步骤6用户B响应正在回答的呼叫。
步骤7工作站B在控制信道发送“连接”消息给工作站A,告诉工作站A用户B正在回答呼叫并且要求工作站A建立一个语音信道。
步骤8工作站A建立一个到工作站B的语音信道。
步骤9工作站B向用户B指示呼叫现在有效。
步骤10工作站A向用户A指示呼叫现在有效。
步骤11用户A及用户B在语音信道上交谈。
2.呼叫终止在任何时候用户A或用户B都可以请求呼叫终止。假设呼叫终止是由用户A提出的。步骤如下步骤1工作站A在控制信道上发送“终止呼叫”消息给工作站B,并且释放呼叫的语音信道。
步骤2工作站B返回“终止呼叫”消息给工作站A,并且也释放语音信道。
步骤3工作站A释放呼叫的工作站-工作站控制信道,完成呼叫终止。
A.III.补充业务1.交替呼叫在某一时刻,用户A有两个或多个正在进行的呼叫,这些呼叫中的某一个(到用户B)是有效的,而其它的呼叫是被保持的。假设用户A希望到用户B的呼叫保持而激活到用户C的呼叫。步骤如下步骤1工作站A在其与工作站B的控制信道上发送“保持”消息给工作站B,告诉工作站B呼叫现在保持。
步骤2工作站A在其与工作站C的控制信道上发送“有效”消息给工作站C,告诉工作站C呼叫现在有效。
2.回叫在呼叫发起的过程中,工作站A在控制信道上的初始消息交换中发现用户B正忙。用户A请求回叫。步骤在图4中示出。
步骤1到3与发起一个呼叫中的这些步骤一样(参看前面结合图3所述的发起及接收呼叫)。
步骤4工作站B以“用户忙”消息响应。告诉工作站A用户B正忙但可以回叫。
步骤5用户A请求将它列入用户B的回叫表。
步骤6工作站A在控制信道上发送“回叫请求”消息给工作站B。此消息包含用户A的电话号码。
步骤7工作站B将用户A的电话号码输入到用户B的回叫记录中。
当用户B其后检查回叫记录时,他/她将知道用户A已经请求回叫。
3.保留呼叫(Camp on Call)除了只要B一成为空闲,必须试图重新呼叫用户B以外,其它的类似于前面回叫过程。
步骤1到3与发起和接收呼叫的这些步骤一样。
步骤4工作站B以“用户正忙”消息响应,告诉工作站A用户B正忙,而保留呼叫是可能的。
步骤5用户A请求保留呼叫。
步骤6工作站A在控制信道上发送“保留呼叫”消息给工作站B。
步骤7工作站B返回“保留确认”消息给工作站A。
步骤8当用户B成为空闲并且指出用户B正在回答保留呼叫时,工作站B在图3所示的步骤7上重新开始与工作站A的呼叫发起过程。
4.转叫用户B可以希望将一个呼入立即转至另一个电话号码(电话号码M),或者假如他/她正忙,或者假如在一个规定的时限超过以后呼叫还没有被回答时将呼入转至另一个电话号码(电话号码M)。假设用户A正在发起一个对用户B的呼叫,在超时以后转叫这种情况的处理步骤如下步骤1到5与发起和接收呼叫的这些步骤一样。
步骤6用户B在超时后还没有回答。
步骤7工作站B在控制信道上发送“转叫”消息给工作站A。这个消息包含了呼叫需转至哪个电话号码(电话号码M)。
步骤8工作站B释放到工作站A的控制信道。
步骤9工作站A对电话号码M发起呼叫。
5.呼叫转移假如用户A有两个正在进行的呼叫一个是与用户B的被保持的呼叫,另一个是与用户C的有效呼叫。用户A请求使用户B与用户C连接,而终止他/她对这两个用户的呼叫。图5示出了此过程。步骤是步骤1工作站A在至工作站C的控制信道上发送“保持”消息给工作站C。
步骤2工作站A在至工作站C的控制信道上发送“接收转移呼叫”消息给工作站C,请求工作站C接收来自工作站B的转移呼叫。
步骤3工作站C返回“转移确认”消息给工作站A,并且等待工作站B的转移呼叫。
步骤4工作站A在其与工作站B的控制信道上发送“发起转移呼叫”消息给工作站B,请求工作站B向工作站C发起转移呼叫。
步骤5工作站B返回“转移确认”消息给工作站A。
步骤6工作站B向工作站C发起转移呼叫。
步骤7工作站A终止对工作站B的呼叫。
步骤8工作站A终止对工作站C的呼叫。
6.呼叫代接假设用户A呼叫用户B并且呼叫正在振铃状态。第三个用户C希望回答此呼叫。步骤如下步骤1工作站C建立至工作站B的控制信道。
步骤2工作站C发送“代接查询”消息给工作站B,并且查明呼叫代接(pickup)是否可能。用户C的电话号码包含在此消息中。
步骤3工作站B返回“代接允许”消息给工作站C。
步骤4工作站C发送“代接请求”消息给工作站B,请求呼叫代接。
步骤5工作站B发送包含用户C的电话号码的“代接”消息给工作站A,指示工作站A发起对用户C的呼叫。
7.多线型假设用户A发起对一个多线型电话号码的呼叫。工作站A将目标电话号码映射到网络地址列表上。这个“地址映射”功能是由电话服务器上运行的服务器处理过程所提供的。工作站A将单独的呼叫发至这些地址中的每一个。工作站A将处理第一个回答的目标地址。并且终止对其它地址上的呼叫。
8.不许呼叫打扰假设用户B请求了不许呼叫打扰。任何试图对用户B呼叫的工作站A将在控制信道上得到“不许打扰”的答复消息。
B.特殊功能的详细描述B.1.参考体系结构图6及图7显示了应用本发明的通信系统的参考体系结构。在工作站的启动层上可实现基本电话业务(主要是呼叫建立,呼叫终止)及补充业务(例如呼叫保持,呼叫返回,呼叫转移,转叫)。集有地址分辨,语音编码及鉴权等功能。
直到现在,用户是由名字或电话号码识别的。在下面,用户将由他门各自的e-mail地址识别。
图6示出了本发明在ATM(异步传输模式)环境下的体系结构。物理层18及ATM层17具有标准的设计特性。TCP(传输控制协议)连接是在IP,即互连网协议15上建立的,在AAL5即ATM适配层16上面运行。在ATM网上实现IP在现时(off-the-shelf)是可实现的。
语音通信要求QoS(业务质量)保证不受传输业务接口14的如可接受的点到点的延迟及延迟抖动的影响。语音信道是由一个保证QoS的VCC(虚拟信道连接)建立的。编码的语音样值是以ATM信元发送的。Q.2931及SAAL(信令ATM适配层)是用于VCC建立和释放的信令协议。传输业务接口14为语音及控制信道提供传输。
启动层(enabling)19使用由传输业务接口14提供的业务建立控制信道及语音信道。特别地,工作站到服务器及工作站到工作站的控制信道如部件(block)15所指出的那样是由TCP连接所实现的。启动层19支持可用于电话应用开发的API(应用程序接口)。
图7叙述了本发明在IP(网间协议)环境下的体系结构。物理层是能够提供所要求的业务的IP子网技术26。由于一个RSVP流是单方向的,所以语音信道的QoS可以由一对RSVP(资源保存协议)流提供。通过使用TCP/UDP协议24及传输业务接口23将编码的语音样值以UDP(用户数据报协议)分组发送。在此例子中,RSVP是用于工作站及路由选择器之间建立必要的RSVP流的信令协议。
在这样一个IP子网中,编码的语音分组也可以在没有RSVP的情况下以UDP分组传输。这是尽力而为的业务,不保证QoS。传输业务接口23为语音及控制信道提供传输能力。启动层22支持用于开发电话应用的API 21。本发明的功能就这么多。某些功能将在下面进一步详细地描述以便于理解本发明。
下面将仍然使用在前面已经介绍的简写如流程图中所示的WS表示工作站,WSA表示用户A的工作站。
在WS-服务器和WS-WS控制信道上交换的控制消息用于实现基本和补充业务。这些控制信道是由TCP连接实现的。
每一个控制消息包含指出控制消息名字及可任选的一个参数表(这个表可以是空的)的代码。为了方便起见,一个控制消息是如下表示的消息名(参数表)在基本及补充业务如何实现的描述中将使用这种标法。另外,为了不包含不必要的细节,只有与正在被描述的过程相关的参数才被列出。
在实现过程的描述中用到一些定时器。这些定时器如下操作。在定时器的定时期满之前当某一预计的事件发生时停止定时器。不管什么理由,假如定时器定时期满,则必须进行恢复工作。
在实现过程的描述中,除非另外特别说明,恢复工作是指使用下面B.II.2节中描述的终止电话呼叫过程。
B.II.基本电话业务基本电话业务包括呼叫发起及呼叫终止。
1.呼叫发起假设在工作站A的用户A(WS A)希望发起一个对工作站B的用户B(WS B)的呼叫并且用户B正好空闲可以接收呼叫。图3使用A.II节中的一般术语示出了其基本步骤。在WS A及WS B上实现的细节如下。
步骤1WS A将用户B的e-mail地址映射为WS B的TCP地址。
WS A过程当从用户A接收到呼叫发起请求时,WS A建立与电话服务器的TCP连接。此连接将被用作WS-服务器的控制信道。TCP连接的建立是众所周知的过程。WS A准备地址查询(AdrQuery)(用户B的e-mail地址)控制消息并发送此消息给电话服务器。
电话服务器当接收到地址查询控制消息时检查地址映射数据库。假如可找到用户B的e-mail地址的入口(entry),则电话服务器准备地址响应(AdrRsp)(用户B的TCP地址)控制消息,并且将此消息返回给WSA;否则,准备地址响应消息(用户B没有登记)并且返回该消息。在此两种情况发生时,释放WS A与电话服务器之间的TCP连接。由电话服务器完成的地址映射功能可以由可行的命名服务器(nameserver)技术如因特网域名系统来实现。
当从电话服务器中接收到地址响应(AdrRsp)控制消息时,WS A解释消息内容。假如WS B的TCP地址作为参数被包含,则WS A转到呼叫发起的步骤2开始处理。另一方面,假如指出“用户B没有登记”,则WS A将此指示告诉用户A结束呼叫发起。
步骤2WS A建立到WS B的WS--WS的控制信道。
WS A过程WS A建立到WS B的TCP连接。该连接将被用作WS A与WSB之间的WS--WS的控制信道。WS A转到呼叫发起的步骤3开始处理。
WS B过程作为WS A建立TCP连接动作的结果,WS B完成连接建立并且启动定时器TB1。
步骤3WS A发送“呼叫请求”控制消息给WS B。
WS A过程WS A准备呼叫请求(CallReq)(用户A的e-mail地址,用户B的e-mail地址)控制消息,发送此消息给WS B并且启动定时器TA2。
步骤4WS B返回“呼叫确认”控制消息给WS A,告诉WSAWS B能够处理呼叫发起。
WS B过程当从WS A接收到呼叫请求(CallReq)控制消息时,WS B停止定时器TB1,并且检查用户B的e-mail地址是否与呼叫请求控制消息中包含的地址匹配。假如检查是匹配的并且用户B是空闲的,则WS B准备呼叫确认(CallCnf)(B空闲)控制消息,并且将此消息返回给WSA。WS B转到步骤5开始处理。
另一方面,假如检查是不匹配,则WS B使用在B.II.2节中描述的过程终止呼叫发起。
WS A过程当从WS B中接收到呼叫确认控制消息时,WS A停止定时器TA2并且启动另一定时器TA3。
步骤5WS B指示用户B有一个呼入。
WS B过程WS B告诉用户B有一个呼入并且启动定时器TB4。
步骤6用户B对其正在回答的呼叫作出响应。
WS B过程WS B停止定时器TB4并且转到步骤7开始处理。
步骤7WS B告诉WS A用户B正在回答呼叫并且要求WS A建立语音信道。
WS B过程WS B准备连接控制消息,发送此消息给WS A并启动定时器TB5。
步骤8WS A建立到WS B的语音信道。
WS A过程当从WS B中接收到连接控制消息时,WS A停止定时器TA3并且建立到WS B的语音信道。此连接将在用户A和用户B之间电话交谈时使用。实现语音信道的建立将在B.II.1.1节中描述。
步骤9WS B指示用户B呼叫现在有效。
WS B过程当从WS A中接收到建立语音呼叫的请求时,WS B完成语音信道的建立,停止定时器TB5并且告诉用户B呼叫有效。
步骤10WS A指示用户A呼叫现在有效。
WS A过程WS A告诉用户A呼叫有效。
步骤11用户A与用户B在语音信道上交谈。
WS A过程在电话交谈的过程中,WS A准备包含来自用户A的编码语音样值的语音消息并且在语音信道上将这些消息发送给WS B。WS A将从WS B接收的语音消息中包含的语音样值解码。
WS B过程在电话交谈的过程中,WS B准备包含来自用户B的编码语音样值的语音消息并且在语音信道上将这些消息发送给WS A。WS B将从WS A接收的语音消息中包含的语音样值解码。
1.1.建立语音信道在呼叫建立的过程中商定将被使用的语音信道的类型。语音信道的类型包括ATM(异步传输模式),RSVP(资源保存协议)或尽力而为的UDP(用户数据报协议)。ATM及RSVP支持保证业务质量,而尽力而为的UDP不支持保证业务质量。尽力而为的UDP是缺省的类型。该商定的实现过程如下。
在呼叫发起的步骤3上(图3),WS A发送呼叫请求控制消息给WS B。与商定相关的参数是WS A的最佳语音信道类型,以及与语音信道建立相对应的地址信息。假如不是最佳语音信道类型,则用于尽力而为的UDP的地址信息作为参数被包含。
在呼叫发起的步骤4中假如WS B也具有相同类型的通路,则WS B确认将使用由WS A提出的语音信道,否则WS B确认将使用尽力而为的UDP(缺省)。在WS B发送到WS A的呼叫确认控制信息中,相关的参数是确认的语音信道类型和用于语音信道建立相对应的地址信息。
在呼叫发起的步骤8中WS A建立到WS B的语音信道。为ATM和RSVP规定了标准协议,因此该建立过程是由熟悉的过程实现的。因为UDP是一个数据报协议,所以对尽力而为的UDP来说没必要建立语音信道。
2.呼叫终止在任何时候,用户A或用户B可以请求呼叫终止。由于定时器超过了规定时限,也可以激活呼叫终止。假设WS A要激活呼叫终止。步骤如下步骤1WS A告诉WS B要呼叫终止。
WS A过程WS A准备呼叫终止(TermCall)控制消息并且将此消息发送给WSB。WS A停止任何正在运行的定时器,释放呼叫的任何已有的语音信道,并且启动定时器TA6。由熟悉的过程实现释放ATM及RSVP语音信道类型。因为UDP是一个数据报协议,所以对尽力而为的UDP来说没必要释放语音信道。
在来自WS B的终止呼叫控制消息被接收之前,假如TA6超过了规定的时限,则WS A通过释放到WS B的WS--WS控制信道完成呼叫终止。
步骤2WS B告诉WS A呼叫已终止。
WS B过程当从WS A中接收到终止呼叫控制消息时,WS B停止任何定时器,释放呼叫的任何已有的语音信道,准备终止呼叫控制消息,发送此消息给WS A并且释放到WS A的WS--WS控制信道。
步骤3WS A完成呼叫终止。
WS A过程当从WS B中接收到终止呼叫控制消息时,WS A停止定时器TA6并且释放到WS B的WS--WS控制信道。
B.III.补充业务下面描述了补充业务的一些实现方法。如上所述,本发明的一个关键问题是能在呼叫过程中保持的WS--WS控制信道上交换控制信息。首先应该定义控制消息的两种类型。紧接着描述三种示范性补充业务的实现过程。
1.控制消息的定义1.1.用于表示保持或激活呼叫的状态控制信息当呼叫处于“有效”状态时,用户可以在语音信道上完成交谈。另一方面,当呼叫处于“保持”状态时,用户之间的交谈被挂起。状态控制信息被定义用于支持状态的改变。
状态(保持)告诉远程的WS呼叫的状态已经改为“保持”。
状态(有效)告诉远程的WS呼叫的状态已经改为“有效”。
1.2.补充业务控制消息下列四个控制消息被定义用于支持实现各种补充业务。
SS信息(SSInfo)此消息用于告诉远程WS关于启动一个确定的SS(补充业务)的可能性。
SS请求(SSReq)此消息用于请求远程WS完成与确定的SS相关的动作。
SS确认(SSCnf)对SS请求消息作出响应,发送此消息用于确认远程WS已经请求的SS的处理过程。
SS拒绝(SSReject)对SS请求作出响应,发送此消息用于拒绝远程WS已经请求的SS的处理过程;此消息包含拒绝的理由。
可在呼叫确认控制信息之后(参看图3的呼叫分配步骤4)及终止呼叫控制信息之前(参看呼叫终止的步骤1)的任何时候发送上述SS信息。
2.补充业务的工作站过程在这一节中,将描述三种补充业务的实现细节。这些例子说明了将如何使用本发明。在这些例子和上面总的描述的基础上,熟悉本领域的技术人员可以很容易地实现其他的补充业务。
2.1.交替呼叫在任何时刻,用户A可能有两个或多个正在进行着的呼叫。这些呼叫中的一个(到用户B)是有效的,而其他是保持的。假设用户A请求保持对用户B的呼叫而激活对用户C的呼叫。交替呼叫的补充业务按下列步骤实现步骤1WS A告诉WS B呼叫已经被保持。
WS A过程当从用户A接收到请求时,WS A将与用户B的呼叫的状态改为“保持”,将呼叫的语音信道与语音子系统断开,准备状态(保持)控制消息,并且发送给WS B。
WS B过程当从WS A中接收到这个状态消息时,WS B将与WS A的呼叫的状态改为“保持”并且将此呼叫的语音信道与语音子系统断开。
步骤2WS A告诉WS C呼叫已经被激活。
WS A过程WS A将与WS C的呼叫的状态改为“有效”,将此呼叫的语音信道连接到语音子系统上,准备状态(有效)控制消息并把此信息发送给WS C。
WS C过程当接收到这个状态信息时,WS C将与WS A的呼叫的状态改为“有效”并且将此呼叫的语音信道连接到语音子系统上。
2.2.回叫图4使用A.III节中的一般术语叙述了此处理过程。假设用户B有一条WS B保持的“回叫”记录。任何主叫用户A可以请求将其e-mail地址输入到此记录中,请求用户B在方便时回叫。在呼叫发起的过程中在用户B正忙或没有回答的情况下,发出此请求。在用户B正忙的情况下回叫的补充业务按如下步骤实现(参见图4)。
步骤1到3WS A和WS B的过程与呼叫发起(参见B.II.1节)中这些过程相同。
步骤4WS B返回“呼叫确认”控制消息给WS A,告诉WSA用户B正忙,而且可以回叫。
WS B过程当从WS A中接收到呼叫请求控制消息时,WS B停止定时器TB1并且检查用户B的e-mail地址是否与呼叫请求控制消息中包含的地址匹配。假如是匹配的而且用户B正忙,则WS B准备呼叫确认(用户B正忙,回叫记录)控制消息,返回此消息给WS A并启动定时器TB4。
WS A过程当从WS B中接收到呼叫确认控制消息时,WS A停止定时器TA2,告诉用户A用户B正忙,而且可以回叫,并且启动定时器TA3。
步骤5用户A请求将其放到用户B的回叫记录中。
WS A过程WS A停止定时器TA3并且转到步骤6开始处理。
步骤6WS A发送SS请求控制消息给WS B。
WS A过程WS A准备SS请求(回叫请求,用户A的e-mail地址)控制消息,发送此消息给WS B并且启动定时器TA5。
步骤7WS B将用户A的e-mail地址输入用户B的回叫记录。
WS B过程当从WS A中接收到SS请求消息时,WS B停止TB4,将用户A的e-mail地址输入用户B的呼叫返回记录。准备SS确认(回叫确认)消息并且返回此信息给WS A。WS B也启动定时器TB6。
定时器TB6在步骤8上(参见B.II.2节)作为由WS A激活的呼叫终止的一部分而被停止。
步骤8WS A终止呼叫发起。
WS A过程当从WS B中接收到SS确认控制消息时,WS A停止定时器TA5并且激活在B.II.2节中描述的呼叫终止的过程。
2.3.呼叫转移图5使用A.III节中的一般术语显示了此过程。假设用户A有两个呼叫正在进行中一个是与用户B的被保持的呼叫,另一个是与用户C的有效呼叫。用户A请求使用户B与用户C连接并且终止对此两个用户的呼叫。呼叫转移补充业务的实现细节描述如下。为了便于说明,虽然没有提到被使用的任何定时器,但它们的用法与呼叫发起(B.II.1节)和回叫(B.III.2节)中描述的类似。
步骤1WS A使与WS C的呼叫保持。
WS A过程当从用户A中接收到呼叫转移请求时,WS A将与WS C的呼叫状态改成“保持”,将此呼叫的语音信道与语音子系统断开,准备状态(保持)控制消息并发送此消息给WS C。
当WS C接收到这个状态控制消息时,WS C将与WS A的呼叫的状态改为“保持”,并且将此呼叫的语音信道与语音子系统断开。
步骤2WS A请求WS C接收转移呼叫。
WS A过程WS A准备SS请求(接收转移呼叫,用户B的e-mail地址)控制消息并发送此消息给WS C。
步骤3WS C确认转移请求。
WS C过程当从WS A中接收到SS请求控制消息时,WS C准备SS确认(转移确认)控制消息并发送此消息给WS A。WS C也保存用户B的e-mail地址并进入“等待转移”状态。
当处于“等待转移”状态时,WS C只接受来自WS B的呼叫请求(转移呼叫)控制消息所发起的呼叫。所有其他呼叫请求控制消息将被一个呼叫确认(用户C正忙)响应。
步骤4WS A请求WS B发起转移呼叫。
WS A过程当从WS C中接收到SS确认控制消息时,WS A准备SS请求(发起转移呼叫,用户C的e-mail地址)控制消息并发送此消息给WS B。
步骤5WS B确认转移请求。
WS B过程当从WS A中接收到SS请求控制消息时,WS B准备SS确认(转移确认)控制消息并发送此消息给WS A。
步骤6WS B发起转移呼叫给WS C。
WS B过程WS B使用在B.II.1节中描述的过程发起对WS C的“转移”呼叫。
步骤7WS A终止与WS B的呼叫。
WS A过程当从WS B中接收到SS确认控制消息时,WS A使用在B.II.2节中描述的过程为与WS B的呼叫激活呼叫终止。
步骤8WS A终止与WS C的呼叫。
WS A过程WS A使用在B.II.2节中描述的过程为与WS C的呼叫激活呼叫终止。
上述对实现过程的描述显示了在电话系统中如何设计业务体系结构,该体系结构以新型的方法将计算机与电话集成在一起,以便充分利用现代工作站和个人计算机的计算功能和多用性及连接全球的快速发展的数据网。当然,上述实施例的描述仅仅说明了本发明的原理和在著名的以有网络如因特网和ATM网及正在开发的新的数据网上的各种应用,熟悉本领域的技术人员在没有违背本发明的构思下,在上述说明的基础上可以很容易地进行各种改变。
权利要求
1.实现和/或控制通过网络(1,4-6)连接的至少两个用户之间的电话连接的方法,包括在终端用户设备(3a-3d)之间建立第一通信信道(12),每一个所述的设备与所述的其中一个用户相关连,传输第一信号,在所述的终端用户设备(3a-3d)之间建立第二通信信道(13)用于传输第二信号,所述的第一个和第二通信信道相互独立。
2.根据权利要求1的方法,其中在终端用户设备(3a-3d)之间交换的第一信号是控制信号,而第二个信号是语音信号,最好是编码的语音信号。
3.根据权利要求2的方法,其中在终端用户设备(3a-3d)之间交换的控制信号包括提供和/或实现基本电话业务和/或补充电话业务的信号。
4.根据权利要求3的方法,其中在终端用户设备(3a-3d)之间交换的控制信号基本上由所述设备或其内部产生的,从而由所述终端用户设备实施所需的信道建立和控制功能。
5.根据前面的任何一项权利要求的方法,其中除了通信信号以外,在终端用户设备(3a-3d)中还实现语音传输功能,尤其是编码/解码功能。
6.根据权利要求1的方法,其中两个信道(12,13)中的每一个透明地,独立地,并且直接地连接到正在通信的或希望通信的用户的终端用户设备(3a-3d)。
7.根据权利要求1的方法,其中第一通信信道(12)在电话会话过程中基本上永久地保持,而第二通信信道(13)被设计成允许间断性操作。
8.一种在一个分散的网络(1)上实现和/或控制至少两个终端用户设备(3a-3d)之间的电话的分布式系统,其中所述终端用户设备(3a-3d)中至少有一个包括在所述终端用户设备(3a-3d)之间直接建立传输第一信号的第一通信信道(12)的装置,并且所述终端用户设备(3a-3d)中至少有一个包括在所述终端用户设备(3a-3d)之间直接建立传输第二信号的独立第二通信信道(13)的装置。
9.根据权利要求8的系统,其中终端用户设备(3a-3d)中的所述装置允许其中一个信道间断性操作而另一个信道基本上要永久地保持。
10.根据权利要求8的系统,其中终端用户设备(3a-3d)中的所述装置用于产生和/或解释在所述终端用户设备之间建立的其中一个信道上交换的控制信号,以便实现基本的和/或补充的电话业务。
11.根据权利要求8的系统,其中终端用户设备(3a-3d)中的所述装置用于处理和/或解释在所述终端用户设备之间建立的其中一个信道上交换的语音信号,以便在所述终端用户设备(3a-3d)之间实现语音电话。
12.根据权利要求8的系统,进一步包括电话服务器(2),用来实现所需的中心功能,尤其是用户和接入控制功能,所述电话服务器被用于与每一个终端用户设备(3a-3d)的基本上直接和独立的通信。
13.根据权利要求8至12任何一项权利要求的系统,其中终端用户设备(3a-3d)是多用途的工作站或个人计算机。
全文摘要
本发明涉及在已有的网络如ATM网,因特网或其他数据网上启动和控制电话的方法和系统,它基本上使用典型的终端用户设备如工作站或个人计算机中的智能进行分布式控制处理。实时信道(提供必要的直接语音通信)和基本上由用户工作站(原则上不包括PBX)建立及来自用户工作站的控制信道(用于类似连接的建立和终止的基本业务及补充业务)的并行使用几乎可以实现任何可以想象的功能。
文档编号H04L29/06GK1209250SQ96180080
公开日1999年2月24日 申请日期1996年2月21日 优先权日1996年2月21日
发明者洪·林·图昂, 约翰尼·威-南格·翁 申请人:国际商业机器公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1