CN1256050A

CN1256050A - 电信网交换机中的语音提示播放方法

Info

Publication number: CN1256050A
Application number: CN99800075.2A
Authority: CN
Inventors: 海基·图南恩; 阿基·克赫恩
Original assignee: Nokia Telecommunications Oy
Current assignee: Nokia Oyj
Priority date: 1998-01-27
Filing date: 1999-01-25
Publication date: 2000-06-07
Also published as: US6418197B1; WO1999040709A3; FI980176A; FI106351B; AU2166299A; CA2284716A1; JP2001519990A; FI980176A0; EP0972412A2; WO1999040709A2

Abstract

本发明涉及电话交换机在连接建立过程中向呼叫方播放语音提示的一种方法。本发明基于将语音提示需求检测与语音提示播放完全分离的思想。在本发明中,在呼叫建立的给定阶段以常规方式检测语音提示需求(6.7)。但是,在本发明中,交换机并不立即播放语音提示,而是在需要时,将其延迟至呼叫建立的较后阶段或较后的事件中播放(6.15)。语音提示可以推迟到例如出现以下情况之后才播放:确实完成附加拨号的收集,证实呼叫成功,证实语音提示是必要的/正确的,等等。因此,基于这种语音提示,可以避免错误和不必要的语音提示以及呼叫的失败。本发明还涉及可以应用本方法的电信网交换机。

Description

电信网交换机中的语音提示播放方法

本发明涉及呼叫连接建立，具体而言，涉及电话交换机在连接建立过程中向呼叫方播放语音提示(announcement)。

电信网交换机负责呼叫建立控制和用户间连接的交换。在对简单的情况下，交换机从主叫方或从另一交换机接收呼叫建立请求，将连接进一步交换到被叫方或下一交换机。实际上，电话交换机在呼叫建立过程中的操作是一个非常复杂的处理，它包括多个连续的子处理。这些子处理包括以用户特定方式触发的特殊业务，号码分析，呼叫前转，特殊计费，等等。这些操作所需的智能可以位于交换机，但现在更为普遍的情况是位于连接到基本网(例如公用电话交换机PSTN)的智能网(IN)。

智能网使得业务的实现和控制更为快捷、容易和灵活。这通过将至少一部分业务控制从交换机转移到智能网中独立的功能单元来实现。因此，业务可以独立于基本网的操作，在改变或增加业务时不需要改变基本网的结构及其软件。这种智能网的一个例子在国际电联(ITU-T)的Q.1200系列建议中描述。完成智能网业务控制功能(SCF)指定的任务的设备或网元称为业务控制点SCP(业务控制点)。在本申请范围内，SCF和SCP相同，此后称为SCP。SCP向交换机发出呼叫建立指令，或者由交换机向SCP呼叫询问呼叫建立指令。负责智能网接口的交换机被称为业务交换点(SSP)。它们至少包括业务交换功能(SSF)和呼叫控制功能(CCF)。呼叫控制功能CCF不是与IN相关的功能，它是交换机已有的标准功能，包括交换机的高层呼叫处理功能，例如建立和释放传输连接。业务交换功能SSF是呼叫控制功能CCF和业务控制点SCP之间的接口。在本申请范围内，业务交换点SSP等同于CCF和SSF所形成的功能实体，此后称为SSP。

在不借助智能网的传统呼叫建立中，电话交换机独立地进行与呼叫路由选择相关的所有决定。在智能网中，与路由选择相关的决定也由SCP作出。

呼叫建立的不同阶段可能包括中间语音提示，向呼叫中的某一方，一般是主叫用户，提示呼叫的进行或者给出其它呼叫相关信息，例如资费信息。在智能网应用中，例如在检测到呼叫的特定阶段或事件之后，SCP可以请求交换机向呼叫方，一般是主叫用户，播放语音提示。目前，交换机在接受通知之后，例如在SCP给出请求之后立即播放语音提示。

现有技术语音提示处理存在以下问题：

1.不必要的计费：在计费语音提示情况下，现有交换机立即开始计费，且无法中止。如果在呼叫建立的早期阶段中播放了语音提示而呼叫建立失败，那么用户可能必需为“不必要”的通话时间支付费用，该时间从播放语音提示的第一时刻开始，到因呼叫建立出现问题而进行的释放结束(释放的语音提示也可能被计费)。

2.不必要的语音提示：在呼叫建立的某一阶段播放了语音提示(例如与呼叫前转相关)，尽管呼叫建立以后可能失败。因此，语音提示可能是不必要的，且不必要地占用了交换机资源(首先播放的语音提示延迟了释放原因的检测；分配给该呼叫的资源可能被不必要地占用)和语音提示资源(如果该语音提示是不必要的)。

3.阻碍了附加拨号的收集：在语音提示中，交换机必须向主叫方发送“地址全消息(ACM)”。该消息至少有两个含义：首先，它表明拨号是完整的，其次，它提供给原交换机一个可以将话音/语音提示连接到该呼叫的状态。基于第一含义，拨入号码不再接受附加拨号(拨号“发送完成”)。如果在非常早的呼叫阶段就播放了语音提示，而如果所用的来话信令(用户和交换机间或交换机之间)要求拨号由多于一个消息提供，则无法再接收新的附加拨号消息，并且呼叫需要释放，因为无法请求/得到分析拨入的号码所需的附加数字。(R2可以从网络请求附加拨号，而例如ISUP直接通过后续地址消息(SAM)提供附加拨号)。

4.不能对不同呼叫建立阶段播放的不同语音提示指定优先级或进行优化：基本操作是在接收到表明应当在业务中播放语音提示的信息之后立即播放语音提示。之后，在呼叫建立阶段，可以接收到另一业务需要播放的语音提示。但是，在某些场合下，只播放第二语音提示比较有利。可是这却无法实现，因为第一语音提示已经播放。

5.不同属性所引起的语音提示集中管理：属性所确定的语音提示无法被另一属性(后激活)阻塞。

6.呼叫建立延时：呼叫建立阶段播放的语音提示引起了呼叫建立时延，因为语音提示立即作为整体播放。如果语音提示转移到例如ACM的正常等待状态，则可以没有时延地执行正常情况下也快速执行的呼叫建立各阶段。

7.没有机会一般性地控制呼叫建立阶段中已被延迟(如果需要，也可以是有条件的)的语音提示：例如，在谈话阶段发生某个事件(例如呼叫等待中)时播放的语音提示应当在该呼叫建立阶段之前设定。

因此，本发明的目的是提供一种方法，以及实现该方法以解决上述问题的设备。

本发明的目的由按照权利要求1的方法实现。

本发明还涉及按照权利要求11的电信网交换机。

本发明基于将语音提示需求检测与语音提示播放完全分离的思想。在本发明中，在呼叫建立的给定阶段以常规方式检测语音提示需求。但是，在本发明中，交换机并不立即播放语音提示，而是在需要时，将其延迟至呼叫建立的较后阶段或较后的事件中播放。语音提示可以推迟到例如出现以下情况之后才播放：确实完成附加拨号的收集，证实呼叫成功，无论如何交换机都已在后向中发送了ACM消息，证实语音提示是必要的/正确的，等等。延迟语音提示，使其在呼叫建立的某个阶段或者某个事件中播放，这取决于各交换机的实现，以及延迟语音提示希望避免的问题。应当注意，本发明的交换机可以以常规方式在检测到需求之后立即播放一些语音提示，而没有延时，这种情况并不会引起上述类型的问题。

按照本发明的一种优选实施例，在检测到语音提示需求时，至少存储语音提示中选择正确的语音提示所需的数据(例如语音提示索引或名字)。此外，最好存储需要播放语音提示的呼叫建立阶段。该数据也可以是确定的：例如在给定阶段播放特定语音提示。需要存储的其它数据可以涉及语音提示类别/类型和优先级，或者确定如何处理与同一呼叫建立相关联的出于不同原因的其它语音提示的规则(禁止其它语音提示，其它语音提示可以覆盖本语音提示，等等)。如果呼叫中得到多于一次的语音提示，则每一语音提示最好单独存储在为此保留的数据结构中的语音提示特定的数据项中。

语音提示数据可以以类似队列或栈的数据结构形式存储。该结构取决于语音提示存储过程中采取的措施。如果语音提示按照建立阶段的时序和优先级排列，那么采用栈可能是明智的，在栈中具有最高优先级且与下一最近的呼叫建立阶段相关联的语音提示总是位于栈的顶端。另一方面，如果没有为语音提示定义次序，则可以例如采用队列，其中按照检测的次序依次输入语音提示。

在为语音提示指定的所有呼叫建立阶段都必须检查包括语音提示数据的该数据结构，如果遇到这种阶段，则必须启动与该呼叫建立相关的数据结构项的处理。处理过程取决于存储中定义的数据结构的次序。此外，应当注意多于一个语音提示可以与同一阶段相关联；在遇到建立阶段时，必需播放所有必要的语音提示。

定义语音提示数据的数据结构也可以在无法播放语音提示的呼叫阶段中处理。例如，与呼叫相关的业务可以从数据结构中删除满足特定条件的所有语音提示。此外，业务可以控制语音提示的存储阶段的操作，例如使得尽管检测到语音提示需求，却不在数据结构中存储该语音提示，或者仅接受满足特定条件的语音提示。

下面，简要地描述本发明如何解决或减轻与现有技术语音提示处理相关的上述问题。

1.可以控制计费语音提示，使之在最近的可能的呼叫建立阶段启动。这样，可以尽量减少“不必要”的计费时间。如果在按照本发明设定的播放阶段发现计费语音提示不必要，则根本不需要启动计费。

2.将语音提示延迟到可以尽量确保呼叫建立成功的呼叫建立阶段，从而尽可能地减少不必要语音提示的数量。这种足够迟的阶段发生在等待用户B方向的ACM消息或者更迟，例如在从用户B方向接收到应答消息(ANM)。

3.将语音提示延迟到已经完成对需要多少拨号的分析的阶段。这种阶段可以是例如等待前向的ACM或应答的阶段。

4.因为语音提示直至到达所需的呼叫建立阶段或者遇到特定事件才播放，所以可以基于为所有语音提示定义的数据，并基于呼叫建立事件，优化所有的语音提示并排列优先级。换句话说，只要没有播放语音提示，就可以阻塞、接受或从数据结构中完全删除。优先级规则可以包括“仅播放具有最高优先级的语音提示”，“仅播放最近的语音提示”，“仅播放第一语音提示”，“语音提示X和语音提示Y互斥”，等等。

5.通过集中管理不同类型的数据(语音提示数据结构和/或其它属性)以及在同一呼叫中基于呼叫事件确定的语音提示，可以解决大多数问题。

6.将语音提示延迟到特定阶段播放，从而可以优化建立率，前述阶段中直到不延迟呼叫建立的话，例如也必须等待来自网络的消息时，才延迟正常的呼叫建立。

7.本发明的机制使以后需要在呼叫中播放的条件(该条件例如可以是呼叫中的某事件)语音提示可以预先存储。

下面结合附图，通过优选实施例来详细描述本发明，在附图中

图1说明了连接到智能网的电信网交换机；

图2示出了本发明第一优选实施例的信令；

图3示出了本发明第一优选实施例的流程图；

图4示出了本发明第四优选实施例的流程图；

图5说明了智能网的业务交换点；

图6说明了智能网的业务控制点；

图7说明了在现有技术呼叫建立过程中播放多个冲突的语音提示；以及

图8说明了本发明的呼叫建立，其中避免了所述冲突的语音提示。

本发明可以应用于在呼叫建立过程中播放语音提示的任何电信交换机。交换机一般包括公用电话交换网(PSTN)交换机和移动通信网(PLMN)交换机。交换机可以连接到智能网。下面以连接到智能网的交换机为例，说明本发明的优选实施例。

图1示出了智能网IN和与其关联的电信系统的一些例子。图1示出了与智能网业务相关的元件和功能。包括业务交换功能(SSF)和呼叫控制功能(CCF)的网元被称为业务控制点SSP。呼叫控制功能CCF不是与智能网关联的功能，而是交换机EX中的标准功能，包括交换机的高层呼叫处理功能，例如建立和释放传输连接。业务交换功能SSF是呼叫控制功能CCF和业务控制功能SCF之间的接口。SSF解释SCF所发送的请求，将其转发给CCF，CCF启动这些请求所要求的呼叫控制功能。相应地，CCF通过SSF向SCF请求指令。SSF固定地连接到CCF，充当CCF的接口。因此，每个SSF与CCF一起位于同一交换机EX中。

包括业务控制功能SCF的网元称为业务控制点(SCP)。业务控制功能是智能网的集中控制部分，包括例如业务逻辑程序的执行环境。对智能网业务而言，业务逻辑程序在业务控制点SCP中启动，该程序的操作决定了SCP在每个呼叫阶段中发送给SSP的指令。每个程序可以有多个执行实例。图1所示的业务控制点SCP是简化的业务控制点，仅包括业务控制功能SCF和必要的接口。

业务数据功能(SDF)是SCF所使用的数据库。业务逻辑程序可以查询和更新SDF信息。例如，用户特定或业务号码特定信息可以存储在SDF中。SDF可以是业务控制点SCP中的数据库管理系统，或者如图1所示，是支持SCF-SDF接口且包括数据库DB的单独的数据点(SDP)。

智能网的特殊资源功能(SRF)是涉及与用户交互的网络机制的接口。SRF可以与智能外设(IP)相连，IP包括比交换机更先进的呼叫处理功能，IP也可以位于业务交换点SSP。

图1还示出了交换机EX，它不属于智能网，除了CCF之外，它还包括向用户提供网络接入的呼叫控制代理功能(CCAF)。因为EX包括CCAF，所以它可以是公用电话交换网PSTN的本地交换机，或者控制移动网络PLMN的基站子系统BSS的移动业务交换中心MSC。CCAF也可以位于业务交换点。

在图1中，网元通过信令网SS7互连。也可以使用其它网络，例如ISDN。

智能网所定义的基本呼叫状态模型(BCSM)描述了交换机中呼叫建立的不同阶段。图2的状态图描述了按照ITU-T Q.1214的发端基本呼叫状态模型(O-BCSM)。在智能网规范中，将业务交换点执行的呼叫处理过程分组成粗略的阶段，称为呼叫内点(PIC)。在图2中，PIC由矩形框表示。与O_BCSM相关联的PIC包括：

“O_空闲&发端试呼授权”。主叫方表明她/他希望发出呼叫(用户线的摘机状态，ITU-T Q.931建立消息，例如IAM消息)，交换机检查她/他发出呼叫的权限/能力。

“收集信息”。交换机收集拨号信息，例如业务信息、前缀和拨入的地址数字。一般在必须检查是否得到足够的拨号的呼叫建立阶段中遇到“收集信息”。在接收到所需数量的数字或预定终止字符，或者控制定时器超时情况下，终止拨号信息的收集。可以从此沿分支到PIC“例外”，并通过DP“O_放弃”到PIC“O_空闲&始发尝试授权”。

“分析信息”。分集并/或按照拨号方案翻译所收集的信息，使得能够确定路由选择地址和呼叫类型。可以从此沿分支到PIC“例外”，并通过DP“O_放弃”到PIC“O_空闲&始发尝试授权”。

“路由选择和通知”。解释路由选择指令和呼叫类型，拨入下一路由。等待来自收端BCSM的被叫方应答事件指示。可以从此沿分支到PIC“路由选择失败”，“O_被叫忙”或“O_无人应答”。

“活跃”。连接建立。

在PIC阶段终止时，通常会遇到检测点(DP)。在图2中，DP由方形框表示。在这些检测点上可以临时终止呼叫建立或释放，向业务控制点SCP请求进一步的呼叫处理指令。在这些检测点上可以将呼叫管理转移到业务控制点。在从检测点DP转移到阶段PIC时，呼叫管理转移到交换点。除了PIC和检测点DP阶段之外，基本呼叫状态模型BCSM还包括转移和事件。转移指示了基本呼叫连接建立从一个PIC进行到另一PIC。事件导致出入PIC阶段的转移。在图2中，转移由箭头表示。业务交换点SSP和业务控制点SCP之间的消息称为操作。例如，SSP可能被设置成响应于“收集信息”操作，从收集用户拨号的PIC2阶段继续呼叫建立。在

一种操作是“播放语音提示”，SCP利用它请求交换机向呼叫方，一般是主叫用户，播放语音提示。目前，交换机在接收到通知之后立即播放语音提示。

参看图3，让我们接着考察按照基本呼叫状态模型O_BCSM的呼叫建立过程中现有技术的计费语音提示的播放。在这种情况下，用户B可以是例如应答服务或类似服务的电话。

在步骤3.1中，交换机(本例中移动业务交换机MSC)从前一交换机接收IAM消息。之后是步骤3.2的PIC“O_空闲”，步骤3.3的DP(“O_空闲”)，步骤3.4的PIC“发端试呼授权”，步骤3.5的DP(“发端试呼授权”)。MSC在步骤3.6中触发控制点SCP中的智能网业务。SCP发出“播放语音提示”操作，因此MSC播放语音提示。该语音提示可以是呼叫事件信息，例如“呼叫已传送”。因为语音提示是计费的，因此MSC在步骤3.8中激活计费。此外，MSC在后向上发送ACM消息和ANM消息，播放语音提示，从而前一交换机也在步骤3.9中激活计费。接着，SCP在步骤3.10中将呼叫建立控制返回给MSC。接着是步骤3.11中的PIC“收集信息”、“分析信息”和“路由选择”，以及步骤3.12中“通知”。但是，用户B没有应答，从而在步骤3.13和3.14中呼叫到达了检测点DP(“O_无人应答”)，并释放呼叫。但是，在语音提示和后续的呼叫建立过程中激活了计费，前述呼叫建立包括了等待用户B应答的时间。因此，对用户A进行了不必要的语音提示和失败呼叫的计费。

下面，参看图4，它描述了如何在按照O_BCSM状态模型的呼叫建立过程中按照本发明的优选实施例播放计费语音提示。

在步骤4.1中，交换机(本例中移动业务交换机MSC)从前一交换机接收IAM消息。之后是步骤4.2的PIC“O_空闲”，步骤4.3的DP(“O_空闲”)，步骤4.4的PIC“发端试呼授权”，步骤4.5的DP(“发端试呼授权”)。MSC在步骤4.6中触发智能网业务控制点SCP中的智能网业务。到此为止，呼叫建立如图3所示进行。SCP发出“播放语音提示”操作，除了通知应当播放哪个语音提示之外，它还通知何时播放语音提示，可能还通知在哪一项上播放语音提示。在图4的例子中，SCP请求MSC在从用户B方向接收到应答消息ANM之后播放语音提示。因此MSC并不立即播放语音提示，而是延迟播放语音提示，将语音提示相关数据置入适当的数据结构，例如语音提示栈中等待。MSC不需要向前一交换机发送ACM或启动计费。SCP在步骤4.8中将呼叫建立控制返回给MSC。接着是步骤4.9中的PIC“收集信息”、“分析信息”和“路由选择”。在这些PIC中，MSC以常规方式从用户B方向接收ACM消息，在用户A方向上发送该消息。步骤4.11中在PIC“O_通知”等待用户B的应答。但是，用户B没有应答，从而在步骤4.12和4.13中呼叫到达了检测点DP(“O_无人应答”)，并释放呼叫。因此，从未接收应答消息ANM以及播放语音提示的条件，也不播放计费语音提示或激活计费。这样，不对用户A进行不必要的语音提示和失败呼叫的计费。

参看图5，让我们接着考察采用的信令中由多个消息提供拨号的情况下，在按照O_BCSM状态模型的呼叫建立过程中现有技术语音提示的播放。

在步骤5.1中，交换机(本例中移动业务交换机MSC)从前一交换机接收IAM消息。之后是步骤5.2的PIC“O_空闲”，步骤5.3的DP(“O_空闲”)，步骤5.4的PIC“发端试呼授权”，步骤5.5的DP(“发端试呼授权”)。MSC在步骤5.6中触发控制点SCP中的智能网业务。在步骤5.7中，SCP请求“播放语音提示”操作，因此MSC在步骤5.8中立即在后向上发送ACM消息，并播放语音提示。接着，SCP在步骤5.9中将呼叫建立控制返回给MSC。接着是步骤5.10中的PIC“收集信息”。在检查拨入的数字数量时，发现(步骤5.11)需要附加数字进行号码分析。但是，MSC无法再从前一交换机接收附加拨号，因为基于步骤5.8中的语音提示已经发送了表明拨号完成的ACM消息。因此，在“收集信息”阶段不得不释放呼叫(步骤5.12）。

参看图6，让我们接着考察采用的信令中由多个消息提供拨号的情况下，在按照O_BCSM状态模型的呼叫建立过程中本发明的语音提示播放。

在步骤6.1中，交换机(本例中移动业务交换机MSC)从前一交换机接收IAM消息。之后是步骤6.2的PIC“O_空闲”，步骤6.3的DP(“O_空闲”)，步骤6.4的PIC“发端试呼授权”，步骤6.5的DP(“发端试呼授权”)。MSC在步骤6.6中触发控制点SCP中的智能网业务。到此为止，呼叫建立如图5所示进行。在步骤6.7中，SCP发出“播放语音提示”操作，除了通知应当播放哪个语音提示之外，它还通知何时播放语音提示，可能还通知在哪一项上播放语音提示。在图6的例子中，SCP请求MSC在分析了拨入的B号码之后，即在PIC“分析信息”之后播放语音提示。因此MSC并不立即播放语音提示，而是将语音提示相关数据置入适当的数据结构，例如语音提示栈中等待。此外，MSC不需要向前一交换机发送ACM。SCP在步骤6.8中将呼叫建立控制返回给MSC。接着是PIC“收集信息”，其中在检查拨入的数字之后，发现需要附加拨号(步骤6.9)。根据所用的信令，由特殊请求消息请求附加拨号，或者等待(定时器所确定的时间段)步骤6.10中是否仍在提供附加拨号。步骤6.11中接收所需的附加拨号，处理例程继续前进(步骤6.12)，经检测点DP(“信息已收集”)到PIC“分析信息”(步骤6.13)。呼叫建立在步骤6.14中到达检测点DP(“信息已分析”)，然后检查在该阶段是否存在需要播放的语音提示(步骤6.15)。因为在语音提示栈中发现步骤6.7中确定的语音提示，所以MSC在后向上向前一交换机发送ACM消息(步骤6.16)，并播放语音提示栈中发现的语音提示(步骤6.17)。接着，呼叫建立以常规方式进行(步骤6.18)。

参看图7，让我们接着考察按照O_BCSM状态模型的呼叫建立过程中，现有技术方式下多个冲突的语音提示的播放。在本例中，交换机控制呼叫建立的所有阶段。

在步骤7.1中，交换机(本例中移动业务交换机MSC)从前一交换机接收IAM消息。之后是步骤7.2的PIC“O_空闲”，步骤7.3的DP(“O_空闲”)，步骤7.4的PIC“发端试呼授权”。根据用户数据，交换机随后在步骤7.5中发现需要向用户A发送语音提示“您的呼叫免费”。MSC在后向上向前一交换机发送ACM消息(步骤7.6)，并向用户A播放语音提示(步骤7.7)。接着，呼叫在步骤7.8到步骤步骤7.12中经过检测点DP(“发端试呼授权”)、PIC“收集信息”、检测点DP(“信息已收集”)、PIC“分析信息”到达检测点DP(“信息已分析”)。号码分析之后，检测出不论给用户A打多少折，都涉及计费呼叫(步骤7.13)。需要在步骤7.14中向用户A发出与第一语音提示冲突的新的语音提示“呼叫费率每分钟15FIM”。接着，呼叫建立以常规方式继续。

下面参看图8，描述了如何按照本发明对语音提示进行优化或确定优先级，利用本发明可以避免上述多个冲突的语音提示的播放。在本例中，交换机控制呼叫建立的所有阶段。

在步骤8.1中，交换机(本例中移动业务交换机MSC)从前一交换机接收IAM消息。之后是步骤8.2的PIC“O_空闲”，步骤8.3的DP(“O_空闲”)，步骤8.4的PIC“发端试呼授权”。根据用户数据，交换机随后发现(步骤8.5)需要向用户A发送语音提示“您的呼叫免费”，语音提示类型是优先级为3的资费语音提示(步骤8.5)。到此为止，呼叫建立如图7所示进行。但是，MSC并不立即播放语音提示，而是将语音提示相关数据置入适当的数据结构，例如语音提示栈中等待(步骤8.6)。在本例中，存储必须在分析了拨入号码之后立即给出该语音提示的通知。接着在步骤8.7到8.11中呼叫经过检测点DP(“发端试呼授权”)、PIC“收集信息”、检测点DP(“信息已收集”)、PIC“分析信息”到达检测点DP(“信息已分析”)。号码分析之后，检测出不论给用户A打多少折，都涉及计费呼叫，需要向用户A发出语音提示“呼叫费率每分钟15 FIM”，语音提示类型是优先级为1的资费语音提示(步骤8.12)，语音提示通知存储在语音提示栈中。步骤8.13中，MSC在后向上发送ACM消息。交换机检查语音提示栈，察看是否已为所述检测点设置了资费语音提示。如果在栈中发现了两个或多个资费语音提示，则交换机比较这些语音提示的优先级，选择优先级较高的语音提示(步骤8.14)。然后，交换机播放选出的语音提示(步骤8.15)。因为在图8的例子中，步骤8.12中存储的语音提示具有较高优先级，所以选择它，从语音提示栈中删除第一语音提示(步骤8.6中存储)。因此，仅向用户A播放包含正确信息的一个语音提示。接着，步骤8.16中呼叫建立以常规方式进行。

在上例中，交换机仅在与每一例子描述相关的点上检查语音提示栈或相应的数据结构。但是，应当理解，交换机可以在为语音提示指定的所有呼叫建立阶段(例如所有检测点DP)上检查并处理语音提示栈。此外，也存在交换机检查并处理语音提示栈的其它点。

需要理解，以上描述及相关的图仅用于说明本发明。对本领域技术人员而言，显然可以在不偏离后附权利要求书所公开的本发明精神和范围的前提下，对本发明作出许多变化和改进。

Claims

1.电信网呼叫建立过程中的一种语音提示播放方法，该方法包括以下步骤：

在呼叫建立的给定阶段检测语音提示需求，其特征在于，该方法还包括以下步骤：

电信交换机将语音提示的播放延迟至呼叫建立的较后阶段，在该阶段证实语音提示是正确的或必要的，和/或在该阶段语音提示不会危及呼叫建立的成功。

2.根据权利要求1的方法，其特征在于，延迟语音提示的播放，直至确实已完成了附加拨号的收集。

3.根据权利要求1或2的方法，其特征在于，延迟语音提示的播放，直至呼叫建立无论如何要求电信交换机在主叫用户方向上发送了一个消息，该消息通知已完成拨号收集。

4.根据权利要求1的方法，其特征在于，延迟语音提示的播放，直至证实呼叫建立成功。

5.根据任一前述权利要求的方法，其特征在于，

在检测到语音提示需求时，至少存储选择该语音提示所需的数据。

6.根据权利要求1到4中任意一项的方法，其特征在于，

在检测到语音提示需求时，如果满足预定的存储条件，则至少存储选择该语音提示所需的数据。

7.根据权利要求5或6的方法，其特征在于，还存储以下信息项中的一项或多项：需要播放语音提示的呼叫建立阶段信息；用以确定在所需呼叫建立阶段播放或不播放语音提示的条件或规则；以及在涉及其它语音提示时如何处理语音提示的条件或规则。

8.根据权利要求5到7中任意一项的方法，其特征在于，

将呼叫的每一语音提示数据存储在数据结构，例如队列或栈的不同数据项中。

9.根据权利要求8的方法，其特征在于，

在为语音提示指定的所有呼叫建立阶段都检查所述数据结构，

处理该数据结构中与呼叫建立的当前阶段相关的所有数据结构数据项。

10.根据权利要求9的方法，其特征在于，

在无法进行语音提示的至少一个呼叫建立阶段处理所述数据结构，所述处理包括例如在满足预定条件时，从数据结构中删除一个或多个语音提示。

11.一种电信网交换机(EX)，包括：

在呼叫建立过程中检测语音提示需求的装置(4.7，6.7，8.5)，

至少向该呼叫中的一方播放语音提示的装置(6.17，8.15)，其特征在于，该交换机还包括

装置(4.7，6.7，6.15，8.5，8.12，8.14)，用于将电信交换机中语音提示的播放延迟至预定的呼叫建立的较后阶段，在该阶段完全确保该语音提示的正确性和必要性，和/或语音提示的播放不会危及呼叫建立的成功。

12.根据权利要求11的方法，其特征在于，交换机在呼叫特定的数据结构，例如栈或队列中，以专用数据项的形式存储(4.7，6.7，8.5，8.12)每一呼叫的不同语音提示数据。

13.根据权利要求12的交换机，其特征在于，所述数据至少包括选择该语音提示所需的数据，并可能包括以下信息项中的一项或多项：需要播放语音提示的呼叫建立阶段信息；用以确定在所需呼叫建立阶段播放或不播放语音提示的条件或规则；以及在涉及其它语音提示时如何处理语音提示的条件或规则。

14.根据权利要求12或13的交换机，其特征在于，交换机在为语音提示指定的所有呼叫建立阶段都检查(6.15，8.14)所述数据结构，并处理该数据结构中与当前呼叫建立阶段相关的所有数据项。

15.根据权利要求14的交换机，其特征在于，交换机在无法进行语音提示的至少一个呼叫建立阶段处理所述数据结构。