CN110225559A - 一种通话控制方法、装置、设备及存储介质 - Google Patents

Abstract

本发明公开了一种通话控制方法、装置、设备及存储介质，涉及通信技术领域，用于在呼叫失败时提示用户呼叫失败的原因，避免用户因呼叫失败产生恐慌焦虑的心理，造成不必要的人身财产损失，提升用户体验。所述方法包括：接收第一终端发起的对目标号码的呼叫请求；若当前无法处理所述呼叫请求，确定当前无法处理所述呼叫请求的原因；在当前无法处理所述呼叫请求的原因为网络侧拥堵时，向所述第一终端发送呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

Description

一种通话控制方法、装置、设备及存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种通话控制方法、装置、设备及存储介质。

背景技术

通话是手机、智能手表等终端的一种基本的功能，其在日常生活中使用十分广泛，也是人们较常使用的一种沟通方式。现实生活中，用户在拨打电话时可能存在着如因网络信号差或者网络拥堵等问题导致呼叫失败，而一旦呼叫失败的话网络侧则会挂断电话，而对于用户来说，却并不知道呼叫失败的具体原因，例如在报警或其它紧急情况下，这将会使得用户恐慌、焦虑的心理加重，进而给用户造成较大的不便，这可能会给用户造成无法挽回的经济损失，甚至危及到用户的生命安全。

由此可见，现有技术中存在着因呼叫失败给用户带来不便或造成的生命财产损失的技术问题。

发明内容

本申请实施例提供了一种通话控制方法、装置、设备及存储介质，用于在呼叫失败时提示用户呼叫失败的原因，避免用户因呼叫失败产生恐慌焦虑的心理，造成不必要的人身财产损失，提升用户体验。

第一方面，提供了一种通话控制方法，所述方法包括：

接收第一终端发起的对目标号码的呼叫请求；

若当前无法处理所述呼叫请求，确定当前无法处理所述呼叫请求的原因；

在当前无法处理所述呼叫请求的原因为网络侧拥堵时，向所述第一终端发送呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

可选的，所述呼叫失败反馈信息还用于指示是否继续等待建立通话连接，所述方法还包括：

保持所述呼叫请求；

接收所述第一终端基于所述呼叫失败反馈信息发送的指示等待信息，其中，所述指示等待信息用于指示所述第一终端能够等待建立通话连接；

根据所述等待指示信息，在所述网络侧能够处理所述呼叫请求时，建立所述第一终端与所述目标号码对应的第二终端之间的通话连接。

可选的，所述指示等待信息还用于指示用户设置的第一等待时长，所述第一等待时长为所述第一终端能够等待的与所述第二终端建立通话连接的最长时长；

则，在从接收所述指示等待信息时开始的所述第一等待时长内，若确定所述网络侧能够处理所述呼叫请求，则根据所述呼叫请求建立所述第一终端与所述第二终端之间的通话连接。

可选的，所述指示等待信息还用于指示用户设置的第一等待时长，所述第一等待时长为所述第一终端能够等待的与所述第二终端建立通话连接的最长时长；则在保持所述呼叫请求之后，所述方法还包括：

在从接收所述指示等待信息时开始达到所述第一等待时长后，确定所述网络侧是否仍处于网络拥堵状态；

若仍处于网络拥堵状态，则终止所述呼叫请求。

可选的，在确定所述网络侧是否仍然处于拥堵状态之前，所述方法还包括：

在接收所述指示等待信息时，确定所述网络侧结束网络拥堵状态所需要的第二等待时长；

确定所述第一等待时长大于或等于所述第二等待时长。

可选的，所述方法还包括：

若确定所述第一等待时长小于所述第二等待时长，则向所述第一终端发送等待不足提示信息，其中，所述等待不足提示信息用于指示所述网络侧在所述第一等待时长内无法处理所述呼叫请求。

可选的，在向所述第一终端发送等待不足提示信息之后，所述方法还包括：

确定所述目标号码是否是预设的紧急号码；

若是所述预设的紧急号码，则继续保持所述呼叫请求；

若不是所述预设的紧急号码，则终止所述呼叫请求。

可选的，所述呼叫失败反馈信息还用于指示第三等待时长，所述第三等待时长为所述网络侧结束网络拥堵状态的最短时长，则在保持所述呼叫请求之后，所述方法还包括：

在从发送所述呼叫失败反馈信息时开始达到第四等待时长时，建立所述第一终端与所述第二终端之间的通话连接；其中，所述第四等待时长为从发送所述呼叫失败反馈信息开始到实际处理所述呼叫请求之间的时长。

可选的，在向所述第一终端发送呼叫失败反馈信息之后，所述方法还包括：

接收所述第一终端发送的用于请求终止所述呼叫请求的终止请求信息；

根据所述终止呼叫请求信息，终止所述呼叫请求。

第二方面，提供一种通话控制方法，所述方法包括：

向网络侧发送请求与目标号码建立通话的呼叫请求；

接收所述网络侧发送的呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

可选的，所述呼叫失败反馈信息还用于指示是否继续等待建立通话连接，在接收所述呼叫失败反馈信息之后，所述方法还包括：

获得用户针对所述第一终端进行的第一操作；

根据所述第一操作，确定指示等待信息；其中，所述指示等待信息用于指示所述第一终端能够等待建立通话连接；

向所述网络侧发送所述指示等待信息。

可选的，所述指示等待信息还用于指示用户设置的第一等待时长，其中，所述第一等待时长为所述第一终端能够等待的与所述目标号码对应的第二终端建立通话连接的最长时长。

可选的，在接收所述网络侧发送的呼叫失败反馈信息之后，所述方法还包括：

获得用户针对所述第一终端进行的第二操作；

根据所述第二操作，生成终止请求信息，其中，所述终止呼叫请求信息用于请求终止所述呼叫请求；

向所述网络侧发送所述终止请求信息。

第三方面，提供了一种通话控制装置，所述装置包括：

第一接收单元，用于接收第一终端发起的对目标号码的呼叫请求；

第一确定单元，用于若当前无法处理所述呼叫请求，确定当前无法处理所述呼叫请求的原因；

反馈单元，用于在当前无法处理所述呼叫请求的原因为网络侧拥堵时，向所述第一终端发送呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

可选的，所述呼叫失败反馈信息还用于指示是否继续等待建立通话连接，所述装置还包括：

保持单元，用于保持所述呼叫请求；

第二接收单元，用于接收所述第一终端基于所述呼叫失败反馈信息发送的指示等待信息，其中，所述指示等待信息用于指示所述第一终端能够等待建立通话连接；

通话建立单元，用于根据所述等待指示信息，在所述网络侧能够处理所述呼叫请求时，建立所述第一终端与所述目标号码对应的第二终端之间的通话连接。

可选的，所述指示等待信息还用于指示用户设置的第一等待时长，所述第一等待时长为所述第一终端能够等待的与所述第二终端建立通话连接的最长时长；所述通话建立单元，用于：

在从接收所述指示等待信息时开始的所述第一等待时长内，若确定所述网络侧能够处理所述呼叫请求，则根据所述呼叫请求建立所述第一终端与所述第二终端之间的通话连接。

可选的，所述指示等待信息还用于指示用户设置的第一等待时长，所述第一等待时长为所述第一终端能够等待的与所述第二终端建立通话连接的最长时长；所述装置还包括终止请求单元，用于：

在从接收所述指示等待信息时开始达到所述第一等待时长后，确定所述网络侧是否仍处于网络拥堵状态；

若仍处于网络拥堵状态，则终止所述呼叫请求。

可选的，所述装置还包括第二确定单元，还用于：

在所述终止请求单元确定所述网络侧是否仍然处于拥堵状态之前，在接收所述指示等待信息时，确定所述网络侧结束网络拥堵状态所需要的第二等待时长；

确定所述第一等待时长大于或等于所述第二等待时长。

可选的，所述第二确定单元还用于：

若确定所述第一等待时长小于所述第二等待时长，则向所述第一终端发送等待不足提示信息，其中，所述等待不足提示信息用于指示所述网络侧在所述第一等待时长内无法处理所述呼叫请求。

可选的，所述装置还包括第三确定单元，用于：

在所述第二确定单元向所述第一终端发送等待不足提示信息之后，确定所述目标号码是否是预设的紧急号码；

若是所述预设的紧急号码，则继续保持所述呼叫请求；

若不是所述预设的紧急号码，则终止所述呼叫请求。

可选的，所述呼叫失败反馈信息还用于指示第三等待时长，所述第三等待时长为所述网络侧结束所述拥堵状态的最短时长，所述建立通话单元还用于：

在所述第二确定单元向所述第一终端发送等待不足提示信息之后，在从发送所述呼叫失败反馈信息时开始达到第四等待时长时，建立所述第一终端与所述第二终端之间的通话连接；其中，所述第四等待时长为从发送所述呼叫失败反馈信息开始到实际处理所述呼叫请求之间的时长。

可选的，所述终止请求单元还用于：

在所述第二确定单元向所述第一终端发送呼叫失败反馈信息之后，接收所述第一终端发送的用于请求终止所述呼叫请求的终止请求信息；

根据所述终止呼叫请求信息终止所述呼叫请求。

第四方面，提供一种通话控制装置，所述装置包括：

发送单元，用于向网络侧发送请求与目标号码建立通话的呼叫请求；

接收单元，用于接收所述网络侧发送的呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

可选的，所述呼叫失败反馈信息还用于指示是否继续等待建立通话连接，所述发送单元还用于：

在接收所述呼叫失败反馈信息之后，获得用户针对所述第一终端进行的第一操作；

根据所述第一操作，确定指示等待信息；其中，所述指示等待信息用于指示所述第一终端能够等待建立通话连接；

向所述网络侧发送所述指示等待信息。

可选的，所述指示等待信息还用于指示用户设置的第一等待时长，其中，所述第一等待时长为所述第一终端能够等待的与所述目标号码对应的第二终端建立通话连接的最长时长。

可选的，所述发送单元还用于：

在接收所述网络侧发送的呼叫失败反馈信息之后，获得用户针对所述第一终端进行的第二操作；

根据所述第二操作，生成终止请求信息，其中，所述终止呼叫请求信息用于请求终止所述呼叫请求；

向所述网络侧设备发送所述终止请求信息。

第五方面，提供一种通话控制设备，所述设备包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行第一方面中任一所述的方法包括的步骤。

第六方面，提供一种通话控制设备，所述设备包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行第二方面中任一所述的方法包括的步骤。

第七方面，提供一种存储介质，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行第一方面中任一方法包括的步骤。

第八方面，提供一种存储介质，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行第二方面中任一方法包括的步骤。

在本申请实施例中，当网络侧接收到第一终端向目标号码发起的呼叫请求后，可以先判断当前是否能够处理该呼叫请求，并在无法处理该呼叫请求时确定无法处理呼叫请求的具体原因，若确定当前无法处理该呼叫请求的原因是由于网络拥堵，则可以向第一终端发送呼叫失败反馈信息，以通过该呼叫失败反馈信息告知使用第一终端的用户当前由于是网络拥堵而无法立即建立通话，也就是说，在第一终端发起的呼叫请求失败后，网络侧可以及时地告知用户本次呼叫失败是由于网络拥堵，从而对用户进行了有效提示，因此，例如在拨打110等紧急打电话时，用户可以知晓呼叫失败的具体原因是由于网络拥堵，而并非是其它不可知的原因，这样可以安抚处于恐慌或焦急状态的用户，避免用户因不知道呼叫失败的具体原因而盲目地做出过激行为，进而避免一些财产损失甚至生命危险，提升用户体验感。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例。

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的另一种应用场景示意图；

图3为本申请实施例提供的通话控制方法的流程图；

图4a为本申请实施例提供的通话控制装置的结构框图；

图4b为本申请实施例提供的通话控制装置的另一结构框图；

图5为本申请实施例提供的通话控制装置的另一结构框图；

图6为本申请实施例提供的通话控制设备的结构示意图；

图7为本申请实施例提供的通话控制设备的另一结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明技术方案保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本发明的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例中，“多个”可以表示至少两个，例如可以是两个、三个或者更多个，本申请实施例不做限制。

为了便于理解，下面先对本发明实施例的技术背景进行介绍。

如前文叙述，现有技术中，当出现如网络堵塞等原因时，可能出现呼叫失败的情况，例如，呼叫控制中心在接收到终端A发起的对目标号码的呼叫请求后，检测到当前网络拥堵、待处理呼叫请求量超负荷等情况，导致当前无法处理终端A发起的呼叫请求，从而无法建立终端A与目标号码对应的终端(例如终端B)之间的通话连接，进而直接挂断终端A的呼叫，但终端A的用户并不知晓为什么不能成功建立通话，所以当用户遇到紧急情况时，容易因呼叫失败产生恐慌、焦虑的心情，进而给用户带来不便，甚至还可能影响用户的财产甚至人生安全。

鉴于此，本申请人的发明人提供了一种通话控制的技术方案，该方案中，在接收到第一终端向目标号码发起的呼叫请求后，网络侧可以根据自身网络情况确定当前是否可以处理该呼叫请求，在不能处理该呼叫请求时，网络侧并不立即终止该呼叫请求，而是确定无法处理该呼叫请求的原因，并在确定出无法处理该呼叫请求的原因是网络拥堵时，向第一终端发送呼叫失败反馈信息，提示第一终端的用户呼叫请求失败的原因，因此可以安抚处于恐慌或焦急状态的用户，避免用户因不知道呼叫失败而盲目做出过激行为，提升用户体验感。

进一步地，在向第一终端发送呼叫失败反馈消息的同时，网络侧可以继续保持呼叫请求，而并不是如现有技术中一样直接挂断电话，进而在网络不再拥堵而能够处理该呼叫请求的时候，且满足预定触发条件(例如接收到第一终端发送的特定信息)时，就可以及时地建立第一终端与目标号码对应的终端(例如称作第二终端)之间的通话连接，以即使地响应第一终端的呼叫请求，尽快地建立第一终端与第二终端之间的通话，以尽量提高呼叫的效率，以及提高呼叫成功的概率。

在介绍完本申请实施例的设计思想后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

请参见图1所示的一种应用场景示意图，该应用场景中包括终端10、终端11和网络侧设备12，其中，终端10和终端11可以是手机、智能手表、固定电话等具有通话功能的终端，例如终端10为主叫终端，终端11为被叫终端；网络侧设备12可以是由建立终端10和终端11之间的通话连接所必须的一个或多个网络设备组成的系统，网络侧设备12例如也可以称为网络侧或呼叫控制中心。

当网络侧设备12接收到终端10发起的对目标号码的呼叫请求后，网络侧设备12可以判断当前是否可以处理该呼叫请求，若不能处理该呼叫请求，则确定出不能处理该呼叫请求的原因，当确定出不能处理呼叫请求的原因为网络拥堵时，网络侧设备12可以向终端10发送用于告知用户网络侧拥堵的呼叫失败反馈信息。同时可以保持该呼叫请求，进而在网络不拥堵时再及时地建立终端10和终端11之间的通话连接，以提高终端10成功拨打电话的概率。

请参见图2所示的另一种应用场景示意图，该应用场景中包括主叫终端20、至少一个被叫终端22和网络侧设备21，其中，主叫终端20和被叫终端22可以是手机，也可以是智能手表、固定电话等具有通话功能的终端，至少一个被叫终端22由一个或者多个服务器(也可以称作控制中心)进行管理，至少一个被叫终端22可以对应一个目标号码，例如，一些客服热线只有一个号码，但对应有多个固定电话，或者例如一些报警电话(例如110或119)也对应多个电话终端，用户在拨打客服热线或者报警电话后，控制中心可以将该呼叫请求分配到当前处于空闲状态的固定电话，从而建立通话连接。

网络侧设备21可以是由建立主叫终端20和被叫终端22之间的通话连接所必须的一个或多个设备组成的系统，例如图2所示，网络侧设备21包括基站和服务器，或者还可以包括其它网络设备。基站在接收到主叫终端20发起的呼叫请求后，会将该呼叫请求发送给服务器处理，进而由服务器控制其对应的至少一个被叫终端22中处于空闲状态的被叫终端22(或者其它特定的被叫终端22)建立与主叫终端20之间的通话连接。其中，网络侧设备21也可以称为网络侧或呼叫控制中心。

图2中的网络侧设备21的实施与图1中的网络侧设备12的实施是类似的，对于网络侧设备21的理解可以参照前述的网络侧设备12的实施部分的描述，此处就不再重复说明了。

在图1或图2所示的应用场景中，网络侧拥堵可以是由于基站处待处理的呼叫请求数量较多而导致的，也可以是由于管理被叫终端的服务器处待处理的呼叫请求数量较多而导致的，或者可以是由于服务器临时掉电或其它原因导致的。

为进一步说明本申请实施例提供的通话控制的方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。所述方法在实际的处理过程中或者装置执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的应用环境)。

请参考图3，图3为本申请实施例提供的通话控制方法的流程图，在图3中是以第一终端为主叫终端、第二终端为被叫终端为例进行说明的。图3中的通话控制方法的流程描述如下。

步骤301：第一终端向网络侧发送用于请求与目标号码建立通话的呼叫请求，则网络侧可以接收到该呼叫请求。

本申请实施例中，请结合前面的图1和图2的应用场景进行理解。第一终端可以是如图1所示的终端10，或者是如图2所示的终端20，第一终端中安装有至少一张用户身份识别卡，用户身份识别卡对应一个号码；目标号码可以是与如图1中所示的终端11的号码，也可以是如图2所示的对应有多个被叫终端的号码；所以，呼叫请求中可以携带有第一终端的号码和被呼叫的目标号码。网络侧可以是指如图1所示的网络侧设备12，或者如图2中所示的网络侧设备21，在本文中，可以将网络侧称为网络侧设备，即，本申请实施例中的网络侧和网络侧设备可以作相同理解。

步骤302：网络侧设备判断当前是否可以处理第一终端发起的对目标号码的呼叫请求，若是，则执行步骤303，若否，则执行步骤304。

步骤303：建立第一终端与目标号码之间的通话连接。

在本申请实施例中，当网络侧设备当前可以处理第一终端发起的对目标号码的呼叫请求时，可以处理该呼叫请求，以建立第一终端和目标号码对应的终端，例如图2中的第二终端，之间的通话连接，在通话连接建立之后，则进入通话阶段。

步骤304：网络侧设备确定当前无法处理呼叫请求的原因。

在本申请实施例中，导致网络侧设备无法处理呼叫请求的原因可能存在多种，可以是如前文所述的网络侧设备当前待处理的呼叫请求数量超过了网络侧设备能够处理的呼叫请求总数量，例如网络侧设备中的基站处待处理的呼叫请求超过负荷量；或者是如图2中所示的网络侧设备中的服务器当前待处理呼叫请求数量超过负荷量；也可以是如图2中所示的网络侧设备中的基站和服务器当前待处理的呼叫请求数量都超过了负荷量；还可以是网络侧设备中的某一设备发生掉电情况，例如，如图2所示的服务器发生掉电状况，致使服务器未接收到或未及时处理基站发送的第一终端发起的对目标号码的呼叫请求。或者还可以是网络侧设备中某一处信号传输线老化断裂等等。

具体的，本申请实施例中可以将前文所述的网络侧设备当前待处理的呼叫请求数量超过了网络侧设备能够处理的呼叫请求总数量的情况都看作是网络拥堵状态，例如，假设网络侧设备中的基站能够处理的呼叫请求数量为300，第一终端发起的对目标号码的呼叫请求为基站接收到的第301条呼叫请求，则可以确定当前网络侧设备处于网络拥堵状态，需要等待。进一步地，本申请实施例中还可以将网络侧设备处理的呼叫请求数量超负荷之外的造成无法处理呼叫请求的原因统称为网络异常状态。

其中，网络拥堵状态是指网络侧设备可以接收到第一终端发起对目标号码的呼叫请求，只是当前等待处理的呼叫请求较多，需要等待一段时间后才能处理第一终端发起的呼叫请求，也就是说，在网络拥堵状态下，第一终端、网络侧设备以及目标号码对应的第二终端之间的通信链路异常、掉电和线路损坏等网络异常的问题，仅是因为待处理的呼叫请求量较多，等待一定时间后该呼叫请求就可以被处理，所以，为了提示第一终端的用户其发起的呼叫请求是能够被处理的，有必要将无法处理呼叫请求的原因为网络拥堵状态告知用户，以安抚处于紧急状态下产生的恐慌、焦虑的心理。而前述的网络异常状态则是指第一终端、网络侧设备以及第二终端之间的通信链路出现问题、或者是掉电、线路损坏等问题，造成网络侧设备不能接收到第一终端发起的呼叫请求，或是第一终端因网络信号差未发送出呼叫请求。

步骤305：若网络侧设备确定出当前无法处理所述呼叫请求的原因为网络拥堵，则获得呼叫失败反馈信息。

在本申请实施例中，呼叫失败反馈信息用于指示网络侧设备当前处于网络拥堵状态，需要等待处理呼叫请求。其中，呼叫失败反馈信息可以是网络侧设备预先设置的预定信息，当发生网络拥堵时则可以直接获得；或者也可以是根据确定的网络拥堵状态临时生成的信息。

具体的，呼叫失败反馈信息可以是短信文本，也可以是一段语音，若呼叫失败反馈信息是一段语音，例如，可以是“当前待处理呼叫请求多，请耐心等待”这样的语音。当然，为了避免时间太长影响网络侧设备对呼叫请求的处理，应当呼叫失败反馈信息中语音的时长控制在合理的时间范围内。

步骤306：网络侧设备向第一终端发送呼叫失败反馈信息，相应的，第一终端可以接收到网络侧设备发送的该呼叫失败反馈信息。

在本申请实施例中，当确定出当前无法处理第一终端发送的呼叫请求的原因是因为网络堵塞时，可以向第一终端发送呼叫失败反馈信息，该呼叫失败反馈信息用于提示用户当前网络侧设备处理网络拥堵状态，无法及时处理第一终端发送的呼叫请求，避免用户因不知晓呼叫失败的原而产生恐慌或焦虑的心情，所以可以安抚用户的心情，提升了用户体验感，同时还避免用户在焦急或恐慌状态下做出不适当的行为造成的人身或财产损失。

进一步地，呼叫失败反馈信息中还可以用于指示是否继续等待建立通话连接，也就是说，在通过呼叫失败反馈信息对用户进行网络拥堵的有效提示的同时，还可以通过呼叫失败反馈信息告知使用用户可以继续等待，而不直接挂断电话，即保持用户的呼叫请求，以在网络侧能正常处理呼叫请求时就及时地建立与目标号码之间的通话连接，进而提高呼叫的成功率和呼叫效率，便于在一次呼叫失败后能够持续的呼叫。

其中，呼叫失败反馈信息中可以包括网络侧设备结束网络拥堵状态所需的最短时长，也可以不包括该最短时长。当呼叫失败反馈信息中包括该最短时长时，网络侧设备可以在向第一终端发送呼叫失败反馈信息之前，确定解决当前网络拥堵状态并可以处理第一终端发送的呼叫请求所需的最短时长，即网络侧设备结束网络拥堵状态所需的最短时长，本申请实施例中可以将该最短时长可称为第三等待时长。进而用户可以根据包括第三等待时长的呼叫失败反馈消息，知晓呼叫请求至少还需要等待多长时间才能被处理，以避免用户因不知晓还需等待多长时间而产生焦虑或恐慌的心理，并方便用户根据需要等待的时长做出相应的决定。

步骤307：保持呼叫请求。

其中，步骤307可以与步骤306可以同时执行，即网络在向第一终端发送呼叫失败反馈消息时就保持该呼叫请求；也可以在步骤306之前执行，即先保持该呼叫请求再向第一终端发送呼叫失败反馈消息；或者还可以在步骤306之后执行，即，先向第一终端发送呼叫失败反馈消息再保持呼叫请求，本申请实施例中，对步骤307和步骤306的执行顺序不做限制，后续以步骤307在步骤306之后执行为例进行举例说明。

在本申请实施例中，当网络侧设备确定出当前无法处理第一终端发起的对目标号码的呼叫请求时，并不会立即终止该呼叫请求，即不会挂断用户通过第一终端拨打的电话，而是保持该呼叫请求，从而可以避免在终止呼叫请求后，需要第一终端重新发送起对目标号码的呼叫请求，所以可以节约呼叫时间，提高呼叫效率。

步骤308：第一终端在接收的呼叫失败反馈信息后，检测针对该第一终端的第一操作，并根据该第一操作确定指示等待信息。

其中，指示等待信息用于指示所述第一终端能够等待建立通话连接。

在本申请实施例中，第一终端在接收到呼叫失败反馈信息后，第一终端的用户可以根据该呼叫失败反馈信息的内容进行第一操作，从而可以根据第一操作确定指示等待信息。其中，第一操作可以通过点击操作或按键操作获取，也可以通过语音方式获取，或者还可以通过其它操作方式获取。

例如，可以假设第一操作为按数字键的操作时，表示第一终端需要继续等待建立通话连接；又假设第一操作为按“*”号键的操作时，表示第一终端主动请求挂断电话。

在本申请实施例中，指示等待信息可以仅指示第一终端需要等待建立通话连接，不限制等待建立通话连接的时长，也可以同时指示第一终端能够等待建立通话连接以及对应可以等待的时长，例如称作第一等待时长，第一等待时长可以为第一终端能够等待的与第二终端建立通话连接的最长时长。

其中，第一等待时长可以是在呼叫失败反馈信息中未指示有第三等待时长时，用户通过第一操作自行设置自己愿意等待的时长，在例如可以设置第一操作为按数字键“1”时，表示第一终端需要等待8s，那么第一终端在检测到按数字键“1”的第一操作时，则确定指示等待信息指示的等待时长为8s。再如，第一操作也可以为依次按压数字键“1”和“2”的操作，来表示第一终端需要等待12s，那么第一终端在检测到迅速按压数字键“1”和“2”的操作时，则确定指示等待信息中指示等待时长为12s。

进一步地，在呼叫失败反馈信息中指示有第三等待时长，即网络侧设备结束网络拥堵最短时长时，可以通过第一操作直接将第一等待时长确定为与第三等待时长相同的时长。例如，假设呼叫失败反馈信息中指示的第三等待时长为10s，则直接将第一操作对应的第一等待时长确定为10s。

当然，在呼叫失败反馈信息中指示有第三等待时长，用户也可以通过第一操作自行设置第一等待时长，不受第三等待时长的限制。例如，假设呼叫失败反馈信息中指示的第三等待时长为10s，用户可以通过第一操作设置小于、等于或者大于10s的任何时长。一般来说，在呼叫失败反馈信息中明确指示了网络侧最快能够结束拥堵状态的第三等待时长时，为了确保呼叫请求在用户设置的第一等待时长内能够被处理，用户对应设置的第一等待时长一般大于或者等于第三等待时长。

步骤309：第一终端向网络侧设备发送指示等待信息，相应的，网络侧设备可以接收第一终端基于呼叫失败反馈信息发送的指示等待信息。

本申请实施例中，第一终端在根据用户的第一操作确定出指示等待信息后，可以向网络侧设备发送确定出的指示等待信息，进而网络侧设备可以接收到第一终端发送的指示等待信息，以根据该指示等待信息明确用户当前能够继续等待，所以可以继续保持呼叫请求而不挂断电话。

步骤310：网络侧设备根据接收到的指示等待信息，确定能够处理该呼叫请求的时机，并该时机时处理第一终端发起的对目标号码的呼叫请求，以建立第一终端与第二终端之间的通话连接。

在本申请实施例中，如前文所述，指示等待信息可以用于指示第一终端能够等待建立通话连接，那么，网络侧设备在接收到该指示等待信息后，网络侧设备则会等待能够处理该呼叫请求的时间，一旦确定能够处理，则及时地处理该呼叫请求时，以尽快地建立第一终端与第二终端之间的通话连接。

在本申请实施例中，如前文所述，指示等待信息中也可以并不指示第一终端等待建立通话连接的时长，即不设置等待的时间，只要网络侧设备结束拥堵就可以及时建立第一终端与第二终端之间的通话连接。也就是说，可以不考虑等待建立通话的时间，只需在网络侧设备结束拥堵时建立第一终端与目标号码对应的第二终端之间的通话连接即可。

在本申请实施例中，若指示等待信息中指示了用户设置的第一终端等待建立通话的时长为第一等待时长，那么网络侧设备在从接收到该指示等待信息时开始到达第一等待时长内，若确定出网络侧能够处理所述呼叫请求，则可以根据该呼叫请求建立第一终端与第二终端之间的通话连接。

进一步地，在网络侧设备在从接收到该指示等待信息时开始到达第一等待时长后，网络侧设备还可以确定其是否处于拥堵状态，若仍确定该网络侧设备处于拥堵状态，即表明在用户指定的时间内还是无法处理第一终端发起的呼叫请求，此时则可即终止该呼叫请求，以节约用户时间。

作为一种可选的实施例，在本申请实施例中，网络侧设备在从接收到该指示等待信息时开始到达第一等待时长后，且判断其是否处于拥堵状态之前，网络侧设备还可以确定结束网络拥堵状态所需的第二等待时长，其中，为了确保网络侧设备在等待第一等待时长内，能够处理第一终端发起的呼叫请求，建立第一终端与目标号码对应的第二终端之间的通话连接，以提高呼叫效率，第一等待时长可以大于或等于第二等待时长。例如，第二等待时长为10s，则第一等待时长则为12s。

当然，由于第一等待时长可以由第一终端的用户自行设置，所以可能存在第一等待时长小于第二等待时长的情况，也就是说，在到达设置的等待建立通话的时间后，若网络侧设备仍处于拥堵状态，无法处理第一终端发起的呼叫请求，从而也可能存在用户因不知道呼叫失败的原因而产生恐慌和焦虑的情况。所以，为了避免这种情况的出现，在确定出第一等待时长小于第二等待时长时，网络侧设备可以发送等待不足提示信息，其中，等待不足提示信息用于指示网络侧设备在第一等待时长内无法处理所述呼叫请求，这样，通过等待不足提示信息可以明确告知用户在其设置的等待时长内仍旧无法处理其发起的呼叫请求，以进一步地对用户进行有效提示。

进一步地，网络侧设备在向所述第一终端发送等待不足提示信息之后，还可以确定目标号码是否是预设的紧急号码，例如预设的紧急号码是110、119等报警电话或者120等急救电话，若目标号码是预设的紧急号码，即表明用户当前所处情形是比较危急的，则可以继续保持第一终端发起的呼叫请求，并且可以再次向第一终端发送呼叫失败反馈信息，以再次告知第一终端的用户呼叫失败的原因，这样可以尽量多次安抚处于危急情形的用户，以尽量降低用户的交焦虑恐慌情绪，可以避免因用户在紧急状况下因无法打通电话而做出不适当的行为，或者遭受不必要的人身、财产损失；若不是预设的紧急号码，则可以终止该呼叫请求，这样可以避免用户浪费等待时间，以便用户及时选择其他处理方式处理当前紧急情况。

进一步地，在一种可能的实施方式中，由于第三等待时长是根据网络侧结束网络拥堵状态，即根据处理完在第一终端发起的呼叫请求之前的其它等待处理的呼叫请求所需的时间确定的，根据网络的情况，可能会出现确定出的处理时间与实际所需的处理时间不相同的情况，所以，可以将网络侧设备从发送呼叫失败反馈信息开始到实际开始处理呼叫请求之间的实际时长称为第四等待时长。其中，第三等待时长可能与第四等待时长相同，也可能不同，即第四等待时长可能大于第三等待时长，也可以小于或等于第三等待时长。一般第三等待时长和第四等待时长的差值都不会太大，保持在一个预定差值范围内。那么，当呼叫失败反馈信息中指示有第三等待时长，网络侧设备可能在从发送呼叫失败反馈信息开始到达第四等待时长时，建立第一终端与目标号码对应的第二终端之间的通话连接。

例如，第三等待时长为15s，若实际上网络侧设备在第12s时已经处理完除第一终端发起的呼叫请求之外的呼叫请求，即第四等待时长为12s，所以，网络侧设备实际上是在等待12s后就开始处理第一终端发起的呼叫请求，建立第一终端与第二终端之间的通话连接。

步骤311：第一终端根据接收的呼叫失败反馈信息，检测第二操作，并根据第二操作确定终止呼叫请求的终止请求信息。

在本申请实施例中，当第一终端接收到网络侧设备发送呼叫失败反馈信息之后，第一终端的用户可以通过第二操作选择终止该呼叫请求，进而第一终端可以根据检测到的第二操作生成确定终止呼叫请求的终止请求信息。其中，第二操作可以是用户基于呼叫失败反馈信息，按下第一终端中对应的功能键的按键操作，也可以是用户发出的语音。

也就是说，用户在根据呼叫失败反馈信息的提示，知晓当前无法打通电话的具体原因之后，可以根据自己当前的实际情况选择主动的挂断电话，以便于进行其它操作或者采用其他的处理方式，以满足不同用户的差异化需求。

步骤312：第一终端向网络侧设备发送终止请求信息，则，网络侧设备可以接收到第一终端发送的终止请求信息。

步骤313：网络侧设备根据终止请求信息，终止呼叫请求。

在本申请实施例中，当网络侧设备接收到终止请求信息后，可以根据该终止请求信息，终止第一终端发起的对目标号码对应的第二终端的呼叫请求，从而第一终端可以发起对其他号码的呼叫请求，避免因等待与目标号码对应的终端建立通话连接造成的时间和电能的浪费。

所以通过上述方法，在本申请实施例中，在接收到第一终端向目标号码发起的呼叫请求后，网络侧可以根据自身网络情况确定当前是否可以处理该呼叫请求，在不能处理该呼叫请求时，网络侧并不立即终止该呼叫请求，而是确定无法处理该呼叫请求的原因，并在确定出无法处理该呼叫请求的原因是网络拥堵时，向第一终端发送呼叫失败反馈信息，提示第一终端的用户呼叫请求失败的原因，因此可以安抚处于恐慌或焦急状态的用户，避免用户因不知道呼叫失败做出过激行为，提升用户体验感。

进一步地，在向第一终端发送呼叫失败反馈消息的同时，网络侧可以继续保持呼叫请求，而并不是如现有技术中一样直接挂断电话，进而在网络不再拥堵而能够处理该呼叫请求的时候，且满足预定触发条件(例如接收到第一终端发送的特定信息)时，就可以及时地建立第一终端与目标号码对应的终端(例如称作第二终端)之间的通话连接，以即使地响应第一终端的呼叫请求，尽快地建立第一终端与第二终端之间的通话，以尽量提高呼叫的效率，以及提高呼叫成功的概率。

基于同一发明构思，本申请实施例中提供了一种通话控制装置，该通话控制装置可以是硬件结构、软件模块、或硬件结构加软件模块，该通话控制装置可以由芯片系统实现，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。如图4a所示，该通话控制装置包括第一接收单元401、第一确定单元402和反馈单元403。其中：

第一接收单元401，用于接收第一终端发起的对目标号码的呼叫请求；

第一确定单元402，用于若当前无法处理呼叫请求，确定当前无法处呼叫请求的原因；

反馈单元403，用于在当前无法处理呼叫请求的原因为网络侧拥堵时，向第一终端发送呼叫失败反馈信息，其中，呼叫失败反馈信息用于指示网络侧当前处于网络拥堵状态。

可选的，呼叫失败反馈信息还用于指示是否继续等待建立通话连接，请参见图4b所示，该通话控制装置还包括：

保持单元404，用于保持呼叫请求；

第二接收单元405，用于接收第一终端基于呼叫失败反馈信息发送的指示等待信息，其中，指示等待信息用于指示第一终端能够等待建立通话连接；

通话建立单元406，用于根据等待指示信息，在网络侧能够处理呼叫请求时，建立第一终端与目标号码对应的第二终端之间的通话连接。

可选的，指示等待信息还用于指示用户设置的第一等待时长，第一等待时长为第一终端能够等待的与第二终端建立通话连接的最长时长；通话建立单元406，用于：

在从接收指示等待信息时开始的第一等待时长内，若确定网络侧能够处理呼叫请求，则根据呼叫请求建立第一终端与第二终端之间的通话连接。

可选的，指示等待信息还用于指示用户设置的第一等待时长，第一等待时长为第一终端能够等待的与第二终端建立通话连接的最长时长；如图4b所示，该通话控制装置还包括终止请求单元407，用于：

在从接收指示等待信息时开始达到第一等待时长后，确定网络侧是否仍处于网络拥堵状态；

若仍处于网络拥堵状态，则终止呼叫请求。

可选的，如图4b所示，该通话控制装置还包括第二确定单元408，用于：

在终止请求单元407确定网络侧是否仍然处于拥堵状态之前，在接收指示等待信息时，确定网络侧结束网络拥堵状态所需要的第二等待时长；

确定第一等待时长大于或等于第二等待时长。

可选的，第二确定单元408还用于：

若确定第一等待时长小于第二等待时长，则向第一终端发送等待不足提示信息，其中，等待不足提示信息用于指示网络侧在第一等待时长内无法处理呼叫请求。

可选的，如图4b所示，该通话控制装置还包括第三确定单元409，用于：

在第二确定单元408向第一终端发送等待不足提示信息之后，确定目标号码是否是预设的紧急号码；

若是预设的紧急号码，则继续保持呼叫请求；

若不是预设的紧急号码，则终止呼叫请求。

可选的，呼叫失败反馈信息还用于指示第三等待时长，第三等待时长为网络侧结束网络拥堵状态的最短时长，建立通话单元406还用于：

在第二确定单元向第一终端发送等待不足提示信息之后，在从发送呼叫失败反馈信息时开始达到第四等待时长时，建立第一终端与第二终端之间的通话连接；其中，第四等待时长为从发送呼叫失败反馈信息开始到实际处理呼叫请求之间的时长。

可选的，终止请求单元407还用于：

在第二确定单元408向第一终端发送呼叫失败反馈信息之后，接收第一终端发送的用于请求终止呼叫请求的终止请求信息；

根据终止呼叫请求信息终止呼叫请求。

基于同一发明构思，本申请实施例中提供了一种通话控制装置，该通话控制装置可以是硬件结构、软件模块、或硬件结构加软件模块。该通话控制装置可以由芯片系统实现，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。如图5所示，该通话控制装置包括发送单元501和接收单元502。其中：

发送单元501，用于向网络侧发送请求与目标号码建立通话的呼叫请求；

接收单元502，用于接收网络侧发送的呼叫失败反馈信息，其中，呼叫失败反馈信息用于指示网络侧当前处于网络拥堵状态。

可选的，呼叫失败反馈信息还用于指示是否继续等待建立通话连接，发送单元501还用于：

在接收呼叫失败反馈信息之后，获得用户针对第一终端进行的第一操作；

根据第一操作，确定指示等待信息；其中，指示等待信息用于指示第一终端能够等待建立通话连接；

向网络侧发送指示等待信息。

可选的，指示等待信息还用于指示用户设置的第一等待时长，其中，第一等待时长为第一终端能够等待的与目标号码对应的第二终端建立通话连接的最长时长。

可选的，发送单元501还用于：

在接收网络侧发送的呼叫失败反馈信息之后，获得用户针对第一终端进行的第二操作；

根据第二操作，生成终止请求信息，其中，终止呼叫请求信息用于请求终止呼叫请求；

向网络侧设备发送终止请求信息。

前述通话控制方法的实施例涉及的各步骤的所有相关内容均可以援引到本发明实施例中的通话控制装置所对应的功能模块的功能描述，在此不再赘述。

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本发明各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

基于同一发明构思，本申请实施例还提供一种通话控制设备，该通话控制设备例如是手机、智能手表等终端设备，例如可以是图1所示的终端10或终端11，或如图2所示的主叫终端20。如图6所示，该通话控制设备包括至少一个处理器601，以及与至少一个处理器连接的存储器602，本申请实施例中不限定处理器601和存储器602之间的具体连接介质，图6中是以处理器601和存储器602之间通过总线600连接为例，总线600在图6中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线600可以分为地址总线、数据总线、控制总线等，为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

基于同一发明构思，本申请实施例还提供一种通话控制设备，该通话控制设备例如是基站、服务器等网络设备，例如可以是图1所示的网络侧设备12，或图2所示的网络侧设备21。如图7所示，该通话控制设备包括至少一个处理器701，以及与至少一个处理器连接的存储器702，本申请实施例中不限定处理器701和存储器702之间的具体连接介质，图7中是以处理器701和存储器702之间通过总线700连接为例，总线700在图7中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线700可以分为地址总线、数据总线、控制总线等，为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

其中，图6中的存储器602和图7中所示的存储器702均存储有可被至少一个处理器执行的指令，至少一个处理器通过执行存储器602或存储器702存储的指令，可以执行前述的通话控制方法中所包括的步骤。

处理器601和处理器701均是通话控制设备的控制中心，可以利用各种接口和线路连接整个通话控制设备的各个部分，通过运行或执行存储在存储器602和存储器702内的指令以及调用存储在存储器602和存储器702内的数据，通话控制设备的各种功能和处理数据，从而对通话控制设备进行整体监控。可选的，处理器601和处理器701均可包括一个或多个处理单元，处理器601和处理器701均可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器601和处理器701中。在一些实施例中，处理器601和存储器602、处理器701存储器702可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器601和处理器701可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的通话控制方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器602和存储器702作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器602和存储器702均可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(ReadOnly Memory，ROM)、带电可擦除可编程只读存储器(Electrically ErasableProgrammable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器602和存储器702是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器602和存储器702还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

通过对处理器601和处理器701进行设计编程，可以将前述实施例中介绍的通话控制方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行前述的通话控制方法的步骤，如何对处理器601和处理器701进行设计编程为本领域技术人员所公知的技术，这里不再赘述。

基于同一发明构思，本申请实施例中提供了一种存储介质，该存储介质存储有计算机可执行指令，当计算机可执行指令用于当计算机指令在计算机上运行时，使得计算机执行如前述的通话控制方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (17)

1.一种通话控制方法，其特征在于，包括：

接收第一终端发起的对目标号码的呼叫请求；

若当前无法处理所述呼叫请求，确定当前无法处理所述呼叫请求的原因；

在当前无法处理所述呼叫请求的原因为网络侧拥堵时，向所述第一终端发送呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

2.如权利要求1所述的方法，其特征在于，所述呼叫失败反馈信息还用于指示是否继续等待建立通话连接，所述方法还包括：

保持所述呼叫请求；

接收所述第一终端基于所述呼叫失败反馈信息发送的指示等待信息，其中，所述指示等待信息用于指示所述第一终端能够等待建立通话连接；

根据所述等待指示信息，在所述网络侧能够处理所述呼叫请求时，建立所述第一终端与所述目标号码对应的第二终端之间的通话连接。

3.如权利要求2所述的方法，其特征在于，所述指示等待信息还用于指示用户设置的第一等待时长，所述第一等待时长为所述第一终端能够等待的与所述第二终端建立通话连接的最长时长；

则，在从接收所述指示等待信息时开始的所述第一等待时长内，若确定所述网络侧能够处理所述呼叫请求，则根据所述呼叫请求建立所述第一终端与所述第二终端之间的通话连接。

4.如权利要求2所述的方法，其特征在于，所述指示等待信息还用于指示用户设置的第一等待时长，所述第一等待时长为所述第一终端能够等待的与所述第二终端建立通话连接的最长时长；则在保持所述呼叫请求之后，所述方法还包括：

在从接收所述指示等待信息时开始达到所述第一等待时长后，确定所述网络侧是否仍处于网络拥堵状态；

若仍处于网络拥堵状态，则终止所述呼叫请求。

5.如权利要求4所述的方法，其特征在于，在确定所述网络侧是否仍然处于拥堵状态之前，所述方法还包括：

在接收所述指示等待信息时，确定所述网络侧结束网络拥堵状态所需要的第二等待时长；

确定所述第一等待时长大于或等于所述第二等待时长。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

若确定所述第一等待时长小于所述第二等待时长，则向所述第一终端发送等待不足提示信息，其中，所述等待不足提示信息用于指示所述网络侧在所述第一等待时长内无法处理所述呼叫请求。

7.如权利要求6所述的方法，其特征在于，在向所述第一终端发送等待不足提示信息之后，所述方法还包括：

确定所述目标号码是否是预设的紧急号码；

若是所述预设的紧急号码，则继续保持所述呼叫请求；

若不是所述预设的紧急号码，则终止所述呼叫请求。

8.如权利要求2所述的方法，其特征在于，所述呼叫失败反馈信息还用于指示第三等待时长，所述第三等待时长为所述网络侧结束网络拥堵状态的最短时长，则在保持所述呼叫请求之后，所述方法还包括：

在从发送所述呼叫失败反馈信息时开始达到第四等待时长时，建立所述第一终端与所述第二终端之间的通话连接；其中，所述第四等待时长为从发送所述呼叫失败反馈信息开始到实际处理所述呼叫请求之间的时长。

9.如权利要求1所述的方法，其特征在于，在向所述第一终端发送呼叫失败反馈信息之后，所述方法还包括：

接收所述第一终端发送的用于请求终止所述呼叫请求的终止请求信息；

根据所述终止呼叫请求信息，终止所述呼叫请求。

10.一种通话控制方法，其特征在于，包括：

向网络侧发送请求与目标号码建立通话的呼叫请求；

接收所述网络侧发送的呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

11.如权利要求10所述的方法，其特征在于，所述呼叫失败反馈信息还用于指示是否继续等待建立通话连接，在接收所述呼叫失败反馈信息之后，所述方法还包括：

获得用户针对所述第一终端进行的第一操作；

根据所述第一操作，确定指示等待信息；其中，所述指示等待信息用于指示所述第一终端能够等待建立通话连接；

向所述网络侧发送所述指示等待信息。

12.如权利要求11所述的方法，其特征在于，所述指示等待信息还用于指示用户设置的第一等待时长，其中，所述第一等待时长为所述第一终端能够等待的与所述目标号码对应的第二终端建立通话连接的最长时长。

13.如权利要求10所述的方法，其特征在于，在接收所述网络侧发送的呼叫失败反馈信息之后，所述方法还包括：

获得用户针对所述第一终端进行的第二操作；

根据所述第二操作，生成终止请求信息，其中，所述终止呼叫请求信息用于请求终止所述呼叫请求；

向所述网络侧发送所述终止请求信息。

14.一种通话控制装置，其特征在于，包括：

第一接收单元，用于接收第一终端发起的对目标号码的呼叫请求；

第一确定单元，用于若当前无法处理所述呼叫请求，确定当前无法处理所述呼叫请求的原因；

反馈单元，用于在当前无法处理所述呼叫请求的原因为网络侧拥堵时，向所述第一终端发送呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于网络拥堵状态。

15.一种通话控制装置，其特征在于，包括：

发送单元，用于向网络侧发送请求与目标号码建立通话的呼叫请求；

接收单元，用于接收所述网络侧发送的呼叫失败反馈信息，其中，所述呼叫失败反馈信息用于指示所述网络侧当前处于拥堵状态。

16.一种通话控制设备，其特征在于，所述设备包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行权利要求1-9或权利要求10-13中任一方法包括的步骤。

17.一种存储介质，其特征在于，所述存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如权利要求1-9或权利要求10-13中任一方法的步骤。