在分组电话网络中实现呼叫处理的方法和装置

摘要

本发明提供了在分组电话网络中进行呼叫路由、排队以及其他呼叫处理的各种方法、装置和系统。根据本发明，一种对分组电话呼叫进行呼叫处理的自动呼叫分配器系统，所述自动呼叫处理系统包括：为一个或者多个其他子系统或者端点处理呼叫控制的呼叫控制子系统；和被耦合至所述呼叫控制子系统的自动呼叫分配器应用程序，所述自动呼叫分配器应用程序控制或者协调对于分组电话呼叫的呼叫处理。

说明书

技术领域

本发明涉及在在分组电话网络中实现呼叫处理的方法和装置。

背景技术

诸如公共交换电话网(PSTN)的传统电路交换式电话系统的用户已经认识到路由和排队呼叫的需要。呼叫路由和排队一般在客户服务中心或者呼叫中心以及其他处理大量呼叫的地方进行。一般，大量的呼叫被发给经常被称为虚拟电话地址或者虚拟电话号码的单一电话号码。虚拟电话地址经常是不对应真实的提供了接收呼叫的物理设备的电话端点的电话号码。更合适地说，虚拟电话地址可以是一个在虚拟端点接收呼叫的电话号码，该虚拟端点用于将呼叫路由至另一个端点。例如，虚拟电话地址可以对应一队或者甚至一组电话端点。另一方面，真实的电话地址一般对应一个电话端点，在该电话端点诸如电话机的物理设备可以接收和发出呼叫。

自动呼叫分配器(ACD)是一般完成呼叫路由和排队功能的设备或者系统。ACD可以将呼叫路由至一个代理或者服务代表，并且/或者将呼叫排队直至服务代表可用。

以下能力是在传统电路交换式电话技术ACD中有时能发现的特征。

呼叫路由：呼叫可以被定址到虚拟电话地址，该虚拟电话地址引起例如在ACD中的具体呼叫路由逻辑在呼叫被转发给实际的电话端点之前被应用。当呼叫被定址到虚拟电话地址时，ACD一般将呼叫定向或路由至一些其他的电话地址(真实的或者虚拟的)。ACD通常基于例如ACD已知的规则、诸如日期时间和呼叫者电话地址等的呼叫特性、通过计算机电话集成(CTI)链接来自外部应用程序的命令或者用来确定关于呼叫者的身份和目的等的补充信息的与呼叫者的语音交互来路由呼叫。

呼叫排队：呼叫可以被定址到虚拟电话地址，在该地址呼叫可以在被处理之前等待可用的资源。虚拟电话地址通常是对应一队或者一组电话端点的电话地址。端点组可以是静态的或者可以实时地动态变化，例如，当客户服务代理在其移位结束之后报告工作或者离开时。端点组可以由物理电话地址组成，或者可以是由根据其身份、指派和/或技能选择的一组客户服务代表组成的虚拟的组。在虚拟电话地址接收的呼叫可以被放在队列中，直到呼叫能够被路由到适当的服务代表或者代理。

呼叫处置/处理：当呼叫在队列中等待时，可能有必要对呼叫者播放音频并且/或者接受双音多频(DTMF)音调和/或呼叫者输入的语音。这种交互可以由诸如ACD的系统或者周期性地通知呼叫者关于他们在队列中的位置、预计的等待时间以及其他信息的应用程序来控制。诸如呼叫排队、路由和呼叫作业的特征在电话系统中作为专有的能力被几乎普遍地实现。

虽然语音呼叫已经传统地在诸如PSTN的公共电路交换式网络上被传递，但是语音呼叫现在通常在诸如作示例的互联网或者互联网协议(IP)网络的分组交换网络上来传递。IP一般是指如1981年9月采用的IETFRFC 791标准5(“IP规范”)所定义的互联网协议(IP)。在IP网络上作出的电话呼叫经常被称为基于IP的语音(VoIP)呼叫或者IP电话呼叫。通常，在诸如IP网络或者互联网的分组交换网络电话上作出的呼叫在这里将被称为分组电话呼叫。在分组交换网上的语音呼叫的传输中所涉及的系统在这里将被称为分组电话系统。

呼叫路由和排队能力在分组电话系统中不常用。分组电话系统现有的实现通常延续在传统电路电话系统中使用的商业模式，即呼叫路由、排队和处理功能一般仅在专有的分组电话产品或者系统中是可用的。因而，改变产品、添加或修改特征或者向这种分组电话系统集成第三方产品会是非常困难的。

发明内容

根据本发明的第一个方面，提供了一种对分组电话呼叫进行呼叫处理的自动呼叫分配器系统，所述自动呼叫处理系统包括为一个或者多个其他子系统或者端点处理呼叫控制的呼叫控制子系统；和被耦合至所述呼叫控制子系统的自动呼叫分配器应用程序，所述自动呼叫分配器应用程序控制或者协调对于分组电话呼叫的呼叫处理。

根据本发明的另一个方面，提供了一种对分组电话呼叫进行呼叫处理的自动呼叫分配器系统，所述自动呼叫分配器系统包括：控制或者协调对于分组电话呼叫的呼叫处理的自动呼叫分配器应用程序；基于来自所述自动呼叫分配器应用程序的指令，处理一个或者多个呼叫控制功能的呼叫控制子系统；按照来自所述自动呼叫分配器应用程序的指令，对呼叫产生媒体的媒体子系统。

根据本发明的另一个方面，提供了一种包括自动呼叫分配器应用程序的装置，所述自动呼叫分配器应用程序控制或者协调对于分组电话呼叫的呼叫处理，所述自动呼叫分配器应用程序动态地产生标准语言媒体处理脚本，所述脚本被另一个设备或者子系统使用来对呼叫或者呼叫者应用媒体处理。

根据本发明的另一个方面，提供了一种装置，包括控制或者协调对于分组电话呼叫的呼叫处理的自动呼叫分配器应用程序、基于来自所述自动呼叫分配器应用程序的指令处理一个或者多个呼叫控制功能的呼叫控制子系统以及基于来自所述自动呼叫分配器应用程序的指令对呼叫产生媒体的媒体子系统，所述自动呼叫分配器应用程序通过一个或者多个基于标准的通信技术与所述呼叫控制子系统和所述媒体子系统通信。

根据本发明的另一个方面，提供了一种控制或者协调对于分组电话呼叫的呼叫路由和排队的自动呼叫分配器应用程序，所述自动呼叫分配器应用程序从呼叫控制子系统和代理端点中的至少一个接收呼叫状态信息，所述自动呼叫分配器应用程序控制所述呼叫控制子系统来路由一个或者多个呼叫，所述自动呼叫分配器应用程序产生识别要被应用于呼叫的媒体的媒体处理脚本。

根据本发明的另一个方面，提供一种控制或者协调分组电话呼叫的路由、排队以及其他呼叫处理的自动呼叫分配器应用程序，所述自动呼叫分配器应用程序从第一子系统接收关于呼叫的信息，所述自动呼叫分配器应用程序基于所述信息动态地产生标准语言媒体处理脚本。

根据本发明的另一个方面，提供了一种按照标准语言媒体处理脚本对分组电话呼叫产生媒体的媒体子系统，所述媒体子系统从另一个子系统接收所述标准语言媒体处理脚本，并按照所述脚本产生媒体，所述媒体通过网络被传递给呼叫者或者呼叫节点。

根据本发明的另一个方面，提供了一种装置，包括通过网络从子系统接收标准语言媒体处理脚本的逻辑或者软件，所述装置按照所述媒体处理脚本中的指令对呼叫者或者呼叫方在本地产生媒体。

根据本发明的另一个方面，提供了一种被耦合至自动呼叫分配器应用程序、媒体子系统以及第一子系统的装置，所述装置为虚拟端点或者其他子系统向所述第一子系统注册电话地址，所述装置向所述自动呼叫分配器应用程序提供关于分组电话呼叫或者呼叫请求的呼叫信息，并且所述装置基于来自所述自动呼叫分配器应用程序的指令控制至少一些呼叫路由功能。

根据本发明的另一个方面，提供了一种对分组电话呼叫进行处理的方法，所述方法包括接收关于呼叫或者呼叫请求的信息；基于所述信息动态地产生媒体处理脚本；向媒体子系统发送所述媒体处理脚本；所述媒体子系统按照所述媒体处理脚本中的指令，对所述呼叫产生或者应用媒体。

根据本发明的另一个方面，提供了一种处理分组电话呼叫的方法，包括为虚拟端点或者为一个或多个子系统注册一个或者多个呼叫地址；接收呼叫建立请求；基于所述注册，将所述呼叫建立请求中的呼叫地址解析为第二地址；向所述第二地址发送所述呼叫建立请求。

根据本发明的另一个方面，提供了一种处理分组电话呼叫的方法，包括为自动呼叫分配器系统的端点注册一个或者多个呼叫地址；接收呼叫建立请求；基于所述注册，将所述呼叫建立请求中的呼叫地址解析为第二地址；向所述第二地址发送所述呼叫建立请求；从对于所述呼叫的自动呼叫分配器应用程序接收指令；基于所述指令处理所述呼叫。

根据本发明的另一个方面，提供了一种处理分组电话呼叫的方法，包括通过标准协议接收呼叫建立请求；通过基于标准的通信技术通知自动呼叫分配器应用程序所述呼叫建立请求；自动呼叫分配器应用程序对于所述呼叫动态地产生标准语言媒体处理脚本；从所述自动呼叫分配器应用程序检索所述媒体处理脚本；以及根据所述媒体处理脚本对所述呼叫应用或者产生媒体。

根据本发明的另一个方面，提供了一种处理分组电话呼叫的方法，包括在呼叫控制子系统接收呼叫或者呼叫建立请求；接收来自自动呼叫分配器应用程序的指令；基于所述指令处理所述呼叫；检测呼叫者输入或者来自所述呼叫的响应；向所述自动呼叫分配器应用程序发送所述呼叫者的输入或者响应；接收来自所述自动呼叫分配器应用程序的另外的指令；基于所述另外的指令，对所述呼叫进行另外的处理。

根据本发明的另一个方面，提供了一种处理分组电话呼叫的方法，包括在呼叫控制子系统接收呼叫或者呼叫建立请求；自动呼叫分配器应用程序提供媒体处理指令；基于所述媒体处理指令，对所述呼叫应用媒体；检测呼叫者的输入或者来自所述呼叫的响应；向所述自动呼叫分配器应用程序发送所述呼叫者的输入或者响应；所述自动呼叫分配器应用程序提供另外的媒体处理指令；以及基于所述另外的媒体处理指令，对所述呼叫进行另外的处理。

根据本发明的另一个方面，提供了一种处理分组电话呼叫的方法，包括接收呼叫或者呼叫建立请求；自动呼叫分配器应用程序产生媒体处理指令；在网络上向呼叫节点发送所述媒体处理指令；以及所述呼叫节点基于所述媒体处理指令，在本地应用或者产生媒体。

根据本发明的另一个方面，提供了一种方法，包括接收来自呼叫节点的请求；响应所述请求产生标准语言媒体处理脚本；在网络上对所述呼叫节点提供所述媒体处理脚本；所述呼叫节点基于所述媒体处理脚本在本地产生媒体。

附图说明

被看作本发明实施例的主题在本发明的权利要求部分中被具体地指出和清楚地要求。关于构成和操作方法两者的本发明的实施例，与其目的、特征和优点一同，当与附图一起阅读时，可以通过参考下面详细的描述被极好地理解，其中：

图1举例说明适于实行本发明一个示例实施例的系统。

图2是举例说明根据示例实施例的系统100的操作的流程图。

图3是举例说明根据示例实施例可能被执行的若干呼叫处理的示例的示图。

图4是举例说明根据示例实施例对于一个呼叫的媒体处理应用程序的流程图。

图5是举例说明根据另一个示例实施例的系统的操作的流程图。

具体实施方式

应该知道说明书中对“一个实施例”或者“实施例”的任何提及意思是被描述的与实施例有关的具体特征、结构或者特点被包括在至少一个本发明的实施例中。“在一个实施例中”或者在说明书各种地方的类似用语的出现未必都是指相同的实施例。

许多具体的细节在这里可能被提出以提供对本发明实施例的彻底的理解。但是，本领域的一般技术人员应理解，没有这些具体的细节，本发明的实施例也可以实行。其他情况中，公知的方法、步骤、组件以及电路没有被详细地描述，以免混淆本发明的实施例。能够理解，这里公开的具体的结构上和功能上的细节可以是代表性的并且未必限定本发明的范围。

用于在分组电话网络中实现呼叫路由、排队和其他呼叫处理功能的各种方法和装置被公开。可以为分组交换网络提供ACD以及其他呼叫处理功能的组合式分组交换网络子系统的互联的一个或多个示例实施例被公开。除了获得该有价值和有用的操作模式，本发明还可以提供从被公开的结构的组合式方法所产生的对于传统ACD的进一步的优点。这些优点可以包括例如更大的配置灵活性、操作特点更容易调整、对于组合式分组交换网络技术领域的技术人员的技术熟悉性、降低由于使用的组合式部件的商品性质造成的成本以及对标准的使用。

在一个实施例中，提供了分组电话系统，它可以包括一个或者多个子系统，例如可以在协议和物理设施之间转换的网关、可以解析或者转换呼叫地址并且可以将呼叫建立请求定向到适当端点的软交换机(softswitch)。系统可以包括处理代表其他子系统和端点的呼叫控制(例如呼叫建立)功能的呼叫控制子系统(例如呼叫控制代理服务器)、可以产生或应用多种媒体或者执行其他呼叫处理功能的媒体子系统(例如媒体服务器)以及一个或多个代理端点。各代理端点可以包括计算机和软件以提供呼叫代理在处理呼叫中所需的呼叫管理功能。系统还可以包括ACD应用程序，所述ACD应用程序可以协调或者控制其他子系统的行为来实现希望的ACD呼叫处理能力，例如排队、路由、媒体处理等等。根据一个实施例，呼叫控制代理服务器、ACD应用程序、媒体服务器以及代理端点可以组成对分组电话呼叫提供ACD(自动呼叫分配器)功能的分组电话ACD系统。

各种实施例可以提供许多附加特征。呼叫控制代理服务器可以监视和控制在媒体服务器和代理端点的呼叫的状态，并且可以控制向这些子系统的呼叫的建立和清除。呼叫控制代理服务器可以向ACD应用程序报告呼叫的状态，并且可以执行来自ACD应用程序的呼叫控制指令(例如，建立呼叫或者将呼叫路由至具体端点的指令)。另外，各种子系统或者设备可以接收由ACD应用程序产生的呼叫处理指令。呼叫处理指令可以作为分立的指令或者以诸如媒体处理脚本的形式被发出。

在一个实施例中，网关可以在第一个网络和第二个网络之间耦合。作为示例，第一个网络可以是公共网络或者不可信网络，而第二个网络可以是提供了分组电话ACD系统来对分组电话呼叫执行呼叫路由、排队以及呼叫处理的可信网络。使用这样的网关可使呼叫跨过对于呼叫者可以是透明的两种不同类型的网络、不同的协议和媒体类型等等被传递。网关还可以作为防火墙来操作，以阻止不需要的分组或者消息传进可信网络。

在一个实施例中，非ACD端点可以向软交换机注册他们的呼叫地址或者电话地址。同样，呼叫控制代理服务器可以向软交换机注册虚拟端点的电话地址(也被称作路由点或者虚拟电话地址)，呼叫控制代理服务器将为其处理呼叫控制。注册可以包括例如提供被注册的电话地址和将接收呼叫控制消息的子系统的网络地址(例如，IP地址)。地址注册之后，软交换机收到的任何呼叫建立请求或者其他呼叫控制消息将会基于对于该电话地址被注册的相应的网络地址被转发(例如，向呼叫控制代理)。

根据一个实施例，在接收呼叫建立请求之后，呼叫控制代理服务器可以通过诸如CTI链接的标准接口通知ACD应用程序收到呼叫建立请求。ACD应用程序可以控制其他子系统来处理呼叫，例如将呼叫路由至具体端点(例如代理端点)、将呼叫放在队列中等待代理和/或对呼叫应用媒体处理。

根据另一个实施例，ACD应用程序可以动态地产生或者写出媒体处理脚本。媒体处理脚本可以包括一个或者多个指令，这些指令确定应产生或者应用于呼叫的具体的媒体，例如音频、语音、文本、网页、视频、图形等等。媒体处理脚本还可以包括进行其他类型呼叫处理的指令，例如接收呼叫者的输入或者响应、检测和转发预定信号或者呼叫者的输入等等。虽然并不要求，但是媒体处理脚本可以用例如作为示例的语音可扩展标记语言(VoiceXML)或者语音应用语言标记(SALT)的标准脚本语言编写。用标准脚本语言编写的媒体处理脚本可以称作标准语言媒体处理脚本。

根据一个实施例，ACD应用程序可以动态地产生或者写出媒体处理脚本，然后向媒体服务器提供脚本或者指向脚本的指针或标识符(例如一个URL)来将媒体应用于呼叫。在一个实施例中，媒体处理脚本可以实时地或者动态地基于不同类型的信息而产生，作为示例，例如基于当前呼叫状态(例如在呼叫队列中的位置)或者与呼叫或呼叫者有关的信息(例如呼叫者的卡号、当前帐户余额)或者其他信息。进入的呼叫可以被建立或者路由至媒体服务器，媒体服务器然后可以按照检索到的媒体处理脚本中的指令对呼叫应用或者产生媒体。使用动态产生的标准语言媒体处理脚本可使ACD应用程序提供可以被媒体服务器以及其他子系统理解的高度可定制化的媒体处理指令。对媒体处理脚本使用标准语言方便地可使例如这些脚本由一个厂商的ACD应用程序产生，然后由另一个厂商的媒体服务器或者其他设备解释或者应用。

而在另一个实施例中，不是通过网络使用远程媒体服务器来产生转发给呼叫者的媒体，而是可以在本地对呼叫者产生媒体。根据一个实施例，媒体处理脚本，例如标准语言媒体处理脚本，可以由ACD应用程序产生并发给与呼叫者相连的设备(例如，呼叫者的计算机或者相应安装的电话)。呼叫者的设备或者计算机于是可以按照媒体处理脚本在本地产生给呼叫者的媒体。呼叫者的计算机(或者呼叫节点)可以包括解释媒体处理脚本并且随后对呼叫或者呼叫者产生或者应用媒体的软件或者逻辑。呼叫者的输入或者响应可以由呼叫节点检测并且发给ACD应用程序来处理。可以由ACD应用程序基于呼叫者的响应或者其他信息产生另外的媒体处理脚本。这些另外的媒体处理脚本可以被呼叫节点检索并用来应用或者产生另外的媒体，作为示例，例如关于呼叫者在队列中的位置和估计的等待时间的更新。ACD应用程序还可以指示呼叫节点中止媒体的产生，并且呼叫可以被建立或者被路由至端点，例如代理端点。

根据一个实施例，提供ACD(自动呼叫分配器)功能可能是有益的，例如提供与在分组电话系统中的一个或者多个其他子系统(例如呼叫控制代理服务器、媒体服务器、网关、软交换机等等)分立的和/或不同的ACD应用程序。提供与在分组电话网络中的一个或者多个其他子系统分立的和/或不同的ACD应用程序可以是使得ACD应用程序被独立地改进或者升级而不影响其他子系统或者受到其他子系统的限制，反之亦然。至少一些分立的子系统的普遍使用可以提高系统的可测量性和模块性，并且可以创造更大的多厂商独立性。例如，使用与媒体服务器和呼叫控制代理服务器不同的ACD应用程序，可以使得ACD逻辑升级或者改进而不要求对这些其他子系统的修改。

作为另一个示例，使用呼叫控制代理服务器向软交换机注册对应于虚拟端点的电话地址(例如队列或者其他路由点)，可以使得软交换机看似(例如对于进入的呼叫或者呼叫者)提供了用于进入的呼叫的ACD特征而不要求对软交换机的任何改变。在这种安排中，不必在软交换机中嵌入这种ACD功能。更灵活的方法可以是提供与软交换机分立的ACD功能。这可以使得使用来自某一厂商的软交换机的系统当使用来自另外的厂商的ACD应用程序时能够被组合。而且，保持ACD功能与软交换机分立可以避免软交换机的处理能力受到压力，并且可使各厂商独立地升级其子系统而不影响其他方面。

根据一个实施例，分组电话系统中的各种子系统可以方便地通过一个或者多个基于标准的接口、公知或者标准的协议、标准语言媒体处理脚本或脚本文件或者其他基于标准的通信技术，与一个或者多个其他子系统通信。因为来自不同的厂商或者制造商各种子系统可以组合，并且可以使用各种标准或基于标准的接口或者标准语言脚本来通信，所以这也可以提高分组电话系统的模块性和可测量性。这些基于标准的通信技术可以包括例如基于标准的CTI链接、一个或者多个诸如H.232、SIP等等的标准协议以及若干标准语言媒体处理脚本。

现在详细地参考附图，其中类似的部分自始至终用类似的参考标号标明。图1举例说明适于实行本发明一个示例实施例的系统。图1中所示的系统100提供了一个示例实施例，其中分组电话呼叫或者类似者可以被发出、接收和处理。如图1的示例实施例所示，系统100可以包括若干类型的分组电话子系统(120、125、130、135以及140，作为示例)来使得呼叫被发出、接收、排队、路由或者其他方面的处理。子系统可以被提供来例如使得呼叫在呼叫者110A-C和代理端点145A-C之间被发出、接收、处理以及路由。

各子系统可以包括例如在节点上提供的软件或者其他逻辑，其中节点可以包括计算机、服务器、交换机、路由器、网桥、网关、个人数字助理、移动设备等等。而且，在其他实施例中，可以在一个节点上提供两个或者多个子系统，其中在单一节点上的子系统可以通过例如软件接口或者其他技术来通信。各子系统可以处理信息并且可以通过通信媒介与一个或者多个其他子系统通信。通信媒介可以包括能够承载信息信号的任何媒介，例如双绞线、同轴电缆、光纤、射频、电子、声或光信号等等。如所提到的，子系统还可以通过软件接口或者其他技术互相通信。

作为示例，图1中所示的各子系统可以通过点对点的链接或者诸如互联网、局域网(LAN)或者PSTN的网络被耦合至一个或者多个其他子系统。作为另外的例子，子系统还可以通过导线、总线或者软件接口通信。各子系统可以通过按照一个或者多个通信协议的分组或者相关的短信息的形式传递信息，来与其他子系统或者设备通信。在该上下文中的分组可以指一组具有限定长度的信息，长度一般以位或者字节来表示。例如，分组长度可以是1000字节。

协议可以包括一组指令，信息信号通过其在通信媒介上被传递。例如，协议可以是分组交换协议，例如由1981年9月采用的互联网工程任务组(IETF)标准7，征求意见(RFC，Request For Comment)793(“TCP规范”)定义的传输控制协议(TCP)，以及1981年9月采用的IETF标准5，RFC 791(“IP规范”)所定义的互联网协议(IP)，两者可以从“www.ietf.org”得到(一同被称为“TCP/IP规范”)。RFC 2068中定义的超文本传送协议(HTTP)/1.1也是经常用于在例如互联网的分组交换网络上的通信。

有许多另外的协议通常用于在诸如互联网的分组交换网络上传递音频(包括语音电话呼叫)、视频以及数据。一个这样的协议是在被称为“ITU-T建议H.232(1998)，基于分组的多媒体通信系统”，也被称作“H.232”的标准框架(standard umbrella)下的一套标准。在RFC 2543(1999年3月)和RFC 3261(2002年6月)中定义的“会话初始协议”或“SIP”是另一个经常被用于在分组交换网上的例如语音电话呼叫以及视频的信息通信的协议。另一个协议，在RFC 1889(1996)“RTP：一种用于实时程序的传送协议”中定义的被称为“RTP”的实时传送协议，提供了适合应用程序传输诸如音频(包括语音)和视频的实时媒体的网络传送功能。这里确定的所有标准都是作为示例而提供的，可能有一个或者多个对于这些标准各自的版本。

参考图1，现在将更详细地描述系统100的结构和安排。系统100可以包括一个或者多个呼叫者110，例如呼叫者110A、110B和110C。各呼叫者110可以向一方或者多方发出或者发起呼叫。各呼叫者110可以使用电话发出呼叫，例如使用模拟电话在PSTN上发出呼叫，或者使用分组电话技术电话(例如，H.323电话或者SIP电话)在分组交换网络上发出呼叫。呼叫者110被耦合至网络115。网络115可以是任何类型的网络，例如PSTN或者互联网。

系统100可以包括一个或多个代理端点145，其中设置了一个或多个代理或服务代表用于处理进入的电话呼叫。电话可以耦合到各代理端点，例如分组电话技术电话或模拟电话等，以允许代理接收或发出呼叫。在各代理端点可以提供带有软件的节点或计算机。

系统100可以包括一个或者多个子系统，例如网关120、软交换机125、呼叫控制代理服务器130、自动呼叫分配器(ACD)应用程序135以及一个或者多个媒体服务器140。在图1中所示的示例实施例中，网关120可以被耦合至网络115，而软交换机125可以在网关120和呼叫控制代理服务器130之间被耦合。一个或者多个代理端点145A-C可以被耦合至呼叫控制代理服务器130并且还可以被耦合至ACD应用程序135以及媒体服务器140。ACD应用程序135和媒体服务器140可以各自被耦合至呼叫控制代理服务器130。子系统120、125、130、135和140中的每一个现在将根据各种示例实施例来描述。

网关120一般可以提供在外部网络域160(包括呼叫者110以及网络115)中使用的协议及物理设施和在内部网络域170(包括子系统125、130、135、140以及端点145)中使用的协议及设施之间的转换，其中实现了ACD功能。换句话说，网关120可以提供协议交互或者转换，来在不同的协议之间转换信号、消息以及媒体(例如数据、语音以及视频信息)。网关120可以包括信令网关和/或媒体网关。术语“信令”可以指用于例如呼叫建立和清除的与控制相关的功能的控制信号或者消息。术语“媒体”可以指例如音频(包括声音)、视频以及数据的可以被传递的不同类型的信息。

在提供信令网关功能方面，网关120可以转换在网络域160中使用的协议之间的控制信号、消息或者信令和对于在网络域170中使用的协议的控制信号、消息或者信令。例如，网关120可以转换来自PSTN兼容协议的呼叫控制信号，并且将通过网络115收到的这些呼叫控制信号转换为诸如H.323或者SIP的与IP网络兼容的一个或者多个相应的呼叫控制信号或者分组。这样，网关120可以从PSTN网络(例如网络115)接收呼叫建立请求信号(请求建立PSTN呼叫)，然后产生和发送相应的SIP邀请消息，该消息可以请求建立相应的分组电话呼叫。

作为另一个实例，如果网络115包括综合业务数字网络(ISDN)，则网关120可以接收ISDN呼叫建立请求，包括作为DNIS(被叫号码识别服务)信号的被叫电话号码。然后网关120可以产生SIP邀请消息或者其他呼叫建立消息，它们可以包括在SIP邀请消息的字段中的被叫电话号码。SIP邀请消息可以被发给网络域170中的一个或者多个子系统或部件，例如软交换机125。PSTN、ISDN以及SIP只是举例的协议。网关120可以提供任何类型的协议之间的协议转换或者协议交互。

在一个示例实施例中，外部网络域160还可以包括诸如互联网或者PSTN的不可信网络，而网络域170可以包括诸如局域网(LAN)的可信网络。这种情况下，网关120可以提供在不可信和可信网络或者网络域之间的隔离。这种隔离可以根据不可信网络的种类和状态而采取多种形式。在一个示例实施例中，网关120可以包括只允许某些类型的分组或者流量从网络域160传到网络域170的防火墙。因此，网关120还可以在图1中表示为防火墙。另外，因为网关120可以履行其他子系统的功能或者代表其他子系统(例如协议交互)，所以网关120还可以被称为代理。

在提供媒体网关功能方面，网关120可以在不同类型的协议之间转换媒体(例如，语音、视频、数据)。例如，网关120可以通过网络115接收PSTN呼叫的模拟语音信号，然后对语音信号采样和数字化。网关120可以通过分组交换网络在自身和呼叫目标之间建立RTP会话。网关120然后可以通过RTP会话向目标发送在一个或者多个RTP分组的有效负载中的数字化的语音信号。以这种方式，网关120可以通过在不同格式之间或者在不同协议之间转换媒体而起到媒体网关的作用。

网关120可以使外部呼叫者与不必要的分组电话信令消息隔离。在一个实施例中，如果外部呼叫者和可信内部网络域170两者都对呼叫信令使用SIP协议，则网关120可以识别和捕获指向呼叫者的反映在可信网络中呼叫的各种中止和重定向的SIP消息。网关120可以在本地处理这些消息，而可以不将它们发给呼叫者的端点。

软交换机125是可以解析或者转换呼叫地址(例如，被呼叫的电话号码或者被呼叫的地址)的子系统，它可以将连接请求或者呼叫建立请求指向适当的端点、下一个跃点或者下一个子系统。举例来说，软交换机125可以将第一协议使用的第一呼叫地址解析为第二协议使用的第二呼叫地址。软交换机125可以在呼叫建立过程中解决地址转换和许可问题。软交换机可以处理控制信号或者信令(例如用于呼叫建立或者呼叫控制)，但是一般不处理媒体信号或者参与到媒体的路径中。媒体路径可以是被媒体信号(例如音频、语音、视频)采用的可以经过系统100或者网络到达呼叫目标或者端点的路径。

例如，作为部分地址转换(或者地址解析)功能，软交换机125可以接收SIP邀请消息或者例如将呼叫目标确定为电话号码的其他呼叫建立请求。软交换机125可以将被呼叫的电话号码解析或者转换为具有不同格式(与电话号码不同)的相应的呼叫地址，例如IP地址或者SIP URL。URL可以是统一资源定位器，它可以是通过其名称、位置或者其他特征确定资源的一串文本。软交换机125可以使用多种不同技术，例如数据库查找等等的来解析或者转换地址。例如，软交换机125可以使用被呼叫的电话号码进行数据库查找，确定SIP消息(或者其他呼叫建立请求)为了处理而应当被发往的相应的IP地址或者SIP URL。

软交换机125不用只被专用于处理要求例如排队、路由以及呼叫处理的ACD特征的呼叫。当然，除了指向虚拟端点或者虚拟地址的要求特定的呼叫路由和排队(ACD功能)的呼叫，软交换机125还可以处理指向简单物理端点(即，呼叫不要求ACD功能，例如路由和排队)的普通分组电话呼叫。不要求ACD功能的呼叫，例如那些指向简单物理端点的呼叫，在图1中被表示为向非ACD端点的呼叫172。

在一个示例实施例中，如果呼叫被定址或者指向不要求ACD功能(例如路由、排队)的呼叫地址或者端点，则软交换机125确定适当端点的相应的地址，并且将呼叫建立请求通过线路172发给非ACD端点。另一方面，如果呼叫被指向虚拟电话地址或者虚拟端点，则软交换机125可以进行地址查找(例如，在数据库中的电话号码到IP地址的查找)，并且将呼叫建立请求发给识别出的地址。在一个示例实施例中，呼叫可以在呼叫中心被定址到虚拟电话地址或者虚拟端点(也被称作虚拟路由点)，在呼叫中心会发生另外的呼叫路由和排队。这种情况下，软交换机125可以在数据库中进行地址查找来确定用于处理指向该虚拟端点的呼叫的适当呼叫控制代理服务器130的网络地址或者其他地址。

呼叫控制代理服务器130插入在软交换机125和一个或者多个端点，例如端点145、ACD应用程序135和媒体服务器140之间。呼叫控制代理服务器130可以捕获呼叫控制消息并且参与影响端点145的分组电话呼叫控制信令，但是一般不参与到媒体路径中。呼叫控制代理服务器130可以确定端点145的状态，并且可以向例如ACD应用程序135的其他子系统报告这些端点的呼叫状态和呼叫事件。举例来说，呼叫状态和呼叫事件可以包括设备被连到其收到的入站呼叫、当前正在发起出站呼叫或者空闲(即挂机)的通知。

呼叫控制代理服务器130可以向软交换机125注册虚拟端点的电话地址或者呼叫地址(也被称作路由点或者虚拟电话地址)。这些向软交换机125注册的地址是呼叫控制代理服务器130将要对其处理呼叫控制(例如，呼叫建立、清除)的呼叫地址或者电话地址。该注册信息可以包括诸如电话地址(例如电话号码)和呼叫控制代理服务器的地址(例如IP地址或者其他地址)。软交换机125可以在供查找的数据库中存储该注册信息。这样，通过呼叫控制代理服务器130向软交换机125注册电话地址之后，随后的指向这种被注册的地址以及在软交换机125收到的呼叫控制信息可以引起软交换机125通过例如数据库查找来解析该电话地址。在这个例子中，软交换机125可以将被注册的呼叫地址或者电话地址解析为例如网络地址的呼叫控制代理服务器130的地址(例如，呼叫控制代理服务器130的IP地址或者SIP URL)。因此，软交换机125然后可以将收到的呼叫控制消息发给识别出的地址，在这种情况中是呼叫控制代理服务器。

虽然没有在图1中示出，但是系统100的各种子系统或者实体可以通过点对点链接，或者更普遍地，通过一个或者多个网络被耦合在一起。例如，网关120可以通过互联网或者其他网络被耦合至软交换机125、代理端点以及媒体服务器140。这样，网关120可以通过互联网或者其他网络与代理端点145或者与媒体服务器140建立对于分组电话呼叫的RTP会话(对于媒体传递)。在一个实施例中，软交换机125、呼叫控制代理服务器130、ACD应用程序135、媒体服务器140以及代理端点145的电话机都通过局域网(LAN)被耦合在一起。

另外，代理端点145和媒体服务器140还可以向软交换机125注册它们各自的呼叫地址。当代理端点145和媒体服务器140发送注册消息来向软交换机125注册它们各自的呼叫地址时，呼叫控制代理服务器130捕获这些注册消息，并且记录该注册信息(例如，被注册的呼叫或者电话地址以及注册电话地址的实体或者子系统的网络地址，例如网络地址(例如IP地址)的地址)。呼叫控制代理服务器130记录代理端点145和媒体服务器140的该注册信息，以便服务器130可以正确地识别进入的呼叫，或者定址或指向特定代理端点或媒体服务器140的呼叫控制消息或呼叫信令消息。呼叫控制代理服务器130然后可以向软交换机125注册对于代理端点145和媒体服务器140的呼叫地址或者电话地址(例如电话号码)，并且向软交换机规定指向这些呼叫地址的呼叫控制或者信令消息应当被转发给呼叫控制代理服务器130。这样，通过注册这些呼叫地址，呼叫控制代理服务器130规定对于代理端点145和媒体服务器140的电话地址应当被软交换机125解析为呼叫控制代理服务器130的网络地址(例如，IP地址、URL)。

呼叫控制代理服务器130可以连续监视与关于(或者指向或者来自)代理端点145或者媒体服务器140的所有呼叫信令。呼叫控制代理服务器可以接收关于来自代理端点145、ACD应用程序135和/或媒体服务器140的呼叫状态或者呼叫情况的更新。呼叫控制代理服务器130可以通过内部CTI链接176，向ACD应用程序中继有效的呼叫进程事件，或者呼叫状态中或其他与呼叫或呼叫处理有关的信息中的变化或者更新。ACD应用程序135接着可以通过例如CTI链接178，向外部应用程序以及支持代理端点145的应用程序或者向其他位置中继这些事件和呼叫信息。

媒体服务器140可以包括一个或者多个媒体服务器。各媒体服务器可以包括例如，包括处理器和存储器的具有硬件的节点、信号处理板、在节点上执行的软件和/或其他应用或提供媒体处理的逻辑。媒体服务器140可以操作多种可以被用于操作或处理呼叫的媒体处理功能。例如，媒体服务器140可以包括适当的软件、硬件、媒体处理板和/或信号处理逻辑来处理、分析和产生多种媒体，例如音频，包括DTMF(双音，多频)音调、语音，视频、图形以及其他媒体信号。媒体服务器140可以执行多种其他功能，例如进行语音识别、文本转语音(text-to-speech)功能和语音转文本(speech-to-text)功能以及其他媒体处理。举例来说，媒体服务器140可以将音频消息或者音调、视频或图形等等注入到呼叫或者媒体路径(例如RTP会话)中。而且，媒体服务器140可以接收和解释呼叫各方产生的DTMF和语音，并且可以按照需要记录呼叫音频。这些只是媒体服务器140可进行的操作的类型的几个示例。虽然许多示例的呼叫是根据音频、DTMF音调、语音识别等等被描述的，但是呼叫还可以发送和接收视频和图形信息、图片、图像等等。

根据一个示例实施例，媒体服务器140可以按照一个或者多个标准语言媒体处理脚本处理呼叫和/或产生媒体。标准语言媒体处理脚本可以由应用程序，例如可能在各实例中所需要的ACD应用程序135，动态地产生。可以给媒体服务器140提供媒体处理脚本和/或指针，该指针指向脚本或资源标识符，例如识别媒体处理脚本的URL。媒体服务器140然后可以处理呼叫和/或产生适当的媒体(音频、DTMF音调、语音、视频、图形、图像)。举例来说，媒体服务器140还可以按照收到的或者识别出的标准语言媒体处理脚本中的指令，处理收到的语音或者DTMF音调、处理通过计算机鼠标或者其他输入设备输入的用户选择以及接收和处理其他用户输入等等。

媒体服务器140可以处理不同类型的标准语言媒体处理脚本。例如，媒体服务器140可以处理标准VoiceXML或者SALT脚本来处理呼叫或者产生或处理媒体。VoiceXML是指1999年万维网联盟(W3C)1.0版语音可扩展标记语言(VoiceXML)，它是可被用于创建能够通过电话访问的万维网内容和服务的基于XML的语言或标准。根据VoiceXML规范，VoiceXML能够被用于创建以综合的语音、数字化音频、口头和DTMF按键输入的识别、口头输入的记录以及电话功能为特征的音频对话。SALT是指2002年7月15日语音应用语言标记(SALT)1.0规范，被看作是HTML的扩展，可以根据SALT规范向网络应用程序和服务添加语音和电话接口。

代理端点145可以包括各自具有适当的软件的节点(例如计算机)，例如来提供代理或者客户服务代表使用的分组电话技术电话。在代理端点145的节点或者计算机可以用分组电话技术端点能力来支持个人客户服务代表，也向ACD应用程序135提供呼叫安排和管理接口。外部应用程序(未在图1中示出)和支持代理端点145的应用程序可以在任何时刻通过分别经由CTI链接180和178(作为示例)向ACD应用程序135发送适当的请求消息来请求特定呼叫动作(例如，呼叫断开或者传送)。

ACD应用程序135可以被耦合至呼叫控制代理服务器130，例如，通过计算机电话集成(CTI)链接。在一些实例中，计算机电话集成(CTI)可以指使用计算机来管理电话呼叫。CTI链接可以用接口，例如基于标准的接口提供，来允许计算机使用公共或者已知的语言管理电话呼叫。ACD应用程序135也可以通过CTI链接178被耦合至代理端点145，以及通过CTI链接180被耦合至一个或者多个外部应用程序。ACD应用程序135可以协调其他子系统的动作来实现希望的ACD呼叫处理能力，例如排队、路由以及其他呼叫处理功能。根据一个实施例，ACD应用程序135可以动态地产生标准语言媒体处理脚本，然后向执行的媒体服务器140提供脚本或者指向脚本的指针或标识符(例如URL)来对呼叫应用媒体。

在整个处理过程中，ACD应用程序135可以通过例如CTI链接178和180向外部应用程序180、向代理端点145(或者向支持代理端点145的应用程序)以及其他节点报告一个或者多个(或者甚至于全部)呼叫的状态。ACD应用程序135还可以接受来自外部应用程序(没有示出)的关于呼叫控制操作的指令。这种报告和命令可以根据ACD应用程序135可以向外部应用程序公开的地址空间和呼叫模型来进行，它们可以与基础的分组电话网络在其上操作的实际的名称空间和呼叫模型不同。例如，ACD应用程序可以报告根据其代理标识符或者用户名称发给代理的呼叫。ACD应用程序135还可以报告通过代理所在的物理分组电话端点的网络地址发给代理的呼叫。

ACD应用程序135还可以与在代理端点或者其他支持代理端点145的应用程序中提供的呼叫安排和管理功能通信，例如，来允许客户服务代理不时地声明它们准备好或者没有准备好接受呼叫。这种通信也可以通过一个或者多个外部应用程序间接地发生，这些应用程序又通过CTI链接向ACD应用程序135报知呼叫安排和管理功能。

图2是举例说明根据示例实施例的系统100的操作的流程图。图2举例说明可以(至少部分地)在分组电话环境，例如使用SIP呼叫信令协议、H.323协议和/或其他协议的网络中操作的各种实施例。

在205处，各种实体或者子系统，例如非ACD端点、代理端点、媒体服务器以及呼叫控制代理服务器向软交换机125注册它们各自的电话地址。非ACD端点可以是一般不进行进一步的呼叫路由或者呼叫分配的端点。注册信息可以包括被注册的电话地址和被定址向电话地址的呼叫控制消息应当被转发往的网络地址(或者其他地址)。软交换机125可以产生查找表格、数据库或者其他用于在被注册的电话地址和它相应的网络地址之间解析和映射的系统。

呼叫控制代理服务器130可以为虚拟端点(也被称作虚拟路由点)注册虚拟电话地址。注册向软交换机125通报呼叫控制代理服务器130的网络地址(或者其他地址)以及该呼叫控制代理服务器130将处理对于呼叫的呼叫控制(例如，呼叫建立、清除)或者指向这些被注册的虚拟电话地址的消息。另外，非ACD端点、代理端点145以及媒体服务器140可以通过呼叫控制代理服务器130向软交换机125注册它们各自的电话地址，如上面所描述的。

在图2中的210处，外部(不可信)网络域160中的呼叫者110向一个电话地址发出呼叫。在这个示例中，被呼叫的电话地址可以是虚拟电话地址。呼叫可以是例如在PSTN上发出的电路交换式呼叫，或者分组电话呼叫。呼叫通过网络115(例如，可以是PSTN或者互联网)被路由，并在网关120被接收。

在图2中的215处，网关120接收呼叫建立请求，在这个示例中可以是对于电路交换式呼叫的呼叫建立请求。网关120然后产生向软交换机125的分组电话呼叫建立请求，提供呼叫和被呼叫的电话地址。在一个实施例中，网关120可以通过第一协议(通过网络115)接收对电话地址的呼叫建立请求，并通过第二协议产生和发送呼叫建立请求(例如，向呼叫控制代理服务器130)。例如，呼叫建立请求可以通过与PSTN兼容(即，对电路交换式电话呼叫的请求)的第一协议被网关120接收，而网关120可以通过例如作为示例的SIP或者H.323的第二协议产生和发送呼叫请求，来向被呼叫的电话地址建立相应的分组电话呼叫。呼叫建立请求可以通过第一网络(例如PSTN)以及通过第一协议被网关120接收，并且可以由网关120产生另一个呼叫建立请求，并使用第二协议在第二网络(例如互联网)上发送。通常，第一网络可以与第二网络相同或者不同，第一协议可以与第二协议相同或者不同。第一网络和第二网络还可以是同一网络的不同部分，例如互联网的部分或者区段。

在图2中的220处，软交换机125接收对于分组电话呼叫的呼叫建立请求。软交换机125可以或者不可以检测呼叫是否要求ACD功能，例如路由或者排队。软交换机125可以将被呼叫的电话地址，例如电话号码解析为第二个地址。在一个实施例中，软交换机125可以使用数据库查找或者其他技术，将被呼叫的电话号码解析或者映射到网络或其他地址。在这个示例中，基于该电话地址(电话号码)先前的注册，软交换机125将被呼叫的电话地址解析或者映射到呼叫控制代理服务器130的网络地址(例如IP地址或其他地址或者资源标识符)。这只是根据一个实施例举例说明软交换机125的操作的示例。

在225处，软交换机125向呼叫控制代理服务器130的网络地址产生并发送呼叫建立请求(例如通过第二协议)，该网络地址在220被识别(通过使用数据库或者其他技术将被呼叫的电话地址解析为网络地址)。呼叫建立请求可以包括被呼叫的电话地址以及其他信息。

在230处，呼叫控制代理服务器130将输入的呼叫或者呼叫建立请求识别为是指向虚拟电话地址，并可以通过CTI链接176通知ACD应用程序135或使其准备，并且等待进一步的指令。

在235处，ACD应用程序135识别呼叫指向的虚拟电话地址，并且确定处理呼叫请求的ACD类型。ACD应用程序135然后可以发送指令或者消息以控制系统100的各种其他子系统来处理呼叫，例如提供呼叫路由、排队和/或对收到的呼叫应用媒体处理。

图3是举例说明根据示例实施例可能被执行的若干呼叫处理的示例的示图。

参考图3，在305处，ACD应用程序135可以路由呼叫或者控制其他子系统来路由呼叫至一个端点，例如代理端点145或者媒体服务器140。ACD应用程序135可以基于多种不同因素路由呼叫，例如预先配置的规则，或者可以向一个或者多个外部应用程序查询用于处理呼叫的进一步的指令。在一个示例实施例中，代理端点的状态可以被监视并被ACD应用程序使用来对呼叫作出路由决定。例如，ACD应用程序可以通过CTI链接178监视代理端点145的状态，或者从代理端点接收状态信息。

来自代理端点145的状态信息可以包括任何与代理或支持代理端点的应用程序或节点的状态有关的或者描述它们的信息、描述在代理端点的任何呼叫处理或者其他在代理端点发生的事件的信息等等。这样的状态信息可以包括例如这些信息：哪个代理是现存的或者登录进了系统中的指示、目前哪个代理正在处理呼叫和哪个代理没有处理呼叫的指示、代理的所有特定技能的指示(例如，来允许特定的呼叫被匹配给特定的代理技能)、什么时候代理已经登录或到达并且能够接收呼叫或者已经注销并且不能再接收呼叫的指示、来自代理的接收特定呼叫或者传送特定呼叫的请求、任何状态的变化或者更新等等。

呼叫路由的机制可以包括例如ACD应用程序135用指令向服务器130发信号来将呼叫转发或者路由到特定端点，然后服务器130向端点发送呼叫建立消息。示例的呼叫路由处理参考315被更详细地描述。

在图3中的310处，ACD应用程序135可以将输入的呼叫置于等待列表或者队列中，例如FIFO(先进，先出)队列。这可以在例如如果没有端点可用来处理输入的呼叫时进行。比FIFO队列更合适地，队列中的呼叫者可以基于多种标准(例如，金卡会员对银卡会员)对服务区分优先次序。

在呼叫队列的示例操作中，通过CTI链接176接收来自呼叫控制代理服务器130的关于对于呼叫的呼叫建立请求已经被接收的通知之后，ACD应用程序135可以查询代理端点145(或者它们各自的节点或应用程序)来确定各代理的状态。如果代理当前不能用来处理输入的呼叫，则呼叫可以被放到队列中等待处理。当代理变得可用并且呼叫是队列中下一个要被处理的呼叫的时候，ACD应用程序135可以通过CTI链接176向呼叫控制代理服务器130发送消息，来与特定的代理端点建立或者创建输入的呼叫。ACD应用程序135可以向服务器130提供接收呼叫的代理端点的网络地址。呼叫建立消息然后可以以与网关120建立分组电话呼叫的指令从呼叫控制代理服务器130通过线路177被发给特定的代理端点145。代理端点然后可以向网关120发送对于呼叫建立请求的答复，并且在代理端点和网关120之间创建分组电话呼叫。

该分组电话呼叫在图1中可以被示为例如RTP流182。根据该示例，通过在网关120和特定代理端点之间建立分组电话呼叫，呼叫在呼叫者110和代理端点145之间通过包括PSTN呼叫(经过网络115)和分组电话呼叫(经过网络域170)的两个呼叫被建立。

参考图3，在315处，媒体处理也可以被应用于呼叫。例如，ACD应用程序135可以要求或者请求一个或者多个下面的内容：

·向呼叫者通告呼叫在队列中的位置的消息；

·当呼叫者在队列中等待时的音乐或者商业公告；

·识别呼叫者或者确定他们的意图的DTMF或者语音交互，例如，要求呼叫者提供他/她的卡号或者识别被请求的部门等等；和/或

·来自呼叫者的DTMF或者语音信号的检测，例如，指出呼叫者希望被从队列中取出并指向别处。

根据一个实施例，在ACD应用程序135的控制下通过媒体服务器140可以对呼叫应用媒体处理。

图4是举例说明根据示例实施例对于一个呼叫的媒体处理应用程序的流程图。在示例实施例中，呼叫控制服务器130可能已经收到对于一个呼叫的呼叫建立请求。服务器130然后可以通过CTI链接176发送消息来通知ACD应用程序135关于收到的呼叫(或者呼叫建立请求)，并请求对呼叫的路由或者呼叫处理指令。来自呼叫控制代理服务器的消息可以包括识别呼叫的呼叫参考编号、被呼叫的电话地址(例如，电话号码)、呼叫者的电话号码以及其他信息。呼叫参考编号(或者呼叫标识符)可以是与呼叫相关联或者能够识别呼叫的编号或者标识符。

参考图4，ACD应用程序135可以确定媒体处理应当被应用于输入的呼叫。因此，在405处，ACD应用程序可以向呼叫控制代理服务器130发送消息，指示服务器130从网关120向媒体服务器140上的端口延伸或者建立呼叫。来自ACD应用程序的消息可以包括识别呼叫的呼叫参考编号(或者呼叫标识符)、媒体服务器140的网络地址以及路由呼叫的端口号。呼叫控制代理服务器130可以将呼叫参考编号匹配到它可以维护的活动呼叫的数据库中的呼叫参考编号。呼叫控制服务器然后可以向媒体服务器140发送对于呼叫的呼叫建立消息，并且可以指定端口号和呼叫参考编号。

向媒体服务器140的呼叫建立消息还可以在消息中包括标准语言媒体处理脚本文件。作为选择，脚本文件可以在单独的消息中被传送。作为选择，比在来自ACD应用程序135的呼叫建立消息中包括脚本文件更合适地，呼叫建立消息可以包括指向媒体处理脚本文件的指针或者资源标识符(例如URL)。媒体处理脚本文件可以提供关于应当被应用于呼叫或者用于处理呼叫的媒体的指令。

在图4中的410处，媒体服务器140接受呼叫建立请求并在网关120和媒体服务器140之间建立分组电话呼叫。这可以例如通过媒体服务器向网关120发送对于呼叫建立请求的答复并由此在网关120和媒体服务器自身之间建立分组电话呼叫来实现。从而，在一个实施例中，呼叫者110可以通过两个网络被连接至媒体服务器140，这两个网络可以使用不同的协议。在图1中所示的示例实施例中，呼叫者110通过在网络115上向网关120的电路交换式电话呼叫被耦合至媒体服务器140，然后通过从网关120的分组电话呼叫被连接到媒体服务器140。

在图4中的415处，媒体服务器140可以使用资源标识符或者URL检索脚本文件，例如标准语言媒体处理脚本文件。如所提到的，呼叫建立消息可以包括诸如识别标准语言媒体处理脚本文件的URL的标识符。标识符或者URL可以对存储在ACD应用程序135上或者其中的、存储在被耦合至ACD应用程序135的存储设备(没有示出)上的或者存储在其他节点或者服务器上的脚本文件进行识别或者解析。根据实施例，媒体服务器140可以例如通过线路186使用HTTP获取(HTTP Get)功能检索标准语言媒体处理脚本文件。该识别出的标准语言媒体处理脚本文件可以包括一个或者多个指令来对呼叫应用媒体处理或者处理呼叫。

根据一个实施例，由媒体服务器140指定的资源标识符或者URL可以包含唯一的信息，以便ACD应用程序135可以确定该HTTP GET请求属于哪个呼叫，即使可能不知道呼叫被指向的媒体服务器上的具体媒体端口。该唯一或者识别信息可以是例如主体呼叫的呼叫参考编号或者ACD应用程序在指示呼叫处理代理服务器130向媒体服务器140延伸呼叫的时候识别的唯一URL。

ACD应用程序135(或者其他节点)可以用识别出的脚本文件答复获取功能或者其他信息检索请求。许多不同的技术能够被用来提供媒体处理脚本文件。例如，比使用通过呼叫控制消息收到的URL或者资源标识符更合适地，媒体服务器140可以改为对于到达某些信令(或者网络)地址或到达媒体服务器140的某些端口的呼叫，或者对于具有某些特征的呼叫，使用预定的标识符或者URL(或者预定的脚本文件)。例如，对于呼叫中心或者商店的销售部门的呼叫可以被路由至第一网络地址或者媒体服务器140的第一端口，而对于服务部门的呼叫可以被路由至第二网络地址或者媒体服务器140的第二端口。这可以使用不同的被叫电话号码或者通过使用DTMF音调或者语言输入查询呼叫者的选择来进行。例如，媒体服务器140可以自动地对于在第一网络地址或第一端口收到的呼叫检索由第一预定URL识别的脚本文件(例如，使用第一脚本文件来处理对于销售部门的呼叫)，并且可以对于在第二网络地址或媒体服务器140的第二端口收到的呼叫检索由第二预定URL识别的脚本文件(例如，使用第二脚本文件来处理对于服务部门的呼叫)。

另外，例如基于在呼叫控制消息或者其他呼叫信息中包括的诸如呼叫参考编号的呼叫特性，媒体服务器140可以构建或者产生资源标识符或者URL。

在另一个实施例中，媒体处理脚本文件可以被动态地产生(例如通过ACD应用程序135或者其他被要求脚本文件的服务器)，以允许基于当前呼叫状态或者与呼叫或呼叫者有关的信息或者其他信息，自定义脚本可以被实时地或者动态地产生。例如，ACD应用程序135可以基于呼叫的一个或者多个特性(例如被叫电话号码)、日期时间、队列中其他呼叫的号码，或者通过向呼叫者查询信息，来产生脚本。例如，媒体服务器140最初可以产生一个消息请求呼叫者说出他们正在呼叫的部门名字或者识别他们正在呼叫的部门(例如，销售、服务、反馈、安装)。媒体服务器140可以向ACD应用程序135提供一些或者全部这类信息(例如，被叫电话号码和被请求的部门)。ACD应用程序135然后可以基于该信息动态地产生自定义媒体处理脚本文件。该动态产生的自定义脚本文件一般可以适合于或者基于呼叫或呼叫者的当前状态或者其他关于呼叫的信息。媒体服务器140然后可以使用URL从ACD应用程序135检索或者获得对于该呼叫的动态产生的媒体处理脚本文件，并根据脚本文件对呼叫应用媒体处理。

在一个示例实施例中，媒体服务器140可以执行或者检索例如使媒体服务器要求呼叫者输入他的信用卡号的初始(或者缺省)脚本文件。例如基于呼叫者是银卡会员还是金卡会员，初始脚本可以包括链接或链联到另一个(或者第二个)URL或者脚本的一个或者多个指令，来在呼叫上进行另外的媒体处理。这些第二脚本可以基于呼叫者的输入(例如，呼叫者的卡号)，例如基于呼叫者是银卡会员还是金卡会员，提供不同水平的服务或者不同类型的媒体处理。

参考图4中的420，检索媒体处理脚本文件之后，媒体服务器140然后可以根据脚本文件中的指令，对呼叫应用媒体处理。例如，ACD应用程序135可以用动态创建的使媒体服务器140执行希望的媒体处理操作的脚本文件回答HTTP GET操作。如上面所提到的，在一个实施例中，这样的媒体处理脚本可以以标准语言提供，例如VoiceXML或者SALT。

例如，在动态创建或者产生媒体处理脚本文件方面，ACD应用程序135可以使用先前输入的信用卡号进行数据库查询，例如获得信用卡余额、最近的支付等等。ACD应用程序135还可以进行许多计算，例如确定呼叫的号码或者在对列中的位置以及呼叫的估计的等待时间。ACD应用程序135或者可以向客户数据库所在的外部应用程序发送输入的信用卡号，然后从外部应用程序接收信用卡余额和最近的支付信息。ACD应用程序135然后可以动态地产生或者创建媒体处理脚本文件，其中包括将指示媒体服务器140进行例如如下操作的指令：通告呼叫者的信用卡余额、最近支付的数量、在呼叫队列中的序号以及在代理将会处理该呼叫之前估计的等待时间，跟随30秒音乐。这只是举例说明ACD应用程序135如何能够动态产生媒体处理脚本文件，例如标准语言(或者基于标准的)媒体处理脚本文件的一个示例。

媒体服务器提供的识别呼叫的呼叫参考编号可以被用于识别和检索由呼叫者先前输入的呼叫者的信息，例如呼叫者的卡号。可能已经由ACD应用程序135动态产生的标准语言媒体处理脚本文件然后可以响应HTTPGet操作被转发给媒体服务器140。这样的脚本中的最终的指令可能是，例如，链联或者链接到又一个URL的请求，它引起媒体服务器从ACD应用程序135或者其他位置提取第二个媒体处理脚本文件。该第二个媒体处理脚本文件可以再次被动态地创建，从而提供例如关于队列位置和等待时间的最新的更新，或者其他媒体处理。第二个媒体处理脚本文件可以包括链联到(或者检索)可以向呼叫者提供进一步信息的第三个媒体处理脚本文件的指令。该链联或者链接处理(例如，链接到连续的脚本文件)能够持续直到呼叫从队列中被释放。脚本还可以包括用于媒体服务器140监听或者检测来自呼叫者的预定DTMF信号或者语音输入的指令。如果媒体服务器140检测到这样的预定信号或者输入(例如，呼叫者响应)，则媒体服务器140可以通过例如HTTP张贴(HTTP POST)方法转发询问或者呼叫者输入或响应(例如，来自呼叫者的DTMF信号或者语音信号)。ACD应用程序135然后可以产生另外的媒体处理脚本文件，它包括基于呼叫者的输入向特定代理转发呼叫或者对呼叫应用其他媒体处理的指令。

如另一个示例，媒体服务器140使用的第一个媒体处理脚本文件可以包括用于媒体服务器140提示呼叫者关于它们正在设法接通销售还是产品支持的指令。接收呼叫者的输入或者响应(例如象语音或DTMF信号)之后，媒体服务器140然后可以通过HTTP POST方法或者其他消息向ACD应用程序135返回呼叫者的DTMF或者译出的语音输入。ACD应用程序135然后可以使用该呼叫者响应来对呼叫动态地产生第二个媒体处理脚本文件。指向该第二个脚本文件的URL(或者第二个脚本文件自身)然后可以通过HTTP POST方法或者其他消息，被发给媒体服务器140。媒体服务器140可以检索第二个媒体处理脚本文件，然后如该第二个脚本文件所指示的，对呼叫应用媒体处理。例如，第二个脚本文件可以包括指令来提示呼叫者另外的信息，然后将呼叫转发给特定的代理，将呼叫放在队列中或者基于来自呼叫者的一个或者多个响应的进行其他呼叫处理。

根据实施例，当ACD应用程序135确定呼叫准备好被路由或者从队列中释放并被路由到代理或者其他位置的时候，ACD应用程序135可以指示呼叫控制代理服务器130发信号给媒体服务器140来断开呼叫的RTP流，并将呼叫信令和相关联的RTP流重定向到希望的地址。

许多变化可以被应用于上述的各种实施例。例如，虽然已经描述了一些呼叫处理功能，但是由传统的电路交换电话ACD提供的多种其他呼叫处理功能，例如呼叫记录，可以由ACD应用程序135和/或媒体服务器140来实现。另外，可以提供多份上述的各种子系统用于冗余，来提供额外的呼叫处理能力或带宽或吞吐量。例如，上述的各种系统可以用多个网关120、多个软交换机。多个呼叫控制代理服务器130以及多个媒体服务器140来操作。虽然各种实施例已经参考若干示例性的协议，例如SIP、H.323、HTTP等等在上面被描述，但是也可以使用多种其他协议。

虽然ACD应用程序135可以控制或者协调呼叫处理的各种方面，但是呼叫处理也可以从其他节点或者子系统被控制或者协调。例如，代理端点145或者支持这种端点的应用程序软件可以以与ACD应用程序指示媒体服务器相同的方式来指示媒体服务器。例如，如果代理端点145要求呼叫的音频流被记录，则该端点可以指示呼叫控制代理服务器130延伸呼叫的支线至媒体服务器140，并且然后可以通过线路187对媒体服务器140提供引起呼叫被记录的适当的媒体处理脚本。代理端点145或者支持的应用程序软件可以通过线路177指示呼叫控制代理服务器130，并且通过CTI链接178接收该服务器的状态和事件信息，如图1所示。

在一些实施例中，一些子系统可以被组合或者完全被除去。根据实施例，可以除去媒体服务器140的使用。媒体服务器140可以被除去，例如，当呼叫者使用能够解释和/或处理诸如SALT脚本或者VoiceXML脚本的标准语言媒体处理脚本的设备(例如计算机)的情况下。例如，呼叫者可以从包括适当硬件，例如语音处理板、图形板和/或用于解释和翻译标准语言媒体处理脚本的适当软件的计算机产生呼叫。呼叫者的计算机可以解释标准语言媒体处理脚本文件中的各种指令，从而可以根据媒体处理脚本文件中的指令向呼叫者翻译或者产生媒体(例如，显示图形和视频、通过扬声器产生音频或者语音、询问呼叫者等等)。在这种情况下，呼叫者的节点(或者呼叫节点)能够发出呼叫(例如，分组电话呼叫)并根据来自由呼叫者的节点从ACD 135检索到的标准语言媒体处理脚本文件的指令对呼叫应用或者产生本地的媒体处理。以这种方式，呼叫者的节点或者计算机可以根据检索到的脚本文件在本地产生对呼叫者的媒体(例如，语音、音频、视频图形、文本)，而不是依赖于远程媒体服务器来应用媒体处理或者产生通过网络发回呼叫者的媒体。

例如，标准语言媒体处理脚本文件可以是VoiceXML脚本或者SALT脚本，引起这种节点：产生或者解释语音或者其他音频、解释来自呼叫者的DTMF信号、产生视频或者图形显示给呼叫者来要求信息以及对呼叫者应用其他媒体处理。在这样的实施例中，各种输入或者响应，例如语音或者DTMF信号或者从显示器作出选择的鼠标点击，可以被呼叫者节点接收，然后被转发给ACD应用程序135。

例如，如果呼叫者使用配备有能够解释基于SALT网页的多媒体网页浏览器的个人计算机，则ACD应用程序135可以使适当的基于SALT的网页直接被发送给该设备，而不是将呼叫延伸至媒体服务器140并指示媒体服务器解释基于SALT的网页。

如果已知呼叫者使用能够显示图形或者混合模式(例如，语音/音频和图形/视频)网页的设备，则ACD应用程序135可以使适当的网页被发送给该设备，以图形或者混合图形/语音模式传送信息。例如，取代指示媒体服务器向呼叫者询问帐号，ACD应用程序135可以(1)向呼叫者的设备发送图形网页请求输入帐号或者(2)发送能够允许任一依赖于呼叫者偏好的信息输入形式(例如，帐号的键入或鼠标输入，或者帐号的语音输入)的多模式网页。然后，按键输入或者语音输入可以被记录，并被发回ACD应用程序135，在那里呼叫者的响应将被分析，然后另外的网页被发给呼叫者。

在另一个实施例中，ACD应用程序135可以向呼叫者的设备发送一系列定期更新的图形网页，显示呼叫者在队列中的位置和预期的等待时间，提供图形点选按钮，呼叫者可以通过它们要求退出队列而以其他一些方式被服务。

上面参考图4描述的实施例可以在呼叫者和媒体服务器140之间建立分组电话呼叫。媒体服务器140于是可以例如按照媒体处理脚本对呼叫者应用媒体处理。媒体(例如，声音、语音、视频、图形、网页)可以由媒体服务器140产生，并在网络(例如，网络域170和/或网络115)上被发给呼叫者。图5的实施例可以使用稍微不同的方法，其中媒体可以由呼叫者的节点(或者计算机)本地产生，而不是依赖媒体服务器140来产生媒体。

图5是举例说明根据另一个示例实施例的系统的操作的流程图。呼叫者可以发起一个呼叫。在505处，例如，呼叫建立请求可以在呼叫控制代理服务器130被接收。代理服务器130可以通过CTI链接176通知ACD应用程序关于收到呼叫(或者呼叫建立请求)。

在510处，呼叫节点(或者呼叫者的计算机)可以检索或者接收来自ACD应用程序或者其他节点的标准语音媒体处理脚本。根据实施例，可以在呼叫节点上提供能够解释标准语言媒体处理脚本以及根据这些脚本产生媒体的软件或者其他逻辑。

在515处，呼叫节点可以根据在收到的媒体处理脚本中的指令，向呼叫者产生媒体(例如，向呼叫者产生音频或者语音信号、视频、图形和/或网页)。呼叫节点还可以接收并转发出呼叫者对ACD应用程序135的任何输入或者响应。另外，媒体处理脚本可以包括一个或者多个向其他媒体处理脚本的URL或者链接，使得呼叫节点检索或者链联至随后的媒体处理脚本。

在520处，根据实施例，如果预定事件被呼叫节点或者ACD应用程序135检测到，则流程可以进入530。如果预定事件没有被检测到，则流程可以返回510，在那里可以检索另一个媒体处理脚本，然后对该媒体处理脚本重复方框515和520。

预定事件可以是例如：1)代理变为对于处理呼叫是可用的，呼叫于是被路由至该代理端点；2)呼叫节点接收来自呼叫者的预定响应或者输入(例如要求向特定部门或者代理的传送)；和/或3)来自ACD 135的停止媒体的本地产生和/或向诸如代理端点的另一个端点建立或者路由呼叫的指令。这些只是一些示例的事件，但是许多种事件都可以引起流程进入530。

在530处，响应检测到预定事件，呼叫可以被路由至代理端点或者其他端点。作为示例，呼叫者可以选择或者请求向服务部门的传送。该输入或者请求然后可以被转发给ACD应用程序135。ACD应用程序135然后可以向呼叫节点发送消息，指示呼叫节点停止媒体的产生，并且ACD应用程序指示呼叫控制代理服务器130向代理端点145路由或者建立呼叫(相应于初始的呼叫建立请求)。

虽然本发明实施例的某些特征已经如这里所描述的被举例说明，但是现在本领域的技术人员可以想到许多修改、替换、变化和等同者。所以，应当理解所附权利要求意图覆盖落入本发明实施例的实际精神范围之内的所有这样的修改和变化。