WO2019128682A1

WO2019128682A1 - Convergent messaging system and message processing method

Info

Publication number: WO2019128682A1
Application number: PCT/CN2018/119994
Authority: WO
Inventors: 邵俊; 李毅; 黄小兵; 孙立波; 杨金舟; 曹懿军
Original assignee: 中兴通讯股份有限公司
Priority date: 2017-12-26
Filing date: 2018-12-10
Publication date: 2019-07-04
Also published as: CN108156069A

Abstract

Disclosed are a convergent messaging system and a message processing method. The convergent messaging system comprises: an access platform and a service platform; the access platform is connected to the service platform; the access platform is configured to receive a first protocol message from a sending client accessed using a first protocol; the service platform is configured to convert the first protocol message into a second protocol message supported by a receiving client accessed by using a second protocol; the access platform is further configured to send the second protocol message to the receiving client.

Description

Fusion message system and message processing method

The present application claims priority to Chinese Patent Application No. PCT Application No.

Technical field

The present application relates to, but is not limited to, communication technologies, for example, to a converged message system and a message processing method.

Background technique

With the rapid development of the global mobile service, instant messaging services, such as SMS, multimedia messaging, mobile email, and mobile instant messaging, have become widely used as important services beyond mobile voice. But with the development of instant messaging services, some problems have also emerged.

Internet manufacturers develop and design client applications (Applications, APPs) and servers themselves, using a proprietary communication protocol model, using the network of carrier communication as a conduit, so that all instant messaging and VoIP functions are in the vendor's own client. achieve. At present, the instant messaging services of Internet manufacturers have been designed as "shake" architectures, and different manufacturers' instant messaging services have built different architecture protocols and platforms. The functions of instant messaging services of different manufacturers are becoming more and more serious. However, since the client messages of different manufacturers adopt private protocols that are not open, they are not interoperable at all, resulting in a large number of client types and protocols in the instant messaging service, thereby affecting the user experience.

Summary of the invention

The following is an overview of the topics detailed in this document. This Summary is not intended to limit the scope of the claims.

The embodiment of the present invention provides a converged message system and a message processing method, which implement multi-end multi-protocol adaptation, thereby improving user experience.

The embodiment of the present application provides a converged message system, including: an access platform and a service platform;

The access platform is connected to the service platform;

The access platform is configured to receive a first protocol message from a sending client that uses the first protocol access;

The service platform is configured to convert the first protocol message into a second protocol message supported by the receiving client that is accessed by using the second protocol;

The access platform is further configured to send the second protocol message to the receiving client.

The embodiment of the present application provides a message processing method, including:

Receiving a first protocol message from a sending client that accesses by using the first protocol;

Converting the first protocol message into a second protocol message supported by the receiving client accessed by using the second protocol;

Sending the second protocol message to the receiving client.

The embodiment of the present application further provides a computer readable medium storing a message processing program, and the message processing program is implemented by a processor to implement the message processing method.

BRIEF abstract

FIG. 1 is a schematic diagram of a converged message system according to an embodiment of the present application;

2 is a schematic diagram of a converged message system provided by an embodiment of the present application;

3 is a schematic structural diagram of an OTT protocol according to an embodiment of the present application;

4 is a flow chart of multi-client registration according to an embodiment of the present application;

FIG. 5 is a flowchart of an example of sending and receiving small messages by different clients according to an embodiment of the present application;

FIG. 6 is a flowchart of another example of sending and receiving small messages by different clients according to an embodiment of the present application;

FIG. 7 is a flowchart of an example of sending and receiving large messages by different clients according to an embodiment of the present application;

FIG. 8 is a flowchart of another example of sending and receiving large messages by different clients according to an embodiment of the present application;

FIG. 9 is a flowchart of a message processing method according to an embodiment of the present application.

Detailed ways

The embodiments of the present application are described in detail below with reference to the accompanying drawings.

The steps illustrated in the flowchart of the figures may be executed in a computer system such as a set of computer executable instructions. Also, although logical sequences are shown in the flowcharts, in some cases the steps shown or described may be performed in a different order than the ones described herein.

The embodiment of the present application provides a fusion message system and a message processing method, such as a mobile phone, a set top box, a tablet computer (PAD), a television (Television, TV), and a computer (Personal Computer, PC). Multiple protocols can be used for simultaneous access, which realizes the conversion transmission between different protocol messages, thereby promoting the development of the Internet mobile instant communication service, which can greatly improve the user satisfaction and improve the user's service experience.

FIG. 1 is a schematic diagram of a converged message system according to an embodiment of the present application. The fused message system provided by this embodiment may be deployed on a server cluster. However, this application does not limit this.

As shown in FIG. 1 , the fused message system provided by the embodiment of the present application includes: an access platform 11 and a service platform 12; wherein the access platform 11 is connected to the service platform 12.

In this embodiment, the access platform 11 is configured to receive the first protocol message from the sending client 10a that accesses the first protocol; the service platform 12 is configured to convert the first protocol message into a receiving client accessed by using the second protocol. The second protocol message supported by the terminal; the access platform 11 is further configured to send a second protocol message to the receiving client 10b.

In an exemplary embodiment, a client (eg, sending client 10a, receiving client 10b) may include a converged communication (RCS) terminal supporting standard instant messaging protocols and OTT protocols. However, this application is not limited thereto.

In an exemplary embodiment, the service platform 12 may include: a protocol support module and a service module; the protocol support module is connected to the service module; wherein the service module is configured to determine the first protocol message according to the first protocol message and the stored end registration information. The protocol conversion indication information, and sends the protocol conversion indication information to the protocol support module; the protocol support module is configured to perform protocol conversion on the first protocol message according to the protocol conversion indication information, and send the converted second protocol message to Access platform 11.

In an exemplary embodiment, the service module may be further configured to update the registration information according to the registration information received from the one or more clients and the stored conflict rule table; wherein the end registration information includes at least: one or more The user's online status and registration type of the client, the registration type can indicate the access protocol supported by the client; the conflict rule table records the registration types that can coexist on the same client.

Exemplarily, the end registration information may include: a user identifier, a user online status, device information (eg, device identification, device capability information, etc.), version information, and registration type. The registration type may include: Native, RCS APP, PC client, and Web client, wherein the Native mode and the RCS APP mode indicate that the RCS standard protocol is used for access, and the PC client and the Web client may indicate that the OTT protocol is adopted. Access.

In an exemplary embodiment, the protocol support module is adapted to provide translation between any two of the following: Session Initiation Protocol (SIP), Message Session Relay Protocol (MSRP), Hypertext Transfer Protocol (HTTP), Extensible Markup Language The XML Configuration Access Protocol (XCAP) protocol, the Aspect-Oriented Programming (AOP), and the Over The Top (OTT) protocol.

In an exemplary embodiment, a Protocol Data Unit (PDU) of the OTT protocol may include: a message header field, one or more custom message fields; wherein any custom message field includes a message header portion and a message Body part. As shown in FIG. 3, the transmitted OTT Protocol Data Unit (PDU) includes a commonly used Multimedia (MM) message header field and a customized message field. The commonly used message header field may include a primary called address (From, To), a message unique identifier (MsgId), a message type (Content-Type), and a terminal type, and each type of message may be used. Custom message domains can embody information specific to multiple message types. Each custom message field can include a message header portion and a message body portion. For example, if the client needs to transmit a whiteboard message delineation direction, the background image identifier may be carried in the message header part of the first custom message domain (part 1), and the message body part carries the picture content; and may be in the second custom message domain ( The message header part of part 2) carries the direction position coordinate identifier, and the message body part carries the line information pointed by the direction. In this example, the OTT protocol is based on binary coding, which has high coding efficiency, good security, and small protocol stack, so the occupied bandwidth is small, and the resource consumption of the client system is low.

In an exemplary embodiment, the service platform 12 may further include: a unified message queue module, a connection service module, and the unified message queue module configured to store the first protocol message received by the service module.

In an exemplary embodiment, if the size of the first protocol message is less than a preset value (for example, 8K), the second protocol message carries the message content of the first protocol message; if the size of the first protocol message is greater than or equal to the preset The value, the second protocol message carries the storage address of the first protocol message.

In this exemplary embodiment, the service module may be further configured to determine a size of the first protocol message; if the size of the first protocol message is less than a preset value, determining that the protocol conversion indication information includes a message content of the first protocol message; If the size of the first protocol message is greater than or equal to the preset value, it is determined that the protocol conversion indication information includes a storage address of the first protocol message. In an embodiment, the protocol conversion indication information may further include: sending the device information of the client, the adopted access protocol, the device information of the receiving client, and the adopted access protocol. When the protocol support module performs the processing according to the protocol conversion indication information, the second protocol message carrying the message content of the first protocol message or the second protocol message carrying the storage address of the first protocol message may be obtained.

In an exemplary embodiment, the protocol support module may be further configured to perform protocol conversion on the first protocol message and send the converted second protocol message to the service module.

The service module may be further configured to: when determining that the size of the first protocol message is greater than or equal to a preset value, establishing a media transmission channel between the client and the receiving client 10b, and transmitting the second protocol message through the media transmission channel. The first protocol message may be an OTT protocol message, and the second protocol message may be a SIP protocol message.

In an exemplary embodiment, the first protocol message may be an OTT protocol message, and the second protocol message may be a converged communication standard protocol message, such as a SIP protocol message; or the first protocol message may be a converged communication standard protocol message, The second protocol message can be an OTT protocol message.

An example of the fused message system provided by this embodiment will be described below with reference to FIG. As shown in FIG. 2, the fused message system provided in this example includes: a unified access platform (corresponding to the foregoing access platform) and a service platform; wherein the service platform includes: a protocol support module, a service module, and a unified message queue module.

In this example, multiple clients can access the converged messaging system simultaneously using different protocols. The client may include a Rich Communication Suite (RCS) terminal supporting a standard instant messaging protocol and an OTT (Over The Top) protocol. In an embodiment, the RCS user can access the network and use the service through a variety of terminals. According to different ways of providing RCS services on the terminal, the RCS service has the following two terminal forms: RCS standard protocol access (for example, Native terminal, (Application, APP) client) and OTT protocol access (for example, computer (Personal Computer, PC) client, web (web) client, etc.). Among them, the Native mode refers to RCS as a factory-prepared preset function of any terminal, and has been specifically modified at the level of chip and operating system; APP mode refers to the existing terminal by installing an application (such as , mobile phone, set-top box, tablet (Portable Android Device (PAD)) with RCS function.

In this example, the unified access platform is responsible for receiving messages from different sending clients, forwarding messages to different receiving clients, and controlling the access protocol of different protocols. As shown in Figure 2, the unified access platform accesses the client supporting the RCS standard protocol through the Session Border Controller (SBC) and the SIP proxy (Siproxy), through the Http proxy (Proxy) and the link distribution gateway ( Link Aggregation Group (LAG) accesses clients that support the OTT protocol.

In this example, the protocol support module can be responsible for the adaptation of multiple protocols, such as Session Initiation Protocol (SIP), Message Session Relay Protocol (MSRP), Hypertext Transfer Protocol (Hyper Text). Transfer Protocol, HTTP), XCAP protocol, OTT protocol, and Access Management Protocol (AOP), etc., and provide conversion between different protocols. In an embodiment, the protocol support module may include a plurality of protocol adaptation units and a management interface machine, each protocol adaptation unit being configured to adapt a protocol, and the management interface machine provides conversion between different protocols.

In this example, the service module is responsible for providing maintenance of the access type and registration status of the client and various service capabilities, such as business processing logic including instant messaging, calls, pictures, and files. Exemplarily, the service module may include a plurality of node service modules, and the client may connect to the corresponding node service module according to the home location where the client is located.

In this example, the business module stores end registration information and a conflict rules table. In an embodiment, the service module stores a registration status table (corresponding to the above-mentioned end registration information) of the registered terminal, which may include a user identifier (eg, a user's mobile phone number), a user online status, version information, a device identifier, and Access type, etc. The conflict rule table can record which registration types (for example, types of access applications) on the same terminal can coexist, and which registration types need to be kicked each other. The conflict rules table can be configured according to business needs. For example, in the conflict rule table shown in Table 1, N/A (Not applicable) means not applicable; the type marked with "x" in the table cannot coexist on the same terminal, that is, the PC on the same terminal (for example, a computer). The client and the web client cannot be registered at the same time. Multiple RCS APP clients cannot be registered at the same terminal. Multiple PC clients cannot be registered at the same terminal, and multiple web clients cannot be registered at the same time.

Table 1

In this example, the service platform processes the initial registration request of the terminal. When the terminal registers, the service platform queries whether the registration type of the terminal conflicts with the registered type of the terminal. If there is no conflict, the terminal is allowed to register. Type; if there is a conflict, the type of the new request is registered, and the registration status of the conflicting type is released; after the terminal registration processing is completed, the service platform updates the registration status table of the terminal.

In this example, because the user ID of the same type of APP is unique, when the user changes the mobile phone or the PAD is reloaded, when the registration request is initiated again, the unified access platform needs to perform the offline processing of the client with the same user identifier. The OTT terminal registers for access, and the service module can record the OTT terminal identifier.

In this example, the Unified Message Queuing module is responsible for the distribution and dumping of messages. The unified message queue module can include a message queue module corresponding to the user identification and the device identification. A message transmitted by a user using a device is placed in its corresponding message queue module.

In this example, after the client accesses the protocol, the management interface of the protocol support module can convert the message sent by the unified message queue module into a protocol message that the client can support according to the registration information stored in the service module. Send to the intended user.

The embodiment provides a converged message system that supports multi-end multi-protocol access, simplifies a complex multi-type message system architecture, and combines the characteristics of multiple services to implement conversion and transmission between different protocols, which facilitates user operations and improves The user experience.

The solutions provided by the embodiments of the present application are described in detail below through various examples. It should be noted that the following multiple examples are described based on the fused message system shown in FIG. 2.

FIG. 4 is a flowchart of multi-client registration according to an embodiment of the present application. In this example, RCS client A can support the SIP standard protocol, and OTT client B can support the OTT protocol.

As shown in FIG. 4, the process of this embodiment includes: step S101 to step S122.

In step S101, the RCS client A initiates active registration to the unified access platform.

In step S102, the unified access platform forwards the SIP registration message to the protocol support module of the service platform, and the protocol support module parses the SIP registration message.

In step S103, the protocol support module of the service platform forwards the SIP registration message to the service module; after receiving the SIP registration message, the service module records the online state and registration type of the user of the RCS client A; wherein the registration type can be used to indicate the RCS The access protocol adopted by client A.

In step S104, the service module invokes a registration subscription interface of the unified message queue module.

In step S105 to step S108, the unified message queue module returns a registration processing result to the service module, and the service module returns a success response message (200OK) to the RCS client A through the protocol support module and the unified access platform; the RCS client A completes the registration. .

In step S109, the OTT client B initiates active registration to the unified access platform.

In step S110, the unified access platform forwards the OTT registration message to the protocol support module of the service platform.

In step S111, the protocol support module converts the OTT registration message into an internal standard registration message and notifies the service module.

In step S112, the service module invokes a registration subscription interface of the unified message queue module.

In step S113 to step S116, the unified message queue module returns a registration processing result to the service module, and the service module returns a success response message (200OK) to the RCS client B through the protocol support module and the unified access platform; the RCS client B completes the registration. .

In this example, after the client B completes the registration, the message queue module corresponding to the client B knows that the user of the client B is online; since there is a communication record between the client A and the client B or is about to communicate, the client The message queue module corresponding to B needs to know the online status of the user of the client A, so as to notify the client A and the client B of the online status of the user of the peer end through the unified message queue module.

In step S117, the message queue module corresponding to the client B queries the service module for the online state of the user of the client A.

In step S118, the service module returns the client A online to the message queue module corresponding to the client B.

In step S119 to step S122, the unified message queue module pushes the registration notification to the node service module to which the client A belongs, and the node service module to which the client A belongs pushes the registration notification to the unified access platform through the protocol support module, and then The unified access platform finally pushes the registration notification to the client A; that is, the client A receives the registration notification of the client B.

Similarly, the message queue module corresponding to the client A queries the service module for the online status of the client B. After the service module returns the client B online, the unified message queue module pushes the registration notification to the node to which the client B belongs. The service module is then pushed by the node service module to which the client B belongs to the unified access platform through the protocol support module, and then the unified access platform pushes the registration notification to the client B, that is, the client B receives the client A. Registration notice.

Referring to FIG. 5 to FIG. 8 , the flow of sending and receiving messages of the converged message system in different scenarios after the client registration is completed will be described. It should be noted that in the following example, the small message is defined as a message with a message size less than 8K, and the large message is defined as a message with a message size greater than or equal to 8K. However, this application is not limited thereto.

FIG. 5 is a flowchart of an example of sending and receiving small messages by different clients according to an embodiment of the present application. In this example, the calling RCS user accesses using the standard SIP protocol, and the called user uses OTT registration access.

As shown in FIG. 5, the flow of this embodiment includes: step S201 to step S215.

In step S201, the user A (the present example is the calling user) client sends a standard SIP MESSAGE message (corresponding to the first protocol message described above).

In step S202, the unified access platform receives the standard SIP MESSAGE message and forwards it to the protocol support module of the service platform protocol adaptation.

In step S203, the protocol support module invokes the internal message to send a standard SIP MESSAGE message to the node service module to which the user A belongs.

In step S204, after the node service module to which the user A belongs performs business logic processing on the standard SIP MESSAGE message (for example, verifying user legality and the like), the message queue module corresponding to the user A client is written.

In step S205 to step S207, the node service module to which the user A belongs returns a successful service response message (202Accepted) to the user A client.

In step S208, after the node service module to which the user A belongs ends processing of the user A, the write operation of the message queue module of the user B (the present example is the called user) is started; that is, the standard SIP MESSAGE message is written to the user B client. The corresponding message queue module.

In step S209, the message queue module corresponding to the user B client notifies the node service module to which the user B belongs that there is new message delivery.

In step S210, the node service module to which the user B belongs sends a service request (SIP MESSAGE message) to the protocol support module of the service platform protocol adaptation according to the user registration status and the registration type. The service request may carry the protocol conversion indication information. For example, the protocol conversion indication information includes device information (such as an identifier) of the user A client, a protocol type, device information of the user B client, and a protocol type.

In step S211, the protocol support module converts the SIP MESSAGE message of the original calling party (the user A client) into an OTT protocol message (Notify message); the protocol support module group is delivered as a message protocol packet acceptable to the user B client. The converted OTT protocol message (corresponding to the second protocol message described above) to the unified access platform.

In step S212, the unified access platform successfully delivers the OTT protocol message to the user B client, and the OTT client used by the user B receives the service presentation.

In step S213 to step S215, the user B client returns a success response message (200 OK) to the service module through the unified access platform and the protocol support module.

FIG. 6 is a flowchart of another example of sending and receiving small messages by different clients according to an embodiment of the present application. In this example, the calling user uses OTT registration access, and the called RCS user uses standard SIP access.

As shown in FIG. 6, the flow of this embodiment includes: step S301 to step S315.

In step S301, the user A (the present example is the calling user) client transmits an OTT protocol message (POST message) (corresponding to the first protocol message described above).

In step S302, the unified access platform receives the OTT protocol message and forwards it to the protocol support module of the service platform protocol adaptation.

In step S303, the protocol support module converts the OTT protocol message into a standard SIP MESSAGE message, and sends the message to the node service module to which the user A belongs.

In step S304, the node service module to which the user A belongs performs business logic processing on the received message, and then writes the received message to the message queue module corresponding to the user A client.

In step S305 to step S307, the node service module to which the user A belongs returns a successful service response message (202Accepted) to the user A client.

In step S308, after the node service module to which the user A belongs ends the processing on the user A, the write operation of the message queue module corresponding to the user B is started.

In step S309, the message queue module of the user B notifies the node service module to which the user B belongs that there is a new message delivery.

In step S310, the node service module to which the user B belongs sends a service request (SIP MESSAGE message) to the protocol adaptation protocol support module according to the user registration status and the registration type. The service request may carry the protocol conversion indication information, for example, The protocol conversion indication information includes device information of the user B client, a protocol type, device information of the user A client, and a protocol type.

In step S311, the protocol support module converts the original caller's OTT protocol message into a standard SIP MESSAGE message; the protocol support module group delivers the converted SIP MESSAGE message to the user's B client acceptable message protocol packet (corresponding to The above second protocol message) to the unified access platform.

In step S312, the unified access platform finally delivers the SIP MESSAGE message to the client of user B, and the RCS client used by user B receives the service presentation.

In step S313 to step S315, the user B client returns a success response message (200 OK) to the service module through the unified access platform and the protocol support module.

FIG. 7 is a flowchart of an example of different clients transmitting and receiving large messages according to an embodiment of the present application. In this example, the calling RCS user accesses using the standard SIP protocol, and the called user uses OTT registration access.

As shown in FIG. 7, the flow of this embodiment includes steps S401 to S427.

In step S401 to step S403, the user A (the present example is the calling user) client sends the standard SIP INVITE signaling; the unified access platform forwards the protocol support module to the service platform protocol adaptation; the protocol support module sets the SIP INVITE The signaling is sent to the node service module to which the user A belongs.

In step S404 to step S406, the node service module to which the user A belongs receives the SIP INVITE signaling return success response message (200OK) to the protocol support module; the protocol support module returns the success response message to the user A client through the unified access platform. end.

In step S407 to step S408, the user A client establishes a media transmission channel (MRSP channel) according to the SIP INVITE signaling negotiation, and sends a message (corresponding to the first protocol message described above) to the user A by using the established media transmission channel. Node business module.

In step S409, the node service module to which the user A belongs stores the received message.

In step S410, the node service module to which the user A belongs returns a success response message (MRSP 200 OK) to the user A client.

In step S411, after the node service module to which the user A belongs performs the service logic processing on the received message, the received message is written into the message queue module corresponding to the client A client; the node service module to which the user A belongs ends to the user A client. After the processing of the terminal, the write operation of the message queue module of user B is started.

In step S412, the message queue module corresponding to the user B notifies the node service module to which the user B belongs that there is new message delivery.

In an embodiment, in step S413 to step S414, the node service module to which the user B belongs determines the size of the message transmitted by the calling party. If the message size is less than 8K, the SIP MESSAGE message is sent according to the user registration status and the registration type. The protocol support module of the protocol adaptation, the SIP MESSAGE message may carry the protocol conversion indication information, and the protocol conversion indication information may include, for example, the message content, the device information of the user B client, the protocol type, the device information of the user A client, and the protocol type.

In step S415, the protocol support module converts the SIP MESSAGE message sent by the node service module to which the user B belongs to an OTT protocol message (Notify message) (corresponding to the second protocol message described above); the protocol support module is grouped into the user B. The message protocol package acceptable to the client is delivered to the unified access platform.

In step S416, the unified access platform finally delivers the OTT protocol message to the client of user B, and the content of the message received by the OTT client used by user B is directly presented.

In step S417 to step S419, the user B client returns a success response message (200 OK) to the service module through the unified access platform and the protocol support module.

In an embodiment, in step S420 to step S421, the node service module to which the user B belongs determines that the message transmitted by the caller is greater than 8K, and then sends a SIP MESSAGE message to the protocol support module according to the user registration status and the registration type, where The SIP MESSAGE message may carry protocol conversion indication information. The protocol conversion indication information may include, for example, a URL address of the service module storing the message content, device information of the user B client, a protocol type, device information of the user A client, and a protocol type.

In step S422, the protocol support module converts the SIP MESSAGE message sent by the node service module to which the user B belongs to an OTT protocol message (corresponding to the second protocol message described above); the protocol support module group is accepted as the user B client. The message protocol package is sent to the unified access platform.

In step S423, the unified access platform finally delivers the OTT protocol message to the client of user B.

In step S424 to step S426, the user B client returns a success response message (200 OK) to the service module through the unified access platform and the protocol support module.

In step S427, the user B client obtains the message content according to the received URL address, and presents it on the OTT client used by the user B.

It should be noted that, in the present example, step S413 to step S419 are selected to be performed according to the determination result of the message size, or step S420 to step S427 are selected and executed.

FIG. 8 is a flowchart of another example of sending and receiving large messages by different clients according to an embodiment of the present application. In this example, the calling user uses the OTT registration access, and the called RCS user accesses using the standard SIP protocol.

As shown in FIG. 8, the flow of this embodiment includes steps S501 to S528.

In step S501 to step S504, the user A (the present example is the calling user) client determines the size of the message transmitted by the calling party; if the message size is less than 8K, the user A client sends an OTT protocol message; The service platform protocol adapts the protocol support module; the protocol support module converts the OTT protocol message into a SIP INVITE request and transmits the message to the service module; the service module stores the received message.

In an embodiment, in step S505 to step S511, the user A client determines that the message size of the calling transmission is greater than 8K, and the user A client sends an HTTP XCAP protocol message; and the unified access platform forwards to the service platform protocol adaptation. The protocol support module converts the internal support message into an internal message PUT message and sends it to the service module; the service module stores the received message and returns a storage address to the user A client; the user A client sends an OTT protocol message, which carries the message The storage address of the content; the protocol support module that is forwarded to the service platform protocol through the unified access platform; the protocol support module converts the OTT protocol message into a SIP INVITE request and transmits the message to the service module.

It should be noted that, in this example, step S501 to step S504 are selected according to the determination result of the message size, or step S505 to step S511 are selected and executed.

In step S512, the node service module to which the user A belongs performs the service logic processing on the received message, writes the received message to the message queue module corresponding to the user A, and returns a successful service response to the user A client; After the node service module finishes processing the user A, the write operation of the message queue module of the user B is started.

In step S513, the message queue module of the user B notifies the node service module to which the user B belongs that there is a new message delivery.

In step S514 to step S515, the node service module to which the user B belongs determines the size of the message transmitted by the calling party. If the message size is less than 8K, the SIP INVITE signaling is sent to the protocol adaptation according to the user registration status and the registration type. The protocol support module carries the protocol conversion indication information, and the protocol conversion indication information may include, for example, the message content, the device information of the user B client, the protocol type, the device information of the user A client, and the protocol type.

In step S516 to step S517, the protocol support module delivers a SIP INVITE message through the unified access platform.

In step S518 to step S520, after receiving the message, the user B client returns a success response message (200OK) to the unified access platform; the unified access platform returns the success response message to the node service to which the user B belongs through the protocol support module. Module.

In an embodiment, in step S521 to step S525, if the node service module to which the user B belongs determines that the message size of the caller transmission is greater than 8K, the SIP INVITE signaling request is sent to the protocol support module; the protocol support module is unified. The access platform delivers the SIP INVITE signaling, and carries the media channel transmission identifier that needs to be established through negotiation; the node service module to which the user B belongs establishes a media transmission channel (MSRP channel) according to the SIP session signaling and the user B client negotiation, and sends The content of the message is sent to the client of user B. User B receives the content of the message sent through the MSRP channel, and the RCS client used by user B receives the service presentation.

In step S526 to step S528, the user B client returns a success response message (200 OK) to the unified access platform, and the unified access platform returns the success response message to the node service module to which the user B belongs through the protocol support module.

It should be noted that, in the present example, step S514 to step S520 are selected to be performed according to the determination result of the message size, or steps S521 to S528 are selected to be performed.

In summary, the fused message system provided by the embodiment simplifies the complex multi-type message system architecture, combines the characteristics of multiple services, facilitates user operations, and improves the user experience. The fused message system provided in this embodiment adopts a message bus architecture, and has a simple structure and convenient deployment. Moreover, the protocol layer is adapted to the unified access of different types of terminals, and the distributed message is sent to the user through the distribution scheduling of the unified message queue module. On different ends. Exemplarily, the converged message system adopts a combination of a standard protocol architecture and an OTT protocol architecture. The interface between the client and the network message platform can adopt a unified abstract OTT interface protocol, and the client and the converged message system can smoothly transition according to requirements.

FIG. 9 is a flowchart of a message processing method according to an embodiment of the present application. The message processing method provided in this embodiment may be performed by the above-described converged message system. As shown in FIG. 9, the message processing method provided in this embodiment includes: Step S901 to Step S903.

In step S901, a first protocol message is received from a sending client that uses the first protocol access.

In step S902, the first protocol message is converted into a second protocol message supported by the receiving client accessed by the second protocol.

In step S903, a second protocol message is sent to the receiving client.

In an exemplary embodiment, step S902 may include: determining protocol conversion indication information of the first protocol message according to the first protocol message and the stored end registration information; and performing protocol on the first protocol message according to the protocol conversion indication information Convert to get the second protocol message.

In an exemplary embodiment, the message processing method of this embodiment may further include: updating registration information according to the registration information received from the one or more clients and the stored conflict rule table; wherein the terminal registration information includes: The online status of the user of one or more clients and the type of registration. The registration type can indicate the access protocol supported by the client; the conflict rule table records the types of registrations that can coexist on the same client.

In an exemplary embodiment, step S902 may include: if the size of the first protocol message is less than a preset value, performing protocol conversion on the first protocol message to obtain a second protocol that carries the message content of the first protocol message. If the size of the first protocol message is greater than or equal to the preset value, perform protocol conversion on the first protocol message to obtain a second protocol message that carries the storage address of the first protocol message.

In an exemplary embodiment, after the step S901, the message processing method of the embodiment may further include: performing protocol conversion on the first protocol message to obtain a second protocol message; if the size of the first protocol message is greater than or equal to a preset The value establishes a media transmission channel between the receiving client and the receiving client, and transmits the second protocol message through the media transmission channel.

In an exemplary embodiment, the first protocol message may be an OTT protocol message, and the second protocol message may be a converged communication standard protocol message, such as a SIP protocol message; or the first protocol message may be a converged communication standard protocol message, and the second The protocol message can be an OTT protocol message.

For a description of the message processing method provided in this embodiment, reference may be made to the description of the foregoing system embodiment, and thus no further details are provided herein.

In addition, the embodiment of the present application further provides a computer readable medium storing a message processing program, which is implemented by a processor to implement the message processing method as described above.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, and functional blocks or units of the methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules or units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical The components work together. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on a computer readable medium, which may include computer storage media (or non-transitory media) and communication media (or transitory media). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and nonvolatile, implemented in any method or technology for storing information, such as computer readable instructions, data structures, program modules or other data. Sex, removable and non-removable media. Computer storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), and Electrically Erasable Programmable Read Only Memory (EEPROM). , flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical disc storage, magnetic box, magnetic tape, disk storage or other magnetic storage A device, or any other medium that can be used to store desired information and that can be accessed by a computer. Moreover, it is well known to those skilled in the art that communication media typically includes computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and can include any information delivery media. .

Claims

A converged messaging system that includes:

Access platform and service platform;

The access platform is connected to the service platform;

The access platform is configured to receive a first protocol message from a sending client that uses the first protocol access;

The service platform is configured to convert the first protocol message into a second protocol message supported by the receiving client that is accessed by using the second protocol;

The access platform is further configured to send the second protocol message to the receiving client.
The system of claim 1, wherein the service platform comprises: a protocol support module and a service module; and the protocol support module is connected to the service module;

The service module is configured to determine protocol conversion indication information of the first protocol message according to the first protocol message and the stored end registration information, and send the protocol conversion indication information to the protocol support module;

The protocol support module is configured to perform protocol conversion on the first protocol message according to the protocol conversion indication information, and send the converted second protocol message to the access platform.
The system according to claim 2, wherein the service module is further configured to update the end registration information according to the registration information received from the at least one client and the stored conflict rule table;

The end registration information includes: a user online status of the at least one client and a registration type, the registration type can indicate an access protocol supported by the client; and the conflict rule table records that the same client can Coexistence registration type.
The system of claim 2, wherein the protocol support module is adapted to provide a transition between any two of the following: a Session Initiation Protocol, a Message Session Relay Protocol, a Hypertext Transfer Protocol, an Extensible Markup Language Configuration Access XCAP Protocol, access management protocol AOP, Internet-based service OTT protocol.
The system of claim 4, wherein the protocol data unit of the OTT protocol comprises: a message header field, at least one custom message domain; wherein any custom message domain in the at least one custom message domain Including the message header part and the message body part.
The system of claim 2, wherein the service platform further comprises: a unified message queue module, connected to the service module, the unified message queue module configured to store the first protocol received by the service module Message.
The system according to claim 1, wherein if the size of the first protocol message is less than a preset value, the second protocol message carries message content of the first protocol message; if the first protocol message The second protocol message carries the storage address of the first protocol message.
The system according to claim 2, wherein the protocol support module is further configured to perform protocol conversion on the first protocol message, and send the converted second protocol message to the service module;

The service module is further configured to: when determining that the size of the first protocol message is greater than or equal to a preset value, establishing a media transmission channel with the receiving client, and transmitting, by using the media transmission channel, the media transmission channel Second protocol message.
A message processing method includes:

Receiving a first protocol message from a sending client that accesses by using the first protocol;

Converting the first protocol message into a second protocol message supported by the receiving client accessed by using the second protocol;

Sending the second protocol message to the receiving client.
The method of claim 9, wherein the converting the first protocol message to the second protocol message supported by the receiving client accessed by the second protocol comprises:

Determining, according to the first protocol message and the stored end registration information, protocol conversion indication information of the first protocol message;

And performing protocol conversion on the first protocol message according to the protocol conversion indication information to obtain a second protocol message.
The method of claim 10 further comprising:

Updating the end registration information according to the registration information received from the at least one client and the stored conflict rule table;

The end registration information includes: a user online status of the at least one client and a registration type, the registration type can indicate an access protocol supported by the client; and the conflict rule table records that the same client can Coexistence registration type.
The method of claim 9, wherein the converting the first protocol message to the second protocol message supported by the receiving client accessed by the second protocol comprises:

And performing protocol conversion on the first protocol message to obtain a second protocol message that carries the message content of the first protocol message, according to determining that the size of the first protocol message is smaller than a preset value;

And determining, according to determining that the size of the first protocol message is greater than or equal to the preset value, performing protocol conversion on the first protocol message to obtain a second protocol message carrying a storage address of the first protocol message.
The method according to claim 9, after the receiving the first protocol message from the sending client that is accessed by using the first protocol, the method further includes:

Performing protocol conversion on the first protocol message to obtain a second protocol message;

And determining, according to determining that the size of the first protocol message is greater than or equal to a preset value, a media transmission channel with the receiving client, and transmitting, by using the media transmission channel, the second protocol message.
The method according to any one of claims 9 to 13, wherein the first protocol message is an OTT protocol message, and the second protocol message is a converged communication standard protocol message; or the first protocol message To fuse the communication standard protocol message, and the second protocol message is an OTT protocol message.
A computer readable medium storing a message processing program, the message processing program being executed by a processor to implement the message processing method according to any one of claims 9 to 14.