CN113709116A - 通话恢复方法、终端设备及存储介质 - Google Patents

通话恢复方法、终端设备及存储介质 Download PDF

Info

Publication number
CN113709116A
CN113709116A CN202110916916.1A CN202110916916A CN113709116A CN 113709116 A CN113709116 A CN 113709116A CN 202110916916 A CN202110916916 A CN 202110916916A CN 113709116 A CN113709116 A CN 113709116A
Authority
CN
China
Prior art keywords
call service
monitoring timer
call
terminal device
present application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110916916.1A
Other languages
English (en)
Other versions
CN113709116B (zh
Inventor
李欣然
唐帅
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Oppo Mobile Telecommunications Corp Ltd
Original Assignee
Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangdong Oppo Mobile Telecommunications Corp Ltd filed Critical Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority to CN202110916916.1A priority Critical patent/CN113709116B/zh
Publication of CN113709116A publication Critical patent/CN113709116A/zh
Application granted granted Critical
Publication of CN113709116B publication Critical patent/CN113709116B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请实施例公开了一种通话恢复方法、终端设备及存储介质，所述方法包括：当通话业务接通时，启动监控定时器；基于监控定时器的运行时间判断是否满足通话业务的恢复条件；若判定满足通话业务的恢复条件，则向网络设备发送请求信息；其中，请求信息用于恢复通话业务；在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器，并继续基于监控定时器的运行时间执行通话业务的恢复处理，直到接收到网络设备发送的通话业务的RTP包。

Description

通话恢复方法、终端设备及存储介质
技术领域
本发明涉及通信技术领域，尤其涉及一种通话恢复方法、终端设备及存储介质。
背景技术
在IP多媒体系统(IP Multimedia Subsystem，IMS)通话流程中，终端和网络经过协议协商过程会在音频(Audio)端口、Audio媒体方向、编码格式等参数上达成一致，从而可以完成通话的建立。
然而，在业务冲突或者网络异常的场景下，终端设备可能会因为无法接收到RTP包而导致通话无声的异常情况，大大降低了终端设备的可靠性和智能性。
发明内容
本申请实施例提供了一种通话恢复方法、终端设备及存储介质，能够解决通话无声的问题，有效提高终端设备的可靠性和智能性。
本申请实施例的技术方案是这样实现的：
第一方面，本申请实施例提供了一种通话恢复方法，所述方法包括：
当通话业务接通时，启动监控定时器；
基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件；
若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息；其中，所述请求信息用于恢复所述通话业务；
在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的RTP包。
第二方面，本申请实施例提供了一种终端设备，所述终端设备包括：启动单元，判断单元，发送单元，
所述启动单元，用于当通话业务接通时，启动监控定时器；
所述判断单元，用于基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件；
所述发送单元，用于若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息；其中，所述请求信息用于恢复所述通话业务；
所述启动单元，还用于在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的RTP包。
第三方面，本申请实施例提供了一种终端设备，所述终端设备包括处理器、存储有所述处理器可执行指令的存储器，当所述指令被所述处理器执行时，实现如第一方面所述的通话恢复方法。
第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有程序，所述程序被处理器执行时，实现如第一方面所述的通话恢复方法。
本申请实施例提供了一种通话恢复方法、终端设备及存储介质，当通话业务接通时，启动监控定时器；基于监控定时器的运行时间判断是否满足通话业务的恢复条件；若判定满足通话业务的恢复条件，则向网络设备发送请求信息；其中，请求信息用于恢复通话业务；在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器，并继续基于监控定时器的运行时间执行通话业务的恢复处理，直到接收到网络设备发送的通话业务的RTP包。由此可见，在本申请的实施例中，终端设备可以进行监控定时器的设计来监控通话业务的异常情况，从而可以在没有接收到RTP包时通过请求信息的发送来恢复通话业务，进而能够解决通话无声的问题，有效提高终端设备的可靠性和智能性。
附图说明
图1为IMS通话流程的示意图；
图2为未收到下行语音RTP包的处理流程的示意图；
图3为本申请实施例提出的通话恢复方法的实现流程示意图一；
图4为本申请实施例提出的通话恢复方法的实现流程示意图二；
图5为本申请实施例提出的通话恢复方法的实现流程示意图三；
图6为本申请实施例提出的通话恢复方法的实现流程示意图四；
图7为本申请实施例提出的通话恢复方法的实现流程示意图五；
图8为本申请实施例提出的通话恢复方法的实现流程示意图六；
图9为本申请实施例提出的通话恢复方法的实现流程示意图七；
图10为本申请实施例提出的终端设备的组成结构示意图一；
图11为本申请实施例提出的终端设备的组成结构示意图二。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。还需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅是用于区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
IP多媒体系统(IP Multimedia Subsystem，IMS)是一种全新的多媒体业务形式，它能够满足终端客户更新颖、更多样化多媒体业务的需求。图1为IMS通话流程的示意图，如图1所示，以主叫流程为例，在正常的IMS通话流程中，用户设备(User Equipment，UE)向代理呼叫会话控制功能(Proxy-Call Session Control Funtion，P-CSCF)发出会话初始协议(Session Initiation Protocol，SIP)INVITE请求，包含初始描述会话的协议(SessionDescription Protocol，SDP)消息，里面包含具体的媒体信息。接着主叫侧和被叫侧分别进行资源预留、协议协商等过程，具体地，P-CSCF收到INVITE消息时候，需要响应100Trying(临时响应)消息，意味着该消息P-CSCF已经收到被叫侧对INVITE请求进行响应，主叫UE收到P-CSCF发来的183Session Progress，该消息里面携带SDP报文，UE发送PRACK消息进行响应，然后收到被叫侧发来的响应200OK，主叫UE发送Update消息用来更新媒体信息，被叫侧对Update进行响应(200OK)，同样携带更新的媒体信息，接着，被叫侧产生振铃消息(180Ringing)，并且对INVITE消息进行响应(200OK)，主叫收到200OK响应发送ACK进行应答，这个时候通话Session已经建立，最后在完成通话后，结束通话。
一般情况下，终端和网络会在协议协商的过程中，在音频(Audio)端口、Audio媒体方向、编码格式等参数上达成一致。但是，随着运营商业务的增加，各业务间的适配性明显不足。例如，当两个本不兼容的通话相关业务同时开通时，可能会由于兼容性的异常最终导致通话无声的情况。
目前而言，由于业务冲突或者网络异常引起的“协议性”通话无声的场景主要包括以下几种情况：
1)网络将Audio媒体方向设置为非sendrecv导致的双端无声/单项无声；
2)网络将Audio端口置为0；
3)网络未按照约定好的类型(如语音实时传输协议(Real-time TransportProtocol，RTP)有效负载(载荷)类型(payload type)，编码格式等)下包，导致的下行无声问题。
也就是说，在业务冲突或者网络异常的场景下，网络可能存在不按照约定好的参数发送RTP包、自发性改变媒体方向、自发且性关闭媒体端口等异常行为，进而导致通话无声等异常情况。
然而，由于运营商未能及时在业务办理上加以限制，或者未能在基站侧及时做软件更新，导致由于同时办理相互冲突的业务引起更为严重的基本功能使用问题。
进一步的，为了防止终端在无法收到下行语音RTP包的情况下长时间处于接通状态，各运营商都在其白皮书内规定了相应的RTP timer，即一段时间内没有收到下行RTP包，在timer超时后终端应该主动挂断电话。图2为未收到下行语音RTP包的处理流程的示意图，如图2所示，在通话接通之后，终端设备可以持续检测下行语音RTP包，如果在RTP timer之内没有接收到下行语音RTP包，则终端设备主动挂断电话。
通话无声的这类异常问题的根因在于，网络内部处理异常导致其出现错误操作，且网络本身不感知。在这种场景下，网络会出现不下发下行语音RTP包，或者下发无效的语音RTP包(无效的定义为：不符合终端和网络在通话建立协商过程达成一致的RTP包格式参数)的行为。
然而对于通话无声的这类异常问题，目前各终端厂商还没有对应的方案。用户往往会认为是终端有异常，对产品产生极大地质疑，降低产品后续用户回购的可能性；对于运营商而言，很难真正意义上地做到快速反应，快速升级，导致问题长时间存在。
因此，如果在终端侧有良好的“自恢复”方案，对于用户体验以及产品自身竞争力，都有较大地提升。
可见，在业务冲突或者网络异常的场景下，终端设备可能会因为无法接收到RTP包而导致通话无声的异常情况，大大降低了终端设备的可靠性和智能性。而目前的技术方案并不能有效解决这一问题。
为了解决上述问题，在本申请的实施例中，终端设备可以进行监控定时器的设计来监控通话业务的异常情况，从而可以在没有接收到RTP包时通过请求信息的发送来恢复通话业务，进而能够解决通话无声的问题，有效提高终端设备的可靠性和智能性。
在本申请中，终端设备，可以是无线终端设备也可以是有线终端设备，无线终端设备可以是指一种具有无线收发功能的设备，可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。所述终端设备可以是手机(mobile phone)、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(Virtual Reality，VR)终端设备、增强现实(Augmented Reality，AR)终端设备、工业控制(industrial control)中的无线终端设备、无人驾驶(self driving)中的无线终端设备、远程医疗(remote medical)中的无线终端设备、智能电网(smart grid)中的无线终端设备、运输安全(transportation safety)中的无线终端设备、智慧城市(smart city)中的无线终端设备、智慧家庭(smart home)中的无线终端设备等等，在此不作限定。
可以理解的是，本申请实施例中，终端设备也可以称为用户设备(userequipment，UE)。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。
本申请一实施例提供了一种通话恢复方法，图3为本申请实施例提出的通话恢复方法的实现流程示意图一，如图3所示，在本申请的实施例中，终端设备进行通话业务恢复的方法可以包括以下步骤：
步骤101、当通话业务接通时，启动监控定时器。
在本申请的实施例中，当通话业务接通时，终端设备可以先启动监控定时器。
进一步地，在本申请的实施例中，终端设备可以向网络设备发送INVITE消息以进行通话业务；终端设备还可以接收网络设备发送的INVITE消息以进行通话业务。
也就是说，在本申请中，通话业务既可以是主叫的业务，即终端设备向其他终端发起呼叫请求；也可以是被叫的业务，即终端设备接收到其他终端发起的呼叫请求。
进一步地，在本申请的实施例中，监控定时器可以用于对是否在预设时间之内接收到网络设备下发的下行RTP包进行监控。其中，该预设时间可以为监控定时器的运行时间。
可以理解的是，在本申请的实施例中，终端设备可以预先对监控定时器的运行时间进行设置。其中，监控定时器的运行时间即为定时器的触发时间time To Trigger。
需要说明的是，在本申请的实施例中，可以认为终端设备接收到RTP包是指终端设备接收到有效的RTP包。相应地，终端设备无法接收到RTP包可以包括终端设备没有接收到任何RTP包，或者，终端设备接收到的RTP包为无效的RTP包。
可选地，在本申请的实施例中，无效的RTP包即为不符合终端设备和网络设备在通话建立协商过程达成一致的RTP包格式参数的RTP包。
示例性的，终端设备可以根据网络的网络参数设置监控定时器的运行时间。例如，终端设备可以根据网络的信号强度，设置监控定时器的运行时间为3s，即time To Trigger＝3s。
可以理解的是，在本申请的实施例中，终端设备可以称之为用户设备(UserEquipment，UE)。该终端设备可以为个人通信业务(Personal Communication Service，PCS)电话、无绳电话、会话发起协议(Session Initiation Protocol，SIP)话机、无线本地环路(Wireless Local Loop，WLL)站、个人数字助理(Personal Digital Assistant，PDA)等设备，该终端设备也可以为智能手机、平板电脑、掌上电脑、移动台(Mobile Station，MS)、移动终端(Mobile Terminal)等等，该终端设备可以经无线接入网(Radio AccessNetwork，RAN)与一个或多个网络设备进行通信。例如，终端设备可以是移动电话(或称为“蜂窝”电话)或具有终端设备的计算机等，例如，终端设备还可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语音和/或数据。终端设备还可以为有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，未来演进的网络中的终端设备等，本申请实施不作限定。
需要说明的是，在本申请的实施例中，网络设备是一种为终端设备提供无线通信功能的设备，包括但不限于：长期演进(Long-Term Evolution，LTE)系统、新空口(NewRadio，NR)系统或者授权辅助接入长期演进(Licensed-Assisted Access using Long-Term Evolution，LAA-LTE)系统中的演进型基站(evolutional Node B，可简称为eNB或e-NodeB)、宏基站、微基站(也可称为“小基站”)、微微基站、基站收发台(Base TransceiverStation，BTS)、基带单元(Base Band Unit，BBU)、接入站点(Access Point，AP)、传输站点(Transmission Point，TP)或新一代基站(new generation Node B，gNodeB)等。
步骤102、基于监控定时器的运行时间判断是否满足通话业务的恢复条件。
在本申请的实施例中，当通话业务接通时，终端设备在启动监控定时器之后，可以基于监控定时器的运行时间对是否满足通话业务的恢复条件进行判断。
需要说明的是，在本申请的实施例中，通话业务的恢复条件可以用于确定通话业务是否存在异常。
进一步地，在本申请的实施例中，在进行通话业务满足通话业务的恢复条件的判断时，如果在监控定时器的运行时间之内没有接收到RTP包，那么终端便可以认为通话业务存在异常，进而可以判定满足通话业务的恢复条件。
相应地，在本申请的实施例中，在进行通话业务满足通话业务的恢复条件的判断时，如果在监控定时器的运行时间之内能够接收到RTP包，那么终端便可以认为通话业务不存在异常，进而可以判定不满足通话业务的恢复条件。
需要说明的是，在本申请的实施例中，在多种异常场景下终端设备均可能无法接收到下行RTP包，例如，协议性错误的异常场景，信号差的异常场景、对端上行异常的异常场景等。
步骤103、若判定满足通话业务的恢复条件，则向网络设备发送请求信息；其中，请求信息用于恢复通话业务。
在本申请的实施例中，在本申请的实施例中，在基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件之后，如果终端设备确定通话业务存在异常，即判定满足通过业务的恢复条件，那么终端设备可以向网络设备发送用于恢复所述通话业务的请求信息。
可以理解的是，在本申请的实施例中，对于无法接收到下发的下行RTP包的异常情况，在确定满足通话业务的恢复条件之后，终端设备可以不再继续等待下行RTP包，而是选择主动向网络设备发送请求信息，以恢复该通话业务。
需要是说明的是，在本申请的实施例中，终端设备发送的请求信息可以用于对通话业务进行会话刷新，从而可以与网络设备重新进行媒体协商，进而可以实现对通话业务的异常情况的解决。
可选地，在本申请的实施例中，在进行请求信息的主动发送时，终端设备可以选择主动发起re-INVITE消息，或者，终端设备可以选择主动发起UPDATE请求。
可以理解的是，在本申请的实施例中，终端设备可以通过请求信息的发送与网络设备重新进行媒体协商。在完成协商之后，终端设备和网络设备均可以按照重新协商的各参数继续进行交互，从而解决网络设备没有下发RTP包给终端设备，导致终端设备通话无声的问题。
进一步地，在本申请的实施例中，图4为本申请实施例提出的通话恢复方法的实现流程示意图二，如图4所示，在基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件之后，即步骤102之后，终端设备进行通话业务恢复的方法还可以包括以下步骤：
步骤105、若判定不满足通话业务的恢复条件，则关闭监控定时器，并基于RTP包建立通话业务的通话。
在本申请的实施例中，在基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件之后，如果终端设备确定通话业务不存在异常，即判定不满足通过业务的恢复条件，那么终端设备选择关闭监控定时器，同时可以基于RTP包建立所述通话业务的通话。
进一步地，在本申请的实施例中，如果在所述监控定时器的运行时间之内接收到所述RTP包，即判定不满足通过业务的恢复条件，那么终端设备便可以基于接收到的下行RTP包针对该通话业务进行通话的建立。
步骤104、在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器，并继续基于监控定时器的运行时间执行通话业务的恢复处理，直到接收到网络设备发送的通话业务的RTP包。
在本申请的实施例中，当判定满足所述通话业务的恢复条件，并向网络设备发送请求信息之后，终端设备可以在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的RTP包。
进一步地，在本申请的实施例中，终端设备在向网络设备发送用于恢复所述通话业务的请求信息之后，如果获取到网络设备对该请求消息的响应，即接收到请求信息对应的响应信息，例如接收到网络设备发送的200OK消息，那么终端设备便可以选择重启监控定时器，并重新利用监控定时器的运行时间进行是否满足所述通话业务的恢复条件的判断。
可以理解的是，在本申请的实施例中，终端设备在重新启动监控定时器之后，如果在监控定时器的运行时间之内能够获取到网络设备下发的下行RTP包，则可以选择基于该RTP包针对该通话业务进行通话的建立；如果在监控定时器的运行时间之内无法接收到网络设备下发的下行RTP包，即再次判定满足所述通话业务的恢复条件，那么终端设备可以重新向网络设备发送用于恢复所述通话业务的请求信息。
也就是说，在本申请的实施例中，如果终端设备没有在监控定时器的运行时间之内接收到网络设备下发的下行RTP包，那么终端设备可以通过发送请求消息来进行通话业务的恢复，即不断地进行监控定时器的重启，以对是否在运行时间之内成功接收到下行RTP包进行监控，即循环执行步骤102至步骤104所提出的通话恢复方法，直到能够获取到该通话业务的RTP包。
进一步地，在本申请的实施例中，图5为本申请实施例提出的通话恢复方法的实现流程示意图三，如图5所示，在基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件之前，即步骤102之前，终端设备进行通话业务恢复的方法还可以包括以下步骤：
步骤106、当通话业务接通时，启动计数器。
在本申请的实施例中，当通话业务接通时，终端设备还可以启动计数器。
需要说明的是，在本申请的实施例中，计数器可以用于记录监控定时器的重启次数。具体地，终端设备在启动计数器时可以将计数器的数值初始化为0，即可以表征监控定时器还没有被重启过。
进一步地，在本申请的实施例中，终端设备可以针对监控定时器的重启处理预先设置一个次数阈值，即预设重启阈值，该预设重启阈值可以对监控定时器的重启次数进行限制。
可选地，在本申请的实施例中，终端设备可以将预设重启阈值设备为大于0的整数，例如，设置预设重启阈值为5。
进一步地，在本申请的实施例中，图6为本申请实施例提出的通话恢复方法的实现流程示意图四，如图6所示，在若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息之后，即步骤103之后，终端设备进行通话业务恢复的方法还可以包括以下步骤：
步骤107、在接收到网络设备发送的请求信息对应的响应信息之后，对计数器的数值进行加1处理。
在本申请的实施例中，当判定满足所述通话业务的恢复条件，并向网络设备发送请求信息之后，终端设备可以在接收到所述网络设备发送的所述请求信息对应的响应信息之后，对计数器的数值进行加1处理。
可以理解的是，在本申请的实施例中，由于终端设备可以在接收到所述网络设备发送的所述请求信息对应的响应信息之后便可以执行重启监控定时器的处理，因此，终端设备可以同时更新用于记录监控定时器的重启次数的计数器的数值，即对计数器的数值进行加1处理。
相应地，在本申请的实施例中，在进行通话业务满足通话业务的恢复条件的判断时，如果在所述监控定时器的运行时间之内未接收到所述RTP包，同时计数器的数值小于或者等于预设重启阈值，那么可以判定满足所述通话业务的恢复条件。
需要说明的是，在本申请的实施例中，如果终端设备在监控定时器的运行时间之内未接收到所述RTP包，且计数器的数值小于或者等于预设重启阈值，即监控定时器的重启次数并没有超出预设重启阈值，那么终端设备便可以确定满足通话业务的恢复条件。
相应地，在本申请的实施例中，如果终端设备在监控定时器的运行时间之内已经接收到所述RTP包，或者，计数器的数值大于预设重启阈值，即监控定时器的重启次数已经超出预设重启阈值，那么终端设备便可以确定不满足通话业务的恢复条件。
也就是说，在本申请的实施例中，在进行是否满足恢复条件的判断时，一方面需要考虑是否存在异常情况，即确定是否能够接收到网络设备下发的下行RTP包；另一方面还需要考虑从是否超出了重启监控定时器的限制次数，即确定计数器的数值是否大于预设重启阈值。
可以理解的是，在本申请的实施例中，如果重启监控定时器的次数已经超出了预设重启阈值，那么可以认为重启监控定时器并不能有效解决无法接收到RTP包的问题，因此可以认为不满足通话业务的恢复条件。
也就是说，在本申请的实施例中，即使确定终端设备在所述监控定时器的运行时间之内未接收到所述RTP包，即存在异常情况有恢复该通话业务的需求，但是只要重启监控定时器的次数已经超出了预设重启阈值，便可以认为不满足通话业务的恢复条件。
可选地，在本申请的实施例中，将设预设重启阈值设置为5，那么在计数器的数值大于5之后，终端设备便不再进行监控定时器的重启处理。
进一步地，在本申请的实施例中，图7为本申请实施例提出的通话恢复方法的实现流程示意图五，如图7所示，在基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件之前，即步骤102之前，终端设备进行通话业务恢复的方法还可以包括以下步骤：
步骤108、当通话业务接通时，启动计时器。
在本申请的实施例中，当通话业务接通时，终端设备还可以先启动计时器。
可以理解的是，在本申请的实施例中，计时器可以用于对通话业务接通之后的持续时间进行记录。
进一步地，在本申请的实施例中，如果确定计数器的数值大于预设重启阈值，那么终端设备便不再进行监控定时器的重启，此时，如果在所述计时器的记录时间大于预设时间阈值时仍然没有接收到所述RTP包，那么终端设备便可以关闭所述监控定时器，并结束所述通话业务。
需要说明的是，在本申请的实施例中，为了避免终端设备在无法收到下行RTP包的情况下长时间处于接通状态，可以预先设置一个时间上限值，即预设时间阈值。具体地，如果在预设时间阈值之内没有接收到下行RTP包，即在计时器记录的时间已经超出预设时间阈值时未接收到下行RTP包，终端设备可以选择主动挂断电话，从而结束该通话业务。
可选地，在本申请的实施例中，预设时间阈值可以大于监控定时器的运行时间。例如，假设预设时间阈值为n秒，监控定时器的运行时间为m秒，那么可以设置n>2m>0，从而可以保证在执行至少一次监控定时器的重启处理之后再结束通话业务。
综上所述，在本申请的实施例中，通过上述步骤101至步骤108提出的通话恢复方法，终端设备在发起/收到呼叫，通话业务接通之后开启监控定时器；若在监控定时器超时前终端设备没收到网络设备下发的下行语音RTP包，则在监控定时器超时后主动发起Re-INVITE或者UPDATE请求，其中携带终端设备的全能力与网络设备进行能力同步更新；更新后收到网络的200OK消息，此时重新启动监控定时器，若在监控定时器超时前终端设备仍然没收到网络设备下发的下行语音RTP包，那么终端设备可以选择重复执行上述通话业务的恢复流程，直到在监控定时器超时前接收到RTP包，从而有效解决没有接收到RTP包所造成的通话无声的问题。
进一步地，本申请提出的通话恢复方法，针对在通话建立过程中，各种异常导致的没收到语音RTP包造成的通话建立受阻场景，终端设备都可以考虑通过添加监控定时器进行优化，从而保证语音业务的成功建立。
本申请实施例提供了一种通话恢复方法，当通话业务接通时，启动监控定时器；基于监控定时器的运行时间判断是否满足通话业务的恢复条件；若判定满足通话业务的恢复条件，则向网络设备发送请求信息；其中，请求信息用于恢复通话业务；在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器，并继续基于监控定时器的运行时间执行通话业务的恢复处理，直到接收到网络设备发送的通话业务的RTP包。由此可见，在本申请的实施例中，终端设备可以进行监控定时器的设计来监控通话业务的异常情况，从而可以在没有接收到RTP包时通过请求信息的发送来恢复通话业务，进而能够解决通话无声的问题，有效提高终端设备的可靠性和智能性。
基于上述实施例，本申请的再一实施例提出了一种通话恢复方法，能够针对网络设备不下发下行语音RTP包而导致终端设备通话无声的场景，提出了一种快速恢复的方案，从而可以解决由网络“协议性错误”造成的通话无声问题。
需要说明的是，本申请实施例提出的通话恢复方法，终端设备可以设计一个下行RTP包的监控定时器TDL_RTP_CHECK，在TDL_RTP_CHECK定时器周期内，即监控定时器TDL_RTP_CHECK的运行时间以内，终端设备检测到没有收到任何下行语音RTP包，或者没有收到任何一个有效语音RTP包时，便可以主动发起re-INVITE或者UPDATE请求，用以对通话业务进行恢复处理。
进一步地，在本申请的实施例中，在主动发起re-INVITE或者UPDATE请求之后，终端设备可以选择重新启动监控定时器TDL_RTP_CHECK，从而可以继续通过监控定时器TDL_RTP_CHECK进行通话业务的恢复。
可以理解的是，在本申请的实施例中，终端设备还可以设计一个计时器RTPTimer。其中，监控定时器TDL_RTP_CHECK与RTP Timer可以在通话业务接通时同时启动，但是配置的监控定时器TDL_RTP_CHECK的运行时间小于RTP Timer对应的预设时间阈值。
进一步地，在本申请的实施例中，在监控定时器TDL_RTP_CHECK的运行时间内，终端检测到没有收到任何下行语音RTP包，或者没有收到任何一个有效语音RTP包，就会主动发起re-INVITE或者UPDATE请求，然后重启监控定时器TDL_RTP_CHECK，并基于重启监控定时器TDL_RTP_CHECK循环进行是否接收到有效语音RTP包或下行语音RTP包的监控，如果在计时器RTPTimer到达预设时间阈值之后仍然没有接收到有效语音RTP包或下行语音RTP包。那么终端设备可以选择主动结束该通话业务。
需要说明的是，在本申请的实施例中，终端设备还可以设计一个计数器，该计数器可以用于记录监控定时器TDL_RTP_CHECK的重启次数，即每重启一次监控定时器TDL_RTP_CHECK，终端设备需要对计数器的数值进行加1处理，从而可以结合预设重启阈值对重启监控定时器TDL_RTP_CHECK的处理进行限制。
进一步地，在本申请的实施例中，在重启监控定时器TDL_RTP_CHECK之前，终端设备可以先确定计数器的数值是否超出预设重启阈值，从而可以进一步确定是否重启重启监控定时器TDL_RTP_CHECK。
可以理解的是，在本申请的实施例中，如果终端设备重启监控定时器TDL_RTP_CHECK的次数已经超出预设重启阈值，那么可以认为通过监控定时器TDL_RTP_CHECK的重启处理无法解决不能接收到有效语音RTP包或下行语音RTP包的问题，因此便可以选择不再执行监控定时器TDL_RTP_CHECK的重启处理。
进一步地，在本申请的实施例中，终端设备可以通过发起re-INVITE或者UPDATE请求进行会话刷新，和网络设备重新进行媒体协商。在协商完毕后，终端设备和网络设备都会按照新协商的各参数继续进行交互。
也就是说，在本申请的实施例中，当TDL_RTP_CHECK定时器超时时，终端设备主动发起用于与网络重新协商能力的re-INVITE或者UPDATE请求，从而可以通过这种方式解决由于网络内部自身交互异常没有给终端设备下发RTP包所导致的终端设备通话无声的问题。
可选地，在本申请的实施例中，图8为本申请实施例提出的通话恢复方法的实现流程示意图六，如图8所示，终端设备进行通话业务恢复的方法可以包括以下步骤：
步骤201、当通话业务接通时，启动监控定时器和计时器。
在本申请的实施例中，当通话业务接通时，终端设备可以先分别启动监控定时器和计时器。
进一步地，在本申请的实施例中，通话业务既可以是主叫的业务，即终端设备向其他终端发起呼叫请求；也可以是被叫的业务，即终端设备接收到其他终端发起的呼叫请求。
示例性的，在本申请的实施例中，监控定时器可以用于监控在运行时间之内是否接收到网络设备下发的下行RTP包。
示例性的，在本申请的实施例中，计时器可以用于对通话业务接通之后的持续时间进行记录。
步骤202、判断是否满足在监控定时器的运行时间之内接收到RTP包？如果满足，则执行步骤203，否则执行步骤204。
在本申请的实施例中，在启动监控定时器之后，可以监控在监控定时器的运行时间之内是否可以接收到RTP包。
步骤203、关闭监控定时器，并基于RTP包建立通话业务的通话。
在本申请的实施例中，如果在监控定时器的运行时间之内接收到RTP包，那么终端设备可以关闭监控定时器，并基于RTP包建立通话业务的通话。
步骤204、判断是否满足计时器记录的时间超出预设时间阈值？如果满足，则执行步骤205，否则执行步骤206。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，那么终端设备可以进一步确定计时器记录的时间，并判断该时间是否超出预设时间阈值。
需要说明的是，在本申请的实施例中，为了避免终端设备在无法收到下行RTP包的情况下长时间处于接通状态，可以预先设置一个时间上限值，即预设时间阈值。
可选地，在本申请的实施例中，预设时间阈值可以大于监控定时器的运行时间。例如，假设预设时间阈值为10秒，监控定时器的运行时间为3秒。
步骤205、结束通话业务。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，且计时器记录的时间超出预设时间阈值，即在预设时间阈值之内没有接收到下行RTP包，那么终端设备可以选择主动挂断电话，从而结束该通话业务。
步骤206、向网络设备发送请求信息。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，且计时器记录的时间没有超出预设时间阈值，那么终端设备可以选择对通话业务进行恢复处理。具体地，终端设备可以先向网络设备发送请求信息。
可以理解的是，在本申请的实施例中，对于无法接收到下发的下行RTP包的异常情况，终端设备可以不再继续等待下行RTP包，而是选择主动向网络设备发送用于恢复所述通话业务的请求信息。
步骤207、在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器。
在本申请的实施例中，在向网络设备发送请求信息之后，终端设备可以在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，即循环执行步骤202至步骤207。
可选地，在本申请的实施例中，图9为本申请实施例提出的通话恢复方法的实现流程示意图七，如图9所示，终端设备进行通话业务恢复的方法可以包括以下步骤：
步骤208、当通话业务接通时，启动监控定时器、计时器、计数器。
在本申请的实施例中，当通话业务接通时，终端设备可以先分别启动监控定时器、计时器、计数器。
示例性的，在本申请的实施例中，计数器可以用于记录监控定时器的重启次数。具体地，终端设备在启动计数器时可以将计数器的数值初始化为0，即可以表征监控定时器还没有被重启过。
步骤202、判断是否满足在监控定时器的运行时间之内接收到RTP包？如果满足，则执行步骤203，否则执行步骤209。
在本申请的实施例中，在启动监控定时器之后，可以监控在监控定时器的运行时间之内是否可以接收到RTP包。
步骤203、关闭监控定时器，并基于RTP包建立通话业务的通话。
在本申请的实施例中，如果在监控定时器的运行时间之内接收到RTP包，那么终端设备可以关闭监控定时器，并基于RTP包建立通话业务的通话。
步骤209、判断是否满足计数器的数值大于预设重启阈值？如果满足，则执行步骤204，否则执行步骤210。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，那么终端设备可以进一步确定计数器的数值，并判断该数值是否超出预设重启阈值。
可选地，在本申请的实施例中，预设重启阈值可以对监控定时器的重启次数进行限制。终端设备可以将预设重启阈值设备为大于0的整数，例如，设置预设重启阈值为5。
步骤204、判断是否满足计时器记录的时间超出预设时间阈值？如果满足，则执行步骤205，否则循环执行步骤204。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，且计数器的数值大于预设重启阈值，那么终端设备可以进一步确定计时器记录的时间，并判断该时间是否超出预设时间阈值。
可以理解的是，在本申请的实施例中，如果重启监控定时器的次数已经超出了预设重启阈值，那么可以认为重启监控定时器并不能有效解决无法接收到RTP包的问题，因此可以选择不再进行监控定时器的重启处理。
步骤205、结束通话业务。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，且计数器的数值大于预设重启阈值，且计时器记录的时间超出预设时间阈值，那么终端设备可以选择主动挂断电话，从而结束该通话业务。
步骤210、对计数器的数值进行加1处理。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，且计数器的数值没有超过预设重启阈值，那么终端设备可以对计数器的数值进行加1处理。
步骤206、向网络设备发送请求信息。
在本申请的实施例中，如果在监控定时器的运行时间之内没有接收到RTP包，且计时器记录的时间没有超出预设时间阈值，那么终端设备可以选择对通话业务进行恢复处理。具体地，终端设备可以先向网络设备发送请求信息。
可以理解的是，在本申请的实施例中，对于无法接收到下发的下行RTP包的异常情况，终端设备可以不再继续等待下行RTP包，而是选择主动向网络设备发送用于恢复所述通话业务的请求信息。
步骤207、在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器。
在本申请的实施例中，在向网络设备发送请求信息之后，终端设备可以在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，即循环执行步骤202至步骤210。
综上所述，通过步骤201至步骤210所提出的通话业务的恢复方法，终端设备在发起/收到呼叫，通话业务接通之后开启监控定时器；若在监控定时器超时前终端设备没收到网络设备下发的下行语音RTP包，则在监控定时器超时后主动发起Re-INVITE或者UPDATE请求，其中携带终端设备的全能力与网络设备进行能力同步更新；更新后收到网络的200OK消息，此时重新启动监控定时器，若在监控定时器超时前终端设备仍然没收到网络设备下发的下行语音RTP包，那么终端设备可以选择重复执行上述通话业务的恢复流程，直到在监控定时器超时前接收到RTP包，从而有效解决没有接收到RTP包所造成的通话无声的问题。
需要说明的是，在本申请的实施例中，终端设备还可以在通话业务接通之后选择开启计数器，该计数器用于记录监控定时器的重启次数。从而可以在预设重启阈值的限制下进行监控定时器的重启处理。如果在监控定时器的重启次数超出预设重启阈值的情况下仍然无法接收到RTP包，则可以确定无法恢复网络异常，终端设备便不再发起监控定时器的重启处理。
进一步地，在本申请的实施例中，为了避免终端设备在无法收到下行RTP包的情况下长时间处于接通状态，可以限定在预设时间阈值之内如果没有接收到RTP包，终端设备便主动挂断电话，从而结束该通话业务。
进一步地，本申请实施例提出的通话业务的恢复方法，能够在不影响正常的通话行为，且用户不感知的基础上，解决无法接收到RTP包所造成的通话无声的问题。
需要说明的是，在本申请的实施例中，在多种异常场景下终端设备均可能无法接收到下行RTP包，例如，协议性错误的异常场景，信号差的异常场景、对端上行异常的异常场景等。其中，通过实施例提出的通话业务的恢复方法，对于协议性错误所引起的通话无声的问题一般在一次参数重新协商后便可以得到解决，对于非协议性错误所引起的通话无声的问题一般在至少一次参数重新协商后便可以得到解决。
本申请实施例提供了一种通话恢复方法，当通话业务接通时，启动监控定时器；基于监控定时器的运行时间判断是否满足通话业务的恢复条件；若判定满足通话业务的恢复条件，则向网络设备发送请求信息；其中，请求信息用于恢复通话业务；在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器，并继续基于监控定时器的运行时间执行通话业务的恢复处理，直到接收到网络设备发送的通话业务的RTP包。由此可见，在本申请的实施例中，终端设备可以进行监控定时器的设计来监控通话业务的异常情况，从而可以在没有接收到RTP包时通过请求信息的发送来恢复通话业务，进而能够解决通话无声的问题，有效提高终端设备的可靠性和智能性。
基于上述实施例，在本申请的另一实施例中，图10为本申请实施例提出的终端设备的组成结构示意图一，如图10所示，本申请实施例提出的终端设备10可以包括启动单元11，判断单元12，发送单元13，关闭单元14，建立单元15，处理单元16，
所述启动单元11，用于当通话业务接通时，启动监控定时器；
所述判断单元12，用于基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件；
所述发送单元13，用于若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息；其中，所述请求信息用于恢复所述通话业务；
所述启动单元11，还用于在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的RTP包。
进一步地，在本申请的实施例中，所述判断单元12，具体用于若在所述监控定时器的运行时间之内未接收到所述RTP包，则判定满足所述通话业务的恢复条件。
进一步地，在本申请的实施例中，所述关闭单元14，用于所述基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件之后，若判定不满足所述通话业务的恢复条件，则关闭所述监控定时器；
所述建立单元15，用于基于所述RTP包建立所述通话业务的通话。
进一步地，在本申请的实施例中，所述启动单元11，还用于当所述通话业务接通时，启动计数器；其中，所述计数器用于记录所述监控定时器的重启次数。
进一步地，在本申请的实施例中，所述处理单元16，用于所述若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息之后，在接收到所述网络设备发送的所述请求信息对应的响应信息之后，对所述计数器的数值进行加1处理。
进一步地，在本申请的实施例中，所述判断单元12，还具体用于若在所述监控定时器的运行时间之内未接收到所述RTP包，且所述计数器的数值小于或者等于预设重启阈值，则判定满足所述通话业务的恢复条件。
进一步地，在本申请的实施例中，所述启动单元11，还用于当所述通话业务接通时，启动计时器。
进一步地，在本申请的实施例中，所述关闭单元14，还用于当所述计数器的数值大于预设重启阈值时，若在所述计时器的记录时间大于预设时间阈值时未接收到所述RTP包，则关闭所述监控定时器；
所述结束单元17，用于结束所述通话业务。
在本申请的实施例中，进一步地，图11为本申请实施例提出的终端设备的组成结构示意图二，如图11所示，本申请实施例提出的终端设备10还可以包括处理器18、存储有处理器18可执行指令的存储器19，进一步地，终端设备10还可以包括通信接口110，和用于连接处理器18、存储器19以及通信接口110的总线111。
在本申请的实施例中，上述处理器18可以为特定用途集成电路(ApplicationSpecific Integrated Circuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(Digital Signal Processing Device，DSPD)、可编程逻辑装置(ProgRAMmable Logic Device，PLD)、现场可编程门阵列(Field ProgRAMmable GateArray，FPGA)、中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。终端设备10还可以包括存储器19，该存储器19可以与处理器18连接，其中，存储器19用于存储可执行程序代码，该程序代码包括计算机操作指令，存储器19可能包含高速RAM存储器，也可能还包括非易失性存储器，例如，至少两个磁盘存储器。
在本申请的实施例中，总线111用于连接通信接口110、处理器18以及存储器19以及这些器件之间的相互通信。
在本申请的实施例中，存储器19，用于存储指令和数据。
进一步地，在本申请的实施例中，上述处理器18，用于当通话业务接通时，启动监控定时器；基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件；若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息；其中，所述请求信息用于恢复所述通话业务；在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的RTP包。
在实际应用中，上述存储器19可以是易失性存储器(volatile memory)，例如随机存取存储器(Random-Access Memory，RAM)；或者非易失性存储器(non-volatile memory)，例如只读存储器(Read-Only Memory，ROM)，快闪存储器(flash memory)，硬盘(Hard DiskDrive，HDD)或固态硬盘(Solid-State Drive，SSD)；或者上述种类的存储器的组合，并向处理器18提供指令和数据。
另外，在本实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请实施例提供了一种终端设备，当通话业务接通时，启动监控定时器；基于监控定时器的运行时间判断是否满足通话业务的恢复条件；若判定满足通话业务的恢复条件，则向网络设备发送请求信息；其中，请求信息用于恢复通话业务；在接收到网络设备发送的请求信息对应的响应信息之后，重启监控定时器，并继续基于监控定时器的运行时间执行通话业务的恢复处理，直到接收到网络设备发送的通话业务的RTP包。由此可见，在本申请的实施例中，终端设备可以进行监控定时器的设计来监控通话业务的异常情况，从而可以在没有接收到RTP包时通过请求信息的发送来恢复通话业务，进而能够解决通话无声的问题，有效提高终端设备的可靠性和智能性。
本申请实施例提供一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现如上所述的通话恢复方法。
具体来讲，本实施例中的一种通话恢复方法对应的程序指令可以被存储在光盘，硬盘，U盘等存储介质上，当存储介质中的与一种通话恢复方法对应的程序指令被一电子设备读取或被执行时，包括如下步骤：
当通话业务接通时，启动监控定时器；
基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件；
若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息；其中，所述请求信息用于恢复所述通话业务；
在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的RTP包。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的实现流程示意图和/或方框图来描述的。应理解可由计算机程序指令实现流程示意图和/或方框图中的每一流程和/或方框、以及实现流程示意图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在实现流程示意图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在实现流程示意图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在实现流程示意图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims (11)

1.一种通话恢复方法，其特征在于，所述方法包括：
当通话业务接通时，启动监控定时器；
基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件；
若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息；其中，所述请求信息用于恢复所述通话业务；
在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的实时传输协议RTP包。
2.根据权利要求1所述的方法，其特征在于，所述基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件，包括：
若在所述监控定时器的运行时间之内未接收到所述RTP包，则判定满足所述通话业务的恢复条件。
3.根据权利要求2所述的方法，其特征在于，所述基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件之后，所述方法还包括：
若判定不满足所述通话业务的恢复条件，则关闭所述监控定时器，并基于所述RTP包建立所述通话业务的通话。
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
当所述通话业务接通时，启动计数器；其中，所述计数器用于记录所述监控定时器的重启次数。
5.根据权利要求4所述的方法，其特征在于，所述若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息之后，所述方法还包括：
在接收到所述网络设备发送的所述请求信息对应的响应信息之后，对所述计数器的数值进行加1处理。
6.根据权利要求4或5所述的方法，其特征在于，所述基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件，包括：
若在所述监控定时器的运行时间之内未接收到所述RTP包，且所述计数器的数值小于或者等于预设重启阈值，则判定满足所述通话业务的恢复条件。
7.根据权利要求4所述的方法，其特征在于，所述方法还包括：
当所述通话业务接通时，启动计时器。
8.根据权利要求7所述的方法，其特征在于，所述方法还包括：
当所述计数器的数值大于预设重启阈值时，若在所述计时器的记录时间大于预设时间阈值时未接收到所述RTP包，则关闭所述监控定时器，并结束所述通话业务。
9.一种终端设备，其特征在于，所述终端设备包括：启动单元，判断单元，发送单元，
所述启动单元，用于当通话业务接通时，启动监控定时器；
所述判断单元，用于基于所述监控定时器的运行时间判断是否满足所述通话业务的恢复条件；
所述发送单元，用于若判定满足所述通话业务的恢复条件，则向网络设备发送请求信息；其中，所述请求信息用于恢复所述通话业务；
所述启动单元，还用于在接收到所述网络设备发送的所述请求信息对应的响应信息之后，重启所述监控定时器，并继续基于所述监控定时器的运行时间执行所述通话业务的恢复处理，直到接收到所述网络设备发送的所述通话业务的RTP包。
10.一种终端设备，其特征在于，所述终端设备包括处理器、存储有所述处理器可执行指令的存储器，当所述指令被所述处理器执行时，实现如权利要求1-8任一项所述的方法。
11.一种计算机可读存储介质，其上存储有程序，其特征在于，所述程序被处理器执行时，实现如权利要求1-8任一项所述的方法。
CN202110916916.1A 2021-08-11 2021-08-11 通话恢复方法、终端设备及存储介质 Active CN113709116B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110916916.1A CN113709116B (zh) 2021-08-11 2021-08-11 通话恢复方法、终端设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110916916.1A CN113709116B (zh) 2021-08-11 2021-08-11 通话恢复方法、终端设备及存储介质

Publications (2)

Publication Number Publication Date
CN113709116A true CN113709116A (zh) 2021-11-26
CN113709116B CN113709116B (zh) 2023-09-26

Family

ID=78652376

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110916916.1A Active CN113709116B (zh) 2021-08-11 2021-08-11 通话恢复方法、终端设备及存储介质

Country Status (1)

Country Link
CN (1) CN113709116B (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101026658A (zh) * 2006-02-24 2007-08-29 英保达股份有限公司 异常断线后恢复通话的网络电话系统及其方法
JP2009164841A (ja) * 2007-12-28 2009-07-23 Kddi R & D Laboratories Inc グループ通信におけるメディア切替方法、セッション管理サーバ、端末及びプログラム
EP2279603A1 (de) * 2008-05-27 2011-02-02 Gigaset Communications GmbH Vorrichtung und verfahren zur neuverhandlung einer multimediaverbindung sowie zugehöriges kommunikationssystem, digitales speichermedium, computer-programm-produkt und computerprogramm
CN109769262A (zh) * 2019-03-25 2019-05-17 维沃移动通信有限公司 VoLTE通话恢复的方法和终端设备
CN111800545A (zh) * 2020-06-24 2020-10-20 Oppo（重庆）智能科技有限公司 终端通话状态检测方法、装置、终端及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101026658A (zh) * 2006-02-24 2007-08-29 英保达股份有限公司 异常断线后恢复通话的网络电话系统及其方法
JP2009164841A (ja) * 2007-12-28 2009-07-23 Kddi R & D Laboratories Inc グループ通信におけるメディア切替方法、セッション管理サーバ、端末及びプログラム
EP2279603A1 (de) * 2008-05-27 2011-02-02 Gigaset Communications GmbH Vorrichtung und verfahren zur neuverhandlung einer multimediaverbindung sowie zugehöriges kommunikationssystem, digitales speichermedium, computer-programm-produkt und computerprogramm
CN109769262A (zh) * 2019-03-25 2019-05-17 维沃移动通信有限公司 VoLTE通话恢复的方法和终端设备
CN111800545A (zh) * 2020-06-24 2020-10-20 Oppo（重庆）智能科技有限公司 终端通话状态检测方法、装置、终端及存储介质

Also Published As

Publication number Publication date
CN113709116B (zh) 2023-09-26

Similar Documents

Publication Publication Date Title
US10856141B2 (en) Security protection negotiation method and network element
JP6101304B2 (ja) 通話セッションを移行するためのネットワーク選択用のシステムと方法
US10051017B2 (en) Error handling during IMS registration
EP2696623B1 (en) Methods and apparatus of monitoring a call state over a single radio voice call continuity handover
CN105580340A (zh) 用于在ue与网络之间交换专用信令消息的机制
US9832650B2 (en) Dynamic WLAN connections
WO2024066150A1 (zh) 网络回落方法、设备及存储介质
CN113348724A (zh) 蜂窝网络中在不活动状态下的上行链路通信
JP7086188B2 (ja) 無線通信方法及び端末デバイス
US10292090B2 (en) Mobile station, mobile communication system, and network device
CN113163058B (zh) 会话参数更新方法、装置及通信设备、电子设备
JP7367186B2 (ja) ページング方法と機器
CN113709116B (zh) 通话恢复方法、终端设备及存储介质
US11849067B2 (en) Method for playing multimedia customized ringing signal and customized alerting tone, and application server
US11792694B2 (en) Packet-switched to circuit-switched handover during VOIP call initiation
CN113438612A (zh) 通话方法、终端设备及存储介质
CN116783986A (zh) 用于数据发射处理的方法及设备
CN110121215B (zh) 5g终端的数据连接建立方法、装置及5g终端
JP2021057792A (ja) 端末装置、基地局装置、方法、および、集積回路
CN105407543A (zh) 一种呼叫控制方法以及核心网设备
CN114467361A (zh) 在多无线电双连接中恢复无线电连接
JP6348875B2 (ja) 中継装置、呼制御システム、呼制御方法、および、呼制御プログラム
WO2017215317A1 (zh) 呼叫处理方法及装置
CN112770412B (zh) 一种分组数据网pdn激活方法及其装置
WO2018058538A1 (zh) 传输信息的方法、网络设备和终端设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant