Relay system, and relay device on transmission side and relay device on reception side in relay system

Abstract

To enable communication regardless of limit on the number of sessions when performing communication of information of a first protocol that requires a connection by handshake every transmission.SOLUTION: When a relay device on a transmission side receives a request to send a call with a predetermined specific destination as a reception side, the relay device on the transmission side transmits a call-sending request including information corresponding to the specific destination to the relay device on the reception side in a first protocol. When the received call-sending request of the first protocol contains information corresponding to the specific destination, the relay device on the reception side returns an error response to the relay device on the transmission side. The relay device on the transmission side which has received an error response transmits another call-sending request in a second protocol that does not require connection. In data communication after a communication path is created, the relay devices on the transmission side and reception side exchange information with each other by performing encapsulation adaptable to the second protocol on packets adaptable to the first protocol.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present invention relates to a relay system, a relay device on the sending side of the relay system, and a relay device on the receiving side. [Background technology]

[0002] One of the communication services offered by some telephone companies is the "Data Connect (registered trademark) service," a bandwidth-guaranteed data communication service. When using the Data Connect service, a secure communication path is established between the other party upon a connection request using a telephone number, and in addition to making voice calls during the connection, various data such as image data and text data can be sent and received. Therefore, while making a voice call, it is possible to confirm images, text, etc. on both sides, and data can be sent and received stably and with high confidentiality (see Patent Document 1 (JP 2021-57718 A)).

[0003] Fig. 23 is a diagram showing an example of a sequence of generating a communication path between a sending side and a receiving side and data communication during a data connect service. In the example of Fig. 23, a WAN (World Area Network) side of a gateway (shown as GW in the figure) as an example of a relay device on the sending side and the receiving side is connected to a communication network such as the Internet, and the sending side device and the receiving side device are connected to the gateway as an example of a relay device on the sending side and the receiving side by a LAN (Local Area Network).

[0004] In the example of Fig. 23, when a call is made from a calling device to a receiving device, the calling gateway GWs sends out a SIP (Session Initiation Protocol) call request "INVITE". When the SIP server receives this "INVITE", it returns "100 Trying" to the calling gateway GWs and transfers the "INVITE" to the receiving gateway GWr. When the receiving gateway GWr receives the "INVITE", it returns "100 Trying" to the SIP server and receives the call from the receiving device.

[0005] When the receiving device responds to this incoming call, the receiving gateway GWr sends a "200 OK" to the SIP server. The SIP server sends a "200 OK" to the sending gateway GWs. Through the above sequence, a communication path (SIP session) is created between the sending device and the receiving device. With the Data Connect service, data communication using TCP (Transmission Control Protocol) packets becomes possible through this SIP session. TCP is a protocol that requires a connection via a handshake each time a call is made.

[0006] When a browser access operation is performed from the sending device using the URL (Uniform Resource Locator) of the receiving device, the sending device sends out a "TCP-syn" TCP packet, which is a browser access request of HTTP (Hypertext Transfer Protocol). This "TCP-syn" TCP packet is sent to a NAPT (Network Address and Port Translation) functional unit via the sending device's gateway GWs. The NAPT functional unit converts the global IP address into a private address (including the port number). The NAPT functional unit then sends the address-converted "TCP-syn" TCP packet to the receiving device via the receiving device's gateway GWr.

[0007] The receiving device that receives the "TCP-syn" TCP packet sends the response "TCP-syn,ack" TCP packet to the NAPT function unit via the receiving gateway GWr. The NAPT function unit includes the private address (including the port number) of the sending device in the received "TCP-syn,ack" TCP packet and sends it to the sending device via the sending gateway GWs.

[0008] The sending device that receives the "TCP-syn,ack" TCP packet sends the response "TCP-ack" TCP packet to the NAPT function unit via the sending gateway GWs. The NAPT function unit sends the received "TCP-ack" TCP packet to the receiving device via the receiving gateway GWr.

[0009] In this manner, a TCP connection sequence is performed, and a communication path based on a SIP session is created between the calling device and the receiving device, and data communication using TCP packets becomes possible over this created communication path. [Prior art documents] [Patent documents]

[0010] [Patent Document 1] Patent Publication No. 2021-57718 Summary of the Invention [Problem to be solved by the invention]

[0011] In the Data Connect service, the number of TCP packet data streams (media streams) that can be sent during one SIP session is limited. In other words, the number of sessions for data communication via TCP connections that can be sent during one SIP session is limited.

[0012] However, depending on the purpose of data communication, there are cases where a data stream of many TCP packets is required. For example, when a sending PC is trying to provide remote maintenance service for a device in a remote location via a network, the number of sessions by the TCP connection will quickly exceed the limit due to the fact that frames are divided in HTTP (Hypertext Transfer Protocol) and the request for a web icon that uses images.

[0013] For example, if five "TCP-syn" TCP packets, which are HTTP browser access requests, are sent from the originating device as shown in Figure 24, the fifth TCP access request, "TCP-syn" TCP packet, will be discarded by the NAPT function unit, and no further sessions for data communication via TCP connections can be generated.

[0014] SUMMARY OF THE PRESENT EMBODIMENT An object of the present invention is to provide a relay system that can solve the above problems. [Means for solving the problem]

[0015] In order to solve the above problem, the invention of claim 1 is as follows: A relay system for communicating information of a first protocol that requires a connection by a handshake for each transmission through a communication path generated based on a transmission request, comprising: The relay device on the sending side a means for transmitting, when receiving a request for transmission to a predetermined specific destination as a receiving side, a transmission request including information corresponding to the specific destination to a relay device on the receiving side in accordance with the first protocol; means for transmitting a second call request using a second protocol that does not require the connection when an error response is received from the relay device on the receiving side in response to the call request; a means for performing encapsulation between the receiving relay device and the first protocol-compliant packet so as to make the packet compatible with the second protocol, in data communication through the communication path generated based on the second transmission request; Equipped with The receiving relay device means for transmitting the error response to the relay device on the calling side when the received call origination request includes information corresponding to the specific called party; means for performing a process for generating the communication path when the second transmission request of the second protocol is received from the relay device on the transmission side; a means for performing encapsulation of a packet conforming to the first protocol so as to conform to the second protocol between the relay device on the transmitting side and the relay device on the transmitting side in data communication through the communication path generated based on the second transmission request; The present invention provides a relay system comprising:

[0016] In the relay system of the invention of claim 1 having the above-mentioned configuration, when a relay device on the transmitting side receives a request to make a call to a predetermined specific destination as the receiving side, the relay device on the receiving side transmits the call request including information corresponding to the specific destination to the relay device on the receiving side using a first protocol that requires a connection by handshake each time a call is made.

[0017] When the receiving relay device receives a call origination request, if the call origination request contains information corresponding to a specific destination, the receiving relay device transmits an error response to the calling relay device.

[0018] When the relay device on the sending side receives this error response, it sends another call request to connect the communication path using the second protocol. When a response arrives from the relay device on the receiving side to this second call request, a communication path based on the call request is created.

[0019] After this communication path is created, data communication packets are exchanged between the relay device on the sending side and the relay device on the receiving side by encapsulating packets compatible with the first protocol to make them compatible with the second protocol. This exchange includes packets for sequences that exchange packets for data communication sessions, but since it is performed with packets compatible with the second protocol that do not require a connection, there is no restriction on the number of sessions for data communication by a connection, as occurs when packets of the first protocol are exchanged.

[0020] In the relay system according to the invention of claim 1 having the above-mentioned configuration, if the origination request does not include information corresponding to a specific destination, the receiving relay device returns a response to the origination request to the origination relay device, thereby generating a communication path based on the origination request, and enabling data communication using packets compatible with the first protocol.

[0021] In addition, even if the originating relay device that has made an originating request including the first information receives a response to the originating request from the receiving relay device without receiving an error response (i.e., if the receiving relay device does not have the functions of the receiving relay device in the invention of claim 1), a communication path based on the originating request is generated between the originating relay device and the receiving relay device, making data communication possible using packets compatible with the first protocol. Effect of the Invention

[0022] According to the present invention, it is possible to perform data communication using a communication path created based on a call origination request, without being subject to restrictions on the number of sessions for data communication via a connection. [Brief description of the drawings]

[0023] [Figure 1] 1 is a diagram showing an example of the overall configuration of an embodiment of a relay system according to the present invention; [Diagram 2]1 is a block diagram showing an example of a configuration of an embodiment of a relay device in an embodiment of a relay system according to the present invention; [Diagram 3] 3 is a diagram for explaining the contents stored in a storage unit in the embodiment of the relay device in FIG. 2; [Figure 4] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a sending side in the embodiment of the relay system according to the present invention. [Diagram 5] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a sending side in the embodiment of the relay system according to the present invention. [Figure 6] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a sending side in the embodiment of the relay system according to the present invention. [Figure 7] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a sending side in the embodiment of the relay system according to the present invention. [Figure 8] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a receiving side in the embodiment of the relay system according to the present invention. [Figure 9] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a receiving side in the embodiment of the relay system according to the present invention. [Figure 10] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a receiving side in the embodiment of the relay system according to the present invention. [Figure 11] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a receiving side in the embodiment of the relay system according to the present invention. [Figure 12] FIG. 13 is a diagram showing a part of a flowchart for explaining the operation of an embodiment of a relay device on a receiving side in the embodiment of the relay system according to the present invention. [Figure 13]FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 14] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 15] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 16] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 17] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 18] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 19] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 20] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 21] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Figure 22] FIG. 11 is a sequence diagram for explaining a part of an example of a sequence for data communication in the embodiment of the relay system according to the present invention. [Diagram 23] FIG. 11 is a sequence diagram for explaining an example of a sequence for data communication in a conventional relay system. [Figure 24] FIG. 11 is a sequence diagram for explaining a problem in an example of a sequence for data communication in a conventional relay system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] Hereinafter, an embodiment of a relay system according to the present invention will be described with reference to the drawings.

[0025] [Overview of the configuration of an embodiment of a relay system] Fig. 1 is a block diagram showing an outline of the configuration of a communication system including an embodiment of a relay system according to the present invention. In the communication system of this example, a gateway 1, which is an example of a relay device on the sending side in an example of a sequence described later, and a gateway 2, which is an example of a relay device on the receiving side, are connected to a communication network 3, which is, for example, the Internet. In this embodiment, the communication network 3 includes a portion that performs a data connect service, as shown in Fig. 1.

[0026] One or more communication function equipped devices 4 are connected to the gateway 1 via a LAN. Similarly, one or more communication function equipped devices 5 are connected to the gateway 2 via a LAN. Also provided are a SIP server 6 and a NAPT function unit 7 for performing address resolution and relay processing for the data connect service. The communication function equipped devices 4 and 5 may be any devices equipped with a communication function, such as a telephone terminal or a personal computer.

[0027] In the communication system of this example, as described later, one of the communication function equipped devices 4 is a personal computer (abbreviated as PC) 4P, and this PC 4P is configured to perform remote maintenance service for the receiving device. In this example, the device that is the target of the remote maintenance service is one example of a predetermined specific counterpart device. In this embodiment, the device that is the target of the remote maintenance service includes not only the receiving communication function equipped device 5 but also the receiving gateway 2.

[0028] 1, one of the communication function-equipped devices 5 on the receiving side is a WEB server 5S, and this WEB server 5S is also an example of a device of a specific predetermined destination. It goes without saying that the example of the specific predetermined destination is not limited to the example in this embodiment.

[0029] [Outline of an embodiment of a relay system] In this embodiment, when gateway 1, an example of a relay device on the calling side, receives a communication request from personal computer 4P, it sends a SIP call request "INVITE" to the WAN side using TCP, an example of a first protocol that requires a connection by handshake each time a call is made.

[0030] Prior to sending this call request "INVITE", in this embodiment, the gateway 1 judges whether the communication request received from the personal computer 4P is a communication request to a predetermined specific destination. In this embodiment, whether the communication request is to a predetermined specific destination is judged by whether the communication request is a remote maintenance communication request for the gateway 2, which is an example of a relay device on the receiving side, or a browser access communication request for the WEB server 5S connected to the gateway 2 via a LAN.

[0031] When the gateway 1 on the calling side judges that the communication request received from the personal computer 4P is a communication request to a predetermined specific destination, it transmits the outgoing request "INVITE" including information for indicating that the communication request is to a predetermined specific destination (information corresponding to the specific destination). In this embodiment, as an example of information corresponding to the specific destination, a unique format name, as described below, which is predetermined to correspond to the specific destination, is included in the "media format" in the body part of the packet of the outgoing request "INVITE".

[0032] In this embodiment, when the receiving gateway 2 receives the call origination request "INVITE" from the gateway 1, it determines whether the call origination request "INVITE" contains information corresponding to a specific destination, and if not, it causes the call to arrive at the communication function-equipped device 5 that is the destination of the communication request, and after it is certain that it has received a response from the communication function-equipped device 5, it returns response information to the calling side.

[0033] In this embodiment, when the gateway 2 determines that the "media format" of the packet (TCP packet) of the call request "INVITE" is included and that the packet contains information corresponding to a specific destination, the gateway 2 returns an error response to the caller's gateway 1. In this case, in this embodiment, information for urging the caller to switch to a protocol other than TCP is added to the error response. In this example, a "488 error response" is used as the error response, and a warning code (Warning-Code: 304) is added as information for urging the caller to switch to a protocol other than TCP, and the response is returned to the caller's gateway 1.

[0034] Upon receiving this error response, Gateway 1 will, based on the "488 error response" with the warning code, resend an "INVITE" call request including information corresponding to the specific destination using UDP (User Datagram Protocol), an example of a second protocol that eliminates the need for a handshake connection each time a call is made.

[0035] The gateway 2, which receives the second transmission request "INVITE" by UDP packet communication, returns a response "200 OK" to create a communication path to the transmitting gateway 1. Then, when the transmitting gateway 1 receives this response "200 OK", a communication path is created between the transmitting communication function equipped device 4 (personal computer 4P) and the gateway 2 via the gateway 1.

[0036] In this embodiment, when a "TCP-syn" TCP packet is sent from the sending side communication function equipped device 4 (personal computer 4P) as a request to send data communication, for example a browser access request, the sending side gateway 1 performs UDP encapsulation processing on the TCP packet and transmits it as a UDP packet to the receiving side gateway 2.

[0037] Gateway 2 on the receiving side, which receives this UDP packet, removes the UDP encapsulation and restores the TCP packet "TCP-syn." Gateway 2 then generates a TCP packet "TCP-syn,ack" in response to the received "TCP-syn," encapsulates the generated TCP packet in UDP, and sends it to Gateway 1 on the sending side as a UDP packet.

[0038] Gateway 1 on the sending side receives this UDP packet and removes the UDP encapsulation to restore the TCP packet's "TCP-syn,ack." Gateway 1 then sends the restored TCP packet's "TCP-syn,ack" to PC 4P via the LAN. PC 4P then sends a TCP packet of "TCP-ack" in response to the "TCP-syn,ack," so Gateway 1 UDP encapsulates the "TCP-ack" of the received TCP packet and sends it as a UDP packet to Gateway 2 on the receiving side.

[0039] When gateway 2 receives this UDP packet, it removes the UDP encapsulation and restores the "TCP-ack" of the TCP packet.

[0040] With the above sequence, Gateway 1 on the sending side and Gateway 2 on the receiving side consider the connection by TCP handshake to be complete, and proceed with subsequent data communication. In this data communication as well, Gateway 1 on the sending side and Gateway 2 on the receiving side perform UDP encapsulation processing on the generated TCP packets, and data communication is exchanged between Gateway 1 and Gateway 2 by UDP packets.

[0041] As described above, in this embodiment, after a call path is generated by a SIP session, information is exchanged between the gateway 1 on the calling side and the gateway 2 on the receiving side by UDP encapsulating TCP packets, and therefore address resolution processing is not performed in the NAPT function unit 7 due to the handshake connection using TCP packets.

[0042] Therefore, even if multiple different browser access requests occur after a speech path is generated by a SIP session, the NAPT function unit 7 does not treat them as different sessions, so data communication is possible regardless of the limit on the number of sessions as described at the beginning.

[0043] [Gateway 1, 2 configuration example] In this example, the gateways 1 and 2 are configured to have both the essential functions of the embodiment of the relay device on the sending side according to this invention and the essential functions of the embodiment of the relay device on the receiving side, and are configured identically. Figure 2 is a block diagram showing an example of the configuration of the gateways 1 and 2.

[0044] In addition, gateway 1 may be configured to have the essential functions of the embodiment of the transmitting side relay device of this invention, but not have the essential functions of the embodiment of the receiving side relay device of this invention, and gateway 2 may be configured to have the essential functions of the embodiment of the receiving side relay device of this invention, but not have the essential functions of the embodiment of the receiving side relay device of this invention.

[0045] 2, in this embodiment, the gateways 1 and 2 are configured by connecting interfaces 102 and 103, a transmission processing unit 104, a reception processing unit 105, a SIP sequence processing unit 106, a specific destination determination unit 107, a data communication processing unit 108, a UDP encapsulation processing unit 109, a UDP decapsulation unit 110, and a LAN subordinate management unit 111 to a control unit 100 configured as a computer via a system bus 101. The interface 102 is connected to a communication network 3. The interface 103 is connected to a LAN.

[0046] The transmission processing unit 104 sends outgoing packets to the WAN side via the interface 102, and also sends received packets and predetermined information to the communication function equipped device 4 connected to the LAN via the interface 103.

[0047] The reception processing unit 105 performs a predetermined process on the received packet received through the interface 102 or the interface 103 under the control of the control unit 100 , and outputs the processed packet to a predetermined processing unit connected to the system bus 101 .

[0048] The SIP sequence processing unit 106 executes the calling side processing and the receiving side processing in the SIP sequence for generating a communication path under the control of the control unit 100. In this embodiment, when a communication request to a predetermined specific destination is received, the SIP sequence processing unit 106 executes the above-mentioned unusual processing as the calling side processing under the control of the control unit 100. Also, the SIP sequence processing unit 106 executes the above-mentioned unusual processing as the receiving side processing under the control of the control unit 100 when a communication request to a specific destination is received.

[0049] A specific destination information storage unit 112 is connected to the specific destination determination unit 107. In this embodiment, the specific destination information storage unit 112 stores information as shown in Fig. 3. That is, the specific destination information storage unit 112 stores table information configured by associating, as information on one to a plurality of specific destinations, operation information of a communication request, information on a format name to be inserted into "media format" in the body part of a TCP packet as an example of information corresponding to a specific destination, and IPv6 address information and IPv4 address information of the specific destination. The IPv4 address is an address on the LAN of the specific destination.

[0050] In the example of FIG. 3, the operation information of the communication request includes, as described above, information on remote maintenance operation for maintaining the receiving gateway 2, and information on operation of an access request to the WEB server 5S.

[0051] As shown in Figure 3, as the format name to be included as the "media format" information in the body section of the TCP packet, "saxa.gw-remote-access" is stored for information on remote maintenance operations, and "saxa.gw-web-access" is stored for information on operations of access requests to the WEB server 5S.

[0052] As shown in FIG. 3, as the IPv6 address and IPv4 address, the address of the gateway 2 is stored for information on remote maintenance operations, and the address of the WEB server 5S is stored for information on operations of an access request to the WEB server 5S.

[0053] 3 is stored as information to be sent to the gateway 1 when the remote maintenance operation is performed by PC4P in this example. The specific destination determination unit 107 checks whether the remote maintenance operation information stored in the specific destination information storage unit 112 matches the information received from PC4P, thereby determining whether a communication request for remote maintenance operation has been made by PC4P, that is, whether a call request to a specific destination has been received.

[0054] 3, the information on the access operation to the WEB server 5S is stored as information sent to the gateway 1 when an access operation to the WEB server 5S is performed by PC4P. In this example, a specific URL, for example, "http: / / saxa.gw-remote-access", is stored as the information. The specific destination determination unit 107 of the gateway 1 checks whether the URL stored in the specific destination information storage unit 112 matches the URL received from PC4P, thereby determining whether an access operation to the WEB server 5S is performed by PC4P, that is, whether a call request to a specific destination is received.

[0055] Then, when specific destination determination unit 107 determines that it has received a call request to a specific destination, it reads out format name information and an IPv6 address corresponding to the determined operation information from specific destination information storage unit 112, and passes them to SIP sequence processing unit 106. SIP sequence processing unit 106 includes the received format name information as "media format" information in the body part of the TCP packet of the call request "INVITE", and transmits the call request "INVITE" to the receiving side.

[0056] Then, the SIP sequence processing unit 106 waits for a response from the receiving side, and when a normal response of "200 OK" is received from the receiving side, it performs the calling side processing of the sequence as described in Figure 23 to generate a communication path.

[0057] Furthermore, when the SIP sequence processing unit 106 receives the above-mentioned "488 error response" from the receiving side, the SIP sequence processing unit 106 determines that what the receiving side is requesting is a switch in media protocol (protocol type) based on the warning code "Warning-Code: 304" included in the "488 error response", and sends another call request "INVITE" via UDP.

[0058] Then, when the SIP sequence processing unit 106 receives a normal response "200 OK" for creating a communication path from the receiving side in response to this second call request "INVITE", the SIP sequence processing unit 106 performs processing for creating a communication path. Then, the SIP sequence processing unit 106 notifies each of the transmission processing unit 104, the data communication processing unit 108, the UDP encapsulating processing unit 109, and the UDP decapsulating unit 110 that a communication path has been created by the second call request "INVITE" by UDP packet communication.

[0059] The above is a description of the processing operations on the calling side in specific destination determination unit 107 and SIP sequence processing unit 106. Next, a processing operation on the receiving side will be described.

[0060] When the SIP sequence processing unit 106 receives a TCP packet of an outgoing call request "INVITE", it requests the specific destination determination unit 107 to determine whether the outgoing call request "INVITE" is for a specific destination. The specific destination determination unit 107 determines whether the "media format" information in the body part of the TCP packet of the outgoing call request "INVITE" contains information of a format name stored in the specific destination information storage unit 112, and returns the determination result to the SIP sequence processing unit 106.

[0061] If the judgment result from the specific destination judgment unit 107 is that the "media format" information in the body part of the TCP packet of the outgoing call request "INVITE" does not include information on the format name stored in the specific destination information memory unit 112, the SIP sequence processing unit 106 performs the receiving side processing of the sequence as described in Figure 23 to generate a communication path.

[0062] Then, if the judgment result from the specific destination judgment unit 107 is that the "media format" information in the body part of the TCP packet of the outgoing call request "INVITE" contains information of a format name stored in the specific destination information memory unit 112, the SIP sequence processing unit 106 returns a "488 error response" with a warning code "Warning-Code:304" to the calling side.

[0063] Then, when the SIP sequence processing unit 106 receives a second call request "INVITE" by UDP packet communication from the calling side that received the "488 error response" with the warning code "Warning-Code:304", it returns a response "200 OK" for creating a communication path to the calling side and performs processing to create a communication path. Then, the SIP sequence processing unit 106 notifies the reception processing unit 105, data communication processing unit 108, UDP encapsulation processing unit 109, and UDP decapsulation unit 110 that a communication path has been created by the second call request "INVITE" by UDP packet communication.

[0064] The data communication processor 108 generates TCP packets to be exchanged in data communication after a communication path is generated by the SIP sequence. In this case, the data communication processor 108 also performs processing to generate TCP packets to be transmitted in response to TCP packets received from the receiving side.

[0065] The UDP encapsulation processing unit 109 performs UDP encapsulation processing on the TCP packets generated by the data communication processing unit 108. The UDP decapsulation unit 110 decapsulates the UDP packets sent from the sending side to restore the TCP packets.

[0066] In this case, if there is no notification from the SIP sequence processing unit 106 that a communication path has been created by a second transmission request "INVITE" by UDP packet communication, the following process is performed. That is, when the data communication processing unit 108 creates a TCP packet for data communication, it sends the TCP packet directly to the communication network 3 on the WAN side through the transmission processing unit 104 and the interface 102. Also, when the reception processing unit 105 receives a TCP packet from the WAN side through the interface 102, it transfers the TCP packet to the data communication processing unit 108. The data communication processing unit 108 analyzes the received TCP packet, performs a process of creating a TCP packet to be sent, and when it determines that the connection for data communication is complete, it performs a process of data communication by the TCP packet.

[0067] Also, when the SIP sequence processing unit 106 notifies the reception unit 105 that a communication path has been created by a second transmission request "INVITE" by UDP packet communication, the following process is performed. That is, when the data communication processing unit 108 generates a TCP packet for data communication, it transfers the TCP packet to the UDP encapsulation processing unit 109. The UDP encapsulation processing unit 109 performs UDP encapsulation processing on the received TCP packet and sends it to the transmission processing unit 104. The transmission processing unit 104 sends the UDP packet generated by UDP encapsulating the TCP packet to the communication network 3 on the WAN side through the interface 102. Also, when the reception processing unit 105 receives a UDP packet from the WAN side through the interface 102, it transfers the UDP packet to the UDP decapsulation unit 110. The UDP decapsulation unit 110 performs UDP decapsulation processing on the received UDP packet to restore the TCP packet, and transfers the restored TCP packet to the data communication processing unit 108. The data communications processing unit 108 analyzes the received TCP packets, performs processing to generate TCP packets to be sent, and when it determines that the data communications connection has been completed, performs processing for data communications using the TCP packets.

[0068] Then, when a notification is received from the SIP sequence processing unit 106 that a communication path has been created by a second call request "INVITE" using UDP packet communication, in the data communication after the data communication session has been established, data communication is performed using TCP packets accompanied by UDP encapsulation processing in the UDP encapsulation processing unit 109 and UDP decapsulation processing in the UDP decapsulation unit 110.

[0069] In this embodiment, when the sending gateway is requesting communication with a specific destination, the sending gateway performs the operation of the embodiment described above by inserting format name information corresponding to the specific destination as "media format" information in the body section of the TCP packet sending request "INVITE." However, if the receiving gateway does not have the functionality of this embodiment, the above-mentioned processing is not performed.

[0070] However, according to this embodiment, if the receiving gateway does not have the function of this embodiment, it does not return an error response as described above to the TCP packet sending request "INVITE" that includes information corresponding to a specific destination, but returns a normal response "200 OK" to the sending relay device, and a communication path is created in the same way as in the case shown in Fig. 23. Therefore, communication is not disabled, and data communication by the same Data Connect service as in the past described in Fig. 23 is possible.

[0071] Similarly, if the receiving side has the functionality of this embodiment but the gateway on the sending side does not have the functionality of this embodiment, a communication path is generated in the same manner as in the case shown in Figure 23, and data communication is possible using the same Data Connect service as in the conventional manner described in Figure 23.

[0072] In addition, the processing of each of the parts shown in Figure 2, namely the transmission processing unit 104, the reception processing unit 105, the SIP sequence processing unit 106, the specific destination determination unit 107, the data communication processing unit 108, the UDP encapsulation processing unit 109, the UDP decapsulation unit 110, and the LAN management unit 111, can also be configured as software functional means by the computer constituting the control unit 100 executing each program.

[0073] [Example of operation of the embodiment of the relay device on the sending side] 4 to 7 are flowcharts for explaining an example of the operation of the gateway 1 at the time of transmission as an example of an embodiment of a relay device on the transmission side. In the following Figs. 4 to 7, the processing of each of the transmission processing unit 104, reception processing unit 105, SIP sequence processing unit 106, specific destination determination unit 107, data communication processing unit 108, UDP encapsulation processing unit 109, UDP decapsulation unit 110, and LAN management unit 111 will be explained as an example in which the processing of each unit is configured as software functional means executed by a program by a computer constituting the control unit 100. Therefore, in the following explanation, the processing of each step of the flowcharts in Figs. 4 to 7 will be explained as being executed by the control unit 100.

[0074] As shown in FIG. 4, the control unit 100 determines whether or not a call request has been received from the LAN side through the interface 103 (step S1), and if it determines that a call request has not been received, performs other processing (step S2), and then returns to step S1.

[0075] When it is determined in step S1 that a call request has been received, the control unit 100 refers to the information stored in the specific recipient information storage unit 112 to determine whether the received call request is addressed to a specific recipient (step S3), and when it is determined that the call request is not addressed to a specific recipient, it executes a processing routine for normal calls.

[0076] Furthermore, when it is determined in step S3 that the received transmission request is for a specific recipient, the control unit 100 identifies the specific recipient based on the information stored in the specific recipient information storage unit 112, and reads out information corresponding to the specific recipient, in this example, format name information, from the specific recipient information storage unit 112. The control unit 100 then inserts the read format name information into "media format" in the body part of the TCP packet of the transmission request "INVITE", and sends the TCP packet of the transmission request "INVITE" to the receiving side via the interface 102 (step S4).

[0077] Next, the control unit 100 determines whether or not a "488 error response" has been received from the receiving side through the interface 102 (step S5). If it is determined in step S5 that a "488 error response" has not been received, the control unit 100 determines whether or not a "200 OK" has been received from the receiving side (step S6), and if it is determined that a "200 OK" has not been received, the process returns to step S5.

[0078] If it is determined in step S6 that "200 OK" has been received, the control unit 100 creates a communication path with the receiving side (step S7) and sends the URL of the access destination for data communication to the sending side for presentation (step S8). The control unit 100 then determines whether or not "TCP-syn" has been received from the LAN side via the interface 103 by a TCP packet for browser access (step S9), and if it determines that it has not been received, waits for its reception. If the control unit 100 determines in step S9 that "TCP-syn" has been received, it transmits the TCP packet of the received "TCP-syn" to the access destination (step S11 in FIG. 5).

[0079] Next, the control unit 100 determines whether or not a TCP packet of "TCP-syn,ack" in response to "TCP-syn" has been received from the receiving side through the interface 102 (step S12), and if not, returns to step S12 and waits for its reception. If it is determined in step S12 that a TCP packet of "TCP-syn,ack" in response to "TCP-syn" has been received, the control unit 100 sends the TCP packet of the response "TCP-syn,ack" to the sending side through the interface 103.

[0080] Then, the control unit 100 waits for reception of a TCP packet of "TCP-ack" sent from the calling side through the interface 103 (step S14), and when reception of the TCP packet of "TCP-ack" through the interface 103 is confirmed, the control unit 100 sends the TCP packet of "TCP-ack" to the access destination (step S15). Then, the control unit 100 creates a data communication path (step S16) and executes data communication by the TCP packet (step S17).

[0081] Next, the control unit 100 determines whether an event to end communication has occurred (step S18), and if it determines that an event to end communication has not occurred, it determines whether "TCP-syn" by a TCP packet of another browser access has been received through the interface 103 (step S19), and if it determines that it has not been received, it returns the process to step S17. Also, if it determines in step S19 that "TCP-syn" by a TCP packet of another browser access has been received through the interface 103, it returns the process to step S11, and the processes from step S11 onwards are repeated.

[0082] Then, if it is determined in step S18 that an event that requires the termination of communication has occurred, a process is performed to disconnect the communication path created in step S7 (step S20), and this processing routine is terminated.

[0083] Also, when it is determined in step S5 that a "488 error response" has been received, the control unit 100 determines that the receiving side has prompted a change to a protocol other than TCP due to the warning code "Warning-Code: 304" accompanying the "488 error response". Then, the control unit 100 resends to the receiving side a call request "INVITE" by UDP packet communication in which the "media protocol" in the body part of the packet in which the format name information read from the specific destination information storage unit 112 has been inserted into the "media format" in the body part has been changed from TCP to UDP (step S21 in FIG. 6).

[0084] Next, the control unit 100 determines whether or not a "200 OK" has been received from the receiving side by UDP packet communication (step S22), and if it determines that a "200 OK" has not been received, the process returns to step S22 and waits for reception of the "200 OK." If it determines in step S22 that a "200 OK" has been received by UDP packet communication, the control unit 100 creates a communication path with the receiving side (step S23) and sends the URL of the access destination for data communication to the sending side to present it (step S24).

[0085] Then, the control unit 100 determines whether or not "TCP-syn" by the browser access TCP packet is received from the LAN side interface 103 (step S25), and if it determines that it has not been received, it waits for its reception. If the control unit 100 determines that the "TCP-syn" TCP packet is received, it performs UDP encapsulation processing on the received "TCP-syn" TCP packet and transmits it to the access destination as a UDP packet (step S26).

[0086] Next, the control unit 100 waits for reception of a UDP packet from the receiving side through the interface 102 (step S27), and when reception of the UDP packet is confirmed, performs UDP decapsulation processing (step S28). Then, the control unit 100 judges whether the TCP packet restored by the UDP decapsulation processing is a "TCP-syn,ack" response to "TCP-syn" (step S29), and when it is confirmed that the response is a "TCP-syn,ack", it sends the TCP packet of the response "TCP-syn,ack" to the sending side through the interface 103 (step S31 in FIG. 7).

[0087] Then, the control unit 100 waits for reception of a "TCP-ack" TCP packet sent from the calling side through the interface 103 (step S32), and when reception of the "TCP-ack" TCP packet through the interface 103 is confirmed, the control unit 100 performs UDP encapsulation processing on the "TCP-ack" TCP packet and sends it to the access destination as a UDP packet (step S33).Then, the control unit 100 creates a data communication path (step S34) and executes data communication by the UDP packet (step S35).

[0088] That is, in step S35, the TCP packet sent from the calling side through interface 103 is subjected to UDP encapsulation processing and transmitted as a UDP packet to the access destination, and the UDP packet sent from the access destination is subjected to UDP decapsulation processing to restore the TCP packet and transmitted to the calling side of the access request through interface 103.

[0089] Next, the control unit 100 determines whether an event to end communication has occurred (step S36), and if it determines that an event to end communication has not occurred, it determines whether a "TCP-syn" has been received through the interface 103 by a TCP packet of another browser access (step S37), and if it determines that a "TCP-syn" has not been received, returns the process to step S35 and repeats the process from step S35 onwards. Also, if it determines in step S36 that a "TCP-syn" has been received through the interface 103 by a TCP packet of another browser access, returns the process to step S26 in Fig. 6 and repeats the process from step S26 onwards.

[0090] Then, if it is determined in step S36 that an event that requires the termination of communication has occurred, the process disconnects the communication path created in step S7 (step S20 in FIG. 5), and this processing routine is terminated.

[0091] [Example of operation of the embodiment of the relay device on the receiving side] 8 to 12 are flowcharts for explaining an example of the operation of the gateway 2 at the time of reception as an example of an embodiment of a relay device on the receiving side. In the following Figs. 8 to 12, the processing of each of the transmission processing unit 104, the reception processing unit 105, the SIP sequence processing unit 106, the specific destination determination unit 107, the data communication processing unit 108, the UDP encapsulation processing unit 109, the UDP decapsulation unit 110, and the LAN management unit 111 will be explained as an example in which the processing of each unit is configured as software functional means executed by a program by the computer constituting the control unit 100. Therefore, in the following explanation, the processing of each step of the flowcharts in Figs. 8 to 12 will be explained as being executed by the control unit 100.

[0092] As shown in FIG. 8, the control unit 100 determines whether or not a TCP packet of an outgoing call request "INVITE" has been received from the WAN side through the interface 102 (step S41), and if it determines that an outgoing call request "INVITE" has not been received, performs other processing (step S42), and then returns to step S41.

[0093] When it is determined in step S41 that an "INVITE" transmission request has been received, the control unit 100 compares the "media format" in the body part of the TCP packet of the received "INVITE" transmission request with the format name information stored in the specific destination information storage unit 112 (step S43) and determines whether the "INVITE" transmission request is addressed to a specific destination (step S44).

[0094] If it is determined in step S44 that the call is not an "INVITE" call request addressed to a specific destination, the control unit 100 returns "200 OK" to the caller (step S45) and creates a communication path (step S46).

[0095] Next, the control unit 100 determines whether or not a "TCP-syn" has been received by the browser access TCP packet through the WAN side interface 102 (step S47), and if it determines that it has not been received, waits for its reception. Then, if the control unit 100 determines in step S47 that a "TCP-syn" TCP packet has been received, it returns a "TCP-syn,ack" TCP packet in response to the received "TCP-syn" TCP packet to the sending side through the interface 102 (step S48).

[0096] Next, the control unit 100 waits for reception of the TCP packet of "TCP-ack" through the interface 102 on the WAN side (step S49), and upon confirming reception of the TCP packet of "TCP-ack" through the interface 102, creates a data communication path and executes data communication using the TCP packet (step S51 in FIG. 9).

[0097] Next, the control unit 100 determines whether an event to end communication has occurred (step S52), and if it determines that an event to end communication has not occurred, it determines whether a "TCP-syn" has been received through the interface 102 by a TCP packet of another browser access (step S53), and if it determines that a "TCP-syn" has not been received, it returns the process to step S51. Also, if it determines in step S53 that a "TCP-syn" has been received through the interface 102 by a TCP packet of another browser access, it returns the process to step S48 in Fig. 8, and the processes from step S48 onwards are repeated.

[0098] If it is determined in step S52 that an event that requires the termination of communication has occurred, the communication path created in step S46 is disconnected (step S54), and this processing routine is terminated.

[0099] Then, when it is determined in step S44 of Fig. 8 that the received transmission request "INVITE" is addressed to a specific destination, the control unit 100 returns a "488 error response" with a warning code "Warning-Code: 304" to the transmission side through the interface 102 (step S61 of Fig. 10). Then, the control unit 100 waits for reception of another transmission request "INVITE" (step S62), and when it confirms reception of another transmission request "INVITE", it refers to the "media format" and "media protocol" in the body part of that packet (step S63) and determines whether or not the transmission request "INVITE" is addressed to a specific destination and is a transmission request by UDP packet communication (step S64).

[0100] Then, when it is determined in step S64 that the received second call request "INVITE" is not addressed to a specific destination and is not satisfied as a call request "INVITE" by UDP packet communication, the control unit 100 performs error processing (step S65). On the other hand, when it is determined in step S64 that the received second call request "INVITE" is addressed to a specific destination and is not satisfied as a call request "INVITE" by UDP packet communication, the control unit 100 returns "200 OK" to the caller through the interface 102 (step S71 in FIG. 11) and creates a communication path (step S72).

[0101] Next, the control unit 100 determines whether or not a UDP packet has been received through the WAN-side interface 102 (step S73), and if it determines that a UDP packet has not been received, waits for reception of a UDP packet. Then, if it determines in step S73 that a UDP packet has been received, the control unit 100 performs a UDP decapsulation process to restore the TCP packet (step S74).

[0102] Then, the control unit 100 checks whether the restored TCP packet is a "TCP-syn" for browser access (step S75), and if so, generates a TCP packet of a "TCP-syn,ack" response to the "TCP-syn" of the received TCP packet, and performs UDP encapsulation processing on the generated TCP packet of the response "TCP-syn,ack" (step S76).Then, the UDP packet generated by the UDP encapsulation processing is transmitted to the sending side via the interface 102 (step S77).

[0103] Thereafter, the control unit 100 waits for reception of a UDP packet through the interface 102 (step S78), and upon confirming reception of the UDP packet, performs UDP decapsulation processing to restore the TCP packet (step S81 in FIG. 12).

[0104] Then, the control unit 100 checks whether the restored TCP packet is a "TCP-ack" (step S82), and when it is confirmed, creates a data communication path (step S83) and performs data communication by UDP packets (step S84). In step S84, a UDP packet sent from the sending side through the interface 102 is decapsulated to restore it to a TCP packet, and a TCP packet to be sent to the sending side of the access request through the interface 102 is encapsulated by UDP and transmitted as a UDP packet.

[0105] Next, the control unit 100 determines whether an event to end communication has occurred (step S85), and if it determines that an event to end communication has not occurred, it determines whether a "TCP-syn" of another browser access has been received through the interface 102 (step S86), and if it determines that a "TCP-syn" has not been received, it returns the process to step S84. Also, if it determines in step S86 that a "TCP-syn" by a TCP packet of another browser access has been received through the interface 102, it returns the process to step S76 in Fig. 11, and the processes from step S76 onwards are repeated.

[0106] If it is determined in step S85 that an event that requires the termination of communication has occurred, the communication path created in step S72 is disconnected (step S87), and this processing routine is terminated.

[0107] [Example of sequence in embodiment of relay system] <Example of sequence for remote maintenance operation> The sequence examples shown in FIGS. 13 to 17 are examples in which the operator of the personal computer 4P is a construction and maintenance person who performs remote maintenance of the gateway 2 with the gateway 2 as a specific destination.

[0108] 13, a construction and maintenance worker operates personal computer 4P to specify remote maintenance targeting gateway 2 as an example of a specific destination, and sends this operation information to gateway 1. Gateway 1 then recognizes, as described above, that this is an outgoing request that specifies gateway 2 as a specific destination, and sends to SIP server 6 an outgoing request "INVITE" TCP packet, including in the "media format" of the body section the format name "saxa.gw-remote-access" meaning remote maintenance of gateway 2 as information corresponding to the specific destination.

[0109] When the SIP server 6 receives this "INVITE", it returns "100 Trying" to the gateway 1 on the sending side, and transfers this "INVITE" to the gateway 2 on the receiving side. When the gateway 2 on the receiving side receives this "INVITE", it returns "100 Trying" to the SIP server 6, and recognizes from the format name of the "media format" in the body part of the TCP packet of the "INVITE" that this is for a specific destination (addressed to itself). Then, since the "media Protocol" is TCP, the gateway 2 returns a "488 error response" with a warning code ("488 Not Acceptable Here; Warning-Code: 304 (Media type not available)") to the SIP server 6. The SIP server 6 returns this "488 error response" with the warning code to the gateway 1 on the sending side.

[0110] Gateway 1, which has received this "488 error response," determines from the warning code "Warning-Code: 304 (Media type not available)" that the other party is requesting a switch in the "media protocol," and, as shown in Fig. 14, switches the "media protocol" from TCP to UDP and sends an "INVITE" with "saxa.gw-remote-access" included as the format name of the "media format" in the body section to SIP server 6 via UDP packet communication. SIP server 6 transfers this "INVITE" of UDP packet communication to gateway 2 on the receiving side.

[0111] Gateway 2, which receives this UDP packet communication "INVITE", returns a UDP packet "100 Trying" and a "200 OK" to SIP server 6 because the "media protocol" is UDP. SIP server 6 sends the "200 OK" to gateway 1 on the sending side. Through the above sequence, a communication path (SIP session) is created between personal computer 4P on the sending side and gateway 2 on the receiving side.

[0112] When the communication path is created, the gateway 1 sends the URL of the access destination to be used for remote maintenance to the personal computer 4P via the LAN, and causes it to be displayed on the screen of the personal computer 4P. In response to this, the remote maintenance person performs the first browser access-1 operation on the screen of the personal computer 4P, and sends the TCP packet "TCP-syn" of that access request to the gateway 1 via the LAN, as shown in Fig. 15.

[0113] When the gateway 1 receives this TCP packet "TCP-syn," it performs UDP encapsulation processing and sends it as a UDP packet to the NAPT function unit 7. The NAPT function unit 7 transfers the received UDP packet to the destination gateway 2. In this case, since the NAPT function unit 7 receives a UDP packet and not a TCP packet, address resolution processing is not performed due to the handshake connection used in the case of a TCP packet.

[0114] When the receiving gateway 2 receives this UDP packet, it performs UDP decapsulation processing to restore the TCP packet "TCP-syn". The gateway 2 then generates a TCP packet "TCP-syn,ack" in response to the "TCP-syn", performs UDP encapsulation processing on the generated TCP packet, and sends it as a UDP packet to the NAPT function unit 7. The NAPT function unit 7 sends the UDP packet addressed to the sending gateway 1.

[0115] On receiving this UDP packet, Gateway 1 on the sending side removes the UDP encapsulation and restores the "TCP-syn,ack" of the TCP packet. Gateway 1 then sends the restored "TCP-syn,ack" of the TCP packet to PC 4P via the LAN. PC 4P, which receives this "TCP-syn,ack" of the TCP packet, creates a TCP packet of "TCP-ack" in response to the "TCP-syn,ack", and sends the "TCP-ack" of the created TCP packet to Gateway 1 via the LAN, as shown in Figure 16.

[0116] The gateway 1 performs UDP encapsulation on the "TCP-ack" of the received TCP packet and transmits it as a UDP packet to the NAPT function unit 7. The NAPT function unit 7 transmits the UDP packet addressed to the gateway 2 on the receiving side.

[0117] When Gateway 2 receives this UDP packet, it removes the UDP encapsulation and restores the "TCP-ack" of the TCP packet.

[0118] The above sequence completes preparations for data communication based on the initial browser access-1. After that, as shown in the middle of Fig. 16, when the personal computer 4P sends out the TCP packet "TCP-psh,ack" requesting data communication, the gateway 1 on the sending side performs UDP encapsulation on the TCP packet "TCP-psh,ack" and sends it as a UDP packet to the gateway 2 on the receiving side via the NAPT function unit 7.

[0119] The receiving gateway 2 performs UDP decapsulation to restore the "TCP-psh,ack" of the TCP packet and generates a TCP packet of "TCP-ack" in response to the "TCP-syn". The gateway 2 then performs UDP encapsulation on the generated TCP packet, as shown in Fig. 17, and transmits it as a UDP packet to the NAPT function unit 7. The NAPT function unit 7 transmits the UDP packet addressed to the sending gateway 1.

[0120] The gateway 1 on the sending side receives this UDP packet and removes the UDP encapsulation to restore the "TCP-ack" of the TCP packet. The gateway 1 then transmits the "TCP-ack" of the restored TCP packet to the PC 4P via the LAN. In this way, data communication between the PC 4P and the gateway 2 based on the initial browser access-1 is completed.

[0121] Thereafter, when a second browser access-2 is performed on the personal computer 4P, the TCP packet "TCP-syn" of that access request is sent to the gateway 1 via the LAN. On receiving this TCP packet "TCP-syn", the gateway 1 performs UDP encapsulation processing on this TCP packet "TCP-syn" in the same manner as in the first browser access-1, and sends it as a UDP packet to the NAPT function unit 7. Thereafter, the same sequence as in the first browser access-1 is performed, and data communication is performed between the personal computer 4P and the gateway 2 based on the second browser access-2.

[0122] Then, for the third, fourth, ... nth browser access, a similar sequence is performed to execute data communication.

[0123] As described above, in this embodiment, after a call path is generated by a SIP session, information is exchanged by UDP packets between the gateway 1 on the calling side and the gateway 2 on the receiving side by performing UDP encapsulation of TCP packets. Therefore, in the NAPT function unit 7, address resolution processing is not performed due to the handshake connection in the case of TCP packets. Therefore, even if multiple different browser access requests occur, the NAPT function unit 7 does not treat them as different sessions, and data communication based on multiple browser access requests is possible regardless of the limit on the number of sessions as explained at the beginning.

[0124] Therefore, according to the relay system of this embodiment, even if a large number of browser access requests for remote maintenance are generated, the large number of browser access requests can be executed without any problems, and remote maintenance work can be performed smoothly.

[0125] <WEBサーバ5Sへのブラウザアクセス> The sequence example shown in Figures 18 to 21 is an example in which the operator of the personal computer 4P is the person accessing the WEB server 5S, and performs WEB access to the WEB server 5S with the WEB server 5S as a specific destination. Since this sequence example has many parts that are similar to the sequence example in the case of the remote maintenance operation described above, the following explanation will mainly focus on the parts that are different from the case of the remote maintenance operation described above shown in Figures 13 to 17.

[0126] As shown in FIG. 18, a person accessing the WEB server 5S makes a browser access request from a personal computer 4P, specifying the WEB server 5S as an example of a specific destination, in this example, to the URL “http: / / saxa.gw-web-access.”

[0127] The gateway 1 then recognizes, as described above, that this is an outgoing request that designates the web server 5S as a specific destination, and sends an "INVITE" TCP packet outgoing request to the SIP server 6, with the format name "saxa.gw-web-access", which means browser access to the web server 5S, included in the "media format" body as information corresponding to the specific destination.

[0128] The subsequent sequence in Fig. 18 and the sequence in Fig. 19 are exactly the same, except that the "media format" in the body contains the format name "saxa.gw-web-access" instead of the format name "saxa.gw-remote-access". Then, similar to the above sequence example, a communication path (SIP session) is created between the sending PC 4P and the receiving gateway 2 through the above sequence.

[0129] When the communication path is created, the gateway 1 sends the URL for accessing the web server 5S to the personal computer 4P via the LAN, as shown in Fig. 20, and causes it to be displayed on the screen of the personal computer 4P. In response to this, the operator of the personal computer 4P performs the first browser access-1 operation on the screen of the personal computer 4P, and sends the TCP packet "TCP-syn" of that access request to the gateway 1 via the LAN.

[0130] When the gateway 1 receives this TCP packet “TCP-syn”, it performs UDP encapsulation processing and transmits it as a UDP packet to the gateway 2 via the NAPT function unit 7 .

[0131] When the receiving gateway 2 receives this UDP packet, it performs UDP decapsulation processing to restore the TCP packet "TCP-syn". The gateway 2 then sends the restored TCP packet "TCP-syn" to the WEB server 5S via the LAN. The WEB server 5S generates a TCP packet "TCP-syn,ack" in response to the "TCP-syn" and sends the generated TCP packet to the gateway 2.

[0132] The gateway 2 performs UDP encapsulation processing on the received TCP packet of “TCP-syn,ack” and transmits it as a UDP packet via the NAPT function unit 7 to the gateway 1 on the sending side.

[0133] On receiving this UDP packet, Gateway 1 on the sending side removes the UDP encapsulation and restores the "TCP-syn,ack" of the TCP packet. Gateway 1 then sends the restored "TCP-syn,ack" of the TCP packet to PC 4P via the LAN. PC 4P, which receives this "TCP-syn,ack" of the TCP packet, creates a TCP packet of "TCP-ack" in response to the "TCP-syn,ack", and sends the "TCP-ack" of the created TCP packet to Gateway 1 via the LAN, as shown in Figure 21.

[0134] The gateway 1 performs UDP encapsulation processing on the “TCP-ack” of the received TCP packet, and transmits it as a UDP packet via the NAPT function unit 7 to the gateway 2 on the receiving side.

[0135] The gateway 2 that receives this UDP packet removes the UDP encapsulation and restores the "TCP-ack" of the TCP packet. The gateway 2 then transmits the restored "TCP-ack" of the TCP packet to the web server 5S.

[0136] Through the above sequence, preparations are made for data communication between the personal computer 4P and the web server 5S based on the initial browser access-1. After that, as shown in the middle of Fig. 21, when the personal computer 4P sends out the TCP packet "TCP-psh,ack" requesting data communication, the gateway 1 on the sending side performs UDP encapsulation on the TCP packet "TCP-psh,ack" and sends it as a UDP packet to the gateway 2 on the receiving side via the NAPT function unit 7.

[0137] The receiving gateway 2 performs UDP decapsulation processing to restore the TCP packet "TCP-psh,ack" and sends the restored TCP packet "TCP-psh,ack" to the WEB server 5S. The WEB server 5S creates a TCP packet for the response "TCP-ack" to the received "TCP-psh,ack" and sends the created TCP packet to the gateway 2.

[0138] The gateway 2 performs UDP encapsulation processing on the TCP packet of the received "TCP-ack" and transmits it as a UDP packet to the gateway 1 on the sending side via the NAPT function unit 7 as shown in FIG.

[0139] The gateway 1 on the sending side that receives this UDP packet removes the UDP encapsulation and restores the "TCP-ack" of the TCP packet. The gateway 1 then transmits the "TCP-ack" of the restored TCP packet to the PC 4P via the LAN. In this way, data communication is performed between the PC 4P and the WEB server 5S based on the initial browser access-1.

[0140] Thereafter, when a second browser access-2 is operated on personal computer 4P, the TCP packet "TCP-syn" of that access request is sent to gateway 1 via the LAN. On receiving this TCP packet "TCP-syn", gateway 1 performs UDP encapsulation processing on this TCP packet "TCP-syn" in the same manner as in the case of the first browser access-1, and transmits it as a UDP packet to gateway 2 on the receiving side via NAPT function unit 7. Gateway 2 performs UDP decapsulation processing on the received UDP packet, restores the TCP packet "TCP-syn", and transmits it to WEB server 5S via the LAN.

[0141] Thereafter, the same sequence as in the case of the first browser access-1 is performed, and data communication is performed between the personal computer 4P and the Web server 5S based on the second browser access-2.

[0142] A similar sequence is performed for the third, fourth, . . . n-th browser accesses, and data communication is performed between the personal computer 4P and the Web server 5S.

[0143] In this example, data communication based on multiple browser access requests is possible regardless of the limit on the number of sessions as described above. Therefore, according to the relay system of this embodiment, even if multiple browser access requests are generated between a communication function equipped device connected to a gateway on the sending side through a LAN and a communication function equipped device connected to a gateway on the receiving side through a LAN, the multiple browser access requests can be executed without any problems, and data communication by WEB access can be performed smoothly.

[0144] [Other embodiments or modifications] In the embodiment described above, the relay device is a gateway, but it goes without saying that the device is not limited to a gateway as long as it performs relay processing between the sending side and the receiving side when communication is performed through a communication network on the WAN side.

[0145] Furthermore, in the above embodiment, the communication function equipped device is connected to the relay device via a LAN, but the present invention is also applicable to the case where a standalone communication function equipped device is connected to the relay device.

[0146] Furthermore, although the first protocol is TCP and the second protocol is UDP, it goes without saying that the present invention is not limited to this.

[0147] In the above embodiment, the information corresponding to a specific destination is inserted into the "media format" in the body of the packet of the call request, but it may be other information in the body. It may also be inserted into a part other than the body, such as the header.

[0148] In the above embodiment, the transmitting relay device inserts information corresponding to the specific recipient into the second transmission request "INVITE" sent in response to an error response from the receiving relay device. However, information corresponding to the specific recipient does not have to be inserted into this second transmission request "INVITE". In this case, the receiving relay device can recognize the specific recipient by retaining information corresponding to the specific recipient contained in the first transmission request "INVITE". Also, if there is only one specific recipient, the receiving relay device can recognize the specific recipient by storing the single specific recipient. [Explanation of symbols]

[0149] 1...Gateway (example of sending side), 2...Gateway (example of receiving side), 3...Communication network, 4, 5...Communication function equipped device, 4P...Personal computer, 5S...WEB server, 6...SIP server, 7...NAPT function unit, 100...Control unit, 101...System bus, 102, 103...Interface, 104...Transmission processing unit, 105...Reception processing unit, 106...SIP sequence processing unit, 107...Specific destination determination unit, 108...Data communication processing unit, 109...UDP encapsulation processing unit, 110...UDP decapsulation unit, 111...LAN subordinate management unit, 112...Specific destination information storage unit

Claims

1. A relay system for communicating information of a first protocol that requires a connection by a handshake for each transmission through a communication path generated based on a transmission request, comprising: The relay device on the sending side a means for transmitting, when receiving a request for transmission to a predetermined specific destination as a receiving side, a transmission request including information corresponding to the specific destination to a relay device on the receiving side in accordance with the first protocol; a means for transmitting a second call request using a second protocol that does not require the connection when an error response is received from the relay device on the receiving side in response to the call request; a means for performing encapsulation between the receiving relay device and the first protocol-compliant packet so as to make the packet compatible with the second protocol, in data communication through the communication path generated based on the second transmission request; Equipped with The receiving relay device means for transmitting the error response to the relay device on the calling side when the received call origination request includes information corresponding to the specific called party; a means for performing a process for generating the communication path when the second transmission request of the second protocol is received from the relay device on the transmission side; a means for performing encapsulation between the first protocol-compliant packet and the relay device on the transmitting side in data communication through the communication path generated based on the second transmission request, to make the packet compatible with the first protocol compatible with the second protocol; A relay system comprising:

2. The relay device on the receiving side adds information to the error response that suggests switching from the first protocol to another protocol.

2. The relay system according to claim 1 .

3. The first protocol is TCP (Transmission Control Protocol), the second protocol is UDP (User Datagram Protocol), and the information corresponding to the specific destination is information on a media format of a body portion of the TCP packet.

3. The relay system according to claim 1 or 2.

4. A relay system for communicating information of a first protocol that requires a connection by a handshake for each transmission through a communication path generated based on a transmission request, comprising: The receiving relay device means for transmitting an error response to a relay device on the calling side when the received call origination request contains information corresponding to a specific destination that is determined in advance; a means for performing a process for generating the communication path when a second transmission request for a second protocol that does not require the connection is received from the relay device on the transmission side; a means for performing encapsulation between the first protocol-compliant packet and the relay device on the transmitting side in data communication on the communication path created based on the second transmission request, to make the packet compatible with the first protocol compatible with the second protocol; A relay device on the transmitting side in a relay system comprising: a means for transmitting, when receiving a request for transmission to the specific destination as a receiving side, a transmission request including information corresponding to the specific destination to the receiving side relay device in accordance with the first protocol; means for transmitting the retransmission request in accordance with the second protocol when the error response is received from the relay device on the receiving side; means for carrying out data communication on the communication path created based on the second transmission request, by encapsulating a packet conforming to the first protocol with the receiving relay device to make it conforming to the second protocol; A relay device on a transmitting side in a relay system comprising:

5. A relay system for communicating information of a first protocol that requires a connection by a handshake for each transmission through a communication path generated based on a transmission request, comprising: The relay device on the sending side a means for transmitting, when receiving a request for transmission to a predetermined specific destination as a receiving side, the request for transmission including information corresponding to the specific destination to a relay device on the receiving side in accordance with the first protocol; means for transmitting the call origination request again in the second protocol when an error response is received from the relay device on the receiving side; a means for performing encapsulation of a packet conforming to the first protocol so as to conform to the second protocol between the relay device on the receiving side and the data communication through the communication path generated based on the second transmission request; A relay device on a receiving side of a relay system comprising: means for transmitting the error response to the relay device on the calling side when the first information is included in the received calling request; a means for performing a process for generating the communication path when the second transmission request of the second protocol is received from the relay device on the transmission side; a means for performing encapsulation of a packet conforming to the first protocol so as to conform to the second protocol between the relay device on the transmitting side and the data communication through the communication path generated based on the second transmission request; 13. A relay device on a receiving side in a relay system comprising:

Images