CN114095887A

CN114095887A - 一种通话异常的提示方法、通信系统、电子设备及介质

Info

Publication number: CN114095887A
Application number: CN202210064110.9A
Authority: CN
Inventors: 李海波
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-01-20
Filing date: 2022-01-20
Publication date: 2022-02-25
Anticipated expiration: 2042-01-20
Also published as: CN114095887B

Abstract

本申请公开了一种通话异常的提示方法、通信系统、电子设备及介质，涉及通信领域，该通信系统包括主叫用户设备UE和网络，该网络用于当通话异常时，向主叫UE发送会话初始协议SIP消息，主叫UE用于根据该SIP消息，确定通话异常；接着，检测网络是否向主叫UE播放提示音，获得检测结果，当检测结果表征网络未向主叫UE播放提示音时，根据该通话异常的原因呈现对应的提示信息。如此，在通话异常的场景中，通过向用户呈现有效的提示，能够消除主叫UE的用户的疑惑，提高用户体验。

Description

一种通话异常的提示方法、通信系统、电子设备及介质

技术领域

本申请涉及通信领域，尤其涉及一种通话异常的提示方法、通信系统、电子设备及介质。

背景技术

从长期演进技术（Long Time Evolution，LTE）开始，提出了通过发起网络间互联协议多媒体子系统（Internet-protocol Multimedia Subsystem，IMS）将语音业务承载在IP网络的语音实现方案，即VoLTE（Voice over LTE）技术。在5G（也可以称为新无线（NewRadio，NR））无线通信系统中，提出了延续在IP网络上承载语音业务的方式，通过5G网络和IMS实现语音业务，即VoNR（Voice over NR）技术。用户设备（User Equipment，UE）在IMS上注册成功后能够通过这些技术来实现语音业务。

在主叫UE和被叫UE通话场景中，在主叫UE拨打被叫UE的号码后，网络会寻呼被叫UE，由于主叫UE的原因（例如，主叫UE欠费）或被叫UE的原因（例如，被叫UE正在通话中、被叫UE为空号等），会出现被叫UE无法被寻呼的情况，即通话异常。此时，网络会向主叫UE播放提示音，以提示主叫UE的用户当前被叫UE无法被寻呼的原因（例如，被叫UE正在通话中）。

在上述通话异常的场景中，若网络出现故障，网络不会向主叫UE播放提示音。由于没有有效的提示，主叫UE的用户无法得知通话异常的原因，进而导致用户误以为自己手机出现了问题，影响用户体验。

发明内容

本申请的目的在于：提供一种通话异常的提示方法、通信系统及电子设备，消除了主叫UE的用户的疑惑，提高了用户体验。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供了一种通信系统，该通信系统包括主叫UE和网络，在该通信系统中，主叫UE可以向网络发送请求（invite）消息，网络可以基于该主叫UE发送的invite消息，寻呼（paging）被叫UE，例如网络可以基于该invite消息得到被叫UE的号码，基于该被叫UE的号码来寻呼被叫UE。在一些场景中，由于主叫UE或者被叫UE的原因，会出现被叫UE无法被寻呼的情况，即通话异常，也可以称被叫UE不可达。其中，主叫UE的原因可以是主叫UE停机、主叫UE欠费等，被叫UE的原因可以是被叫UE为空号、被叫UE关机、被叫UE不可及、被叫UE忙、被叫UE停机、被叫UE无应答等。

在通话异常的场景中，网络会将通话异常的原因携带在会话初始协议SIP消息中发送给主叫UE，随后向主叫UE播放提示音，提示用户通话异常的原因。然而，若网络出现故障，则网络不会向主叫UE播放提示音，即主叫UE的用户无法得到有效的提示。基于此，主叫UE检测网络是否向主叫UE播放提示音，得到检测结果，当该检测结果表征网络未向主叫UE播放提示音时，主叫UE可以基于通话异常的原因呈现对应的提示信息，例如通话的原因为被叫UE关机时，主叫UE可以播放被叫UE关机对应的提示音或者显示被叫UE关机的提示语。如此，即使网络出现故障，主叫UE也能够向用户呈现有效的提示，进而能够消除用户的疑惑，提高用户体验。

在一些可能的实现方式中，主叫UE，用于通过示范接收到网络发送的携带有提示音的实时传输协议RTP包，检测网络是否向主叫UE播放提示音。主叫UE，用于当主叫UE接收到网络发送的携带有提示音的RTP包时，获得网络向主叫UE播放提示音的检测结果，当主叫UE未接收到网络发送的携带有提示音的RTP包时，获得网络未向主叫UE播放提示音的检测结果。

在一些可能的实现方式中，主叫UE，用于通过将本次通话的信令交互流程和标准信令交互流程进行比较，检测网络是否向主叫UE播放提示音，该标准信令交互流程包括网络向主叫UE播放提示音的流程。主叫UE，用于当本次通话的信令交互流程包括网络向主叫UE播放提示音的流程时，获得网络向主叫UE播放提示音的检测结果，当本次通话的信令交互流程不包括网络向主叫UE播放提示听的流程时，获得网络未向主叫UE播放提示音的检测结果。

在一些可能的实现方式中，标准信令交互流程可以通过预先配置得到，也可以通过神经网络预先学习得到。

在一些可能的实现方式中，主叫UE，用于可以通过将本次通话的信令交互流程和异常信令交互流程进行比较，检测网络是否向主叫UE播放提示音，该异常信令交互流程不包括网络向主叫UE播放提示音的流程。主叫UE，用于当本次通话的信令交互流程与该异常信令交互流程不一致时，获得网络向主叫UE播放提示音的检测结果，当本次通话的信令交互流程与该异常信令交互流程一致时，获得网络未向主叫UE播放提示音的检测结果。

在一些可能的实现方式中，异常信令交互流程可以通过预先配置得到，也可以通过神经网络预先学习得到。

在一些可能的实现方式中，主叫UE，用于接收网络发送的SIP消息，该SIP消息包括会话进度，会话进度携带有通话异常的原因，根据该通话异常的原因，确定通话异常。

在一些可能的实现方式中，主叫UE，用于根据该通话异常的原因播放对应的提示音，根据通话异常的原因显示对应的提示语。如此，用户能够基于提示音或者是提示语得到通话异常的原因，消除用户的疑惑，提高用户体验。

第二方面，本申请提供了一种通话异常的提示方法，该包括可以应用于主叫用户UE，该方法包括：

主叫UE确定通话异常；

主叫UE检测网络是否向主叫UE播放提示音，获得检测结果；

当检测结果表征网络未向主叫UE播放提示音时，主叫UE根据通话异常的原因呈现对应的提示信息。

在一些可能的实现方式中，所述主叫UE检测网络是否向所述主叫UE播放提示音，获得检测结果，包括：

所述主叫UE通过是否接收到网络发送的携带有提示音的实时传输协议RTP包，检测网络是否向所述主叫UE播放提示音；

当所述主叫UE接收到所述网络发送的携带有提示音的RTP包时，所述主叫UE获得网络向所述主叫UE播放提示音的检测结果；

当所述主叫UE未接收到所述网络发送的携带有提示音的RTP包时，所述主叫UE获得网络未向所述主叫UE播放提示音的检测结果。

所述主叫UE通过将本次通话的信令交互流程和标准信令交互流程进行比较，检测网络是否向所述主叫UE播放提示音；所述标准信令交互流程包括所述网络向所述主叫UE播放提示音的流程；

当所述信令交互流程包括所述网络向所述主叫UE播放提示音的流程时，所述主叫UE获得网络向所述主叫UE播放提示音的检测结果；

当所述信令交互流程不包括所述网络向所述主叫UE播放提示音的流程时，所述主叫UE获得网络未向所述主叫UE播放提示音的检测结果。

在一些可能的实现方式中，所述标准信令交互流程通过预先配置得到或通过神经网络预先学习得到。

所述主叫UE通过将本次通话的信令交互流程和异常信令交互流程进行比较，检测网络是否向所述主叫UE播放提示音；所述异常信令交互流程不包括所述网络向所述主叫UE播放提示音的流程；

当所述信令交互流程与所述异常信令交互流程不一致时，所述主叫UE获得网络向所述主叫UE播放提示音的检测结果；

当所述信令交互流程与所述异常信令交互流程一致时，所述主叫UE获得网络未向所述主叫UE播放提示音的检测结果。

在一些可能的实现方式中，所述异常信令交互流程通过预先配置得到或通过神经网络预先学习得到。

在一些可能的实现方式中，所述主叫UE确定通话异常，包括：

所述主叫UE接收网络发送的SIP消息，所述SIP消息包括会话进度，所述会话进度携带有通话异常的原因；

所述主叫UE根据所述通话异常的原因，确定所述通话异常。

在一些可能的实现方式中，所述主叫UE根据通话异常的原因呈现对应的提示信息，包括：

所述主叫UE根据通话异常的原因播放对应的提示音；和/或，

所述主叫UE根据通话异常的原因显示对应的提示语。

第三方面，本申请提供了一种电子设备，该电子设备包括存储器和处理器，在所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令；当所述指令被所述处理器执行时，使得所述电子设备执如第二方面中任一项所述的方法。

第四方面，本申请提供了一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在计算设备上运行时，所述计算设备执行如第二方面中任一项所述的方法。

第五方面，本申请提供了一种计算机程序产品，该计算机程序产品包括指令；当所述指令被计算设备运行时，使得所述计算设备执行如第二方面中任一种所述的方法。

应当理解的是，本申请中对技术特征、技术方案、有益效果或类似语言的描述并不是暗示在任意的单个实施例中可以实现所有的特点和优点。相反，可以理解的是对于特征或有益效果的描述意味着在至少一个实施例中包括特定的技术特征、技术方案或有益效果。因此，本说明书中对于技术特征、技术方案或有益效果的描述并不一定是指相同的实施例。进而，还可以任何适当的方式组合本实施例中所描述的技术特征、技术方案和有益效果。本领域技术人员将会理解，无需特定实施例的一个或多个特定的技术特征、技术方案或有益效果即可实现实施例。在其他实施例中，还可在没有体现所有实施例的特定实施例中识别出额外的技术特征和有益效果。

附图说明

图1为本申请实施例提供的一种无线通信系统的示意图；

图2为本申请实施例提供的一种通话异常的提示方法的流程图；

图3为本申请实施例提供的又一种通话异常的提示方法的流程图；

图4为本申请实施例提供的再一种通话异常的提示方法的流程图；

图5为本申请实施例提供的另一种通话异常的提示方法的流程图；

图6为本申请实施例提供的场景1中通话异常的提示方法的流程图；

图7A为本申请实施例提供的再一种提示界面的示意图；

图7B为本申请实施例提供的又一种提示界面的示意图；

图7C为本申请实施例提供的再一种提示界面的示意图；

图8为本申请实施例提供的场景2中通话异常的提示方法的流程图；

图9为本申请实施例提供的场景3中通话异常的提示方法的流程图；

图10为本申请实施例提供的场景4中通话异常的提示方法的流程图；

图11为本申请实施例提供的场景5中通话异常的提示方法的流程图；

图12为本申请实施例提供的一种电子设备的示意图；

图13为本申请实施例提供的又一种电子设备的示意图。

具体实施方式

本申请说明书和权利要求书及附图说明中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于限定特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请，下面将结合附图对本申请的实施例进行详细描述。

首先，结合图1来描述可以在其中应用本申请实施例的无线通信系统。图1为可以在其中应用本申请实施例的无线通信系统的示意图。该无线通信系统可以是LTE，也可以是5G无线通信系统，或者未来无线通信发展中出现的新的通信系统等。只要无线通信系统采用IMS作为语音实现方案，那么该无线通信系统可以应用本申请实施例。

如图1所示，无线通信系统100包括UE 101a、UE 101b、为UE 101a提供LTE网络的接入网设备102、为UE 101b提供5G网络的接入网设备103、核心网设备104、以及IP多媒体子系统（IMS）105。其中，UE101a可以为主叫UE、UE101b为被叫UE。在一些示例中，也可以将接入网设备102、接入网设备103、核心网设备104和IMS 105统称为网络（network，NW）。

IMS 105可以包括代理呼叫会话控制功能（Proxy-Call Session ControlFunction，P-CSCF）实体、查询呼叫会话控制功能（Interrogating-Call Session ControlFunction，I-CSCF）、服务呼叫会话控制功能（Serving-Call Session Control Function，S-CSCF）实体、和归属地用户服务器（Home Subscriber Server，HSS）。

P-CSCF实体是接入网到IMS的最先连接点，所有发起于支持IMS的UE和终止于支持IMS的UE的会话消息都要通过P-CSCF实体转发。P-CSCF实体可用于将来自UE的IMS注册请求转发给S-CSCF实体，以及将注册响应信息转发给UE。

I-CSCF实体可以连接S-CSCF实体和P-CSCF实体，用于为UE提供到归属网络的入口。在IMS注册过程中，P-CSCF实体可以将来自UE的IMS注册请求转发给I-CSCF实体，I-CSCF实体可以查询IMS中的HSS，为UE选择一个S-CSCF实体。在呼叫过程中，去往IMS网络的呼叫消息首先路由到I-CSCF，I-CSCF实体可以通过IMS中的HSS为UE查询到用户所注册的S-CSCF实体的地址信息，之后再将消息路由到S-CSCF。

S-CSCF实体为IMS的控制核心，为UE提供会话控制和注册等功能。S-CSCF实体用于接收P-CSCF实体转发的IMS注册请求，与HSS配合对UE进行鉴权。S-CSCF在确定鉴权通过后，从HSS获取UE的签约信息。S-CSCF实体还用于基于ISC接口与各应用服务器相连，S-CSCF实体还用于触发应用服务器执行操作，将UE的请求路由到相应的应用服务器。

HSS用于存储所有与用户和服务相关的数据，例如用户身份、签约信息、接入信息等。

应该理解，虽然图1所示的无线通信系统100仅包括两个UE、一个接入网设备102和一个接入网设备103，但无线通信系统100可以包括更少和/或更多UE、和/或更多接入网设备。此外，无线通信系统100还可以包括为UE 101a提供2G/3G/5G网络的接入网设备。无线通信系统100还可以包括为UE 101b提供2G/3G/LTE网络的接入网设备。

以当UE 101a为例，UE 101a可以在开机、重启、退出飞行模式、热插拔卡、公共陆地移动网络（Public Land Mobile Network，PLMN）变更、跟踪区域更新（Tracking AreaUpdate，TAU）、IMS注册失败等事件发生时，生成IMS注册请求。然后，UE 101a可以将该IMS注册请求通过接入网以及核心网发送给IMS 106中的P-CSCF实体。UE 101a还可以通过核心网以及接入网，从IMS 106接收注册响应消息。例如，IMS注册请求可以是初始注册请求。该初始注册请求可以包括用户信息、终端能力信息等。相应地，注册响应消息可以是会话初始协议（Session initialization Protocol，SIP） 401消息。该401消息可以包括鉴权信息，用于要求UE101a进行鉴权。又例如，IMS注册请求可以是挑战（challenging）注册请求。该挑战注册请求可以包括鉴权信息。相应地，注册响应消息可以是SIP 200 OK消息，用于指示IMS注册成功。

在UE 101a成功注册IMS的情况下，UE 101a可以通过IMS来实现语音业务。例如UE101a可以通过拨打其他UE（例如UE 101b）的手机号码来呼叫其他UE，或者接听来自其他UE的来电呼叫。

在本申请实施例中，以当UE 101a为例，当UE101a没有接收到注册响应信息时，或者当UE 101a从IMS接收到会话发起协议（Session Initiation Protocol，SIP）错误码时，表明UE 101a未成功注册IMS。例如，该SIP错误码可以是在SIP接口协议中规定的403消息（即表示禁止）、404消息（即表示找不到用户）、408消息（即表示请求超时）、480消息（即表示临时不可用）、503消息（即表示服务不可用）、504消息（即表示服务器超时）等。该SIP接口协议例如可以是征求意见稿（Request For Comments，RFC）3261协议。当UE 101a接收到注册响应信息时，表明UE 101成功注册了IMS。

另外，本申请实施例还会涉及以下SIP消息。180消息（即表示振铃，收到 INVITE的UA正在尝试提醒用户。该180消息可以用于发起本地回铃）。181消息（即表示呼叫被转接，服务器（如网络）可以使用此181消息来指示呼叫正在转发到一组不同的目的地）。183消息（即表示会话进度，183消息用于传达有关未以其他方式分类的呼叫进度的信息。 Reason-Phrase、标题字段或消息正文可以用于传达有关呼叫进度的更多详细信息。）200消息（即表示会话成功，请求已成功。与200消息一起返回的信息取决于请求中使用的方法）。487消息（即表示请求终止，请求被BYE或CANCEL请求终止。对于CANCEL请求本身永远不会返回此响应）。

为了便于理解，下面先结合附图介绍通话异常的提示方法，如图2所示，该图为本申请实施例提供的通话异常的提示方法的流程图，该提示方法包括：

S201：主叫UE向NW发送请求（invite）消息。

S202：NW基于主叫UE发送的invite消息，寻呼（paging）被叫UE。

在一些示例中，NW可以解析该invite消息得到被叫UE的号码，然后基于该被叫UE的号码来寻呼被叫UE。然而由于主叫UE或者被叫UE的原因，会出现被叫UE无法被寻呼的情况，即通话异常，也可以称为被叫UE不可达。被叫UE的原因可以是被叫UE为空号、被叫UE关机、被叫UE不可及、被叫UE忙、被叫UE停机、被叫UE无应答等，主叫UE的原因可以是主叫UE停机、主叫UE欠费等。在NW接收到主叫UE发送的invite消息后，可以建立专有承载。

需要说明书的是，本申请实施例中不具体限定建立专有承载的时机，本领域技术人员可以根据实际需要，确定建立专有承载的时机。

S203：NW向主叫UE发送183消息。

该183消息可以基于通话异常的原因确定，如此NW可以在183消息中携带通话异常的原因，例如被叫UE关机。在一些示例中，该183消息中会携带上述被叫UE关机的原因值，例如：Q.850;cause=20;text="Subscriber absent",SIP;cause=480，其中text="Subscriberabsent"表示的是原因值。

S204：NW向主叫UE播放提示音。

在一些示例中，NW可以通过实时传输协议（Real-time Transport Protocol，RTP）向主叫UE发送RTP包，以向主叫UE播放提示音。延续上例，当通话异常的原因是被叫UE关机时，该提示音可以是“您拨打的用户已关机，请稍后再拨”。如此，主叫UE的用户能够基于该提示音知晓本次通话异常的原因，如被叫UE处于关机状态。

S205：NW向主叫UE发送487消息。

该487消息用于指示主叫UE结束通话。在一些实施例中，NW可以在网络计时结束后，向主叫UE发送487消息。

在另一些实施例中，主叫UE的用户听到上述提示音后，也可以直接挂断通话，触发主叫UE向NW发送BYE消息。

如图3所示，该图为本申请实施例提供的又一种的通话异常的提示方法的流程图，该提示方法包括：

S301：主叫UE向NW发送invite消息。

S302：NW基于主叫UE发送的invite消息，寻呼（paging）被叫UE。

类似的，NW可以解析该invite消息得到被叫UE的号码，然后基于该被叫UE的号码来寻呼被叫UE。然而由于主叫UE或者被叫UE的原因，会出现被叫UE无法被寻呼的情况，即通话异常，也可以称为被叫UE不可达。

S303：NW向主叫UE发送183消息。

S304：NW向主叫UE发送181消息。

与上述图2所示的示例不同的是，当NW寻呼被叫UE失败（如无法寻呼到被叫UE）时，即上述通话异常时，NW可以将针对于被叫UE的寻呼转接到预设号码，该预设号码可以是运营商设置的号码。该181消息用于指示主叫UE的对被叫UE的invite消息被转接到上述预设号码。

在另一些示例中，当被叫UE设置了呼叫转移时，，NW可以将针对于被叫UE的寻呼转接到呼叫转移所针对的号码，例如被叫UE的朋友的号码、被叫UE的副卡号码等。接着，NW寻呼该呼叫转移所针对的号码失败时，NW还可以将针对于被叫UE的寻呼转接到上述预设号码。

S305：NW向主叫UE发送180消息。

该180消息用于指示主叫UE振铃。

S306：NW向主叫UE播放提示音。

类似的，NW可以通过RTP协议向主叫UE发送RTP包，以向主叫UE播放提示音。延续上例，当通话异常的原因是被叫UE关机时，该提示音可以是“您拨打的用户已关机，请稍后再拨”。如此，主叫UE的用户能够基于该提示音知晓被叫UE处于关机状态。

S307：NW向主叫UE发送200消息。

该200消息用于指示会话成功。在一些示例中，主叫UE还可以提示用户留言，以便被叫UE的用户获取该主叫UE的用户的留言。

S308：主叫UE向NW发送BYE消息。

该BYE消息用于指示会话结束。在一些示例中，主叫UE的用户可以通过挂断的方式，触发主叫UE向NW发送BYE消息。

在图2和图3所示的通话异常的场景中，NW均会向主叫UE进行播放提示音，以提示主叫UE本次通话异常的原因。然而，当NW出现故障导致NW无法向主叫UE的用户播放提示音时，主叫UE的用户将无法得知通话异常的原因，进而导致用户误以为自己手机出现了问题，影响用户体验。

为了便于理解，下面介绍NW故障时通话异常的提示方法。如图4所示，图4所示的方法与上述图2所示的方法相对应，该方法包括：

S401：主叫UE向NW发送invite消息。

S402：NW基于主叫UE发送的invite消息，寻呼（paging）被叫UE。

S403：NW向主叫UE发送183消息。

S404：NW向主叫UE发送487消息。

与上述图2所示的示例不同之处在于，在NW向主叫UE发送183消息后，由于NW故障，NW并没有向主叫UE播放提示音，而是在若干秒的延时后，直接向主叫UE发送487消息，进而强制结束会话。主叫UE的用户并无法得通话异常的原因，例如被叫UE处于关机状态。由此，主叫UE的用户会产生疑惑，例如，误认为自己手机出现了问题。

类似的，参见图5，图5所示的方法与上述图3所示的方法相对应，该方法包括：

S501：主叫UE向NW发送invite消息。

S502：NW基于主叫UE发送的invite消息，寻呼（paging）被叫UE。

S503：NW向主叫UE发送183消息。

S504：NW向主叫UE发送181消息。

S505：NW向主叫UE发送487消息。

与上述图3所示的示例不同之处在于，在NW向主叫UE发送181消息后，由于NW故障，NW并没有向主叫UE发送180消息，以及没有向主叫UE播放提示音，而是在若干秒的延时后，直接向主叫UE发送487消息，进而强制结束会话。主叫UE的用户并无法得通话异常的原因，例如被叫UE处于关机状态。由此，主叫UE的用户会产生疑惑，例如，误认为自己手机出现了问题。

有鉴于此，本申请实施例提供了一种通话异常的提示方法，该方法旨在由于NW故障导致NW没有向主叫UE播放提示音时，主叫UE基于通话异常的原因，向用户呈现与该通话异常的原因相对应的提示信息。例如主叫UE可以向用户播放提示音，也可以向用户显示提示语。如此，即使NW出现故障，主叫UE也能够提示用户通话异常的原因，消除用户的疑惑，提高了用户体验。

在不同的场景中，本申请实施例提供的通话异常的提示方法不同，下面分别介绍。

场景1：

在场景1中，如图6所示，该图为本申请实施例提供的通话异常的提示方法的流程图，该方法包括：

S601：主叫UE向网络NW发送invite消息。

S602：NW基于主叫UE发送的invite消息，寻呼（paging）被叫UE。

S603：NW向主叫UE发送183消息。

S604：主叫UE检测NW是否向主叫UE播放提示音，得到第一检测结果。

在一些示例中，主叫UE可以在收到183消息后的第一预设时间段内，检测NW是否向主叫UE播放提示音，若在该第一预设时间段内，主叫UE仍未检测到NW向主叫UE播放提示音，则主叫UE确定NW未向主叫UE播放提示音的第一检测结果；若在该第一预设时间段内，主叫UE检测到NW向主叫UE播放提示音，则主叫UE确定NW向主叫UE播放提示音的第一检测结果。其中，上述第一预设时间段可以是从主叫UE接收到183消息开始到主叫UE接收到487消息为止对应的时间段；当然也可以是固定时长的时间段，例如2秒、3秒等。

需要说明的是，本申请不具体限定上述第一预设时间段的具体数值，在另一些示例中，第一预设时间段也可以是主叫UE多次从接收到183消息到接收到487消息所对应的平均值，也可以是经验值。本领域技术人员可以根据实际需要设定上述第一预设时间段。

在一些示例中，主叫UE可以通过是否接收到NW发送的RTP包，检测NW是否向主叫UE播放提示音。当主叫UE接收到NW发送的RTP包时，则确定NW向主叫UE播放提示音，即主叫UE获得NW向主叫UE播放提示音的第一检测结果，当主叫UE未接收到NW发送的RTP包时，则确定NW未向主叫UE播放提示音，即主叫UE获得NW未向主叫UE播放提示音的第二检测结果。

在另一些示例中，主叫UE还可以基于语音识别技术，检测NW是否向所述主叫UE播放提示音；当主叫UE识别到提示音时，主叫UE获得NW向所述主叫UE播放提示音的第一检测结果；当主叫UE未识别到提示音时，主叫UE获得网络未向主叫UE播放提示音的第一检测结果。例如，主叫UE可以在上述第一预设时间段内识别是否存在提示音；主叫UE也可以在上述第一预设时间段识别提示音的具体内容，例如提示音对应的文本。

需要说明的是，以上仅仅是主叫UE检测NW是否向主叫UE播放提示音的示例，本领域技术人员还可以基于实际需要，选择其他方式进行检测。

S605：NW向主叫UE发送487消息。

当第一检测结果表征NW未向主叫UE播放提示音时，主叫UE执行S606。在S606中，主叫UE从预先存储的提示音中选择与通话异常的原因对应的提示音进行播放。

在一些示例中，可以在主叫UE的本地预先存储通话异常的原因与其对应的提示音，当然也可以预先存储通话异常的原因与其对应的提示音以及提示语（提示音对应的文本），如下表1所示：

表1

原因值	提示音	提示语
			被叫UE处于关机状态	音频1	文本1
被叫UE正在通话中	音频2	文本2
			主叫UE欠费	音频3	文本3
……	……	……

其中，原因值为“被叫UE处于关机状态”时，提示音为“音频1”，如“你拨叫的用户已关机，请稍后再拨”对应的语音，提示语为“文本1”，如提示音对应的文本；原因值为“被叫UE正在通话中”时，提示音为“音频2”，如“你拨叫的用户正在通话中，请稍后再拨”对应的语音，提示语为“文本2”，如提示音对应的文本；原因值为“主叫UE欠费”时，提示音为“音频3”，如“你已欠费，请缴费后再拨”对应的语音，提示语为“文本3”，如提示音对应的文本。

需要说明的是，上述表1中所示的原因值仅仅为示例说明，在另一些示例中，通话异常的原因还可以是被叫UE为空号、被叫UE停机、被叫UE无应答等。

在一些示例中，NW确定通话异常后，可以将通话异常的原因携带在183消息中，例如，183消息可以携带Reason: “Q.850;cause=20;text="Subscriber absent",SIP;cause=480”，其中，text=“Subscriber absent”表示的是原因值，例如该原因值可以是“被叫UE处于关机状态”。如此，主叫UE在接收到183消息后，主叫UE可以基于183消息确定通话异常，然后可以对该183消息进行解析，进而确定该183消息携带了上述通话异常的原因。接着，主叫UE可以根据上述表1播放相应的提示音以及显示相应的提示语。

下面结合图7A-图7C分别介绍上述表1所示的3种示例对应的提示界面。

如图7A所示，该图为本申请实施例提供的一种提示界面的示意图。该提示界面包括提示语701和挂断控件702。当原因值为“被叫UE处于关机状态”时，该提示语701可以是“你拨叫的用户已关机，请稍后再拨”，挂断控件702用于挂断通话，用户可以点击该挂断控件702，主叫UE检测到用户对该挂断控件702的点击操作后，可以基于该点击操作挂断通话。

如图7B所示，该图为本申请实施例提供的又一种提示界面的示意图。该提示界面包括提示语703和挂断控件704。当原因值为“被叫UE正在通话中”时，该提示语703可以是“你拨叫的用户正在通话中，请稍后再拨”，挂断控件704用于挂断通话。

如图7C所示，该图为本申请实施例提供的又一种提示界面的示意图。该提示界面包括提示语705和挂断控件706。当原因值为“主叫UE欠费”时，该提示语705可以是“你已欠费，请缴费后再拨”，挂断控件706用于挂断通话。

继续参见图6，当第一检测结果表征NW向主叫UE播放提示音时，主叫UE执行S607。在S607中，主叫UE可以按照正常流程进行处理，例如主叫UE可以挂断通话，也可以不进行本地播放提示音。

当主叫UE检测到NW向主叫UE播放提示音时，主叫UE可以按照图2所示的流程进行处理。在一些示例中，主叫UE的用户在听到上述提示音后，可以挂断通话；在另一些示例中，NW向主叫UE播放提示音超过预设时间（例如10秒）后挂断通话。

在该方法中，在通话异常的场景中，若NW由于故障未向主叫UE播放提示音，主叫UE在确定NW未向主叫UE播放提示音后，能够基于183消息获取通话异常原因，并从本地选择通话异常的原因对应的提示音进行播放以及选择通话异常的原因对应的提示语进行展示，从而使主叫UE的用户知晓该通话异常的原因，消除用户的疑惑，提高用户体验。

场景2：

场景2与场景1的不同之处在于，在场景2中，被叫UE设置了呼叫转移，如此，主叫UE可以在接收NW发送的183消息和181消息后，检测NW是否向主叫UE播放提示音，从而保证在被叫UE设置呼叫转移的情况下，能够正确检测NW是否向主叫播放提示音。

在场景2中，如图8所示，该图为本申请实施例提供的通话异常的提示方法的流程图。该方法包括：

S801：主叫UE向NW发送invite消息。

S802：NW基于主叫UE发送的invite消息，寻呼（paging）被叫UE。

S803：NW向主叫UE发送183消息。

S804：主叫UE检测NW是否向主叫UE播放提示音，得到第二检测结果。

在一些示例中，主叫UE可以在收到183消息后的第二预设时间段内，检测NW是否向主叫UE播放提示音，若在该第二预设时间段内，主叫UE仍未检测到NW向主叫UE播放提示音，则主叫UE确定NW未向主叫UE播放提示音的第二检测结果；若在该第二预设时间段内，主叫UE检测到NW向主叫UE播放提示音，则主叫UE确定NW向主叫UE播放提示音的第二检测结果。其中，上述第二预设时间段可以是从主叫UE接收到183消息开始到主叫UE接收到181消息为止对应的时间段；当然也可以是固定时长的时间段，例如2秒、3秒等。

需要说明的是，本申请不具体限定上述第二预设时间段的具体数值，在另一些示例中，第二预设时间段也可以是主叫UE多次从接收到183消息到接收到181消息所对应的平均值，也可以是经验值。本领域技术人员可以根据实际需要设定上述第二预设时间段。

S805：NW向主叫UE发送181消息。

该181消息中可以携带NW为被叫UE设置的预设号码，主叫UE接收到该181消息后，可以对该181消息进行解析，判断该181消息所携带的号码是否为预设号码，若是，则表明通话异常，从而进一步提高确定通话异常的准确度。

当第二检测结果表征NW未向主叫UE播放提示音时，在步骤S805之后，主叫UE执行S806。在S806中，主叫UE检测NW是否向主叫UE播放提示音，得到第三检测结果。当第二检测结果表征NW未向主叫UE播放提示音时，需要进行再次检测，从而进一步确定检测结果的准确度。

当第二检测结果表征NW向主叫UE播放提示音时，主叫UE执行S809。在S809中，主叫UE可以按照正常流程进行处理，例如主叫UE可以挂断通话，也可以不进行本地播放提示音。

在一些示例中，主叫UE可以在收到181消息后的第三预设时间段内，检测NW是否向主叫UE播放提示音，若在该第三预设时间段内，主叫UE仍未检测到NW向主叫UE播放提示音，则主叫UE确定NW未向主叫UE播放提示音的第三检测结果；若在该第三预设时间段内，主叫UE检测到NW向主叫UE播放提示音，则主叫UE确定NW向主叫UE播放提示音的第三检测结果。其中，上述第三预设时间段可以是从主叫UE接收到181消息开始到主叫UE接收到487消息为止对应的时间段；当然也可以是固定时长的时间段，例如2秒、3秒等。

需要说明的是，S804和S806中主叫UE检测NW是否向主叫UE播放提示音的方式可以参见S604，此处不再赘述。

需要说明的是，本申请不具体限定上述第三预设时间段的具体数值，在另一些示例中，第三预设时间段也可以是主叫UE多次从接收到181消息到接收到487消息所对应的平均值，也可以是经验值。本领域技术人员可以根据实际需要设定上述第三预设时间段。

S807：NW向主叫UE发送487消息。

当第三检测结果表征NW未向主叫UE播放提示音时，主叫UE执行 S808。在S808中，主叫UE从预先存储的提示音中选择与通话异常的原因对应的提示音进行播放。

主叫UE还可以向用户显示提示界面，如上述图7A-图7C所示，此处不再赘述。

当第三检测结果表征NW向主叫UE播放提示音时，主叫UE执行S809。

场景3：

在场景3中，主叫UE可以基于上述图2和图3所示的NW未发生故障时，主叫UE和NW之间的信令交互流程进行学习，例如主叫UE可以基于神经网络进行学习，从而主叫UE能够学习到上述图2和图3所示的场景中主叫UE和NW之间的信令交互流程。在另一些示例中，主叫UE也可以基于上述图2和图3所示的NW未发生故障时，主叫UE和NW之间的信令交互流程进行记录，从而主叫UE能够得到上述图2和图3所示的场景中主叫UE和NW之间的信令交互流程。

在场景3中，如图9所示，该图为本申请实施例提供的通话异常的提示方法的流程图，该方法包括：

S901：主叫UE判断本次通话的信令交互流程与第一参考流程是否一致；若否，则执行S902；若是，则执行S904。

第一参考流程可以是主叫UE基于上述图2和图3所学习和/或记录得到的主叫UE与NW之间的信令交互流程，即标准信令交互流程。在一些示例中，主叫UE可以在接收到NW发送的487消息后开始，将本次通话的信令交互流程与第一参考流程进行比较。当本次通话的信令交互流程与第一参考流程不一致时，则执行S902，否则执行S904。

需要说明的是，上述第一参考流程也可以是预先配置的信令交互流程。本领域技术人员可以根据实际需要选择第一参考流程的获取方式。

S902：主叫UE判断缺失的流程是否为NW未向主叫UE播放提示音；若是，则执行S903；若否，则执行S904。

当缺失的流程为NW未向主叫UE播放提示音时，主叫UE的用户将无法知晓本次通话异常的原因，进而会使该用户产生疑惑，影响用户体验。因此，在主叫UE判断缺失的流程为NW未向主叫UE播放提示音时，则执行S903，否则执行S904。

S903：主叫UE从预先存储的提示音中选择与通话异常的原因对应的提示音进行播放。

S904：主叫UE挂断通话。

需要说明的是，场景3所示的通话异常的提示方法可以应用在图4所示的示例S404之后，即在图4所示的示例中，主叫UE接收到NW发送的487消息后，开始执行S901；该提示方法还可以应用在图5所示的示例S505之后，即在图5所示的示例中，主叫UE接收到NW发送的487消息后，开始执行S901。

场景4：

在场景4中，主叫UE可以基于上述图2和图3所示的NW未发生故障时，主叫UE和NW之间的信令交互流程进行学习，例如主叫UE可以基于神经网络进行学习，从而主叫UE能够学习到上述图2和图3所示的场景中主叫UE和NW之间的信令交互流程。在另一些示例中，主叫UE也可以基于上述图2和图3所示的NW未发生故障时，主叫UE和NW之间的信令交互流程进行记录，从而主叫UE能够得到上述图2和图3所示的场景中主叫UE和NW之间的信令交互流程。

与场景3不同的是，在场景4中，主叫UE可以在每发生一次信令交互（例如接收信令或发送信令）时，判断该信令交互是否符合第二参考流程。如图10所示，图为本申请实施例提供的通话异常的提示方法的流程图，该方法包括：

S1001：主叫UE获取发生的信令交互。

S1002：主叫UE判断本次发生的信令交互是否符合第二参考流程；若是，返回S1001，以在下次发生的信令交互后，对下次发生的信令交互进行判断，若否，则执行S1003。

第二参考流程可以是主叫UE基于上述图2和图3所学习和/或记录得到的主叫UE与NW之间的信令交互流程，即标准信令交互流程。在一些示例中，主叫UE可以在接收到NW发送的183消息后开始，将本次发生的信令交互与第二参考流程进行比较。当本次发生的信令交互符合第二参考流程时，对下次发生的信令交互进行判断，否则执行S1003。下面举例说明本次发生的信令交互符合第二参考流程，例如，本次发生的信令交互为信令1，若第二参考流程中规定本次信令交互为信令1，则符合第二参考流程；若第二参考流程中规定本次信令交互为信令2，则不合符第二参考流程。

需要说明的是，上述第二参考流程也可以是预先配置的信令交互流程。本领域技术人员可以根据实际需要选择第二参考流程的获取方式。

S1003：主叫UE判断本次发生的信令交互在第二参考流程中对应的信令交互是否为NW向主叫UE播放提示音；若是，则执行S1004；若否，返回S1001，以在下次发生的信令交互后，对下次发生的信令交互进行判断。

在一些示例中，主叫UE在将本次发生的信令交互与第二参考流程进行比较后，即可确定本次发生的信令交互在第二参考流程中对应的信令交互。

当本次发生的信令交互在第二参考流程中对应的信令交互为NW未向主叫UE播放提示音时，主叫UE的用户将无法知晓本次通话异常的原因，进而会使该用户产生疑惑，影响用户体验。因此，在主叫UE判断NW未向主叫UE播放提示音时，则执行S1004，否则对下次发生的信令交互进行判断。

S1004：主叫UE从预先存储的提示音中选择与通话异常的原因对应的提示音进行播放。

需要说明的是，场景4所示的通话异常的提示方法可以应用在图4所示的示例中任一步骤之后，例如在S401之后，开始执行S1001；该提示方法还可以应用在图5所示的示例中任一步骤之后，例如在S501后，开始执行S1001。

场景5：

在场景5中，主叫UE可以基于上述图4和图5所示的NW发生故障时，主叫UE和NW之间的信令交互流程进行学习，例如主叫UE可以基于神经网络进行学习，从而主叫UE能够学习到上述图4和图5所示的场景中主叫UE和NW之间的信令交互流程。在另一些示例中，主叫UE也可以基于上述图4和图5所示的NW发生故障时，主叫UE和NW之间的信令交互流程进行记录，从而主叫UE能够得到上述图4和图5所示的场景中主叫UE和NW之间的信令交互流程。

在场景5中，如图11所示，该图为本申请实施例提供的通话异常的提示方法的流程图，该方法包括：

S1101：主叫UE判断本次通话的信令交互流程与第三参考流程是否一致；若是，则执行S1102；若否，则执行S1103。

第三参考流程可以是主叫UE基于上述图4和图5所学习和/或记录得到的主叫UE与NW之间的信令交互流程，即异常信令交互流程。在一些示例中，主叫UE可以在接收到NW发送的487消息后开始，将本次通话的信令交互流程与第三参考流程进行比较。当本次通话的信令交互流程与第三参考流程一致时，则执行S1102，否则执行S1103。

需要说明的是，上述第三参考流程也可以是预先配置的信令交互流程。本领域技术人员可以根据实际需要选择第三参考流程的获取方式。

S1102：主叫UE从预先存储的提示音中选择与通话异常的原因对应的提示音进行播放。

S1103：主叫UE挂断通话。

需要说明的是，场景5所示的通话异常的提示方法可以应用在图4所示的示例S404之后，即在图4所示的示例中，主叫UE接收到NW发送的487消息后，开始执行S1101；该提示方法还可以应用在图5所示的示例S505之后，即在图5所示的示例中，主叫UE接收到NW发送的487消息后，开始执行S1101。

基于上述内容描述，本申请实施例提供了一种通话异常的提示方法，该方法可以在由于NW故障导致NW没有向主叫UE播放提示音时，主叫UE基于通话异常的原因，向用户播放与该通话异常的原因相对应的提示音。如此，即使NW出现故障，主叫UE也能够提示用户通话异常的原因，消除用户的疑惑，提高了用户体验。

需要说明的是，本申请的上述各个实施例之间相同或相似的步骤可以互相参考。

在一些实施例中，上述主叫UE可以是电子设备，电子设备可以是手机、平板电脑、桌面型、膝上型、笔记本电脑、超级移动个人计算机（Ultra-mobile Personal Computer，UMPC）、手持计算机、上网本、个人数字助理（Personal Digital Assistant，PDA）、可穿戴电子设备、智能手表等设备，本申请对上述电子设备的具体形式不做特殊限制。在本实施例中，电子设备的结构可以如图12所示，图12为本申请实施例提供的一种电子设备的结构示意图。

如图12所示，电子设备可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。

可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，在本申请中，处理器110确定通话异常，然后检测网络是否向主叫UE播放提示音，获得检测检测，当检测结果表征网络未向主叫UE播放提示音时，根据通话异常的原因呈现对应的提示信息。

其中，控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

在一些实施例中，电子设备的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code divisionmultiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC ，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system ，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidounavigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellitesystem，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

电子设备通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息，如显示提示语等。

电子设备的显示屏194上可以显示一系列图形用户界面（graphical userinterface，GUI），这些GUI都是该电子设备的主屏幕。一般来说，电子设备的显示屏194的尺寸是固定的，只能在该电子设备的显示屏194中显示有限的控件。控件是一种GUI元素，它是一种软件组件，包含在应用程序中，控制着该应用程序处理的所有数据以及关于这些数据的交互操作，用户可以通过直接操作（direct manipulation）来与控件交互，从而对应用程序的有关信息进行读取或者编辑。一般而言，控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。。

电子设备可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音，播放提示音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备可以通过扬声器170A收听音乐，或收听免提通话，或播放提示音。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备可以设置至少一个麦克风170C。在另一些实施例中，电子设备可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

本申请的一些实施例还提供了一种电子设备，如图13所示，该电子设备包括：一个或多个处理器1302；存储器1303；以及一个或多个计算机程序1304，上述各器件可以通过一个或多个通信总线1305连接。其中该一个或多个计算机程序1304被存储在上述存储器1303中，并被配置为被该一个或多个处理器1302执行，该一个或多个计算机程序1304包括指令，上述指令可以用于执行如图2至图11相应实施例中手机执行的各个步骤。当然，图13所示的电子设备还可以包括如传感器模块、音频模块以及SIM卡接口等其他器件，本申请实施例对此不做任何限制。其中，该电子设备还可以包括显示屏1301和扬声器1306，该显示屏1301可以用于向用户显示提示语，该扬声器1306可以用于向用户播放提示音。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中包括指令，当上述指令在电子设备上运行时，使得该电子设备执行图2至图11中的相关方法步骤，以实现上述实施例中的方法。

本申请实施例还提供了一种包含指令的计算机程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行如图2至图11中的相关方法步骤，以实现上述实施例中的方法。

本实施例还提供了一种控制设备，所述控制设备包括处理器和存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器执行所述计算机指令时，所述控制设备执行如图2至图11中的相关方法步骤实现上述实施例中的方法。该控制设备可以是一个集成电路IC，也可以是一个片上系统SOC。其中集成电路可以是通用集成电路，也可以是一个现场可编程门阵列FPGA，也可以是一个专用集成电路ASIC。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器执行各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种通信系统，其特征在于，所述通信系统包括主叫用户设备UE和网络；

所述网络，用于当通话异常时，向主叫UE发送会话初始协议SIP消息；

所述主叫UE，用于根据所述SIP消息确定通话异常；还用于检测网络是否向所述主叫UE播放提示音，获得检测结果；当检测结果表征所述网络未向所述主叫UE播放提示音时，根据所述通话异常的原因呈现对应的提示信息。

2.一种通话异常的提示方法，其特征在于，所述方法应用于主叫用户设备UE，所述方法包括：

主叫UE确定通话异常；

所述主叫UE检测网络是否向所述主叫UE播放提示音，获得检测结果；

当检测结果表征网络未向所述主叫UE播放提示音时，所述主叫UE根据通话异常的原因呈现对应的提示信息。

3.根据权利要求2所述的方法，其特征在于，所述主叫UE检测网络是否向所述主叫UE播放提示音，获得检测结果，包括：

4.根据权利要求2所述的方法，其特征在于，所述主叫UE检测网络是否向所述主叫UE播放提示音，获得检测结果，包括：

5.根据权利要求4所述的方法，其特征在于，所述标准信令交互流程通过预先配置得到或通过神经网络预先学习得到。

6.根据权利要求2所述的方法，其特征在于，所述主叫UE检测网络是否向所述主叫UE播放提示音，获得检测结果，包括：

7.根据权利要求6所述的方法，其特征在于，所述异常信令交互流程通过预先配置得到或通过神经网络预先学习得到。

8.根据权利要求2所述的方法，其特征在于，所述主叫UE确定通话异常包括：

所述主叫UE接收网络发送的SIP消息，所述SIP消息携带有通话异常的原因；

所述主叫UE根据所述通话异常的原因确定通话异常。

9.根据权利要求2-8任一项所述的方法，其特征在于，所述主叫UE根据通话异常的原因呈现对应的提示信息，包括：

所述主叫UE根据通话异常的原因播放对应的提示音；和/或，

所述主叫UE根据通话异常的原因显示对应的提示语。

10.一种电子设备，其特征在于，包括：

存储器和处理器；

在所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令；当所述指令被所述处理器执行时，使得所述电子设备执如权利要求2至9中任一项所述的方法。

11.一种计算机存储介质，其特征在于，包括计算机指令，当所述计算机指令在计算设备上运行时，所述计算设备执行如权利要求2至9中任一项所述的方法。