CN102255906B - Data transmission and receiving methods, equipment and systems - Google Patents

Abstract

The invention provides a data sending and receiving method, device and system. The sending method includes: the sender encapsulates the data to be sent and the virtual IP address of the sender as the load of the RTP message, and adds the header of the RTP message, which carries the type identification of the load; The network card sends the RTP message to the receiver through the RTP channel between the sender and the receiver; the receiver receives and parses the RTP message, and analyzes the load of the RTP message according to the type identifier of the load; if the receiver knows the load carries the virtual IP address of the sender, the data is sent to the virtual network card of the receiver, so that the virtual network card of the receiver can receive the data. The data sending and receiving method, device and system of the present invention realize the transfer of other types of data except voice data and video data without using other protocols during the SIP session.

Description

Data sending and receiving method, device and system

technical field

The present invention relates to network communication technology, in particular to a data sending and receiving method, device and system.

Background technique

Real-time Transport Protocol (RTP), as the technical basis of multimedia Internet Protocol (IP), has been widely used in streaming media systems, video conferencing and push-to-talk systems.

In the prior art, the communication parties who want to perform voice or video communication usually use the Session Initiation Protocol (Session Initiation Protocol, SIP) to establish a session between the two parties, and negotiate the address and port of the RTP media channel during the establishment of the SIP session . During the communication process, the two parties transmit multimedia information such as voice or video through the negotiated RTP media channel, so as to realize voice communication or video communication between the two communicating parties. But for the two sides of the communication, there are many other communication requirements, such as the transmission of shared documents, etc. At this time, it is necessary to establish a new channel to transfer files based on other protocols, such as the File Transfer Protocol (FTP), so that The communication parties also need to perform authentication and authentication processes again, resulting in waste of network resources and serious time-consuming.

Contents of the invention

In view of the above-mentioned defects, the present invention provides a data sending and receiving method, device and system, which are used to realize that in the process of SIP conversation, there is no need to establish a new communication channel based on other protocols to transmit data other than voice data and video data. other types of data.

According to an aspect of the present invention, a method for sending data is provided, including:

The sender encapsulates the data to be sent to the receiver and the virtual Internet Protocol IP address of the sender as the load of the real-time transport protocol RTP message, and adds the header of the RTP message before the load; wherein, The type identifier of the payload is carried in the header;

The sending party sends the RTP message to the receiving party through the RTP channel negotiated between the sending party and the receiving party in the process of establishing a session initiation protocol SIP call through its own virtual network card; so that the The receiver parses the header of the RTP message, and parses the payload according to the type identifier of the payload in the header, and if it is known through parsing that the payload carries the virtual IP address of the sender Then write the analyzed data into its own virtual network card to complete the receiving of the data.

According to another aspect of the present invention, a sending device is also provided, including:

An encapsulation module, configured to encapsulate the data to be sent to the receiving device and the virtual IP address of the sending device into the payload of the RTP message, and add the header of the RTP message before the load; wherein, the header carries have the type identification of the payload;

The sending module is used to send the RTP message to the receiving device through the RTP channel negotiated between the sending device and the receiving device during the process of establishing a SIP call through its own virtual network card; so that the receiving device Parsing the header of the RTP message, parsing the payload according to the type identifier of the payload in the header, and if it is known through parsing that the payload carries the virtual IP address of the sending device, pass The data obtained by parsing is written into its own virtual network card to complete the receiving of the data.

According to yet another aspect of the present invention, a receiving device is also provided, including:

The receiver parses the header of the RTP message received from the sender, and parses the load according to the type identifier of the payload in the header; wherein, the header carries the type identifier of the payload, and the The payload carries the sender's virtual IP address and data to be sent to the receiver;

If the receiver learns that the payload carries the sender's virtual IP address through analysis, it writes the data obtained through analysis into its own virtual network card to complete the data reception.

According to yet another aspect of the present invention, a data receiving method is also provided, including:

The RTP message parsing module parses the header of the RTP message received from the sending device, and analyzes the load according to the type identifier of the load in the header; wherein, the type of the load is carried in the header identification, the payload carries the virtual IP address of the sending device and data to be sent to the receiving device;

The writing module is configured to write the data obtained through parsing into its own virtual network card to complete the receiving of the data if it is known through parsing that the payload carries the virtual IP address of the sending device.

According to still another aspect of the present invention, a data transmission system is provided, including the sending device of the present invention and the receiving device of the present invention.

According to the data sending and receiving method, device and system of the present invention, for both communicating parties in an ongoing SIP session, if the sender has other types of data transmission other than voice/video, then identify the data in the field PT of the RTP message The load type identification corresponding to the type, and send its own virtual IP address together with the data to be sent as the load of the RTP message to the receiver through the previously negotiated RTP channel; if the receiver parses and knows that the load carries a virtual IP address, it will know Establish a virtual IP connection with the sender, and put the data carried in the payload to its own virtual network card. Therefore, the communication of other types of data other than video data or audio data is realized through the virtual IP connection of the two communicating parties, which avoids the need for the sender and the receiver to perform authentication and authentication again based on other protocols (such as FTP protocol) Waiting for the process to establish a new channel to realize the communication of non-voice/video type data, which saves network resources and can complete the communication quickly. Moreover, since the RTP message carries the virtual IP address uniquely corresponding to the sender, the receiver can directly determine the sender of the message by parsing the RTP message, realizing the transparency of the sender to the receiver. It avoids the problem that the receiving party cannot accurately know the IP address of the sending party when there is Network Address Translation (NAT) between the communicating parties.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. For those skilled in the art, other drawings can also be obtained according to these drawings without any creative effort.

FIG. 1 is a schematic flowchart of a data sending method according to Embodiment 1 of the present invention.

FIG. 2 is a schematic structural diagram of an RTP message in the data sending method shown in FIG. 1 .

FIG. 3 is a schematic structural diagram of the RTP header of the RTP packet shown in FIG. 2 .

FIG. 4 is a schematic structural diagram of a sending device according to Embodiment 2 of the present invention.

FIG. 5 is a schematic flowchart of a data receiving method according to Embodiment 3 of the present invention.

FIG. 6 is a schematic structural diagram of a receiving device according to Embodiment 4 of the present invention.

FIG. 7 is a system architecture diagram of a data transmission system according to Embodiment 5 of the present invention.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention.

Embodiment one

FIG. 1 is a schematic flowchart of a data sending method according to Embodiment 1 of the present invention. As shown in Figure 1, the data sending method includes the following steps:

Step S101, the sender encapsulates the data to be sent to the receiver and the virtual IP address of the sender as the payload of the RTP message, and adds the header of the RTP message before the payload; wherein the header carries the type identifier of the payload;

Step S102, the sending party sends the RTP message to the receiving party through the RTP channel negotiated between the sending party and the receiving party in the process of establishing a SIP call through its own virtual network card; so that the The receiver parses the header of the RTP message, parses the payload according to the type identifier of the payload in the header, and if it is known through parsing that the payload carries the virtual IP address of the sender, then Writing the analyzed data into its own virtual network card to complete the receiving of the data.

Wherein, the sender and the receiver are communication parties that have established a SIP session. The two parties negotiated the address and port of the RTP channel during the establishment of the SIP session. During the SIP session, the audio data or video data communicated between the two parties are encapsulated into RTP packets and communicated through the RTP channel.

FIG. 2 is a schematic structural diagram of an RTP message in the data sending method shown in FIG. 1 . As shown in Figure 2, an RTP message includes two parts: a message and a payload, wherein the header includes a physical Ethernet header, an IP header, a UDP header, and an RTP header, and the payload includes the virtual IP address of the sender and the data to be sent. More specifically, FIG. 3 is a schematic structural diagram of the RTP header of the RTP packet shown in FIG. 2 . As shown in Figure 3, the RTP header includes field V, field P, field X, field CC, field M, field PT, field Sequence Number, field timestamp, field SSRC identifier and field CSRC identifiers. Among them, the field CSRC identifiers only appears in the RTP message when the mixer is inserted, while the remaining fields appear in all RTP messages. The meaning of each field is explained in detail as follows:

Field V: version number, 2 bits, used to identify the RTP version;

Field P: padding flag, 1 bit, used to identify whether to set the padding bit;

Field X: extension identifier, 1 bit, used to identify whether to set the extension bit; if the extension bit is set, the fixed RTP header is followed by a header extension;

Field CC: Provide source (contribution source, CSRC) count, 4 bits, which includes the number of CSRC identifiers immediately after the fixed RTP header;

Field M: flag, 1 bit, the interpretation of the flag is defined by the setting, the purpose is to allow important events to be marked in the packet flow; the setting can define other flag bits or specify no flag bit by changing the number of bits;

Field PT: payload type (Payload Type, PT), 7 bits, used to identify the RTP payload format and determine its interpretation; set the static mapping of the specified payload type code to the payload format, such as including audio, video, image, text and html, etc. ; Other payload type codes can be dynamically defined through non-RTP channels; the default mapping for audio and video is indicated in the relevant settings; this field can support further expansion;

Field Sequence Number: serial number, 16 bits; the serial number increases with each RTP message, and is used by the receiver to detect the loss of the message and restore the message sequence; the serial number will be random at the beginning, so that the encrypted text attack more difficult;

Field timestamp: timestamp, 32 bits, used to reflect the sampling time of the first octet in the RTP message, the sampling time must be derived from a monotonically, linearly increasing clock to allow synchronization with jitter calculations;

Field SSRC identifier: synchronization source identifier, 32 bits, used to identify the synchronization source;

Field CSRC identifiers: CSRC list, 0 to 15 items, each 32 bits; the CSRC list indicates the source contained in the packet that acts on the payload. The identification number is given by the CC segment.

When the communication parties send audio data or video data through the RTP channel during the SIP session, they need to add information about the sender’s physical network card in the physical Ethernet header of the RTP message; add the receiver’s physical IP address in the IP header; Add the communication port negotiated during the establishment of the SIP session in the UDP header; identify the audio data or video data in the field PT in the RTP header; and use the audio data or video data to be sent as the load of the RTP message. If both parties are in a SIP session, one party (sender) has other types of data (such as documents or remote assistance) to send to the other party (receiver) except audio data or video data, then it is the same as the above-mentioned sending audio data or video data, there are the following differences in the encapsulation of the RTP message: for the header of the RTP message, the field PT in the RTP header identifies the payload type identifier corresponding to the type of data to be sent, and the payload type identifier is divided by Other types of identification other than audio data and video data, where the communication parties pre-agreed on the load type identification and the analysis method of the corresponding type of load; for the load of the RTP message, the sender sends the data to be sent together with its own virtual IP The address is used as the payload of the RTP packet; the header and payload of the RTP packet constitute a complete RTP packet. Wherein, the sender and the receiver are preset with respective virtual network cards and virtual IP addresses.

The sender sends the RTP message to the receiver through the RTP channel between the sender and the receiver through its own virtual network card. After receiving the RTP message, the receiver first parses the RTP message and reads the contents of each field in the header. When the receiver knows that the payload data carried by the RTP message is not the default audio data or video data through the payload type identifier in the field PT, the payload of the RTP packet is analyzed to detect whether the payload contains Virtual IP address. If the receiver reads the virtual IP address of the sender from the RTP message, it knows that a virtual IP connection has been established between the sender and the receiver, that is, the RTP message is sent out by the virtual network card of the sender. The receiver processes the data in the payload as the data sent by the sender of the virtual IP connection, that is, sends the data carried in the payload to its own virtual network card, that is, the virtual network card receives and processes the data according to the data type . So far, the transmission of the data between the virtual network card of the sender and the virtual network card of the receiver is realized.

According to the data sending method of the above-mentioned embodiment, for the communication parties in the ongoing SIP session, if the sender has other types of data transmission other than voice/video, then identify the payload type corresponding to the data type in the field PT of the RTP message identification, and send its own virtual IP address together with the data to be sent as the load of the RTP message to the receiver through the previously negotiated RTP channel; if the receiver parses and knows that the load carries a virtual IP address, then it knows Virtual IP connection, and put the data carried in the payload to its own virtual network card. Therefore, the communication of other types of data other than video data or audio data is realized through the virtual IP connection of the two communicating parties, which avoids the need for the sender and the receiver to perform authentication and authentication again based on other protocols (such as FTP protocol) Waiting for the process to establish a new channel to realize the communication of non-voice/video type data, which saves network resources and can complete the communication quickly. Moreover, since the RTP message carries the virtual IP address uniquely corresponding to the sender, the receiver can directly determine the sender of the message by parsing the RTP message, realizing the transparency of the sender to the receiver. It avoids the problem that the receiving party cannot accurately obtain the IP address of the sending party when there is NAT between the two communicating parties.

Further, in the data sending method of the above-mentioned embodiment, before the step of the sender taking the data to be sent to the receiver and the virtual IP address of the sender as the load of the RTP message, the sender further includes:

The sender establishes a virtual network card and sets a virtual IP address.

Further, in the data sending method of the above embodiment, the payload of the RTP message further includes a virtual Ethernet header used to identify the virtual network card of the sender.

According to the data sending method of the above-mentioned embodiment, since the payload of the RTP message carries a virtual Ethernet header used to identify the virtual network card of the sender, and the RTP message is sent out via the virtual network card, the receiver can directly know The network card that sends the message improves the transparency of the application.

Embodiment two

FIG. 4 is a schematic structural diagram of a sending device according to Embodiment 2 of the present invention. As shown in Figure 2, the sending device includes:

The encapsulation module 21 is used for encapsulating the data to be sent to the receiving device and the virtual IP address of the sending device as the load of the RTP message, and adding the header of the RTP message before the load; wherein, in the header Carrying the type identifier of the payload;

The sending module 22 is used to send the RTP message to the receiving device through the RTP channel negotiated between the sending device and the receiving device in the process of establishing a SIP call through its own virtual network card; so that the receiving device The device parses the header of the RTP message, parses the payload according to the type identifier of the payload in the header, and if it is known through parsing that the payload carries the virtual IP address of the sending device, then The data obtained through parsing is written into its own virtual network card to complete the receiving of the data.

The data transmission process performed by the sending device in the above embodiment is the same as the data transmission method described in Embodiment 1, so it will not be repeated here.

According to the sending device of the above-mentioned embodiment, for the communication parties in the ongoing SIP session, if the sending device has other types of data transmission other than voice/video, then identify the payload type identifier corresponding to the data type in the field PT of the RTP message , and send its own virtual IP address together with the data to be sent as the payload of the RTP message to the receiving device through the previously negotiated RTP channel; if the receiving device parses and knows that the payload carries a virtual IP address, it knows that it has established a virtual IP connection, and put the data carried in the payload to its own virtual network card. Therefore, the communication of other types of data other than video data or audio data can be realized through the virtual IP connection between the two communicating parties, avoiding the need for re-authentication and authentication between the sending device and the receiving device based on other protocols (such as FTP protocol) Waiting for the process to establish a new channel to realize the communication of non-voice/video type data, which saves network resources and can complete the communication quickly. Moreover, since the RTP message carries the virtual IP address uniquely corresponding to the sending device, the receiving device can directly determine the sending device of the message by parsing the RTP message, realizing the transparency of the sending device to the receiving device. This avoids the problem that the receiving device cannot accurately obtain the sender's IP address when there is NAT between the two communicating parties.

Further, the sending device in the above embodiment also includes:

The configuration module is used to establish a virtual network card and set a virtual IP address.

Further, in the sending device in the above embodiment, the encapsulation module is further configured to encapsulate the virtual Ethernet header used to identify the virtual network card of the sender in the payload of the RTP message.

According to the sending device in the above embodiment, since the payload of the RTP message carries the virtual Ethernet header used to identify the virtual network card of the sending device, and the RTP message is sent out via the virtual network card, the receiver can directly know the sending The network card of the message improves the transparency of the application.

Embodiment three

FIG. 5 is a schematic flowchart of a data receiving method according to Embodiment 3 of the present invention. As shown in Figure 5, the data receiving method includes:

Step S301, the receiver parses the header of the RTP message received from the sender, and parses the payload according to the type identifier of the payload in the header; wherein, the header carries the type identifier of the payload , the payload carries the virtual IP address of the sender and data to be sent to the receiver;

Step S302, if the receiver knows that the payload carries the virtual IP address of the sender through analysis, write the data obtained through analysis into its own virtual network card to complete the data reception.

According to the data receiving method of the above-mentioned embodiment, for the communication parties in the ongoing SIP session, if the sender has other types of data transmission other than voice/video, then the payload type corresponding to the data type is identified in the field PT of the RTP message identification, and send its own virtual IP address together with the data to be sent as the load of the RTP message to the receiver through the previously negotiated RTP channel; if the receiver parses and knows that the load carries a virtual IP address, then it knows Virtual IP connection, and put the data carried in the payload to its own virtual network card. Therefore, the communication of other types of data other than video data or audio data is realized through the virtual IP connection of the two communicating parties, which avoids the need for the sender and the receiver to perform authentication and authentication again based on other protocols (such as FTP protocol) Waiting for the process to establish a new channel to realize the communication of non-voice/video type data, which saves network resources and can complete the communication quickly. Moreover, since the RTP message carries the virtual IP address uniquely corresponding to the sender, the receiver can directly determine the sender of the message by parsing the RTP message, realizing the transparency of the sender to the receiver. It avoids the problem that the receiving party cannot accurately obtain the IP address of the sending party when there is NAT between the two communicating parties.

Further, in the data receiving method of the above-mentioned embodiment, if the receiver knows that the payload carries the virtual IP address of the sender through analysis, the receiver writes the data obtained through analysis into its own virtual IP address. The steps for the network card also include:

The receiver establishes a virtual network card and sets a virtual IP address.

Further, in the data receiving method of the above embodiment, the payload of the RTP message further includes a virtual Ethernet header used to identify the virtual network card of the sender.

According to the data receiving method of the above-mentioned embodiment, since the payload of the RTP message carries a virtual Ethernet header used to identify the virtual network card of the sender, and the RTP message is sent out via the virtual network card, the receiver can directly know The network card that sends the message improves the transparency of the application.

Embodiment four

FIG. 6 is a schematic structural diagram of a receiving device according to Embodiment 4 of the present invention. As shown in Figure 4, the receiving device includes:

The RTP message parsing module 41, parses the header of the RTP message received from the sending device, and parses the load according to the type identification of the load in the header; wherein, the header carries the content of the load Type identification, the payload carries the virtual IP address of the sending device and data to be sent to the receiving device;

The writing module 42 is configured to write the data obtained through parsing into its own virtual network card to complete the receiving of the data if it is known through parsing that the payload carries the virtual IP address of the sending device.

The data transmission process performed by the receiving device in the above embodiment is the same as the data transmission method in the above embodiment, so it will not be repeated here.

According to the receiving device of the above-mentioned embodiment, for the communication parties in the ongoing SIP session, if the sending device has other types of data transmission other than voice/video, then identify the payload type identifier corresponding to the data type in the field PT of the RTP message , and send its own virtual IP address together with the data to be sent as the payload of the RTP message to the receiving device through the previously negotiated RTP channel; if the receiving device parses and knows that the payload carries a virtual IP address, it will know the virtual IP connection, and put the data carried in the payload to its own virtual network card. Therefore, the communication of other types of data other than video data or audio data can be realized through the virtual IP connection between the two communicating parties, avoiding the need for re-authentication and authentication between the sending device and the receiving device based on other protocols (such as FTP protocol) Waiting for the process to establish a new channel to realize the communication of non-voice/video type data, which saves network resources and can complete the communication quickly. Moreover, since the RTP message carries the virtual IP address uniquely corresponding to the sending device, the receiving device can directly determine the sending device that sent the message by parsing the RTP message, realizing the transparency of the sending device to the receiving device , to avoid the problem that the receiving device cannot accurately obtain the IP address of the sending device when there is NAT between the two communicating parties.

Further, in the receiving device of the above embodiment, it also includes:

The configuration module is used to establish a virtual network card and set a virtual IP address.

Embodiment five

FIG. 7 is a system architecture diagram of a data transmission system according to Embodiment 5 of the present invention. As shown in Figure 7, the data transmission system includes the sending device 51 of the second embodiment and the receiving device 52 of the fourth embodiment,

According to the data transmission system of the above-mentioned embodiment, it is realized that the communication parties establishing the SIP session can communicate other types of data except video data or audio data during the SIP session, without the sending device and the receiving device based on other protocols (For example, the FTP protocol) re-perform authentication and authorization procedures to establish a new channel, which saves network resources and can quickly complete communication.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: it can still be Modifications are made to the technical solutions described in the foregoing embodiments, or equivalent replacements are made to some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims (12)

1. a data transmission method for uplink, is characterized in that, comprising:

Transmit leg is encapsulated as the virtual Internet protocol IP address of the data to recipient to be sent and described transmit leg the load of real time transport protocol RTP message, and before described load, adds the header of described RTP message; Wherein, in described header, carry the type identification of described load;

The RTP passage that described transmit leg is consulted by described transmit leg and described recipient described RTP message by the Microsoft Loopback Adapter of self in setting up the process of SIP SIP calling is sent to described recipient; So that described recipient resolve described RTP message header, according to the type identification of the described load in described header, described load is resolved, if and know that by parsing the virtual ip address that carries described transmit leg in described load knows that the virtual IP address of setting up with described transmit leg is connected, and by through resolving Microsoft Loopback Adapter that the described data that obtain write self to complete the reception of described data.

2. data transmission method for uplink according to claim 1, is characterized in that, described transmit leg also comprised before the step to recipient's data and the virtual ip address of described transmit leg as the load of RTP message to be sent:

Described transmit leg is set up Microsoft Loopback Adapter and virtual ip address is set.

3. data transmission method for uplink according to claim 1 and 2, is characterized in that, the load of described RTP message also comprises for identifying the virtual Ethernet header of the Microsoft Loopback Adapter of described transmit leg.

4. a transmitting apparatus, is characterized in that, comprising:

Package module for being encapsulated as the load of RTP message by be sent to the data of receiving equipment and the virtual ip address of transmitting apparatus, and adds the header of described RTP message before described load; Wherein, in described header, carry the type identification of described load;

Sending module, the RTP passage of described RTP message being consulted in the process of setting up SIP calling by described transmitting apparatus and described receiving equipment for the Microsoft Loopback Adapter by self is sent to described receiving equipment; So that described receiving equipment resolve described RTP message header, according to the type identification of the described load in described header, described load is resolved, if and know that by parsing the virtual ip address that carries described transmitting apparatus in described load knows that the virtual IP address of setting up with described transmitting apparatus is connected, and by through resolving Microsoft Loopback Adapter that the described data that obtain write self to complete the reception of described data.

5. transmitting apparatus according to claim 4, is characterized in that, also comprises:

Configuration module, for setting up Microsoft Loopback Adapter and virtual ip address being set.

6. according to the transmitting apparatus described in claim 4 or 5, it is characterized in that, described package module is also for being encapsulated in the load of RTP message for identifying the virtual Ethernet header of the Microsoft Loopback Adapter of transmitting apparatus.

7. a data receive method, is characterized in that, comprising:

Recipient resolves the header of the RTP message receiving from transmit leg, according to the type identification of the load in described header, described load is resolved; Wherein, in described header, carry the type identification of described load, in described load, carry virtual ip address and the data to recipient to be sent of described transmit leg;

If described recipient knows that by parsing the virtual ip address that carries described transmit leg in described load knows that the virtual IP address of setting up with described transmit leg is connected, and by through resolving Microsoft Loopback Adapter that the described data that obtain write self to complete the reception of described data.

8. data receive method according to claim 7, it is characterized in that, if the virtual ip address that carries described transmit leg in described recipient is known described load by parsing also comprised by write self the step of Microsoft Loopback Adapter through resolving the described data that obtain before:

Described recipient sets up Microsoft Loopback Adapter and virtual ip address is set.

9. according to the data receive method described in claim 7 or 8, it is characterized in that, the load of described RTP message also comprises for identifying the virtual Ethernet header of the Microsoft Loopback Adapter of described transmit leg.

10. a receiving equipment, is characterized in that, comprising:

RTP packet parsing module, resolves from the header of the RTP message of transmitting apparatus reception, according to the type identification of the load in described header, described load is resolved; Wherein, in described header, carry the type identification of described load, in described load, carry virtual ip address and the data to receiving equipment to be sent of described transmitting apparatus;

Writing module, if for knowing that by parsings the virtual ip address that described load carries described transmitting apparatus knows that the virtual IP address of setting up with described transmitting apparatus is connected, and the Microsoft Loopback Adapter that the described data that obtain through parsing are write to self is to complete the reception of described data.

11. receiving equipments according to claim 10, is characterized in that, also comprise:

Configuration module, for setting up Microsoft Loopback Adapter and virtual ip address being set.

12. 1 kinds of data communication systems, is characterized in that, comprise transmitting apparatus and the receiving equipment as described in claim 10 or 11 as described in as arbitrary in claim 4 to 6.