Control device, control method, and program

Abstract

A control device 1 comprises: a storage unit 14 that stores a connection method by which a session was established in the past; a determination unit 12 that receives a connection request from a connection source client A and determines whether or not a connection method corresponding to the connection source client A and a connection destination client B exists in the storage unit 14; and a notification unit 13 that, if the corresponding connection method exists in the storage unit 14, notifies the connection source client A and the connection destination client B of an address candidate used in the connection method and causes the connection source client A and the connection destination client A to acquire only the address of the notified address candidate.

Description

Control Device, Control Method, and Program

[0001] The present disclosure relates to a control device, a control method, and a program.

[0002] In establishing a media session by WebRTC, there is a procedure of collecting address candidates (ICE Candidates) used as media destinations, exchanging them with each other, and checking connectivity. There are three types of address candidates to be collected (host, server-reflexive, relay).

[0003] Host is the address of the client itself. Server-reflexive (srflx) is the address outside the NAT obtained from the STUN server. Relay is the relay address of the TURN server. ICE is described in Non-Patent Documents 1 and 2.

[0004] RFC8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) TraversalRFC8838 Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol

[0005] In the process of a client or server collecting address candidates from the STUN server and the TURN server, there is a problem that time and communication resources are required.

[0006] Also, in checking connectivity, in order to try multiple pairs of address candidates, the number of attempts to check connectivity increases when the number of pairs is large. For example, when two clients each have three types of address candidates, a large number of attempts are required. Also, depending on the implementation, connectivity checks are performed for pairs that are not used.

[0007] This disclosure is made in view of the above circumstances, and its purpose is to provide a technology that can streamline the collection of address candidates and connectivity verification, thereby reducing the time and communication resources required to establish a session.

[0008] To achieve the above objective, one aspect of the present disclosure is a control device comprising: a storage unit that stores connection methods for which sessions have been established in the past; a determination unit that receives a connection request from a connecting client and determines whether a connection method corresponding to the connecting client and the connected client exists in the storage unit; and a notification unit that, if a corresponding connection method exists in the storage unit, notifies the connecting client and the connected client of address candidates used in the connection method and causes the connecting client and the connected client to obtain only the addresses of the notified address candidates.

[0009] One aspect of the present disclosure is a control system comprising a control device and a plurality of clients, wherein the control device includes a storage unit that stores connection methods for which sessions have been established in the past, a determination unit that receives a connection request from a connecting client and determines whether a connection method corresponding to the connecting client and the connected client exists in the storage unit, and a notification unit that, if a corresponding connection method exists in the storage unit, notifies the connecting client and the connected client of the address candidate used in the connection method, and the connecting client and the connected client each include an acquisition unit that acquires only the address of the notified address candidate.

[0010] One aspect of the present disclosure is a control method performed by a control device, the control device comprising a storage unit that stores connection methods for which sessions have been established in the past, receiving a connection request from a connecting client, determining whether a connection method corresponding to the connecting client and the connected client exists in the storage unit, and if a corresponding connection method exists in the storage unit, notifying the connecting client and the connected client of the address candidate used in the connection method, and causing the connecting client and the connected client to acquire only the address of the notified address candidate.

[0011] This disclosure provides a technology that streamlines the collection of address candidates and connectivity verification, thereby reducing the time and communication resources required to establish a session.

[0012] Figure 1 is a diagram showing an example configuration of the communication system of this embodiment. Figure 2 is a diagram showing an example configuration of a client. Figure 3 is a sequence diagram showing an overview of session establishment. Figure 4 is a sequence diagram showing an overview of session establishment. Figure 5 is an explanatory diagram explaining session establishment for clients A and B. Figure 6 is an explanatory diagram explaining session establishment for clients A and B. Figure 7 is an explanatory diagram explaining session establishment for clients A and B. Figure 8 is an explanatory diagram explaining session establishment for clients A and B. Figure 9 is an explanatory diagram explaining session establishment for clients A and B. Figure 10 is an explanatory diagram explaining session establishment for clients A and B. Figure 11 is an explanatory diagram explaining session establishment for clients A and B. Figure 12 is a diagram showing an example of DB result data. Figure 13 is an explanatory diagram explaining session establishment for clients A and B. Figure 14 is an explanatory diagram explaining session establishment for clients A and C. Figure 15 is an explanatory diagram explaining session establishment for clients A and C. Figure 16 is an explanatory diagram explaining session establishment for clients A and C. Figure 17 is an explanatory diagram explaining session establishment for clients A and C. Figure 18 is an explanatory diagram illustrating the establishment of sessions for clients A and C. Figure 19 is an explanatory diagram illustrating the establishment of sessions for clients A and C. Figure 20 is an explanatory diagram illustrating the establishment of sessions for clients A and C. Figure 21 is a diagram showing an example of DB result data. Figure 22 is an explanatory diagram illustrating the establishment of sessions for clients A and C. Figure 23 is a sequence diagram for establishing sessions for clients A and B. Figure 24 is a sequence diagram for establishing sessions for clients A and B. Figure 25 is a sequence diagram for establishing sessions for clients A and C. Figure 26 is a sequence diagram for establishing sessions for clients A and C. Figure 27 is an example of hardware configuration.

[0013] The embodiments of this disclosure will be described below with reference to the drawings.

[0014] Figure 1 shows an example of the configuration of the communication system of this embodiment. The communication system of this embodiment is a system that uses WebRTC (Web Real-Time Communication), but is not limited to this.

[0015] WebRTC is a technology that enables real-time communication between web browsers and mobile apps via APIs. WebRTC collects and exchanges candidate addresses (ICE candidates) to be used as media destinations, and verifies connectivity. The collected address candidates include host (the client's own IP address), server-reflexive (the IP address outside the NAT), and relay (the relay IP address held by the TURN server). Hereafter, server-reflexive will be referred to as srflx.

[0016] The collection of address candidates takes the most time and communication resources in the following order: relay, srflx, and host. Host collection takes almost no time. Srflx is affected by the physical distance to STUN servers 4A and 4B, the number and / or type of NATs 7A and 7B, and the number of concurrent user connections. Relay is affected by the physical distance to TURN servers 5A and 5B, the number and / or type of NATs 7A and 7B, and the number of concurrent user connections.

[0017] The illustrated communication system includes clients A, B, and C and NATs 7A and 7B at each user location, and on the network are web servers 3A and 3B, STUN servers 4A and 4B, TURN servers 5A and 5B, a signaling server 6, and a control server 1.

[0018] Web servers 3A and 3B act as bridges for the transfer of stream data generated during communication. STUN servers 4A and 4B notify clients of their IP address (srflx) as seen from the external network. TURN servers 5A and 5B notify clients of the relay IP address (relay). Signalling server 6 obtains information about communication partners from clients.

[0019] The control server 1 (control device) comprises a transmitting / receiving unit 11, a determination unit 12, a generation unit 13 (notification unit), and a DB 14 (storage unit).

[0020] The transmitting / receiving unit 11 sends and receives data with the Signaling server 6. The transmitting / receiving unit 11 successfully confirms connectivity and registers the connection method in DB 14.

[0021] The determination unit 12 receives a connection request from the connecting client and determines whether a connection method corresponding to the connecting client and the destination client exists in DB 14. The determination unit 12 may also determine whether a connection method including the domain of the connecting client and the domain of the destination client exists in DB 14.

[0022] The generation unit 13, if a corresponding connection method exists in DB 14, notifies the source client and destination client of the address candidates used in the connection method, and causes the source client and destination client to obtain only the addresses of the notified address candidates. DB 14 stores connection methods for which sessions have been established in the past.

[0023] Figure 2 shows an example configuration of client A. Clients B and C are the same as client A. The illustrated client A includes JavaScript 21, a control APP 22, and an ICE Agent 23.

[0024] JavaScript21 (JavaScript library) is a JavaScript application required for WebRTC connections. The JavaScript is delivered from Web server 3A.

[0025] The control APP 22 is an application delivered from the Web server 3A and comprises a transmit / receive unit 221, a control unit 222, and an acquisition unit 223. The transmit / receive unit 221 transmits and receives data with JavaScript and the ICE Agent 23. The control unit 222 controls the ICE Agent 23. Specifically, the control unit 222 controls the ICE Agent 23 to acquire only the address candidates of the connection method stored in the DB 14. The acquisition unit 223 acquires successful connection methods from the ICE Agent 23, for example, using the getStats API. The getStats API is an API for collecting WebRTC statistics.

[0026] ICE Agent 23 collects address candidates from STUN server 4A and TURN server 5A. ICE Agent 23 may collect only specified address candidates, depending on the control of control APP 22. Once a pair of address candidates is formed, ICE Agent 23 performs a connectivity check. ICE Agent 23 may send the connection method of the successful connectivity check to control APP 22.

[0027] Figures 3 and 4 are sequence diagrams illustrating the overview of media session establishment in this embodiment. In Figures 3 and 4, the Signaling server 6, Web servers 3A and 3B, and control server 1 are omitted. Also, each client A, B, and C communicates with other devices via NAT 7A and NAT 7B. In the illustrated example, client A first establishes a session with client B, and then establishes a session with client C.

[0028] In Figure 3, client A requests the srflx address outside of NAT 7A from STUN server 4A (S11) and sends an SDP (Session Description Protocol) Offer to client B (S12). Upon receiving the SDP Offer, client B requests the srflx address outside of NAT 7B from STUN server 4B (S13) and sends an SDP Answer to client A (S14).

[0029] Client A requests a relay address from TURN server 5A (S15). Client B requests a relay address from TURN server 5B (S16).

[0030] Client A and Client B exchange address candidates (A host - B host) and perform connectivity checks without waiting for responses from STUN servers 4A and 4B and TURN servers 5A and 5B (S17).

[0031] Client A obtains an srflx address from STUN server 4A (S18) and sends the address to Client B via WebSocket (S19). Client A may use WebSocket for subsequent communications with Client B. Client B obtains an srflx address from STUN server 4B (S20) and sends the address to Client A via WebSocket (S21).

[0032] Once the srflx addresses are collected, client A and client B exchange address candidates and perform connectivity checks (S22). Here, connectivity checks are performed for A srflx - B host, A host - B srflx, and A srflx - B srflx. If at least one connectivity check in S22 is successful, a session is established and media communication is established (S23).

[0033] Client A obtains a relay address from TURN server 5A (S24) and sends that address to Client B via WebSocket (S25). Client B obtains a relay address from TURN server 5B (S26) and sends that address to Client A via WebSocket (S27).

[0034] Once the relay addresses are collected, clients A and B exchange candidate addresses and perform connectivity checks (S28). Here, connectivity checks are performed for A relay - B host, A host - B relay, A relay - B srflx, A srflx - B relay, and A relay - B relay. The operation after any connectivity check is successful and media communication is established depends on the implementation. For example, the operation may end when media communication is established (S23) and the subsequent operations (S24 to S28) may not be performed, or the subsequent operations (S24 to S28) may be continued in the background and the session may be switched to a better pair if one is found.

[0035] In Figure 4, client A disconnects the media session with client B, which was established in S23, and establishes a media session with client C. Note that client C is a client in the same domain as client B.

[0036] In step S23, client A stores the connection method used between client A and client B in the control server 1. Then, client A disconnects the media session with client B (S30) and begins establishing a media session with client C.

[0037] Specifically, client A requests the srflx address outside of NAT 7A from STUN server 4A (S31) and sends an SDP Offer to client C (S32). Client A uses the connection method between client A and client B that was stored in control server 1 in S23. Here, it is assumed that both clients use the STUN candidate (A srflx - B srflx) as their connection method stored in control server 1 in S23. In this case, when client A connects with client C (a client in the same domain as client B), address candidates other than the STUN candidate are not collected.

[0038] When client C receives the SDP Offer in S32, it requests the srflx address outside of NAT 7B from STUN server 4B (S33) and sends the SDP Answer to client A (S34).

[0039] Client A obtains an srflx address from STUN server 4A (S35) and sends this address to Client C via WebSocket (S36). Client C obtains an srflx address from STUN server 4B (S37) and sends this address to Client A via WebSocket (S38). Clients A and C exchange srflx addresses and perform connectivity checks (S39). Here, connectivity checks are performed between A srflx and C srflx.

[0040] If the connectivity check in S39 is successful, a media session is established between client A and client C, and media communication is established (S40).

[0041] Thus, in this embodiment, the history of past connection methods between client A and client B can be utilized to improve the efficiency of connections with client C. Specifically, when connecting with a new client (user), the history of previously used connection methods (Host / STUN / TURN) can be utilized to conserve communication resources used for collecting connection method address candidates (ICE Candidate) and verifying connectivity.

[0042] Furthermore, this embodiment can be applied not only to the reconnection of the same client (user), but also when other clients (users) in the same domain connect.

[0043] The media session establishment process described in Figures 3 and 4 will be explained in detail below using Figures 5 to 22. Client A communicates with other devices via NAT 7A, while clients B and C communicate with other devices via NAT 7B.

[0044] Figures 5 to 13 are diagrams when there is no data (history) corresponding to the DB14 of the control server 1. In Figure 5, when starting communication via WebRTC, client A accesses Web server 3A and acquires a user ID, JavaScript (JavaScript library), and a control APP from Web server 3A (S51). Web server 3A issues the user ID of client A in the form of, for example, "username@domain", and distributes JavaScript and the control APP to client A. In the illustrated example, the user ID of client A is set as useraaa@office1.example.com.

[0045] Similar to client A, when starting communication via WebRTC, client B accesses Web server 3B and acquires a user ID, JavaScript, and a control APP from Web server 3B (S51). In the illustrated example, the user ID of client B is set as userbbb@home1.example.com.

[0046] In Figure 6, in order to start connection with client B, before transmitting the SDP Offer, client A transmits the user ID of the source of connection (client A) and the user ID of the destination of connection (client B) to control server 1 via Signalling server 6 (S52). Signalling server 6 notifies control server 1 of the user ID of the source of connection and the user ID of the destination of connection (S53).

[0047] In S52, client A may transmit the SDP Offer to Signalling server 6, and Signalling server 6 may attach the response from control server 1 to the SDP Offer and transmit it to client B.

[0048] The determination unit 12 of the control server 1 receives a notification from the Signalling server 6 via the transmission / reception unit 11, and determines whether there is result data of the connectivity confirmation in the DB 14 using the source user ID and the destination user ID included in the notification (S54). For example, the determination unit 12 may determine whether the result data of the connectivity confirmation when a client of "@office1.example.com" (domain) communicates with a client of "@home1.example.com" (domain) exists in the DB 14.

[0049] In FIG. 7, when there is no result data of the connectivity confirmation in the DB 14, the determination unit 12 notifies the generation unit 13 to that effect. The generation unit 13 generates a blank control signal (for example, a control signal with null set) indicating that there is no result data, and transmits it to the client A via the Signalling server 6 (S55). The generation unit 13 may transmit the control signal to the Signalling server 6 via the determination unit 12 and the transmission / reception unit 11.

[0050] The Signalling server 6 transmits the control signal to the client A in json format using a channel such as websocket. When the client A receives a blank control signal, it performs the normal operation described below.

[0051] In FIG. 8, the client A requests the STUN server 4A for its srflx address after NAT conversion (S56). The STUN server 4A transmits the srflx address to the client A (S57). In the illustrated example, the IP address of the client A is as follows.

[0052] IP address (host candidate): A NAT-translated IP address (srflx candidate): A' Then, client A sends an SDP Offer containing ICE Candidate (A, A') to client B via the Signaling Server 6 and exchanges ICE Candidate (A, A') with client B (S58). Also, client A sets the blank control signal sent by control server 1 in S55 into the SDP Offer. If the SDP Offer contains a blank control signal, client B performs the normal operation described below.

[0053] In Figure 9, when client B receives the ICE Candidate from client A in S58, it requests its NAT-translated srflx address from STUN server 4B (S59). STUN server 4B sends the srflx address to client B (S60). In the illustrated example, the IP address of client B is as follows.

[0054] IP address (host candidate): B NAT translated IP address (srflx candidate): B' Client B sends an SDP containing the ICE Candidate (B, B') to Client A via the Signaling Server 6, and exchanges the ICE Candidate (B, B') with Client A (S61).

[0055] In Figure 10, Client A and Client B perform connectivity checks with the exchanged ICE Candidates (S62).

[0056] In Figure 11, client A uses the getStats API (an API for collecting WebRTC statistics) to collect information and perform connectivity checks, and sends the successful connection method to the Signaling server 6 (S63). Client A may also send the connectivity check results (success or failure) of each ICE Candidate Peer to the Signaling server 6. This is the same operation as Chrome WebRTC Internals. In addition, considering the characteristics of Tricke ICE, client A may send the successful connection method as soon as information is collected.

[0057] Similarly, client B also sends the successful connection method to the Signaling server 6 (S63). Client B may also send the results of the connectivity check (success or failure) for each ICE Candidate Peer to the Signaling server 6.

[0058] The Signalling server 6 transmits the successful connection methods sent from clients A and B to the control server 1 (S64). The transmitting / receiving unit 11 of the control server 1 stores the successful connection methods as connectivity confirmation result data in the DB 14.

[0059] Figure 12 shows an example of connectivity check result data stored in DB 14 at the time shown in Figure 11. The illustrated result data includes the source user ID, destination user ID, type of Local Candidate, type of Remote Candidate, and storage time. Here, it indicates that connectivity check was successful between the srflx address candidate (Local Candidate) of client A and the srflx address candidate (Remote Candidate) of client B. The transmitting / receiving unit 11 stores only the user ID pairs for which connectivity check was successful in DB 14. Note that when updating DB 14, the transmitting / receiving unit 11 may overwrite the existing result data with new result data if result data with a perfectly matching user ID already exists.

[0060] In Figure 13, if connectivity is confirmed successfully, a media session is established between client A and client B, and media communication is established (S65).

[0061] Next, referring to Figures 14 to 22, we will explain the case where there is corresponding data in DB14 of control server 1.

[0062] In Figure 14, client A disconnects the media session with client B, which was established in S65 of Figure 13 (S70). When client C starts communication using WebRTC, it accesses web server 3B and obtains a user ID, JavaScript, and control app from web server 3B (S71). Web server 3B issues a user ID for client C and delivers JavaScript and the control app to client C. In the illustrated example, the user ID for client C is ID:userccc@home1.example.com.

[0063] In Figure 15, in order to initiate a connection with Client A, Client C sends the source user ID and destination user ID to the control server 1 via the Signalling server 6 before sending the SDP Offer (S72). The Signalling server 6 notifies the control server 1 of the source user ID and destination user ID (S73).

[0064] In addition, in S72, client C may send the SDP Offer to the Signaling server 6, and the Signaling server 6 may add the response from the control server 1 to the SDP Offer and send it to client A.

[0065] The determination unit 12 of the control server 1 receives a notification from the Signaling server 6 via the transmission / reception unit 11, and uses the user ID of the connecting user and the user ID of the connecting user included in the notification to determine whether or not there is connectivity confirmation result data in DB 14 (S74).

[0066] For example, the determination unit 12 may use "To: useraaa@office1.example.com, From: userccc@home1.example.com" as search conditions. Alternatively, the determination unit 12 may determine whether or not data from a connectivity check when a client from "@home1.example.com" (domain) communicates with a client from "@office1.example.com" (domain) exists in DB 14.

[0067] If DB14 in this case is the DB14 shown in Figure 12, there is no result data where the user ID is an exact match, but there is result data where only the domain name matches. In other words, DB14 contains the result data of connectivity checks when a client from the domain "@home1.example.com" communicates with a client from the domain "@office1.example.com".

[0068] The determination unit 12 may search using the following priority search logic and notify the generation unit 13 of the connection method of the highest priority pair (result data) as the search result.

[0069] Priority 1 (highest priority): Result data where the user ID is an exact match.

[0070] Priority 2 (next highest priority): Result data where only the domain name matches. If there are multiple result data where only the domain name matches, the storage time is used to select the result data (e.g., the result data with the most recent storage time).

[0071] In Figure 16, the determination unit 12 notifies the generation unit 13 of the determination result in S74. The determination result may include connectivity confirmation result data extracted from DB 14. In the illustrated example, it may include the address type on the @home1.example.com side (Local Candidate): srflx and the address type on the @office1.example.com side (Remote Candidate): srflx. That is, the determination result may include the address type of the connecting client C and the address type of the connecting client A for the successful connection method.

[0072] The generation unit 13 generates a control signal including the successful connection method and transmits it to client C via the Signaling server 6 (S75). The generation unit 13 may also transmit the control signal to the Signaling server 6 via the determination unit 12 and the transmission / reception unit 11. In this case, the control server 1 does not transmit the control signal directly to client A, but transmits the control signal to client A via the Signaling server 6.

[0073] The Signalling server 6 sends the control signals received from the control server 1 to the client C in JSON format using an existing channel, such as a websocket (S76). These control signals include the successful connection method (@home1.example.com side: srflx, @office1.example.com side: srflx).

[0074] Client C receives the control signal and collects candidate addresses based on the successful connection method included in the control signal. Here, Client C collects only candidate addresses for srflx (S77). Client C may also use an API such as libwebrtc to collect candidate addresses.

[0075] In Figure 17, client C sends an SDP Offer, including the successful connection method, to client A via the Signalling server 6 (S78). The successful connection method only needs to include at least the address candidate on the @office1.example.com side (srflx). The Signalling server 6 sends the SDP Offer to client A via websocket or similar.

[0076] Client A collects only the candidate addresses (srflx) of successful connection methods included in the SDP Offer (S79). Client A may also use an API such as libwebrtc to collect candidate addresses.

[0077] In Figure 18, client C obtains its NAT-translated srflx address from STUN server 4B (S80). STUN server 4B sends the srflx address to client C. In the illustrated example, the IP address of client C is as follows.

[0078] IP address (host candidate): C NAT-translated IP address (srflx candidate): C' Client A requests its NAT-translated srflx address from STUN server 4A (S80). STUN server 4A sends the NAT-translated srflx address to client A. In the illustrated example, the IP address of client A is as follows.

[0079] IP address (host candidate): A NAT translated IP address (srflx candidate): A' Then, client C sends an SDP containing ICE Candidate (C, C') to client A via the Signaling server 6 and exchanges the ICE Candidate with client A (S81). Client A sends an SDP containing ICE Candidate (A, A') to client C via the Signaling server 6 and exchanges the ICE Candidate with client C (S81).

[0080] In Figure 19, Client C and Client A perform connectivity checks on the exchanged ICE Candidates (S82).

[0081] In Figure 20, client A uses the getStats API to collect information and perform connectivity checks, and sends the successful connection method to the Signaling server 6 (S83). Client A may also send the connectivity check results (success, failure) of each ICE Candidate Peer to the Signaling server 6. Similarly, client C also sends the successful connection method to the Signaling server 6 (S83). Client C may also send the connectivity check results (success, failure) of each ICE Candidate Peer to the Signaling server 6.

[0082] The Signalling server 6 transmits the successful connection methods sent from clients A and C to the control server 1 (S84). The transmitting / receiving unit 11 of the control server 1 stores the successful connection methods as connectivity confirmation result data in the DB 14.

[0083] Figure 21 shows an example of the connectivity check result data stored in DB14 at the time shown in Figure 20. Here, result data has been added indicating that client A and client C successfully confirmed connectivity with each other using srflx address candidates.

[0084] In Figure 22, when connectivity checks are successful, a media session is established between client A and client C, and media communication is established (S85).

[0085] The operation of this embodiment will be explained below using the sequence diagrams in Figures 23 to 26. Here, NAT 7A and 7B are omitted, and Web servers 3A and 3B are referred to as Web server 3.

[0086] Figures 23 and 24 are sequence diagrams showing how client A establishes a session with client B.

[0087] In Figure 23, client A receives instructions from the user and accesses web server 3 (S101). Web server 3 issues a user ID and sends JavaScript and a control application to client A (S102). The user ID of client A shown in the figure is useraaa@office1.example.com.

[0088] Client B, like Client A, receives user instructions and accesses Web Server 3 (S103). Web Server 3 issues a user ID and sends JavaScript and a control APP to Client B (S104). The user ID for Client B shown in the diagram is userbbb@home1.example.com.

[0089] To initiate a connection with client B, client A sends its user ID (client A) and the user ID (client B) to the control server 1 via the signaling server 6 (S105, S106).

[0090] The control server 1 uses the user ID of the connecting user and the user ID of the connecting user transmitted from client A to determine whether the corresponding connectivity check result data exists in DB 14 (S107). Here, it is assumed that the relevant result data does not exist in DB 14.

[0091] In this case, the control server 1 generates a blank control signal (e.g., null) indicating that there is no result data (S108) and sends it to client A via the signaling server 6 (S109, S110).

[0092] The JavaScript of client A receives a blank control signal and sends the signal to the control app (S111). The control app does not control the ICE Agent if the control signal is blank. The JavaScript of client A sends an SDP Offer containing the control signal to client B via the Signaling server 6 (S112, S113).

[0093] The JavaScript on client B receives an SDP Offer containing a blank control signal and sends the signal to the control app (S114). The control app does not control the ICE Agent if the control signal is blank.

[0094] The JavaScript on client A instructs the ICE Agent to obtain an ICE Candidate (address candidate) (S115). The ICE Agent requests an srflx candidate from the STUN server 4A (S116) and a relay candidate from the TURN server 5A (S117).

[0095] Similarly, the JavaScript on client B instructs the ICE Agent to retrieve an ICE Candidate (S118). The ICE Agent requests an srflx candidate from the STUN server 4B (S119) and a relay candidate from the TURN server 5B (S120).

[0096] In Figure 24, the STUN server 4A sends the srflx candidate to client A (S121). The ICE Agent on client A sends the received srflx candidate to JavaScript (S122), and JavaScript sets the srflx candidate in the SDP and sends it to client B (S123).

[0097] The JavaScript on client B sends the received srflx candidate to the ICE Agent (S124). The ICE Agent on client A and the ICE Agent on client B perform connectivity checks (S125). Connectivity checks are performed as soon as the ICE Candidate peers are established. At this point, connectivity checks between host A and host B, and between srflx A and host B, are possible. Here, we assume that these two connectivity checks fail.

[0098] STUN server 4B sends the srflx candidate to client B (S126). Client B's ICE Agent sends the received srflx candidate to JavaScript (S127), and JavaScript sets the srflx candidate in the SDP and sends it to client A (S128).

[0099] The JavaScript on client A sends the received srflx candidate to the ICE Agent (S129). The ICE Agent on client A and the ICE Agent on client B perform connectivity checks (S130). At this point, connectivity checks can be performed between host A and srflx B, and between srflx A and srflx B. Here, we assume that host A - srflx B fails, and srflx A - srflx B succeeds.

[0100] Since the connectivity between srflx A and srflx B was successfully confirmed, a media session is established between client A and client B using the srflx A - srflx B connection method, and media communication is established (S131).

[0101] After media communication is established, the remaining ICE Candidates are collected and sent to the recipient, but since there are already Peers that have successfully confirmed connectivity, connectivity confirmation does not need to be performed. Specifically, TURN server 5A sends relay candidate to client A (S132). Client A's ICE Agent sends the received relay candidate to JavaScript (S133), and JavaScript sets the relay candidate in SDP and sends it to client B (S134).

[0102] Similarly, the TURN server 5B sends the relay candidate to client B (S135). The ICE Agent on client B sends the received relay candidate to JavaScript (S136), and JavaScript sets the relay candidate in the SDP and sends it to client A (S137).

[0103] The control app for client A uses the getStats API to obtain the successful connection method from the ICE Agent (S138). The control app sends the successful connection method to JavaScript (S139), and JavaScript sends the successful connection method to the control server 1 via the Signaling server 6 (S140, S141). The control server 1 stores the successful connection method as connectivity confirmation result data in DB 14 (S142).

[0104] The control app for client B uses the getStats API to obtain the successful connection method from the ICE Agent (S143). The control app sends the successful connection method to JavaScript (S144), and JavaScript sends the successful connection method to the control server 1 via the Signaling server 6 (S145, S146). The control server 1 stores the successful connection method as connectivity confirmation result data in DB 14 (S147).

[0105] Figures 25 and 26 are sequence diagrams showing how client C establishes a session with client A. Here, it is assumed that the media session between client A and client B is disconnected.

[0106] In Figure 25, client C receives user instructions and accesses web server 3 (S201). Web server 3 issues a user ID and sends JavaScript and a control application to client C (S202). The user ID of client C shown in the figure is userccc@home1.example.com.

[0107] To initiate a connection with Client A, Client C sends its own user ID (Client C) and the user ID of the destination (Client A) to the control server 1 via the Signaling server 6 (S203, S204).

[0108] The control server 1 uses the user ID of the connecting user and the user ID of the connecting user transmitted from client A to determine whether or not there is connectivity confirmation result data corresponding to DB14 (S205). Here, it is assumed that the relevant result data is in DB14.

[0109] In this case, the control server 1 generates a control signal containing the corresponding result data (S206) and transmits the control signal to the client C via the signaling server 6 (S207, S208).

[0110] The JavaScript on client C receives the control signal and sends the control signal to the control app (S209). The control app controls the ICE Agent if the control signal contains result data for a successful connection method (S210). Specifically, the control app controls the ICE Agent to collect only the srflx candidates used in the successful connection method.

[0111] The JavaScript on client C sends an SDP Offer, including the successful connection method, to client A via the Signaling server 6 (S211, S212).

[0112] The JavaScript of client A receives the SDP Offer and sends the successful connection method included in the SDP Offer to the control APP (S213). If the control APP receives a successful connection method, it controls the ICE Agent (S214). Specifically, the control APP controls the ICE Agent to collect only the srflx candidates used in the successful connection method.

[0113] The JavaScript on client C instructs the ICE Agent to retrieve an ICE Candidate (S215). Following the instructions in S210, the ICE Agent requests the srflx candidate only from the STUN server 4A (S216).

[0114] The JavaScript on client A instructs the ICE Agent to retrieve an ICE Candidate (S217). Following the instructions in S214, the ICE Agent requests the srflx candidate only from the STUN server 4A (S218).

[0115] In Figure 26, STUN server 4B sends the srflx candidate to client C (S219). Client C's ICE Agent sends the received srflx candidate to JavaScript (S220), and JavaScript sets the srflx candidate in the SDP and sends it to client A (S221). Client A's JavaScript sends the received srflx candidate to the ICE Agent (S222).

[0116] STUN server 4A sends the srflx candidate to client A (S223). Client A's ICE Agent sends the received srflx candidate to JavaScript (S224), and JavaScript sets the srflx candidate in the SDP and sends it to client C (S225). Client C's JavaScript sends the received srflx candidate to the ICE Agent (S226).

[0117] The ICE Agent of Client C and the ICE Agent of Client A perform connectivity checks (S227). Connectivity checks are performed as soon as the ICE Candidate peers are established. At this point, the connectivity check between srflx A and srflx C is performed and is considered successful.

[0118] Since the connectivity between srflx A and srflx C was successfully confirmed, a media session is established between client A and client C using the srflx A - srflx C connection method, and media communication is established (S228).

[0119] The control application of client C obtains the successful connection method from the ICE Agent using the getStats API (S229). The control application sends the successful connection method to JavaScript (S230), and JavaScript sends the successful connection method to the control server 1 via the Signaling server 6 (S231, S232). The control server 1 stores the successful connection method as connectivity confirmation result data in DB 14 (S233).

[0120] The control app for client A uses the getStats API to obtain the successful connection method from the ICE Agent (S234). The control app sends the successful connection method to JavaScript (S235), and JavaScript sends the successful connection method to the control server 1 via the Signaling server 6 (S236, S237). The control server 1 stores the successful connection method as connectivity confirmation result data in DB 14 (S238).

[0121] The control server 1 of this embodiment described above includes a DB 14 that stores connection methods for which sessions have been established in the past, a determination unit 12 that receives a connection request from a connecting client and determines whether a connection method corresponding to the connecting client and the connected client exists in the DB 14, and a generation unit 13 that, if a corresponding connection method exists in the DB 14, notifies the connecting client and the connected client of address candidates used in the connection method and causes the connecting client and the connected client to obtain only the addresses of the notified address candidates.

[0122] The control system of this embodiment comprises a control server 1 and a plurality of clients. The control server 1 includes a DB 14 that stores connection methods for which sessions have been established in the past, a determination unit 12 that receives connection requests from connecting clients and determines whether or not connection methods corresponding to the connecting client and the connected client exist in the DB 14, and a generation unit 13 that, if the corresponding connection method exists in the DB 14, notifies the connecting client and the connected client of address candidates used in the connection method. The connecting client and the connected client are equipped with a control APP 22 that obtains only the addresses of the notified address candidates.

[0123] According to this embodiment, the collection of address candidates and connectivity checks during session establishment can be streamlined, reducing the time and communication resources required to establish a session. Specifically, by utilizing the history of previously used connection methods when connecting a client, the time and communication resources required for collecting address candidates and connectivity checks can be reduced.

[0124] Furthermore, in this embodiment, the determination unit 12 of the control server 1 determines whether a connection method including the domain of the connecting client and the domain of the connecting client exists in DB 14. As a result, in this embodiment, the history of previously used connection methods can be applied not only when the same client (user) reconnects, but also when other clients with the same domain connect.

[0125] The control server 1 and clients A, B, and C described above can use a general-purpose computer system, such as the one shown in Figure 27. The illustrated computer system includes a CPU (Central Processing Unit, processor) 901, memory 902, storage 903 (HDD: Hard Disk Drive, SSD: Solid State Drive), communication device 904, input device 905, and output device 906. The memory 902 and storage 903 are storage devices. In this computer system, the functions of the control server 1 and clients A, B, and C are realized when the CPU 901 executes a predetermined program loaded onto the memory 902.

[0126] The control server 1 may be implemented on a single computer or on multiple computers. Alternatively, the control server 1 may be a virtual machine implemented on a computer. The programs for the control server 1 and clients A, B, and C can be stored on computer-readable recording media such as HDDs, SSDs, USB (Universal Serial Bus) memory, CDs (Compact Discs), and DVDs (Digital Versatile Discs), or distributed over a network. Computer-readable recording media are, for example, non-transitory recording media.

[0127] This disclosure is not limited to the embodiments described above, and numerous modifications are possible within the scope of its essence.

[0128] A, B, C: Client 1: Control Server (Control Device) 11: Transmit / Receive Unit 12: Determination Unit 13: Generation Unit (Notification Unit) 14: DB (Storage Unit) 21: JavaScript 22: Control APP 221: Transmit / Receive Unit 222: Control Unit 223: Acquisition Unit 23: ICE Agent 3, 3A, 3B: Web Server 4A, 4B: STUN Server 5A, 5B: TURN Server 5 6: Signaling Server 7A, 7B: NAT

Claims

1. A control device comprising: a storage unit that stores connection methods for which sessions have been established in the past; a determination unit that receives a connection request from a connecting client and determines whether a connection method corresponding to the connecting client and the connected client exists in the storage unit; and a notification unit that, if the corresponding connection method exists in the storage unit, notifies the connecting client and the connected client of the address candidate used in the connection method and causes the connecting client and the connected client to acquire only the address of the notified address candidate.

2. The control device according to claim 1, wherein the determination unit determines whether or not a connection scheme including the domain of the connecting client and the domain of the connecting client exists in the storage unit.

3. A control system comprising a control device and a plurality of clients, wherein the control device includes a storage unit that stores connection methods for which sessions have been established in the past, a determination unit that receives a connection request from a connecting client and determines whether a connection method corresponding to the connecting client and the connected client exists in the storage unit, and a notification unit that, if a corresponding connection method exists in the storage unit, notifies the connecting client and the connected client of the address candidate used in the connection method, and the connecting client and the connected client each include an acquisition unit that acquires only the address of the notified address candidate.

4. A control method performed by a control device, wherein the control device includes a storage unit that stores connection methods for which sessions have been established in the past, receives a connection request from a connecting client, determines whether a connection method corresponding to the connecting client and the destination client exists in the storage unit, and if the corresponding connection method exists in the storage unit, notifies the connecting client and the destination client of the address candidate used in the connection method, and causes the connecting client and the destination client to acquire only the address of the notified address candidate.

Images