语音应用托管环境中的端口管理方法和装置 【技术领域】
本发明涉及语音应用的托管，具体地说，涉及语音应用托管环境(VAHE)中的端口管理方法和装置。
背景技术
在传统的计算机电话系统集成(CTI)应用中，语音应用通常只涉及语音播放和电话用户的按键选择之间的交互作用。随着语音应用(例如语音服务中心、语音拨号、语音查询、语音游戏等等)的繁荣，语音技术(语音识别、发话人识别和语音合成)已经被用来提供更为自然的用户界面，并出现了语音应用托管服务。在这种托管服务中，客户即被服务方租用托管服务提供商的计算机系统资源(包括硬件和软件)和电话资源，将其开发的语音应用运行在该托管环境中，为最终用户(即该语音应用的用户)提供诸如电话技术支持等的服务。通过托管服务，客户可以用更少的成本得到更好的服务。为简明起见，在本说明书下面的说明中，假定一个客户对应于一个应用，尽管在实际中一个客户可以对应多个应用，或者一个应用可以对应多个客户。也就是说，将每一个客户-应用对视为一个不同的客户或者应用。
由公用交换电话网(PSTN)干线、交换系统和计算机系统接口构成的电话资源是托管环境中最昂贵的资源。为简明起见，下面用端口代表电话资源。
图1为语音应用托管环境分层模型的一种结构示例。其中，PSTN102为底层，其上为PABX(专用自动交换机)104、CTI平台(例如交互式语音响应(IVR)平台)106及基于它们的语音应用运行环境108。另外，托管环境还可以提供语音应用运行时可能需要地语音技术服务110。顶层是后端逻辑112，其可以由企业数据库和/或应用服务器构成。从“模型-视图-控制器(MVC，Model-view-Controller)”的角度看，后端逻辑112是模型部分，语音应用的呼叫流控制部分为控制器，语音应用的用户接口部分(可能包括语音技术)与IVR平台和PABX一起是视图(view)部分。一般，语音应用托管环境可以定义为包括PABX、IVR平台、语音应用运行环境；进一步，可以包括语音服务和系统管理部件114组成的集群或者阵列。
在传统的CTI应用中，对于在系统上运行的程序来说，端口资源通常是在图1所示的PABX层或者IVR层以静态的方式提供的。换句话说，端口被物理地分配给不同的应用。
其中一种方式是，如图2a所示，在PABX层，可以将多个电话号码或者分机号码(中继线)绑定为一个逻辑组(逻辑中继线)，对该逻辑组中的号码的呼叫就会被连接到同一个应用。具体举例来说，同一客户(例如产品制造商)租用了多个端口(中继线1-N)，这些端口被绑定为一个逻辑中继线，该逻辑中继线对应于一个提供技术支持服务的应用。当呼叫从所述任何一个端口呼入时，就被连接到所述应用。
另一种方式是，在IVR层(图2b)，可以使用端口(中继线)-应用对，即端口和应用一一对应。例如，第一个客户的应用1与中继线1和2对应，第二个客户的应用2与中继线3、4...N对应，等等。
这些现有方法具有下述缺点：
1)因为PABX和IVR平台目前的设计和实现的限制，端口资源几乎是静态地与应用绑定在一起。例如，在图2a中，该客户静态地拥有N个端口；在图2b中，第一个应用静态地拥有两个端口。如果需要调整绑定关系，就不得不首先修改有关绑定的配置文件，然后关掉交换机(或者IVR系统)，并重新启动来使修改生效。
2)由于上述弱点，很难在运行环境中实时地实现动态端口资源配置，从而不能使端口资源的使用最优化。
然而，动态端口资源配置可以给托管服务提供商和租用托管服务的客户都带来好处。具体来说，为了降低成本，客户不希望租用固定的资源，而更原意按使用付费，同时保障在高峰期的服务质量；对于托管服务提供商来说，则希望通过资源的动态分配来充分利用资源，以达到利润最大化。
【发明内容】
因此，本发明的目的是提供一种新方法和装置，在语音应用层对端口资源进行分配，这样，端口资源与应用就不再是物理地绑定在一起，从而使动态分配端口资源成为可能。
本发明的另一个目的是提供一种新方法和装置，在语音应用层实现端口资源的动态分配，而不需要设计和实现新的PABX/IVR平台。
为此，本发明在语音应用运行环境中加入了一个端口管理装置。该装置接管了所有的端口资源，并在用户的呼叫到达实际语音应用之前，根据预定的端口分配方案(PAS)判断是接通还是拒绝该访问请求。具体来说，托管环境中的每个语音应用均被分配了一个可区别的访问代码(即应用标识，它既可以是应用对应的电话号码，也可以是呼叫者输入的访问标识等)。呼叫者需要该访问代码来确定他所访问的应用。端口管理装置包含了本质上也是一个语音应用的部件，它相当于托管环境中所有应用的接通器，插入在用户要访问的语音应用开始之前和访问结束之后。用户的呼叫到达时，首先会和该部件交互，输入访问代码，端口管理装置根据该代码确定语音应用，并根据预定的端口分配方案判断是接通还是拒绝该访问请求。动态地改变端口分配方案，则可实现端口资源的动态分配。如果需要维护端口使用信息，那么在接通了请求的情况下，还可以在用户和语音应用交互结束后，修改端口使用记录。
具体来说，为实现上述第一个目的，本发明首先提供了一种语音应用托管环境中的端口管理方法，该语音应用托管环境包括交换机(PABX)、CTI应用平台以及基于它们的语音应用运行环境，该方法在语音应用运行环境中实现，包括下列步骤：提供规定每一个语音应用可以使用的最大端口数的端口分配方案，并为每一个语音应用分配访问代码；通过PABX和CTI应用平台接收来话呼叫；根据来话呼叫提供的访问代码识别来话呼叫要访问的语音应用；比较该应用目前使用的端口数以及相应的最大端口数；根据比较结果决定是否将来话呼叫连接到相应的语音应用。
在上述方法中，端口分配方案可以包括下述方式之一或者它们的任意组合：至少一个语音应用的最大端口数中的部分端口数是固定的；至少一个语音应用的最大端口数中的部分端口数根据预定的时间表变化；至少一个语音应用的最大端口数中的部分端口数是自由的，取决于语音应用托管环境中的可用端口数；至少一个语音应用的最大端口数中的部分端口数按照客户访问量模式变化；至少一个语音应用的最大端口数中的部分端口数按照客户访问的历史流量变化；至少部分语音应用的最大端口数中的部分端口数按照这些语音应用的实际访问量比例分配；等等。
访问量模式的统计周期可以是日、周、月等任何周期。访问量分布的统计时隙可以是任何有意义长度。
实际访问量的统计时隙也可以是任何有意义长度。
当使用客户访问的历史流量变化确定语音应用的部分端口数时，将系统时间切分为一系列时隙，在每个时隙里，记录有关应用对端口资源的使用，由之获得该应用的历史流量信息，据之确定下一个时隙的流量，从而确定所述部分端口数。
所述历史流量信息可以是下述信息之一或者它们的任意组合：前一时隙的流量；以前一个或多个连续时隙的平均流量的统计；以前多个连续时隙的流量变化趋势。
在该方法中，还可以提供策略信息，规定每一个语音应用(也就是客户)采用上述方式中的哪一种或者哪一种组合来确定其最大端口数。
最好，根据所述策略信息，并根据预定优化目标，确定最优端口分配方案。优化目标可以是下述目标之一或者任意组合这些目标后的折衷：资源使用最优化；托管服务提供商利润最大化；反应速度最快化；不同客户服务的公平性；控制简单性；等等。
所述访问代码可以是电话号码本身，也可以是呼叫方输入的应用标识代码，或者是从电话号码中提取的代码。
相应地，本发明提供了一种实现上述方法的语音应用托管环境中的端口管理装置，该语音应用托管环境包括PABX、CTI应用平台以及基于它们的语音应用运行环境，该装置包括：端口分配方法产生器，提供规定每一个语音应用可以使用的最大端口数的端口分配方案；呼叫处理器，从所述PABX和CTI应用平台接收来话呼叫，确定来话呼叫对应的语音应用，并向所述端口分配控制器请求访问所述应用，根据端口分配控制器的响应决定是否将该呼叫连接到相应的语音应用；端口分配控制器，接收所述呼叫处理器对语音应用的请求，比较该应用目前使用的端口数以及相应的最大端口数，将比较结果传递给所述呼叫处理器。
所述呼叫处理器可以包括一个应用列表和一个分发器。应用列表为访问代码与具体的语音应用的映射表，由呼叫处理器用于从来话呼叫确定相应的语音应用。分发器用于根据端口分配控制器的响应将呼叫连接到具体的语音应用。
所述端口分配控制器可以包括计数器和比较器。所述计数器用于对每一个应用当前使用的端口计数。所述比较器用于比较每一个应用当前使用的端口数及相应的最大端口数。
所述端口分配方法产生器可以包括一个分配方案的存储装置，直接存储端口分配方案。其甚至可以作为端口分配控制器的一部分，即，端口分配方案存储在端口分配控制器中。或者，端口分配方法产生器可以包括一个策略存储/读取装置，用于存储或者从策略池中读取策略信息；和端口分配/优化装置，用于根据所述策略信息确定端口分配方案。
所述端口分配方法产生器还可以包括：一个信息池，用以记录呼叫信息；一个流量监测/预测装置，根据所述呼叫信息确定语音应用的当前访问量或者预测语音应用的流量；由所述端口分配/优化装置根据当前访问量和/或预测流量确定端口分配方案。
所述策略信息可以由策略生成器生成。
这样，在本发明中，不是根据PABX或者IVR平台的物理绑定来确定端口是否可用，而是在呼叫已经进入语音应用运行环境之后，根据预定的端口分配方案确定端口是否应由特定的应用使用。因此，如果要改变端口分配方案，则与PABX或者IVR平台无关，从而使端口的动态分配成为可能。例如，可以根据客户呼叫的历史信息动态地改变将来的端口分配方案。
【附图说明】
下面结合附图对本发明的优选实施例进行详细的说明。附图中：
图1是语音应用托管环境的结构示意图；
图2a是现有技术中端口资源与应用的一种绑定方式的示意图；
图2b是现有技术中端口资源与应用的另一种绑定方式的示意图；
图3a的示意图图示了现有技术中电话呼叫与语音应用之间的相互作用；
图3b的示意图与图3a相对照，图示了本发明中电话呼叫与语音应用之间的相互作用；
图4为本发明的端口管理装置的第一个实施例的示意图；
图5为图4所示端口管理装置的工作流程图；
图6为本发明的端口管理装置的呼叫处理器的一种结构举例；
图7为图6所示呼叫处理器的工作流程图；
图8为本发明的端口管理装置的端口分配控制器的一种结构举例；
图9为图8所示端口分配控制器的工作流程图；
图10为本发明的端口管理装置的第二实施例的示意图；
图11为本发明的端口管理装置的第三实施例的示意图；
图12为本发明的端口管理装置的端口分配方法产生器的一种结构举例；
图13为图12所示端口分配方法产生器的工作流程图；
图14为图12所示端口分配方法产生器的预测装置的示意图；
图15为本发明的端口管理装置的第四实施例的示意图；
图16为本发明的端口管理装置的呼叫处理器基于VoiceXML的实现的示意图；
图17为图16所示呼叫处理器的工作流程图。
【具体实施方式】
首先参照图3b说明处理一个呼叫的总体过程，以便说明本发明的基本设计思想。需要说明的是，为了图面简明，图3a和3b中省略了图1所示的PSTN 102、后端逻辑112和系统管理部件114。
按照本发明，电话呼叫经由PABX 104和CTI平台(本说明书中以IVR平台为例)106进入实现本发明的方法的端口管理装置304，后者会要求呼叫者提供访问代码(第一过程31)；端口管理装置304按照本发明的端口管理方法，根据由访问代码标识的语音应用302的端口资源分配方案，决定是将该呼叫发送给该访问代码代表的语音应用302还是挂机。如果端口管理装置接受了该呼叫，就将该呼叫发送给实际的语音应用302(第二过程32)，呼叫者与语音应用302开始正常会话(第三过程33)。当语音应用结束后(用户挂机或系统挂机)，端口管理装置304还会修改端口使用记录。如果端口管理装置决定拒绝该呼叫，则在向呼叫者提示系统繁忙后将该呼叫挂断(第四过程32’)。
与此相对照，在现有技术中，由于端口资源是在PABX 104和IVR平台106层与具体语音应用302物理绑定，因此，当有电话呼叫时，根据所述绑定关系，呼叫直接和语音应用302建立会话联系(过程30)。(如果物理资源都不够用，则呼叫不会经由PABX 104进入语音应用运行环境108，这不属于本发明的范围)
由此可见，本发明由于在语音应用层(即语音应用运行环境中)实现，因此与PABX 104和IVR平台106无关，从而使端口资源的动态分配成为可能。
下面描述本发明的具体实施方式。
图4示出了本发明的端口管理装置的第一种实施例；图5示出了与本发明的端口管理装置和方法的第一种实施例相应的工作流程图。
如图4所示，该端口管理装置304包括呼叫处理器402、端口分配控制器406和端口分配方法产生器408。端口分配控制器和端口分配方法产生器一起，可以称为资源管理器404。在呼叫过程中，呼叫处理器和所有语音应用运行在同一语音应用运行环境(见图2)上。语音应用运行环境支持按照语音应用指定的流程和呼叫进行交互。该语音应用运行环境还负责响应语音应用请求的语音服务(见图3b)(比如语音识别、语音合成、发话人识别)。呼叫处理器从呼叫方获取访问代码，与资源管理器中的端口分配控制器协同工作以实现端口分配。其中，端口分配控制器根据端口分配方法产生器产生的端口分配方案对呼叫处理器提交的端口请求进行响应，呼叫处理器根据所述响应对来电呼叫进行处理。
下面结合图4和图5进一步详细描述端口管理装置304的结构和工作流程。
呼叫可以从VAHE中的任何端口进入(步骤502)。呼叫处理器402接收该呼叫，并与呼叫者交互作用以获取访问代码(步骤504)。通过在应用列表中搜索所述访问代码，呼叫处理器402获得呼叫者想要访问的应用的信息(比如应用ID和实际入口地址)(步骤506)。呼叫处理器402向资源管理器(404)中的端口分配控制器(406)提出请求，请求允许将该呼叫连接到语音应用。端口分配控制器404根据呼叫处理器的请求信息，检索到存储的相应应用目前使用的端口数(步骤508)，将其与该应用可以使用的最大端口数进行比较(步骤510)。
如果使用端口数不小于最大端口数，表明该应用目前没有可以使用的端口，该呼叫应当被中断，释放当前端口供其他语音应用使用。此时，呼叫处理器告诉该呼叫者系统忙，然后切断该呼叫(步骤518)，该呼叫结束。这样，该端口就被释放，可用于接收新的呼叫。
如果所述使用端口数小于最大端口数，则表明该应用还有可用端口。此时，呼叫处理器402将该应用的使用端口数增一，并将该呼叫提交给语音应用的实际入口(步骤512)，所述入口由如上所述从应用访问代码获得的入口地址指示。此后，呼叫方与语音应用会话(步骤514)。当呼叫者结束对语音应用的访问时，呼叫流返回呼叫处理器。然后，呼叫处理器将被使用的端口数减一，切断该呼叫(步骤516)。这意味着该端口被回收，可以用于接收新的访问。
如图6所示，呼叫处理器402可包括一个访问代码-应用列表602和一个分发器604。该列表保存了从访问代码到具体应用之间的映射关系，分发器604负责将呼叫连接到具体的应用上。所述访问代码也就是语音应用的标识，它既可以是应用对应的电话号码，也可以是呼叫者输入的访问标识，或者是从电话号码中提取的代码。类似于800电话的末尾号码，依据电信系统的不同，有不同的方式用于定位被叫号码：
1.DNIS(Dialed Number Identification Service，被叫号码辨识服务)或DID(Direct Inward Dialing，内部直拨)。如果交换机支持，这类信息可以在信道上作为DTMF或MFR1信号被传输；
2.公路信令(Common Channel Signaling)。在基于ISDN的系统上，被叫号码是一直可用的。
3.可交换数据链路(RS232 exchange data link)。在基于RS232的系统上，被叫号码可以通过信号处理得到。
4.信道标识(Channel Identification)，即各种平台提供的逻辑信道标识技术。这种信道标识可以被用来区分应用。
下面结合图6和图7进一步详细说明呼叫处理器402的工作过程。由于在本发明中，端口管理装置与呼叫和应用的交互作用都是通过呼叫处理器来进行，所以，呼叫处理器的工作过程与端口管理装置的工作过程是相应的。因此，对于图7中与图5相同的步骤采用了相同的附图标记。
从电话系统端(即图6中的端口1到端口M)发出的任何一个呼叫请求都被呼叫处理器402接收(步骤502)。根据该呼叫的访问代码，通过访问代码-应用列表602将该呼叫映射到相应的应用(步骤504、506)。之后，呼叫处理器对端口分配控制器404发出访问所述应用的请求并得到响应(步骤702)。该响应表明对于该应用，是否还有可用的端口(步骤704)。如果没有，则挂断呼叫(步骤518)，被临时占用的端口被释放，可用于新的呼叫。如果有，则由分发器604将该呼叫分发给相应的应用(步骤706)。接下来，呼叫方与语音应用会话(步骤514)。会话结束后，分发器604挂断呼叫，呼叫处理器将端口分配控制器中该应用的使用端口数减一(步骤708)。这样，对应的物理端口被释放，可用于接收新的访问任何应用的呼叫；该应用的逻辑端口也被释放，可用于接收新的访问该应用的呼叫。
对于呼叫处理器(以及本发明的装置的其他部件)的开发编程模式，没有具体的要求。对于本领域的技术人员来说，基于本申请的公开，写出具体的应用程序只是一种常规劳动。它可以使用VoiceXML(语音可扩展标记语言)开发，也可以是基于某个语音和电话平台开发的应用。根据CTI平台的不同，呼叫处理器的实现也不同。一般呼叫处理器是基于CTI平台提供的应用编程接口实现的业务对象。在本发明中，它与所有的被叫号码绑定，再根据具体被叫号码的不同去触发不同的应用。
图16的结构示意图和图17的工作流程图为作为举例的基于VoiceXML(它构成前述语音应用运行环境)的呼叫处理器实现方式。图16中，呼叫从交换机、ISDN等等进入CTI平台106上的VoiceXML解释器。VoiceXML通过http协议和基于VoiceXML开发的呼叫处理器402以及具体的应用交互。呼叫处理器和应用可以是驻留在万维网(Web)服务器上的Web应用(ASP、JSP、Java Servlet、CGI等)。VoiceXML解释器向它们提出http请求，它们将生成的VXML文件返回VoiceXML解释器。
下面结合图17具体描述作为举例基于VoiceXML的呼叫处理器的工作过程。呼叫处理器402是VoiceXML解释器所绑定的初始应用，所有呼叫进来后，VoiceXML解释器都首先交给呼叫处理器处理。呼叫处理器根据其应用列表生成含主菜单的VoiceXML文件并传回VoiceXML解释器(步骤1702)。VoiceXML解释器在接收到用户访问代码后将其通过诸如http请求的方式提交给呼叫处理器处理(步骤1704)。然后，如上所述，呼叫处理器查询应用列表找到相关应用(步骤1706)，并询问资源管理器是否接收该呼叫(步骤1708)。
如果资源管理器确定不接收该呼叫，则呼叫处理器通知VoiceXML解释器切断电话，当VoiceXML解释器找不到下一个待处理的页面时即挂断，也可通过显式的disconnect标记挂断(步骤1710)。
如果资源管理器确定接收该呼叫，则呼叫处理器将VoiceXML解释器连接到应用的实际URL地址，例如在返回的VoiceXML解释器文件中使用next(步骤1712)。呼叫服务完成后，应用告诉VoiceXML解释器返回呼叫处理器，可以同样使用诸如next的标签(步骤1714)。这一步有可能会同时提交相应的参数，使得呼叫处理器足以标识是哪一个呼叫请求。然后，呼叫处理器通知资源管理器该呼叫完成(步骤1716)，并通知VoiceXML解释器切断电话(步骤1710)。
图8为端口分配控制器406的一种实施例，图9为其工作流程。该端口分配控制器包括一个计数器802和一个比较器804。该计数器包括多个与应用相应的计数器，用于对相应应用正在使用的端口计数。当端口分配控制器406收到呼叫处理器对某个语音应用的请求(也就是端口请求)时(步骤902)，比较器804从该语音应用对应的计数器获取该应用正在使用的端口数(步骤904)，将其与端口分配方法(PAS)中相应应用的最大端口数进行比较(步骤906)，将比较结果提供给呼叫处理器(步骤910)。并且，如果比较结果是计数器值小于所述最大端口数，则将相应计数器值增一(步骤908)。此外，如果端口分配控制器收到呼叫处理器释放端口的请求，则相应应用的计数器值减一(图9中未示出)。
端口分配方法产生器408的主要功能是提供给端口分配控制器一个分配端口的依据，即规定每一个应用可以使用的最大端口数的端口分配方案(PAS)。在本实施例中，端口分配方法产生器可以是一个静态配置，即，其中直接存储了每个客户(对应于一个语音服务等级协议VSLA)或者每个语音应用允许分配的最大端口数，在整个系统运行期间都按照这种方案进行端口分配。此时，端口分配方法产生器事实上就是一个语音应用-最大端口数映射表，可以直接作为端口分配控制器的一部分，即存储在端口分配控制器中。
端口分配方法产生器也可以根据预定的标准动态调整端口分配方案。即，在不同的时间段，端口分配方案可能被修改，或者切换到另一种截然不同的端口分配方案。所述预定标准也可以存储在端口分配方法产生器中，例如是一个时间表，直接规定各应用在各时段的最大端口数。
显然，不同的客户、不同的应用对端口资源会有不同的要求。这些要求称之为策略。上述两种例子，即最大端口数固定和最大端口数按时间表变化，就可以分别视为一种策略。策略还可能包括其他不直接规定最大端口数的信息，例如某些应用的端口数不受限制。策略信息不仅可以存储在端口分配方法产生器中，还可以存储在语音应用托管环境中的任何存储介质上，例如如图10所示存储在一个策略池1002中。策略池1002中的信息可以由维护人员直接写入，也可以由策略生成器1004根据服务提供商和客户之间达成的服务等级协议(SLA)等生成。策略池可以是一个数据库或者其他用于存储信息的数据结构(例如文件、数据仓库等)。
策略信息还可以包括下列信息：某些应用的端口数按照客户访问的历史流量变化；某些应用的端口数按照实际访问量比例分配；某些应用按照客户访问量模式等等。所谓访问量模式，是指访问量在统计周期内的访问量随时间的分布，例如在一天中的分布，或者在一周中的分布等。具体地说，例如，如果以日为统计周期，则中午和晚上为访问量高峰；如果以星期为统计周期，则周六、周日为访问量高峰等。
此时，为了确定所述历史流量或者实际访问量，或者，如果访问量模式不是预定的，为了通过统计确定访问量模式，需要记录呼叫的历史信息。因此，如图11所示，在本发明的第三实施例中，端口管理装置304还包括一个呼叫信息池，它可以是数据库或者其他用于存储信息的数据结构(例如文件、数据仓库等)，用于存储呼叫信息，比如由呼叫处理器在其中存储应用代码、呼叫开始、结束时间和接通与否。具体地，例如，呼叫处理器接收到呼叫后，将应用代码和该呼叫的开始时间记录到呼叫信息池中；然后，在呼叫处理器请求端口分配控制器并从其获得响应后，将响应结果(表明呼叫是否能接通)记录到信息池中；如果呼叫接通，则在呼叫结束时将呼叫结束时间记录到呼叫信息池中。根据呼叫信息池的信息可以得出各应用的历史流量、实际访问量和访问量模式。
不言而喻，在本实施例中，策略信息可以存储在端口分配方法产生器中，也可以类似于第二实施例一样存储在策略池中，如图15的第四实施例所示。事实上，在本发明中，任何需要存储的信息都可以存储在任何可能的一个或者多个地方，这对本领域普通技术人员来说是显而易见的。
策略信息还可包括客户要求的服务质量参数。对于典型的CTI应用，比如交互式话音响应(IVR)系统和客户关系管理(CRM)应用，通常使用忙时业务量(定义为访问率/服务率)和阻塞率(定义为被阻塞的呼叫和总呼叫数的比例)来量度服务质量。阻塞率的确定可以使用任何一种流量模型。例如，按照通信领域的ErlangB流量模型，阻塞率Pi(i为应用或者说VSLA编号)取决于访问量Ai和分配给该应用的最大端口数mi：
Pi=Aimi/mi!Σj=0mi(Aij/j!)---(a)]]>
在端口资源充裕的情况下，只需要按照每一个应用(客户)的策略要求确定最大端口数就可以了。下面分别说明一些如何按照上述每一种策略确定某个应用的最大端口数的例子：
(1)如果分配策略规定某个应用的最大端口数固定，则在任何时候，该应用的可用最大端口数都确定为该端口数。
(2)如果分配策略规定某个应用的最大端口数按照预定时间表变化，则任何时候的最大端口数可以通过检索该时间表而得到。
(3)如果分配策略规定某个应用的最大端口数是自由的，则在任一时刻，该应用的最大端口数为托管环境中剩余的端口数。
(4)如果分配策略规定某个应用的最大端口数按照访问量模式确定，则根据呼叫信息池中的记录统计该应用的访问量模式，比如在一天或者一周等中的分布等。根据该模式，可以预测任意时刻的访问量。从而，根据策略信息中的服务质量参数(例如阻塞率)，如果策略信息中不包含服务质量参数则按照某种预定标准，例如最佳服务质量参数，根据上述公式(a)得到最大端口数。
(5)如果分配策略规定某个应用的最大端口数按照实际访问量比例分配，则根据呼叫信息池中的记录统计当前该应用的访问量占总访问量的比例，将其乘以总端口数，则得到该应用在该时刻的最大端口数。基于该策略，端口分配方案可以实时调整相应应用的最大端口数。但是，也可以将系统时间划分为时隙，按时隙统计访问量比例，据以确定下一时隙的最大端口数。
(6)如果分配策略规定某个应用的最大端口数按照历史流量确定，则根据呼叫信息池中的记录统计该应用的历史流量，根据历史流量预测下一时隙的流量，再根据上述公式(a)得到最大端口数。下面详细说明流量的预测。
首先，将系统时间划分为时隙(TS)序列，TS1，TS2，...TSj-1，TSj...
然后，根据上一时隙TSj-1，或者以前的多个时隙，的呼叫负载，预测至少一个应用在下一时隙TSj的流量。预测算法多种多样。图14所示为一个流量预测模型举例。其中，从呼叫信息池中读出时隙TSj-1的访问记录，包括访问的开始时间、结束时间与接通与否(输入信息)；然后由预测算法统计在该时隙中访问的总次数和访问被阻塞的次数，设定时隙TSj的流量(预测流量)，例如可以将其简单地设定为等于时隙TSj-1的访问流量(总次数减去被阻塞的次数)。
也可以根据过去的多个时隙的平均流量来预测下一个时隙的流量。或者，预测算法也可以是根据对以前多个时隙的统计，将流量增减趋势考虑在内预测下一时隙的流量。在该预测模型中，还可以包括一个反馈回路，根据汇集到呼叫信息池中的预测流量和实际流量进行误差分析，调整预测算法。
在通过统计确定访问量模式和预测流量时，需要确定统计时隙(即端口分配方案的调整间隔)、流量预测的统计时隙和预测时隙(即端口分配方案的调整间隔)。它们可以是等时间间隔，也可根据流量变化动态调整，或由某些事件触发，例如维护人员的介入或者流量的突变等。通过设定合理设定所述时间间隔长度，可以及时调整端口分配方案，同时准确反映通信负载的变化。
在端口资源有限的情况下，各个应用或者客户的端口使用会发生冲突。此时，则需要加以权衡和协调，获得一个最优的端口分配方案。这个优化过程可以有各种各样的优化目标。所谓优化目标，是指端口分配方案要达到的某种最优化程度，例如资源最优化、托管服务提供商收入最大化、反应速度最快化、不同客户服务的公平性、控制简单性，等等。事实上，端口分配方案可以设定任何目标，甚至没有目标，即无需优化(例如前述端口资源充裕的情况)。
优化过程是一个典型的有约束条件的最优化问题。约束条件就是端口总数，优化目标则如前所述可以是各种各样的目标，例如托管服务提供商的利润最大化。这对于计算机技术领域的技术人员来说是一种常规算法，可以以各种各样的方式和语言实现。例如，可以定义一个目标函数(最优化函数)，然后利用各种优化技术(例如动态规划、神经网络、遗传算法都是非常普遍的例子)来达到目标。作为举例，可以考虑用遍历的方式：对于每一个应用(客户)的端口数的变化产生一个不同的端口分配方案；遍历每一个不同的端口分配方案，从中选取最优的方案，例如利润最大的方案。
当然，端口分配方案也可以是上述各种方案的部分或者全部组合。这种组合有两层含义。一方面是就不同的应用而言，例如，对于在分配策略(客户和托管服务提供商议定)中选择静态端口数的语音应用，静态地分配所需数目的端口，作为端口分配方案中的最大端口数。对于其他语音应用，则使用上述各种方法动态设定最大端口数，以便实现端口的统计复用。另一方面是就一个应用而言，其能够使用的端口数可以分为若干部分，例如一部分按照固定端口数确定(即最低限度)，另一部分按照历史流量确定，等等。
根据上述对端口分配方法产生器的说明，本领域普通技术人员完全能够编制出相应的程序实现该装置和相应的方法。附图12、13为它们的一种举例，下面对其加以说明。
图12所示为端口分配方法产生器的一种优选的结构举例。它包括一个存储/读取装置1202、一个流量监测/预测装置1204和一个端口分配/优化装置1206。存储/读取装置1202用于存储或者从策略池1002中读取策略信息，并将策略信息提供给端口分配/优化装置1206和流量监测/预测装置1204。根据需要，流量监测/预测装置从呼叫信息池1102读取有关的呼叫信息，据之确定当前访问量或者预测流量。端口分配/优化装置根据策略信息和流量信息确定端口分配方案并提供给端口分配控制器。如果必要，端口分配/优化装置根据其中存储的或者从其他信息源读取的优化目标确定最优的端口分配方案。
如前所述，所述策略池1002不是必需的。如果端口分配方案的确定不需要利用呼叫信息，则呼叫信息池1102和流量监测/预测装置1204也不是必需的。如果所述策略信息直接是端口分配方案例如固定端口数，则所述端口分配方法产生器只需有所述存储/读取装置就足够了，甚至作为端口分配控制器的一部分。
下面结合图13举例说明图12所示的端口分配方法产生器的工作过程。首先存储/读取装置1202从策略池1002读取一个应用的策略信息(步骤1302)。然后根据策略信息从呼叫信息池1102获取相应的呼叫信息(步骤1304)。如前所述，对于某些应用，不需要呼叫信息就可以确定最大端口数。因此，如果此时能确定该应用的最大端口数(步骤1306)(例如前述固定端口数和按时间表变化的情况)，则由端口分配/优化装置1206确定该最大端口数(步骤1308)，并处理下一个应用(步骤1310)。否则根据呼叫信息池1102的信息确定该应用的当前访问量和/或下一时隙的流量(步骤1312)。如果此时能确定该应用的最大端口数(例如在端口资源充裕的情况下，根据访问量模式、历史流量、实际访问量比例等直接确定端口数)(步骤1314)，则端口分配/优化装置1206确定该最大端口数(步骤1308)，并处理下一个应用(步骤1310)。否则继续处理其余应用(步骤1316)。在所有应用处理完毕之后，由端口分配/优化装置综合考虑各应用的信息(例如端口数自由的应用需要在最后确定其端口数)，必要时利用优化算法(例如在端口资源有限的情况下实现托管服务提供商利润最大化)为剩下的应用分配端口数。各应用的最大端口数即构成提供给端口分配控制器的端口分配方案。
注意，上述实施方式只是一种举例。例如，在图13中，对于各应用的处理完全可以并行进行。又如，可以在处理完所有应用，获得每一个应用的所需端口数信息和/或流量信息后，利用优化算法确定所有应用的最大端口数。
另外需要注意的是，对于每一应用，调整其最大端口数的时间间隔(例如所述时隙)可以各不相同。所以，对于整个端口管理装置或者方法来说，端口分配方案的调整时间间隔是由各应用的调整时间间隔决定的。
由上述描述可知，本发明提供了一种在语音应用托管环境中的语音应用层实现的端口管理方法和装置，使端口资源的动态分配和统计复用成为可能。
需要注意的是，本发明的保护范围不局限于前述优选实施例，而应覆盖不脱离本发明的实质的所有变体。首先，上述各种技术方案或者技术特征可以在本发明的范围内自由组合。其次，尽管在对本发明的说明中采用了IVR平台作为例子，但对于本领域普通技术人员显而易见的是，本发明的实质与具体平台无关。如前所述，CTI应用可以是IVR应用，也可以是CRM应用，等等。在CTI平台之上的语音应用运行环境可以是VoiceXML，也可以是其它环境。再者，本发明的方法和装置可以由本领域普通技术人员通过编程以各种方式实现，本说明书中所说明的具体方式只是一种举例。例如，对于所述装置而言，其各个部件的功能可以合并在一个或者多个部件中，也可以分割到不同的部件中。又比如，所述端口分配方案、策略信息和优化目标都只是举例，事实上可以有任何端口分配方案、策略信息和优化目标。