故障处理方法和终端与流程

1.本申请涉及通信技术领域，具体涉及一种故障处理方法和终端。


背景技术：

2.语音信箱业务是一种基于多种网络、以语音信息交互为主要功能的业务，语音信箱为用户提供存储、转发和提取语音信息等服务。在业务的特征基础上，可对传统的语音信箱进行可视化的改进(例如，提供web页面、客户端、转彩信下发等多种可视化途径)。语音信箱的可视化使得用户操作更加便利，用户体验更好,具有广泛的商用价值。
3.但是，当语音信箱的客户端出现故障时(例如，软件冲突、因某种原因导致终端宕机(crash)等)，语音信箱的客户端会频繁向服务器发送带外短信，使服务器的数据处理量急剧增加，导致服务器的处理性能降低。


技术实现要素：

4.为此，本申请提供一种故障处理方法和终端，如何避免终端和服务器之间不必要的带外短信的交互的问题。
5.为了实现上述目的，本申请第一方面提供一种故障处理方法，方法包括：采集当前客户端所在的终端的状态信息；以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器；记录状态信息和状态信息的发送频率，生成状态信息集合；在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障；在确定终端发生故障的情况下，停止发送状态信息。
6.在一些具体实现中，在确定终端发生故障的情况下，停止发送状态信息，包括：设置状态信息为无效信息，并生成停止发送标识；依据停止发送标识，停止发送状态消息。
7.在一些具体实现中，在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障，包括：在确定发送频率大于预设频率阈值的情况下，对状态信息集合中的状态信息进行分析，获得分析结果；依据分析结果，检测终端是否发生故障。
8.在一些具体实现中，状态信息包括终端的位置信息、终端对应的注册用户信息和终端对应的运营商信息中的任意一种或几种。
9.在一些具体实现中，状态信息集合包括n条状态信息，n为大于或等于1的整数；在确定发送频率大于预设频率阈值的情况下，对状态信息集合中的状态信息进行分析，获得分析结果，包括：在确定发送频率大于预设频率阈值的情况下，提取n条状态信息中的位置信息、注册用户信息和运营商信息中的任意一种或几种；对状态信息集合中的n条状态信息进行分析，确定如下分析结果中的任意一种或几种：对n个位置信息进行分析，获得位置分析结果；对n个注册用户信息进行分析，获得注册用户信息分析结果；对n个运营商信息进行分析，获得运营商信息分析结果。
10.在一些具体实现中，位置信息包括经纬度信息；对n个位置信息进行分析，获得位
置分析结果，包括：将n个位置信息进行两两对比，确定n个位置信息中是否存在异常位置，获得位置分析结果；其中，位置分析结果包括：n个位置信息均相同，或，n个位置信息中存在异常位置。
11.在一些具体实现中，注册用户信息包括国际移动用户识别号码；对n个注册用户信息进行分析，获得注册用户信息分析结果，包括：提取n个注册用户信息中的任意一个国际移动用户识别号码，并将提取的国际移动用户识别号码作为预设号码；依据预设号码查找n个注册用户信息，确定n个注册用户信息中是否存在与预设号码不同的号码，获得注册用户信息分析结果。
12.在一些具体实现中，运营商信息包括预设运营商信息；对n个运营商信息进行分析，获得运营商信息分析结果，包括：依据预设运营商信息查找n个运营商信息，确定n个运营商信息是否都相同，获得运营商信息分析结果；其中，运营商信息分析结果包括：n个运营商信息均为预设运营商信息，或，n个运营商信息中存在与预设运营商信息不同的运营商信息。
13.在一些具体实现中，依据分析结果，检测终端是否发生故障，包括：在确定分析结果包括：位置分析结果为n个位置信息均相同、注册用户信息分析结果为n个注册用户信息均相同、且n个运营商信息均相同的情况下，确定终端发生故障；否则，确定终端没有发生故障。
14.为了实现上述目的，本申请第二方面提供一种终端，其包括：采集模块，用于采集当前客户端所在的终端的状态信息；发送模块，用于以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器；记录模块，用于记录状态信息和状态信息的发送频率，生成状态信息集合；检测模块，用于在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障；处理模块，用于在确定终端发生故障的情况下，停止发送状态信息。
15.本申请中的故障处理方法和终端，通过采集当前客户端所在的终端的状态信息，可获知终端的状态(例如，是否存在异常等)；以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器，保证语音信箱服务器能够实时获得终端的状态；记录状态信息和状态信息的发送频率，生成状态信息集合；通过记录状态信息以及状态信息的发送频率，可获知状态信息的上报是否正常(例如，状态信息的发送频率是否过慢或过快等)；在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障；通过发送频率和状态信息确定终端是否存在终端宕机等意外情况发生，保证终端的安全性；在确定终端发生故障的情况下，停止发送状态信息，减少终端发送不必要的带外短信给服务器，提升服务器的业务处理性能，避免用户投诉，提升用户体验。
附图说明
16.附图用来提供对本申请实施例的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请，并不构成对本申请的限制。通过参考附图对详细示例实施例进行描述，以上和其它特征和优点对本领域技术人员将变得更加显而易见，在附图中：
17.图1示出本申请一实施例中的故障处理方法的流程示意图。
18.图2示出本申请又一实施例中的故障处理方法的流程示意图。
19.图3示出本申请实施例中的终端的组成方框图。
20.图4示出本申请实施例中的故障处理系统的组成方框图。
21.图5示出本申请实施例中的故障处理系统的工作方法的流程示意图。
22.在附图中：
23.301：采集模块
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
302：发送模块
24.303：记录模块
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
304：检测模块
25.305：处理模块
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
401：终端
26.402：服务器
ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
403：基站
27.404：短消息中心服务器
具体实施方式
28.以下结合附图对本申请的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本申请，并不用于限制本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。
29.需要说明的是，本申请涉及的技术方案中，用户个人信息数据的获取，遵循国家相关法律法规(例如，《信息安全技术个人信息安全规范》等)。并且，信息获得方式为明确告知用户，并通过合法途径；获得的信息类型与产品或服务的业务功能直接关联，且获得信息为最低频率和最少数量采集；搜集个人信息未违背个人信息主体的自主意愿；收集个人信息时获得授权同意；间接获得个人信息时，或为网络公开数据集，或其他方式获得，且遵循获得间接个人信息的规范要求。
30.并且，本申请涉及的技术方案中用户个人信息数据的存储，遵循国家相关法律法规(例如，《信息安全技术个人信息安全规范》等)。如果技术方案涉及下面某种具体操作，则可以进一步选择符合下面对应的处理方式：个人信息存储时间最小化；个人信息已经经过去标识化处理；个人敏感信息加密存储；个人生物信息与个人身份信息分开存储；不存储原始个人生物信息，比如仅存储摘要信息，或者仅对其进行使用，或者使用后删除原始个人生物信息。
31.本技术方案用户数据的使用，遵循国家相关法律法规(例如，《信息安全技术个人信息安全规范》等)。如：个人信息访问控制采取相应规定措施；个人信息的展示给予规定限制；个人信息使用目的没有超出直接或合理关联范围；使用个人信息时消除明确身份指向性，避免精确定位到特定个人。
32.为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
33.语音信箱(或语音留言)可支持如下业务功能中的任意一种或几种：支持传统的交互式语音应答(interactive voice response，ivr)服务，可使网站(或客户端)无缝对接传统ivr语音平台；采用识别率最高的语音技术，特色文语双显技术；灵活设置个性电话提示音，礼貌拒接任何不想接的电话；轻松设置呼叫转移，不再漏掉任何一个来电。当用户使用智能终端(例如，智能手机等)的客户端登录语音信箱时，无须使用注册账号。但在用户使用pc等设备登陆网站时，需要使用注册账号。当智能终端的客户端不在线时，留言消息会以短
信的形式发送到用户的智能终端上，且还会同步到用户的ivr语音平台服务器中。
34.用户可以通过以下两种方式查看留言：1)免费下载并安装语音信箱软件至智能终端上，使用该智能终端中的语音信箱软件查看留言。其中，因使用语音信箱而产生的流量费用由运营商收取(例如，因使用语音信箱而产生的通信资费和直接在智能终端上使用的通信资费一样；或，对语音信箱业务会员，采用包月制收取流量费用)。2)采用带外短信方式，进行客户端与服务器之间的状态查询或留言等，由于带外短信对于智能终端而言是不可见的，智能终端对应的应用(例如，语音信箱app等)可以截取该带外短信，以使服务端能够向客户端推送相关留言数据。
35.由于采用带外短信的方式进行通知，当语音信箱的客户端出现故障时(例如，终端软件冲突或者终端软件崩溃时)，可视化语音信箱服务器会频繁收到智能终端发送的多个上行带外短信，会给通信网络带来不必要的通信压力，易引起用户投诉。
36.针对上述问题，本申请第一方面提供一种故障处理方法。图1示出本申请一实施例中的故障处理方法的流程示意图。该故障处理方法可应用于终端。如图1所示，故障处理方法包括如下步骤：
37.步骤s101，采集当前客户端所在的终端的状态信息。
38.其中，当前客户端可以是语音信箱的应用程序(application，app)，通过在终端上安装语音信箱的app，可使用该app采集其所在的终端的状态信息，
39.其中，状态信息还可以包括终端的名称、终端对应的服务器地址、服务器的端口号等信息中的任意一种或几种。以上对于状态信息仅是举例说明，可根据实际情况进行具体设定，其他未说明的状态信息也在本申请的保护范围之内，在此不再赘述。
40.步骤s102，以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器。
41.需要说明的是，在进行数据通信时，传输层协议中定义了发送重要数据的数据格式，例如，带外数据(out
‑
of
‑
band，oob)格式。如果通信一方有重要的数据需要通知对方时，通过传输层协议可保证将重要数据快速地发送到对方。其中，带外短信是可以是以oob形式发送的短信息，以使基站能够快速获得终端上报的状态信息，并将该状态信息转发至语音信箱服务器。
42.步骤s103，记录状态信息和状态信息的发送频率，生成状态信息集合。
43.其中的发送频率可采用如下方式获得：在预设时长(例如，5秒、10秒等)内，根据发送状态信息的时间信息和该预设时长内发送的状态信息的条数，确定发送频率。通过获得预设时长内的平均发送频率，均衡测量状态信息的发送情况。
44.需要说明的是，状态信息集合中包括多条状态信息，例如可包括n条状态信息，n为大于或等于1的整数。并且，每条状态信息可对应一个发送时间。
45.步骤s104，在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障。
46.其中，预设频率阈值是预先根据历史数据确定的发送频率，例如，可以设定预设频率阈值为10条/秒。
47.需要说明的是，终端在正常工作时，发送频率不会太快，例如，发送频率可以是5条/秒；但当终端发生故障时，发送频率会大于预设频率阈值，例如，当发送频率为20条/秒
(即，发送频率大于10条/秒)时，表征终端可能发生故障，再根据对状态信息集合中的状态信息进行分析，确定状态信息是否正常，是否存在某条或某几条状态信息存在异常情况，进而确定终端是否发生故障。
48.步骤s105，在确定终端发生故障的情况下，停止发送状态信息。
49.例如，当终端上安装的语音信箱app崩溃时，可能导致状态信息中存在异常情况，此时，需要停止发送状态信息给基站，避免基站接收到的状态信息过多，而导致通信资源被浪费，并且使语音信箱服务器接收到大量的无用信息。
50.在一些具体实现中，在确定终端发生故障的情况下，停止发送状态信息，包括：设置状态信息为无效信息，并生成停止发送标识；依据停止发送标识，停止发送状态消息。
51.其中，终端还可以包括发送模块，当发送模块获得停止发送标识时，可将设置为无效信息的状态信息丢弃，不再发送给基站。直至终端的故障被解决时，该停止发送标识被置为无效时，发送模块再恢复状态信息的发送，从而减少终端发送不必要的带外短信。
52.在本实施例中，通过采集当前客户端所在的终端的状态信息，可获知终端的状态(例如，是否存在异常等)；以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器，保证语音信箱服务器能够实时获得终端的状态；记录状态信息和状态信息的发送频率，生成状态信息集合；通过记录状态信息以及状态信息的发送频率，可获知状态信息的上报是否正常(例如，状态信息的发送频率是否过慢或过快等)；在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障；通过发送频率和状态信息确定终端是否存在终端宕机等意外情况发生，保证终端的安全性；在确定终端发生故障的情况下，停止发送状态信息，减少终端发送不必要的带外短信给服务器，提升服务器的业务处理性能，避免用户投诉，提升用户体验。
53.图2示出本申请又一实施例中的故障处理方法的流程示意图。该故障处理方法可应用于终端。如图2所示，故障处理方法包括如下步骤：
54.步骤s201，采集当前客户端所在的终端的状态信息。
55.其中，状态信息还包括终端的位置信息、终端对应的注册用户信息和终端对应的运营商信息中的任意一种或几种。
56.例如，位置信息可以是经纬度信息，也可以是终端所处位置对应的地标建筑的名称等。用户身份识别信息包括用户的身份信息，例如，通过用户身份识别卡(subscriber identity module，sim)所存储的信息，获得的终端对应的用户身份信息，运营商信息包括为终端提供通信服务的运营商的信息，例如，公共陆地移动网(public land mobile network，plmn)信息等。
57.步骤s202，以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器。
58.步骤s203，记录状态信息和状态信息的发送频率，生成状态信息集合。
59.需要说明的是，本实施例中的步骤s202～步骤s203与上一实施例中的步骤s102～步骤s103相同，在此不再赘述。
60.步骤s204，在确定发送频率大于预设频率阈值的情况下，对状态信息集合中的状态信息进行分析，获得分析结果。
61.其中，分析结果包括：状态信息正常或状态信息不正常。当状态信息不正常时，表
征终端可能存在故障，例如，终端中安装的语音信箱app出现崩溃的现象等。若状态信息正常，则表征终端没有出现故障，处于正常工作状态。
62.在一些具体实现中，状态信息集合包括n条状态信息，n为大于或等于1的整数；在确定发送频率大于预设频率阈值的情况下，对状态信息集合中的状态信息进行分析，获得分析结果，包括：在确定发送频率大于预设频率阈值的情况下，提取n条状态信息中的位置信息、注册用户信息和运营商信息中的任意一种或几种；对状态信息集合中的n条状态信息进行分析，确定如下分析结果中的任意一种或几种：对n个位置信息进行分析，获得位置分析结果；对n个注册用户信息进行分析，获得注册用户信息分析结果；对n个运营商信息进行分析，获得运营商信息分析结果。
63.其中，一条状态信息中包括一条位置信息、一条用户身份识别信息和一条运营商信息中的任意一种或几种。在提取n条状态信息中的各种信息时，可获得n条位置信息、n条用户身份识别信息和n条运营商信息中的任意一种或几种。
64.例如，可提取n条位置信息，或，提取n条位置信息和n条用户身份识别信息，或，提取n条用户身份识别信息和n条运营商信息等，通过提取最少的信息，来对终端进行分析，以获得对终端的分析结果。节省分析时间，提升对终端的分析效率。
65.在一些具体实现中，位置信息包括经纬度信息；对n个位置信息进行分析，获得位置分析结果，包括：将n个位置信息进行两两对比，确定n个位置信息中是否存在异常位置，获得位置分析结果；其中，位置分析结果包括：n个位置信息均相同，或，n个位置信息中存在异常位置。
66.通过将n个位置信息进行两两对比，保证对n个位置信息均能验证到，提升对位置信息的验证准确性。当确定位置分析结果是n个位置信息均相同时，表征终端没有发生位移，仍然处于语音信箱服务器的服务范围内。当确定位置分析结果是n个位置信息中存在异常位置信息时，表征终端存在位移，有可能不在语音信箱服务器的服务范围之内，需要语音信箱服务器采取措施，以提高对该终端的服务效果。
67.在一些具体实现中，注册用户信息包括国际移动用户识别号码；对n个注册用户信息进行分析，获得注册用户信息分析结果，包括：提取n个注册用户信息中的任意一个国际移动用户识别号码，并将提取的国际移动用户识别号码作为预设号码；依据预设号码查找n个注册用户信息，确定n个注册用户信息中是否存在与预设号码不同的号码，获得注册用户信息分析结果。
68.通过在n个注册用户信息中，查找是否存在与预设号码不同的号码，在确定n个注册用户信息中的号码都相同时，表征当前终端没有更换用户身份识别卡(subscriber identification module，sim)，注册用户信息分析结果是注册用户信息没有发生变更；否则，若确定n个注册用户信息中存在与预设号码不同的号码，则表征当前终端的注册用户信息已经发生变更。
69.在一些具体实现中，运营商信息包括预设运营商信息；对n个运营商信息进行分析，获得运营商信息分析结果，包括：依据预设运营商信息查找n个运营商信息，确定n个运营商信息是否都相同，获得运营商信息分析结果；其中，运营商信息分析结果包括：n个运营商信息均为预设运营商信息，或，n个运营商信息中存在与预设运营商信息不同的运营商信息。
70.通过在n个运营商信息中查找第一运营商信息或第二运营商信息，确定n个运营商信息所包括的运营商的类型，以确定终端是否存在更换运营商的情况。若获得的运营商信息分析结果是n个运营商信息均为第一运营商信息，或，n个运营商信息均为第二运营商信息，表征该终端没有更换运营商；若获得的运营商信息分析结果是n个运营商信息包括第一运营商信息和第二运营商信息，表征该终端已经更换了运营商，需要调整语音信箱服务器下发消息时所经过的通信路径，以保证终端能够正常接收到语音信箱服务器下发的消息，提升用户体验。
71.步骤s205，依据分析结果，检测终端是否发生故障。
72.其中，若分析结果是状态信息正常，则确定终端没有发生故障；若分析结果是状态信息不正常，则确定终端发生故障。
73.例如，状态信息不正常可以表现为：终端上报的位置信息发生多次变化，或，终端上报的用户身份识别信息存在异常信息，或，运营商信息发生变化(例如，用户从某个服务小区移动到另一个服务小区等)。以上对于状态信息不正常的表现形式仅是举例说明，可根据实际情况进行具体设定，其他未说明的状态信息不正常的表现形式也在本申请的保护范围之内，在此不再赘述。
74.在一些具体实现中，依据分析结果，检测终端是否发生故障，包括：在确定分析结果包括：位置分析结果为n个位置信息均相同、注册用户信息分析结果为n个注册用户信息均相同、且n个运营商信息均相同的情况下，确定终端发生故障；否则，确定终端没有发生故障。
75.通过多维度的分析结果，对终端进行衡量和检测，确定终端是否发生故障，保证对终端的检测准确性。
76.步骤s206，在确定终端发生故障的情况下，停止发送状态信息。
77.需要说明的是，本实施例中的步骤s206与上一实施例中的步骤s105相同，在此不再赘述。
78.在本实施例中，通过多个不同维度的状态信息，对终端进行分析和检测，获得分析结果，并根据该分析结果确定终端是否发生故障，保证对终端的检测准确性。能够在确定终端发生故障的情况下，停止发送状态信息，减少终端发送的带外短信的数量，提升服务器的业务处理性能，避免用户投诉，提升用户体验。
79.本申请第二方面提供一种终端。图3示出本申请实施例中的终端的组成方框图。如图3所示，终端包括如下模块：
80.采集模块301，用于采集当前客户端所在的终端的状态信息；发送模块302，用于以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器；记录模块303，用于记录状态信息和状态信息的发送频率，生成状态信息集合；检测模块304，用于在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障；处理模块305，用于在确定终端发生故障的情况下，停止发送状态信息。
81.在本实施例中，通过采集模块采集当前客户端所在的终端的状态信息，可获知终端的状态；使用发送模块以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器，保证语音信箱服务器能够实时获得终端的状态；使用记录模块记录状态信息和状态信息的发送频率，生成状态信息集合；通过记录状态信息以及状态信息的发
送频率，可获知状态信息的上报是否正常(例如，状态信息的发送频率是否过慢或过快等)；使用检测模块在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障；通过发送频率和状态信息确定终端是否存在终端宕机等意外情况发生，保证终端的安全性；使用处理模块在确定终端发生故障的情况下，停止发送状态信息，减少终端发送不必要的带外短信给服务器，提升服务器的业务处理性能，避免用户投诉，提升用户体验。
82.值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本申请的创新部分，本实施方式中并没有将与解决本申请所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。
83.本申请第三方面提供一种故障处理系统。图4示出本申请实施例中的故障处理系统的组成方框图。如图4所示，故障处理系统具体包括如下设备：终端401、服务器402、基站403和短消息中心服务器404。
84.其中，服务器402需满足交互式邮件存取协议(internet mail access protocol，imap)的接口定义。服务器402还可以访问可视化语音信箱的消息和数据(例如，收取语音消息、设置提示音(greeting)、通过终端的用户界面(user interface，ui)设置个人身份识别码(personal identification number，pin)等)。短消息中心服务器404需提供短信息服务(short message service，sms)接口，sms接口用于收发终端401和服务器402之间的带外数据(out
‑
of
‑
band，oob)，通过该sms接口，服务器402可为终端401提供可视化语音信箱的相关状态信息(例如，收件箱/提示音更新等信息)。当带外状态(out
‑
of
‑
band states，oobs)为活跃(active)状态时，表示服务器402是可用的。当终端401向服务器402发送查询状态信息请求时，服务器402必须返回查询结果给终端401。但终端401不一定能够准时接收到服务器402发送的查询结果，若终端401在超时后，仍没有收到服务器402反馈的查询结果，则终端401需重新发送查询状态信息请求。
85.在一些具体实现中，服务器402还可为终端401提供可用的短消息中心(short message service center，smsc)服务器的地址，终端401通过使用该smsc地址可查询到自己的语音邮箱状态信息。该smsc地址可通过预编程的方式写入终端401中。
86.需要说明的是，终端401上的端口地址的定义应符合短信技术实现协议(即，第三代合作伙伴计划中的技术规范(3rd generation partnership project technical specification，3gpp ts)23.040)中的章节9.2.3.24.3和9.2.3.24.4的定义。例如，终端401发送的sms消息会送达至5499端口，该5499端口仅用于语音信箱业务的消息收发。终端401可通过sms接口，完成oob数据的设置(例如，基础参数的设置、对语音信箱的账户的操作维护信息的设置等)，该oob数据是独立于imap接口的数据。
87.在一些具体实现中，在终端401通过sms接口进行oob数据的设置时，可采用的数据类型为type 0sms，该类型的sms中的短信类型是0或1(即，class＝0或者class＝1的sms)。为了确保该sms在传统的终端上不可见，可将该sms的消息头中的参数“短信协议标识(tp
‑
protocol
‑
identifier，tp
‑
pid)”设置为“me数据下载(me data download)”例如，将tp
‑
pid设置为0x7d。
88.例如，终端401的上行查询指令可以包括：
89.1)首次激活语音信箱按钮时的上行查询指令，该指令包括设备型号(device)、设备类型(type)，例如，type＝1；
90.2)插入手机卡指令，该指令包括device和type，例如，type＝2；
91.3)手机开机指令，该指令包括device和type，例如，type＝3。
92.需要说明的是，当终端401发送已上三种指令中的任意一种时，服务器402都需要返回查询响应。当服务器402没有反馈查询响应时，终端401须将自己的状态设置为离线。
93.当用户的语音信箱账号的状态发生变化时，服务器402将会下发状态(state)消息；同时，终端401也可以向服务器402发送上行查询指令1)～3)中的任意一种。
94.在一个具体实现中，state消息可包括如下关键字段中的任意一种或几种：
95.state<状态信息，例如，active状态，或，非活跃状态(inactive)>
96.name
ꢀꢀꢀꢀꢀꢀ
<imap登录名称>
97.server
ꢀꢀꢀꢀ
<imap服务器地址>
98.port
ꢀꢀꢀꢀꢀꢀ
<imap服务器的端口号>
99.pw
ꢀꢀꢀꢀꢀꢀꢀꢀ
<imap服务器的密码>
100.location
ꢀꢀ
<用户的位置信息，例如，经纬度信息等>
101.newsim
ꢀꢀꢀꢀ
<是否是新的sim的信息>
102.plmn
ꢀꢀꢀꢀꢀꢀ
<用户驻留的运营商的plmn信息>
103.当服务器402接收到的state消息是active状态的消息时，表示语音信箱中的语音消息有更新，或，提示音有更新等信息。
104.图5示出本申请实施例中的故障处理系统的工作方法的流程示意图。如图5所示，故障处理系统的工作方法包括如下步骤：
105.步骤s501，终端401读取自身的位置信息(例如，经纬度信息等)，读取是否新的sim信息，以及确定plmn信息，然后，将以上三种信息写入state消息中。
106.步骤s502，终端401将state消息通过带外短信的方式发送到基站403，以使基站403转发该state消息至服务器402。
107.其中，在消息的转发过程中，该state消息还会经过短消息中心服务器404，以使处于不同网段上的服务器402和终端401能够进行通信。
108.步骤s503，终端401中安装的语音信箱的app记录发送state消息(以带外短信的形式)的发送频率，并监控该发送频率是否超过预设频率阈值。
109.例如，设定预设频率阈值为20条/秒，当终端401检测到发送state短消息的频率大于20条/秒时，确定启动终端401的状态监测判断模块，以使状态监测判断模块对终端401进行判断，该终端401是否存在故障。
110.步骤s504，终端401的状态监测判断模块对发送的每条state短消息进行分析，提取各个state短消息中的终端地理位置信息，以及是否插入新的sim信息，用户注册的运营商网络plmn信息。
111.步骤s505，如果终端401的状态监测判断模块确定发送的每条state短消息中的地理位置信息相同，并且不是插入的新sim卡，也没有注册到新的运营商网络，那么判断该终端401出现故障，故障原因可能为用户终端软件冲突，或者终端软件系统崩溃导致的语音信
箱app发送的带外短信过多，并确定终端401发送的state短消息为无用消息。
112.步骤s506，终端401停止以带外短信的形式，发送上行state短消息。
113.在本实施例中，通过采集当前客户端所在的终端的状态信息，可获知终端的状态(例如，是否存在异常等)；以带外短信的形式发送状态信息至基站，以使基站转发状态信息至语音信箱服务器，保证语音信箱服务器能够实时获得终端的状态；记录状态信息和状态信息的发送频率，生成状态信息集合；通过记录状态信息以及状态信息的发送频率，可获知状态信息的上报是否正常(例如，状态信息的发送频率是否过慢或过快等)；在确定发送频率大于预设频率阈值的情况下，依据状态信息集合中的状态信息，确定终端是否发生故障；通过发送频率和状态信息确定终端是否存在终端上安装的app崩溃等意外情况发生，保证终端的安全性；在确定终端发生故障的情况下，停止发送状态信息，减少终端发送不必要的带外短信给服务器，提升服务器的业务处理性能，避免用户投诉，提升用户体验。
114.可以理解的是，以上实施方式仅仅是为了说明本申请的原理而采用的示例性实施方式，然而本申请并不局限于此。对于本领域内的普通技术人员而言，在不脱离本申请的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本申请的保护范围。