CN115277614A - 消息处理的方法、设备、存储介质及程序产品 - Google Patents

消息处理的方法、设备、存储介质及程序产品 Download PDF

Info

Publication number
CN115277614A
CN115277614A CN202110472099.5A CN202110472099A CN115277614A CN 115277614 A CN115277614 A CN 115277614A CN 202110472099 A CN202110472099 A CN 202110472099A CN 115277614 A CN115277614 A CN 115277614A
Authority
CN
China
Prior art keywords
message
receipt
multimedia message
multimedia
receiving
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.)
Pending
Application number
CN202110472099.5A
Other languages
English (en)
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.)
Chengdu TD Tech Ltd
Original Assignee
Chengdu TD Tech 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 Chengdu TD Tech Ltd filed Critical Chengdu TD Tech Ltd
Priority to CN202110472099.5A priority Critical patent/CN115277614A/zh
Publication of CN115277614A publication Critical patent/CN115277614A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供一种消息处理的方法、设备、存储介质及程序产品。本申请的方法，通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B‑TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。

Description

消息处理的方法、设备、存储介质及程序产品
技术领域
本申请涉及通信技术，尤其涉及一种消息处理的方法、设备、存储介质及程序产品。
背景技术
目前，宽带集群通信(Broadband Trunking Communication，简称B-TrunC)协议中定义了基于可扩展通讯和表示协议(Extensible Messaging and Presence Protocol，简称XMPP)和超文本传输协议(Hyper Text Transfer Protocol，简称HTTP)协议的短/彩信等多媒体消息的收发流程。
发送端用户可以基于B-TrunC多媒体消息协议向接收端用户发送短/彩信等多媒体消息，并且可以确认消息是否发送成功。但是，发送端用户无法知道接收端用户是否阅读或下载了消息的内容信息。对于发送端用户急需接收端用户阅读消息、但又不便于通过其他方式联系到接收端用户的紧急情况下，会给用户造成极大的不便，无法满足用户需求。
发明内容
本申请提供一种消息处理的方法、设备、存储介质及程序产品，用以解决发送端用户无法知道接收端用户是否阅读或下载了消息的内容信息，无法满足用户需求的问题。
第一方面，本申请提供一种消息处理的方法，应用第一设备，所述方法包括：
向第二设备发送携带回执请求的多媒体消息；
响应于接收到所述第二设备发送的回执消息，通过前端页面展示所述多媒体消息的处理状态。
第二方面，本申请提供一种消息处理的方法，应用于第二设备，所述方法包括：
接收第一设备发送的多媒体消息，所述多媒体消息携带回执请求；
在对所述多媒体消息进行所述回执请求对应的处理之后，向所述第一设备发送对所述多媒体消息的回执消息。
第三方面，本申请提供一种消息处理的设备，应用第一设备，包括：
发送模块，用于向第二设备发送携带回执请求的多媒体消息；
回执状态展示模块，用于响应于接收到所述第二设备发送的回执消息，通过前端页面展示所述多媒体消息的处理状态。
第四方面，本申请提供一种消息处理的设备，应用于第二设备，包括：
接收模块，用于接收第一设备发送的多媒体消息，所述多媒体消息携带回执请求；
回执处理模块，用于在对所述多媒体消息进行所述回执请求对应的处理之后，向所述第一设备发送对所述多媒体消息的回执消息。
第五方面，本申请提供一种电子设备，包括：
发送器，接收器，处理器，存储器，以及存储在所述存储器上并可在所述处理器上运行的计算机程序；
其中，所述处理器运行所述计算机程序时实现上述任一方面所述的方法。
第六方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现任一方面所述的方法。
第七方面，本申请提供一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现任一方面所述的方法。
本申请提供的消息处理的方法、设备、存储介质及程序产品，通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B-TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。
图1为本申请实施例一提供的消息处理的方法流程图；
图2为本申请实施例二提供的消息处理的方法流程图；
图3为本申请实施例提供的B-TrunC多媒体消息协议的流程示意图；
图4为本申请实施例三提供的消息处理的设备的结构示意图；
图5为本申请实施例四提供的消息处理的设备的结构示意图；
图6为本申请实施例五提供的消息处理的设备的结构示意图；
图7为本申请实施例六提供的电子设备的结构示意图。
通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
本申请所涉及的术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
实施例一
图1为本申请实施例一提供的消息处理的方法流程图。本实施例中的方法应用于电子设备，该电子设备可以是智能手机、平板电脑等移动终端(User Equipment，简称UE)，也可以是调度台(Dispatch Console，简称DC)等，在其他实施例中，该方法还可应用于其他设备，本实施例以电子设备为UE或DC为例进行示意性说明。
如图1所示，该方法具体步骤如下：
步骤S101、第一设备向第二设备发送携带回执请求的多媒体消息。
本实施例中，第一设备为消息发送端，第二设备为消息的接收端。第一设备和第二设备均为电子设备，可以是UE或DC等。
第一设备向第二设备发送多媒体消息时，将回执请求携带在多媒体消息中一起发送。
步骤S102、第二设备接收第一设备发送的多媒体消息，多媒体消息携带回执请求。
第二设备接收到第一设备发送的多媒体消息之后，可以从而多媒体消息中提取回执请求。
第二设备接收到第一设备发送的多媒体消息之后，可以获取多媒体消息的信息内容，例如获取多媒体消息的正文、或下载多媒体消息对应的附件等。
步骤S103、第二设备在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息。
第二设备获取到回执请求之后，根据回执请求，在第二设备对多媒体消息完成回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息。
示例性地，回执请求为阅读回执请求，在第二设备读取多媒体消息的信息内容(也就是用户通过第二设备阅读多媒体消息的信息内容)之后，向第一设备发送对多媒体消息的阅读回执消息。
示例性地，回执请求为接收回执请求，在第二设备接收到多媒体消息的信息内容之后，向第一设备发送对多媒体消息的接收回执消息。
示例性地，回执请求为下载回执请求，在第二设备下载多媒体消息的信息内容(如多媒体消息对应附件)之后，向第一设备发送对多媒体消息的下载回执消息。
步骤S104、响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态。
第一设备在接收到第二设备返回的回执消息之后，可以确定第二设备已经完成对多媒体消息的回执请求对应的处理，第一设备通过前端页面展示多媒体消息的处理状态。
示例性地，接收到接收回执消息之后，第一设备可以通过前端页面将多媒体消息标记为已接收状态。
示例性地，接收到阅读回执消息之后，第一设备可以通过前端页面将多媒体消息标记为已阅读状态。
示例性地，接收到下载回执消息之后，第一设备可以通过前端页面将多媒体消息标记为已下载状态。
需要说明的是，发送端的第一设备和接收端的第二设备之间传输消息时，经由多媒体消息业务服务器(Multimedia Messaging Service Server，简称MMSS)转发，符合B-TrunC多媒体消息协议规定的通信流程。
本申请实施例通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B-TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。
实施例二
图2为本申请实施例二提供的消息处理的方法流程图；图3为本申请实施例提供的B-TrunC多媒体消息协议的流程示意图。在上述实施例一的基础上，本实施例中，回执消息为以下任意一种：阅读回执消息、接收回执消息、下载回执消息。
如图2所示，该方法具体步骤如下：
步骤S201、第一设备向第二设备发送携带回执请求的多媒体消息。
本实施例中，第一设备为消息发送端，第二设备为消息的接收端。第一设备和第二设备均为电子设备，可以是UE或DC等。
第一设备向第二设备发送多媒体消息时，将回执请求携带在多媒体消息中一起发送。
示例性地，发送端可以在短/彩信XMPP消息中增加回执请求字段，例如，在标准B-TrunC多媒体消息中增加回执请求后的多媒体消息如下所示，其中带有下划线的部分为增加的回执请求(用“Receipt”信元表示)，也即是：
Figure BDA0003045753160000051
Figure BDA0003045753160000061
其中，新增的“Receipt”信元的说明如下表1所示：
表1
Figure BDA0003045753160000062
另外，可以在B-TrunC多媒体消息协议中增加回执消息对应的消息类型。示例性地，B-TrunC多媒体消息协议中的消息类型的取值及对应的含义如下表2所示：
表2
消息类型(MsgType)取值 含义说明
1 多媒体消息发送
2 多媒体消息收到确认ACK消息
3 多媒体消息收到失败FAIL消息
4 阅读回执消息
…
101-200 保留值，厂家可用于私有实现
表2中以增加的阅读回执消息的消息类型的取值为4为例进行示例性地说明，还可以增加其他类型的回执消息并指定各类型的回执消息的对应的消息类型取值。
步骤S202、第二设备接收第一设备发送的多媒体消息，多媒体消息携带回执请求。
第二设备接收到第一设备发送的多媒体消息之后，可以从而多媒体消息中提取回执请求。
第二设备接收到第一设备发送的多媒体消息之后，可以获取多媒体消息的信息内容，例如获取多媒体消息的正文、或下载多媒体消息对应的附件等。
步骤S203、第二设备在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息。
本实施例中，根据第一设备的回执请求的不同，第二设备向第一设备反馈的回执消息也不同。回执消息可以为以下任意一种：阅读回执消息、接收回执消息、下载回执消息。
第二设备获取到回执请求之后，根据回执请求，在第二设备对多媒体消息完成回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息。
示例性地，回执请求为阅读回执请求，在第二设备读取多媒体消息的信息内容(也就是用户通过第二设备阅读多媒体消息的信息内容)之后，向第一设备发送对多媒体消息的阅读回执消息。
示例性地，回执请求为接收回执请求，在第二设备接收到多媒体消息的信息内容之后，向第一设备发送对多媒体消息的接收回执消息。
示例性地，回执请求为下载回执请求，在第二设备下载多媒体消息的信息内容(如多媒体消息对应附件)之后，向第一设备发送对多媒体消息的下载回执消息。
示例性地，新增的回执消息的格式一个示例如下：
Figure BDA0003045753160000071
其中，接收端反馈的回执消息的消息标识(协议中的message id)与发送端发送的多媒体消息的消息标识(协议中的message id)一致，发送端根据回执消息的消息标识关联相应的多媒体消息，并在用户操作界面呈现多媒体消息的处理状态(例如已阅读状态、已接收状态、已下载状态)。
MsgType表示消息类型，不同类型的消息(如多媒体消息和回执消息等)对应的消息类型不同，不同类型的回执消息(如阅读回执消息、接收回执消息、下载回执消息等)对应的消息类型也不同。
MsgText表示消息的内容信息。例如，对于阅读回执消息，MsgText可以填写“Read”，表示接收端已阅读多媒体消息；对于接收回执消息，MsgText可以填写“Receive”，表示接收端已接收多媒体消息；对于下载回执消息，MsgText可以填写“Download”，表示接收端已下载多媒体消息的内容信息。
如果接收端收到为群组消息时，需要MsgGroup中填写对应的群组号。
另外，根据实际应用场景需要，回执消息还可以设置为其他类型的回执消息，回执消息的具体类型和内容可以根据实际应用场景的需要进行扩展和配置，本实施例此处不做具体限定。
步骤S204、第一设备接收第二设备发送的回执消息，回执消息的消息标识与多媒体消息的消息标识一致，回执消息的消息类型与多媒体消息的消息类型不一致。
其中，第二设备反馈的回执消息的消息标识(如协议中的message id)与第一设备发送的多媒体消息的消息标识(协议中的message id)一致，发送端根据回执消息的消息标识关联相应的多媒体消息，并在用户操作界面呈现多媒体消息的处理状态(例如已阅读状态、已接收状态、已下载状态)。
步骤S205、响应于接收到第二设备发送的回执消息，第一设备向第二设备发送对回执消息的确认消息。
本实施例中，第一设备收到第二设备的回执消息之后，可以向第二设备发送对回执消息的确认消息。其中，对回执消息的确认消息可以采用B-TrunC协议当前定义的ACK消息。
另外，如果第一设备接收第二设备的回执消息失败，可以向第二设备发送回执消息的失败消息。其中，对回执消息的确认消息可以采用B-TrunC协议当前定义的FAIL消息。
需要说明的是，发送端的第一设备和接收端的第二设备之间传输消息时，经由多媒体消息业务服务器(Multimedia Messaging Service Server，简称MMSS)转发，符合B-TrunC多媒体消息协议规定的通信流程。
步骤S206、第一设备通过前端页面展示多媒体消息的处理状态。
第一设备在接收到第二设备返回的回执消息之后，可以确定第二设备已经完成对多媒体消息的回执请求对应的处理，第一设备通过前端页面展示多媒体消息的处理状态。
示例性地，接收到接收回执消息之后，第一设备可以通过前端页面将多媒体消息标记为已接收状态。
示例性地，接收到阅读回执消息之后，第一设备可以通过前端页面将多媒体消息标记为已阅读状态。
示例性地，接收到下载回执消息之后，第一设备可以通过前端页面将多媒体消息标记为已下载状态。
下面以多媒体消息为包含附件的彩信为例，结合图3，对改进后B-TrunC多媒体消息协议的处理流程进行详细地说明，具体包括如下步骤：
步骤S1：HTTP Post(附件上传)；
图3中用UE/DC(MO)表示作为发送端的第一设备，用UE/DC(MT)表示作为接收端的第二设备。
该步骤S1中，UE/DC(MO)使用HTTP Post进行附件上传操作，向多媒体消息业务服务器(Multimedia Messaging Service Server，简称MMSS)发送附件上传消息，将发送方彩信的附件上传至MMSS。其中附件上传消息的消息体中包含主叫用户表示(如UDN userid)、消息标识(如msgid)、时间(date)、附件名(filename)等。
步骤S2：MMSS向UE/DC(MO)返回HTTP 200OK；
MMSS接收到UE/DC(MO)发送的附件上传消息之后，采用HTTP协议向UE/DC(MO)返回HTTP 200OK响应消息。
步骤S3：UE/DC(MO)向MMSS发送携带回执请求的XMPP MMS消息；
该步骤中，UE/DC(MO)将携带回执请求的多媒体消息通知消息通过XMPP消息(如XMPP MMS消息)发送给MMSS。
其中，多媒体消息通知消息包含消息标识(message id)、UE/DC(MO)的UDN、UE/DC(MT)的UDN、服务器地址(ServerIP)、多媒体消息主题(subject)、多媒体消息类型(MsgType)、多媒体消息的正文(MsgText)、附件名(attach)、是否发送原图(original_image_attached)以及缩略图编码。其中，多媒体消息通知消息包含的消息标识(messageid)与步骤S1的消息标识(msgid)相同，由此绑定附件和多媒体消息通知为一个多媒体消息过程。
在步骤S3中，发送端XMPP多媒体消息中，增加扩展字段，用于发送端进行短彩信“Receipt”回执请求的发送。
步骤S4：MMSS向UE/DC(MT)发送携带回执请求的XMPP MMS消息；
该步骤中，MMSS本地查看被叫用户的在线状态，如果被叫用户当前是离线的，那么启动“离线多媒体消息处理”流程。如果被叫用户当前是在线的，则向被叫用户发送多媒体消息通知消息(携带回执请求的XMPP MMS消息)，消息中包含UE/DC(MO)的UDN、UE/DC(MT)的UDN、多媒体消息主题(subject)、多媒体消息类型(MsgType)、多媒体消息的正文(MsgText)、附件名(attach)、是否发送原图(original_image_attached)以及缩略图编码等。
需要注意的是，对于被叫离线的情况，MMSS返回ACK消息，ACK消息中的ReturnCode取值为1。
步骤S5：UE/DC(MT)向MMSS返回ACK/FAIL消息；
被叫用户得到多媒体消息的正文之后，UE/DC(MT)向MMSS返回ACK消息。ACK消息中包含消息标识(message id)、被叫UDN、消息类型(MsgType)、服务器地址(serverIP)等。
如果多媒体消息接收失败，则UE/DC(MT)向MMSS返回FAIL消息，FAIL消息中携带失败原因。
步骤S6：MMSS向UE/DC(MO)返回ACK/FAIL消息；
该步骤中，MMSS根据收到的ACK/FAIL消息向UE/DC(MO)返回ACK/FAIL消息，如果是ACK消息，则ACK消息中包含消息标识(message id)、主叫UDN、服务器地址(serverIP)、消息类型(MsgType)；如果是FAIL消息，则FAIL消息中包含失败原因。
步骤S7：HTTP Get(附件下载)；
该步骤中，多媒体消息接收成功后，UE/DC(MT)从MMSS下载附件。具体地，UE/DC(MT)根据步骤S4中多媒体消息通知消息中的主叫UDN、消息标识(message id)、附件名(filename)生成URL，被叫用户通过访问URL发起附件下载HTTP GET流程。
步骤S8：MMSS向UE/DC(MT)返回HTTP 200OK响应消息，消息中携带附件。
步骤S9：UE/DC(MT)向MMSS返回XMPP回执消息；
该步骤中，UE/DC(MT)将回执消息(例如“阅读回执”多媒体消息)通过XMPP消息发送给MMSS，回执消息包含消息标识(message id)、UE/DC(MO)的UDN、UE/DC(MT)的UDN、服务器地址(ServerIP)、多媒体消息类型(MsgType)、多媒体消息的正文(MsgText)等。
其中，回执消息中的消息标识(message id)与步骤S3的消息标识(message id)相同，由此绑定回执消息和多媒体消息通知消息为一个多媒体消息过程。
步骤S10：MMSS向UE/DC(MO)发送XMPP回执消息；
该步骤中，MMSS本地查看UE/DC(MO)用户的在线状态，如果UE/DC(MO)用户当前是离线的，那么启动“离线多媒体消息处理”流程，与当前B-TrunC协议定义一致。
如果UE/DC(MO)用户在线，则向UE/DC(MO)用户发送XMPP回执消息(如“阅读回执”多媒体消息)，回执消息包含消息标识(message id)、UE/DC(MO)的UDN、UE/DC(MT)的UDN、服务器地址(ServerIP)、多媒体消息类型(MsgType)、多媒体消息的正文(MsgText)等。
其中，回执消息中的消息标识(message id)与步骤S3的消息标识(message id)相同，由此绑定回执消息和多媒体消息通知消息为一个多媒体消息过程。
步骤S11：UE/DC(MO)向MMSS返回ACK/FAIL消息；
发送端用户接收到回执消息后，向MMSS服返回ACK消息，ACK消息中包含消息标识(message id)、主叫UDN、消息类型(MsgType)、服务器地址(serverIP)等。UE/DC(MO)在多媒体消息界面呈现相应的状态告知用户对端多媒体消息的处理状态，如“已阅读”等。如果回执消息接收失败，则向MMSS服返回FAIL消息，FAIL消息中携带失败原因。
步骤S12：MMSS向UE/DC(MT)返回ACK/FAIL消息。
该步骤中，MMSS根据收到的ACK/FAIL消息向UE/DC(MT)返回ACK/FAIL消息。如果是ACK消息，则ACK消息中包含消息标识(message id)、主叫UDN、消息类型(MsgType)、服务器地址(serverIP)等；如果是FAIL消息，消FAIL息中包含失败原因。
本申请实施例通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B-TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。
实施例三
图4为本申请实施例三提供的消息处理的设备的结构示意图。本申请实施例提供的消息处理的设备可以执行消息处理的实施例提供的处理流程。如图4所示，该消息处理的设备40包括：发送模块401和回执状态展示模块402。
具体地，发送模块401，用于向第二设备发送携带回执请求的多媒体消息。
回执状态展示模块402，用于响应于接收到第二设备发送的回执消息，通过前端页面展示多媒体消息的处理状态。
本申请实施例提供的装置可以具体用于执行上述实施例一种第一设备所执行的方法流程，具体功能此处不再赘述。
本申请实施例通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B-TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。
实施例四
图5为本申请实施例四提供的消息处理的设备的结构示意图。在上述实施例三的基础上，本实施例中，如图5所示，该消息处理的设备40还包括：接收模块403，用于：
响应于接收到第二设备返回的回执消息，通过前端页面展示多媒体消息的处理状态之前，接收第二设备发送的回执消息，回执消息的消息标识与多媒体消息的消息标识一致，回执消息的消息类型与多媒体消息的消息类型不一致。
其中，回执消息为以下任意一种：阅读回执消息、接收回执消息、下载回执消息。
可选的，发送模块401还用于：响应于接收到第二设备发送的回执消息，在通过前端页面展示多媒体消息的处理状态之前，向第二设备发送对回执消息的确认消息。
本申请实施例提供的装置可以具体用于执行上述实施例二中第一设备所执行的方法流程，具体功能此处不再赘述。
本申请实施例通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B-TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。
实施例五
图6为本申请实施例五提供的消息处理的设备的结构示意图。本申请实施例提供的消息处理的设备可以执行消息处理的实施例提供的处理流程。如图6所示，该消息处理的设备50包括：接收模块501和回执处理模块502。
具体地，接收模块501，用于接收第一设备发送的多媒体消息，多媒体消息携带回执请求。
回执处理模块502，用于在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息。
本申请实施例提供的装置可以具体用于执行上述实施例一种第二设备所执行的方法流程，具体功能此处不再赘述。
可选地，接收模块501还用于接收第一设备发送的多媒体消息，多媒体消息携带回执请求。该消息处理的设备50还可以包括：发送模块，用于在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息。
本申请实施例通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B-TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。
实施例六
图7为本申请实施例六提供的电子设备的结构示意图。如图7所示，该电子设备100包括：发送器70，接收器71，处理器72，存储器73，以及存储在存储器73上并可在处理器72上运行的计算机程序。
其中，处理器72运行计算机程序时实现上述任一方法实施例所提供的方法。
本申请实施例通过发送端的第一设备向接收端的第二设备发送携带回执请求的多媒体消息；第二设备接收第一设备发送的多媒体消息，在对多媒体消息进行回执请求对应的处理之后，向第一设备发送对多媒体消息的回执消息；响应于接收到第二设备发送的回执消息，第一设备通过前端页面展示多媒体消息的处理状态，实现了B-TrunC多媒体消息的回执消息机制，发送端用户可以及时地获知接收端用户对多媒体消息的处理状态，满足了用户需求。
另外，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时实现上述任一方法实施例提供的方法。
另外，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时实现上述任一方法实施例提供的方法。
本申请还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一方法实施例提供的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (10)

1.一种消息处理的方法，其特征在于，应用第一设备，所述方法包括：
向第二设备发送携带回执请求的多媒体消息；
响应于接收到所述第二设备发送的回执消息，通过前端页面展示所述多媒体消息的处理状态。
2.根据权利要求1所述的方法，其特征在于，响应于接收到所述第二设备返回的回执消息，通过前端页面展示所述多媒体消息的处理状态之前，还包括：
接收所述第二设备发送的回执消息，所述回执消息的消息标识与所述多媒体消息的消息标识一致，所述回执消息的消息类型与所述多媒体消息的消息类型不一致；
其中，所述回执消息为以下任意一种：阅读回执消息、接收回执消息、下载回执消息。
3.根据权利要求1所述的方法，其特征在于，响应于接收到所述第二设备发送的回执消息，在通过前端页面展示所述多媒体消息的处理状态之前，还包括：
向所述第二设备发送对所述回执消息的确认消息。
4.一种消息处理的方法，其特征在于，应用于第二设备，所述方法包括：
接收第一设备发送的多媒体消息，所述多媒体消息携带回执请求；
在对所述多媒体消息进行所述回执请求对应的处理之后，向所述第一设备发送对所述多媒体消息的回执消息。
5.根据权利要求4所述的方法，其特征在于，所述在对所述多媒体消息进行所述回执请求对应的处理之后，向所述第一设备发送对所述多媒体消息的回执消息，包括以下至少一项：
在接收到所述多媒体消息的内容信息之后，向所述第一设备发送对所述多媒体消息的接收回执消息；
在读取所述多媒体消息的内容信息之后，向所述第一设备发送对所述多媒体消息的阅读回执消息；
在下载所述多媒体消息的内容信息之后，向所述第一设备发送对所述多媒体消息的下载回执消息。
6.一种消息处理的设备，其特征在于，应用第一设备，包括：
发送模块，用于向第二设备发送携带回执请求的多媒体消息；
回执状态展示模块，用于响应于接收到所述第二设备发送的回执消息，通过前端页面展示所述多媒体消息的处理状态。
7.一种消息处理的设备，其特征在于，应用于第二设备，包括：
接收模块，用于接收第一设备发送的多媒体消息，所述多媒体消息携带回执请求；
回执处理模块，用于在对所述多媒体消息进行所述回执请求对应的处理之后，向所述第一设备发送对所述多媒体消息的回执消息。
8.一种电子设备，其特征在于，包括：
发送器，接收器，处理器，存储器，以及存储在所述存储器上并可在所述处理器上运行的计算机程序；
其中，所述处理器运行所述计算机程序时实现如权利要求1至5中任一项所述的方法。
9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述的方法。
10.一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1至5中任一项所述的方法。
CN202110472099.5A 2021-04-29 2021-04-29 消息处理的方法、设备、存储介质及程序产品 Pending CN115277614A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110472099.5A CN115277614A (zh) 2021-04-29 2021-04-29 消息处理的方法、设备、存储介质及程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110472099.5A CN115277614A (zh) 2021-04-29 2021-04-29 消息处理的方法、设备、存储介质及程序产品

Publications (1)

Publication Number Publication Date
CN115277614A true CN115277614A (zh) 2022-11-01

Family

ID=83745568

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110472099.5A Pending CN115277614A (zh) 2021-04-29 2021-04-29 消息处理的方法、设备、存储介质及程序产品

Country Status (1)

Country Link
CN (1) CN115277614A (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101106752A (zh) * 2007-07-04 2008-01-16 中兴通讯股份有限公司 一种彩信回执平台及使用该平台实现彩信回执业务的方法
CN102685022A (zh) * 2011-03-11 2012-09-19 中兴通讯股份有限公司 媒体消息回执的处理方法和具有网关功能的装置
CN106100972A (zh) * 2016-06-02 2016-11-09 腾讯科技（深圳）有限公司 一种消息处理方法、系统、第一终端及第二终端
CN106874334A (zh) * 2016-08-12 2017-06-20 阿里巴巴集团控股有限公司 一种数据处理方法及装置、资讯处理系统
CN108933727A (zh) * 2017-05-25 2018-12-04 中兴通讯股份有限公司 消息回执的处理方法和装置
CN110557321A (zh) * 2018-06-04 2019-12-10 中国移动通信有限公司研究院 一种信息传输方法、网络设备及终端
CN111954170A (zh) * 2019-05-14 2020-11-17 成都鼎桥通信技术有限公司 建立群组资源的处理方法、装置、核心网及存储介质
CN112449313A (zh) * 2019-08-30 2021-03-05 普天信息技术有限公司 宽带集群系统中彩信业务附件下载确认方法及装置
CN112714055A (zh) * 2019-10-25 2021-04-27 成都鼎桥通信技术有限公司 宽带集群通信的点对点短消息阅读确认方法、装置和系统

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101106752A (zh) * 2007-07-04 2008-01-16 中兴通讯股份有限公司 一种彩信回执平台及使用该平台实现彩信回执业务的方法
CN102685022A (zh) * 2011-03-11 2012-09-19 中兴通讯股份有限公司 媒体消息回执的处理方法和具有网关功能的装置
CN106100972A (zh) * 2016-06-02 2016-11-09 腾讯科技（深圳）有限公司 一种消息处理方法、系统、第一终端及第二终端
CN106874334A (zh) * 2016-08-12 2017-06-20 阿里巴巴集团控股有限公司 一种数据处理方法及装置、资讯处理系统
CN108933727A (zh) * 2017-05-25 2018-12-04 中兴通讯股份有限公司 消息回执的处理方法和装置
CN110557321A (zh) * 2018-06-04 2019-12-10 中国移动通信有限公司研究院 一种信息传输方法、网络设备及终端
CN111954170A (zh) * 2019-05-14 2020-11-17 成都鼎桥通信技术有限公司 建立群组资源的处理方法、装置、核心网及存储介质
CN112449313A (zh) * 2019-08-30 2021-03-05 普天信息技术有限公司 宽带集群系统中彩信业务附件下载确认方法及装置
CN112714055A (zh) * 2019-10-25 2021-04-27 成都鼎桥通信技术有限公司 宽带集群通信的点对点短消息阅读确认方法、装置和系统

Similar Documents

Publication Publication Date Title
CN1767508B (zh) 即时消息传送服务中的文件传输方法以及用于支持该方法的移动通信终端
US8041342B2 (en) Moving notification message
TW462159B (en) Mobile communication terminal
EP1424860A2 (en) Method for controlling a multimedia messaging service between a telecommunication device and a telecommunication network, respective smart card and telecommunication device
CN108293082B (zh) 用于在通信终端中支持语音呼叫的方法及其终端
EP2456144A2 (en) Method, device and system for identifying a service
CN114979984B (zh) 消息的传输方法及装置
JP4230924B2 (ja) メール配信装置
KR101346394B1 (ko) 인스턴트 메시지의 멀티미디어 링톤 디스플레이 방법 및 시스템
CN115277614A (zh) 消息处理的方法、设备、存储介质及程序产品
JP2012138689A (ja) 携帯端末への発信者情報表示システムおよび発信者情報表示用プログラム
CN111565235A (zh) 一种获取多媒体消息业务服务器地址的方法及装置
CN113794622B (zh) 消息处理方法、装置、电子设备及存储介质
CN102137346A (zh) 多媒体消息业务处理方法和相关设备以及系统
CN114338584B (zh) 消息撤回方法和消息传输系统
JP6999056B2 (ja) メッセージ管理装置及びメッセージ管理方法
US20060035655A1 (en) System and method for application distribution
US8929518B2 (en) Information processing system, message server, and control method and control program thereof
US20010034783A1 (en) Method for transmitting information
CN115884107A (zh) 消息处理方法、装置、设备及可读存储介质
CN116897528A (zh) 信息通信方法和程序
CN102238492A (zh) 移动终端发送和接收具有签名档的短信的方法及装置
CN105392198A (zh) 网络通信方法及装置
CN111050288A (zh) 使用短消息推送位置的方法、系统、电子设备及存储介质
US9544426B2 (en) Method for transmitting data related to a call

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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20221101