阅读说明：本技术 一种数据传输方法、装置及存储介质 (Data transmission method, device and storage medium ) 是由 林皓 宋可新 付凯 王岩 宋萌 于 2020-12-30 设计创作，主要内容包括：本申请实施例提供一种数据传输方法、装置及存储介质,方法包括：当进行音视频会话时,通过预先创建的一个用户数据报协议UDP端口接收至少一个发送端所发送的至少一个UDP数据包；基于每个UDP数据包、UDP数据包的发送端以及UDP数据包的接收端之间的映射关系,将每个UDP数据包发送给所述UDP数据包所对应的接收端。本申请实施例实现了单端口对音视频数据的转发过程,大幅度减少webrtc音视频数据转发所占用的UDP端口数量,解决了端口随接入人数不断增加的问题。(An embodiment of the application provides a data transmission method, a data transmission device and a storage medium, wherein the method comprises the following steps: when audio and video conversation is carried out, at least one UDP data packet sent by at least one sending end is received through a User Datagram Protocol (UDP) port which is created in advance; and sending each UDP data packet to a receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet. The embodiment of the application realizes the forwarding process of the single port to the audio and video data, greatly reduces the number of UDP ports occupied by the webrtc audio and video data forwarding, and solves the problem that the number of the ports is continuously increased along with the number of the users who access the ports.)

1. A method of data transmission, comprising:

when audio and video conversation is carried out, at least one UDP data packet sent by at least one sending end is received through a User Datagram Protocol (UDP) port which is created in advance;

and sending each UDP data packet to a receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

2. The data transmission method according to claim 1, wherein before sending each UDP packet to the receiving end corresponding to the UDP packet based on a mapping relationship among each UDP packet, the sending end of the UDP packet, and the receiving end of the UDP packet, the method further comprises:

acquiring the type of each UDP data packet;

and acquiring the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet based on the type of each UDP data packet.

3. The data transmission method according to claim 2, wherein the obtaining a mapping relationship between each UDP packet, the sending end of the UDP packet, and the receiving end of the UDP packet based on the type of each UDP packet comprises:

when the type of the UDP data packet is a NAT session traversal application STUN, determining a source IP and a sending port of the UDP data packet through a UDP protocol, and determining a sending end of the UDP data packet based on the source IP and the sending port of the UDP data packet;

acquiring other clients which have the same audio and video session with the sending end, and determining the other clients as a receiving end of the UDP data packet;

and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

4. The data transmission method according to claim 3, further comprising:

determining a port and an IP address of the transmitting end based on a mapping relation among the UDP data packet, the transmitting end of the UDP data packet and the receiving end of the UDP data packet;

and sending a data return packet of the STUN protocol to the sending end based on the port and the IP address of the sending end.

5. The data transmission method according to claim 2, wherein the obtaining a mapping relationship between each UDP packet, the sending end of the UDP packet, and the receiving end of the UDP packet based on the type of each UDP packet comprises:

when the type of the UDP data packet is a real-time transport protocol RTP or a real-time transport control protocol RTCP, analyzing the packet head of the UDP data packet to acquire a synchronous information source SSRC identifier;

based on a session stream SSRC identifier in a pre-established audio and video session and a mapping relation between a sending end and a receiving end, the sending end and the receiving end of the UDP data packet are obtained;

and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

6. The data transmission method according to claim 5, wherein the sending each UDP packet to the receiving end corresponding to the UDP packet based on a mapping relationship among each UDP packet, the sending end of the UDP packet, and the receiving end of the UDP packet, comprises:

when the type of the UDP data packet is RTP or RTCP, modifying the packet head of the UDP data packet so that a receiving end of the UDP data packet can normally receive the UDP data packet, carrying out data packet verification and security socket protocol (SSL) encryption operation on the modified UDP data packet, and sending the RTP data packet which passes the verification and is encrypted to the receiving end corresponding to the UDP data packet;

the RTCP type data packets include a sending end report SR data packet, a receiving end report RR data packet, a feedback report FB data packet or a transmission ending BYE data packet.

7. The data transmission method according to any one of claims 1 to 6, further comprising:

and updating the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet in real time.

8. A data transmission apparatus, comprising:

the receiving module is used for receiving at least one UDP data packet sent by at least one sending end through a pre-established UDP port;

and the sending module is used for sending each UDP data packet to the receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the data transmission method according to any of claims 1 to 7 are implemented when the processor executes the program.

10. A non-transitory computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the data transmission method according to any one of claims 1 to 7.

Technical Field

The present application relates to the field of data transmission technologies, and in particular, to a data transmission method, an apparatus, and a storage medium.

Background

When media data are forwarded by using a Web Real-Time Communication (Webrtc) audio and video technology from an insecure network, multi-port User Datagram Protocol (UDP) is adopted for corresponding forwarding. The number of the UDP ports can be increased along with the multiple of the number of the participants, the potential requirement of releasing a plurality of UDP ports for an insecure network is met, and the potential risk of network attack of the insecure network is greatly increased.

Disclosure of Invention

The embodiment of the application provides a data transmission method, a data transmission device and a storage medium, and aims to solve the problem that the number of required ports is continuously increased along with the number of users accessing the ports in the audio and video process.

An embodiment of the present application provides a data transmission method, including:

when audio and video conversation is carried out, at least one UDP data packet sent by at least one sending end is received through a User Datagram Protocol (UDP) port which is created in advance;

and sending each UDP data packet to a receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Optionally, before sending each UDP data packet to the receiving end corresponding to the UDP data packet based on a mapping relationship between each UDP data packet, the sending end of the UDP data packet, and the receiving end of the UDP data packet, the method further includes:

acquiring the type of each UDP data packet;

and acquiring the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet based on the type of each UDP data packet.

Optionally, the obtaining, based on the type of each UDP data packet, a mapping relationship between each UDP data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet includes:

when the type of the UDP data packet is a NAT session traversal application STUN, determining a source IP and a sending port of the UDP data packet through a UDP protocol, and determining a sending end of the UDP data packet based on the source IP and the sending port of the UDP data packet;

acquiring other clients which have the same audio and video session with the sending end, and determining the other clients as a receiving end of the UDP data packet;

and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Optionally, the method further comprises:

determining a port and an IP address of the transmitting end based on a mapping relation among the UDP data packet, the transmitting end of the UDP data packet and the receiving end of the UDP data packet;

and sending a data return packet of the STUN protocol to the sending end based on the port and the IP address of the sending end.

Optionally, the obtaining, based on the type of each UDP data packet, a mapping relationship between each UDP data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet includes:

when the type of the UDP data packet is a real-time transport protocol RTP or a real-time transport control protocol RTCP, analyzing the packet head of the UDP data packet to acquire a synchronous information source SSRC identifier;

based on a session stream SSRC identifier in a pre-established audio and video session and a mapping relation between a sending end and a receiving end, the sending end and the receiving end of the UDP data packet are obtained;

and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Optionally, the sending, based on a mapping relationship between each UDP data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet, each UDP data packet to the receiving end corresponding to the UDP data packet includes:

when the type of the UDP data packet is RTP or RTCP, modifying the packet head of the UDP data packet so that a receiving end of the UDP data packet can normally receive the UDP data packet, carrying out data packet verification and security socket protocol (SSL) encryption operation on the modified UDP data packet, and sending the RTP data packet which passes the verification and is encrypted to the receiving end corresponding to the UDP data packet;

the RTCP type data packets include a sending end report SR data packet, a receiving end report RR data packet, a feedback report FB data packet or a transmission ending BYE data packet.

Optionally, the method further comprises:

and updating the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet in real time.

This embodiment also provides a data transmission device, including:

the receiving module is used for receiving at least one UDP data packet sent by at least one sending end through a pre-established UDP port;

and the sending module is used for sending each UDP data packet to the receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

An embodiment of the present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the steps of the data transmission method when executing the program.

Embodiments of the present application provide a non-transitory computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, implements the steps of the data transmission method.

According to the data transmission method, the data transmission device and the storage medium, when audio and video conversation is carried out, at least one UDP data packet sent by at least one sending end is received through a pre-established UDP port, each UDP data packet is sent to a receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet, UDP single-port forwarding of the UDP data is achieved, the number of UDP ports occupied by webrtc audio and video data forwarding is greatly reduced, the number of the ports cannot be increased continuously due to the number of people, the risk of non-secure network attack caused by excessive ports is reduced, and the problem that the number of the ports is increased continuously along with the number of people who are accessed is solved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

FIG. 1 is a flow chart illustrating steps of a data transmission method according to an embodiment of the present application;

fig. 2 is a schematic diagram of a data forwarding process in an embodiment of the present application;

FIG. 3 is a block diagram of a data transmission apparatus according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of an electronic device in an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

As shown in fig. 1, which is a flowchart illustrating steps of a data transmission method in an embodiment of the present application, the method includes the following steps:

step 101: when the audio and video conversation is carried out, at least one UDP data packet sent by at least one sending end is received through a pre-established UDP port.

Specifically, the audio-video session may be a Webrtc audio-video session.

In the data transmission process, the data transmission device creates a unique User Datagram Protocol (UDP) port, and receives at least one UDP data packet sent by at least one sending end through the unique UDP port, so that the Webrtc media data is forwarded by the single UDP port, and the number of the ports is not increased continuously due to the number of people.

The number of the transmitting ends may be plural, and is not particularly limited herein. In addition, multiple transmitting ends may transmit UDP packets at the same time or at different times, which is not particularly limited herein.

Step 102: and sending each UDP data packet to a receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Specifically, the sending end and the receiving end are clients, which may be a computer, a mobile phone, a tablet, or the like, in this embodiment, one client may be the sending end or the receiving end, and the client that sends data is determined as the sending end, and the client that receives data is determined as the receiving end.

In this step, a mapping relationship between each received UPD data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet may be obtained first, and then each UDP data packet is sent to the receiving end corresponding to the UDP data packet based on the mapping relationship, so that a forwarding process of the UDP single port to data is implemented, and a risk of an insecure network attack caused by too many ports is reduced.

Of course, the receiving end of the UDP packet may be one or more, and this is not limited herein. In addition, after the receiving end receives the UDP data packet, the receiving end can reply the UDP data packet through the established dynamic mapping relation among the DUP data packet, the sending end and the receiving end, and accurate and efficient real-time audio and video data forwarding is realized.

In addition, it should be noted that, when the UDP port forwards the received UDP packet, a secure transport protocol (SRTP) transmission scheme may be used, and a Session Description Protocol (SDP) key exchange manner is used to ensure secure transmission of the audio/video session. In addition, the encryption and decryption of the UDP data packet can be performed in a Secure Socket Layer (SSL) manner, so as to ensure the secure transmission of the audio/video session.

In this way, in this embodiment, by creating the only one UDP port, receiving the plurality of UDP data packets through the only one UDP port, and then sending each UDP data packet to the receiving end corresponding to the UDP data packet, media data is forwarded by a single port, and the problem that the number of ports increases with the number of users accessing the ports is solved.

Optionally, in this embodiment, before sending each UDP data packet to the receiving end corresponding to the UDP data packet based on the mapping relationship between each UDP data packet, the sending end of the UDP data packet, and the receiving end of the UDP data packet, the following steps need to be further performed:

step A1: and acquiring the type of each UDP data packet.

Specifically, the embodiment may perform packet segmentation and classification on the received UDP data packet, and specifically, may determine the length of the data packet and the type of the data packet by analyzing the header of the UDP data packet.

Specifically, the types of the UDP packets may include a network address translation session traversal application (STUN), a real-time transport protocol (RTP), and a real-time transport control protocol (RTCP), that is, the UDP packets may be STUN packets, RTP packets, or RTCP packets.

Step A2: and acquiring the mapping relation among each UDP data packet, the transmitting end of the UDP data packet and the receiving end of the UDP data packet based on the type of each UDP data packet.

Specifically, in this embodiment, based on the type of each UDP data packet, the mapping relationship between each UDP data packet, the sending end of the UDP data packet, and the receiving end of the UDP data packet may be obtained in different manners.

The mapping relationship may be obtained in the following manners:

firstly, when the type of the UDP data packet is STUN, a source IP and a sending port of the UDP data packet may be determined through a UDP protocol, a sending end of the UDP data packet is determined based on the source IP and the sending port of the UDP data packet, then other clients performing the same audio/video session with the sending end are obtained, the other clients are determined as a receiving end of the UDP data packet, and finally a mapping relationship between the UDP data packet, the sending end of the UDP data packet, and the receiving end of the UDP data packet is established.

Specifically, when the type of the UDP packet is STUN, that is, when the UDP packet is a STUN packet, a source IP and a sending port of the UDP packet may be determined by a UDP protocol, that is, a sending end of the UDP packet is determined; in addition, in this embodiment, other clients performing the same audio/video session with the sending end of the UDP data packet may also be obtained, and the other clients are determined as the receiving end of the UDP data packet, so that a mapping relationship between the UDP data packet, the sending end of the UDP data packet, and the receiving end of the UDP data packet may be dynamically established.

Specifically, when the type of the UDP packet is STUN, the source of the packet may also be determined by using username in the STUN protocol, so as to establish a mapping relationship between the username and the STUN packet, and determine a source IP and a sending port of the packet by using the UDP protocol, and further establish a binding relationship between the uersname and the source IP and the port of the packet, that is, the uersname represents the packet, the mapping relationship between the uersname and the sending end of the packet is established, and finally the mapping relationship between the uersname, the sending end of the UDP packet, and the receiving end of the UDP packet is established.

In addition, optionally, in this embodiment, when the UDP packet is a STUN packet, a data return packet of the STUN protocol needs to be performed after the SUTN packet is analyzed, at this time, a port and an IP address of a transmitting end may be determined based on a mapping relationship between the UDP packet, the transmitting end of the UDP packet, and a receiving end of the UDP packet, and the data return packet of the STUN protocol is sent to the transmitting end based on the port and the IP address of the transmitting end, so that session link connectivity is ensured.

In addition, in this embodiment, the source IP and the port of the data packet need to be updated in real time to ensure that the UDP link can correctly return the packet to the sending end when the sending end switches the network address, for example: the transmitting end switches the network in the data transmitting process, the 4G network is switched to the WiFi network, and the normal conversation can still be ensured, so that the audio and video conversation is not influenced by network switching.

Secondly, when the type of the UDP data packet is RTP or RTCP, analyzing the packet head of the UDP data packet to obtain a synchronous information source (SSRC for short), then obtaining a sending end and a receiving end of the UDP data packet based on a session stream SSRC identifier in the audio and video session and a mapping relation between the sending end and the receiving end, and then establishing a mapping relation between the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Specifically, in the audio/video session process, a secure transport layer protocol (TLS) mode may be used to perform SDP protocol interaction, perform key interaction among multiple parties of the session, agree on an SSRC identifier as a unique identifier of the session stream, and establish a mapping relationship between each client (including a sending end and a receiving end) and the SSRC identifier.

Then, when the type of the UDP packet is RTP or RTCP, that is, the UDP packet is an RTP packet or an RTCP packet, the header of the UDP packet may be analyzed to obtain the SSRC identifier, and then the receiving end of the UDP packet may be determined based on a mapping relationship between the SSRC identifier and the receiving end, so that a mapping relationship between the UDP packet, the transmitting end of the UDP packet, and the receiving end of the UDP packet may be established.

In addition, optionally, in this embodiment, when each UDP data packet is sent to the receiving end corresponding to the UDP data packet, when the type of the UDP data packet is RTP or RTCP, the header of the UDP data packet may be modified so that the receiving end of the UDP data packet can receive the UDP data packet normally, and the modified UDP data packet is subjected to data packet verification and secure socket protocol SSL encryption operation, and the UDP data packet that passes the verification and encryption is sent to the receiving end corresponding to the UDP data packet.

The RTCP type data packets include a Sender Report (SR) data packet, a Receiver Report (RR) data packet, a feedback report (FB) data packet, or a transmission end (BYE) data packet.

Specifically, when the type of the UDP packet is RTP or RTCP, the timestamp may be changed and the MAPPING value may be modified when the packet header of the packet is modified, so that the receiving end of the packet can receive the packet normally, and then the packet may be verified and the SSL data may be encrypted and finally transmitted to the receiving end.

In addition, when the type of the DUP packet is RTCP, the RTCP packet may be further classified to detect whether the RTCP packet is an SR packet, an RR packet, an FB packet, or a BYE packet, and then the SR packet, the RR packet, the FB packet, and the BYE packet are modified, respectively, and the timestamp and the modified MAPPING value may be changed during the modification.

Therefore, the mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet is established through the process, and the UDP data packet can be correctly sent to the receiving end.

In addition, optionally, in this embodiment, the mapping relationship between each UDP data packet, the sending end of the UDP data packet, and the receiving end of the UDP data packet needs to be updated in real time, so that normal running of a session can be ensured, and it is ensured that an audio/video session is not affected by network switching.

It should be noted that, in this embodiment, the receiving end may also serve as the sending end to send the audio/video data generated by the receiving end while receiving the data, so as to form a single-port data forwarding process for communicating the audio and the video of both parties.

The process of the present application is specifically explained below with reference to fig. 2.

Firstly, the sending end and the receiving end carry out SDP protocol interaction in an LTS mode, exchange keys and determine SSRC session flow identification.

Then, the sending terminals Client a, Client B, Client C, Client n, etc. send data packets, and at this time, the UDP port receives the data packets sent by the multiple sending terminals, that is, receives the mixed data, and performs packetization and classification of different data packets, data tracing and data decryption by analyzing the data packet header.

And then, after data tracing and data decryption, establishing a mapping relation among the data packet, a transmitting end of the data packet and a receiving end of the data packet in the data mapping area.

When the data packet is the STUN data packet, determining the source of the data packet through the username in the STUN protocol, establishing a mapping relation between the username and the STUN data packet, determining the source IP and the sending port of the data packet through the UDP protocol, establishing a binding relation between the uersname and the source IP and the port of the data packet, and updating the IP and the port of the sending end in real time. In addition, after the STUN data packet is analyzed, data repackaging of the STUN protocol is carried out, a repackaging client, namely a port and an IP address of a sending end, is determined through the mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet, and the STU repackaging is carried out to ensure that session links are communicated.

When the data packet is an RTP data packet, acquiring the unique identifier of the SSRC session stream by analyzing an RTP protocol header, determining a receiving end of the RTP data packet, then modifying the header of the RTP data packet, changing the timestamp, modifying the MAPPING value of the data, then carrying out data packet verification and SSL data encryption, and forwarding the data packet to the corresponding receiving end. For example, sender a1 sends a packet to receiver (Client) a ', sender B sends a packet to receiver B', and sender An sends a packet to receiver Bn.

When the data packet is the RTCP data packet, the packet head of the RTP data packet is analyzed to obtain the unique identification of the SSRC session flow, and whether the data packet is the RTCP data packet is further judged, if so, the RTCP data packet is classified to confirm whether the data packet is the SR packet, the RR packet, the FB packet or the BYE packet.

And finally, respectively modifying the packet headers of the RTP packet, the SR packet, the RR packet, the FB packet, the BYE packet and the like in the data calibration area, changing the timestamp, modifying the MAPPING value of the data, verifying the data packet, encrypting SSL data in the data encryption area, and forwarding the data to a corresponding receiving end. For example, based on the mapping relationship, the receiving end Client a 'receives the real-time data of the sending end Client a, the receiving end Client B' receives the real-time data of the sending end Client B, the receiving end Client C 'receives the real-time data of the sending end Client C, and the receiving end Client n' receives the real-time data of the sending end Client n.

In the above process, the source IP and the port of the data packet need to be updated in real time to ensure that the UDP link switches the network address at the sending end, and the packet can be correctly returned to the sending end, for example: the transmitting end switches the network in the data transmitting process, and when the 4G network is switched to the WiFi network, the normal conversation can still be ensured, and the audio and video conversation is not influenced by network switching.

Therefore, in the embodiment, the audio and video data are forwarded through the single UDP port, the number of UDP ports occupied by webrtc audio and video data forwarding is greatly reduced, and the maintenance cost during the technical use is reduced.

In addition, as shown in fig. 3, a block diagram of a data transmission apparatus according to the present application is shown, where the apparatus includes:

a receiving module 301, configured to receive, through a pre-created user datagram protocol UDP port, at least one UDP data packet sent by at least one sending end when performing an audio/video session;

a sending module 302, configured to send each UDP data packet to a receiving end corresponding to the UDP data packet based on a mapping relationship between each UDP data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet.

Optionally, the apparatus further comprises:

the first acquisition module is used for acquiring the type of each UDP data packet;

and the second acquisition module is used for acquiring the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet based on the type of each UDP data packet.

Optionally, the second obtaining module is specifically configured to, when the type of the UDP packet is nat session traversal application STUN, determine a source IP and a sending port of the UDP packet through a UDP protocol, and determine a sending end of the UDP packet based on the source IP and the sending port of the UDP packet; acquiring other clients which have the same audio and video session with the sending end, and determining the other clients as a receiving end of the UDP data packet; and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Optionally, the second obtaining module is specifically configured to, when the type of the UDP data packet is a real-time transport protocol RTP or a real-time transport control protocol RTCP, analyze a packet header of the UDP data packet, and obtain a synchronization source SSRC identifier; based on a session stream SSRC identifier in a pre-established audio and video session and a mapping relation between a sending end and a receiving end, the sending end and the receiving end of the UDP data packet are obtained; and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

It should be noted that, the present apparatus can implement the method steps implemented by the foregoing method, and can achieve the same technical effects, which are not described herein again.

In addition, as shown in fig. 4, for an entity structural schematic diagram of the electronic device provided in the embodiment of the present application, the electronic device may include: a processor (processor)410, a communication Interface 420, a memory (memory)430 and a communication bus 440, wherein the processor 410, the communication Interface 420 and the memory 430 are communicated with each other via the communication bus 440. The processor 410 may invoke a computer program stored on the memory 430 and executable on the processor 410 to perform the methods provided by the various embodiments described above, including, for example:

when audio and video conversation is carried out, at least one UDP data packet sent by at least one sending end is received through a User Datagram Protocol (UDP) port which is created in advance; and sending each UDP data packet to a receiving end corresponding to the UDP data packet based on the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Optionally, before sending each UDP data packet to the receiving end corresponding to the UDP data packet based on a mapping relationship between each UDP data packet, the sending end of the UDP data packet, and the receiving end of the UDP data packet, the method further includes:

acquiring the type of each UDP data packet; and acquiring the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet based on the type of each UDP data packet.

Optionally, the obtaining, based on the type of each UDP data packet, a mapping relationship between each UDP data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet includes:

when the type of the UDP data packet is a NAT session traversal application STUN, determining a source IP and a sending port of the UDP data packet through a UDP protocol, and determining a sending end of the UDP data packet based on the source IP and the sending port of the UDP data packet; acquiring other clients which have the same audio and video session with the sending end, and determining the other clients as a receiving end of the UDP data packet; and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Optionally, the method further comprises:

determining a port and an IP address of the transmitting end based on a mapping relation among the UDP data packet, the transmitting end of the UDP data packet and the receiving end of the UDP data packet; and sending a data return packet of the STUN protocol to the sending end based on the port and the IP address of the sending end.

Optionally, the obtaining, based on the type of each UDP data packet, a mapping relationship between each UDP data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet includes:

when the type of the UDP data packet is a real-time transport protocol RTP or a real-time transport control protocol RTCP, analyzing the packet head of the UDP data packet to acquire a synchronous information source SSRC identifier; based on a session stream SSRC identifier in a pre-established audio and video session and a mapping relation between a sending end and a receiving end, the sending end and the receiving end of the UDP data packet are obtained; and establishing a mapping relation among the UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet.

Optionally, the sending, based on a mapping relationship between each UDP data packet, a sending end of the UDP data packet, and a receiving end of the UDP data packet, each UDP data packet to the receiving end corresponding to the UDP data packet includes:

when the type of the UDP data packet is RTP or RTCP, modifying the packet head of the UDP data packet so that a receiving end of the UDP data packet can normally receive the UDP data packet, carrying out data packet verification and security socket protocol (SSL) encryption operation on the modified UDP data packet, and sending the RTP data packet which passes the verification and is encrypted to the receiving end corresponding to the UDP data packet;

the RTCP type data packets include a sending end report SR data packet, a receiving end report RR data packet, a feedback report FB data packet or a transmission ending BYE data packet.

Optionally, the method further comprises:

and updating the mapping relation among each UDP data packet, the sending end of the UDP data packet and the receiving end of the UDP data packet in real time.

In addition, the logic instructions in the memory 430 may be implemented in the form of software functional units and stored in a computer readable storage medium when the software functional units are sold or used as independent products. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Embodiments of the present application also provide a non-transitory computer readable storage medium, on which a computer program is stored, and the computer program is implemented by a processor to execute the methods provided by the above embodiments.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.