CN114051070A - 一种来电通知方法及装置 - Google Patents

Abstract

本申请公开一种来电通知方法及装置，其特征在于，该方法包括：被叫终端接收到错误反馈信息，其中该被叫终端处于被主叫终端的第一来电呼叫且未响铃的状态，该错误反馈信息用于表示该第一来电在响铃前接通失败；该被叫终端根据该错误反馈信息确定该第一来电在响铃前接通失败的失败原因；该被叫终端至少根据该失败原因输出目标提示信息，该目标提示信息为多个不同的提示信息中与该失败原因对应的提示信息，该多个不同的提示信息中的每一个提示信息分别用于表示一种该第一来电在响铃前接通失败的原因。从而避免用户错过重要来电，同时可以帮助被叫用户根据失败原因确定是否需要回拨主叫终端，满足用户需求，帮助用户减少工作量。

Description

一种来电通知方法及装置

技术领域

本申请涉及计算机领域，尤其涉及一种来电通知方法及装置。

背景技术

随着移动终端的发展，手机已经成为生活中、工作中不可或缺的工具，尤其是在于人与人的联系方面，人们可以通过手机打电话交谈，为日常生活带来很大的便捷。

目前，主叫手机通过IP多协议子系统（IP Multimedia Subsystem，IMS）呼叫被叫手机，被叫手机需要先与IMS完成会话初始协议（Session initialization Protocol，SIP）中关于被叫接通流程的信令交互，具体的，当信令交互流程走到被叫手机向IMS发送180振铃消息的流程时，被叫手机才会开始响铃。

然而，若被叫接通流程的信令交互未走到被叫手机向IMS发送180振铃消息的流程，则此次来电在被叫手机响铃前接通失败，被叫手机不会响铃，被叫用户无法感知到主叫手机的此次来电，可能导致被叫用户错过重要来电。

发明内容

第一方面，本申请提供一种来电通知方法，所述方法包括：所述被叫终端接收到错误反馈信息，其中所述被叫终端处于被主叫终端的第一来电呼叫且未响铃的状态，所述错误反馈信息用于表示所述第一来电在响铃前接通失败；所述被叫终端根据所述错误反馈信息确定所述第一来电在响铃前接通失败的失败原因；所述被叫终端至少根据所述失败原因输出目标提示信息，所述目标提示信息为多个不同的提示信息中与所述失败原因对应的提示信息，所述多个不同的提示信息中的每一个提示信息分别用于表示一种所述第一来电在响铃前接通失败的原因。

示例性的，上述目标提示信息中可以不包括该主叫终端的标识，例如该目标提示信息为：“您有一个由于网络异常的未响铃来电”，而对于未响铃来电的其他详细信息（例如主叫终端的电话号码、该主叫终端的电话号码对应的主叫用户的昵称、或关于该主叫终端的电话号码在一定时长内的未响铃来电的次数等信息中的一项或多项），可以到终端中相应的其他界面查看。

示例性的，上述目标提示信息中也可以包括该主叫终端的标识（例如主叫终端的电话号码），或者，该提示信息中可以包括该主叫终端的标识在该被叫终端中对应的昵称（例如在该被叫终端中与该主叫终端的电话号码对应的昵称），或者，该提示信息中还可以包括该第一来电的来电时间，本文对此不做限定。

示例性的，被叫终端可以为移动终端或平板电脑。

可理解的，上述被叫终端处于被主叫终端的第一来电呼叫且未响铃的状态，也即该被叫终端被该主叫终端呼叫，但该被叫终端未对该主叫终端的呼叫做出响铃响应。具体的，被叫终端接收该IP多协议子系统发送的关于该第一来电的呼叫请求消息后，被叫终端未向IP多协议子系统发送针对该第一来电的呼叫请求消息的振铃180 ringing消息之前，该被叫终端则处于被主叫终端的第一来电呼叫且未响铃的状态。

示例性的，该第一来电可以包括该主叫终端的电话号码以及来电时间（来电时间也可以理解为呼叫时间，本文对此不做限定）。

在本申请实施例中，错误反馈信息可以包括用于指示上述第一来电接通失败的失败原因的信息；示例性的，错误反馈信息可以是用于指示上述第一来电接通失败的失败原因为网络异常的信息；示例性的，错误反馈信息也可以是包括用于指示上述第一来电接通失败的失败原因为主叫用户主动挂断的信息；示例性的，错误反馈信息中也可以是用于指示上述第一来电接通失败的失败原因为未知的错误的信息。从而被叫终端可以通过错误反馈信息确定该第一来电在响铃前接通失败的失败原因。

可理解的，该错误反馈信息还可以是用于指示其他失败原因的信息（例如用于指示由于数据丢包导致来电接通失败的信息等），本文对此不做限定。

在本申请实施例中，上述多个不同的提示信息中的每一个提示信息分别用于表示一种与其他提示信息不同的上述第一来电在响铃前接通失败的原因。示例性的，该多个不同的提示信息包括提示信息A、提示信息B和提示信息C；该提示信息A、该提示信息B或该提示信息C分别用于表示一种不同的该第一来电在响铃前接通失败的原因；例如，该提示信息A用于表示该第一来电在响铃前接通失败的原因为网络异常，该提示信息B用于表示该第一来电在响铃前接通失败的原因为主叫终端主动挂断，该提示信息C用于标识该第一来电在响铃前接通失败的原因为未知的错误。

示例性的，上述目标失败原因可以是第一来电在未响铃前接通失败的失败原因为网络异常，该第一来电中用于指示主叫终端的电话号码，该第一来电还可以用于指示来电时间和/或拨打次数。可理解的，输出第一来电在未响铃前接通失败的失败原因既可以向被叫用户指示该第一来电在未响铃前接通失败，还可以向被叫用户指示该第一来电接通失败的失败原因。

可理解的，若只向被叫用户输出关于主叫终端的未响铃来电接通失败，会使得被叫用户对未响铃来电接通失败的原因存在一定的困扰，为得到未响铃来电接通失败的原因以免错误重要来电，用户则会选择一一未响铃来电对应的主叫终端去电回拨，询问该未响铃来电接通失败的原因，从而会给被叫用户带来较大的工作量。

由此，采用本申请实施例提供的来电通知方法，对于响铃前接通失败的第一来电（也即未响铃来电），输出该未响铃来电的提示信息，避免用户错过重要来电。同时基于错误检查，进一步剖析呼叫接通失败的失败原因，基于呼叫接通失败的不同失败原因，输出与失败原因对应的提示信息，被叫用户可以根据失败原因确定是否需要回拨主叫终端，满足用户需求，帮助用户减少工作量，以及减少终端不必要的性能损耗。

结合第一方面，在一种可能的实施方式中，所述错误反馈信息包括第一类型错误反馈信息，所述第一类型错误反馈信息为预设的用于表示主叫终端主动挂断导致呼叫接通失败的错误反馈信息，所述被叫终端根据所述错误反馈信息确定所述第一来电在响铃前接通失败的失败原因，具体包括：所述被叫终端根据所述第一类型错误反馈信息确定所述失败原因为所述主叫终端主动挂断；所述被叫终端至少根据所述失败原因输出目标提示信息，具体包括：所述被叫终端输出第一提示信息，所述第一提示信息用于指示所述第一来电在响铃前由于所述主叫终端主动挂断导致呼叫接通失败。

可理解的，上述第一来电在响铃前由于上述主叫终端主动挂断导致呼叫接通失败，也即该第一来电在响铃前由于该主叫终端主动挂断该第一来电从而导致呼叫接通失败。主叫终端主动挂断也可以理解为主叫用户主动挂断，或者也可以理解为主叫用户通过该主叫终端主动挂断，本文对此不做限定。

示例性的，上述第一类型错误反馈信息可以是与失败原因对应的标识，一个标识用于唯一标识对应的失败原因。该标识可以包括一个或多个组成部分，例如该标识可以包括数值和文字两个部分，该数值部分也可以理解为原因值（cause值）部分，该文字部分也可以理解为关于该原因值的相关说明（text值）部分。

可选的，上述第一提示信息可以包括主叫终端的电话号码和失败原因，还可以包括来电时间以及来电次数中的一项或多项。示例性的，上述第一提示信息可以包括上述主叫终端的电话号码、该主叫终端发起呼叫的呼叫时间以及上述失败原因。例如，该第一提示内容为：“11月29日14时12分您有一通来自139xxxxxx85号码的来电，在响铃前因对方挂断而终止”。可选的，还可以进一步根据主叫终端的电话号码是否包含于被叫终端的通讯录中，若是，该第一提示信息中还可以包括该主叫终端的电话号码对应的昵称，例如上述第一提示信息中包括该139xxxxxx85号码的昵称为小明。

在本申请实施例中，在失败原因为主叫终端主动挂断的情况下，输出向被叫用户指示由于主叫用户主动挂断导致来电在未响铃前接通失败的提示信息。一般地，主叫用户在未接通前主动挂断可能是主叫用户不小心点错了然后匆忙挂断的，这时被叫用户查看到该提示信息后，发现恰好主叫终端的电话号码为陌生号码，则可以不做处理。可理解的，主叫用户在未接通前主动挂断也有可能是主叫用户处于被控制等危险处境中，这时被叫用户查看到该提示信息后，发现恰好主叫终端的电话号码为熟悉的号码，则可以选择回拨或做其他处理。由此，在更进一步地避免用户错过重要来电以及帮助用户减少工作量。

结合第一方面，在一种可能的实施方式中，所述第一类型错误反馈信息包括第一类型会话初始协议SIP错误码中的一项或多项SIP错误码和/或第一类型会话取消消息中的一项或多项会话取消消息，所述第一类型SIP错误码为预设的用于表示主叫终端主动挂断导致呼叫接通失败的SIP错误码的集合，所述第一类型会话取消消息为预设的用于表示主叫终端主动挂断导致呼叫接通失败的会话取消消息的集合。

在本申请实施例中，错误反馈信息可以包括SIP错误码，上述第一类型错误反馈信息可以包括该SIP错误码中预设的用于表示主叫终端主动挂断导致呼叫接通失败的SIP错误码的集合，也即第一类型错误反馈信息可以包括上述第一类型SIP错误码。该错误反馈信息还可以包括会话取消消息（会话取消消息即为cancel消息），上述第一类型错误反馈信息还可以包括该cancel消息中预设的用于表示主叫终端主动挂断导致呼叫接通失败的会话取消消息的集合，也即该第一类型错误反馈信息还可以包括上述第一类型会话取消消息。

可理解的，上述预设的用于表示主叫终端主动挂断导致呼叫接通失败的SIP错误码或cancel消息的具体取值依据通信标准而定，本文对此不做限定。

结合第一方面，在一种可能的实施方式中，所述第一类型SIP错误码包括486SIP错误码、600SIP错误码、或603SIP错误码中的一项或多项；所述第一类型会话取消消息包括所述第一类型SIP错误码、原因值为17且错误原因说明为用户忙的会话取消消息或原因值为1且原因值说明为用户结束呼叫的会话取消消息中的一项或多项。

在本申请实施例中，上述cancel消息可以包括SIP错误码、错误原因协议（Q.850cause）以及释放原因消息（RELEASE_CAUSE）中的一项或多项，其中，该Q.850 cause中的错误码（错误码也可以理解为原因值，例如cause值）为17且错误原因说明（错误原因说明也可以理解为原因值说明，例如text值）为用户忙（user busy）的cancel消息、以及RELEASE_CAUSE中原因值为1（例如cause值为1）且原因值说明为用户结束呼叫（例如text值为Userends call）的cancel消息用于表示主叫终端主动挂断导致呼叫接通失败。

示例性的，上述486SIP错误码可以是cause值为486且text值为此处太忙busyhere的SIP错误码，上述600 SIP错误码为cause值为600且text值为各处均忙busyeverywhere的SIP错误码；上述603错误码为cause值为603且text值为婉拒decline的SIP错误码。

在本申请实施例中，可以采用原因值（例如cause值）标识一个SIP错误码，例如486SIP错误码用于标识cause值为486且text值为此处太忙busy here的SIP错误码。也可以采用原因值和原因值说明来标识一个SIP错误码，本文对此不做限定。可以采用原因值（例如cause值）标识一个cancel消息，也可以采用原因值和原因值说明来标识一个cancel消息，在另外一些实施方式中，还可以采用原因值、原因值说明以及原因值类型来标识一个cancel消息，例如采用reason：Q.850 Cause；Cause:17；text：“user busy”标识一个cancel消息。

结合第一方面，在一种可能的实施方式中，所述错误反馈信息包括第二类型错误反馈信息，所述第二类型错误反馈信息为预设的用于表示网络异常导致呼叫接通失败的错误反馈信息，所述被叫终端根据所述错误反馈信息确定所述第一来电在响铃前接通失败的失败原因，具体包括：所述被叫终端根据所述第二类型错误反馈信息确定所述失败原因为网络异常；所述被叫终端至少根据所述失败原因输出目标提示信息，具体包括：所述被叫终端输出第二提示信息，所述第二提示信息用于指示所述第一来电在响铃前由于网络异常导致呼叫接通失败。

示例性的，第二错误反馈信息可以为错误反馈信息中除了第一类型错误反馈信息之外的其他反馈信息中的全部或部分反馈信息。示例性的，该错误反馈信息还可能包括第三错误反馈信息，该第三错误反馈信息为该错误反馈信息中除了第一类型错误反馈信息和第二类型错误反馈信息之外的其他反馈信息中的全部或部分反馈信息。例如，该第三错误反馈信息为预设的用于表示由于数据丢包导致呼叫接通失败的错误反馈信息，或者，该第三错误反馈信息为预设的用于表示由于未知的错误导致呼叫接通失败的错误反馈信息，本文对于该错误反馈信息可以包括的不同类型的错误反馈信息的数量不做限定。

在本申请实施例中，该第二错误反馈信息用于表示由于网络异常导致呼叫接通失败，该网络异常可以是指IP多协议子系统（IP Multimedia Subsystem，IMS）（也可以理解为通话服务器）网络异常，也可以是指主叫终端或被叫终端的网络异常。在另外一些实现方式中，也可以根据预设的用于表示网络异常方的主体（例如网络异常方的主体可以是服务器、主叫终端或被叫终端）的错误码输出对应的主体网络异常导致呼叫接通失败的提示信息，本文对此不做限定。

在本申请实施例中，在失败原因为网络异常的情况下，输出向被叫用户指示由于网络异常导致来电在未响铃前接通失败的提示信息。一般地，由于网络异常在未响铃前挂断的来电，一般是主叫用户确定要拨打的来电，而不是主叫用户不小心点错而匆忙挂断的，被叫用户可以根据该网络异常的失败原因确定这通来电的重要程度，更进一步地避免用户错过重要来电。

结合第一方面，在一种可能的实施方式中，所述第二类型错误反馈信息包括第二类型会话初始协议SIP错误码中的一项或多项SIP错误码和/或第二类型会话取消消息中的一项或多项会话取消消息，所述第二类型SIP错误码为预设的用于表示网络异常导致呼叫接通失败的SIP错误码的集合，所述第二类型会话取消消息为预设的用于表示网络异常导致呼叫接通失败的会话取消消息的集合。

在本申请实施例中，上述第二类型SIP错误码可以是SIP错误码中除了上述第一类型SIP错误码之外的其他SIP错误码中的全部或部分SIP错误码。上述第二类型会话取消消息可以是cancel消息中除了上述第一类型cancel消息的其他cancel消息中的全部或部分cancel消息。

结合第一方面，在一种可能的实施方式中，所述第二类型SIP错误码包括SIP错误码中除了486SIP错误码、600SIP错误码、以及603SIP错误码之外的其他SIP错误码；所述第二类型会话取消消息包括除了所述486SIP错误码、所述600SIP错误码、以及所述603SIP错误码、错误码为17且错误原因说明为用户忙的会话取消消息以及原因值为1且原因值说明为用户结束呼叫的会话取消消息之外的cancel消息。

结合第一方面，在一种可能的实施方式中，所述被叫终端根据所述错误反馈信息确定所述第一来电在响铃前接通失败的失败原因，具体包括：在确定所述错误反馈信息包含于第一类型错误反馈信息的情况下，所述被叫终端确定所述失败原因为所述主叫终端主动挂断，所述第一类型错误反馈信息为预设的用于表示主叫终端主动挂断导致呼叫接通失败的错误反馈信息的集合；在确定所述错误反馈信息包含于第二类型错误反馈信息的情况下，所述被叫终端确定所述失败原因为网络异常，所述第二类型错误反馈信息为预设的用于表示网络异常导致呼叫接通失败的错误反馈信息的集合；所述被叫终端至少根据所述失败原因输出目标提示信息，具体包括：在所述被叫终端确定所述失败原因为所述主叫终端主动挂断的情况下，所述被叫终端输出第一提示信息，所述第一提示信息用于指示所述第一来电在响铃前由于主叫终端主动挂断导致呼叫接通失败；在所述被叫终端确定所述失败原因为网络异常的情况下，所述被叫终端输出第二提示信息，所述第二提示信息用于指示所述第一来电在响铃前由于网络异常导致呼叫接通失败。

结合第一方面，在一种可能的实施方式中，在所述在被主叫终端的第一来电呼叫且被叫终端未响铃的情况下，所述被叫终端接收到错误反馈信息之前，所述方法还包括：所述被叫终端接收IP多协议子系统发送的第一呼叫请求消息，所述第一呼叫请求消息用于指示所述第一来电，第一呼叫请求消息为所述IP多协议子系统根据所述主叫终端呼叫所述被叫终端的呼叫信息生成的，其中，所述第一呼叫请求消息包括所述主叫终端的电话号码；在所述被叫终端至少根据所述失败原因输出目标提示信息之前，所述方法还包括：所述被叫终端确定是否输出关于所述第一来电的未响铃通知；所述被叫终端至少根据所述失败原因输出目标提示信息包括：在所述被叫终端确定输出关于所述第一来电的未响铃通知的情况下，所述被叫终端至少根据所述失败原因输出所述目标提示信息。

可理解的，上述第一呼叫请求消息（也即第一invite消息）中还可以包括呼叫时间、包括此次会话的呼叫标识（call-ID）（该call-ID用于唯一标识该第一invite消息）、会话类型以及传输类型等其他信息，具体包括何种信息根据SIP协议而定，本文对此不做限定。

结合第一方面，在一种可能的实施方式中，所述被叫终端中记录的白名单中包括所述主叫终端的电话号码，所述白名单为被叫用户在所述被叫终端中记录的对于未响铃来电输出提示信息的号码列表，所述被叫终端确定是否输出关于所述第一来电的未响铃通知，具体包括：所述被叫终端根据所述白名单确定输出关于所述第一来电的未响铃通知。

上述被叫终端中记录的白名单中包括所述主叫终端的电话号码，也可以理解为该主叫终端的电话号码包含于该白名单中。

在本申请实施例中，上述白名单可以存储于被叫终端中，也可以存储于被叫终端的云端服务器中，本文对此不做限定。当该白名单存储于该云端服务器时，被叫终端可以从该云端服务器中获取该白名单，从而可以在需要的时候将白名单的数据在被叫终端中显示，从而可以理解为被叫终端中记录有白名单。

示例性的，根据主叫终端的电话号码的类型，例如电话号码为陌生号码则不输出上述目标提示信息，电话号码为白名单中的号码则输出上述目标提示信息。由此，对于未响铃来电增加根据主叫终端的电话号码的类型做进一步的未响铃来电通知的管控处理，在未响铃来电为被叫用户允许输出该未响铃来电的通知消息的情况下，才向被叫用户输出明确的通知消息，在避免用户错过重要来电的同时减少未响铃来电通知给被叫用户带来的一些不必要的打扰，以及避免非必要的未响铃来电提醒增加被叫用户的工作量。

结合第一方面，在一种可能的实施方式中，所述被叫终端确定是否输出关于所述第一来电的未响铃通知，具体包括：在根据所述主叫终端的电话号码和历史未响铃来电列表确定预设时长内关于所述主叫终端的未响铃来电的次数大于第一阈值的情况下，所述被叫终端确定输出关于所述第一来电的未响铃通知，所述历史未响铃来电列表用于记录每个未响铃来电中主叫终端的电话号码和来电时间，所述第一阈值为大于或等于2的正整数。

结合第一方面，在一种可能的实施方式中，在所述预设时长内关于所述主叫终端的未响铃来电的次数小于或等于所述第一阈值的情况下，所述被叫终端根据所述第一呼叫请求消息存储所述第一来电的来电信息，且确定不输出关于所述第一来电的未响铃通知，所述第一来电的来电信息包括所述主叫终端的电话号码和所述来电时间。

结合第一方面，在一种可能的实施方式中，所述第一呼叫请求消息还包括来电时间，所述被叫终端中记录的黑名单、白名单、或特殊类别号码中均不包括所述主叫终端的电话号码，所述特殊类别号码包括与所述被叫终端使用相同操作系统的终端用户标记过的号码，所述黑名单为被叫用户在所述被叫终端中记录的对于未响铃来电不输出提示信息的号码列表，所述白名单为被叫用户在所述被叫终端中记录的对于未响铃来电输出提示信息的号码列表，所述被叫终端确定是否输出关于所述第一来电的未响铃通知，具体包括：在根据所述主叫终端的电话号码和历史未响铃来电列表确定预设时长内关于所述主叫终端的未响铃来电的次数大于第一阈值的情况下，所述确定输出关于所述第一来电的未响铃通知，所述历史未响铃来电列表用于记录每个未响铃来电中主叫终端的电话号码和来电时间，所述第一阈值为大于或等于2的正整数。

在本申请实施例中，对于不属于上述特殊类别号码、白名单或黑名单中的任一项的陌生电话，进一步判断该陌生电话在预设时长内的未响铃来电次数是否超过第一阈值（示例性的，该第一阈值为3），通过来电次数确定未响铃来电的重要程度和/或紧急程度。若该主叫终端的电话号码在预设时长内的未响铃来电次数超过第一阈值则输出对应的提示信息，在避免被叫用户错过重要来电的同时对未响铃来电增加输出条件，过滤非必要的未响铃来电，进一步避免非必要的未响铃来电提醒增加被叫用户的工作量。

结合第一方面，在一种可能的实现方式中，所述第一呼叫请求消息还包括来电时间，所述多个不同的提示信息中的任意一个提示信息还携带所述主叫终端的电话号码和所述来电时间。

结合第一方面，在一种可能的实现方式中，所述第一呼叫请求消息包括主叫终端的电话号码和来电时间，所述多个不同的提示信息中的任意一个提示信息包括所述主叫终端的电话号码、所述来电时间以及预设时长内该主叫终端的电话号码的未响铃来电的来电次数。

可理解的，若该主叫终端的电话号码在预设时长内的未响铃来电次数未超过第一阈值则存储该第一来电的来电信息，以使得后续若关于该被叫终端的电话号码再次出现未响铃来电时，可以确定在预设时长内关于该被叫终端的电话号码的未响铃来电是否大于上述第一阈值。

可选的，在一种可能的实施方式中，也可以针对上述历史未响铃来电列表中来电时间与当前时间的时间差值的绝对值大于上述预设时长的未响铃来电做清除处理，从而可以节省存储空间，提供存储空间的利用率。

结合第一方面，在一种可能的实施方式中，所述主叫终端的电话号码包含于特殊类别号码，所述特殊类别号码包括与所述被叫终端使用相同操作系统的终端用户标记过的号码，所述方法还包括：在所述被叫终端根据所述特殊类别号码确定不输出关于所述第一来电的未响铃通知的情况下，所述被叫终端不输出所述目标提示信息。

示例性的，该特殊类别号码可以为被终端用户标记过为骚扰电话或诈骗电话的特殊类别号码。

由此，当主叫终端的电话号码不包含与该特殊类别号码时，可以输出上述目标提示信息。对于主叫终端的电话号码包含于特殊类别电话则不输出上述目标提示信息，在避免用户错过重要来电的同时，进一步减少未响铃来电通知给被叫用户带来的一些不必要的打扰，以及避免非必要的未响铃来电提醒增加被叫用户的工作量。

在另外一种可能的实现方式中，上述主叫终端的电话号码也可以既包含于上述特殊类别电话号码，也包含于上述白名单中，这种情况下，可理解为被标记的该主叫终端的电话号码恰好是被叫用户认识且被叫用户认为较重要的对于未响铃来电需要输出提示信息的号码，这时，可以被叫终端可以确定输出上述目标提示信息，以避免被叫用户错过重要来电。

结合第一方面，在一种可能的实施方式中，所述被叫终端中记录的黑名单包括所述主叫终端的电话号码，所述黑名单为被叫用户在所述被叫终端中记录的对于未响铃来电不输出提示信息的号码列表，所述方法还包括：在所述被叫终端根据所述黑名单确定不输出关于所述第一来电的未响铃通知的情况下，所述被叫终端不输出所述目标提示信息。

可理解的，上述白名单和上述黑名单中不存在同一个的电话号码，也就是，不存在任意一个电话号码，该电话号码既包含于该黑名单又包含于该白名单。

由此，当主叫终端的电话号码包含于黑名单时，不输出上述目标提示信息，在避免用户错过重要来电的同时，进一步减少未响铃来电通知给被叫用户带来的一些不必要的打扰，以及避免非必要的未响铃来电提醒增加被叫用户的工作量。

可理解的，上述关于特殊类别号码、白名单、黑名单或预设时长内的未响铃来电的次数中的一项或多项的管控处理，可以在被叫终端根据错误反馈信息确定第一来电在响铃前接通失败的失败原因之前或之后执行。示例性的，在被叫终端根据错误反馈信息确定第一来电在响铃前接通失败的失败原因之后执行，例如，在确定到失败原因为主叫终端主动挂断之后，再确定该主叫终端的电话号码是否包含于黑名单，在确定该主叫终端的电话号码包含于黑名单的情况下，确定不输出上述第一提示信息。示例性的，在被叫终端根据错误反馈信息确定第一来电在响铃前接通失败的失败原因之前执行，例如，被叫终端先确定该主叫终端的电话号码是否包含于黑名单，若是，则被叫终端不再根据错误反馈信息确定第一来电在响铃前接通失败的失败原因，从而可以减少被叫终端的性能损耗。

结合第一方面，在一种可能的实施方式中，在所述被叫终端接收IP多协议子系统发送的第一呼叫请求消息之后，所述方法还包括：在确定不向所述IP多协议子系统发送试呼叫消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息；或者，在确定向所述IP多协议子系统发送所述试呼叫消息、且确定不向所述IP多协议子系统发送会话进行消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述会话进行消息用于表示正在处理一些操作以响应所述第一呼叫请求；或者，在确定向所述IP多协议子系统发送所述会话进行消息、且确定未接收到所述IP多协议子系统发送的临时应答消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述临时应答消息用于表示所述IP多协议子系统已接收到所述会话进行消息；或者，在确定接收到所述临时应答消息、且确定不向所述IP多协议子系统发送第一会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述第一会话成功消息用于表示所述IP多协议子系统与所述被叫终端关于所述第一临时应答消息的会话成功完成；或者，在确定向所述IP多协议子系统发送所述第一会话成功消息、且确定不向所述IP多协议子系统发送振铃消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述振铃消息用于表示所述被叫终端已开始响铃。

可理解的，在被叫终端接收到上述第一呼叫请求消息（也即接收到上述第一来电呼叫后），IP多协议子系统与被叫终端会针对该第一呼叫请求消息依次进行被叫接通流程的N（N为大于或等于1的正整数）次信令交互，若该N次信令交互中的任意一个信令交互失败则表示该第一来电在未响铃前接通失败。示例性的，被叫接通流程的信令交互为不带资源预留的信令交互的情况下，该N的值为5，依次进行的5次信令交互包括上述试呼叫（100trying）消息、会话进行（183 session progress）消息、临时应答（PRACK）消息、第一会话成功（200 ok）消息以及振铃（180 ringing）消息的信令交互。

在本申请实施例中，所述被叫终端依次判断该5次信令交互是否交互成功，在确定交互不成功的情况下，所述被叫终端确定是否接收到所述错误反馈信息。若确定任意一个信令交互失败，则不再判断下一个信令是否交互成功。由此，在帮助被叫用户避免错过重要来电的同时，减少被叫终端确认一通接通失败的未响铃来电所需的性能消耗（例如电量损耗和/或硬件执行损耗等）。

结合第一方面，在一种可能的实施方式中，在所述被叫终端接收IP多协议子系统发送的第一呼叫请求消息之后，所述方法还包括：在确定不向所述IP多协议子系统发送试呼叫消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息；或者，在确定向所述IP多协议子系统发送所述试呼叫消息、且确定不向所述IP多协议子系统发送会话进行消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述会话进行消息用于表示正在处理一些操作以响应所述第一呼叫请求；或者，在确定向所述IP多协议子系统发送所述会话进行消息、且确定未接收到所述IP多协议子系统发送的临时应答消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述临时应答消息用于表示所述IP多协议子系统已接收到所述会话进行消息；或者，在确定接收到所述临时应答消息、且确定不向所述IP多协议子系统发送第一会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述第一会话成功消息用于表示所述IP多协议子系统与所述被叫终端关于所述第一临时应答消息的会话成功完成；或者，在确定向所述IP多协议子系统发送所述第一会话成功消息，且确定未接收到所述IP多协议子系统发送的资源预留更新通知消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述资源预留更新通知消息用于表示所述IP多协议子系统已预留好与所述被叫终端进行会话所需的语音业务数据相关的资源；或者，在确定接收到所述资源预留更新通知消息、且确定不向所述IP多协议子系统发送第二会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述第二会话成功消息用于指示所述IP多协议子系统与所述被叫终端关于所述资源预留更新通知消息的会话成功完成；或者，在确定向所述IP多协议子系统发送所述第二会话成功消息、且确定不向所述IP多协议子系统发送所述振铃消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息。

示例性的，被叫接通流程的信令交互为带资源预留的信令交互的情况下，该N的值为7，依次进行的7次信令交互包括上述试呼叫（100 trying）消息、会话进行（183 sessionprogress）消息、临时应答（PRACK）消息、第一会话成功（第一200 ok）消息、资源预留更新通知（update）消息、第二会话成功（第二200 ok）消息以及振铃（180 ringing）消息的信令交互。

在本申请实施例中，所述被叫终端依次判断该7次信令交互是否交互成功，在确定交互不成功的情况下，所述被叫终端确定是否接收到所述错误反馈信息。若确定任意一个信令交互失败，则不再判断下一个信令是否交互成功。由此，在帮助被叫用户避免错过重要来电的同时，减少被叫终端确认一通接通失败的未响铃来电所需的性能消耗（例如电量损耗和/或硬件执行损耗等）。

结合第一方面，在一种可能的实施方式中，在所述确定接收到所述主叫终端的第一来电呼叫之后，所述方法还包括：在确定第一时长内未向所述IP多协议子系统发送试呼叫消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息；或者，在确定所述第一时长内向所述IP多协议子系统发送了所述试呼叫消息、且确定第二时长内未向所述IP多协议子系统发送会话进行消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述会话进行消息用于表示正在处理一些操作以响应所述第一呼叫请求；或者，在确定所述第二时长内向所述IP多协议子系统发送了所述会话进行消息、且确定第三时长内未接收到所述IP多协议子系统发送的临时应答消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述临时应答消息用于表示所述IP多协议子系统已接收到所述会话进行消息；或者，在确定所述第三时长内接收到所述临时应答消息、且确定第四时长内未向所述IP多协议子系统发送第一会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述第一会话成功消息用于表示所述IP多协议子系统与所述被叫终端关于所述第一临时应答消息的会话成功完成；或者，在确定所述第四时长内向所述IP多协议子系统发送了所述第一会话成功消息、且确定第五时长内未向所述IP多协议子系统发送振铃消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述振铃消息用于表示所述被叫终端已开始响铃。

结合第一方面，在一种可能的实施方式中，在所述确定接收到所述主叫终端的第一来电呼叫之后，所述方法还包括：在确定第一时长内未向所述IP多协议子系统发送试呼叫消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息；或者，在确定所述第一时长内向所述IP多协议子系统发送了所述试呼叫消息、且确定第二时长内未向所述IP多协议子系统发送会话进行消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述会话进行消息用于表示正在处理一些操作以响应所述第一呼叫请求；或者，在确定所述第二时长内向所述IP多协议子系统发送了所述会话进行消息、且确定第三时长内未接收到所述IP多协议子系统发送的临时应答消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述临时应答消息用于表示所述IP多协议子系统已接收到所述会话进行消息；或者，在确定所述第三时长内接收到所述临时应答消息、且确定第四时长内未向所述IP多协议子系统发送第一会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述第一会话成功消息用于表示所述IP多协议子系统与所述被叫终端关于所述第一临时应答消息的会话成功完成；或者，所述被叫终端在确定所述第四时长内向所述IP多协议子系统发送了所述第一会话成功消息，且确定第六时长内未接收到所述IP多协议子系统发送的资源预留更新通知消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述资源预留更新通知消息用于表示所述IP多协议子系统已预留好与所述被叫终端进行会话所需的语音业务数据相关的资源；或者，所述被叫终端在确定所述第六时长内接收到所述资源预留更新通知消息、且确定第七时长内未向所述IP多协议子系统发送第二会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息，所述第二会话成功消息用于指示所述IP多协议子系统与所述被叫终端关于所述资源预留更新通知消息的会话成功完成；或者，所述被叫终端在确定所述第七时长内向所述IP多协议子系统发送了所述第二会话成功消息、且确定所述第八时长内未向所述IP多协议子系统发送所述振铃消息的情况下，所述被叫终端确定是否接收到所述错误反馈消息。

结合第一方面，在一种可能的实施方式中，所述方法还包括：将所述第一时长确定为第一最大时间差值，所述第一最大时间差值为两个或两个以上第一时间差值中的最大时间差值，所述第一时间差值为样本数据中被叫终端接收呼叫请求消息的接收时间与发送试呼叫消息的发送时间的时间差值；所述样本数据包括两个或两个以上目标信令交互的交互信息，所述目标信令交互为被叫终端与IP多协议子系统关于invite消息依次进行的N次被叫接通流程的信令交互的结果为交互成功的信令交互，所述交互信息包括信令发送或接收时间；将所述第二时长确定为第二最大时间差值，所述第二最大时间差值为两个或两个以上第二时间差值中的最大时间差值，所述第二最大时间差值为样本数据中被叫终端发送试呼叫消息的发送时间与发送会话进行消息的发送时间的时间差值；将所述第三时长确定为第三最大时间差值，所述第三最大时间差值为两个或两个以上第三时间差值中的最大时间差值，所述第三时间差值为样本数据中两个或两个以上被叫终端发送会话进行消息的发送时间与接收临时应答消息的接收时间的时间差值；将所述第四时长确定为第四最大时间差值，所述第四最大时间差值为两个或两个以上第四时间差值中的最大时间差值，所述第四时间差值为样本数据中被叫终端接收临时应答消息的接收时间与发送第一会话成功消息的发送时间的时间差值；将所述第五时长确定为第五最大时间差值，所述第五最大时间差值为两个或两个以上第五时间差值中的最大时间差值，所述第五时间差值为样本数据中被叫终端发送第一会话成功消息的发送时间与发送振铃消息的发送时间的时间差值；将所述第六时长确定为第六最大时间差值，所述第六最大时间差值为两个或两个以上第六时间差值中的最大时间差值，所述第六时间差值为样本数据中被叫终端发送第一会话成功消息的发送时间与接收资源预留更新通知消息的接收时间的时间差值；将所述第七时长确定为第七最大时间差值，所述第七最大时间差值为两个或两个以上第七时间差值中的最大时间差值，所述第七时间差值为样本数据中被叫终端接收资源预留更新通知消息的接收时间与发送第二会话成功消息的发送时间的时间差值；将所述第八时长确定为第八最大时间差值，所述第八最大时间差值为两个或两个以上第八时间差值中的最大时间差值，所述第八时间差值为样本数据中被叫终端发送第二会话成功消息的发送时间与发送振铃消息的发送时间的时间差值。

由此，根据被叫终端与IMS是否在相应的时长内完成相应的信令交互确定是否在180 ringing信令交互之前信令交互就已经交互失败。这样当信令交互失败出现在180ringing信令交互之前的信令交互中时，则立即确定此次来电在未响铃前接通失败；而不是直到预设时长内结束被叫终端与IMS都没有未完成180 ringing信令交互，或直到被叫终端接收到IMS发送的通话断开的失败信息，或直到被叫终端接收到IMS发送的SIP错误码的情况下，才会确定此次来电在未响铃前接通失败。在帮助被叫用户避免错过重要来电的同时，减少被叫终端确认一通接通失败的未响铃来电所需的性能消耗。

结合第一方面，在一种可能的实施方式中，所述方法还包括：在所述被叫终端未接收到所述错误反馈信息的情况下，所述被叫终端确定所述失败原因为未知的错误；所述被叫终端至少根据所述失败原因输出目标提示信息，具体包括：在所述被叫终端确定所述失败原因为未知的错误情况下，所述被叫终端输出第三提示信息，所述第三提示信息用于指示所述第一来电在响铃前由于未知的错误导致呼叫接通失败。

第二方面，本申请实施例提供一种电子设备，该电子设备包括：一个或多个处理器和存储器；该存储器与该一个或多个处理器耦合，该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令，该一个或多个处理器调用该计算机指令以使得该电子设备执行第一方面或第一方面的任意可能的实现方式中的方法。

第三方面，本申请实施例提供一种芯片系统，该芯片系统应用于电子设备，该芯片系统包括一个或多个处理器，该处理器用于调用计算机指令以使得该电子设备执行该第一方面或第一方面的任意可能的实现方式所示的方法。

第四方面，本申请实施例提供一种包含指令的计算机程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行该第一方面或第一方面的任意可能的实现方式所示的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，包括指令，其特征在于，当该指令在电子设备上运行时，使得该电子设备执行该第一方面或第一方面的任意可能的实现方式所示的方法。

可以理解的，上述第二方面提供的电子设备、第三方面提供的芯片系统、第四方面提供的计算机程序产品和第五方面提供的计算机存储介质均用于执行本申请实施例第一方面或第一方面的任一实现方式所示的方法。因此，其所能达到的有益效果可参考对应方法中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的本申请实施例提供的来电通知方法的场景示意图；

图2为本申请实施例提供的正常接通中被叫终端与IMS的信令交互流程示意图；

图3为本申请实施例提供的未响铃来电列表的用户界面示意图；

图4A-图4B为本申请实施例提供的未响铃来电详情页面的用户界面示意图；

图5为本申请实施例提供的一种显示未响铃来电提示内容的用户界面示意图；

图6为本申请实施例提供的又一种显示未响铃来电提示内容的用户界面示意图；

图7为本申请实施例提供的一种当未响铃来电的号码属于特殊类别号码列表时，不将该未响铃来电存储到未响铃来电通知列表中的示意图；

图8为本申请实施例提供的一种当未响铃来电的号码属于黑名单列表时，不将该未响铃来电存储到未响铃来电通知列表中的示意图；

图9为本申请实施例提供的一种当未响铃来电的号码属于白名单列表时，将该未响铃来电存储到未响铃来电通知列表中的示意图；

图10为本申请实施例提供的一种来电通知方法的流程示意图；

图11为本申请实施例提供的一种带资源预留的信令交互的来电通知方法的流程示意图；

图12为本申请实施例提供的一种分析未响铃来电接通失败的失败原因的方法流程示意图；

图13为本申请实施例提供的另一种分析未响铃来电接通失败的失败原因的方法流程示意图；

图14为本申请实施例提供的一种根据主叫终端的电话号码的类型对未响铃来电通知的做进一步管控处理的方法流程示意图；

图15为本申请实施例提供的又一种根据主叫终端的电话号码的类型对未响铃来电通知的做进一步管控处理的方法流程示意图；

图16为本申请实施例提供的又一种根据主叫终端的电话号码的类型对未响铃来电通知的做进一步管控处理的方法流程示意图；

图17为本申请实施例提供的又一种来电通知方法的流程示意图；

图18为本申请实施例提供的终端200的硬件结构示意图；

图19为本申请实施例的终端200的软件结构框图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地描述。

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

在本文中提及的“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

在本申请中，“至少一个（项）”是指一个或者多个，“多个”是指两个或两个以上，“至少两个（项）”是指两个或三个及三个以上，“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合。例如，a，b或c中的至少一项（个），可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”。

在本申请实施例中，IP多媒体子系统（IP Multimedia Subsystem，IMS）可以是多个具有处理语音及多媒体业务的设备的集合，也可以理解为是多个具有处理语音及多媒体业务的服务器的集合。IMS中可以包括一个或一个以上核心网设备，该核心网设备可以是长期演进（long Term Evolution，LTE）系统中的代理呼叫会话控制功能（Proxy-CallSession Control Function，P-CSCF），还可以是UMTS系统中的服务GPRS支持节点（ServingGPRS Support Node，SGSN）、移动交换中心（MobileSwitching Center，简称MSC）。可理解的，本文所描述的IP是指网际互连协议（Internet Protocol），本文中关于IP的描述均与此相同。

可理解的，本申请实施例提供的来电通知方法可以适用于采用IMS处理语音及多媒体业务的所有场景。示例性的，可以适用于4G通话（Voice over Long-Term Evolution，VoLTE），也可以适用于5G通话（Vonr over NR，VoNR）。

在本申请实施例中，被叫终端可以是任意具备通话功能的电子设备；示例性的，被叫终端可以是移动终端或平板电脑。可理解的，主叫终端可以是任意具备通话功能的电子设备，主叫终端与被叫终端的概念一致，关于主叫终端的具体的概念描述请参照对于被叫终端的相关描述，不再详述。

示例性的，本申请实施例提供的来电通知方法可以用于如图1所示的主叫终端通过IMS呼叫被叫终端的场景中。具体的，主叫终端向IMS发起呼叫请求信令，该呼叫请求信令中包含主叫终端的电话号码和被叫终端的电话号码。IMS接收到该呼叫请求信令后再根据被叫终端的电话号码找到对应的被叫终端，并将呼叫请求信令发送给被叫终端，可理解的，发送给被叫终端的呼叫请求信令包括主叫终端的电话号码，但可以不包括被叫终端的电话号码。被叫终端接收到该呼叫请求信令后，向IMS发送请求响应消息，该请求响应消息用于表征被叫终端已收到主叫终端经IMS发送的呼叫请求消息。为便于理解，下文将对IMS与被叫终端的数据交互流程展开详细描述。

需要说明的是，被叫终端与IMS所进行的关于呼叫接通流程（也可以理解为被叫接通流程）的信令交互可以分为：不带资源预留(precondition)的信令交互、带资源预留的信令交互，具体使用哪种信令交互与被叫终端和IMS是否支持资源预留有关。

可理解的，主叫终端与IMS或IMS与被叫终端之间的通信可能会经过其他网络，例如基站（图1相应地在主叫终端与IMS或IMS与被叫终端之间的通信中示出了基站图标），这里不做详述。在本申请实施例中，IMS与被叫终端以及IMS与主叫终端之间通信的协议包括会话初始协议（Session initialization Protocol，SIP）。可理解的，一个通话过程，两端要传递多种信令，在SIP协议中，这些信令是一种约定格式的IP数据包，称为SIP消息，也就是说，通话过程中有多种SIP消息，每一种消息都是一个IP数据包。本文涉及的一些SIP消息，以及其表征意义如下：

（1）invite消息：invite消息为SIP请求消息，用于表示主叫用户发起呼叫请求，邀请其他用户加入一个会话；该invite消息也可以理解为呼叫请求消息。

（2）100 trying消息：100 trying消息为临时响应消息（临时响应消息用于表示请求已经被接受，但需要继续处理），用于响应invite消息，表示做出100 trying响应的一端已接收到invite消息，正在处理一些操作以完成此次请求；该100 trying消息也可以理解为100试呼叫消息或试呼叫消息。

（3）183 session progress消息：183 session progress消息为临时响应消息，表示正在处理一些操作以完成invite请求；该183 session progress消息也可以理解为会话进行消息。

（4）PRACK消息：PRACK消息是请求消息，表示发送PRACK的一端请求另一端对本次临时响应消息做确认完成的响应消息。PRACK消息也可以理解为对临时响应消息的应答消息，表示对1xx（x为自然数）临时响应消息的确认消息，也即发送PRACK的一端已接收到临时响应消息。

（5）update消息：update消息为请求消息，update消息用于表示发送update的一端已准备好与另一端进行会话所需要的音视频端口、编码格式等资源，也可以理解为发送update的一端在准备好会话资源后通知另一端本端已做好会话准备，并请求另一端针对该update消息做出响应。

（6）200 ok消息：200 ok消息是确认完成的响应消息，例如用于响应PRACK消息和update消息；当200 ok消息用于响应PRACK消息时，该200 ok用于对本次临时响应消息做确认完成的响应消息；当200 ok消息用于响应update消息时，该200 ok消息用于表示发送200ok消息的一端也已准备好与另一端进行会话所需要的音视频端口、编码格式等资源，也就是说，即将建立会话的两端都已准备好会话资源。

（7）180 ringing消息：180 ringing消息是响应消息，用于向主叫终端指示被叫终端已开始振铃。

为了便于对本申请实施例的理解，下面以带资源预留的信令交互为例，结合图2对正常接通中被叫终端与IMS的信令交互流程进行介绍（也可以理解为被叫接通流程的信令交互成功的流程）。

如图2所示，正常接通中被叫终端与IMS的信令交互可以包括：

S201，IMS向被叫终端发送invite（呼叫请求）消息，相应的，被叫终端接收该invite消息。

上述invite消息可以为主叫终端通过IMS转发给被叫终端的invite消息。其中，该invite消息中携带有主叫终端的电话号码，可选的，该invite消息还可以包括主叫终端发起呼叫的时间等。在一些描述中，该invite消息也可以称为会话请求消息。

S202，被叫终端向IMS发送100 trying（100试呼叫）消息，相应的，IMS接收该响应消息100 trying消息。

在本申请实施例中，被叫终端接收到IMS发送的invite消息后，会回复100 trying消息做出临时响应，该100 trying消息用于向IMS指示被叫终端已接收到IMS发送的invite消息。

S203，被叫终端向IMS发送183 session progress（会话进行）消息，相应的，IMS接收该183 session progress消息。

在SIP协议中，若上述183 session progress消息中包括sdp的消息内容字段（例如content-type：application/sdp字段），则该183 session progress消息中包括会话描述协议（Session Description Protocol，SDP）消息，该SDP消息中包括被叫终端支持的音视频端口、编码格式。该183 session progress消息中携带SDP消息可以用于向IMS指示被叫终端支持的音视频端口、编码格式以及向IMS指示为被叫终端预留传输语音业务数据的资源。

S204，IMS向被叫终端发送PRACK（临时应答）消息，相应的，被叫终端接收该PRACK消息。

在本申请实施例中，IMS接收到被叫终端发送的183 session progress消息后，会回复PRACK消息做出响应，该PRACK消息用于向被叫终端指示IMS已接收到被叫终端发送的183 session progress消息。

S205，被叫终端向IMS发送200 ok（会话成功）消息，相应的，IMS接收该200 ok消息。

在本申请实施例中，被叫终端接收到IMS发送的PRACK消息后，会回复200 ok消息做出响应，该200 ok消息用于向IMS指示被叫终端已接收到IMS发送的PRACK消息。

S206，IMS向被叫终端发送update（资源预留更新通知）消息，相应的，被叫终端接收该update消息。

在本申请实施例中，当IMS接收到主叫终端发送的资源预留成功的消息后，会向被叫终端发送update消息，该update消息用于向被叫终端指示主叫终端的资源预留已完成。另外，需要说明的是，上述IMS根据上述183 session progress消息为被叫终端预留的资源可以通过其他的消息通知给被叫终端，例如：非接入层消息。

S207，被叫终端向IMS发送200 ok（更新状态确认）消息，相应的，IMS接收该200 ok消息。

在本申请实施例中，被叫终端接收到IMS发送的update消息后，会回复200 ok消息做出响应，该200 ok消息用于向IMS指示被叫终端已接收到IMS发送的update消息，且被叫终端也已完成资源预留任务。

可理解的，SIP消息中包括命令序列号（Command Sequence Number，CSeq）字段，该CSeq字段用于标识事务并对事务排序的，可理解的，事务是指一个请求消息（例如invite请求消息、PRACK请求消息或update）以及这个请求消息对应的所有响应消息的集合，该CSeq字段也可以用于表征该SIP消息与其他SIP消息的关联关系。该CSeq包括一个序列号和信令名称，序列号的值可以是一个任意的32位无符号整数，序列号的值按照规则严格单向按1递增。

示例性的，上述步骤S201中的invite消息中包含的命令序列号为“1 invite”，则上述步骤S202中的100 trying消息和步骤S203中的183 session progress消息中包含的命令序列号均为“1 invite”，用于表征该100 trying消息和该183 session progress消息是针对该invite消息的响应消息。上述步骤S204中的PRACK消息中包含的命令序列号为“2PRACK”，则S205中的200 ok消息中包含的命令序列号也为“2 PRACK”，用于表征该200 ok消息是针对该PRACK消息的确认完成消息。

在SIP协议中，若上述步骤S203中的183 session progress消息中包括资源预留字段（例如require：100rel，precondition字段），则被叫终端与IMS所进行的关于被叫接通流程的信令交互为带资源预留的信令交互。具体体现为，带资源预留的信令交互中包括上述步骤S206和步骤S207。不带资源预留的信令交互中不包括上述步骤S206和步骤S207。

S208，被叫终端向IMS发送180 ringing（振铃）消息，相应的，IMS接收该180ringing消息。

在本申请实施例中，被叫终端做好会话准备后准备开始振铃时，向IMS发送180ringing消息，从而经由IMS向主叫终端指示被叫终端已做好会话准备正在振铃，等待被叫用户接听。

至此被叫终端与IMS就完成了带资源预留的信令交互流程。也即，主叫终端已成功接通了被叫终端，等待被叫终端接听后，主叫用户与被叫用户即可通过主叫终端和被叫终端进行通话。

结合上述图2的相关描述和其他来电通知的方法的实现方式，对比说明本申请实施例提供的来电通知方法的优势。

复用上述图2，在图2的信令交互流程中，只有在执行完最后一个步骤（即图2的S208），也即被叫终端向核心网发送了180 ringing，被叫终端与IMS所进行的关于被叫接通流程的信令交互才算成功，这样，被叫终端才会响铃，被叫用户才会通过被叫终端的响铃感知到主叫终端的此次来电。若被叫终端与IMS所进行的关于被叫接通流程的信令交互失败，则被叫终端不会向IMS发送180 ringing，被叫终端不会响铃，使得被叫用户无法通过被叫终端感知到主叫终端的此次来电，可能导致被叫用户错过重要来电。

亦或者，被叫终端在确定被叫终端与IMS所进行的关于被叫接通流程的信令交互失败后，输出提示信息，以向被叫用户指示主叫终端的此次来电在被叫终端振铃前接通失败。然而，可能是主叫用户使用主叫终端时不小心拨错了电话号码或者不小心点错了拨号功能，接着主叫用户在接通响铃前匆忙将电话挂断而导致被叫终端与IMS的关于被叫接通流程的信令交互失败，被叫终端未响铃。这时，被叫终端输出主叫终端此次来电在响铃前异常挂断的提示信息，被叫用户查看到该提示信息后不知道是什么原因导致来电在响铃前异常挂断，会误以为是重要客户的来电。这时被叫用户会再次给主叫终端拨号，并询问之前的来电在响铃前异常挂断的原因，才可得知并没有重要事情，而是不小心拨错，由此，导致为主叫终端和被叫终端带来了不必要的性能损耗，以及浪费主叫用户和被叫用户的时间和精力。

然而，采用本申请实施例提供的来电通知方法，当被叫终端确定被叫接通流程的信令交互失败后，根据IMS发送的错误反馈信息，进行错误检查，进一步剖析呼叫接通失败的失败原因。例如SIP错误码或会话取消消息（cancel消息），确定失败原因是主叫用户主动挂断还是网络异常；若失败原因为主叫用户主动挂断，则被叫终端输出的提示信息用于表示由于主叫用户主动挂断导致通话在未响铃前异常结束，若失败原因为网络异常，则被叫终端输出的提示信息用于表示由于网络异常导致通话异常结束。在一些表述中，会话取消消息也可以称为取消会话消息。

也即基于错误检查，进一步剖析呼叫接通失败的失败原因，向被叫用户提示来电在未响铃前结束的失败原因。从而被叫用户可以通过查看提示信息得到来电在未响铃前结束的失败原因，被叫用户可以根据失败原因确定是否需要回拨主叫终端。例如，当来电是主叫用户主动挂断、被叫用户不认识的主叫终端的电话号码或被叫用户很忙没有时间处理这通来电时，被叫用户在得知失败原因为主叫用户主动挂断的情况下就可以不回拨这通电话；或者，被叫用户当前有空余的时间处理这通来电时，被叫用户可以选择回拨以免错过重要来电。

由此，在帮助被叫用户避免错过重要来电的同时，还可以基于错误检查向用户提供不同的提示信息，满足用户需求，帮助用户减少工作量，以及减少终端不必要的性能损耗。

在一种实现方式中，在确定被叫终端与IMS所进行的关于被叫接通流程的信令交互中，确定预设时长内被叫终端是否向IMS发送上述180 ringing振铃消息，若是则信令交互成功；若否则信令交互失败，输出提示信息以向被叫用户指示主叫终端的此次来电在主叫终端振铃前接通失败。

采用本申请实施例提供的另外一种来电通知方法，确定被叫终端与IMS是否在相应的时长内完成相应的信令交互，若否则立即确定呼叫接通失败。示例性的，确定被叫终端是否在a时长内向IMS发送100 trying消息，若否则立即确定此次来电在未响铃前接通失败，被叫终端侧输出提示信息；若是则确定是否在下一个对应的时长内完成对应的信令交互，可理解的，100 trying消息之后的信令交互即为183 session progress消息的信令交互，例如确定b时长内被叫终端是否向IMS发送183 session progress消息，若否则立即确定此次来电在未响铃前接通失败，以此类推。上述a时长或b时长的具体取值可以为，呼叫正常接通正常响铃流程的样本中（例如200个呼叫正常接通流程的信令交互中）对应的每两个信令交互之间相隔时长的最大值，例如，该a时长即为200个呼叫正常接通的样本流程中，被叫终端接收到IMS发送的invite信令接收时刻到被叫终端向IMS发送100 trying信令的发送时刻相隔的时长中的最大值；该b时长即为200个呼叫正常接通的样本流程中，被叫终端向IMS发送100 trying信令的发送时刻到被叫终端接收到IMS发送的183 sessionprogress消息的接收时刻相隔的时长中的最大值。

也就是说，可以根据被叫终端与IMS是否在相应的时长内完成相应的信令交互确定是否在180 ringing信令交互之前信令交互就已经交互失败。这样当信令交互失败出现在180 ringing信令交互之前的信令交互中时，则立即确定此次来电在未响铃前接通失败，而当信令交互失败出现在180 ringing信令交互之前的信令交互中时，仍然一直等待预设时长结束后，才能确定此次来电在未响铃前接通失败。示例性的，信令交互在100 trying处出现信令交互失败，采用本申请实施例提供的来电通知方法，当确定在a时长（例如a时长为100ms）内终端与IMS未完成100 trying的信令交互，则确定此次来电在未响铃前接通失败。而不是，直到预设时长内（例如1s内）结束被叫终端与IMS都没有未完成180 ringing信令交互，或直到被叫终端接收到IMS发送的通话断开的失败信息，或直到被叫终端接收到IMS发送的SIP错误码的情况下，才会确定此次来电在未响铃前接通失败。

由此，在帮助被叫用户避免错过重要来电的同时，减少被叫终端确认一通接通失败的未响铃来电所需的性能消耗（例如电量损耗和/或硬件执行损耗等）。

下面介绍本申请实施例提供的用户界面。

可理解的，本申请实施例提供的方法可以由任意具备通话功能的被叫终端执行。示例性的，该被叫终端包括移动终端或平板电脑等。为便于描述，以移动终端作为该被叫终端的一个示例，介绍本申请实施例提供的用户界面。

示例性的，如图3所示，在被叫终端中通话应用（application，app）的首页中新增用于展示响铃前异常挂断的来电信息的显示界面。该显示界面中包括“未响铃来电”列表的分组（在图3中以标号301示出），该“未响铃来电”列表中包括未响铃来电的主叫终端的电话号码，呼叫时间以及来电详情查看入口302（在图3中有指示该来电详情查看入口302即为图3中所示的圆圈内加感叹号的图标，也可以理解为按钮）。可理解的，实际应用中，该“未响铃来电”列表的名称也可以为其他名称，“未响铃来电”列表中包含的内容也可以比未响铃来电的电话号码，呼叫时间以及来电详情查看入口302更多或更少的数据内容，本文对此不做限定。

示例性的，当用户点击了来电详情查看入口302，则显示如图4A所示的来电详情界面，该来电详情界面中包括未响铃来电的电话号码、来电日期和钟点时间、拨号功能键以及短信功能键等。在本申请实施例中，该来电详情界面还包括来电的未响铃前结束的原因401的数据内容。例如，若通话在未响铃前结束的原因为主叫用户主动挂断，则在如图4A所示的该未响铃前结束的原因401处显示“响铃前因对方挂断而终止”。或者，若通话在未响铃前结束的原因为网络异常，则如图4B所示，在该未响铃前结束的原因401处显示“响铃前因网络异常而终止”。可理解的，“响铃前因对方挂断而终止”和/或“响铃前因网络异常而终止”的显示内容仅为示例，还可以为其他合适的提示内容（例如“响铃前因主叫用户主动挂断而导致通话流程未走到响铃步骤”），本文对此不做限定。

可理解的，实际应用中，来电详情界面中可以包括比未响铃来电的电话号码、来电日期和钟点时间、拨号功能键、短信功能键以及未响铃前结束的原因401更多或更少的数据内容，本文对此不做限定。可理解的，在被叫终端中的通话app的首页新增未响铃来电信息的显示界面仅为示例，还可以在通话app中的其他功能页面新增未响铃来电信息的显示界面，本文对此不做限定。

在本申请实施例中，还可以在被叫终端中设置当接收到未响铃来电时，若被叫终端处于锁屏状态，在锁屏界面中显示对应的提示内容。示例性的，如图5所示，在被叫终端屏幕的上方弹出“您11月29日14时12分有一通来电号码为139xxxxxx85的来电在响铃前因网络异常原因而终止，如有需要，请回拨”的提示内容。可理解的，根据需求也可以设置为在被叫终端屏幕的任意位置显示该提示内容，提示内容可以以弹框的方式或弹幕等方式呈现，本文对此不做限定。

示例性的，如图6所示，也可以将未响铃来电的提示信息显示在下拉栏中，显示内容可以包括但不限于未响铃来电的电话号码、来电日期和钟点时间以及未响铃前结束的原因。可理解的，还可以基于本申请实施例提供的方法设置其他的用户界面，本文对此不做限定

由此，被叫终端基于错误检查向用户提供未响铃来电以及来电在未响铃前异常结束的原因，以便于用户根据该异常原因确定是否需要回拨主叫终端，从而帮助用户减少工作量，同时避免用户错过重要来电。

在本申请实施例中，还可以为用户提供特殊类别号码（例如骚扰电话等）标记功能、黑名单功能以及白名单功能。对于未响铃来电增加根据主叫终端的电话号码的类型做进一步的未响铃来电通知的管控处理，根据主叫终端的电话号码的类型，确定是否需要分析未响铃来电接通失败的失败原因或者已得到失败原因是否需要通过被叫终端输出提示内容以向被叫用户指示关于该主叫终端的电话号码的未响铃来电的提示内容的管控。例如根据主叫终端的电话号码是否属于特殊类别电话、是否属于被叫终端设置的响铃前来电提醒的黑名单列表或白名单列表，确定是否需要分析该失败原因或者已得到该失败原因是否需要通过被叫终端输出提示内容。

示例性的，如图7所示，当未响铃来电173xxxxxx65属于特殊类别号码列表时，则不将173xxxxxx65号码的未响铃来电存储到未响铃来电通知列表中，以及不输出相应的提示信息。

示例性的，如图8所示，当未响铃来电173xxxxxx65属于黑名单列表时，则不将173xxxxxx65号码的未响铃来电存储到未响铃来电通知列表中，以及不输出相应的提示信息。

示例性的，如图9所示，当未响铃来电173xxxxxx65属于白名单列表时，则将173xxxxxx65号码的未响铃来电存储到未响铃来电通知列表中，以及输出相应的提示信息。

可理解的，在一些实现方式中，对于属于特殊类别号码或黑名单列表的号码的未响铃来电，也可以存储到未响铃来电通知列表中，但是不直接输出相应的提示信息，本文对此不做限定。

实施例1：

以下结合上述图1-图6的相关描述以及如图10所示的方法流程图，详细介绍本申请实施例提供的来电通知方法。

可理解的，可以由被叫终端执行本申请实施例的来电通知方法，也可以由该被叫终端中的来电通知模块执行本申请实施例的来电通知方法。其中，该来电通知模块可以为该被叫终端中的硬件部件。例如，该来电通知模块可以为该被叫终端中用于执行本申请提供的来电通知方法的芯片。或者，该来电通知模块也可以为该被叫终端中已有的硬件部件提供的可以执行本申请提供的来电通知方法的软件功能模块。示例性的，该来电通知模块为一个应用程序。本申请实施例对于该来电通知模块的具体形态不作限定。

以下为便于描述，如图10所示的来电通知方法省略了执行本申请实施例提供的方法的执行主体。具体的，执行本申请实施例提供的方法的执行主体可以为被叫终端也可以为上述来电通知模块。

如图10所示，先以被叫终端与IMS关于被叫接通流程的信令交互为不带资源预留的信令交互为例说明本申请实施例提供的来电通知方法，该来电通知方法包括以下步骤：

S1001，接收IMS发送的第一invite消息。

在本申请实施例中，第一invite消息可以为主叫终端通过IMS转发给被叫终端的invite消息，该第一invite消息中包括主叫终端的电话号码以及主叫终端发起呼叫的呼叫时间。可理解的，该第一invite消息中还可以包括此次会话的呼叫标识（call-ID）（该call-ID用于唯一标识该第一invite消息）、会话类型、传输类型以及CSeq字段等其他信息，具体包括何种信息根据SIP协议而定，本文对此不做限定。

S1002，确定被叫终端是否向IMS发送100 trying消息。

关于100 trying消息的具体说明请参照上文（例如上述图2步骤S202）相关描述，在此不再详述。

在SIP协议中，正常情况下，被叫终端与IMS进行的关于上述第一invite请求的被叫接通流程的信令交互中（以下为便于描述将被叫终端与IMS进行的关于第一invite请求的被叫接通流程的信令交互称为第一信令交互），当被叫终端成功接收到该第一invite请求后，被叫终端会向IMS发送100 trying消息。则可理解的，在被叫终端到上述第一invite消息后，确定被叫终端是否向IMS发送100 trying消息；若确定被叫终端向IMS发送100trying消息，则表示该第一信令交互仍在正常进行；若被叫终端未向IMS发送100 trying消息，则表示该第一信令交互出现异常。例如，由于网络异常或主叫用户主动挂断，导致本次会话关闭，此时被叫终端即使接收到该第一invite消息也无需向IMS发送该100 trying消息。

在确定被叫终端不向IMS发送100 trying消息的情况下，执行步骤S1003。在确定被叫终端向IMS发送100 trying消息的情况下，执行步骤S1008。

S1003，确定被叫终端是否接收到IMS发送的错误反馈信息。

在本申请实施例中，该错误反馈信息为可解析的错误信息，示例性的该错误反馈信息可以为SIP错误码或带reason头域的会话取消消息（cancel消息）。可理解的，cancel消息可以携带用于标识和解释cancel消息错误原因的reason头域，也可以不携带reason头域。例如Reason：SIP；cause=486；text=“Busy Here”为携带reason头域的形式，对于携带reason头域的cancel，则可以根据该reason头域确定该cancel消息是否为用于表示主叫用户主动挂断的错误原因或用于表示网络异常的错误原因。

其中，上述SIP错误码中包括预设的用于表示由于主叫用户主动挂断导致呼叫接通失败（也可以理解上述第一信令交互失败）的SIP错误码和预设的用于表示由于网络异常导致呼叫接通失败的SIP错误码。该cancel消息中包括预设的用于表示由于主叫用户主动挂断导致呼叫接通失败（也可以理解上述第一信令交互失败）的cancel消息和预设的用于表示由于网络异常导致呼叫接通失败的cancel消息。在一些表述中，上述预设的用于表示由于主叫用户主动挂断导致呼叫接通失败的SIP错误码也可以称为第一类型SIP错误码，上述预设的用于表示由于网络异常导致呼叫接通失败的SIP错误码也可以称为第二类型SIP错误码，上述预设的用于表示由于主叫用户主动挂断导致呼叫接通失败的cancel消息也可以称为第一类型会话取消消息（也即第一类型cancel消息），上述预设的用于表示由于网络异常导致呼叫接通失败的cancel消息也可以称为第二类型会话取消消息（也即第二类型cancel消息）。

示例性的，根据SIP协议中的请求评论（Request For Comments ，RFC）3261协议，SIP错误码包括客户端错误（client-error）码（具体为4xx错误码，x为自然数）、服务端（该服务端可以理解为IMS）错误（server-error）码（具体为5xx错误码，x为自然数）以及全局错误（global-failure）码（具体为6xx错误码，x为自然数）。

示例性的，如下表1所示，client-error码中的cause值为486的错误码（例如486错误码具体为cause=486；text=“Busy Here”），以及，global-failure码中的cause值为600错误码（例如600错误码具体为cause=600；text=“Busy Everywhere”）和cause值为603错误码（例如603错误码具体为cause=603 ；text=“Decline”）用于表示呼叫接通失败的失败原因为主叫用户主动挂断。上述cause值可以理解为原因值标号，上述text可以理解原因值说明。

可理解的，还可以有除了上述486错误码、600错误码以及603错误码之外的其他SIP错误码，用于表示呼叫接通失败的失败原因为主叫用户主动挂断，本文对此不做限定。在本申请实施例中，SIP错误码中的其他错误码（也即除了上述用于表示呼叫接通失败的失败原因为主叫用户主动挂断的错误码之外的其他错误码）用于表示呼叫接通失败的失败原因为网络异常，该网络异常可以是被叫终端侧网络异常，也可以是IMS侧网络异常，还可以是主叫终端侧网络异常，本文对此不做限定。

示例性的，用于表示网络异常的SIP错误码可以包括400-Bad Request（为便于描述以下以cause值-text值的方式表示一个SIP错误码）、401-Unauthorized、402-PaymentRequired、403- Forbidden、404-Not Found、405-Method Not Allowed、406-NotAcceptable、407-Proxy Authentication Required、408-Request Timeout、410-Gone、413-Request Entity Too Large、414- Request-URI Too Large、415-Unsupported MediaType、416-Unsupported URI Scheme、420-Bad Extension、421-Extension Required、423-Interval Too Brief、480-Temporarily not available、481- Call Leg/TransactionDoes Not Exist、482-Loop Detected、483-Too Many Hops、484-Address Incomplete、485- Ambiguous、487-Request Terminated、488-Not Acceptable Here、491-RequestPending、493-Undecipherable、500-Internal Server Error、501-Not Implemented、502-Bad Gateway、503-Service Unavailable、504-Server Time-out、505-SIP Version notsupported、513-Message Too Large、604-Does not exist anywhere以及606-NotAcceptable中的一项或多项。

表1

在本申请实施例中，上述cancel消息可以为SIP 错误码、Q.850错误原因信息（Q.850 cause）以及释放原因信息（RELEASE_CAUSE）。可理解的，IMS给被叫终端发送的错误反馈信息，可能是单独的SIP错误码，可能是不携带SIP错误码的cancel消息，也可能是携带SIP错误码的cancel消息。

根据SIP协议，cancel消息的数据内容可以包括用于指示cancel消息类型的reason属性值。示例性的，cancel消息的数据内容包括的reason属性的值为“Reason：SIP”，则表示该cancel消息的类型为SIP错误码。该reason属性的值为“Reason：RELEASE_CAUSE”，则表示该cancel消息的类型为上述RELEASE_CAUSE，该reason属性的值为“Reason：Q.850Cause”，则表示该cancel消息的类型为上述Q.850 Cause。

示例性的，cancel消息可以携带SIP错误码的字段。例如，cancel消息中携带的SIP错误码的信息为Reason：SIP；cause=486；text=“Busy Here”。该SIP错误码中的486、600以及603错误码用于表示呼叫接通失败的失败原因为主叫用户主动挂断。关于SIP错误码的概念与上述表1中对应的相关说明一致，在此不再赘述。

示例性的，如下表2所示，根据SIP协议中的Q.850协议，上述Q.850 cause中的cause值为17的原因值（例如具体为cancel消息：reason：Q.850 Cause；Cause:17；text：“user busy”）用于表示呼叫接通失败的失败原因为用户主动挂断。根据3GPP 24.229协议，RELEASE_CAUSE的中的cause值为1的原因值（具体为cancel消息：reason：RELEASE_CAUSE；cause=1；text=“User ends call”）用于表示呼叫接通失败的失败原因为用户主动挂断。可理解的，关于cause值与text值的具体取值（例如486、600、603、17、1）依据通信标准或IMS的关于原因值的定义的变化而变化，在此不做限定。

可理解的，还可以有除了上述cause值为17的消息和cause为1的消息之外的其他cancel消息，用于表示呼叫接通失败的失败原因为主叫用户主动挂断，本文对此不做限定。在本申请实施例中，cancel消息中的其他消息（也即除了上述用于表示呼叫接通失败的失败原因为主叫用户主动挂断的cancel消息之外的其他错误码）用于表示呼叫接通失败的失败原因为网络异常，该网络异常可以是被叫终端侧网络异常，也可以是IMS侧网络异常，还可以是主叫终端侧网络异常，本文对此不做限定。

示例性的，用于表示网络异常的cancel消息可以包括Q850 Cause: Unallocatednumber（为便于描述以下以cancel消息类型：text值表示一个Q850 Cause消息）、Q850Cause: No route to specified transit network、Q850 Cause: No route todestination、Q850 Cause: send special information tone、Q850 Cause: misdialedtrunk prefix、cause=3;text="Media bearer loss"以及cause=4;text="SIP timeout -no ACK"等中的一项或多项cancel消息。

表2

reason（cancel消息类型）	cause值	text值
			Q.850 Cause	17	user busy
RELEASE_CAUSE	1	user ends call

一般地，可以采用cause值唯一标识一个SIP消息或一个cancel消息，也可以由cause值和text值唯一标识一个SIP消息或一个cancel消息，还可以由cause值、text值以及reason值唯一标识一个cancel消息，本文对此不做限定。为便于描述，本文主要以采用cause值唯一标识一个SIP消息或一个cancel消息为例确定错误反馈信息是否为用户主动挂断的失败原因。也可以理解为为便于描述，本文采用cause值指代一个SIP消息或一个cancel消息，例如采用cause值486指代上述cause=486；text=“Busy Here”SIP错误码；采用cause值1指代上述Reason：RELEASE_CAUSE；cause=1；text=“User ends call”cancel消息。

在确定被叫终端接收到IMS发送的错误反馈信息的情况下，执行步骤S1004。在确定被叫终端未接收到IMS发送的错误反馈信息的情况下，执行步骤S1007。

S1004，根据该错误反馈信息确定导致呼叫接通失败的失败原因是否为主叫用户主动挂断。

可选的，当采用cause值唯一标识一个原因值时，可以直接采用错误反馈信息中的cause值确定导致呼叫接通失败（也可以理解为通话在未响铃前异常结束）的失败原因是否为主叫用户主动挂断。例如，若cause值包括486、600、603、1以及17中的一项或多项的情况下，则确定导致呼叫接通失败的失败原因为主叫用户主动挂断。

可选的，当采用cause值唯一标识一个原因值时，也可以先确定错误反馈信息为SIP错误码还是cancel消息，在确定上述错误反馈信息为上述SIP错误码的情况下，若该SIP错误码中的cause值包括上述486、600、以及603中的一项或多项cause值的情况下，则确定导致呼叫接通失败的失败原因是否为主叫用户主动挂断。在确定上述错误反馈信息为上述cancel消息的情况下，若该cancel消息中的cause值包括上述17或1的cause值的情况下，则确定导致呼叫接通失败的失败原因为主叫用户主动挂断。

可选的，当采用cause值和text值唯一标识一个原因值时，可以直接采用错误反馈信息中的cause值确定导致呼叫接通失败的失败原因是否为主叫用户主动挂断，也可以先确定错误反馈信息为SIP错误码还是cancel消息，若是SIP错误码再判断该SIP错误码是否为SIP错误码中用于表示失败原因是否为主叫用户主动挂断的SIP错误码，若是cancel消息在判断该cancel消息是否为cancel消息中用于表示失败原因是否为主叫用户主动挂断的SIP错误码。

可选的，当采用cause值、text值以及reason值唯一标识一个cancel值且采用cause值和text值唯一标识一个SIP错误码时，可以先确定错误反馈信息为SIP错误码还是cancel消息；在确定上述错误反馈信息为上述SIP错误码的情况下，若该SIP错误码中包括上述cause=486；text=“Busy Here”、cause=600；text=“Busy Everywhere”以及cause=603；text=“Decline”中的一项或多项的情况下，则确定导致呼叫接通失败的失败原因是否为主叫用户主动挂断。在确定上述错误反馈信息为上述cancel消息的情况下，若该cancel消息为上述reason：RELEASE_CAUSE；cause=1；text=“User ends call”或为上述reason：Q850；Cause:17；text：“user busy”的cancel消息的情况下，则确定导致呼叫接通失败的失败原因为主叫用户主动挂断。

示例性的，在上述错误反馈信息为预设的用于表示由于主叫用户主动挂断导致呼叫接通失败的错误反馈信息的情况下，上述关于第一invite消息呼叫接通失败的原因为主叫用户主动挂断。在上述错误反馈信息为预设的用于表示由于网络异常导致呼叫接通失败的错误反馈信息的情况下，上述关于第一invite消息呼叫接通失败的原因为网络异常。在一些表述中，上述用于表示由于主叫用户主动挂断导致呼叫接通失败的错误反馈信息也可以统称为第一类型错误码，上述用于表示由于网络异常导致呼叫接通失败的错误反馈信息也可以称为第二类型错误码。

在确定导致呼叫接通失败的失败原因为主叫用户主动挂断的情况下，执行步骤S1005。在确定导致呼叫接通失败的失败原因不为主叫用户主动挂断的情况下，执行步骤S1006。

S1005，确定呼叫异常的原因为主叫用户主动挂断，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第一提示内容。

在本申请实施例中，在确定呼叫异常的原因为主叫用户主动挂断的情况下，可以将该第一invite消息中包含的主叫终端的电话号码存储到数据库表A中，该数据库表A用于存储未响铃来电的信息。可选的，还可以将该第一invite消息中包含的其他数据内容（例如call-ID、会话类型以及呼叫时间等中的一项或多项）存储到数据库表A中，本文对此不做限定。示例性的，数据库表A中存储了该第一invite消息中的主叫终端的电话号码和呼叫时间（包括日期和时钟时间）。在本文中，关于“一项或多项”的描述是指一项或一项以上，也即“多项”是指一项以上，本文关于“一项或多项”的说明均与此一致。

示例性的，如下表3所示，该数据库表A中存储的数据内容包括未响铃来电的来电号码、呼叫时间以及未响铃原因（也即失败原因）。例如，上述第一invite消息中包括的未响铃来电的电话号码为157xxxxxx55，呼叫时间为“2021/11/2914:12”，未响铃原因为主叫用户主动挂断。则在确定导致该第一invite消息的呼叫接通失败的失败原因为主叫用户主动挂断的情况下，在数据库表A中存储相应的数据内容。可理解的，关于表3中的未响铃原因列中的值可以为网络异常或主叫用户主动挂断，根据需求也可以用其他符号指代该网络异常或该主叫用户主动挂断的未响铃原因，例如用取值0指代网络异常的未响铃原因以及用1指代主叫用户主动挂断的未响铃原因，本文对此不做限定。

可选的，上述数据库表A可以存储在被叫终端中，也可以存储在被叫终端的服务器或云端服务器中，本申请实施例对此不做限定。

表3

来电号码	呼叫时间	未响铃原因
			157xxxxxx55	2021/11/10 14:15	网络异常
157xxxxxx55	2021/11/10 14:16	网络异常
			139xxxxxx85	2021/11/2914:12	主叫用户主动挂断
...	...	...

在本申请实施例中，可以在被叫终端的通话app的首页中新增用于显示未响铃来电信息的列表对应的前端用户界面（为便于描述，本文将该前端用户界面称为未响铃来电列表）。具体可以参照上文关于图3的相关描述，在此不再详述。

示例性的，当确定呼叫异常的原因为主叫用户主动挂断时，将上述第一invite消息中包含的主叫电话号码以及该失败原因存储到数据库表A中。在被叫终端检测到被叫用户打开了通话app中的该未响铃来电列表页面的情况下，将该数据库表A中存储的部分数据内容显示到该未响铃来电列表页面中。例如，将该第一invite消息中包含的主叫电话号码显示到该未响铃来电列表页面中。可选的，还可以将该第一invite消息中包含的其他数据内容（例如call-ID、会话类型以及呼叫时间等中的一项或多项）显示到该未响铃来电列表页面中，本文对此不做限定。

在本申请实施例中，还可以在被叫终端的通话app中还可以新增用于显示未响铃来电的详细信息的用户界面。具体参照上文关于上述图4A-图4B的相关描述，在此不再详述。

在本申请实施例中，上述第一提示内容用于向被叫用户指示主叫终端的此次来电在未响铃前接通失败。该第一提示内容可以包括上述第一invite消息中包括的数据内容中的一项或多项。示例性的，该第一提示内容可以包括主叫终端的电话号码以及主叫终端发起呼叫的呼叫时间。例如，该第一提示内容为：“11月29日14时12分您有一通来自139xxxxxx85号码的来电，在响铃前因对方挂断而终止”。具体以何种方式输出该第一提示内容，可以参照本文关于图5-图6的相关说明，在此不再详述。

S1006，确定呼叫接通失败的失败原因为网络异常，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第二提示内容。

在本申请实施例中，在确定呼叫异常的原因不为主叫用户主动挂断的情况下，确定呼叫接通失败的失败原因为网络异常，将该第一invite消息中包含的主叫终端的电话号码以及该失败原因存储到上述数据库表A中。其中，复用上述表3，数据库表A中存储的该第一invite消息的失败原因列的值为“网络异常”，具体如何存储以及存储的数据内容可以参照上述步骤S1005的相关说明，在此不再详述。

可理解的，可以在同一个数据库表（例如上述数据库表A）中存储失败原因为主叫用户主动挂断和失败原因为网络异常的未响铃来电信息，也可以在不同的两个数据库表中分别存储失败原因为主叫用户主动挂断和失败原因为网络异常的未响铃来电信息，例如在上述数据库表A中存储失败原因为主叫用户主动挂断的未响铃来电信息，在上述数据库表B中存储失败原因为网络异常的未响铃来电信息，本文对此不做限定。

在本申请实施例中，上述第二提示内容用于向被叫用户指示主叫终端的此次来电在未响铃前接通失败的失败原因为网络异常。该第二提示内容可以包括上述第一invite消息中包括的数据内容中的一项或多项。示例性的，该第二提示内容可以包括主叫终端的电话号码以及主叫终端发起呼叫的呼叫时间。例如，该第二提示内容为：“11月29日14时12分您有一通来自139xxxxxx85号码的来电，在响铃前因网络异常而终止”。具体以何种方式输出该第二提示内容，可以参照本文关于图5-图6的相关说明，在此不再详述。

S1007，结束流程。

在本申请实施例中，在确定被叫终端未接收到IMS发送的错误反馈信息的情况下，被叫终端侧可以不输出提示信息，不向被叫用户提醒主叫终端的此次来电（也可以理解为结束流程，不做操作），通话记录中也可以不记录此次来电的信息。具体的，不存储该第一invite消息中包含的主叫终端的电话号码。

由此，当上述第一信令交互失败且被叫终端未接收到IMS反馈的错误信息的情况下，不做进一步的处理，提高被叫终端系统容错性，减少代码漏洞（bug）。

在一些实现方式中，在确定被叫终端未接收到IMS发送的错误反馈信息的情况下，也可以有其他的处理方式，本文对此不做限定。

示例性的，在确定被叫终端未接收到IMS发送的错误反馈信息的情况下，也可以有其他的处理方式，例如确定呼叫接通失败的失败原因为未知，存储该第一invite消息中包含的主叫终端的电话号码、呼叫时间以及该失败原因，并输出第三提示信息，该第三提示信息用于向被叫用户指示主叫终端的此次来电在未响铃前接通失败的失败原因未知。例如，该第三提示内容为：“11月29日14时12分您有一通来自139xxxxxx85号码的来电，在响铃前因未知的错误而终止”。具体以何种方式输出该第三提示内容，可以参照本文关于图5-图6的相关说明，在此不再详述。

示例性的，在被叫终端接收到的IMS发送的不可解析的错误信息，例如被叫终端接收到的IMS发送的cancel消息且该cancel消息为不带reason头域的不可解析的cancel消息的情况下，执行上述步骤S1007（也即对被叫用户无提醒，在通话记录中无记录）。

S1008，确定被叫终端是否向IMS发送183 session progress消息。

关于183 session progress消息的具体说明请参照上文（例如上述图2中的步骤S203）相关描述，在此不再详述。

在SIP协议中，正常情况下，被叫终端与IMS进行的上述第一信令交互中，当被叫终端成功接收到该第一invite请求后，被叫终端会向IMS发送100 trying消息，随后发送183session progress。则可理解的，在确定被叫终端向IMS发送100 trying消息后，确定被叫终端是否向IMS发送183 session progress消息；若确定被叫终端向IMS发送183 sessionprogress消息，则表示该第一信令交互仍在正常进行；若被叫终端未向IMS发送183session progress消息，则表示该第一信令交互出现异常。

在确定被叫终端不向IMS发送183 session progress消息的情况下，执行上述步骤S1003，也即确定被叫终端是否接收到IMS发送的错误反馈信息。在确定被叫终端向IMS发送183 session progress消息的情况下，执行步骤S1009。

S1009，确定被叫终端是否接收到IMS发送的PRACK消息。

关于PRACK消息的具体说明请参照上文（例如上述图2中的步骤S204）相关描述，在此不再详述。

在SIP协议中，正常情况下，被叫终端与IMS进行的上述第一信令交互中，当被叫终端向IMS发送183 session progress消息且IMS接收到该183 session progress消息后，IMS会向被叫终端发送PRACK消息。则可理解的，在确定被叫终端向IMS发送183 sessionprogress消息后，确定被叫终端是否接收到IMS发送的PRACK消息；若确定被叫终端接收到IMS发送的PRACK消息，则表示该第一信令交互仍在正常进行；若确定被叫终端未接收到IMS发送的PRACK消息，则表示该第一信令交互出现异常。

在确定被叫终端未接收到IMS发送的PRACK消息的情况下，执行上述步骤S1003，也即确定被叫终端是否接收到IMS发送的错误反馈信息。在确定被叫终端接收到IMS发送的PRACK消息的情况下，执行步骤S1010。

S1010，确定被叫终端是否向IMS发送200 ok消息。

在SIP协议中，可以通过SIP消息（也即200 ok消息）中的CSeq字段来标识该200 ok消息是针对上述S1009步骤的PRACK消息的响应确认消息。关于200 ok消息的具体说明请参照上文（例如上述图2中的步骤S205和S207）相关描述，在此不再详述。

在SIP协议中，正常情况下，被叫终端与IMS进行的上述第一信令交互中，当被叫终端接收到IMS发送的PRACK消息后，被叫终端会向IMS发送200 ok会话成功消息。则可理解的，在确定被叫终端接收到IMS发送的PRACK消息后，确定被叫终端是否向IMS发送200 ok消息；若确定被叫终端向IMS发送200 ok消息，则表示该第一信令交互仍在正常进行；若确定被叫终端未接收到IMS发送的PRACK消息，则表示该第一信令交互出现异常。

在确定被叫终端不向IMS发送200 ok消息的情况下，执行上述步骤S1003，也即确定被叫终端是否接收到IMS发送的错误反馈信息。在确定被叫终端向IMS发送200 ok消息的情况下，执行步骤S1011。

S1011，确定被叫终端是否向IMS发送180 ringing消息。

关于180 ringing消息的具体说明请参照上文（例如上述图2中的步骤S208）相关描述，在此不再详述。

在SIP协议中，正常情况下，若上述第一信令交互为不带资源预留的信令交互，被叫终端与IMS进行的上述第一信令交互中，当被叫终端与IMS完成上述步骤S1008中的183session progress消息、上述步骤S1009中的PRACK消息以及上述步骤S1010中的200 ok消息的信令交互后，被叫终端就会向IMS发送180 ringing消息。则可理解的，在确定被叫终端向IMS发送200 ok消息后，确定被叫终端是否向IMS发送180 ringing消息；若确定被叫终端向IMS发送180 ringing消息，则表示该第一信令交互仍在正常进行；若确定被叫终端不向IMS发送180 ringing消息，则表示该第一信令交互出现异常。

在确定被叫终端不向IMS发送180 ringing消息的情况下，执行上述步骤S1003，也即确定被叫终端是否接收到IMS发送的错误反馈信息。在确定被叫终端向IMS发送180ringing消息的情况下，执行步骤S1012。

S1012，被叫终端响铃或振动。

可理解的，上述在确定被叫终端不向IMS发送183 session progress消息的情况下，或者，在确定被叫终端未接收到IMS发送的PRACK消息的情况下，或者，在确定被叫终端不向IMS发送200 ok消息的情况下，或者，在确定被叫终端不向IMS发送180 ringing消息的情况下，执行上述步骤S1003，也会继续执行步骤S1003之后的步骤（依据具体执行情况继续执行步骤S1003之后的步骤），也即，依据具体情况继续执行上述步骤S1003-步骤S1007，从而进一步确定上述第一信令交互失败的失败原因。

由此，在帮助被叫用户避免错过重要来电的同时，基于对呼叫失败的失败原因的分析，向用户提供不同的提示信息，被叫用户可以根据失败原因确定是否需要回拨主叫终端，满足用户需求，帮助用户减少工作量，以及减少终端不必要的性能损耗。

在一些实现方式中，被叫终端与IMS关于被叫接通流程的也可以为带资源预留的信令交互（也可以理解为上述第一信令交互也可以为带资源预留的信令交互），以下结合关于上述图10的相关说明和如图11所示的方法流程图，说明本申请实施例提供的来电通知方法。

如图11所示，对于上述第一信令交互为带资源预留的信令交互的情况下，在上述步骤S1010之后步骤S1011之前，本申请实施例提供的来电通知方法还包括：

在上述步骤S1010中确定被叫终端是否向IMS发送200 ok消息之后，在确定被叫终端位向IMS发送200 ok消息的情况下，执行上述步骤S1003（也即确定被叫终端是否接收到IMS发送的错误反馈信息）。在确定被叫终端向IMS发送200 ok消息的情况下，执行步骤S1101。

S1101，确定被叫终端是否接收到IMS发送的update消息。

可理解的，该步骤S1101中所描述的200 ok消息为上述步骤S1010中的200 ok消息，也即该200 ok消息为针对上述S1009步骤的PRACK消息的响应确认消息。

关于update消息的更详细的说明请参照上文相关描述，在此不再详述。

在SIP协议中，正常情况下，若上述第一信令交互为带资源预留的信令交互，被叫终端与IMS进行的上述第一信令交互中，当被叫终端与IMS完成执行上述步骤S1010确定被叫终端向IMS发送200 ok消息后且主叫终端向IMS发送了已完成资源预留的通知消息后，IMS就会向被叫终端发送上述update 消息。则可理解的，在执行上述步骤S1010确定被叫终端向IMS发送200 ok消息后，确定被叫终端是否接收到IMS发送的update消息；若确定被叫终端接收到IMS发送的update消息，则表示该第一信令交互仍在正常进行；若确定被叫终端未接收到IMS发送的update消息，则表示该第一信令交互出现异常。

在本申请实施例中，在确定被叫终端未接收到IMS发送的update消息的情况下，执行上述步骤S1003（也即确定被叫终端是否接收到IMS发送的错误反馈信息）。在确定被叫终端未接收到IMS发送的update消息的情况下，执行步骤1102。

S1102，确定被叫终端是否响应于该update消息向IMS发送200 ok消息。

在本申请实施例中，该步骤S1102中的200 ok消息中包括的CSeq字段可以标识该200 ok消息是针对上述S1101中的update消息的响应确认消息，区别于上述步骤S1010中的200 ok消息中的CSeq字段中标识了S1010中的200 ok消息是针对上述S1009步骤的PRACK消息的响应确认消息。关于200 ok消息的更详细的说明请参照上文相关描述，在此不再详述。

在SIP协议中，正常情况下，若上述第一信令交互为带资源预留的信令交互，被叫终端与IMS进行的上述第一信令交互中，当被叫终端与IMS执行上述步骤S1101确定被叫终端接收到IMS发送的update消息且被叫终端侧也已完成资源预留后，被叫终端就会向IMS发送上述200 ok（针对上述步骤S1101中的update消息）的响应确认消息。则可理解的，在执行上述步骤S1101确定被叫终端接收到IMS发送的update消息后，确定被叫终端是否响应于该update消息向IMS发送200 ok消息；若确定被叫终端响应于该update消息向IMS发送200 ok消息，则表示该第一信令交互仍在正常进行；若确定被叫终端未响应于该update消息向IMS发送200 ok消息，则表示该第一信令交互出现异常。

在本申请实施例中，在确定被叫终端响应于该update消息向IMS发送200 ok消息的情况下，执行上述步骤S1011，也即确定被叫终端是否向IMS发送180ringing消息。

可理解的，在确定被叫终端响应于该update消息向IMS发送200 ok消息的情况下，执行上述步骤S1011，在执行完上述步骤S1011后，也会依据具体执行情况继续执行步骤S1011之后的步骤。也就是说，在确定被叫终端不向IMS发送183 session progress消息的情况下，继续执行上述步骤S1011-步骤S1012，从而进一步确定上述第一信令交互是否成功，以及若该第一信令交互，则根据错误分析确定失败原因。

在本申请实施例中，在确定被叫终端接收到IMS发送的update消息且被叫终端未响应于该update消息向IMS发送200 ok消息的情况下，执行上述步骤S1003，也即确定被叫终端是否接收到IMS发送的错误反馈信息。

可理解的，上述在确定被叫终端未接收到IMS发送的update消息的情况下，或者，在确定被叫终端未响应于该update消息向IMS发送200 ok消息的情况下，执行上述步骤S1003，也会继续执行步骤S1003之后的步骤（依据具体执行情况继续执行步骤S1003之后的步骤），也即依据具体情况继续执行上述步骤S1003-步骤S1007，从而进一步确定上述第一信令交互失败的失败原因。

以下详细介绍上述步骤S1003-步骤S1006的具体实现方法。

在本申请实施例中，如图12所示，在错误反馈信息是SIP错误码的示例中，上述步骤S1003（确定被叫终端是否接收到IMS发送的错误反馈信息）具体可以是步骤S1201，上述步骤S1004（根据该错误反馈信息确定导致呼叫接通失败的失败原因是否为主叫用户主动挂断）具体可以是步骤S1202，具体的：

S1201，确定被叫端是否接收到IMS发送的SIP错误码。

关于SIP错误码的具体说明请参照上文图10中步骤S1003的相关描述，在此不再详述。

在确定被叫端接收到IMS发送的SIP错误码的情况下，执行步骤S1202。

S1202，确定该SIP错误码是否包含486、600或603错误码中的一项或多项。

关于486、600或603错误码的具体说明请参照上表1的相关描述，在此不再详述。

在确定该SIP错误码包含486、600或603错误码中的一项或多项的情况下，执行上述步骤S1005，也即确定呼叫接通失败的失败原因为主叫用户主动挂断，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第一提示内容。

在确定该SIP错误码不包含486、600或603错误码中的一项或多项的情况下，执行上述步骤S1006，也即确定呼叫接通失败的失败原因为网络异常，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第二提示内容。

关于第一invite消息、主叫终端的电话号码、失败原因、第一提示内容以及第二提示内容的具体说明请参照图10中的相关描述，在此不再详述。

在本申请实施例中，如图13所示，在错误反馈信息是cancel消息的示例中，上述步骤S1003（确定被叫终端是否接收到IMS发送的错误反馈信息）具体可以是步骤S1301，上述步骤S1004（根据该错误反馈信息确定导致呼叫接通失败的失败原因是否为主叫用户主动挂断）具体可以包括步骤S1302至S1304，具体的：

S1301，确定被叫终端是否接收到IMS发送的cancel消息。

上述确定被叫终端是否接收到IMS发送的cancel消息具体包括：确定被叫终端是否接收到IMS发送的带reason头域的cancel消息。

关于reason头域和cancel消息的具体说明请参照上文图10中步骤S1003的相关描述，在此不再详述。

在确定被叫终端接收到IMS发送的cancel消息的情况下，执行步骤S1302。

S1302，确定该cancel消息是否携带SIP错误码。

关于SIP错误码的具体说明请参照上文图10中步骤S1003的相关描述，在此不再详述。

在确定cancel消息携带SIP错误码的情况下，执行步骤S1303；在确定cancel消息不携带SIP错误码的情况下，执行步骤S1304。

S1303，确定该SIP错误码是否包含486、600或603错误码中的一项或多项。

关于486、600或603错误码的具体说明请参照图10和上表1的相关描述，在此不再详述。

在确定该SIP错误码包含486、600或603错误码中的一项或多项的情况下，执行上述步骤S1005，也即确定呼叫接通失败的失败原因为主叫用户主动挂断，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第一提示内容。

在确定该SIP错误码不包含486、600或603错误码中的一项或多项的情况下，执行上述步骤S1006，也即确定呼叫接通失败的失败原因为网络异常，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第二提示内容。

S1304，确定该cancel消息是否为Q.850 Cause（Q.850错误原因消息）中cause值为17，text值为“user busy”的Q.850 Cause消息或RELEASE_CAUSE（释放原因信息）中的cause值为1，text值为“user ends call”的RELEASE_CAUSE消息。

可理解的，在cancel消息携带reason头域的情况下，可以通过判断该cancel消息是否为reason：Q.850 Cause；Cause:17；text：“user busy”或reason：RELEASE_CAUSE；cause=1；text=“User ends call”确定该cancel消息是否为用于表示呼叫接通失败的失败原因为主叫用户主动挂断的cancel消息。

关于Q.850 Cause、RELEASE_CAUSE的具体说明请参照图10和上表2中的相关描述，在此不再详述。

在确定该cancel消息为Q.850 Cause中cause值为17，text值为“user busy”的Q.850 Cause消息或RELEASE_CAUSE中的cause值为1，text值为“user ends call”的RELEASE_CAUSE消息的情况下，执行上述步骤S1005，也即确定呼叫接通失败的失败原因为主叫用户主动挂断，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第一提示内容。

在确定该cancel消息不为Q.850 Causecause值为17，text值为“user busy”的Q.850 Cause消息且不为RELEASE_CAUSE中的cause值为1，text值为“user ends call”的RELEASE_CAUSE消息的情况下，执行上述步骤S1006，也即确定呼叫接通失败的失败原因为网络异常，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第二提示内容。

关于第一invite消息、主叫终端的电话号码、失败原因、第一提示内容以及第二提示内容的具体说明请参照图10中的相关描述，在此不再详述。

可选的，执行上述步骤S1302（确定该cancel消息是否携带SIP错误码）与执行上述步骤S1304（确定该cancel消息是否为Q.850 Cause中cause值为17，text值为“user busy”的Q.850 Cause消息或RELEASE_CAUSE中的cause值为1，text值为“user ends call”的RELEASE_CAUSE消息）可以没有先后顺序，也可以有先后顺序。也就是说，可以同时执行步骤S1302和步骤S1304（也即可以同时执行上述步骤S1302-S1303和步骤S1304）。例如图13所示，也可以先执行S1302，在确定该cancel消息不携带SIP错误码的情况下，再执行S1304（也即在确定该cancel消息不携带SIP错误码的情况下，再执行S1304）。还可以先执行S1304，在确定该cancel消息不为Q.850错误原因信息中的user busy且不为RELEASE_CAUSE（释放原因信息）中的User ends call的情况下，再执行S1302（S1302-S1303），本文对此不做限定。

可选的，上述步骤S1003-步骤S1006具体可以仅包括上述关于图12所示的步骤内容，也可以仅包括上述图13所示的步骤内容，还可以包括上述关于图12和图13所示的步骤内容，本文对此不做限定。

示例性的，在上述步骤S1003至步骤S1006包括上述关于图12和图13所示的步骤内容的情况下，上述步骤S1201至S1202和步骤S1301至S1304可以同时执行，也可以先后执行，本文对此不做限定。例如，先执行上述步骤S1201至S1202，在步骤S1201中确定被叫终端未接收到IMS发送的SIP错误码的情况下，再执行步骤S1301至S1304，若在步骤S1201中确定被叫终端接收到IMS发送的SIP错误码的情况下，可以不再执行上述步骤S1301至S1304；也可以基于需求，在执行步骤S1201-S1202后确定失败原因不为主叫用户主动挂断的情况下，继续执行上述步骤S1301-S1304，本文对此不做限定。又例如，先执行上述步骤S1301至S1304，在步骤S1301中确定被叫终端未接收到IMS发送的cancel消息（会话取消消息）的情况下，再执行上述步骤S1201至S1202。若在步骤S1301中确定被叫终端接收到IMS发送的cancel消息（会话取消消息）的情况下，可以不再执行上述步骤S1201至S1202；也可以基于需求，在执行步骤S1301-S1304后确定失败原因不为主叫用户主动挂断的情况下，继续执行上述步骤S1201-S1202，本文对此不做限定。

由此，基于失败原因分析向用户提供不同的提示信息，被叫用户可以根据失败原因确定是否需要回拨主叫终端，满足用户需求，帮助用户减少工作量，以及减少被叫用户由于无法得知失败原因而回拨电话，给被叫终端带来不必要的性能损耗。

在本申请实施例提供的来电通知方法中，对于未响铃来电还增加了根据主叫终端的电话号码的类型做进一步的未响铃来电通知的管控处理。根据主叫终端的电话号码的类型，确定是否需要分析未响铃来电接通失败的失败原因或者已得到失败原因是否需要通过被叫终端输出提示内容以向被叫用户指示关于该主叫终端电话号码的未响铃来电的提示内容的管控。例如根据主叫终端的电话号码是否属于骚扰电话、是否属于被叫终端设置的响铃前来电提醒的黑名单列表或白名单列表，确定是否需要分析该失败原因或者已得到该失败原因是否需要通过被叫终端输出提示内容。

以下详细说明本申请实施例提供的来电通知方法中关于未响铃来电通知的管控处理的相关内容。

示例性的，如图14所示，根据主叫终端的电话号码的类型，确定是否需要分析未响铃来电接通失败的失败原因，具体的，在执行图10中的步骤S1003（也即确定被叫终端是否接收到IMS发送的错误反馈信息）之前，以及步骤S1002或S1012之前，本申请实施例提供的方法还可以包括以下步骤：

S1401，确定主叫终端的电话号码是否为特殊类别号码。

可理解的，该主叫终端的电话号码是指上述步骤S1001中的第一invite消息中包括的主叫终端的电话号码。关于第一invite消息的具体说明请参照本文关于图10的相关描述，在此不再详述。

在本申请实施例中，上述特殊类别号码可以包括骚扰电话、诈骗电话、广告推销、房产中介以及快递送餐中的一项或多项特殊类别号码。

以下为便于描述，以被叫终端使用的系统为安卓系统，并以与被叫终端使用的终端同为安卓系统的用户（也即安卓用户）为例，详细说明上述特殊类别号码。

示例性的，如下表4所示，在被叫终端的服务器或云服务器中配置有数据库表C，该数据库表C用于存储上述特殊类别号码的数据信息，具体可以包括类别、号码以及被标记次数（初始值为0）。当安卓用户中的任意一个用户将A号码标记为骚扰电话，则在该数据库表中存储该A号码，并将该A号码对应的被标记次数加1。

表4

类别	号码	被标记次数
			骚扰电话	182xxxxxx80	10
诈骗电话	172xxxxxx90	10000

示例性的，当确定上述第一invite消息中包括的主叫终端的电话号码包含于上述数据库表C中，则确定该主叫终端的电话号码为特殊类别号码。当确定上述第一invite消息中不包括的主叫终端的电话号码包含于上述数据库表C中，则确定该主叫终端的电话号码为特殊类别号码。

可理解的，存储该特殊类别号码的存储方式可以有很多种，例如还可以在不同的数据库表中存储不同的类别的电话对应的信息，或者，也可以不细分类别，而是直接记录电话号码的被标记次数等，从而具体的如何确定主叫终端的电话号码是否为特殊类别号码可以依据存储方式而定，本文对此不做限定。

在本申请实施例中，若确定主叫终端的电话号码为特殊类别号码，可以不继续分析未响铃来电接通失败的失败原因，或者不对被叫用户提醒该未响铃来电，在未响铃来电通话记录中不记录该此次来电。

在一些实现方式中，若确定主叫终端的电话号码为特殊类别号码，也可以根据该电话号码的被标记次数确定是否需要继续分析未响铃来电接通失败的失败原因，或者，已分析失败原因的，根据电话号码的被标记次数确定是否向被叫用户提醒该未响铃来电，在未响铃来电通话记录中不记录该此次来电。示例性的，当该电话号码的被标记次数大于100时，确定需要继续分析未响铃来电接通失败的失败原因，或者，已分析失败原因的，确定向被叫用户提醒该未响铃来电，在未响铃来电通话记录中记录该此次来电。

在一些实现方式中，也可以在确定主叫终端的电话号码为特殊类别号码之后，继续判断该电话号码是否包含于被叫终端设置的响铃前来电提醒的白名单列表，若是则继续分析未响铃来电接通失败的失败原因，对被叫用户提醒该未响铃来电，在未响铃来电通话记录中记录该此次来电。从而避免未响铃来电恰好是被叫用户认识的人，而又由于未响铃来电号码属于特殊类别号码不被提示，导致被叫用户错过重要来电。

可选的，上述特殊类别号码可以存储在被叫终端中，也可以存储在被叫终端的服务器或云服务器中，本文对此不做限定。

在确定主叫终端的电话号码不为特殊类别号码的情况下，执行步骤S1402，在确定主叫终端的电话号码为特殊类别号码的情况下，执行上述步骤S1007，也即结束流程。

S1402，确定主叫的电话号码是否包含于被叫终端设置的响铃前来电提醒的黑名单列表。

在本申请实施例中，在确定主叫终端的电话号码不为特殊类别号码的情况下，确定主叫的电话号码是否包含于被叫终端设置的响铃前来电提醒的黑名单列表。

在本申请实施例中，在被叫终端中还提供未响铃来电是否允许通知的个性化设置的功能（以下为便于描述，将未响铃来电是否允许通知的个性化设置的功能简称为未响铃来电个性化设置功能）。该未响铃来电个性化功能中可以包括黑名单列表，用户（使用被叫终端的用户）可以通过该黑名单功能，将希望未响铃来电不输出提示内容（也即不通知）的来电号码加入黑名单列表。对属于该黑名单列表中的电话号码的未响铃来电，被叫终端可以不分析未响铃来电接通失败的失败原因，不对被叫用户提醒该未响铃来电，在未响铃来电通话记录中可以不记录该此次来电。或者也可以分析未响铃来电接通失败的失败原因，并在存储该未响铃来电的信息，但是不向被叫用户直接提醒该未响铃来电的内容，而当用户打开了相应的存储或记录未响铃来电的功能后，还是可以查看到未响铃来电的信息。

示例性的，黑名单列表中包括的电话号码如下表5所示。可理解的，该黑名单列表可以存储在被叫终端中，也可以存储在被叫终端的服务器、云服务器或云端中，本文对此不做限定。

表5

黑名单号码
	183xxxxxx70
178xxxxxx90
	173xxxxxx65

在确定主叫的电话号码不包含于被叫终端设置的响铃前来电提醒的黑名单列表的情况下，执行步骤S1403；在确定主叫的电话号码包含于被叫终端设置的响铃前来电提醒的黑名单列表的情况下，执行上述步骤S1007，也即结束流程。

S1403，确定主叫终端的电话号码是否包含于被叫终端设置的响铃前来电提醒的白名单列表。

在本申请实施例中，在确定主叫的电话号码不包含于被叫终端设置的响铃前来电提醒的黑名单列表的情况下，确定主叫的电话号码是否包含于被叫终端设置的响铃前来电提醒的白名单列表。

在本申请实施例中，上述未响铃来电个性化功能中还可以包括白名单功能，用户可以通过该白名单功能，将希望未响铃来电输出提示信息的来电号码加入白名单列表。对属于该白名单列表中的电话号码的未响铃来电，被叫终端分析未响铃来电接通失败的失败原因，对被叫用户提醒该未响铃来电，在未响铃来电通话记录中可以不记录该此次来电。

可理解的，该白名单列表可以存储在被叫终端中，也可以存储在被叫终端的服务器、云服务器或云端中，本文对此不做限定。

在确定主叫终端的电话号码包含于该白名单列表的情况下，执行上述步骤S1003，也即确定被叫端是否收到IMS发送的错误反馈信息。

在本申请实施例中，当确定主叫终端的电话号码包含于白名单列表的情况下，执行步骤S1003，并根据具体情况执行上述步骤S1003-S1007，确定未响铃来电接通失败的失败原因。

在确定主叫终端的电话号码不包含于上述白名单列表的情况下，执行步骤S1404；在确定主叫终端的电话号码包含于上述白名单列表的情况下，执行步骤S1003，也即确定被叫端是否收到IMS发送的错误反馈信息。

S1404，确定60s内该主叫终端的电话号码是否拨打出现两次及两次以上。

在本申请实施例中，在确定主叫终端的电话号码不包含于上述白名单列表的情况下，确定60s（s为时间单位：秒）内该主叫终端的电话号码的未响铃来电的次数是否大于两次或两次以上。

可理解的，上述60s仅为示例，还可以为其他合适的取值，例如2min（min为时间单位：分钟）或5min等合适的取值，本文对此不做限定。

在确定60s内上述主叫终端的电话号码未拨打出现两次及两次以上的情况下，执行步骤S1405；在确定60s内上述主叫终端的电话号码拨打出现两次及两次以上的情况下，执行步骤S1003，也即确定被叫端是否收到IMS发送的错误反馈信息。

S1405，存储此次来电的信息，但不向用户通知此次来电。

可理解的，上述存储此次来电的信息，但不向用户通知此次来电，具体可以包括：继续执行上述步骤S1003-S1007，确定未响铃来电接通失败的失败原因。若存在用户主动挂断或网络异常的失败原因，则存储上述第一invite消息中包含的主叫终端的电话号码以及该失败原因，但不输出上述第一提示内容和第二提示内容。关于第一invite消息、第一提示内容、第二提示内容的具体说明请参照本文关于图10的相关描述，在此不再详述。

示例性的，如上表3所示，若主叫终端的来电号码为“157xxxxxx55”，不属于特殊类别号码、不属于黑名单列表中的号码、也不属于白名单列表中的号码，则执行上述步骤S1003-S1007得到未响铃原因，将该来电号码、呼叫时间以及未响铃来电原因存储在数据库表A中。当处理下一个未响铃来电时，则可以从该数据库表A中，根据来电号码和呼叫时间确定当前未响铃来电60s（s为时间单位：秒）内的拨号次数。

可理解的，在另外一些实施例中，上述存储此次来电的信息，但不向用户通知此次来电，具体还可以为：不分析未响铃来电接通失败的失败原因，仅存储上述第一invite消息中包含的主叫终端的电话号码以及呼叫时间，且不向用户通知此次来电。具体实现方式不唯一，依据具体需求而定，本文对此不做限定。

在本申请实施例中，在确定主叫终端的电话号码为特殊类别号码的情况下，或者，在确定主叫终端的电话号码不为特殊类别号码且主叫终端的电话号码包含于被叫终端设置的响铃前来电提醒的黑名单列表的情况下，执行上述S1007，结束流程，不分析此次未响铃来电的失败原因，不存储此次来电的信息，且不向用户通知此次来电（也可以理解为不做操作或结束流程）。

从而，节省不必要的错误分析带来的性能损耗。

可理解的，上述黑名单列表和白名单列表中不包括相同的电话号码。

可理解的，在实际应用中，来电通知方法中关于未响铃来电通知的管控处理可以包括，上述图14所示的判断步骤S1401、S1402、S1403以及S1405中的一项或多项步骤，且该一项或多项步骤可以同时执行，也可以先后执行，本文对此不做限定。示例性的，来电通知方法中关于未响铃来电通知的管控处理可以仅包括S1401步骤，确定主叫终端的电话号码是否为特殊类别号码，若是则不分析此次未响铃来电的失败原因，不存储此次来电的信息，以及不向用户通知此次来电，若否则继续执行上述步骤S1003。示例性的，如图14所示，来电通知方法中关于未响铃来电通知的管控处理可以包括步骤S1401、S1402、S1403以及S1405，而图14中关于步骤S1401、S1402、S1403以及S1405的先后执行顺序仅为示例，还可以为其他的执行顺序，本文对此不做限定。

示例性的，如图15所述，先执行步骤S1501（确定主叫终端的电话号码是否包含于被叫终端设置的响铃前来电提醒的白名单列表），相当于先执行上述步骤S1403。在执行上述步骤S1501后确定主叫终端的电话号码不包含于被叫终端设置的响铃前来电提醒的白名单列表的情况下，则执行步骤S1502（确定主叫终端的电话号码是否属于特殊类别号码），相当于执行上述步骤S1401。在执行步骤S1502后确定主叫终端电话号码不属于特殊类别号码的情况下，则执行步骤S1503（确定主叫终端的电话号码是否包含于被叫终端设置的响铃前来电提醒的黑名单列表），相当于执行上述步骤S1402。在执行上述步骤S1503后确定主叫端电话号码不包含于被叫终端设置的响铃前来电提醒的黑名单列表，则执行步骤S1504（确定60s内该主叫终端的电话号码是否拨打出现两次及两次以上），相当于执行上述步骤S1405。

从而对未响铃来电通知做过滤管控处理，在需要或有必要的时候分析来电在未响铃前接通失败的失败原因，并向被叫用户输出明确的通知消息，在避免用户错过重要来电的同时尽量减少未响铃来电通知给被叫用户带来的一些不必要的打扰，以及减少被叫用户的工作量。

在一些可能的实现方式中，也可以在确定到未响铃来电呼叫接通失败的失败原因之后（也即步骤S1004之后），以及输出提示内容（第一提示内容、第二提示内容或第三提示内容）之前（也即步骤S1005和步骤S1006之前），对未响铃来电通知做管控处理，根据主叫终端的电话号码的类型再确定执行上述步骤S1005、S1006或S1007中的哪些步骤。示例性的，先执行上述步骤S1003-S1004确定到呼叫失败的失败原因后，再执行如图14或图15所示的方案。

例如，在执行上述步骤S1003-S1004确定来电在未响铃前接通失败的失败原因为用户主动挂断的情况下，执行如图14所示的方案，也即根据主叫终端的电话号码的类型确定是否输出上述第一提示信息。具体的，如图16所示，在执行步骤S1401-步骤S1404后，确定主叫终端的电话号码不为特殊类别号码、主叫终端的电话号码不包含于被叫终端设置的响铃前来电提醒的黑名单列表、以及主叫终端的电话号码包含于被叫终端设置的响铃前来电提醒的白名单列表的情况下，或者，在确定主叫终端的电话号码不包含于被叫终端设置的响铃前来电提醒的白名单列表，但60s内该主叫终端的电话号码是否拨打出现两次及两次以上的情况下，则执行上述步骤S1005，也即确定呼叫接通失败的失败原因为主叫用户主动挂断，存储该第一invite消息中包含的主叫终端的电话号码以及该失败原因，以及输出第一提示内容。

或者，在执行步骤S1401-步骤S1404后，确定主叫终端的电话号码为特殊类别号码，或主叫终端的电话号码包含于被叫终端设置的响铃前来电提醒的黑名单列表的情况下，执行上述步骤S1007，结束流程。

可理解的，未响铃来电通知的管控处理还可以有其他实现方式，例如根据主叫终端的电话号码的所属地区，以及被叫终端的电话号码的所属地区对未响铃来电通知做管理处理，本文对此不做限定。

由此，对未响铃来电通知做过滤管控处理，在需要或有必要的时候，向被叫用户输出明确的通知消息，在避免用户错过重要来电的同时尽量减少未响铃来电通知给被叫用户带来的一些不必要的打扰，以及减少被叫用户的工作量。

在本文其他实施例中，第一提示内容也可以称为第一提示信息，第二提示内容也可以称为第二提示信息，第三提示内容也可以称为第三提示信息，只是相同概念的不同表述。

实施例2：

如图17所示，本文还提供了另外一种来电通知方法，确定被叫终端与IMS是否在对应的时长内完成对应的信令交互，若否则立即确定此次来电在未响铃前接通失败，若是，则确定被叫终端与IMS是否在对应时长内完成下一个相应的信令交互。

以下为便于描述，如图17所示的来电通知方法省略了执行本申请实施例提供的方法的执行主体。具体的，执行本申请实施例提供的方法的执行主体可以为被叫终端也可以为来电通知模块，关于该来电通知模块的具体说明请参照本文其他实施例（例如图10）中的相关描述，在此不再详述。

具体的，如13所示，该来电通知方法包括以下步骤：

S1701，接收IMS发送的第一invite消息。

关于第一invite消息的具体说明请参照本文其他实施例的相关描述（例如图10中S1001），在此不再详述。

S1702，确定a时长内被叫终端是否向IMS发送100 trying消息。

关于100 trying消息的具体说明请参照本文其他实施例的相关描述，在此不再详述。

在本申请实施例中，上述a时长可以是程序设计者根据经验自定义设置的时长。为保证该a时长的准确性，上述a时长也可以是样本时长，该样本时长是指呼叫正常接通正常响铃流程中成功执行上述图2所示的每个步骤的样本数据中，抓取该样本数据中每两个信令步骤之间的日志（log），并分析该log中每两个相邻步骤之间的相隔时长，以及取样本数据中对应两个相邻步骤的该相隔时长中的最大值作为该对应两个相邻步骤的样本时长。

示例性的，样本数量为200，每个样本数据为呼叫正常接通正常响铃的信令交互流程。抓取该200个样本数据中与上述图2中步骤S201-S202对应的日志（log），该log中包括步骤S201的执行时间和S202的执行时间，将该200个样本数据中该步骤S201的执行时间和步骤S202的执行时间做差运算，得到200个差值，取该200个差值中的最大值作为上述a时长的值。从而，提高a时长的可信度、准确度和容错度。

可理解的，上述样本数量200仅为示例，在实际应用中，上述样本数量还可以为其他合适的取值，本文对此不做限定。

可选的，上述样本时长还可以是样本数据中对应步骤的执行时间的平均值、中位数等其他取值，示例性的，上述a时长还可以是上述200个差值的平均值，本文对此不做限定。

在确定a时长内被叫终端未向IMS发送100 trying消息的情况下，执行步骤S1703。在确定a时长内被叫终端向IMS发送100 trying消息的情况下，执行步骤S1704。

S1703，确定呼叫接通失败，并输出第四提示内容。

在本申请实施例中，关于具体如何存储该第一invite消息中包含的主叫终端的电话号码，可以参照本文其他实施例的相关描述（例如图10中S1005），在此不再详述。

在本申请实施例中，上述第四提示内容，用于向用户指示主叫终端的电话号码的此次来电呼叫接通失败（未响铃前异常终止）。可理解的，关于本文其他实施例（例如上述实施例1）中关于被叫终端接收IMS发送的错误反馈信息，并根据该错误反馈信息确定此次来电接通失败的失败原因等方案内容也同样适用于如图17所示的实施例中，当步骤S1704中继续对失败原因值做进一步分析的情况下，在确定失败原因为主叫用户主动挂断的情况下，该第四提示内容可以为上述第一提示内容，在确定失败原因为网络异常的情况下，该第四提示内容可以为上述第二提示内容，在确定失败原因未知的情况下，该第四提示内容可以为上述第三提示内容。

S1704，确定b时长内被叫终端是否向IMS发送183 session progress消息。

在确定b时长内被叫终端未向IMS发送183 session progress消息的情况下，执行上述步骤S1703，也即确定被叫终端是否接收到IMS发送的cancel消息或SIP错误码。

在确定b时长内被叫终端向IMS发送183 session progress消息的情况下，执行步骤S1705。

S1705，确定c时长内被叫终端是否接收到IMS发送PRACK应答消息。

在确定c时长内被叫终端未接收到IMS发送PRACK应答消息的情况下，执行上述步骤S1703，也即确定被叫终端是否接收到IMS发送的cancel消息或SIP错误码。

在确定c时长内被叫终端接收到IMS发送PRACK应答消息的情况下，执行步骤S1706。

S1706，确定d时长内被叫终端是否向IMS发送200 ok消息。

在确定d时长内被叫终端未向IMS发送200 ok消息的情况下，执行上述步骤S1703，也即确定被叫终端是否接收到IMS发送的cancel消息或SIP错误码。

在确定d时长内被叫终端向IMS发送200 ok消息的情况下，执行步骤S1707。

S1707，确定e时长内被叫终端是否向IMS发送180 ringing消息。

在确定e时长内被叫终端未向IMS发送180 ringing消息的情况下，执行上述步骤S1703，也即确定被叫终端是否接收到IMS发送的cancel消息或SIP错误码。

在确定e时长内被叫终端向IMS发送180 ringing消息的情况下，执行步骤S1708。

S1708，被叫终端响铃或振动。

在本申请实施例中，关于上述b时长、c时长、d时长以及e时长的取值方式的说明可以参照上述步骤S1702中关于a时长的取值方式的相关描述，在此不再详述。

由此，根据被叫终端与IMS是否在相应的时长内完成相应的信令交互确定是否在180 ringing信令交互之前信令交互就已经交互失败。这样当信令交互失败出现在180ringing信令交互之前的信令交互中时，则立即确定此次来电在未响铃前接通失败；而不是直到预设时长内结束被叫终端与IMS都没有未完成180 ringing信令交互，或直到被叫终端接收到IMS发送的通话断开的失败信息，或直到被叫终端接收到IMS发送的SIP错误码的情况下，才会确定此次来电在未响铃前接通失败。在帮助被叫用户避免错过重要来电的同时，减少被叫终端确认一通接通失败的未响铃来电所需的性能消耗。

可理解的，关于本文其他实施例（例如上述实施例1）中关于被叫终端接收IMS发送的错误反馈信息，并根据该错误反馈信息确定此次来电接通失败的失败原因、关于带资源预留的信令交互、以及关于未响铃来电通知的管控处理（特殊类型号码、黑名单列表以及白名单列表）等方案内容也同样适用于本申请实施例中。也就是说，上述图10中的步骤S1003-S1007、图11中的S1101-S1102、图12中的S1201-S1202、图13中的步骤S1001-S1008、图14中的步骤S1401-S1405、以及图15中的步骤S1501-S1504中的相关方案，也同样适用于图17所示的来电通知方法，其具体实现方式以及有益效果请参照上文相应描述，在此不再详述。

在一些表述中，上述a时长也可以称为第一时长，上述b时长也可以称为第二时长，上述c时长也可以称为第三时长，上述d时长也可以称为第四时长，上述e时长也可以称为第五时长。

在本文中，被叫终端可以是任意具备通话功能的电子设备；示例性的，被叫终端可以是移动终端或平板电脑。可理解的，当被叫终端为移动终端或平板电脑时，被叫终端中需要配置有包含电话业务的用户标识模块(subscriber identification module，SIM)卡（也即SIM卡）或嵌入式SIM（Embedded-SIM，eSIM）卡。本文描述的被叫终端与IMS进行的信令交互可以理解为，被叫终端通过SIM卡或eSIM卡与IMS进行信令交互。

可理解的，本申请实施例提供的被叫终端可以是任意具备通话功能的电子设备，例如也可以是固定电话，当被叫终端为固定电话时，被叫终端可以通过电话线处理电话业务，也可以理解为被叫终端中可以不用额外配置SIM卡。可理解的，当被叫终端为固定电话时，可以通过保留拨号记录或者语音助手等方式向被叫用户指示未响铃来电，本文对此不做限定。

可理解的，本文提供的来电通知方法可以适用于采用IMS处理语音及多媒体业务的所有场景，主要应用于电话语音业务场景，但也可以基于需求，应用于其他语音或多媒体业务中，例如社交软件（微信等）中的语音通话或视频通话等应用场景中，本文对此不做限定。

可理解的，目前通信领域中处理语音及多媒体业务的系统网络为IMS，随着通信协议的不断发展，处理语音及多媒体业务的系统也可以为其他系统网络，本申请实施例提供的来电通知方法的核心思想也可以适用于该其他系统网络，本文对此不做限定。

下面以上述被叫终端为如图18所示的终端200为例对实施例进行具体说明。应该理解的是，终端200可以具有比图18中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图18中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

终端200可以包括：处理器210，外部存储器接口220，内部存储器221，天线1，天线2，移动通信模块230，无线通信模块240，传感器模块250，音频模块260，扬声器260A，受话器260B，麦克风260C，用户标识模块(subscriber identification module，SIM)卡接口270、按键280以及显示屏281等。其中传感器模块250可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。

示例性的，终端200中还可以包括通用串行总线(universal serial bus，USB)接口，充电管理模块，电源管理模块，电池，马达，指示器以及摄像头等部件，本文对此不做限定。

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

处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

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

在一些实施例中，处理器210可以包括一个或多个接口。接口可以包括集成电路（inter-integrated circuit，I2C）接口，集成电路内置音频（inter-integrated circuitsound，I2S）接口，脉冲编码调制（pulse code modulation，PCM）接口，通用异步收发传输器（universal asynchronous receiver/transmitter，UART）接口，移动产业处理器接口（mobile industry processor interface，MIPI），通用输入输出（general-purposeinput/output，GPIO）接口，用户标识模块（subscriber identity module，SIM）接口，和/或通用串行总线（universal serial bus，USB）接口等。

示例性的，处理器210可以用于执行上述图10-图17所示的方法实施例中任意一个方法实施例的方法或步骤，也可以由处理器210和终端200中的其他模块配合执行上述图10-图17所示的实施例中任意一个方法实施例的方法或步骤，本文对此不做限定。

需要说明的是，具体执行过程可以参见图10或图17所示的实施例的具体说明，在此不进行赘述。

可理解的，终端200通过GPU，显示屏281，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏281和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器210可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

外部存储器接口220可以用于连接外部存储卡，例如Micro SD卡，实现扩展终端200的存储能力。外部存储卡通过外部存储器接口220与处理器210通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行终端200的各种功能应用以及数据处理。内部存储器221可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序（比如声音播放功能，图像播放功能等）等。存储数据区可存储终端200使用过程中所创建的数据（比如音频数据，电话本等）等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器（universal flash storage，UFS）等。

在本申请实施例中，可以在该内部存储器221中存储上述主叫终端的电话号码、呼叫时间、失败原因、第一提示内容、以及第二提示内容中的一项或多项。关于电话号码、呼叫时间、失败原因、第一提示内容、以及第二提示内容的描述请参照本申请其他方法实施例的相关描述，在此不再赘述。

终端200的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。

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

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

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

无线通信模块260可以提供应用在终端200上的包括无线局域网（wireless localarea networks，WLAN）（如无线保真（wireless fidelity，Wi-Fi）网络），蓝牙（bluetooth，BT），全球导航卫星系统（global navigation satellite system，GNSS），调频（frequencymodulation，FM），近距离无线通信技术（near field communication，NFC），红外技术（infrared，IR）等无线通信的解决方案。无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块260经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器210。无线通信模块260还可以从处理器210接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，终端200的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得终端200可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统（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）。

显示屏281用于显示图像，视频等。显示屏281包括显示面板。显示面板可以采用液晶显示屏（liquid crystal display，LCD），有机发光二极管（organic light-emittingdiode，OLED），有源矩阵有机发光二极体或主动矩阵有机发光二极体（active-matrixorganic light emitting diode的，AMOLED），柔性发光二极管（flex light-emittingdiode，FLED），Miniled，MicroLed，Micro-oLed，量子点发光二极管（quantum dot lightemitting diodes，QLED）等。在一些实施例中，终端200可以包括1个或N个显示屏281，N为大于1的正整数。

在本申请实施例中，可以由显示屏281显示上述第一提示内容和/或第二提示内容等，以及由显示屏281显示上述图3-图6所示的用户界面。

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

终端200可以通过音频模块260，扬声器260A，受话器260B，麦克风260C，耳机接口260D，以及应用处理器等实现音频功能。例如接打电话、音乐播放，录音等。

扬声器260A，也称“喇叭”，用于将音频电信号转换为声音信号。终端200可以通过扬声器260A收听免提通话或收听音乐。

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

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

图19是本申请实施例的终端200的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将系统分为四层，从上至下分别为应用程序层，应用程序框架层，运行时（Runtime）和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。如图19所示，应用程序包可以包括通话，相机，图库，日历，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序（也可以称为应用（application，App））。

在本申请实施例中，应用程序层还可以包括来电通知模块，该来电通知模块用于执行本申请实施例中的来电通知方法（如图10-图17所示的步骤或方法）。

在本申请的一些实施例中，该来电通知模块、也可以位于该软件构架的其他层级中，例如应用程序框架层、系统库、内核层等，此处不作限定。

应用程序框架层为应用程序层的应用程序提供应用编程接口（applicationprogramming interface，API）和编程框架。应用程序框架层包括一些预先定义的函数。

如图19所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。电话管理器用于提供终端100的通信功能。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。

运行时（Runtime）包括核心库和虚拟机。Runtime负责系统的调度和管理。

核心库包含两部分：一部分是编程语言（例如，jave语言）需要调用的功能函数，另一部分是系统的核心库。

应用程序层和应用程序框架层可以运行在虚拟机中。虚拟机可以将应用程序层和应用程序框架层的编程文件（例如，jave文件）执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器（surface manager），媒体库（Media Libraries），三维图形处理库（例如：OpenGL ES），二维图形引擎（例如：SGL）等。

内核层是硬件和软件之间的层。内核层可以包含显示驱动，摄像头驱动，音频驱动，传感器驱动，虚拟卡驱动等。

上述实施例中所用，根据上下文，术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地，根据上下文，短语“在确定…时”或“如果检测到（所陈述的条件或事件）”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到（所陈述的条件或事件）时”或“响应于检测到（所陈述的条件或事件）”。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线）或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质（例如固态硬盘）等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (17)

1.一种来电通知方法，其特征在于，所述方法包括：

被叫终端接收到错误反馈信息，其中所述被叫终端处于被主叫终端的第一来电呼叫且未响铃的状态，所述错误反馈信息用于表示所述第一来电在响铃前接通失败；

所述被叫终端根据所述错误反馈信息确定所述第一来电在响铃前接通失败的失败原因；

所述被叫终端至少根据所述失败原因输出目标提示信息，所述目标提示信息为多个不同的提示信息中与所述失败原因对应的提示信息，所述多个不同的提示信息中的每一个提示信息分别用于表示一种所述第一来电在响铃前接通失败的原因。

2.根据权利要求1所述的方法，其特征在于，所述错误反馈信息包括第一类型错误反馈信息，所述第一类型错误反馈信息为预设的用于表示主叫终端主动挂断导致呼叫接通失败的错误反馈信息，

所述被叫终端根据所述错误反馈信息确定所述第一来电在响铃前接通失败的失败原因，包括：

所述被叫终端根据所述第一类型错误反馈信息确定所述失败原因为所述主叫终端主动挂断；

所述被叫终端至少根据所述失败原因输出目标提示信息，包括：

所述被叫终端输出第一提示信息，所述第一提示信息用于指示所述第一来电在响铃前由于所述主叫终端主动挂断导致呼叫接通失败。

3.根据权利要求2所述的方法，其特征在于，所述第一类型错误反馈信息包括第一类型会话初始协议SIP错误码中的一项或多项SIP错误码和/或第一类型会话取消消息中的一项或多项会话取消消息，所述第一类型SIP错误码为预设的用于表示主叫终端主动挂断导致呼叫接通失败的SIP错误码的集合，所述第一类型会话取消消息为预设的用于表示主叫终端主动挂断导致呼叫接通失败的会话取消消息的集合。

4.根据权利要求3所述的方法，其特征在于，所述第一类型SIP错误码包括486SIP错误码、600SIP错误码、或603SIP错误码中的一项或多项；所述第一类型会话取消消息包括所述第一类型SIP错误码、原因值为17且错误原因说明为用户忙的会话取消消息或原因值为1且原因值说明为用户结束呼叫的会话取消消息中的一项或多项。

5.根据权利要求1所述的方法，其特征在于，所述错误反馈信息包括第二类型错误反馈信息，所述第二类型错误反馈信息为预设的用于表示网络异常导致呼叫接通失败的错误反馈信息，

所述被叫终端根据所述错误反馈信息确定所述第一来电在响铃前接通失败的失败原因，包括：

所述被叫终端根据所述第二类型错误反馈信息确定所述失败原因为网络异常；

所述被叫终端至少根据所述失败原因输出目标提示信息，包括：

所述被叫终端输出第二提示信息，所述第二提示信息用于指示所述第一来电在响铃前由于网络异常导致呼叫接通失败。

6.根据权利要求5所述的方法，其特征在于，所述第二类型错误反馈信息包括第二类型会话初始协议SIP错误码中的一项或多项SIP错误码和/或第二类型会话取消消息中的一项或多项会话取消消息，所述第二类型SIP错误码为预设的用于表示网络异常导致呼叫接通失败的SIP错误码的集合，所述第二类型会话取消消息为预设的用于表示网络异常导致呼叫接通失败的会话取消消息的集合。

7.根据权利要求6所述的方法，其特征在于，所述第二类型SIP错误码包括SIP错误码中除了486SIP错误码、600SIP错误码、以及603SIP错误码之外的其他SIP错误码；所述第二类型会话取消消息包括除了所述486SIP错误码、所述600SIP错误码、以及所述603SIP错误码、原因值为17且错误原因说明为用户忙的会话取消消息以及原因值为1且原因值说明为用户结束呼叫的会话取消消息之外的cancel消息。

8.根据权利要求1所述的方法，其特征在于，在所述被叫终端接收到错误反馈信息之前，所述方法还包括：

所述被叫终端接收IP多协议子系统发送的第一呼叫请求消息，所述第一呼叫请求消息用于指示所述第一来电，第一呼叫请求消息为所述IP多协议子系统根据所述主叫终端呼叫所述被叫终端的呼叫信息生成的，其中，所述第一呼叫请求消息包括所述主叫终端的电话号码；

在所述被叫终端至少根据所述失败原因输出目标提示信息之前，所述方法还包括：

所述被叫终端确定是否输出关于所述第一来电的未响铃通知；

所述被叫终端至少根据所述失败原因输出目标提示信息，包括：

在所述被叫终端确定输出关于所述第一来电的未响铃通知的情况下，所述被叫终端至少根据所述失败原因输出所述目标提示信息。

9.根据权利要求8所述的方法，其特征在于，所述被叫终端中记录的白名单中包括所述主叫终端的电话号码，所述白名单为被叫用户在所述被叫终端中记录的对于未响铃来电输出提示信息的号码列表，

所述被叫终端确定是否输出关于所述第一来电的未响铃通知，包括：

所述被叫终端根据所述白名单确定是否输出关于所述第一来电的未响铃通知。

10.根据权利要求8所述的方法，其特征在于，所述被叫终端确定是否输出关于所述第一来电的未响铃通知，包括：

在根据所述主叫终端的电话号码和历史未响铃来电列表确定预设时长内关于所述主叫终端的未响铃来电的次数大于第一阈值的情况下，所述被叫终端确定输出关于所述第一来电的未响铃通知，所述历史未响铃来电列表用于记录每个未响铃来电中主叫终端的电话号码和来电时间，所述第一阈值为大于或等于2的正整数。

11.根据权利要求10所述的方法，其特征在于，所述方法还包括：

在所述预设时长内关于所述主叫终端的未响铃来电的次数小于或等于所述第一阈值的情况下，所述被叫终端根据所述第一呼叫请求消息存储所述第一来电的来电信息，且确定不输出关于所述第一来电的未响铃通知，所述第一来电的来电信息包括所述主叫终端的电话号码和所述来电时间。

12.根据权利要求8所述的方法，其特征在于，在所述被叫终端接收IP多协议子系统发送的第一呼叫请求消息之后，所述方法还包括：

在确定不向所述IP多协议子系统发送试呼叫消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息；

或者，

在确定向所述IP多协议子系统发送所述试呼叫消息、且确定不向所述IP多协议子系统发送会话进行消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述会话进行消息用于表示正在处理一些操作以响应所述第一呼叫请求；

或者，

在确定向所述IP多协议子系统发送所述会话进行消息、且确定未接收到所述IP多协议子系统发送的临时应答消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述临时应答消息用于表示所述IP多协议子系统已接收到所述会话进行消息；

或者，

在确定接收到所述临时应答消息、且确定不向所述IP多协议子系统发送第一会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述第一会话成功消息用于表示所述IP多协议子系统与所述被叫终端关于所述临时应答消息的会话成功完成；

或者，

在确定向所述IP多协议子系统发送所述第一会话成功消息、且确定不向所述IP多协议子系统发送振铃消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述振铃消息用于表示所述被叫终端已开始响铃。

13.根据权利要求8所述的方法，其特征在于，在所述被叫终端接收IP多协议子系统发送的第一呼叫请求消息之后，所述方法还包括：

在确定不向所述IP多协议子系统发送试呼叫消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息；

或者，

在确定向所述IP多协议子系统发送所述试呼叫消息、且确定不向所述IP多协议子系统发送会话进行消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述会话进行消息用于表示正在处理一些操作以响应所述第一呼叫请求；

或者，

在确定向所述IP多协议子系统发送所述会话进行消息、且确定未接收到所述IP多协议子系统发送的临时应答消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述临时应答消息用于表示所述IP多协议子系统已接收到所述会话进行消息；

或者，

在确定接收到所述临时应答消息、且确定不向所述IP多协议子系统发送第一会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述第一会话成功消息用于表示所述IP多协议子系统与所述被叫终端关于所述临时应答消息的会话成功完成；

或者，

在确定向所述IP多协议子系统发送所述第一会话成功消息，且确定未接收到所述IP多协议子系统发送的资源预留更新通知消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述资源预留更新通知消息用于表示所述IP多协议子系统已预留好与所述被叫终端进行会话所需的语音业务数据相关的资源；

或者，

在确定接收到所述资源预留更新通知消息、且确定不向所述IP多协议子系统发送第二会话成功消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息，所述第二会话成功消息用于指示所述IP多协议子系统与所述被叫终端关于所述资源预留更新通知消息的会话成功完成；

或者，

在确定向所述IP多协议子系统发送所述第二会话成功消息、且确定不向所述IP多协议子系统发送振铃消息的情况下，所述被叫终端确定是否接收到所述错误反馈信息。

14.根据权利要求12或13所述的方法，其特征在于，所述方法还包括：

在所述被叫终端未接收到所述错误反馈信息的情况下，所述被叫终端确定所述失败原因为未知的错误；

所述被叫终端至少根据所述失败原因输出目标提示信息，包括：

在所述被叫终端确定所述失败原因为未知的错误情况下，所述被叫终端输出第三提示信息，所述第三提示信息用于指示所述第一来电在响铃前由于未知的错误导致呼叫接通失败。

15.一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器和显示屏；

所述存储器与所述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，所述一个或多个处理器调用所述计算机指令以使得所述电子设备执行如权利要求1至14任一项所述的方法。

16.一种芯片系统，所述芯片系统应用于电子设备，所述芯片系统包括一个或多个处理器，所述处理器用于调用计算机指令以使得所述电子设备执行如权利要求1至14中任一项所述的方法。

17.一种计算机可读存储介质，包括指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1至14中任一项所述的方法。

Images