CN115884374A - 消息处理的方法、通信装置、存储介质和产品 - Google Patents

Abstract

本申请实施例提供一种消息处理的方法、通信装置、存储介质和产品，其中方法包括：在建立通话连接之前，从网络设备接收至少两路寻呼请求；对寻呼请求进行呼叫连接处理；向网络设备发送第一响应消息，其中，第一响应消息用于指示寻呼请求的呼叫进展；在第一预设时长内，若接收到网络设备针对寻呼请求的拒绝消息，或未接收到网络设备针对寻呼请求的反馈，则确定寻呼请求为无效寻呼请求；释放无效寻呼请求占用的资源。采用本申请实施例，能够识别多路寻呼请求中的无效寻呼请求，并释放该无效寻呼请求占用的资源，有利于提高通话的成功率。

Description

消息处理的方法、通信装置、存储介质和产品

技术领域

本申请涉及通信技术领域，尤其涉及一种消息处理的方法、通信装置、存储介质和产品。

背景技术

IP多媒体子系统(IP multimedia subsystem，IMS)是一种基于互联网协议(internet protocol，IP)，且用于提供多媒体业务的网络系统。通过IMS可以为终端设备提供多种多媒体业务，如语音通话、视频通话等。会话启动协议(session initiationprotocol，SIP)是IMS的控制层协议，可用于建立、改变或结束多媒体会话的应用层协议，与实时传输协议(real-time transport protocol，RTP)、RTP控制协议(RTP controlprotocol，RTCP)、会话描述协议(session description protocol，SDP)、域名系统的(domain name system，DNS)解析协议等协议配合，共同完成IMS中会话的建立及媒体协商。

请参考图1，图1为现有技术中终端设备处理多路寻呼请求的流程示意图。如图1所示，在IMS域下的用户终端(user equipment，UE)，从网络设备接收到第一路寻呼请求(例如，INVITE请求)之后，会对第一路寻呼请求进行呼叫连接处理。例如，向网络设备发送100Trying消息(可简称为100消息)，以告知网络设备已收到第一路寻呼请求，正在进行下一步的处理。在UE和第一路寻呼请求对应的主叫终端建立通话连接之前，可能还会收到其他的寻呼请求(例如，第二路寻呼请求和第三路寻呼请求等)。终端设备会处理最先接收到的第一路寻呼消息，对于后续收到的第二路寻呼消息、第三路寻呼消息等，终端设备都会回复拒绝消息(例如，此处太忙消息(486Busy Here，可简称为486消息))。

然而，网络设备的异常会导致sip信令存在堵塞，使得有效的寻呼请求在第三路或第三路之后才发送。终端设备无法感知网络设备的异常，则终端设备直接拒绝后面接收到的寻呼请求，存在拒接有效(或正确)的寻呼请求，而处理无效(或错误)的寻呼请求的情况发生，导致通话建立失败，漏接来电的事件发生。因此，如何处理多路寻呼请求是本领域技术人员待解决的技术问题。

发明内容

本申请实施例公开了一种消息处理的方法、通信装置、存储介质和产品，能够识别多路寻呼请求中的无效寻呼请求，并释放该无效寻呼请求占用的资源，有利于提高通话的成功率。

第一方面，本申请公开了第一种消息处理的方法，应用于被叫终端，包括：在建立通话连接之前，从网络设备接收至少两路寻呼请求；对所述寻呼请求进行呼叫连接处理；向所述网络设备发送第一响应消息；在第一预设时长内，若接收到所述网络设备针对所述寻呼请求的拒绝消息，或未接收到所述网络设备针对所述寻呼请求的反馈，则确定所述寻呼请求为无效寻呼请求；释放所述无效寻呼请求占用的资源。

其中，寻呼请求包括IMS寻呼请求，所述呼叫连接处理包括分配资源。所述第一响应消息用于指示所述寻呼请求的呼叫进展，所述反馈包括所述拒绝消息和临时响应消息中的至少一种。

可以理解，在被叫终端建立通话连接之前，若被叫终端从网络设备接收到至少两路寻呼请求，则可以先假设网络设备支持每一寻呼请求，则对每一路的寻呼请求进行呼叫连接处理，可得到每一路寻呼请求分配的资源。再分别向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第一预设时长内，确定是否收到网络设备针对寻呼请求的反馈。若被叫终端接收到网络设备针对该寻呼请求的拒绝消息，则可以表示该寻呼请求对应的网络设备不支持执行该寻呼请求对应的呼叫连接步骤，可以确定该寻呼请求为无效寻呼请求。若被叫终端未接收到网络设备针对该寻呼请求的反馈，则可以表示网络设备出现异常，或表示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以正常通信，可以确定该寻呼请求为无效寻呼请求。在确定无效寻呼请求之后，可以释放该无效寻呼请求占用的资源，可避免处理无效寻呼请求的情况发生，有利于提高通话的成功率和建立通话的准确率。

在一种可能的示例中，在向所述网络设备发送第一响应消息之后，还包括：在所述第一预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则确定所述寻呼请求为有效寻呼请求。

可以理解，在第一响应消息发送之后的第一预设时长内，若被叫终端接收到网络设备针对该寻呼请求的临时响应消息，则可以表示网络设备无异常可以正常通信，可以确定该寻呼请求为有效寻呼请求，从而可以执行有效寻呼请求未完成的呼叫连接处理步骤，有利于提高通话的成功率。

在一种可能的示例中，在确定所述寻呼请求为有效寻呼请求之后，还包括：若所述有效寻呼请求的数量等于1，则执行所述有效寻呼请求未完成的呼叫连接处理步骤；或者若所述有效寻呼请求的数量大于1，则确定所述有效寻呼请求中最先收到的目标寻呼请求；释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源，执行所述目标寻呼请求未完成的呼叫连接处理步骤。

可以理解，在确定有效寻呼请求之后，先确定有效寻呼请求的数量。该数量应大于或等于1，若有效寻呼请求的数量等于1，则可以执行该有效寻呼请求未完成的呼叫连接处理。若有效寻呼请求的数量大于1，则表示有多路有效寻呼请求。可以选取多路有效寻呼请求中最早收到的目标寻呼请求，再执行该目标寻呼请求未完成的呼叫连接处理步骤，并释放有效寻呼请求中除目标寻呼请求之外的有效寻呼请求占用的资源。如此，可避免后续的有效寻呼请求为先收到的有效寻呼请求的重发消息，造成的重复建立通话连接。且先建立最先收到的有效寻呼请求的通话连接，满足通话顺序，有利于提高通话的成功率和建立通话的准确率。

在一种可能的示例中，在所述释放所述无效寻呼请求占用的资源之后，还包括：向所述网络设备发送第二响应消息。

其中，第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态，可以包括486消息等，在此不做限定。可以理解，在释放无效寻呼请求占用的资源后，不再执行该无效寻呼请求的呼叫连接步骤，从而不会实现无效寻呼请求的通话连接。被叫终端可以向网络设备发送被叫终端对于该无效寻呼请求为忙线状态的指示信息，以提示网络设备不需再响应该无效寻呼请求，有利于提高网络设备的处理效率。且网络设备还可告知该无效寻呼请求对应的主叫终端，以提示稍后通信等信息。

需要说明的是，在释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源之后，还可包括向网络设备发送被叫终端对于所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求为忙线状态。

第二方面，本申请公开了第二种消息处理的方法，应用于被叫终端，包括：在建立通话连接之前，从网络设备接收寻呼请求；对所述寻呼请求进行呼叫连接处理；向所述网络设备发送第一响应消息；在第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则对所述第一响应消息进行修改，得到至少一个第三响应消息；向所述网络设备发送所述第三响应消息；在所述第二预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则执行所述寻呼请求未完成的呼叫连接处理步骤。

其中，寻呼请求包括IMS寻呼请求，所述呼叫连接处理包括分配资源。所述第一响应消息用于指示所述寻呼请求的呼叫进展，所述反馈包括以下至少一种：临时响应消息和拒绝消息。

可以理解，在建立通话连接之前，若被叫终端从网络设备接收到寻呼请求，则可以进行呼叫连接处理。再向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第二预设时长内，若未接收到网络设备针对该寻呼请求的反馈，则可以修改该响应消息，并发送修改后的响应消息，以试探网络设备是否支持修改后的响应消息。若在修改后的响应消息发送之后的第二预设时长内，接收到网络设备针对该寻呼请求的临时响应消息，则可以执行该寻呼请求未完成的呼叫连接处理步骤。如此，通过不同的响应消息试探网络设备，有利于提高通话的成功率。

在一个可能的示例中，所述对所述第一响应消息进行修改，得到至少一个第三响应消息，包括：对所述第一响应消息的目标参数进行修改，得到至少一个第三响应消息。

其中，目标参数的目标类型包括以下至少一项：用户代理User-Agent头域、请求Require头域、音视频媒体参数类型、资源预留参数；若所述第一响应消息基于用户数据报协议UDP，则所述目标类型包括协议类型，所述第三响应消息基于传输控制协议TCP。

可以理解，在同一个对话内，在修改第一响应消息的目标参数之后，可得到不同的第三响应消息。通过修改后的第三响应消息对网络设备进行试探，在试探成功时完成剩余的呼叫处理步骤，有利于提高通话连接的成功率。

在一个可能的示例中，在所述向所述网络设备发送所述第三响应消息之后，还包括：在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，且存在下一个所述第三响应消息，则向所述网络设备发送下一个所述第三响应消息。

可以理解，在第三响应消息的数量为多个时，可以预先设置第三响应消息的发送顺序。即在第三响应消息未收到反馈时，再发送下一个第三响应消息，可进一步提高通话连接的成功率。

在一个可能的示例中，在所述对所述第一响应消息进行修改，得到至少一个第三响应消息之前，还包括：返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第一资源；根据所述第一资源确定到达To头域的第一标签tag参数；所述对所述第一响应消息进行修改，得到至少一个第三响应消息，包括：对所述第一响应消息的第一参数和所述第一tag参数进行修改，得到第三响应消息。

其中，所述第一参数的类型为目标类型。

可以理解，返回执行根据所述寻呼请求进行呼叫连接处理的步骤，会建立新的对话，被叫终端会重新分配资源。根据新分配的第一资源确定第一响应消息的To头域的第一tag参数。再对第一响应消息的第一参数和第一tag参数进行修改，得到第三响应消息。根据新分配的第一资源确定第一响应消息的To头域的第一tag参数。再对第一响应消息的第一参数和第一tag参数进行修改，得到第三响应消息。在发送第三响应消息之后，可以理解为被叫终端虚拟出的另一个终端发送第三响应消息。再基于网络设备是否对该终端是否有反馈，来确定网络设备是否能支持未完成的呼叫连接步骤。如此，通过虚拟出新的终端和修改的响应消息，在不同的对话内对网络设备进行试探，有利于提高通话连接的成功率。

在一个可能的示例中，在所述向所述网络设备发送所述第三响应消息之后，还包括：在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第二资源；根据所述第二资源确定所述To头域的第二tag参数；对所述第一响应消息的第二参数和所述第二tag参数进行修改，得到第四响应消息；向所述网络设备发送所述第四响应消息。

其中，所述第二参数的类型为所述目标类型。

可以理解，在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的反馈，则再次返回执行根据所述寻呼请求进行呼叫连接处理的步骤，再建立一个新的对话，可以得到的新分配的第二资源。根据新分配的第二资源确定第一响应消息的To头域的第二tag参数。再对第一响应消息的第二参数和第二tag参数进行修改，得到第四响应消息。在发送第四响应消息之后，可以得到新的对话，可以理解为被叫终端虚拟出的另一个终端发送第四响应消息。再基于网络设备是否对该终端有反馈，来确定网络设备是否能支持未完成的呼叫连接步骤。若还是未收到反馈，则基于该示例再次执行，直至接收到网络设备的反馈或在满足预设条件时，结束修改的步骤。如此，在同一个对话内，在修改第一响应消息中目标类型的参数之后，可得到不同的第三响应消息。通过修改响应消息试探网络设备，有利于提高通话连接的成功率。

在本申请实施例中，预设条件可以包括已没有可修改的响应消息，或与第一响应消息的发送时间的时间间隔超过一个预设的时长(可以为第一预设时长，或可以为大于第二预设时长的时长)等，在此不做限定。在满足预设条件时，还可以释放该无效寻呼请求占用的资源。

在一个可能的示例中，还包括：在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的拒绝消息，则释放所述寻呼请求占用的资源。如此，可避免处理无效的寻呼请求的情况发生，有利于提高通话的成功率和建立通话的准确率。

在一个可能的示例中，在向所述网络设备发送第一响应消息之后，还包括：在第三预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述向所述网络设备发送第一响应消息的步骤。

其中，所述第三预设时长小于所述第二预设时长。

可以理解，由于修改了To头域的tag参数，创建了新的对话，则在第一响应消息对应的对话中，还可重新发送第一响应消息，以确认是否为网络异常造成的无反馈。且在第一响应消息之后的第三预设时长内，若接收到网络设备的临时响应消息，则可执行未完成的呼叫连接处理步骤。若接收到网络设备的拒绝消息，则可释放该寻呼请求占用的资源。若未接收到网络设备的反馈，则可在第三预设时长到达时，或2倍第三预设时长等其他时长到达时，进行重发。如此，通过重发第一响应消息，有利于提高通话连接的成功率。

在一个可能的示例中，还包括：根据所述寻呼请求的协议类型确定所述第二预设时长。如此，可提高确定第一响应消息是否无效的准确率，有利于提高通信的成功率。

在一个可能的示例中，若所述寻呼请求的协议类型为UDP，则所述第二预设时长大于3*T1，且小于4*T1，其中，所述T1为第一计时器的预设时长。

在一个可能的示例中，若所述寻呼请求的协议类型TCP，则所述第二预设时长大于5秒，且小于6秒。

第三方面，本申请还公开了第三种消息处理的方法，应用于网络设备，包括：在建立通话连接之前，向被叫终端发送至少两路寻呼请求，所述寻呼请求包括IMS寻呼请求；从所述被叫终端接收第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展。

在一种可能的示例中，从所述被叫终端接收第一响应消息之后，还包括：向所述被叫终端发送针对所述寻呼请求的反馈，所述反馈包括以下至少一种：拒绝消息和临时响应消息。

第四方面，本申请还公开了第四种消息处理的方法，应用于主叫终端，包括：向网络设备发送寻呼请求，所述寻呼请求包括IMS寻呼请求。

第五方面，本申请公开了第一种通信装置，应用于被叫终端，包括：收发单元用于在建立通话连接之前，从网络设备接收至少两路寻呼请求；处理单元用于对所述寻呼请求进行呼叫连接处理；所述收发单元还用于向所述网络设备发送第一响应消息；所述处理单元还用于在第一预设时长内，若接收到所述网络设备针对所述寻呼请求的拒绝消息，或未接收到所述网络设备针对所述寻呼请求的反馈，则确定所述寻呼请求为无效寻呼请求；释放所述无效寻呼请求占用的资源。

其中，寻呼请求包括IMS寻呼请求，所述呼叫连接处理包括分配资源。所述第一响应消息用于指示所述寻呼请求的呼叫进展，所述反馈包括所述拒绝消息和临时响应消息中的至少一种。

可以理解，在被叫终端建立通话连接之前，若被叫终端从网络设备接收到至少两路寻呼请求，则可以先假设网络设备支持每一寻呼请求，则对每一路的寻呼请求进行呼叫连接处理，可得到每一路寻呼请求分配的资源。再分别向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第一预设时长内，确定是否收到网络设备针对寻呼请求的反馈。若被叫终端接收到网络设备针对该寻呼请求的拒绝消息，则可以表示该寻呼请求对应的网络设备不支持执行该寻呼请求对应的呼叫连接步骤，可以确定该寻呼请求为无效寻呼请求。若被叫终端未接收到网络设备针对该寻呼请求的反馈，则可以表示网络设备出现异常，或表示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以正常通信，可以确定该寻呼请求为无效寻呼请求。在确定无效寻呼请求之后，可以释放该无效寻呼请求占用的资源，可避免处理无效寻呼请求的情况发生，有利于提高通话的成功率和建立通话的准确率。

在一种可能的示例中，所述处理单元还用于在所述第一预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则确定所述寻呼请求为有效寻呼请求。

可以理解，在第一响应消息发送之后的第一预设时长内，若被叫终端接收到网络设备针对该寻呼请求的临时响应消息，则可以表示网络设备无异常可以正常通信，可以确定该寻呼请求为有效寻呼请求，从而可以执行有效寻呼请求未完成的呼叫连接处理步骤，有利于提高通话的成功率。

在一种可能的示例中，所述处理单元还用于若所述有效寻呼请求的数量等于1，则执行所述有效寻呼请求未完成的呼叫连接处理步骤；或者若所述有效寻呼请求的数量大于1，则确定所述有效寻呼请求中最先收到的目标寻呼请求；释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源，执行所述目标寻呼请求未完成的呼叫连接处理步骤。

可以理解，在确定有效寻呼请求之后，先确定有效寻呼请求的数量。该数量应大于或等于1，若有效寻呼请求的数量等于1，则可以执行该有效寻呼请求未完成的呼叫连接处理。若有效寻呼请求的数量大于1，则表示有多路有效寻呼请求。可以选取多路有效寻呼请求中最早收到的目标寻呼请求，再执行该目标寻呼请求未完成的呼叫连接处理步骤，并释放有效寻呼请求中除目标寻呼请求之外的有效寻呼请求占用的资源。如此，可避免后续的有效寻呼请求为先收到的有效寻呼请求的重发消息，造成的重复建立通话连接。且先建立最先收到的有效寻呼请求的通话连接，满足通话顺序，有利于提高通话的成功率和建立通话的准确率。

在一种可能的示例中，所述收发单元还用于向所述网络设备发送第二响应消息，所述第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态。

其中，第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态，可以包括486消息等，在此不做限定。可以理解，在释放无效寻呼请求占用的资源后，不再执行该无效寻呼请求的呼叫连接步骤，从而不会实现无效寻呼请求的通话连接。被叫终端可以向网络设备发送被叫终端对于该无效寻呼请求为忙线状态的指示信息，以提示网络设备不需再响应该无效寻呼请求，有利于提高网络设备的处理效率。且网络设备还可告知该无效寻呼请求的主叫终端，以提示稍后通信等信息。

第六方面，本申请公开了第二种通信装置，应用于被叫终端，包括：收发单元用于在建立通话连接之前，从网络设备接收寻呼请求；处理单元用于对所述寻呼请求进行呼叫连接处理；所述收发单元还用于向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；所述处理单元还用于在第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则对所述第一响应消息进行修改，得到至少一个第三响应消息，所述反馈包括以下至少一种：临时响应消息和拒绝消息；所述收发单元还用于向所述网络设备发送所述第三响应消息；所述处理单元还用于在所述第二预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则执行所述寻呼请求未完成的呼叫连接处理步骤。

其中，寻呼请求包括IMS寻呼请求，所述呼叫连接处理包括分配资源。所述第一响应消息用于指示所述寻呼请求的呼叫进展，所述反馈包括以下至少一种：临时响应消息和拒绝消息。

可以理解，在建立通话连接之前，若被叫终端从网络设备接收到寻呼请求，则可以进行呼叫连接处理。再向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第二预设时长内，若未接收到网络设备针对该寻呼请求的反馈，则可以修改该响应消息，并发送修改后的响应消息，以试探网络设备是否支持修改后的响应消息。若在修改后的响应消息发送之后的第二预设时长内，接收到网络设备针对该寻呼请求的临时响应消息，则可以执行该寻呼请求未完成的呼叫连接处理步骤。如此，通过不同的响应消息试探网络设备，有利于提高通话的成功率。

在一种可能的示例中，所述处理单元具体用于对所述第一响应消息的目标参数进行修改，得到至少一个第三响应消息。

其中，所述目标参数的目标类型包括以下至少一项：用户代理User-Agent头域、请求Require头域、音视频媒体参数类型、资源预留参数；若所述寻呼请求基于用户数据报协议UDP，则所述目标类型包括协议类型，所述第三响应消息基于传输控制协议TCP。

可以理解，在同一个对话内，在修改第一响应消息的目标参数之后，可得到不同的第三响应消息。通过修改后的第三响应消息对网络设备进行试探，在试探成功时完成剩余的呼叫处理步骤，有利于提高通话连接的成功率。

在一种可能的示例中，所述收发单元还用于在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，且存在下一个所述第三响应消息，则向所述网络设备发送下一个所述第三响应消息。

可以理解，在第三响应消息的数量为多个时，可以预先设置第三响应消息的发送顺序。即在第三响应消息未收到反馈时，再发送下一个第三响应消息，可进一步提高通话连接的成功率。

在一种可能的示例中，所述处理单元具体用于返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第一资源；根据所述第一资源确定To头域的第一tag参数；对所述第一响应消息的第一参数和所述第一tag参数进行修改，得到第三响应消息。

其中，所述第一参数的类型为目标类型。

可以理解，返回执行根据所述寻呼请求进行呼叫连接处理的步骤，会建立新的对话，被叫终端会重新分配资源。根据新分配的第一资源确定第一响应消息的To头域的第一tag参数。再对第一响应消息的第一参数和第一tag参数进行修改，得到第三响应消息。根据新分配的第一资源确定第一响应消息的To头域的第一tag参数。再对第一响应消息的第一参数和第一tag参数进行修改，得到第三响应消息。在发送第三响应消息之后，可以理解为被叫终端虚拟出的另一个终端发送第三响应消息。再基于网络设备是否对该终端是否有反馈，来确定网络设备是否能支持未完成的呼叫连接步骤。如此，通过虚拟出新的终端和修改的响应消息，在不同的对话内对网络设备进行试探，有利于提高通话连接的成功率。

在一种可能的示例中，所述处理单元还用于在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第二资源；根据所述第二资源确定所述To头域的第二tag参数；对所述第三响应消息的第二参数和所述第二tag参数进行修改，得到第四响应消息；向所述网络设备发送所述第四响应消息。

其中，所述第二参数的类型为所述目标类型。

可以理解，在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的反馈，则再次返回执行根据所述寻呼请求进行呼叫连接处理的步骤，再建立一个新的对话，可以得到的新分配的第二资源。根据新分配的第二资源确定第一响应消息的To头域的第二tag参数。再对第一响应消息的第二参数和第二tag参数进行修改，得到第四响应消息。在发送第四响应消息之后，可以得到新的对话，可以理解为被叫终端虚拟出的另一个终端发送第四响应消息。再基于网络设备是否对该终端有反馈，来确定网络设备是否能支持未完成的呼叫连接步骤。若还是未收到反馈，则基于该示例再次执行，直至接收到网络设备的反馈或在满足预设条件时，结束修改的步骤。如此，在同一个对话内，在修改第一响应消息中目标类型的参数之后，可得到不同的第三响应消息。通过修改响应消息试探网络设备，有利于提高通话连接的成功率。

在本申请实施例中，预设条件可以包括已没有可修改的响应消息，或与第一响应消息的发送时间的时间间隔超过一个预设的时长(可以为第一预设时长，或可以为大于第二预设时长的时长)等，在此不做限定。在满足预设条件时，还可以释放该无效寻呼请求占用的资源。

在一个可能的示例中，处理单元还用于在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的拒绝消息，则释放所述寻呼请求占用的资源。如此，可避免处理无效的寻呼请求的情况发生，有利于提高通话的成功率和建立通话的准确率。

在一种可能的示例中，所述处理单元还用于在所述第一响应消息发送之后的第三预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述向所述网络设备发送第一响应消息的步骤。

其中，所述第三预设时长小于所述第二预设时长。

可以理解，由于修改了To头域的tag参数，创建了新的对话，则在第一响应消息对应的对话中，还可重新发送第一响应消息，以确认是否为网络异常造成的无反馈。且在第一响应消息之后的第三预设时长内，若接收到网络设备的临时响应消息，则可执行未完成的呼叫连接处理步骤。若接收到网络设备的拒绝消息，则可释放该寻呼请求占用的资源。若未接收到网络设备的反馈，则可在第三预设时长到达时，或2倍第三预设时长等其他时长到达时，进行重发。如此，通过重发第一响应消息，有利于提高通话连接的成功率。

在一种可能的示例中，所述处理单元还用于根据所述寻呼请求的协议类型确定所述第二预设时长。如此，可提高确定第一响应消息是否无效的准确率，有利于提高通信的成功率。

在一种可能的示例中，若所述寻呼请求基于UDP，则所述第二预设时长大于3*T1，且小于4*T1，其中，所述T1为第一计时器的预设时长。

在一种可能的示例中，若所述寻呼请求基于TCP，则所述第二预设时长大于5秒，且小于6秒。

第七方面，本申请公开了第三种通信装置，应用于网络设备，包括：收发单元用于在建立通话连接之前，向被叫终端发送至少两路寻呼请求，所述寻呼请求包括IMS寻呼请求；从所述被叫终端接收第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展。

在一种可能的示例中，收发单元还用于向所述被叫终端发送针对所述寻呼请求的反馈，所述反馈包括以下至少一种：拒绝消息和临时响应消息。

第八方面，本申请公开了第四种通信装置，应用于网络设备，包括：收发单元用于向网络设备发送寻呼请求。

第九方面，本申请公开了第六种通信装置，包括处理器和与处理器连接的存储器和通信接口，存储器用于存储一个或多个程序，并且被配置由处理器执行上述任一方面的步骤。

第十方面，本申请实施例公开了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述任一方面的方法。

第十一方面，本申请实施例公开了一种计算机程序产品，计算机程序产品用于存储计算机程序，当计算机程序在计算机上运行时，使得计算机执行上述任一方面的方法。

第十二方面，本申请实施例公开了第一种芯片，包括处理器和存储器，处理器用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的设备执行上述任一方面的方法。

第十三方面，本申请实施例公开了第二种芯片，包括：输入接口、输出接口和处理电路，输入接口、输出接口与处理电路之间通过内部连接通路相连，处理电路用于执行上述任一方面的方法。

第十四方面，本申请实施例公开了第三种芯片，包括：输入接口、输出接口、处理器，可选的，还包括存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行上述任一方面中的方法。

第十五方面，本申请实施例公开了一种芯片系统，包括至少一个处理器，存储器和接口电路，存储器、收发器和至少一个处理器通过线路互联，至少一个存储器中存储有计算机程序；计算机程序被处理器执行上述任一方面中的方法。

通过实施本申请实施例，在被叫终端建立通话连接之前，若被叫终端从网络设备接收到至少两路寻呼请求，则可以先假设网络设备支持每一寻呼请求，则对每一路的寻呼请求进行呼叫连接处理，可得到每一路寻呼请求分配的资源。再分别向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第一预设时长内，确定是否收到网络设备针对寻呼请求的反馈。若被叫终端接收到网络设备针对该寻呼请求的拒绝消息，则可以表示该寻呼请求对应的网络设备不支持执行该寻呼请求对应的呼叫连接步骤，可以确定该寻呼请求为无效寻呼请求。若被叫终端未接收到网络设备针对该寻呼请求的反馈，则可以表示网络设备出现异常，或表示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以正常通信，可以确定该寻呼请求为无效寻呼请求。在确定无效寻呼请求之后，可以释放该无效寻呼请求占用的资源，可避免处理无效寻呼请求的情况发生。若被叫终端接收到网络设备针对该寻呼请求的临时响应消息，则可以表示网络设备无异常可以正常通信，可以确定该寻呼请求为有效寻呼请求，从而可执行该有效寻呼请求未完成的呼叫连接步骤。如此，有利于提高通话的成功率。

在另一方面，在被叫终端从网络设备接收到寻呼请求之后。对该寻呼请求进行呼叫连接处理，并向网络设备发送响应消息。在第二预设时长内，若未接收到网络设备针对该寻呼请求的反馈，则可以修改该响应消息，并发送修改后的响应消息，以试探网络设备是否支持修改后的响应消息。如此，通过不同的响应消息试探网络设备，有利于提高通话的成功率。

附图说明

以下对本申请实施例用到的附图进行介绍。

图1是现有技术中提供的一种终端设备处理多路寻呼请求的流程示意图；

图2是本申请实施例提供的一种通信系统的结构示意图；

图3是本申请实施例提供的一种终端设备的结构示意图；

图4是本申请实施例提供的一种网络设备的结构示意图；

图5是本申请实施例提供的一种IMS的结构示意图；

图6是本申请实施例提供的一种消息处理的方法的流程示意图；

图7是本申请实施例提供的另一种消息处理的方法的流程示意图；

图8是本申请实施例提供的又一种消息处理的方法的流程示意图；

图9是本申请实施例提供的另一种终端设备处理多路寻呼请求的流程示意图；

图10是本申请实施例提供的又一种终端设备处理多路寻呼请求的流程示意图；

图11是本申请实施例提供的一种通信装置的结构示意图；

图12是本申请实施例提供的另一种通信装置的结构示意图。

具体实施方式

下面结合本申请实施例中的附图对本申请实施例进行描述。

请参见图2，图2是本申请实施例提供的一种通信系统的结构示意图。本申请实施例中的通信系统可以是支持第二代(second generation，2G)移动通讯技术的通讯系统，例如，全球移动通信系统(global system for mobile communication，GSM)接入技术、码分多址(code division multiple access，CDMA)接入技术；或者，该通信系统可以是支持第三代(third generation，3G)移动通讯技术的通讯系统，例如，宽带码分多址(widebandcode division multiple access，WCDMA)接入技术等；或者，该通信系统可以是支持第四代(fourth generation，4G)移动通讯技术的通信系统，例如，长期演进(long termevolution，LTE)接入技术；或者，该通信系统可以是支持第五代(fifth generation，5G)移动通讯技术的通信系统，例如，NR接入技术；或者，该通信系统可以是支持多种无线技术的通信系统，例如，支持LTE技术和NR技术的通信系统。另外，该通信系统可以适用于面向未来的通信技术。采用IMS作为语音解决方案的通信系统，均可以采用本申请实施例提供的消息处理的方法。

如图2所示，通信系统可以包括至少一个终端设备(例如，终端设备201)、至少一个接入网设备(例如，接入网设备202)、至少一个核心网设备(例如，核心网设备203)和IP多媒体子系统(IP multimedia subsystem，IMS)(例如，IMS204)。

在本申请实施例中，终端设备是一种具有无线收发功能的设备。该终端设备可以部署在陆地上，包括室内或室外、手持、穿戴或车载。该终端设备还可以部署在水面上(如轮船等)或空中(例如飞机、气球和卫星上等)。该终端设备可以是手机(mobile phone)、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(self-driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等等。

本申请的实施例对于应用场景不做限定。终端设备有时也可以称为用户设备(user equipment，UE)、终端(terminal)、接入终端、UE单元、UE站、移动设备、移动站、移动台(mobile station)、移动终端、移动客户端、移动单元(mobile unit)、远方站、远程终端设备、远程单元、无线单元、无线通信设备、用户代理或用户装置等。其中，接入终端可以是蜂窝电话、无绳电话、会话启动协议(session initiation protocol，SIP)电话、无线本地环路(wireless local loop，WLL)站、个人数字处理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，未来5G中的终端设备或者未来演进的公共陆地移动网(public landmobile network，PLMN)网络中的终端设备等。以下描述中多以终端为终端设备进行举例说明。

请参照图3，图3为本申请实施例提供的一种终端设备的结构示意图。可以理解的是，图3中的终端设备300可以是图2示出的通信系统中的终端设备201。如图3所示，终端设备300可包括输入输出模块(包括音频输入输出模块318、按键输入模块316以及显示器320等)、用户接口302、一个或多个处理器304、发射器(transmit，TX)306、接收器(receive，RX)308、耦合器310、天线314以及存储器312。这些部件可通过总线或者其它方式连接，图3以通过总线305连接为例。其中：

天线314可用于将电磁能转换成自由空间中的电磁波，或者将自由空间中的电磁波转换成传输线中的电磁能。耦合器310用于将天线314接收到的移动通信信号分成多路，分配给多个的接收器308。

发射器306可用于对处理器304输出的信号进行发射处理。

接收器308可用于对天线314接收的移动通信信号进行接收处理。

在本申请实施例中，发射器306和接收器308可看作一个无线调制解调器。在终端设备300中，发射器306和接收器308的数量均可以是一个或者多个。

除了图3所示的发射器306和接收器308，终端设备300还可包括其他通信部件，例如全球定位系统(global positioning system，GPS)模块、蓝牙(Bluetooth)模块、无线高保真(wireless fidelity，Wi-Fi)模块等。不限于上述表述的无线通信信号，终端设备300还可以支持其他无线通信信号，例如卫星信号、短波信号等等。不限于无线通信，终端设备300还可以配置有有线网络接口(如局域网(local area network，LAN)接口)301来支持有线通信。

输入输出模块可用于实现终端设备300和用户/外部环境之间的交互，可主要包括音频输入输出模块318、按键输入模块316以及显示器320等。输入输出模块还可包括摄像头、触摸屏以及传感器等等。输入输出模块可通过用户接口302与处理器304进行通信。

存储器312可以和处理器304通过总线或者输入输出端口耦合，存储器312也可以与处理器304集成在一起。存储器312用于存储各种软件程序和/或多组指令。存储器312可包括高速随机存取的存储器，或者可包括非易失性存储器。例如，一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器312可以存储操作系统(下述简称系统)，例如，ANDROID，IOS，WINDOWS，或者LINUX等嵌入式操作系统。存储器312还可以存储网络通信程序，该网络通信程序可用于与一个或多个附加设备，一个或多个终端设备，一个或多个网络设备进行通信。存储器312还可以存储用户接口程序，该用户接口程序可以通过图形化的操作界面将应用程序的内容形象逼真的显示出来，或者可以通过菜单、对话框以及按键等输入控件接收用户对应用程序的控制操作。在本申请实施例中，存储器312可用于存储本申请的一个或多个实施例提供的消息处理的方法在终端设备300侧的实现程序。

处理器304可用于读取和执行计算机可读指令。具体的，处理器304可用于调用存储于存储器312中的程序，例如，本申请的一个或多个实施例提供的消息处理的方法在终端设备300侧的实现程序，并执行该程序包含的指令以实现后续实施例涉及的方法。处理器304可支持2G通信、3G通信、4G通信以及5G通信等中的一个或多个通信技术。可选的，当处理器304发送任何消息或数据时，其具体通过驱动或控制发射器306做所述发送。可选的，当处理器304接收任何消息或数据时，其具体通过驱动或控制接收器308做所述接收。因此，处理器304可以被视为是执行发送或接收的控制中心，发射器306和接收器308是发送和接收操作的具体执行者。

需要说明的，图3所示的终端设备300是本申请实施例的一种实现方式，实际应用中，终端设备300还可以包括更多或更少的部件，这里不作限制。

在本申请实施例中，接入网设备可以是接入网侧用于支持终端接入通信系统的设备，接入网设备可以称为基站(base station，BS)，例如，4G接入技术通信系统中的演进型基站(evolved node base station，eNB)、5G接入技术通信系统中的下一代基站(nextgeneration node base station，gNB)、发送接收点(transmission reception point，TRP)、接入点(access point，AP)等等，或者接入网设备可以称为宿主节点、IAB宿主(IABdonor)、宿主IAB、宿主或宿主gNB(donor gNB，DgNB)等。

应理解，本申请实施例中的网络设备可以为上述的接入网设备、核心网设备或IMS。请参照图4，图4为本申请实施例提供的一种网络设备的结构示意图。如图4所示，网络设备400可包括：一个或多个处理器401、存储器402、网络接口403、发射器405、接收器406、耦合器407和天线408。这些部件可通过总线404或者其他方式连接，图4以通过总线连接为例。其中：

网络接口403可用于网络设备400与其他通信设备(例如，其他网络设备)进行通信。具体的，网络接口403可以是有线接口。

发射器405可用于对处理器401输出的信号进行发射处理，例如，信号调制。接收器406可用于对天线408接收的移动通信信号进行接收处理。例如，信号解调。在本申请的一些实施例中，发射器405和接收器406可看作一个无线调制解调器。在网络设备400中，发射器405和接收器406的数量均可以是一个或者多个。天线408可用于将传输线中的电磁能转换成自由空间中的电磁波，或者将自由空间中的电磁波转换成传输线中的电磁能。耦合器407可用于将移动通信信号分成多路，分配给多个的接收器406。

存储器402可以和处理器401通过总线404或者输入输出端口耦合，存储器402也可以与处理器401集成在一起。存储器402用于存储各种软件程序和/或多组指令。具体的，存储器402可包括高速随机存取的存储器，或者可包括非易失性存储器。例如，一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器402可以存储操作系统(下述简称系统)。例如，uCOS、VxWorks、RTLinux等嵌入式操作系统。存储器402还可以存储网络通信程序，该网络通信程序可用于与一个或多个附加设备，一个或多个终端设备，一个或多个网络设备进行通信。

处理器401可用于进行无线信道管理、实施呼叫和通信链路的建立和拆除，并为本控制区内的用户提供小区切换控制等。具体的，处理器401可包括：用于话路交换和信息交换的中心的管理/通信模块(administration module/communication module，AM/CM)、用于完成呼叫处理、信令处理、无线资源管理、无线链路的管理和电路维护功能的基本模块(basic module，BM)、用于完成复用解复用和码变换功能的码变换及子复用单元(transcoder and sub multiplexer，TCSM)等等。

在本申请实施例中，处理器401可用于读取和执行计算机可读指令。具体的，处理器401可用于调用存储于存储器402中的程序。例如，本申请的一个或多个实施例提供的数据传输的方法在网络设备400侧的实现程序，并执行该程序包含的指令。

需要说明的是，图4所示的网络设备400是本申请实施例的一种实现方式，实际应用中，网络设备400还可以包括更多或更少的部件，这里不作限制。

在本申请实施例中，核心网设备还可以称为核心网网元。核心网设备可以连接一个或者多个接入网设备，可以为系统中的终端提供会话管理、接入认证、互联网协议(internet protocol，IP)地址分配和数据传输中的一种或者多种功能。例如，核心网设备可以是4G接入技术通信系统中的移动管理实体(mobile management entity，MME)或者服务网关(serving gateway，SGW)，5G接入技术通信系统中的接入和移动性管理功能(accessand mobility management function，AMF)网元或者用户面性能(user plane function，UPF)网元等等。

IMS是一种基于IP，且用于提供多媒体业务的网络系统。请参照图5，图5为本申请实施例提供的一种终端设备的结构示意图。可以理解的是，图5中的IMS500可以是图2示出的通信系统中的IMS204。如图5所示，IMS500可以包括代理呼叫状态控制功能(proxy-callsession control function，P-CSCF)实体501、查询呼叫状态控制功能(interrogating-call session control function，I-CSCF)实体502、服务呼叫状态控制功能(serving-call session control function，S-CSCF)实体503、归属地用户服务器(home subscriberserver，HSS)504等。

在本申请实施例中，P-CSCF实体可以为接入网设备到IMS的最先连接点，所有发起于支持IMS的终端设备和终止于支持IMS的终端设备的会话消息都要通过P-CSCF实体转发。P-CSCF实体可用于将来自终端设备的注册请求转发给S-CSCF实体，以及将注册应答信息转发给终端设备。

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

S-CSCF实体为IMS的控制核心，为终端设备提供会话控制和注册等功能。S-CSCF实体用于接收P-CSCF实体转发的终端设备的注册请求，与HSS配合对终端设备进行鉴权；以及在确定鉴权通过后，从HSS获取终端设备的签约信息。S-CSCF实体还用于基于ISC接口(是各应用服务器(application server，AP)与S-CSCF之间，以及IMS的网关功能(gate wayfunction，GWF)与S-CSCF之间的接口)与各应用服务器(application server，AP)相连。S-CSCF实体还用于触发应用服务器执行操作，将终端设备的请求消息路由到相应的应用服务器。

HSS为IMS中存储有所有与用户和服务相关的数据的主要的数据存储器。存储在HSS中的数据主要包括用户身份、签约信息、接入信息等，在此不做限定。

在本申请实施例中，终端设备用于生成注册请求，并将生成的注册请求通过接入网设备、以及核心网设备发送给IMS中的P-CSCF实体。终端设备还可用于通过核心网设备、以及接入网设备的从IMS接收注册应答消息。例如，注册请求为挑战注册请求，注册应答消息为确认消息(例如，200OK消息，可简称为200消息)。

需要说明的是，图2所示的通信系统是本申请实施例的一种实现方式，实际应用中，通信系统和通信系统中的装置还可以包括更多或更少的部件，这里不作限制。

本申请实施例中的术语“系统”和“网络”可被互换使用。“多个”是指两个或两个以上，鉴于此，本申请实施例中也可以将“多个”理解为“至少两个”。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，字符“/”，如无特殊说明，一般表示前后关联对象是一种“或”的关系。且在本申请实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

为了便于理解本申请，以下介绍本申请实施例涉及的会话启动协议(sessioninitiation protocol，SIP)。SIP是IMS的控制层协议，可用于建立、改变或结束多媒体会话的应用层协议，与实时传输协议(real-time transport protocol，RTP)、RTP控制协议(RTPcontrol protocol，RTCP)、会话描述协议(session description protocol，SDP)、域名系统的(domain name system，DNS)解析协议等协议配合，共同完成IMS中会话的建立及媒体协商。

SIP是通过IP通信(Voice over IP，VoIP)技术最常使用的协议。VoIP是一种允许通过IP协议传递语音和多媒体(视频，图片)内容的技术，可用于解决移动与固网融合，引入语音、数据、视频三重融合等差异化业务的重要方式。VoIP可包括通过LTE通信(Voice overLTE，VoLTE)、通过WiFi通信(Voice over WiFi，VoWiFi)和通过WiFi通信(Voice over NR，VoNR)等。其中，VoLTE是一个面向终端和数据终端的高速无线通信标准。它基于IMS网络，在LTE上使用sip信令作为控制层面(control plane)、使用用户数据报协议(user datagramprotocol，udp)/IP协议作为语音服务的媒体层面(media plane)。VoNR和VoWiFi与VoLTE处理实现机制类似，其所有数据交互分别在承载于NR、WiFi上。

SIP可以基于传输控制协议(transmission control protocol，TCP)，或者可以基于用户数据报协议(user datagram protocol，UDP)。SIP协议通常用于两个或多个端点之间的网络电话和多媒体分发。例如，一个人可以使用SIP向另一个人发起电话呼叫，或者某个人可以与许多参与者简历电话会议。

SIP中的每一种网络元素都由SIP统一资源标识符(uniform resourceidentifier，URI)进行标识。SIP可包括用户代理(user agent，UA)、代理服务器(proxyserver)、注册服务器(registrar server)、重定向服务器(redirect server)、本地服务器(location server)等网络元素。

其中，UA是端口，可用于邀请、修改、中断一次会话。UA在逻辑上被分为用户代理客户端(user agent client，UAC)和用户代理服务器(user agent server，UAS)。UAC可作为发送请求接受响应的设备，UAS可作为接收请求做出回应的设备。也就是说，呼叫的终端设备(可称为主叫终端)可作为客户端，被呼叫的终端设备(可称为被叫终端)可作为服务端。

代理服务器位于两个UA之间，是将一个UA的请求转发给其他用户的设备，扮演了类似路由器的角色。注册服务器从UA接收注册请求，帮助用户进行网络验证。重定向服务器在接收到请求之后，从注册服务器创建的数据库中查找预期的收件人。本地服务器向代理服务器、重定向服务器提供有关被叫终端可能的位置信息。

SIP报头是一组结构化的报头序列，大部分情况下跟超文本传输协议(hyper texttransfer protocol，HTTP)报头采用相同的规则，以NAME:VALUE的形式定义。其中，NAME用于表明报头字段名，VALUE是包含信息的令牌。

SIP消息分为请求和响应两类。其中，请求的开始行包含一个定义请求的方法，以及一个将请求发往何处的URI。响应消息通常由UAS或SIP的服务器发出，响应中包含一个响应码。请参考下表，SIP的响应码有以下六类。

SIP请求的类型可以包括邀请(INVITE)请求、注册(REGISTER)请求、再见(BYE)请求、确认(ACK)请求、取消(CANCEL)请求、可选的(OPTIONS)请求等，还可包括参考(REFER)请求、订阅(SUBSCRIBE)请求、通知(NOTIFY)请求、公布(PUBLISH)请求、消息(MESSAGE)请求、更新(UPDATE)请求、信息(INFO)请求和临时确认信息(PRACK)请求等扩展的请求，在此不做限定。SIP请求还可称作SIP方法，例如，INVITE方法。

其中，BYE请求用于中断一个建立的会话。BYE请求可以主叫终端或被叫终端发送，不能由代理服务器发送。BYE请求通常跳过代理服务器，端到端发送。BYE请求不能发送给一个等待INVITE请求或一个未建立的会话。

ACK请求是对INVITE方法的最后响应。ACK请求可能包含SDP消息体。ACK不能用于修改已经在初始INVITE请求中发送的媒体描述，有状态的代理接收到ACK请求需确定是否这个ACK应该被转发另一个代理或UA。对于2xx的响应，ACK请求是端到端的，对于其他最终响应，有状态的代理是逐跳工作的。CANCEL请求被用于终止未建立的会话，UA使用CANCEL请求取消先前发起的挂起的呼叫尝试。

INVITE请求用于启动一次会话，也就是说，一个INVITE方法被用于在UA之间建立媒体会话。INVITE请求通常带有消息体，消息体包含主叫方的媒体信息。INVITE请求还可以包含其它会话信息，例如，资源列表。如果INVITE请求中没有携带媒体信息，那么就要在UAC发出的ACK请求中携带。如果ACK中的媒体信息是不能接受的，那么主叫终端可发一条BYE请求以终止会话。这时不能用CANCEL请求，因为会话已经建立了。会话建立的标志是INVITE请求接收到成功的响应消息(例如，200等)或发送出去一个ACK请求，直到发送BYE请求中断会话。在一个建立的dialog中再次发送INVITE请求被称作重邀请(Re-INVITE)请求，用于改变会话的特征或刷新dialog状态。

REGISTER请求是UA用于发送注册请求，由UA发给注册服务器。OPTIONS请求被用于查询UA或代理服务器的功能，响应列出可用的功能。代理服务器不会生成OPTIONS请求。SUBSCRIBE请求被用于建立订阅，以获取关于特定事件的通知。NOTIFY请求被UA用于获取特定事件的发生，通常当订阅者和通知程序之间存在订阅时，将触发通知。PUBLISH请求被用于发送事件状态信息给服务器。REFER请求用于被一个UA引用另一个UA来访问对话的URI。INFO请求被一个UA发送信令信息给另一个UA与它建立媒体会话。UPDATE请求被用于修改会话状态，当会话未建立时，用户可以使用UPDATE请求修改编码。MESSAGE请求使用SIP发送即时消息，一个MESSAGE请求通常包含的内容比较短。

PRACK请求用于确认收到了可靠的临时回复(1XX)，适用于除了从未可靠的传输中收到100Trying消息(可简称为100消息)之外的所有的临时响应。其中，100Trying响应表示对端已收到请求，正在进行下一步的处理，具体处理什么流程，取决于UAS本身。PRACK请求可以包含一个消息体，用于拒绝或接收(offer/answer)接收到的消息。

SIP协议还包括资源预留(precondition)的步骤，相比普通的呼叫流程更安全。资源预留在通话前协商了两次(invite-183、update-200ok)，而普通的流程只协商了一次(invite-200ok)，保证了资源预留成功之后才能振铃接通呼叫，避免了普通流程中通话接通后无声音的情况。主叫终端的INVITE请求中携带support：precondition头域和require：precondition头域。被叫终端收到INVITE请求之后，回复“18X”消息，并在消息中携带头域require：100rel。资源预置参数可包括当前状态、期望状态、确认状态、预置条件处理类型、状态类型、方向标志等。资源预置参数通常在标准中以qos进行描述。

SIP报头可包括始于(From)头域、到(To)头域、经流(Via)头域、用户代理(User-Agent)头域、请求(Require)头域等。其中，From头域和To头域是请求和响应中包含的头域，From头域指示请求的初始者，To头域指示请求的预定接收者。From头域可以包含一个“tag”参数。如果请求包含了不止一个Via头域，则To头域可增加标签“tag”参数。Via头域指示请求迄今为止所走的路径，可防止请求的循环，同时确保了响应(回答)沿同样的路径返回。User-Agent头域包含了关于发送初始请求的客户用户代理的消息。客户使用Require头域，通知UAS客户希望服务器所支持的选项，以便合适地处理请求。

目前，在IMS域下的用户终端UE从网络设备接收到第一路寻呼请求(例如，INVITE请求)之后，会对第一路寻呼请求进行呼叫连接处理。在UE和第一路寻呼请求对应的主叫终端建立通话连接之前，可能还会收到其他的寻呼请求(例如，第二路寻呼请求和第三路寻呼请求等)。终端设备会处理最先接收到的第一路寻呼消息，对于后续收到的第二路寻呼消息、第三路寻呼消息等，终端设备都会回复拒绝消息(例如，此处太忙消息(486Busy Here，可简称为486消息))。

然而，网络设备的异常会导致sip信令存在堵塞，使得有效的寻呼请求在第三路或第三路之后才发送。终端设备无法感知网络设备的异常，则终端设备直接拒绝后面接收到的寻呼请求，存在拒接有效(或正确)的寻呼请求，而处理无效(或错误)的寻呼请求的情况发生，导致通话建立失败，漏接来电的事件发生。

基于此，本申请实施例提出一种消息处理的方法，能够识别多路寻呼请求中的无效寻呼请求，并释放该无效寻呼请求占用的资源，可提高通话的成功率。

具体的，请参见图6，图6是本申请实施例提供的一种消息处理的方法。该方法可应用于如图2所示的通信系统中，以下以网络设备和被叫终端进行举例说明。该方法包括但不限于如下步骤：

S601：在建立通话连接之前，被叫终端从网络设备接收至少两路寻呼请求。

相应地，网络设备在接收到主叫终端的寻呼请求之后，向寻呼请求的被叫终端发送该寻呼请求。且在被叫终端与主叫终端建立通话连接之前，网络设备都可以向被叫终端转发该被叫终端的寻呼请求。若被叫终端在预设时长内对寻呼请求无反应，则网络设备还可以向被叫终端重发该寻呼请求或寻呼请求的相关消息。

需要说明的是，被叫终端从网络设备接收到的寻呼请求之间存在先后顺序，通常最先收到的寻呼请求称为第一路寻呼请求。在第一路寻呼请求收到之后收到的寻呼请求称为第二路寻呼请求，在第二路寻呼请求收到之后收到的寻呼请求称为第三路寻呼请求等，以此类推。

在本申请实施例中，寻呼请求用于指示被叫终端与寻呼请求对应的主叫终端进行呼叫连接处理，以实现通话连接。寻呼请求可以包括IMS寻呼请求。也就是说，该寻呼请求可以为基于SIP协议的寻呼请求。寻呼请求还可以包括其他类型的寻呼请求，在此不做限定。

S602：被叫终端对寻呼请求进行呼叫连接处理。

在本申请实施例中，呼叫连接处理可以包括分配资源，即为被叫终端和主叫终端的通话分配资源。呼叫连接处理还可以包括振铃和接听等，在此不做限定。在被叫终端进行振铃处理之后，被叫终端可基于用户设置进行响铃或振动，用户可选择接听或挂断。在用户选择接听之后，被叫终端进行接听处理，以实现通话连接。在呼叫连接处理的过程中，被叫终端可能向网络设备发送100消息、正在拨打消息(180Ringing，可简称为180消息)、通话进展消息(183Session Progress，可简称为183消息)等。

S603：被叫终端向网络设备发送第一响应消息。

相应地，网络设备从被叫终端接收第一响应消息。

在本申请实施例中，第一响应消息用于指示寻呼请求的呼叫进展。第一响应消息可以为18X消息中的至少一种。可选的，第一响应消息为183消息。

S604：在第一预设时长内，若被叫终端接收到网络设备针对寻呼请求的拒绝消息，或未接收到网络设备针对寻呼请求的反馈，则确定所述寻呼请求为无效寻呼请求。

在被叫终端的对端支持PRACK流程的情况下，在被叫终端向网络设备发送第一响应消息之后，被叫终端可以采用定时器基于第一预设时长进行计时。本申请对于第一预设时长不做限定，可以为固定的数值，例如，3秒等。或者第一预设时长基于网络设备的服务质量参数、路损因子、发射功率、功率调整因子等参数进行确定，在此不做限定。

在本申请实施例中，反馈包括但不限于以下至少一种：拒绝消息和临时响应消息(例如，PRACK消息)。其中，拒绝消息表示网络设备拒绝响应第一响应消息的呼叫进展，临时响应消息表示网络设备允许执行第一响应消息对应的呼叫连接处理步骤。

可以理解，网络设备在收到第一响应消息之后，可拒绝或响应该第一响应消息的呼叫进展。若网络设备回复临时响应消息，以指示收到第一响应消息，且正在进行第一响应消息对应的呼叫进展的下一步的处理。进一步表示网络设备无异常，可以完成通话连接，可以确定该寻呼请求为有效寻呼请求，从而可执行该有效寻呼请求中未完成的呼叫连接处理步骤。若网络设备回复拒绝消息，以指示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以完成通话连接，可以确定该寻呼请求为无效寻呼请求，从而可释放该无效寻呼请求占用的资源。或者若网络设备没有回复任何消息，即没有回复拒绝消息或临时响应消息中的至少一种，则可以表示网络设备出现异常或表示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以完成通话连接，可以确定该寻呼请求为无效寻呼请求，也可释放该无效寻呼请求占用的资源。

在本申请实施例中，网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤的情况，可包括网络设备解析第一响应消息失败和网络设备确定该第一响应消息满足丢弃情况等，在此不做限定。例如，网络设备升级后，可能对终端的183消息中User-Agent头域解析失败，导致网络设备不会向被叫终端回复183消息的反馈。又例如，网络设备收到基于UDP的INVITE请求，被叫终端通常也会响应INVITE请求，向网络设备发送基于UDP的183消息。而网络设备中的演进型分组数据网关(evolved packet data gateway)因为最大传输单元(maximum transmission unit，MTU)的限制，对于超过预设容量的消息直接丢弃。如此，在网络设备确定该183消息的容量大于预设容量时，会直接丢弃该183消息，导致网络设备不会向被叫终端回复183消息的反馈。

需要说明的是，被叫终端针对每一路寻呼请求，均发送一个指示该寻呼请求的呼叫进展的第一响应消息。在发送给网络设备之后，分别进行计时。举例来说，寻呼请求中的第一路寻呼请求的第一响应消息的发送时间为10点24分00秒，第二路寻呼请求的第一响应消息的发送时间为10点24分02秒，第三路寻呼请求的第一响应消息的发送时间为10点24分03秒。假设第一预设时长为3秒，则在10点24分00秒～10点24分03秒内，确定是否收到第一路寻呼请求的反馈。在10点24分03秒～10点24分06秒内，确定是否收到第三路寻呼请求的反馈。

S605：被叫终端释放无效寻呼请求占用的资源。

在图6所描述的方法中，在被叫终端建立通话连接之前，若被叫终端从网络设备接收到至少两路寻呼请求，则可以先假设网络设备支持每一寻呼请求，则对每一路的寻呼请求进行呼叫连接处理，可得到每一路寻呼请求分配的资源。再分别向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第一预设时长内，确定是否收到网络设备针对寻呼请求的反馈。若被叫终端接收到网络设备针对该寻呼请求的拒绝消息，则可以表示该寻呼请求对应的网络设备不支持执行该寻呼请求对应的呼叫连接步骤，可以确定该寻呼请求为无效寻呼请求。若被叫终端未接收到网络设备针对该寻呼请求的反馈，则可以表示网络设备出现异常，或表示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以正常通信，可以确定该寻呼请求为无效寻呼请求。在确定无效寻呼请求之后，可以释放该无效寻呼请求占用的资源，可避免处理无效寻呼请求的情况发生，有利于提高通话的成功率。

在一种可能的示例中，在步骤S605之后，还可包括以下步骤：被叫终端向网络设备发送第二响应消息。

相应地，网络设备从被叫终端接收第二响应消息。然后，网络设备向寻呼请求对应的主叫终端发送第二响应消息，以告知该主叫终端被叫终端为忙线状态。

在本申请实施例中，第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态，可以包括486消息等，在此不做限定。可以理解，在释放无效寻呼请求占用的资源后，不再执行该无效寻呼请求的呼叫连接步骤，从而不会实现无效寻呼请求的通话连接。被叫终端可以向网络设备发送被叫终端对于该无效寻呼请求为忙线状态的指示信息，以提示网络设备不需再响应该无效寻呼请求，有利于提高网络设备的处理效率。且网络设备还可告知该无效寻呼请求的主叫终端，以提示稍后通信等信息。

请参见图7，图7是本申请实施例提供的另一种消息处理的方法。该方法也可应用于如图2所示的通信系统中，以下以网络设备和被叫终端进行举例说明。该方法包括但不限于如下步骤：

S701：在通话连接之前，被叫终端从网络设备接收至少两路寻呼请求。

S702：被叫终端对寻呼请求进行呼叫连接处理。

S703：被叫终端向网络设备发送第一响应消息。

S704：在第一预设时长内，若被叫终端接收到网络设备针对寻呼请求的临时响应消息，则确定寻呼请求为有效寻呼请求。

在本申请实施例中，寻呼请求可以包括IMS寻呼请求。呼叫连接处理可以包括分配资源，第一响应消息用于指示所述寻呼请求的呼叫进展，反馈包括但不限于以下至少一种：拒绝消息和临时响应消息。步骤S701～S704具体可参照步骤S601～S604的描述，在此不再赘述。

需要说明的是，步骤S704和步骤S604可以基于被叫终端向网络设备发送寻呼请求的第一响应消息的先后顺序和收到反馈的情况执行。例如，寻呼请求中的第一路寻呼请求的第一响应消息的发送时间为10点24分00秒，第二路寻呼请求的第一响应消息的发送时间为10点24分02秒。若第一预设时长为3秒，则在10点24分00秒～10点24分03秒内，确定是否收到第一路寻呼请求的反馈。在10点24分02秒～10点24分05秒内，确定是否收到第二路寻呼请求的反馈。假设在10点24分02秒时，接收到第一路寻呼请求的临时响应消息，则确定第一路寻呼请求为有效寻呼请求。假设在10点24分03秒时，没有接收到第二路寻呼请求的临时响应消息，或接收到第二路寻呼请求的拒绝消息，则确定第二路寻呼请求为无效寻呼请求。

在图7所描述的方法中，在被叫终端建立通话连接之前，若被叫终端从网络设备接收到至少两路寻呼请求，则可以先假设网络设备支持每一寻呼请求，则对每一路的寻呼请求进行呼叫连接处理，可得到每一路寻呼请求分配的资源。再分别向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第一预设时长内，确定是否收到网络设备针对寻呼请求的反馈。若被叫终端接收到网络设备针对该寻呼请求的临时响应消息，则可以表示网络设备无异常可以正常通信，可以确定该寻呼请求为有效寻呼请求，从而可以执行有效寻呼请求未完成的呼叫连接处理步骤，有利于提高通话的成功率。

在一种可能的示例中，在步骤S704之后，还包括以下两种情况，其中：

第一种：若有效寻呼请求的数量等于1，则执行被叫终端执行有效寻呼请求未完成的呼叫连接处理步骤。

第二种：若有效寻呼请求的数量大于1，则被叫终端确定有效寻呼请求中最先收到的目标寻呼请求；被叫终端释放有效寻呼请求中除目标寻呼请求之外的有效寻呼请求占用的资源，执行目标寻呼请求未完成的呼叫连接处理步骤。

可以理解，在确定有效寻呼请求之后，先确定有效寻呼请求的数量。该数量应大于或等于1，若有效寻呼请求的数量等于1，则可以执行该有效寻呼请求未完成的呼叫连接处理。若有效寻呼请求的数量大于1(或有效寻呼请求的数量为大于或等于2的整数)，则表示有多路有效寻呼请求。可以选取多路有效寻呼请求中最早收到的目标寻呼请求，再执行该目标寻呼请求未完成的呼叫连接处理步骤，并释放有效寻呼请求中除目标寻呼请求之外的有效寻呼请求占用的资源。如此，可避免后续的有效寻呼请求为先收到的有效寻呼请求的重发消息，造成的重复建立通话连接。且先建立最先收到的有效寻呼请求的通话连接，满足通话顺序，有利于提高通话的成功率和建立通话的准确率。

在本申请实施例中，后续未完成的呼叫连接过程可以包括：网络设备向被叫终端发送UPDATE请求，被叫终端以200消息回复UPDATE请求。被叫终端再振铃，并向网络设备发送180消息，以告知网络设备正在拨打。在被叫终端的用户接听之后，被叫终端可以向网络设备发送200消息，以确认通话建立成功。网络设备可以以ACK请求回复该200消息。用户挂断之后，被叫终端可以向网络设备发送BYE请求，网络设备可以以200消息回复该BYE请求，以确认通话结束。

需要说明的是，在释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源之后，还可包括向网络设备发送被叫终端对于所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求为忙线状态。如此，以提示网络设备不需再响应该无效寻呼请求，有利于提高网络设备的处理效率。且网络设备还可告知该无效寻呼请求对应的主叫终端，以提示稍后通信等信息。

请参见图8，图8是本申请实施例提供的又一种消息处理的方法。该方法也可应用于如图2所示的通信系统中，以下以网络设备和被叫终端进行举例说明。该方法包括但不限于如下步骤：

S801：在建立通话连接之前，被叫终端从网络设备接收寻呼请求。

S802：被叫终端对寻呼请求进行呼叫连接处理。

S803：被叫终端向网络设备发送第一响应消息。

在本申请实施例中，寻呼请求可包括IMS寻呼请求。本申请对于寻呼请求的类型和数量不做限定，也就是说，被叫终端可以接收到一路寻呼请求，或者可如图6和图7所示的方法中，接收至少两路寻呼请求。呼叫连接处理可以包括分配资源，第一响应消息用于指示寻呼请求的呼叫进展。步骤S801～S803可参照步骤S601～S603的描述，在此不再赘述。

在一个可能的示例中，在步骤S803之后，还包括以下步骤：在第二预设时长内，若被叫终端接收到网络设备针对寻呼请求的拒绝消息，则释放所述寻呼请求占用的资源。如此，可避免处理无效的寻呼请求的情况发生，有利于提高通话的成功率和建立通话的准确率。

在一种可能的示例中，在释放所述寻呼请求占用的资源之后，还可包括以下步骤：被叫终端向网络设备发送忙线响应消息。

相应地，网络设备从被叫终端接收忙线响应消息。然后，网络设备向寻呼请求对应的主叫终端发送忙线响应消息，以告知该主叫终端，被叫终端对于在第二预设时长内被叫终端接收到网络设备针对寻呼请求的拒绝消息的寻呼请求为忙线状态。

在该示例中，忙线响应消息可以包括486消息等，在此不做限定。可以理解，在释放寻呼请求占用的资源后，不再执行该寻呼请求的呼叫连接步骤，从而不会实现该寻呼请求的通话连接。被叫终端可以向网络设备发送被叫终端对于该寻呼请求为忙线状态的指示信息，以提示网络设备不需再响应该寻呼请求，有利于提高网络设备的处理效率。且网络设备还可告知该寻呼请求的主叫终端，以提示稍后通信等信息。

S804：在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的反馈，则对第一响应消息进行修改，得到至少一个第三响应消息。

在本申请实施例中，反馈包括但不限于以下至少一种：拒绝消息和临时响应消息。本申请对于第二预设时长不做限定，该第二预设时长可以等于或不等于第一预设时长。第二预设时长可以为固定的数值，例如，5秒。或者在一种可能的示例中，根据寻呼请求的协议类型确定第二预设时长。

本申请对于寻呼请求的协议类型不做限定，在寻呼请求为IMS寻呼请求时，寻呼请求的协议类型可以为UDP或TCP。可以理解，不同协议类型的寻呼请求的解析时长不同，例如，由于UDP对应的数据包相对TCP对应的数据包较大，则基于UDP的寻呼请求的解析时长应大于基于TCP的寻呼请求的解析时长，从而可设置基于UDP的寻呼请求的第二预设时长大于基于TCP的寻呼请求的第二预设时长。如此，根据寻呼请求的协议类型确定不同寻呼请求的第二预设时长，可提高确定第一响应消息是否无效的准确率，有利于提高通信的成功率。

可选的，若寻呼请求的协议类型为UDP，则第二预设时长大于3*T1，且小于4*T1，其中，所述T1为第一计时器的预设时长。

其中，第一计时器用于重发消息，T1通常为500毫秒。每一次重发消息的预设时长可以为T1，2*T1，4*T1，8*T1等。重发消息的时长的最大值可小于第二计时器的预设时长T2，T2通常为4秒。举例来说，在被叫终端向网络设备发送响应消息之后，在第一计时器的预设时长内，若未接收到网络设备的反馈，则重复该响应消息。

可以理解，在该示例中，基于UDP的协议类型确定第二预设时长，可提高第一响应消息是否无效的准确率，有利于提高通信的成功率。

可选的，若寻呼请求的协议类型TCP，则第二预设时长大于5秒，且小于6秒。如此，基于TCP的协议类型确定第二预设时长，可提高第一响应消息是否无效的准确率，有利于提高通信的成功率。

如前所述，在被叫终端向网络设备发送第一响应消息之后，若网络设备没有反馈，则可以表示网络设备出现异常，或表示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以完成通话连接，可以确定该寻呼请求为无效寻呼请求，也可释放该无效寻呼请求占用的资源。因此，可以在第二预设时长内，若未接收到网络设备针对寻呼请求的反馈，则修改第一响应消息，得到第三响应消息。再将第三响应消息发送给网络设备，以试探网络设备是否对第三响应消息有反应。在发送第三响应消息之后的第二预设时长内，确定被叫终端是否收到寻呼请求的反馈。若被叫终端接收到网络设备针对寻呼请求的临时响应消息，则执行寻呼请求未完成的呼叫连接处理步骤。若被叫终端接收到网络设备针对寻呼请求的拒绝消息，则可以释放该寻呼请求占用的资源。若被叫终端未接收到网络设备针对寻呼请求的反馈，则可以修改第三响应消息，再发送修改的第三响应消息，直至接收到网络设备针对该第三响应消息的反馈，或者在满足预设条件时，结束修改的步骤。

在本申请实施例中，预设条件可以包括已没有可修改的第三响应消息，或与第一响应消息的发送时间的时间间隔超过一个预设的时长(可以为第一预设时长，或者可以为大于第二预设时长的时长)等，在此不做限定。在满足预设条件时，还可以释放该无效寻呼请求占用的资源。

本申请对于修改第一响应消息的方法不做限定，可以包括以下两种情况，其中：

第一种，被叫终端对第一响应消息的目标参数进行修改，得到至少一个第三响应消息。

在本申请实施例中，目标参数的目标类型包括以下至少一项：User-Agent头域、Require头域、音视频媒体参数类型、资源预置参数；若所述第一响应消息基于UDP，则所述目标类型包括协议类型，所述第三响应消息基于TCP。

举一个例子来说，假设第一响应消息为183消息。网络设备升级后，可能对终端的183消息中User-Agent头域解析失败。因此，修改183消息中的User-Agent头域，得到第三响应消息。若第三响应消息的第二预设时长内，接收到网络设备的临时响应消息，则可以执行后续未完成的呼叫连接过程。

再举一个例子，假设第一响应消息为183消息，如前所述，在网络设备接收到基于UDP的183消息之后，可能基于MTU的限制会丢弃该183消息。因此，将基于UDP的183消息修改为基于TCP的183消息，得到第三响应消息。若第三响应消息的第二预设时长内，接收到网络设备的临时响应消息，则可以执行后续未完成的呼叫连接过程。

可以理解，在同一个对话内，在修改第一响应消息的目标参数之后，可得到不同的第三响应消息。通过修改后的第三响应消息对网络设备进行试探，在试探成功时完成剩余的呼叫处理步骤，有利于提高通话连接的成功率。

在第一种修改方法中，第三响应消息的数量可以为1个或多个。在一种可能的示例中，在步骤S805之后，还包括以下步骤：在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，且存在下一个所述第三响应消息，则向所述网络设备发送下一个所述第三响应消息。

可以理解，在第三响应消息的数量为多个时，可以预先设置第三响应消息的发送顺序。即在第三响应消息未收到反馈时，再发送下一个第三响应消息，可进一步提高通话连接的成功率。本申请对于第三响应消息的发送顺序不做限定，可以基于网络设备中修改目标参数的成功率进行确定等。

举例来说，如图9所示，在被叫终端接收到网络设备发送的寻呼请求(例如，IMS寻呼请求中的INVITE请求)之后，被叫终端向网络设备发送100消息，以告知网络设备已收到INVITE请求，正在进行下一步的处理。然后，被叫终端向网络设备发送第一响应消息(例如，183消息)。在第一响应消息发送之后的第二预设时长内，未接收到网络设备的反馈。被叫终端可以向网络设备发送第一响应消息的修改消息，即修改后的第三响应消息。在该第三响应消息发送之后的第二预设时长内，未接收到网络设备的反馈。被叫终端可以向网络设备发送第一响应消息的另一修改消息，即下一个第三响应消息。在下一个第三响应消息发送之后的第二预设时长内，接收到网络设备发送的临时响应消息。被叫终端可以以200消息回复网络设备的临时响应消息，以确认成功应答。也就是说，在未修改To头域的tag参数的基础上，通过修改响应消息中的参数对网络试探成功，以使网络设备和被叫终端可以完成后续的呼叫连接步骤。

第二种，包括以下步骤A1～A3，其中：

A1：返回执行步骤S802，得到新分配的第一资源。

A2：被叫终端根据所述第一资源确定To头域的第一tag参数。

A3：被叫终端对所述第一响应消息的第一参数和所述第一tag参数进行修改，得到第三响应消息。

在本申请实施例中，第一参数的类型为目标类型，可参照上述的描述，在此不再赘述。

可以理解，重新执行步骤S802，会建立新的对话，被叫终端会重新分配资源。根据新分配的第一资源确定第一响应消息的To头域的第一tag参数。再对第一响应消息的第一参数和第一tag参数进行修改，得到第三响应消息。根据新分配的第一资源确定第一响应消息的To头域的第一tag参数。再对第一响应消息的第一参数和第一tag参数进行修改，得到第三响应消息。在发送第三响应消息之后，可以理解为被叫终端虚拟出的另一个终端发送第三响应消息。再基于网络设备是否对该终端是否有反馈，来确定网络设备是否能支持未完成的呼叫连接步骤。如此，通过虚拟出新的终端和修改的响应消息，在不同的对话内对网络设备进行试探，有利于提高通话连接的成功率。

需要说明的是，第二种方法中第三响应消息的数量为1，即不存在下一个第三响应消息。

在步骤S805之后，在一种可能的示例中，还包括以下步骤A4～A7，其中：

A4：在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的反馈，则返回执行步骤S802，得到新分配的第二资源。

A5：被叫终端根据第二资源确定To头域的第二tag参数。

A6：被叫终端对第三响应消息的第二参数和第二tag参数进行修改，得到第四响应消息。

A7：被叫终端向网络设备发送第四响应消息。

在本申请实施例中，第二参数的类型为目标类型，可参照上述的描述，在此不再赘述。需要说明的是，第二参数的类型可以与第一参数的类型相同或不同。当第二参数的类型可以与第一参数的类型相同时，第二参数的数值应与第一参数的数值不同。

可以理解，在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的反馈，则再次执行步骤S802，再建立一个新的对话，可以得到的新分配的第二资源。根据新分配的第二资源确定第一响应消息的To头域的第二tag参数。再对第一响应消息的第二参数和第二tag参数进行修改，得到第四响应消息。在发送第四响应消息之后，可以得到新的对话，可以理解为被叫终端虚拟出的另一个终端发送第四响应消息。再基于网络设备是否对该终端有反馈，来确定网络设备是否能支持未完成的呼叫连接步骤。若还是未收到反馈，则再次执行A4～A7的步骤，直至接收到网络设备的反馈或在满足预设条件时，结束修改的步骤。如此，通过修改响应消息试探网络设备，有利于提高通话连接的成功率。

在一种可能的示例中，在步骤S803之后，还包括以下步骤：在第三预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述向所述网络设备发送第一响应消息的步骤。

其中，第三预设时长小于第二预设时长，第三预设时长可以为上述的T1。可以理解，在第二种修改方法中，由于修改了To头域的tag参数，创建了新的对话，则在第一响应消息对应的对话中，还可重新发送第一响应消息，以确认是否为网络异常造成的无反馈。且在第一响应消息之后的第三预设时长内，若接收到网络设备的临时响应消息，则可执行未完成的呼叫连接处理步骤。若接收到网络设备的拒绝消息，则可释放该寻呼请求占用的资源。若未接收到网络设备的反馈，则可在第三预设时长到达时，或2倍第三预设时长等其他时长到达时，进行重发。如此，通过重发第一响应消息，有利于提高通话连接的成功率。

举例来说，如图10所示，在被叫终端接收到网络设备发送的寻呼请求(例如，INVITE请求)之后，被叫终端向网络设备发送100消息，以告知网络设备已收到寻呼请求，正在进行下一步的处理。然后，被叫终端向网络设备发送第一响应消息(例如，183消息)。在第一响应消息发送之后的第三预设时长内，未接收到网络设备的反馈，被叫终端可以向网络设备重传第一响应消息。也就是说，第一个dialog网络设备无响应，被叫终端重传第一响应消息。在第一个第一响应消息发送之后的第二预设时长内，未接收到网络设备的反馈。被叫终端可以建立一个新的对话，得到新的To头域的tag参数，并修改第一响应消息中的第一参数，得到修改后的第三响应消息。在第三响应消息发送之后的第二预设时长内，若接收到网络设备发送的临时响应消息。被叫终端可以以200消息回复网络设备的临时响应消息，以确认成功应答。也就是说，在第二个dialog网络设备正常响应。如此，在第一次修改To头域的tag参数的基础上，通过修改响应消息中的参数对网络试探成功，以使网络设备和被叫终端可以完成后续的呼叫连接步骤(图10中未示出)。

S805：被叫终端向网络设备发送第三响应消息。

在一个可能的示例中，在步骤S805之后，还包括以下步骤：在所述第二预设时长内，若被叫终端接收到网络设备针对寻呼请求的拒绝消息，则释放所述寻呼请求占用的资源。如此，可避免处理无效的寻呼请求的情况发生，有利于提高通话的成功率和建立通话的准确率。

在一种可能的示例中，在释放所述寻呼请求占用的资源之后，还可包括以下步骤：被叫终端向网络设备发送忙线响应消息。如此，被叫终端可以向网络设备发送被叫终端对于该寻呼请求为忙线状态的指示信息，以提示网络设备不需再响应该寻呼请求，有利于提高网络设备的处理效率。且网络设备还可告知该寻呼请求的主叫终端，以提示稍后通信等信息。

S806：在第二预设时长内，若被叫终端接收到网络设备针对寻呼请求的临时响应消息，且执行寻呼请求未完成的呼叫连接处理步骤。

在图8所示的方法中，在建立通话连接之前，若被叫终端从网络设备接收到寻呼请求，则可以进行呼叫连接处理。再向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第二预设时长内，若未接收到网络设备针对该寻呼请求的反馈，则可以修改该响应消息，并发送修改后的响应消息，以试探网络设备是否支持修改后的响应消息。若在修改后的响应消息发送之后的第二预设时长内，接收到网络设备针对该寻呼请求的临时响应消息，则可以执行该寻呼请求未完成的呼叫连接处理步骤。如此，通过不同的响应消息试探网络设备，有利于提高通话的成功率。

上述详细阐述了本申请实施例的方法，下面提供了本申请实施例的装置。

请参见图11，图11是本申请实施例提供的一种通信装置的结构示意图，该通信装置1100可以包括收发单元1101和处理单元1102。该通信装置1100可以为被叫终端、网络设备或主叫终端中的至少一个。

当通信装置1100为被叫终端时，在一个实施例中，收发单元1101用于在建立通话连接之前，从网络设备接收至少两路寻呼请求，所述寻呼请求包括IMS寻呼请求；

处理单元1102用于对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

所述收发单元1101还用于向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

所述处理单元1102还用于在第一预设时长内，若接收到所述网络设备针对所述寻呼请求的拒绝消息，或未接收到所述网络设备针对所述寻呼请求的反馈，则确定所述寻呼请求为无效寻呼请求，所述反馈包括所述拒绝消息和临时响应消息中的至少一种；释放所述无效寻呼请求占用的资源。

在一种可能的示例中，所述处理单元1102还用于在所述第一预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则确定所述寻呼请求为有效寻呼请求。

在一种可能的示例中，所述处理单元1102还用于若所述有效寻呼请求的数量等于1，则执行所述有效寻呼请求未完成的呼叫连接处理步骤；或者若所述有效寻呼请求的数量大于1，则确定所述有效寻呼请求中最先收到的目标寻呼请求；释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源，执行所述目标寻呼请求未完成的呼叫连接处理步骤。

在一种可能的示例中，所述收发单元1101还用于向所述网络设备发送第二响应消息，所述第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态。

当通信装置1100为被叫终端时，在另一个实施例中，收发单元1101用于在建立通话连接之前，从网络设备接收寻呼请求，所述寻呼请求包括IMS寻呼请求；

处理单元1102用于对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

所述收发单元1101还用于向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

所述处理单元1102还用于在第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则对所述第一响应消息进行修改，得到至少一个第三响应消息，所述反馈包括以下至少一种：临时响应消息和拒绝消息；

所述收发单元1101还用于向所述网络设备发送所述第三响应消息；

所述处理单元1102还用于在所述第二预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则执行所述寻呼请求未完成的呼叫连接处理步骤。

在一种可能的示例中，所述处理单元1102具体用于对所述第一响应消息的目标参数进行修改，得到至少一个第三响应消息，所述目标参数的目标类型包括以下至少一项：用户代理User-Agent头域、请求Require头域、音视频媒体参数类型、资源预留参数；若所述寻呼请求基于用户数据报协议UDP，则所述目标类型包括协议类型，所述第三响应消息基于传输控制协议TCP。

在一种可能的示例中，所述收发单元1101还用于在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，且存在下一个所述第三响应消息，则向所述网络设备发送下一个所述第三响应消息。

在一种可能的示例中，所述处理单元1102具体用于返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第一资源；根据所述第一资源确定To头域的第一tag参数；对所述第一响应消息的第一参数和所述第一tag参数进行修改，得到第三响应消息，所述第一参数的目标类型包括以下至少一项：User-Agent头域、Require头域、音视频媒体参数类型、资源预置参数；若所述寻呼请求基于UDP，则所述目标类型包括协议类型，所述第三响应消息基于TCP。

在一种可能的示例中，所述处理单元1102还用于在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第二资源；根据所述第二资源确定所述To头域的第二tag参数；对所述第三响应消息的第二参数和所述第二tag参数进行修改，得到第四响应消息，所述第二参数的类型为所述目标类型；向所述网络设备发送所述第四响应消息。

在一个可能的示例中，所述处理单元1102还用于在第二预设时长内，若被叫终端未接收到网络设备针对寻呼请求的拒绝消息，则释放所述寻呼请求占用的资源。

在一种可能的示例中，所述处理单元1102还用于在所述第一响应消息发送之后的第三预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述向所述网络设备发送第一响应消息的步骤，所述第三预设时长小于所述第二预设时长。

在一种可能的示例中，所述处理单元1102还用于根据所述寻呼请求的协议类型确定所述第二预设时长。

在一种可能的示例中，若所述寻呼请求基于UDP，则所述第二预设时长大于3*T1，且小于4*T1，其中，所述T1为第一计时器的预设时长。

在一种可能的示例中，若所述寻呼请求基于TCP，则所述第二预设时长大于5秒，且小于6秒。

当通信装置1100为网络设备时，收发单元1101用于在建立通话连接之前，向被叫终端发送至少两路寻呼请求，所述寻呼请求包括IMS寻呼请求；从所述被叫终端接收第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展。

在一种可能的示例中，收发单元1101还用于向所述被叫终端发送针对所述寻呼请求的反馈，所述反馈包括以下至少一种：拒绝消息和临时响应消息。

当通信装置1100为主叫终端时，收发单元1101用于向网络设备发送寻呼请求。

需要说明的是，各个单元的实现还可以对应参照图6、图7或图8所示的方法实施例的相应描述。

请参见图12，图12是本申请实施例提供的另一种通信装置1200的结构示意图。该通信装置1200包括处理器1201、存储器1202和通信接口1203，所述处理器1201、存储器1202和通信接口1203通过总线1204相互连接。

存储器1202包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmableread only memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)，该存储器1202用于相关计算机程序及数据。通信接口1203用于接收和发送数据。

处理器1201可以是一个或多个中央处理器(central processing unit，CPU)，在处理器1201是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

该通信装置1200中的处理器1201用于读取所述存储器1202中存储的计算机程序代码。该通信装置1200可以为被叫终端、网络设备或主叫终端中的至少一个。当通信装置1200为被叫终端时，在一个实施例中，处理器1201可以执行以下操作：

在建立通话连接之前，从网络设备接收至少两路寻呼请求，所述寻呼请求包括IMS寻呼请求；

对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

在第一预设时长内，若接收到所述网络设备针对所述寻呼请求的拒绝消息，或未接收到所述网络设备针对所述寻呼请求的反馈，则确定所述寻呼请求为无效寻呼请求，所述反馈包括所述拒绝消息和临时响应消息中的至少一种；

释放所述无效寻呼请求占用的资源。

在一种可能的示例中，处理器1201还用于执行如下操作：

在所述第一预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则确定所述寻呼请求为有效寻呼请求。

在一种可能的示例中，处理器1201还用于执行如下操作：

若所述有效寻呼请求的数量等于1，则执行所述有效寻呼请求未完成的呼叫连接处理步骤；或者

若所述有效寻呼请求的数量大于1，则确定所述有效寻呼请求中最先收到的目标寻呼请求；释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源，执行所述目标寻呼请求未完成的呼叫连接处理步骤。

在一种可能的示例中，处理器1201还用于执行如下操作：

向所述网络设备发送第二响应消息，所述第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态。

在另一个实施例中，处理器1201可以执行以下操作：

在建立通话连接之前，从网络设备接收寻呼请求，所述寻呼请求包括IMS寻呼请求；

对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

在第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则对所述第一响应消息进行修改，得到至少一个第三响应消息，所述反馈包括以下至少一种：临时响应消息和拒绝消息；

向所述网络设备发送所述第三响应消息；

在所述第二预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则执行所述寻呼请求未完成的呼叫连接处理步骤。

在一个可能的示例中，处理器1201具体用于执行以下步骤：

对所述第一响应消息的目标参数进行修改，得到至少一个第三响应消息，所述目标参数的目标类型包括以下至少一项：用户代理User-Agent头域、请求Require头域、音视频媒体参数类型、资源预留参数；若所述第一响应消息基于用户数据报协议UDP，则所述目标类型包括协议类型，所述第三响应消息基于传输控制协议TCP。

在一个可能的示例中，处理器1201还用于执行以下步骤：

在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，且存在下一个所述第三响应消息，则向所述网络设备发送下一个所述第三响应消息。

在一个可能的示例中，处理器1201具体用于执行以下步骤：

返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第一资源；

根据所述第一资源确定到达To头域的第一标签tag参数；

对所述第一响应消息的第一参数和所述第一tag参数进行修改，得到第三响应消息，所述第一参数的目标类型包括以下至少一项：User-Agent头域、Require头域、音视频媒体参数类型、资源预置参数；若所述第一响应消息基于UDP，则所述第一参数的类型包括协议类型，所述第三响应消息基于TCP。

在一个可能的示例中，处理器1201还用于执行以下步骤：

在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第二资源；

根据所述第二资源确定所述To头域的第二tag参数；

对所述第一响应消息的第二参数和所述第二tag参数进行修改，得到第四响应消息，所述第二参数的类型为所述目标类型；

向所述网络设备发送所述第四响应消息。

在一个可能的示例中，处理器1201还用于执行以下步骤：

在第三预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述向所述网络设备发送第一响应消息的步骤，所述第三预设时长小于所述第二预设时长。

在一个可能的示例中，处理器1201还用于执行以下步骤：

根据所述寻呼请求的协议类型确定所述第二预设时长。

在一个可能的示例中，若所述寻呼请求的协议类型为UDP，则所述第二预设时长大于3*T1，且小于4*T1，其中，所述T1为第一计时器的预设时长。

在一个可能的示例中，若所述寻呼请求的协议类型TCP，则所述第二预设时长大于5秒，且小于6秒。

当通信装置1200为网络设备时，处理器1201可以用于执行以下步骤：

在建立通话连接之前，向被叫终端发送至少两路寻呼请求，所述寻呼请求包括IP多媒体子系统IMS寻呼请求；从所述被叫终端接收第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展。

在一种可能的示例中，处理器1201还用于执行以下步骤：

向所述被叫终端发送针对所述寻呼请求的反馈，所述反馈包括以下至少一种：拒绝消息和临时响应消息。

当通信装置为主叫终端时，处理器1201可以用于执行以下步骤：

向网络设备发送寻呼请求。

需要说明的是，各个操作的实现还可以对应参照图6、图7或图8所示的方法实施例的相应描述。

本申请实施例还提供第一种芯片，包括处理器和存储器，所述处理器用于从所述存储器中调用并运行所述存储器中存储的指令，使得安装有所述芯片的设备执行图6、图7或图8所示的方法。

本申请实施例还提供第二种芯片，包括：输入接口、输出接口和处理电路，其中，所述输入接口、所述输出接口与所述处理电路之间通过内部连接通路相连，所述处理电路用于执行图6、图7或图8所示的方法。

本申请实施例还提供第三种芯片，包括：输入接口、输出接口、处理器，可选的，还包括存储器，其中，所述输入接口、所述输出接口、所述处理器以及所述存储器之间通过内部连接通路相连，所述处理器用于执行所述存储器中的代码，当所述代码被执行时，所述处理器用于执行图6、图7或图8所示的方法。

本申请实施例还提供一种芯片系统，所述芯片系统包括至少一个处理器，存储器和接口电路，所述存储器、所述收发器和所述至少一个处理器通过线路互联，所述至少一个存储器中存储有指令；所述指令被所述处理器执行时，图6、图7或图8所示的方法流程得以实现。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，图6、图7或图8所示的方法流程得以实现。

本申请实施例还提供一种计算机程序产品，所述计算机程序产品用于存储计算机程序，当所述计算机程序在计算机上运行时，图6、图7或图8所示的方法流程得以实现。

本申请实施例还提供一种芯片系统，所述芯片系统包括至少一个处理器，存储器和接口电路，所述存储器、所述收发器和所述至少一个处理器通过线路互联，所述至少一个存储器中存储有指令；所述指令被所述处理器执行时，图6、图7或图8所示的方法流程得以实现。

综上所述，通过实施本申请实施例，在被叫终端建立通话连接之前，若被叫终端从网络设备接收到至少两路寻呼请求，则可以先假设网络设备支持每一寻呼请求，则对每一路的寻呼请求进行呼叫连接处理，可得到每一路寻呼请求分配的资源。再分别向网络设备发送指示寻呼请求的呼叫进展的响应消息。在发送响应消息之后的第一预设时长内，确定是否收到网络设备针对寻呼请求的反馈。若被叫终端接收到网络设备针对该寻呼请求的拒绝消息，则可以表示该寻呼请求对应的网络设备不支持执行该寻呼请求对应的呼叫连接步骤，可以确定该寻呼请求为无效寻呼请求。若被叫终端未接收到网络设备针对该寻呼请求的反馈，则可以表示网络设备出现异常，或表示网络设备不支持继续执行该寻呼请求对应的呼叫连接步骤，难以正常通信，可以确定该寻呼请求为无效寻呼请求。在确定无效寻呼请求之后，可以释放该无效寻呼请求占用的资源，可避免处理无效寻呼请求的情况发生。若被叫终端接收到网络设备针对该寻呼请求的临时响应消息，则可以表示网络设备无异常可以正常通信，可以确定该寻呼请求为有效寻呼请求，从而可执行该有效寻呼请求未完成的呼叫连接步骤。如此，有利于提高通话的成功率。

在另一方面，在被叫终端从网络设备接收到寻呼请求之后。对该寻呼请求进行呼叫连接处理，并向网络设备发送响应消息。在第二预设时长内，若未接收到网络设备针对该寻呼请求的反馈，则可以修改该响应消息，并发送修改后的响应消息，以试探网络设备是否支持修改后的响应消息。如此，通过不同的响应消息试探网络设备，有利于提高通话的成功率。

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

Claims (29)

1.一种消息处理的方法，其特征在于，包括：

在建立通话连接之前，从网络设备接收至少两路寻呼请求，所述寻呼请求包括IP多媒体子系统IMS寻呼请求；

对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

在第一预设时长内，若接收到所述网络设备针对所述寻呼请求的拒绝消息，或未接收到所述网络设备针对所述寻呼请求的反馈，则确定所述寻呼请求为无效寻呼请求，所述反馈包括所述拒绝消息和临时响应消息中的至少一种；

释放所述无效寻呼请求占用的资源。

2.根据权利要求1所述的方法，其特征在于，在所述向所述网络设备发送第一响应消息之后，所述方法还包括：

在所述第一预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则确定所述寻呼请求为有效寻呼请求。

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

若所述有效寻呼请求的数量等于1，则执行所述有效寻呼请求未完成的呼叫连接处理步骤；或者

若所述有效寻呼请求的数量大于1，则确定所述有效寻呼请求中最先收到的目标寻呼请求；释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源，执行所述目标寻呼请求未完成的呼叫连接处理步骤。

4.根据权利要求1-3中任一项所述的方法，其特征在于，在所述释放所述无效寻呼请求占用的资源之后，所述方法还包括：

向所述网络设备发送第二响应消息，所述第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态。

5.一种消息处理的方法，其特征在于，包括：

在建立通话连接之前，从网络设备接收寻呼请求，所述寻呼请求包括IMS寻呼请求；

对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

在第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则对所述第一响应消息进行修改，得到至少一个第三响应消息，所述反馈包括以下至少一种：临时响应消息和拒绝消息；

向所述网络设备发送所述第三响应消息；

在所述第二预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则执行所述寻呼请求未完成的呼叫连接处理步骤。

6.根据权利要求5所述的方法，其特征在于，所述对所述第一响应消息进行修改，得到至少一个第三响应消息，包括：

对所述第一响应消息的目标参数进行修改，得到至少一个第三响应消息，所述目标参数的目标类型包括以下至少一项：用户代理User-Agent头域、请求Require头域、音视频媒体参数类型、资源预留参数；若所述第一响应消息基于用户数据报协议UDP，则所述目标类型包括协议类型，所述第三响应消息基于传输控制协议TCP。

7.根据权利要求5或6所述的方法，其特征在于，在所述向所述网络设备发送所述第三响应消息之后，所述方法还包括：

在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，且存在下一个所述第三响应消息，则向所述网络设备发送下一个所述第三响应消息。

8.根据权利要求5所述的方法，其特征在于，在所述对所述第一响应消息进行修改，得到至少一个第三响应消息之前，所述方法还包括：

返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第一资源；

根据所述第一资源确定到达To头域的第一标签tag参数；

所述对所述第一响应消息进行修改，得到至少一个第三响应消息，包括：

对所述第一响应消息的第一参数和所述第一tag参数进行修改，得到第三响应消息，所述第一参数的目标类型包括以下至少一项：User-Agent头域、Require头域、音视频媒体参数类型、资源预置参数；若所述第一响应消息基于UDP，则所述第一参数的类型包括协议类型，所述第三响应消息基于TCP。

9.根据权利要求8所述的方法，其特征在于，在所述向所述网络设备发送所述第三响应消息之后，所述方法还包括：

在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第二资源；

根据所述第二资源确定所述To头域的第二tag参数；

对所述第一响应消息的第二参数和所述第二tag参数进行修改，得到第四响应消息，所述第二参数的类型为所述目标类型；

向所述网络设备发送所述第四响应消息。

10.根据权利要求8或9所述的方法，其特征在于，在所述向所述网络设备发送第一响应消息之后，所述方法还包括：

在第三预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述向所述网络设备发送第一响应消息的步骤，所述第三预设时长小于所述第二预设时长。

11.根据权利要求5-9中任一项所述的方法，其特征在于，所述方法还包括：

根据所述寻呼请求的协议类型确定所述第二预设时长。

12.根据权利要求10所述的方法，其特征在于，若所述寻呼请求的协议类型为UDP，则所述第二预设时长大于3*T1，且小于4*T1，其中，所述T1为第一计时器的预设时长。

13.根据权利要求10所述的方法，其特征在于，若所述寻呼请求的协议类型TCP，则所述第二预设时长大于5秒，且小于6秒。

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

收发单元，用于在建立通话连接之前，从网络设备接收至少两路寻呼请求，所述寻呼请求包括IP多媒体子系统IMS寻呼请求；

处理单元，用于对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

所述收发单元，还用于向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

所述处理单元，还用于在第一预设时长内，若接收到所述网络设备针对所述寻呼请求的拒绝消息，或未接收到所述网络设备针对所述寻呼请求的反馈，则确定所述寻呼请求为无效寻呼请求，所述反馈包括所述拒绝消息和临时响应消息中的至少一种；释放所述无效寻呼请求占用的资源。

15.根据权利要求14所述的通信装置，其特征在于，所述处理单元，还用于在所述第一预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则确定所述寻呼请求为有效寻呼请求。

16.根据权利要求15所述的通信装置，其特征在于，所述处理单元，还用于若所述有效寻呼请求的数量等于1，则执行所述有效寻呼请求未完成的呼叫连接处理步骤；或者若所述有效寻呼请求的数量大于1，则确定所述有效寻呼请求中最先收到的目标寻呼请求；释放所述有效寻呼请求中除所述目标寻呼请求之外的有效寻呼请求占用的资源，执行所述目标寻呼请求未完成的呼叫连接处理步骤。

17.根据权利要求14-16中任一项所述的通信装置，其特征在于，所述收发单元，还用于向所述网络设备发送第二响应消息，所述第二响应消息用于指示被叫终端对于所述无效寻呼请求为忙线状态。

18.一种通信装置，其特征在于，包括：

收发单元，用于在建立通话连接之前，从网络设备接收寻呼请求，所述寻呼请求包括IMS寻呼请求；

处理单元，用于对所述寻呼请求进行呼叫连接处理，所述呼叫连接处理包括分配资源；

所述收发单元，还用于向所述网络设备发送第一响应消息，所述第一响应消息用于指示所述寻呼请求的呼叫进展；

所述处理单元，还用于在第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则对所述第一响应消息进行修改，得到至少一个第三响应消息，所述反馈包括以下至少一种：临时响应消息和拒绝消息；

所述收发单元，还用于向所述网络设备发送所述第三响应消息；

所述处理单元，还用于在所述第二预设时长内，若接收到所述网络设备针对所述寻呼请求的临时响应消息，则执行所述寻呼请求未完成的呼叫连接处理步骤。

19.根据权利要求18所述的通信装置，其特征在于，所述处理单元具体用于对所述第一响应消息的目标参数进行修改，得到至少一个第三响应消息，所述目标参数的目标类型包括以下至少一项：用户代理User-Agent头域、请求Require头域、音视频媒体参数类型、资源预留参数；若所述寻呼请求基于用户数据报协议UDP，则所述目标类型包括协议类型，所述第三响应消息基于传输控制协议TCP。

20.根据权利要求18或19所述的通信装置，其特征在于，所述收发单元，还用于在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，且存在下一个所述第三响应消息，则向所述网络设备发送下一个所述第三响应消息。

21.根据权利要求18所述的通信装置，其特征在于，所述处理单元具体用于返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第一资源；根据所述第一资源确定To头域的第一tag参数；对所述第一响应消息的第一参数和所述第一tag参数进行修改，得到第三响应消息，所述第一参数的目标类型包括以下至少一项：User-Agent头域、Require头域、音视频媒体参数类型、资源预置参数；若所述寻呼请求基于UDP，则所述目标类型包括协议类型，所述第三响应消息基于TCP。

22.根据权利要求20所述的通信装置，其特征在于，所述处理单元还用于在所述第二预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述根据所述寻呼请求进行呼叫连接处理的步骤，得到新分配的第二资源；根据所述第二资源确定所述To头域的第二tag参数；对所述第三响应消息的第二参数和所述第二tag参数进行修改，得到第四响应消息，所述第二参数的类型为所述目标类型；向所述网络设备发送所述第四响应消息。

23.根据权利要求21或22所述的通信装置，其特征在于，所述处理单元还用于在所述第一响应消息发送之后的第三预设时长内，若未接收到所述网络设备针对所述寻呼请求的反馈，则返回执行所述向所述网络设备发送第一响应消息的步骤，所述第三预设时长小于所述第二预设时长。

24.根据权利要求18-23中任一项所述的通信装置，其特征在于，所述处理单元还用于根据所述寻呼请求的协议类型确定所述第二预设时长。

25.根据权利要求24所述的通信装置，其特征在于，若所述寻呼请求基于UDP，则所述第二预设时长大于3*T1，且小于4*T1，其中，所述T1为第一计时器的预设时长。

26.根据权利要求24所述的通信装置，其特征在于，若所述寻呼请求基于TCP，则所述第二预设时长大于5秒，且小于6秒。

27.一种通信装置，其特征在于，包括至少一个处理器、存储器和通信接口，所述处理器用于调用所述存储器中存储的计算机程序，以使得所述通信装置实现如权利要求1-13中任一项所述的方法。

28.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在一个或多个处理器上运行时，实现如权利要求1-13中任一项所述的方法。

29.一种计算机程序产品，其特征在于，所述计算机程序产品在一个或多个处理器上运行时，实现如权利要求1-13中任一项所述的方法。

Images