Method for compatible data transmission between Web browser and MCX system

Abstract

The invention discloses a method compatible with data transmission between a Web browser and an MCX system, and belongs to the technical field of communication networks, a gateway is deployed between a Web browser side and a standard MCX system side, bidirectional protocol conversion is executed through the gateway, and the gateway comprises a WebRTC signaling adaptation module, an MCX signaling agent module and a media transfer module; the method comprises the following steps: receiving a call signaling based on a WebRTC protocol from a Web client through a WebRTC signaling adaptation module, and converting the call signaling into an intermediate signaling format; through an MCX signaling agent module, the intermediate signaling format is converted into a signaling format which can be identified by a standard MCX system, and the establishment of a signaling session is completed on behalf of the Web client and the MCX system; media transmission connection with the Web client and the MCX system is established through a media transfer module, and media stream protocol conversion and forwarding are carried out; according to the invention, the technical problem that the Web browser and the MCX system cannot directly communicate due to protocol difference is solved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of communication network, and relates to a method for data transmission between a compatible Web browser and an MCX system. BACKGROUND

[0002] In the MCX (standard key communication) system, especially in the MCPTT (mission critical push-to-talk) service, the architecture is usually composed of three core components of MCPTT client, MCPTT server and media server. With the development of mobile Internet, it has become an explicit trend to expand the MCPTT system capability to a wider range of terminal types. Among them, the Web browser is considered as an ideal carrier for building a lightweight MCPTT client due to its cross-platform and no need for additional software installation. The WebRTC (Web Real-Time Communication) technology built-in in modern browsers provides powerful real-time audio and video communication basic capabilities. However, there is a technical gap of protocol incompatibility between the existing standard MCX system and the WebRTC system, which hinders the direct intercommunication between the two.

[0003] Firstly, in terms of media transmission and security mechanism, the standard MCX system usually uses the RTP (Real-time Transport Protocol) / RTCP (Real-time Transport Control Protocol) protocol family to carry media stream and control signaling, and uses SIP (Session Initiation Protocol) and its SDP (Session Description Protocol) for call control and media negotiation. While WebRTC carries out media transmission based on SRTP (Secure Real-time Transport Protocol) / SRTCP (Secure Real-time Transport Control Protocol), a more secure protocol, and has built-in complex ICE (Interactive Connectivity Establishment), STUN (NAT Session Traversal Utilities) and TURN (Traversal Using Relays around NAT) mechanisms to cope with complex NAT network environment. These two completely different protocol stacks result in that the secure media stream generated by the Web end cannot be directly processed by the standard MCX media server.

[0004] Secondly, there is also an obstacle in the processing of talk burst control messages. The standard MCX system uses RTCP packets to transmit talk burst control signaling. However, for the Web client, such RTCP messages are usually not directly constructed and sent by the application layer code, but automatically processed by the WebRTC underlying engine. This makes it difficult for the Web client to implement the talk burst control process compatible with the MCX system end to end.

[0005] In summary, an MCPTT client running in a web browser cannot directly conduct voice calls with terminals or systems that conform to the standard MCPTT protocol. Currently, the conventional solution to this problem is to develop a completely new media server component that natively supports WebRTC for the MCX system. However, this approach implies a deep modification or even replacement of the existing, stable core network, facing a series of problems such as high R&D costs, long testing cycles, and significant deployment risks, which is detrimental to project risk control.

[0006] Therefore, there is an urgent need in this field for an innovative solution that can efficiently and reliably achieve seamless voice communication between web browsers and standard MCX systems without modifying the existing MCX core network infrastructure. Summary of the Invention

[0007] The purpose of this invention is to overcome the technical bottlenecks of existing standard MCX systems and WebRTC systems being unable to directly interoperate due to protocol differences, and the high cost of modifying existing systems. It provides a data transmission method compatible with web browsers and MCX systems. By deploying signaling and media gateways between the two, a three-in-one protocol conversion architecture of "signaling adaptation-media conversion-talking control" is constructed, realizing end-to-end connectivity from signaling negotiation and secure media stream transmission to talking control, fundamentally solving the problems of system incompatibility and communication failure caused by protocol barriers.

[0008] The technical solution adopted in this invention is a method for data transmission between a web browser and an MCX system. The key is to deploy a signaling and media gateway between the web browser side and the standard MCX system side, and to perform bidirectional protocol conversion through the signaling and media gateway so that the two sides can communicate with each other. The aforementioned signaling and media gateway includes a WebRTC signaling adaptation module, an MCX signaling proxy module, and a media relay module; The above method achieves media stream protocol conversion and forwarding between the Web client and the MCX system, as well as the conversion and transmission of talk control signaling, through the aforementioned signaling and media gateway; wherein, the aforementioned signaling and media gateway establishes a communication session through the following steps: The WebRTC signaling adaptation module receives call signaling from the Web client based on the WebRTC protocol and converts it into an intermediate signaling format. The MCX signaling proxy module converts the intermediate signaling format into a standard MCX system-recognizable signaling format and establishes a signaling session between the web client and the MCX system on behalf of the web client. The media relay module establishes media transmission connections with both the web client and the MCX system to perform media stream protocol conversion and forwarding.

[0009] Specifically, the aforementioned intermediate signaling formats include SIP messages as defined by the standard MCPTT standard and standard WebRTCoffee SDP; the aforementioned web client is an MCPTT client running on a web browser.

[0010] Specifically, the aforementioned media stream protocol conversion and forwarding includes media-level protocol conversion operations and codec conversion operations.

[0011] More specifically, the above-mentioned media-level protocol conversion operation is as follows: the media relay module decrypts the media stream from the Web client based on the Secure Real-Time Transport Protocol (SRTP) and converts it into a Real-Time Transport Protocol (RTP) stream used by the standard MCX system; and encrypts the RTP stream from the MCX system into an SRTP stream and sends it to the Web client.

[0012] More specifically, the above codec conversion operation is performed by the media relay module in real time when the voice codecs supported by the Web client and the MCX system are incompatible, converting the Opus encoding format supported by the Web client to the AMR-WB or AMR-NB encoding formats supported by the MCX system.

[0013] Furthermore, the conversion and transmission of the aforementioned voice control signaling includes: converting the voice control request from the Web client, based on the Session Initiation Protocol (SIP MESSAGE), into voice control signaling based on the Real-Time Transmission Control Protocol (RTCP) used by the standard MCX system; and converting the voice control response from the MCX system, based on RTCP, into a response message based on SIPMESSAGE and sending it back to the Web client.

[0014] Furthermore, the aforementioned SIP MESSAGE uses the proprietary MCPTT XML protocol format as the message body.

[0015] Furthermore, the WebRTC signaling adaptation module receives call signaling from the Web client, specifically by receiving a SIP INVITE request containing a WebRTC Offer SDP via a WebSocket connection.

[0016] Preferably, when the MCX signaling proxy module converts the intermediate signaling format into a signaling format recognizable by the standard MCX system, it specifically performs SDP format conversion, including mapping the interactive connection establishment ICE candidate address information in the WebRTC SDP to the corresponding parameters of the standard MCX system SDP.

[0017] Compared with the prior art, the present invention has the following advantages: This invention proposes a method for achieving voice data transmission compatible with web browsers and standard MCX systems by deploying a signaling and media gateway. By deploying a signaling and media gateway, a complete protocol conversion system is constructed, realizing seamless interoperability between the WebRTC system and the standard MCX system.

[0018] Specifically, its beneficial effects are reflected in the following four core aspects: First, this invention achieves excellent system compatibility, maximizing the utilization of existing investments. It resolves protocol differences through a single external gateway, requiring no hardware or software modifications to the existing MCX core network (including MCPTT servers and media servers) compliant with 3GPP (3rd Generation Partnership Project) standards. This invention significantly reduces the cost and complexity of system upgrades, enabling the rapid and economical extension of specialized critical communication capabilities to web terminals.

[0019] Secondly, this invention ensures low-latency, highly reliable voice communication quality. The signaling and media gateway design of this invention focuses on the efficient processing of real-time media streams. On the one hand, it minimizes the additional latency introduced by protocol conversion through a streamlined protocol stack and efficient transcoding algorithms; on the other hand, it inherits WebRTC's native powerful NAT (Network Address Translation) traversal capabilities (such as ICE, STUN / TURN), ensuring a high success rate in establishing end-to-end connections and maintaining communication stability in complex network environments.

[0020] Third, this invention offers extremely high access flexibility and scenario adaptability. The method of this invention allows any modern browser that supports WebRTC (whether on a PC, mobile phone, or tablet) to quickly access a professional MCX system. This completely breaks the traditional dependence on dedicated hardware, greatly expanding the terminal coverage and application scenarios of mission-critical communication, and providing unprecedented convenience for emergency response, mobile office, and other applications.

[0021] Fourth, this invention ensures end-to-end communication security. The signaling and media gateway of this invention can complete the security context conversion from the Web end to the MCX end, including decrypting and re-encapsulating the DTLS-SRTP (Datagram Transport Layer Security Protocol) media stream commonly used by WebRTC, and performing secure mapping of talk rights control signaling, thereby ensuring the confidentiality and integrity of voice data throughout the entire transmission process while achieving interconnection.

[0022] In summary, this invention not only fundamentally solves the technical bottleneck that prevents direct communication between web browsers and MCX systems due to protocol differences, but also provides a complete solution that is easy to deploy, reliable in performance, secure, and flexible, possessing significant engineering application value and broad market prospects. Detailed Implementation

[0023] Various exemplary embodiments of the present invention will now be described in detail. This detailed description should not be considered as a limitation of the present invention, but rather as a more detailed description of certain aspects, features, and embodiments of the present invention.

[0024] It should be understood that the terminology used in this invention is merely for describing particular embodiments and is not intended to limit the invention. Furthermore, with respect to numerical ranges in this invention, it should be understood that each intermediate value between the upper and lower limits of the range is also specifically disclosed. Any stated value or intermediate value within a stated range, as well as each smaller range between any other stated value or intermediate value within said range, is also included in this invention. The upper and lower limits of these smaller ranges may be independently included or excluded from the range.

[0025] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. While only preferred methods and materials have been described herein, any methods and materials similar or equivalent to those described herein may be used in the implementation or testing of this invention. All references to this specification are incorporated by way of citation to disclose and describe methods and / or materials associated with those references. In the event of any conflict with any incorporated reference, the content of this specification shall prevail.

[0026] Various modifications and variations can be made to the specific embodiments described in this specification without departing from the scope or spirit of the invention, as will be apparent to those skilled in the art. Other embodiments derived from this specification will also be readily apparent to those skilled in the art. This specification and embodiments are merely exemplary.

[0027] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to. Example 1

[0028] This embodiment provides a method for voice data transmission between a web browser and an MCX system that does not support WebRTC. The method deploys a signaling and media gateway between the web browser side and the standard MCX system side.

[0029] The signaling and media gateway in this embodiment includes three core modules: a WebRTC signaling adaptation module, an MCX signaling proxy module, and a media relay module.

[0030] The method in this embodiment performs bidirectional protocol conversion at the signaling, media, and voice control layers through a signaling and media gateway, specifically including the following steps: Step S1, Interoperability process of signaling plane: Signaling plane interoperability aims to establish a communication session, which is accomplished collaboratively by the WebRTC signaling adaptation module and the MCX signaling proxy module of the signaling and media gateway.

[0031] Step S11: The web client initiates a call.

[0032] The MCPTT client on the web browser, i.e. the web client, sends a SIP INVITE call request to the WebRTC signaling adaptation module of the signaling and media gateway via a WebSocket connection; The request includes a standard SIP message and a WebRTC Offer SDP (Proposal Session Description).

[0033] Step S12, Signaling conversion and proxy.

[0034] The WebRTC signaling adaptation module receives and parses the request, converting the signaling information into an intermediate signaling format. This intermediate signaling format includes SIP messages as defined by the standard MCPTT and standard WebRTC Offer SDP. Subsequently, the MCX signaling agent module obtains this intermediate signaling format and performs SDP format conversion, mapping the interactive connection establishment (ICE) candidate address information in the WebRTCOffer SDP to the corresponding parameters of the standard MCX system SDP, thereby generating a SIP INVITE request that can be recognized by the standard MCX system.

[0035] Step S13: Interact with the MCX system.

[0036] The MCX signaling agent module sends the converted SIP INVITE request to the MCX system and completes the standard SIP session establishment process with the MCX system on behalf of the web client, and finally receives the SIP 200 OK response from the MCX system.

[0037] Step S14: Response feedback.

[0038] The MCX signaling proxy module passes the Answer SDP from the 200 OK response to the WebRTC signaling adapter module through an intermediate signaling format. The WebRTC signaling adaptation module reverse-engineers it into a WebRTC Answer SDP (Response Session Description) and sends it back to the web client via a WebSocket connection.

[0039] Step S2, Media Interface Communication Process: The media plane interconnection is responsible for the bidirectional flow of voice data, which is executed by the media relay module of the signaling and media gateway, including media layer protocol conversion operations and codec conversion operations.

[0040] Step S21: Establish a media transmission connection.

[0041] The media relay module establishes media transmission connections with both the Web client and the MCX system. The connection with the Web client is a standard WebRTC PeerConnection. Voice data is collected and encoded into SRTP packets on the Web client and sent to the signaling and media gateway via the optimal path established by ICE.

[0042] Step S22: Media stream conversion and forwarding from Web to MCX.

[0043] The media relay module of the signaling and media gateway performs the following core operations: Step S221, SRTP to RTP conversion: The media relay module decrypts SRTP-based media streams from web clients and converts them into clean RTP streams.

[0044] Step S222, Codec Conversion: When it is detected that the web client is incompatible with the voice codecs supported by the MCX system, such as the web client using Opus (audio codec format) and the MCX client requiring AMR-WB (Adaptive Multi-Rate Wideband Coding), the media relay module starts the real-time voice transcoding function to convert between Opus encoding format and AMR-WB encoding format.

[0045] Step S223: The converted RTP stream is forwarded to the media server of the MCX system.

[0046] Step S224, Package Format and Timing Adjustment: Adjust the timestamps, sequence numbers, etc. of the RTP packets to meet the timing requirements of the MCX system, and then repackage them.

[0047] Step S23: Media stream conversion and forwarding from MCX to Web, i.e., reverse media stream processing. Specifically, this includes: The media relay module receives RTP-based media streams from the MCX system media server; then, it encodes, decodes, and transcodes the streams as needed, and performs encrypted conversion from RTP to SRTP; finally, it sends the resulting SRTP stream to the web client through the established WebRTCPeerConnection.

[0048] Step S3, Interoperability of Voice Control Plane: Interoperability of the voice control plane ensures that the Web client can participate in the voice control mechanism of the MCX system. The protocol format for voice control messages needs to be negotiated between the Web client and the signaling and media gateway. For example, in this invention, the voice control messages between the Web client and the signaling and media gateway are carried by SIP MESSAGE messages, using the proprietary MCPTT XML protocol format of this invention as the message body.

[0049] Step S31: Switching of voice control signaling from Web to MCX.

[0050] When a web client initiates a talk request, it sends a SIP MESSAGE message to the signaling and media gateway, which uses the proprietary MCPTT XML protocol format as the message body. The signaling and media gateway parses this message and converts its content into an equivalent talk control packet based on the Real-time Transmission Control Protocol (RTCP), which is then sent to the MCX system.

[0051] Step S32: MCX to Web talk rights signaling conversion, i.e. reverse talk rights control processing.

[0052] The signaling and media gateway receives the RTCP-based call control response from the MCX system, converts its content into a SIP message, and sends it back to the web client. Example 2

[0053] This embodiment provides an application scenario based on the method of Embodiment 1, and details the specific application of the method of the present invention in actual emergency rescue command scenarios.

[0054] In this scenario, the command center uses the standard MCPTT system, while on-site volunteers are only equipped with laptops running Chrome. Seamless voice communication between the two can be achieved by deploying a signaling and media gateway server in the network; this gateway is pre-configured with the address and authentication information of the MCX server.

[0055] The signaling and media gateway in this embodiment includes three core modules: the WebRTC signaling adaptation module, the MCX signaling proxy module, and the media relay module.

[0056] This embodiment is based on the method of Embodiment 1, and performs bidirectional protocol conversion at the signaling, media, and voice control layers through the signaling and media gateway. The specific application process is as follows: Step S1, Interoperability process of signaling plane: Signaling plane interoperability aims to establish a communication session, which is accomplished collaboratively by the WebRTC signaling adaptation module and the MCX signaling proxy module of the signaling and media gateway.

[0057] Step S11: The web client initiates a call.

[0058] On-site volunteers open a designated URL, and their browsers load a JavaScript-based Web MCPTT client, i.e., a Web client. The web client connects to the signaling and media gateway via WebSocket. When a volunteer clicks "Join Rescue Team 1" on the web interface, the web client creates a SIP INVITE message with WebRTC Offer SDP and sends it to the signaling and media gateway via WebSocket.

[0059] Step S12, Signaling conversion and proxy.

[0060] The WebRTC signaling adaptation module receives and parses the request, converting the signaling information into an intermediate signaling format. This intermediate signaling format includes SIP messages as defined by the standard MCPTT and standard WebRTC Offer SDP. Subsequently, the MCX signaling proxy module obtains this intermediate signaling format and generates a SIP INVITE request, fills in an Offer SDP without WebRTC features, and sends the message to the MCX system's MCPTT server, requesting "Join Rescue Group 1".

[0061] Step S13: Interact with the MCX system.

[0062] The MCX signaling agent module sends the converted SIP INVITE request to the MCX system and completes the standard SIP session establishment process with the MCX system on behalf of the web client, and finally receives the SIP 200 OK response from the MCX system.

[0063] Step S14: Response feedback.

[0064] The MCX signaling proxy module passes the Answer SDP from the 200 OK response to the WebRTC signaling adapter module through an intermediate signaling format. The WebRTC signaling adaptation module converts the SDP in the 200 OK response into a WebRTC Answer SDP and sends it back to the volunteer's web browser.

[0065] Step S2, Media Interface Communication Process: The media plane interconnection is responsible for the bidirectional flow of voice data, which is executed by the media relay module of the signaling and media gateway, including media layer protocol conversion operations and codec conversion operations.

[0066] Step S21: Establish a media transmission connection.

[0067] The browser establishes an SRTP media stream with the signaling and media gateway, and the media relay module establishes media transmission connections with the web client and the MCX system respectively. The connection established with the web client is a standard WebRTC PeerConnection.

[0068] Step S22: Media stream conversion and forwarding from Web to MCX.

[0069] After the volunteer presses the PTT (One-Click) button on the web interface and gains the right to speak, the voice data transmission stream is opened, and the Opus-encoded voice SRTP stream reaches the signaling and media gateway.

[0070] The media relay module of the signaling and media gateway performs the following core operations: Step S221, SRTP to RTP conversion: The media relay module decrypts SRTP and converts it into a clean RTP stream.

[0071] Step S222, Codec Conversion: The media relay module transcodes it into an RTP stream in AMR-WB format required by the MCX system.

[0072] Step S223: The converted RTP stream is forwarded to the media server of the MCX system.

[0073] Step S224, Package Format and Timing Adjustment: The media relay module adjusts the timestamps, sequence numbers, and other parameters of RTP packets to meet the timing requirements of the MCX system.

[0074] Step S23: Media stream conversion and forwarding from MCX to Web, i.e., reverse media stream processing. Specifically, this includes: The media server distributes this audio stream to all other MCPTT terminals within the group (including command center and other rescue personnel). The PTT (Public Talk Platform) voice messages from the command center commander are transmitted back to the volunteers' browsers via the reverse path and played back, specifically including: The media relay module receives RTP streams from the MCX system, encodes and decodes them as needed, encrypts them into SRTP streams, and sends them to the web client via WebRTC PeerConnection.

[0075] Step S3, Interoperability of Voice Control Plane: Interoperability of the speech control plane ensures that the Web client can participate in the speech control mechanism of the MCX system.

[0076] Step S31: Switching of voice control signaling from Web to MCX.

[0077] When a volunteer presses the PTT button on the web interface to request to speak, their talk control message is carried in a SIPMESSAGE message and forwarded to the MCX system via the signaling and media gateway.

[0078] Step S32: MCX to Web talk rights signaling conversion, i.e. reverse talk rights control processing.

[0079] The signaling and media gateway converts the RTCP response message generated by the MCX system into a SIP MESSAGE message and sends it to the web client; at this point, the web client obtains call access.

[0080] This embodiment demonstrates the entire process of volunteers accessing a standard MCX communication system via a web browser in an emergency scenario. Through the coordinated action of signaling and media gateways, a complete communication link from call setup and media stream forwarding to talk control is achieved, confirming the technical feasibility of achieving bidirectional interoperability between the web client and the professional MCPTT system at the signaling, media, and control levels, ultimately realizing seamless voice communication between heterogeneous systems.

[0081] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for data transmission between a web browser and an MCX system, characterized in that, A signaling and media gateway is deployed between the web browser side and the standard MCX system side. The signaling and media gateway performs bidirectional protocol conversion to enable the two sides to communicate with each other. The signaling and media gateway includes a WebRTC signaling adaptation module, an MCX signaling proxy module, and a media relay module; The method achieves media stream protocol conversion and forwarding between the Web client and the MCX system, as well as the conversion and transmission of talk control signaling, through the signaling and media gateway. The signaling and media gateway establishes a communication session through the following steps: The WebRTC signaling adaptation module receives call signaling from the Web client based on the WebRTC protocol and converts it into an intermediate signaling format. The MCX signaling proxy module converts the intermediate signaling format into a standard MCX system-recognizable signaling format and establishes a signaling session between the web client and the MCX system on behalf of the web client. The media relay module establishes media transmission connections with both the web client and the MCX system to perform media stream protocol conversion and forwarding.

2. The data transmission method according to claim 1, characterized in that, The intermediate signaling format includes SIP messages as defined by the standard MCPTT standard and standard WebRTC Offer SDP; the web client is an MCPTT client running on a web browser.

3. The data transmission method according to claim 1, characterized in that, The media stream protocol conversion and forwarding includes media-level protocol conversion operations and codec conversion operations.

4. The data transmission method according to claim 3, characterized in that, The specific media layer protocol conversion operation is as follows: the media relay module decrypts the media stream from the Web client based on the Secure Real-Time Transport Protocol (SRTP) and converts it into a Real-Time Transport Protocol (RTP) stream used by the standard MCX system; and encrypts the RTP stream from the MCX system into an SRTP stream and sends it to the Web client.

5. The data transmission method according to claim 3, characterized in that, The codec conversion operation is performed by the media relay module in real time when the Web client and the voice codec supported by the MCX system are incompatible. This converts the Opus encoding format supported by the Web client to the AMR-WB or AMR-NB encoding format supported by the MCX system.

6. The data transmission method according to claim 1, characterized in that, The conversion and transmission of the right-of-way control signaling includes: converting the right-of-way control request from the Web client, based on the Session Initiation Protocol (SIP MESSAGE), into right-of-way control signaling based on the Real-Time Transmission Control Protocol (RTCP) used by the standard MCX system; and converting the right-of-way control response from the MCX system, based on RTCP, into a response message based on SIP MESSAGE and sending it back to the Web client.

7. The data transmission method according to claim 6, characterized in that, The SIP MESSAGE uses the proprietary MCPTT XML protocol format as the message body.

8. The data transmission method according to claim 1, characterized in that, The WebRTC signaling adapter module receives call signaling from the web client, specifically by receiving a SIPINVITE request containing a WebRTC Offer SDP via a WebSocket connection.

9. The data transmission method according to claim 1, characterized in that, When the MCX signaling agent module converts the intermediate signaling format into a signaling format recognizable by the standard MCX system, it specifically performs SDP format conversion, including mapping the interactive connection establishment ICE candidate address information in WebRTC SDP to the corresponding parameters of the standard MCX system SDP.