JP2008205988A - Data communication system and session management server - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data communication system that is capable of increasing or decreasing the number of session management servers flexibly, without including identification information of the session management server in identification information of a communication device and is further capable of implementing data communication while distributing the message processing load in the session management server even when communication requiring shared information is executed between the session management server and the communication device. <P>SOLUTION: The data communication system includes multiple communication devices which perform data communication with each other, multiple session management servers which manages sessions of data communication between the communication devices, and a load balancer which assigns the session management servers for processing a message received from the communication device according to a predetermined criterion, wherein, the session management server is provided with a unit for managing a currently logged-in communication device and a state of the communication performed by the communication device, and a unit for acquiring information necessary for performing communication with the communication device. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a data communication method and system, and more particularly to a data communication method and system that enables data communication between communication devices using a session management server device.

  When performing data communication between two entities (for example, a device or a process embodied by executing software on a device), data communication such as enabling or disconnecting the data communication is possible. In order to perform control, a communication protocol for control independent of data communication may be used. For example, in IP telephones, a protocol called SIP (Session Initiation Protocol) is widely used as a control communication protocol (refer to Non-Patent Document 1 for details of SIP).

  Hereinafter, in SIP, the operation when the first communication device establishes a communication session (hereinafter also simply referred to as a session) with the second communication device using the session management server and enables data communication. Is briefly explained.

  First, prior to the communication session establishment process, the first communication device registers the IP address of the communication device in the session management server. That is, the communication device has a registration request message (which also includes an identifier (also called SIP-URI) for uniquely identifying the communication device or the user of the communication device in the session management server, and the IP address of the communication device). (Also called REGISTER message) to the session management server. The session management server records the identifier described in the registration request message in association with the IP address.

  Note that the association between the identifier of a certain communication device and the IP address recorded in the session management server is deleted when the validity period set when the association is recorded elapses. It can also be deleted by transmitting a registration deletion request message (for example, instructing the association validity period to be set to 0 in the REGISTER message) from the communication device.

  Also, in this specification, a state where an identifier and an IP address of a certain communication device (entity) are recorded in association with the session management server is also referred to as that the communication device is logged in to the session management server, The state that is not recorded is also referred to as the communication device logging out from the session management server.

  By logging in, the session management server can transmit an INVITE message (described later) received from the connection source communication device to the connection destination communication device. Conversely, the connection destination communication device can receive an INVITE message or the like from the session management server.

  Similarly, the second communication device also logs in to the session management server prior to session establishment processing.

  Next, the first communication device performs processing for establishing a session with the second communication device.

  That is, the first communication device transmits a session establishment request message (hereinafter also referred to as an INVITE message) requesting the session management server to establish a session with the second communication device. In the INVITE message, the identifier of the first communication device and the identifier of the second communication device are described. The session management server that has received the INVITE message transmits the INVITE message to the second communication device. When receiving the session establishment request, the second communication device that has received the INVITE message transmits a response message (also referred to as a 200OK message) to that effect to the session management server. The session management server returns the response message to the first communication device. When the first communication device receives the response message, a communication session is established with the second communication device.

  The above is the operation when the first communication device establishes a session with the second communication device using the session management server and enables data communication in SIP.

  When a message is received from a communication device, the session management server processes the message while appropriately updating information such as which communication device is currently logged in and the communication status between arbitrary communication devices. The communication state is also called a call state, indicating communication, communication establishment processing, communication disconnection processing, and the like. For this reason, the load on the session management server increases as the number of communication devices logged in to the session management server increases.

  Therefore, as described in Non-Patent Document 1, multiple session management servers that have a function to control a communication session between two communication devices are linked together and managed using a single session management server. A method of reducing the load on the session management server by reducing the number of communication devices is known. That is, the first communication device is logged in to the first session management server and the second communication device is logged in to the second session management server. First, the first communication device transmits the INVITE message to the first session management server. The first session management server that has received the INVITE message transfers the INVITE message to the second session management server. The second session management server transfers the INVITE message to the second communication device. Similarly, the second communication device transmits the response message to the second session management server. The second session management server that has received the response message transfers the response message to the first session management server. The first session management server transfers the response message to the first communication device.

  In addition, when using the function described in Non-Patent Document 1 that links multiple session management servers, the SIP-URI of the communication device is information indicating which session management server the communication device is managed by Is included. For example, in the case of a SIP-URI of “USER1@SIPSERVER1.HITACHI.COM”, it is common that “SIPSERVER1.HITACHI.COM” is information (usually called a domain) that identifies the session management server. . The session management server manages a table that associates the identification information of other session management servers with which the session management server is associated with the IP address of the session management server, and determines a session management server that transmits a message.

  Alternatively, there is a method for distributing the load of the session management server using a plurality of session management servers and a load distribution device that distributes messages from the communication devices according to predetermined criteria.

  For example, Patent Document 1 discloses a method in which a call state is stored in a database that can be read and written from a plurality of session management servers, and an available server among the plurality of servers performs processing.

  Non-Patent Document 1 describes that an encrypted communication protocol such as TLS or S / MIME is used in order to prevent eavesdropping or falsification of communication data between the session management server and the communication device.

Japanese Patent No. 3730545 IETF, RFC3261: SIP: Session Initiation Protocol, [searched on November 29, 2005], Internet <URL: http://www.ietf.org/rfc/rfc3261.txt>

Today, there are many cases where it is desired to describe the organization to which the communication device belongs rather than the identification information of the session management server in the domain. That is, there is a demand for communication devices belonging to the same organization to be in the same domain, such as “USER1@HITACHI.COM” or “USER2@HITACHI.COM”. In this way, the organization to which the communication device belongs can be uniquely identified simply by confirming the domain name of the communication device.
However, when load sharing is performed using a function that links multiple session management servers, the SIP-URI domain of the communication device must contain identification information for identifying the session management server Therefore, there is a problem that the above requirement cannot be realized.

  Also, when performing load distribution using a function that links multiple session management servers, the administrator assigns a SIP-URI once to the communication device, such as by initial setting of the communication management device. If this happens, there is a problem that the session management server for logging in cannot be changed without changing the settings of the communication device. For this reason, for example, in a system that has been operated with 10 session management servers, the number of communication devices has been reduced, so that the operation effort of reducing the number of session management servers to 8 becomes large.

  In the load distribution method described in Patent Document 1, there is no such problem because the load distribution apparatus dynamically selects a session management server that processes the message and distributes the message for each message of the communication apparatus. .

  However, in the load balancing method described in Patent Document 1, when TLS communication is used between a session management server and a communication device, a communication device communicates with the session management server that processed the REGISTER message of the communication device. Holds a communication session. For this reason, for example, if the session management server that received the INVITE message requesting communication with the second communication device from the first communication device was not the session management server that processed the REGISTER message of the second communication device Has a problem that it cannot communicate with the second communication device.

  The holding of the communication session means, for example, that both the data transmission source and the reception source share the state of how much data has been transmitted and received. Therefore, what has the above-mentioned problems includes not only TLS but also connection-type communication in which communication is performed while checking whether data has arrived during data transmission, as represented by TCP.

  Therefore, the load distribution method described in Patent Document 1 has a problem that it is difficult to achieve both reliable communication and safe communication.

  The present invention provides a data communication system capable of distributing the processing load of a session management server without including the identification information of the session management server in the identification information of the communication device.

  The present invention also provides a data communication system that can flexibly increase or decrease the number of session management servers.

  Furthermore, the present invention provides data that can realize data communication while distributing the message processing load on the session management server even when communication requiring shared information is performed between the session management server and the communication device. A communication system is provided.

  Specifically, the present invention relates to a plurality of communication devices that perform data communication with each other, a plurality of session management servers that manage a data communication session between the communication devices, and a communication device according to a predetermined standard. Means for managing a currently logged-in communication device and a state of communication performed by the communication device in a data communication system comprising a load distribution device that distributes a session management server that processes messages received from The session management server is provided with means for acquiring information necessary for communicating with the communication device.

  The information necessary for communicating with the communication device corresponds to information related to a session management server that manages the communication device and shared information for holding a communication session with the communication device.

  More specifically, the data communication system provided by the present invention includes a plurality of session management servers for managing a data communication session between the communication devices, and the communication device 1 to the communication device according to a predetermined standard. 2, a communication message that does not include information specifying the session management server that manages the communication device 2, and distributes the communication message to any one of the session management servers; A data communication system for managing data communication between a plurality of communication devices, comprising: a session management server that has received a communication message; and means for acquiring information necessary for communicating with the communication device 2 It is.

  Further, the information necessary for communicating with the communication device 2 may be identification information for specifying the session management server to which the communication device 2 is logged in.

  Further, the means for acquiring information necessary for communicating with the communication device 2 indicates whether or not the communication device 2 is logged in, whether the session management server that has received the session establishment request message is another session management server. And means for responding to the session management server that has received the session establishment request message that the session management server to which the communication device 2 is logged in is informed that the communication device 2 is logged in. But you can.

  The means for acquiring information necessary for communicating with the communication device 2 is an identification for specifying a session management server that can be accessed by the plurality of session management servers and to which the communication device is logged in. A shared database in which information is recorded, and a session management server that has received the session establishment request message may include means for searching the shared database.

  The communication message may be a session establishment request message or a session establishment response message.

  Further, the information necessary for communicating with the communication device 2 is an encrypted communication setting used when communicating with the communication device 2, and the information necessary for communicating with the communication device 2 is acquired. The means records the encrypted communication settings used when communicating with the communication device 2, the shared database accessible by the plurality of session management servers, and the session management server receiving the session establishment request message, Means for searching a shared database.

  The communication message may be a call information search request message or a call information search response message.

  The identification information for identifying the session management server may be a domain name, host name, IP address, URI, or the like.

  According to the above aspect, since the session management server to which the communication device logs in is selected by the load balancer when the communication device transmits the REGISTER message, the SIP-URI domain of the communication device includes the session management server. Not only the identification information but also the organization information can be described, and at the same time, the number of session management servers can be increased or decreased according to the number of communication devices.

  Further, according to the above aspect, since the session management server acquires information necessary for communicating with the communication device that is the message transmission destination and transmits the message, shared information is shared between the session management server and the communication device. Data communication can be realized while distributing the message processing load on the session management server, even when communication is required.

  According to the present invention, it is possible to provide a load distribution method capable of achieving both reliable communication and safe communication.

  In addition, load balancing is possible even when multiple SIP servers belonging to the same domain are used.

  Embodiments of the present invention will be described below with reference to the drawings. Note that the present invention is not limited to these embodiments.

  In the following, an example of application to SIP will be described. In addition to SIP, the present invention is applicable to a system that transmits and receives a session establishment request message and a response message via a session management server when a communication session is established. Is applicable.

  Furthermore, each device in each of the following embodiments includes, for example, a processor (CPU) 91, various software (programs) executed by the processor 91, and a memory for storing data, as shown in FIG. 92 and / or hard disk 93, network interface 94 for connecting to network 0 (LAN1, LAN2), input device such as a mouse and keyboard, a display device, and an input / output device 95 including a read / write device for an external storage medium; These components are realized on a general electronic computer interconnected by an internal communication line (called a bus) 16 such as a bus.

  That is, the processing unit and the processing included in each device in each of the following embodiments are realized by the processor 91 executing a necessary program stored in the hard disk 93 or the memory 92 in each device at a necessary timing. The These programs may be stored in advance in the hard disk 93 or the memory 92 of each device, and when necessary, the program is introduced from the other device into the storage unit via a medium that can be used by the device. Also good. The medium refers to, for example, a removable storage medium that can be used by the input / output device 95 or a communication medium that can be used via the network interface 94 (that is, a network or a carrier wave or digital signal that propagates through the network). Further, each of the above-described processing units can be configured as hardware such as an integrated circuit.

  In addition, identifiers such as domain names, URLs, URIs, IP addresses and the like used in the following embodiments are fictitious used for explanation and do not matter even if they exist.

  First, the first embodiment will be described with reference to FIGS.

  FIG. 1 is a diagram showing a system configuration in the first embodiment.

  The system shown here is a session management server device, three SIP servers (SIP server 11, SIP server 12, SIP server 13), load balancer 30, and data communication with services used by users Communication device (referred to as user terminal) 51 and a communication device 52 that provides services. Three SIP servers and the load balancer 30 are connected via the LAN 1 and further load balanced. The device 30, the communication device 51, and the communication device 52 are connected via the network 0.

  The SIP server 11 is assigned an IP address of 192.168.10.11. The registrar DB 21 for managing the communication device logged in to the SIP server 11 and the communication session information managed by the SIP server 11 And a call information DB 41 for management. The software structure of the SIP server 11 includes a network interface card (NIC) control unit 101 for communicating with other SIP servers and the load balancer 30 via the LAN 1, a SIP message processing unit 102 for processing SIP messages, A registrar processing unit 103 that controls processing to the registrar DB 21, a session control unit 104 that controls processing to the call information DB 41, a SIP server search unit 105 that searches for a SIP server to which a certain communication management device is logged in, Consists of.

  The SIP server 12 is assigned an IP address of 192.168.10.12. The registrar DB 22 for managing the communication device logged in to the SIP server 12 and the communication session information managed by the SIP server 12 are provided. It has a call information DB 42 for management, and has a software structure similar to that of the SIP server 11. Furthermore, the SIP server 13 is assigned an IP address of 192.168.10.13, and the registrar DB 23 for managing the communication device logged in to the SIP server 13 and the communication session information managed by the SIP server 13 are stored. It has a call information DB 43 for management, and has a software structure similar to that of the SIP server 11.

  The load balancer 30 is a device having a function of centrally receiving messages from communication devices via the network 0 and transferring the messages to the SIP server, and is assigned an IP address of 192.168.10.1. Note that the load balancer 30 used in the present embodiment has a function of transferring a message to the SIP server that transferred the message immediately before when the message is received from the same communication device within a predetermined period. ing.

  Furthermore, the communication device 51 is assigned an IP address of 192.168.20.11 and a SIP-URI of user@hitachi.com. The software structure of the communication device 51 includes a network interface card (NIC) control unit 511 for communicating with the load balancer 30 and the communication device 52 via the network 0, a SIP message processing unit 512 for processing SIP messages, And a service communication device processing unit 513 that enjoys a service provided by the communication device 52.

  The communication device 52 is assigned an IP address of 192.168.30.11 and a SIP-URI of service@hitachi.com. The software structure of the communication device 52 includes a network interface card (NIC) control unit 521 for communicating with the load balancer 30 and the communication device 51 via the network 0, a SIP message processing unit 522 for processing SIP messages, And a service communication device processing unit 523 that provides a service to the communication device 51.

  Hereinafter, the first embodiment will be described with reference to a communication procedure when the communication device 51 shown in FIG. 1 performs data communication with the communication device 52 as an example.

  3 and 4 are sequence diagrams showing data communication according to the first embodiment.

  First, in the first embodiment, the communication device 51 and the communication device 52 perform login processing to the SIP server.

  FIG. 3 is a diagram showing a sequence when the communication device 51 and the communication device 52 perform login processing to the SIP server.

  First, in FIG. 3, the communication device 52 performs a login process to the SIP server.

That is, the communication device 52 negotiates TLS communication with the SIP server via the load balancer 30 (S1). At this time, when the load balancer 30 that has received a message requesting the negotiation of TLS communication from the communication device 52 selects a SIP server to transfer the message from among the three SIP servers, the message is transferred to the selected SIP server. To do. In FIG. 3, the SIP server 13 is selected, and TLS communication is established between the communication device 52 and the SIP server 13.
In TLS communication, the communication device 52 and the SIP server 13 periodically transmit a message for confirming that the communication session is not disconnected. For this reason, the load balancer 30 always transfers a message from the communication device 52 to the SIP server 13 while TLS communication is established between the communication device 52 and the SIP server 13.

  Next, in order to request location registration, the communication device 52 transmits a REGISTER message in the SIP message to the load balancer 30 (S2). The load balancer 30 that has received the REGISTER message transfers the message to the SIP server 13 (S3).

  The SIP server 13 that has received the REGISTER message, the registrar processing unit 103 sends the request source SIP-URI (service@hitachi.com) indicated by the From header of the received REGISTER message and the request source IP address indicated by the Contact header to the registrar DB 23 ( When the location data indicating the relationship with 192.168.30.11) is registered, the SIP message processing unit 102 transmits a SIP response message addressed to the communication device 52 in order to notify the success of the location registration (S4).

  The load balancer 30 that has received the SIP response message transmits the message to the communication device 52 (S5).

  Thus, the login to the SIP server of the communication device 52 is completed, and the communication device 52 waits for a service provision request from the communication device 51.

  Subsequently, in the present embodiment, the communication device 51 performs login processing to the SIP server.

  That is, the communication device 51 negotiates TLS communication with the SIP server via the load balancer 30 (S6). At this time, when the load balancer 30 that has received a message requesting the negotiation of TLS communication from the communication device 51 selects a SIP server to transfer the message from among the three SIP servers, the message is transferred to the selected SIP server. To do. In FIG. 3, the SIP server 11 is selected, and TLS communication is established between the communication device 51 and the SIP server 11. Thereafter, while the TLS communication is established between the communication device 51 and the SIP server 11, the load balancer 30 always transfers a message from the communication device 51 to the SIP server 11.

  Next, the communication device 51 transmits a REGISTER message to the load balancer 30 in order to request location registration (S7). The load balancer 30 that has received the REGISTER message transfers the message to the SIP server 11 (S8).

  In the SIP server 11 that has received the REGISTER message, the registrar processing unit 103 sends to the registrar DB 21 the request source SIP-URI (user@hitachi.com) indicated by the From header of the received REGISTER message and the request source IP address indicated by the Contact header ( When the location data indicating the relationship with 192.168.20.11) is registered, the SIP message processing unit 102 transmits a SIP response message addressed to the communication device 51 in order to notify the success of the location registration (S9).

  The load balancer 30 that has received the SIP response message transmits the message to the communication device 51 (S10).

  This completes the login to the SIP server of the communication device 51.

  The communication device 51 that has completed the login process requests the communication device 52 to provide a service.

  FIG. 4 is a diagram illustrating a sequence in the case where the communication device 51 that has completed the login process receives service from the communication device 52.

  First, when the communication device 51 receives a service from the communication device 52, the communication device 51 transmits an INVITE message (S11), and the load balancer 30 establishes a SIP server with which the TLS communication is established with the communication device 51. The INVITE message is transferred to 11 (S12).

  The SIP server 11 that has received the INVITE message processes the INVITE message according to the processing flow shown in FIG.

  That is, in the SIP server 11, the registrar processing unit 103 accesses the registrar DB 21 and searches for the IP address of the recipient SIP-URI indicated by the To header of the received INVITE message (step 1001).

  Here, when the corresponding IP address can be retrieved from the registrar DB 21, the process proceeds to step 1007, where the session management unit 104 of the SIP server 11 determines the communication session identification information indicated by the Call-ID header of the INVITE message. , It records in the call information DB 41 that the communication session is in the state of “establishing process (waiting for response from recipient)”.

  Next, an INVITE message is transmitted to the searched IP address (step 1008). At this time, the SIP server 11 adds the identification information of the SIP server 11 to the Via header of the INVITE message.

  On the other hand, if the corresponding IP address cannot be retrieved from the registrar DB 21 in step 1001, the SIP server retrieval unit 105 retrieves the SIP server that manages the communication device indicated by the SIP-URI. A search request message 81 is created, and the SIP server search request message 81 is transmitted to the LAN 1 by broadcast communication (steps 1003 and S13).

  As shown in FIG. 6, the SIP server search request message 81 of the present embodiment is described as a command line including the search target SIP-URI (in FIG. 6, “SEARCH_REQUEST sip: service@hitachi.com” This means that the SIP server managing the communication device having the SIP-URI service@hitachi.com is searched).

  On the other hand, the SIP server that has received the SIP server search request message 81 processes the SIP server search request message 81 according to the processing flow shown in FIG.

  That is, when the SIP server receives the SIP server search request message 81 in step 1011, the registrar processing unit 103 accesses the registrar DB, and the IP address of the SIP-URI indicated by the command line of the SIP server search request message 81 Is searched (step 1012).

  Here, if the corresponding IP address cannot be retrieved from the registrar DB 21, the processing is terminated as it is.

  On the other hand, when the corresponding IP address can be searched from the registrar DB 21, the SIP server search unit 105 creates a SIP server search response message 82 and sends the message to the destination indicated by the source line of the SIP server search request message 81. (Step 1014).

  As shown in FIG. 6, the SIP server search response message 82 of the present embodiment is described as a command line indicating the search result of the search target SIP-URI (in FIG. 6, “SEARCH_RESULT SUCCESS” is described. And identification information for identifying the SIP server that manages the search target SIP-URI ("IP_ADDRESS: 192.168.10.13" in Fig. 6). This means that the IP address of the SIP server that manages the search target SIP-URI is 192.168.10.13).

  In FIG. 4, since the communication device 52 is logged in to the SIP server 13, the SIP server 13 transmits a SIP server search response message 82 to the SIP server 11 (S14).

  The SIP server 11 that has received the SIP server search response message 82 refers to the message and acquires the IP address of the SIP server that manages the communication device (step 1005).

  In the SIP server 11, the acquired IP address is an appropriate address as the IP address of the SIP server (for example, when the SIP server locally manages a list of IP addresses of all SIP servers, the IP address is (Step 1006), the session management unit 104 of the SIP server 11 determines that the communication session identification information indicated by the Call-ID header of the INVITE message The call information DB 41 indicates that the SIP-URI of the transmission source of the INVITE message, the SIP-URI of the transmission destination of the INVITE message, and that the communication session is in the “establishing process (waiting for response from the reception destination)” state. To record.

  Next, the IP address acquired from the SIP server search response message 82, that is, the INVITE message is transmitted to the SIP server 13 in FIG. 4 (steps 1008 and S15). At this time, the SIP server 11 adds the identification information of the SIP server 11 to the Via header of the INVITE message.

  The SIP server 13 that has received the INVITE message processes the INVITE message according to the processing flow shown in FIG.

  That is, in step 1001, the registrar processing unit 103 accesses the registrar DB 23 to search for the IP address of the recipient SIP-URI indicated by the To header of the received INVITE message.

  Here, since the SIP server 13 is a SIP server to which the communication device 52 is logged in, the corresponding IP address can be searched from the registrar DB 23.

  Therefore, the SIP server 13 transitions to step 1007, and the session management unit 104 of the SIP server 13 determines that the communication session identification information indicated by the Call-ID header of the INVITE message, the communication source identification information indicated by the From message, When the identification information of the communication destination indicated by the To message and that the communication session is in the state of “establishing processing (waiting for response from the reception destination)” are recorded in the call information DB 41, the IP address retrieved from the registrar DB23, that is, An INVITE message is transmitted to the communication device 52 via the load balancer 30 (steps 1008, S16, S17). At this time, the SIP server 13 adds the identification information of the SIP server 13 to the Via header of the INVITE message.

  Upon receiving the INVITE message, the communication device 52 checks whether the SIP message processing unit 523 can accept the communication requested by the message, and creates the inspection result as a SIP response message. (S18). The load balancer 30 transmits the message to the SIP server 13 (S19).

  In the SIP server 13 that has received the SIP response message, the SIP message processing unit 102 confirms the content of the message, and if it is “communication permitted”, the session management unit 104 accesses the call information DB 43 to call the message. -Update the status of the communication session indicated by the ID header to the “connected” status.

  On the other hand, if “communication refused”, the session management unit 104 accesses the call information DB 43 and deletes the entry related to the communication session indicated by the Call-ID header of the message.

  Next, the SIP server 13 confirms the Via header of the SIP response message and transmits the message to the SIP server 11 (S20).

  The SIP server 11 that has received the SIP response message, similar to the SIP server 13, when the SIP message processing unit 102 updates the call information DB 41 according to the content of the message, sends the SIP response to the communication device 51 via the load balancer 30. A message is transmitted (S21, S22).

  In the communication device 51 that has received the SIP response message, the SIP message processing unit 512 confirms the content of the message, and if it is “communication permitted”, the service communication device processing unit 513 is connected to the service server processing unit 523 of the communication device 52. Conduct data communication (S23) and enjoy the service.

  When the use of the service is terminated, the communication device 51 transmits a BYE message to the load balancer 30 (S24). The load balancer 30 that has received the BYE message transmits the message to the SIP server 11 (S25).

  The SIP server 11 that has received the BYE message processes the message according to the processing flow of FIG. As a result, the SIP server 11 broadcasts the SIP server search request message 81 in step 1004 (S26), and receives the SIP server search response message 82 from the SIP server 13 (S27). In step 1007, the session management unit 104 accesses the call information DB 41 and updates the state of the communication session indicated by the Call-ID header of the BYE message to “communication disconnection (waiting for response from the reception destination)”. Further, the SIP server 11 transmits the BYE message to the SIP server 13 in step 1008 (S28). At this time, the SIP server 11 adds the identification information of the SIP server 11 to the Via header of the BYE message.

  Next, the SIP server 13 that has received the BYE message also processes the message according to the processing flow of FIG. As a result, in step 1007, the SIP server 13 causes the session management unit 104 to access the call information DB 43, and sets the communication session status indicated by the Call-ID header of the BYE message to “Communication disconnected (waiting for response from recipient). ) ".

  Further, in step 1008, the SIP server 13 transmits the BYE message to the communication device 52 via the load balancer 30 (S29, S30). At this time, the SIP server 13 adds the identification information of the SIP server 13 to the Via header of the BYE message.

  In the communication device 52 that has received the BYE message, the SIP message processing unit 523 performs a communication disconnection process requested by the message, and transmits a SIP response message to the load balancer 30 (S31). The load balancer 30 transmits the message to the SIP server 13 (S32).

  In the SIP server 13 that has received the SIP response message, the session management unit 104 accesses the call information DB 43 and deletes the entry related to the communication session indicated by the Call-ID header of the message.

  Next, the SIP server 13 confirms the Via header of the SIP response message and transmits the message to the SIP server 11 (S33).

  The SIP server 11 that has received the SIP response message, similar to the SIP server 13, when the SIP message processing unit 102 updates the call information DB 41 according to the content of the message, sends the SIP response to the communication device 51 via the load balancer 30. A message is transmitted (S34, S35).

  If the SIP server search response message 82 does not return even after a predetermined period in step 1004 in FIG. 5, or the sender of the message cannot be acquired from the SIP server search response message 82 in step 1006 in FIG. In this case, the SIP server transits to step 1009, and the SIP message processing unit 102 creates a SIP response message indicating the occurrence of an error, and returns it to the sender of the SIP message. For example, such a state occurs when the communication device 51 transmits an INVITE message to the communication device 52 after the communication device 52 has logged out.

  The above is the operation when the communication device 51 that has completed the login process receives the service from the communication device 52 in this embodiment.

  In the first embodiment, the call information is managed by the session management server and does not have to have a shared database.

  On the other hand, in the load distribution method described in Patent Document 1, the shared database is updated every time one message is processed. For this reason, there is a problem that a high-speed communication means is required between the shared database having very high processing performance and the session management server and the shared database. Further, the load distribution method described in Patent Document 1 has a problem that the state of the shared database cannot be uniquely determined when a plurality of session management servers simultaneously control the same call information.

  That is, according to the present embodiment, a high-performance shared database and a high-speed communication means between the shared database and the session management server are not required, and the state of the shared database cannot be uniquely determined. There is an effect that the state does not occur.

  In the first embodiment, the IP address is used as identification information for specifying the SIP server described in the SIP server search response message 82, but the present invention is not limited to this. As identification information for specifying a SIP server, a combination of an IP address and a port number, a domain name, a host name, a URI, a MAC address, or the like may be used instead of an IP address.

  In the first embodiment, the SIP server search message is broadcast to the LAN 1 in order to search for the communication device that is the destination of the INVITE message or BYE message. However, the present invention is not limited to this. The LAN1 administrator may set multicast communication that reaches a plurality of SIP servers, and the SIP server may transmit a SIP server search message using the multicast communication. In other words, when a special IP address is used as the IP address for multicast and the LAN1 administrator receives a packet addressed to the IP address, the router in LAN1 is set to forward the packet to multiple SIP servers. May be.

  By doing so, the network load of LAN1 can be reduced as compared with the case of using broadcast communication. Alternatively, the SIP server may manage the IP addresses of other SIP servers, and individually send a SIP server search message to each SIP server. In this way, load distribution can be performed among SIP servers belonging to different subdomains.

  In the first embodiment, the communication device 51 starts the communication disconnection process, but the present invention is not limited to this. The disconnection process may be executed from the communication device 52.

  Next, a second embodiment will be described with reference to FIGS.

  In the first embodiment described above, the SIP server search unit 105 broadcasts the SIP server search request message 81 and receives the SIP server search request message 81 in order to acquire information on the SIP server that manages the communication device. The SIP server searches its own registrar DB, and the SIP server that has succeeded in the search responds with a SIP server search response message 82.

  The second embodiment is characterized in that a management DB is provided for managing which SIP server is logged in by a communication device that is accessible from the SIP server and that is currently logged in.

  FIG. 8 is a diagram showing a system configuration in the second embodiment.

  The system shown here includes three SIP servers (SIP server 11, SIP server 12, and SIP server 13) that are session management servers, a load balancer 30, and a management DB 40 that is a feature of this embodiment. A communication device (also referred to as a user terminal) 51 used by a user to perform data communication with a service, and a communication device 52 that provides a service. The three SIP servers and the load balancer 30 are Connected via LAN1, 3 SIP servers and management DB40 are connected via LAN2, and load balancer 30, communication device 51, and communication device 52 are connected via network 0 Has been.

  The management DB 40 is an information processing apparatus having the hardware configuration shown in FIG.

  The SIP server 11 is assigned an IP address of 192.168.10.11. The registrar DB 21 for managing the communication device logged in to the SIP server 11 and the communication session information managed by the SIP server 11 And a call information DB 41 for management. The software structure of the SIP server 11 includes a network interface card (NIC) control unit 101 for communicating with other SIP servers and the load balancer 30 via the LAN 1, a SIP message processing unit 102 for processing SIP messages, A registrar processing unit 103 that controls processing to the registrar DB 21, a session control unit 104 that controls processing to the call information DB 41, a SIP server search unit 105 that searches for a SIP server to which a certain communication management device is logged in, Consists of.

  The SIP server 12 is assigned an IP address of 192.168.10.12. The registrar DB 22 for managing the communication device logged in to the SIP server 12 and the communication session information managed by the SIP server 12 are provided. It has a call information DB 42 for management, and has a software structure similar to that of the SIP server 11. Furthermore, the SIP server 13 is assigned an IP address of 192.168.10.13, and the registrar DB 23 for managing the communication device logged in to the SIP server 13 and the communication session information managed by the SIP server 13 are stored. It has a call information DB 43 for management, and has a software structure similar to that of the SIP server 11.

  The load balancer 30 is a device having a function of centrally receiving messages from communication devices via the network 0 and transferring the messages to the SIP server, and is assigned an IP address of 192.168.10.1. Note that the load balancer 30 used in the embodiment has a function of transferring a message to the SIP server that transferred the message immediately before when the message is received from the same communication device within a predetermined period. Yes.

  Furthermore, the communication device 51 is assigned an IP address of 192.168.20.11 and a SIP-URI of user@hitachi.com. The software structure of the communication device 51 includes a network interface card (NIC) control unit 511 for communicating with the load balancer 30 and the communication device 52 via the network 0, a SIP message processing unit 512 for processing SIP messages, And a service communication device processing unit 513 that enjoys a service provided by the communication device 52.

  The communication device 52 is assigned an IP address of 192.168.30.11 and a SIP-URI of service@hitachi.com. The software structure of the communication device 52 includes a network interface card (NIC) control unit 521 for communicating with the load balancer 30 and the communication device 51 via the network 0, a SIP message processing unit 522 for processing SIP messages, And a service communication device processing unit 523 that provides a service to the communication device 51.

  Hereinafter, the second embodiment will be described by taking a communication procedure when the communication device 51 shown in FIG. 8 performs data communication with the communication device 52 as an example.

  9 and 10 are sequence diagrams showing data communication according to the second embodiment. Description of steps and messages described in the first embodiment indicated by the same reference numerals as those in FIGS. 3 and 4 is omitted as much as possible.

  First, also in the second embodiment, the communication device 51 and the communication device 52 perform login processing to the SIP server.

  FIG. 9 is a diagram showing a sequence when the communication device 51 and the communication device 52 perform login processing to the SIP server.

  Also in the present embodiment, after establishing the TLS communication with the SIP server 13, the communication device 52 transmits a REGISTER message and requests login processing (S1 to S3, S6 to S8).

  At this time, the SIP server 13 processes the REGISTER message according to the processing flow shown in FIG. That is, the SIP server 13 that has received the REGISTER message transmits a SIP server search request message 81 to the management DB 40 (S301 in FIG. 9) in step 2001, and the communication device that has transmitted the REGISTER message to the management DB 40, that is, communication It is searched whether the SIP-URI of the device 52 has already been registered. When the SIP server search response message 82 is received from the management DB 40 (S302 in FIG. 9) and the SIP-URI of the communication device 52 has already been registered in the management DB 40, the SIP server 13 passes through the load balancer 30. The SIP response message indicating an error is transmitted to the communication device 52 (step 2110).

  In this embodiment, when the search target SIP-URI is not yet registered, the command line of the SIP server search response message 82 is described as “SEARCH_RESULT FAILURE” to indicate that the search has failed.

  On the other hand, if the SIP-URI of the communication device 52 has not been registered in the management DB 40, the SIP server 13 associates and stores the SIP-URI and IP address of the communication device 52 in the registrar DB 23 in step 2103.

  Next, in step 2104, the SIP server 13 sends a SIP server registration request message 83 (S303 in FIG. 9), and the SIP-URI of the communication device 52 and the SIP server to which the communication device 52 is logged in to the management DB 40. That is, the information of the SIP server 13 is registered in association with each other.

  As shown in FIG. 6, the SIP server registration request message 83 of this embodiment is described as a command line including the SIP-URI to be registered (“REGISTER_REQUEST sip: service@hitachi.com” in FIG. 6). However, this means requesting registration of the SIP-URI service@hitachi.com) and information on the SIP server that manages the SIP-URI to be registered ("CONTACT: 192.168." In Fig. 6). 10.13: 5060 / UDP ”, which means that the IP address of the SIP server that manages the search target SIP-URI is 192.168.10.13, and that UDP 5060 port is waiting for communication. ).

  Next, when the SIP server 13 receives the SIP server registration response message 82 from the management DB 40 (S304 in FIG. 9), the SIP server 13 transmits a SIP response message indicating login success to the communication device 52 via the load balancer 30. (Step 2105).

  As shown in FIG. 6, the SIP server registration response message 84 of this embodiment is described as a command line including the registration result of the registration target SIP-URI (“REGISTER_RESULT SUCCESS” in FIG. 6). Indicates that the registration was successful), and a line indicating the SIP-URI to be registered (shown as “SIP-URI: sip: service@hitachi.com” in FIG. 6). .

  Thus, the login of the communication device 52 is completed.

  The communication device 51 also performs login in the same manner.

  Next, the communication device 51 that has completed the login process requests the communication device 52 to provide a service.

  FIG. 10 is a diagram illustrating a sequence in the case where the communication apparatus 51 that has completed the login process receives service from the communication apparatus 52.

  The SIP server 11 that has received the INVITE message from the communication device 51 via the load balancer 30 in the sequence of S11 to S12 in FIG. 10 processes the INVITE message according to the processing flow shown in FIG.

  That is, the SIP server 11 first determines whether or not the system uses connection-type communication for communication between the communication device and the SIP server (step 2000).

  If connection-type communication is used, step 2006 and subsequent steps are executed.

  On the other hand, if connection-type communication is not used, the process proceeds to step 2001 to search for whether the SIP-URI of the sender of the INVITE message (communication device 51 in FIG. 10) is registered in the registrar DB21. To do.

  Here, when the SIP-URI of the sender of the INVITE message is registered, step 2006 and subsequent steps are executed.

  On the other hand, if the SIP-URI of the sender of the INVITE message is not registered, the process proceeds to step 2003, the SIP server search request message 81 is sent to the management DB 40, and the sender of the INVITE message logs in. Search for existing SIP servers. As a result, if there is no SIP server to which the sender of the INVITE message is logged in, the process proceeds to step 2020, and a SIP response message indicating an error is transmitted to the sender of the INVITE message.

On the other hand, if there is a SIP server to which the sender of the INVITE message is logged in, it is confirmed whether information about the SIP server exists in the Via header of the INVITE message (step 2005). In step 2005, if there is no information about the SIP server to which the sender of the INVITE message is logged in in the Via header of the INVITE message, the SIP server 11 determines that the SIP to which the sender of the INVITE message is logged in. Send an INVITE message to the server. (At this time, the SIP server 11 does not have to include the information of the SIP server 11 in the Via header of the INVITE message.)
On the other hand, if information on the SIP server to which the sender of the INVITE message is logged in exists in the Via header of the INVITE message in step 2005, the SIP server 11 executes step 2006 and subsequent steps.

  When using a non-connection type communication, when a communication device sends an INVITE message, the load balancer 30 may transfer the INVITE message to a SIP server to which the communication device is not logged in. However, by performing the processing from step 2001 to step 2005, the INVITE message can be transmitted to the SIP server to which the communication device is logged in, and the call information DB of the SIP server to which the communication device is logged in is stored. It can be updated correctly.

  In this embodiment, since the TLS communication used for communication between the SIP server and the communication device is connection-type communication, the process proceeds to step 2006 in step 2000.

  In step 2006, the SIP server 11 searches the registrar DB 21 for the SIP-URI of the recipient of the INVITE message (communication device 52 in FIG. 10).

  Here, when the SIP-URI of the recipient of the INVITE message is registered in the registrar DB 21, the SIP server 11 causes the session management unit 104 to identify the communication session identification information indicated by the Call-ID header of the INVITE message, Record in the call information DB 41 that the communication source identification information indicated by the From message, the communication destination identification information indicated by the To message, and that the communication session is in the "establishing process (waiting for response from the reception destination)" status (Step 2010) and an INVITE message is transmitted to the IP address associated with the SIP-URI (Step 2011). At this time, the SIP server 11 includes the information of the SIP server 11 in the Via header of the INIVTE message.

  On the other hand, if the SIP-URI of the recipient of the INVITE message is not registered in the registrar DB 21, the SIP server 11 sends a SIP server search request message 81 to the management DB 40 in step 2008 (S 103 in FIG. 10). Search for the SIP server to which the message recipient is logged in.

  When the SIP server search response message 82 is received from the management DB 40 (S104 in FIG. 10), and the information of the SIP server to which the recipient of the INVITE message is logged in (SIP server 13 in FIG. 10) can be acquired. The SIP server 11 confirms that the session management unit 104 is in the communication session identification information indicated by the Call-ID header of the INVITE message and the communication session is in the state of “establishing processing (waiting for a response from the receiving destination)”. Is recorded in the call information DB 41 (step 2010), the INVITE message is transmitted to the IP address of the SIP server acquired from the SIP server search response message 82 (S15). At this time, the SIP server 11 includes the information of the SIP server 11 in the Via header of the INIVTE message.

  Note that if the SIP information to which the recipient of the INVITE message is logged in cannot be acquired, the SIP server 11 sends a SIP response message indicating an error to the sender of the INVITE message (step 2020).

  In FIG. 10, the SIP server 13 that has received the INVITE message from the SIP server 11 processes the INIVITE message according to the processing flow shown in FIG. As a result, in step 2010, the SIP server 13 causes the session management unit 104 to confirm that the communication session identification information indicated by the Call-ID header of the INVITE message and that the communication session is “establishing processing (waiting for a response from the receiver). ) ”State is recorded in the call information DB 43, the INVITE message is transmitted to the IP address acquired from the registrar DB 23 via the load balancer 30 (S16, S17).

  Since the sequence and processing from S17 to S23 are the same as those in the first embodiment, description thereof will be omitted.

  As for the processing for disconnecting communication, the sequence and processing are the same as those in the first embodiment except that the SIP server receiving the BYE message processes the BYE message according to the processing flow shown in FIG. Therefore, explanation is omitted.

  The above is the operation of the system of the second embodiment when the communication device 51 that has completed the login process receives service from the communication device 52.

  Next, processing when the communication device 51 or the communication device 52 logs out after the use or provision of the service is completed will be described.

  FIG. 13 is a diagram showing a sequence when the communication device 51 logs out.

  In FIG. 13, the processing when the communication device 51 logs out is shown in the sequence from S51 to S57.

  When the communication device 51 logs out, first, the communication device 51 transmits a REGISTER message in which the value of the Expires header is set to 0 to the load balancer 30 (S51). The load balancer 30 that has received the REGISTER message transfers the REGISTER message to the SIP server 11 (S52).

  The SIP server 11 that has received the REGISTER message processes the REGISTER message according to the flow shown in FIG.

  That is, the SIP server 11 first determines whether or not the system uses connection-type communication for communication between the communication device and the SIP server (step 2200).

  If connection-type communication is used, step 2204 and subsequent steps are executed.

  On the other hand, if connection type communication is not used, the process proceeds to step 2201, where the SIP server search request message 81 is transmitted to the management DB 40, and the sender of the REGISTER message (communication device 51 in FIG. 13) is sent. Search for the logged-in SIP server. As a result, when there is no SIP server to which the sender of the REGISTER message is logged in, the process proceeds to step 2230, and a SIP response message indicating an error is transmitted to the sender of the REGISTER message.

On the other hand, if there is a SIP server to which the sender of the RESIGER message is logged in, it is checked whether the IP address of the SIP server matches its own IP address (step 2203). If the IP addresses do not match in step 2203, the SIP server 11 transmits a REGISTER message to the SIP server to which the sender of the REGISTER message is logged in. (At this time, the SIP server 11 does not have to include the information of the SIP server 11 in the Via header of the REGISTER message.)
On the other hand, if the IP addresses match in step 2203, if there is information about the SIP server to which the sender of the REGISTER message is logged in in the Via header of the REGISTER message, the SIP server 11 executes step 2204 and subsequent steps. .

  When using a non-connection type communication, when a certain communication device sends a REGISTER message, the load balancer 30 may transfer the REGISTER message to the SIP server to which the communication device is not logged in. However, by performing the processing from step 2201 to step 2203, the REGISTER message can be transmitted to the SIP server to which the communication device is logged in, and the registrar DB of the SIP server to which the communication device is logged in is correctly set. Can be updated.

  In step 2204, the SIP server 11 searches the call information DB 41 to determine whether an entry including the SIP-URI of the sender of the REGISTER message exists.

  At this time, if the corresponding entry does not exist (No in step 2205), the process proceeds to step 2207.

  On the other hand, if the corresponding entry exists (Yes in step 2205), the SIP server performs processing for terminating the corresponding communication. When the corresponding communication is terminated, the process proceeds to step 2207.

  In step 2207, the SIP server 11 searches the registrar DB 21 to see if the SIP-URI of the sender of the REGISTER message is registered.

  At this time, if the corresponding SIP-URI is not registered (No in Step 2208), the process proceeds to Step 2230, and a SIP response message indicating an error is transmitted to the sender of the REGISTER message.

  On the other hand, if the corresponding SIP-URI has been registered (Yes in step 2208), the SIP server 11 transmits a SIP server deletion request message 85 to the management DB 40 (S53 in FIG. 13).

  As shown in FIG. 6, the SIP server deletion request message 85 of this embodiment is described as a command line including the SIP-URI to be deleted (“DELETE_REQUEST sip: user@hitachi.com” in FIG. 6). However, this means requesting deletion of the SIP-URI user@hitachi.com).

  Upon receiving the SIP server deletion request message 85, the management DB 40, when deleting the entry including the SIP-URI specified in the SIP server deletion request message 85, sends a SIP server deletion response message 86 to the SIP server 11 (FIG. 13). S54).

  As shown in FIG. 6, the SIP server deletion response message 86 of this embodiment is described as a command line including the deletion result of the SIP-URI to be deleted (“DELETE_RESULT SUCCESS” in FIG. Indicates that the deletion was successful), and a line indicating the SIP-URI to be deleted (indicated as “SIP-URI: sip: user@hitachi.com” in FIG. 6) .

  The SIP server 11 that has received the SIP server deletion response message 86 moves to step 2210 and deletes the entry including the SIP-URI of the sender of the REGISTER message from the registrar DB 21.

  Next, the SIP server 11 transmits a SIP response message indicating successful processing to the sender of the REGISTER message to the communication device 51 via the load balancer 30 (S55 and S56 in FIG. 13).

  The above is the operation of the SIP server 11 that has received the REGISTER message.

  The communication device 51 that has received the SIP response message ends the TLS communication (S57).

  The above is the operation when the communication device 51 logs out. The same operation is performed with the SIP server 13 when the communication device 52 logs out.

  According to this embodiment, since the call information is managed by the session management server, at least information related to the SIP server to which the communication device is logged in may be recorded in the management DB.

  As a result, in the load balancing method described in Patent Document 1, since the shared database is updated every time one message is processed, the shared database with extremely high processing performance, the session management server, and the shared database However, in this embodiment, the management DB is not required to have high processing performance or high speed communication means between the SIP server and the management DB. Also, even if multiple session management servers try to control the same call information at the same time, unlike the load balancing method described in Patent Document 1, a situation may occur in which the state of the management DB cannot be uniquely determined do not do.

  Furthermore, in this embodiment, since a shared database is used instead of broadcast communication to acquire information on the SIP server that manages the communication device, the amount of communication transmitted and received between SIP servers can be suppressed. There is an effect.

  Next, a third embodiment will be described with reference to FIGS.

  In the first and second embodiments described above, the SIP server that has received the SIP message acquires information on the SIP server to which the SIP message destination is logged in, and sends the SIP message to the SIP server. It was.

  In the third embodiment, a management DB that manages communication settings for communication with the currently logged-in communication device that is accessible from the SIP server is provided, and the SIP server that receives the SIP message is Its main feature is that it acquires communication settings and communicates with the destination of SIP messages.

  FIG. 15 is a diagram showing a system configuration in the third embodiment.

  As in the second embodiment, the system shown here includes three SIP servers (SIP server 11, SIP server 12, and SIP server 13), a load balancer 30, a management DB 40, a communication device 51, The three SIP servers and the load balancer 30 are connected via the LAN 1, the three SIP servers and the management DB 40 are connected via the LAN 2, and the communication device 52. The load balancer 30, the communication device 51, and the communication device 52 are connected via the network 0.

  The SIP server 11 is assigned an IP address of 192.168.10.11 and includes a registrar DB21. The SIP server 12 is assigned an IP address of 192.168.10.12 and has a registrar DB22. Furthermore, the SIP server 13 is assigned an IP address of 192.168.10.13 and includes a registrar DB23.

  The load balancer 30 is assigned an IP address of 192.168.10.1. Note that the load balancer 30 used in this embodiment also has a function of transferring a message to the SIP server that transferred the message immediately before when the message is received from the same communication device within a predetermined period. ing.

  Further, the communication device 51 is assigned an IP address of 192.168.20.11 and a SIP-URI of user@hitachi.com, and the communication device 52 is assigned an IP address of 192.168.30.11 and a SIP of service@hitachi.com. -A URI is assigned. The software structure of the communication device 51 and the communication device 52 is the same as the software structure of the communication device 51 and the communication device 52 of the second embodiment.

  Furthermore, the management DB 40 of this embodiment communicates with the call information table 401 that records the call information managed by the SIP server 11, the SIP server 12, and the SIP server 13, and the SIP server 11, the SIP server 12, and the SIP server 13. The communication shared information table 402 records communication settings for communicating with the device 51 and the communication device 52. Here, the call information table 401 includes a Call-ID that is identification information of a communication session, a SIP-URI of a sender of a communication session, a SIP-URI of a receiver of a communication session, and the communication session. Are recorded. The communication shared information table 402 includes a SIP-URI that is identification information of a communication device and access point information (that is, a set of IP address, port number, and transport layer protocol type) when communicating with the communication device. ), The type of encryption algorithm used for encrypted communication with the communication device, the key value used for encrypted communication, the sequence number for identifying the message order, Is recorded.

  Hereinafter, the second embodiment will be described by taking a communication procedure when the communication device 51 shown in FIG. 15 performs data communication with the communication device 52 as an example.

  16 and 17 are sequence diagrams showing data communication according to the first embodiment. Description of steps and messages described in the first embodiment indicated by the same reference numerals as those in FIGS. 3 and 4 is omitted as much as possible.

  FIG. 16 is a diagram showing a sequence when the communication device 51 performs a login process to the SIP server.

  In this embodiment, when the communication device 51 negotiates encrypted communication with the SIP server (SIP server 11 in FIG. 16) to establish encrypted communication (S6), the SIP server 11 establishes encrypted communication. The setting is registered in the management DB 40 (S401, S402).

  Next, the SIP server 11 that has received the REGISTER message transmitted by the communication device 51 acquires the communication setting with the communication device 51 from the management DB 40 (S403, S404), and decrypts the REGISTER message using the setting. . Here, when the message can be correctly decoded, the communication setting with the communication device 51 recorded in the management DB 40 is updated (S405, S406).

  Next, when the SIP server 11 creates a SIP response message for the REGISTER message, the SIP server 11 acquires the communication setting with the communication device 51 from the management DB 40 (S407, S408), and encrypts the SIP response message using the setting. Are transmitted to the communication device 51 (S9, S10). Here, when the transmission of the message is completed, the communication setting with the communication device 51 recorded in the management DB 40 is updated (S409, S410).

  Thus, the login of the communication device 51 is completed.

  As described above, in this embodiment, every time a SIP server sends / receives a SIP message or a SIP response message to / from a certain communication device, the SIP server obtains communication settings with the communication device from the management DB 40, and performs encryption and decryption. In addition to performing the process, the communication settings recorded in the management DB 40 are updated. In the following, for the sake of simplicity, description of acquisition and update processing of communication settings from the management DB 40 is omitted.

  FIG. 17 is a diagram illustrating a sequence when the communication device 51 establishes a communication session with the communication device 52.

  First, when the communication device 51 establishes a communication session with the communication device 52, the communication device 51 transmits an INVITE message to the load balancer 30 (S501).

  When receiving the INVITE message, the load balancer 30 selects the SIP server that transfers the INVITE message from the three SIP servers, and transfers the INVITE message to the selected SIP server (S502). FIG. 17 shows a case where the SIP server 11 is selected as the SIP server to be transferred.

  Upon receiving the INVITE message, the SIP server 11 searches the call information table 402 of the management DB 40 to find out whether call information having the communication session identification information indicated by the Call-ID header of the INVITE message is registered. (S503, S504).

  Here, when call information having communication session identification information indicated by the Call-ID header of the INVITE message is registered, a SIP response message indicating that processing is already in progress via the load balancer 30 Is transmitted to the communication device 51.

On the other hand, when call information having the identification information of the communication session indicated by the Call-ID header of the INVITE message is not registered, a call information update request message is transmitted to the call information table 402 of the management DB 40, and the call information table 402 The communication session identification information indicated by the Call-ID header of the INVITE message, the SIP-URI of the transmission source of the INVITE message, the SIP-URI of the transmission destination of the INVITE message, and the communication session “Waiting for a response from the recipient” is recorded. (S505, S506)
Next, the SIP server 11 transmits the INVITE message to the communication device 52 designated as the destination of the INVITE message via the load balancer 30 (S507, S508).

  The communication device 52 that has received the INVITE message creates a SIP response message for the INVITE message and transmits it to the load balancer 30 (S509).

  When receiving the SIP response message, the load balancer 30 selects the SIP server that transfers the SIP response message from the three SIP servers, and transfers the SIP response message to the selected SIP server (S510). FIG. 17 shows a case where the SIP server 13 is selected as the SIP server to be transferred.

  The SIP server 13 that has received the SIP response message searches the call information table 402 of the management DB 40 to determine whether call information having the communication session identification information indicated by the Call-ID header of the SIP response message is registered. Search is performed (S511, S512).

  Here, when call information having communication session identification information indicated by the Call-ID header of the SIP response message is not registered, a SIP response message indicating that an error has occurred via the load balancer 30 Is transmitted to the communication device 52.

On the other hand, when call information having communication session identification information indicated by the Call-ID header of the SIP response message is registered, if the content of the SIP response message is “communication permitted”, the call information table 402 of the management DB 40 is stored. A call information update request message is transmitted, and the call information of the communication session indicated by the Call-ID header of the SIP response message is deleted from the call information table 402. On the other hand, if the content of the SIP response message is “communication permitted”, a call information update request message is transmitted to the call information table 402 of the management DB 40, and the communication indicated by the Call-ID header of the SIP response message in the call information table 402 Update the session call information status to "Connected" status. (S513, S514)
Next, the SIP server 13 transmits the SIP response message to the communication device 51 designated as the transmission destination of the SIP response message via the load balancer 30 (S515, S516).

  As described above, in this embodiment, every time a SIP server receives an INVITE message or a SIP response message for an INVITE message with a certain communication device, the SIP server acquires call information regarding the communication session from the management DB 40 and processes the message. Then, the call information recorded in the management DB 40 is updated according to the processing result. In this embodiment, even when a BYE message or a SIP response message for the BYE message is received, call information regarding the communication session is acquired from the management DB 40 and the message is processed. Then, the call information recorded in the management DB 40 is updated according to the processing result.

  In this embodiment, a shared database accessible from the SIP server is provided, and communication settings for communicating with the communication device are recorded in the shared database. For this reason, the SIP server that received the SIP message or SIP response message refers to the shared database to obtain the communication settings, so that even if the source of the SIP message or SIP response message is not the logged-in SIP server, the message Can be processed (for example, when encrypted communication is performed, it can be correctly decrypted).

  In this embodiment, the SIP server refers to the shared database to acquire the communication setting even when a SIP message or a SIP response message is transmitted. Therefore, there is an effect that the message can be directly transmitted to the communication device without transmitting the message to the SIP server to which the communication device to which the SIP message or the SIP response message is transmitted is logged in.

The figure which illustrated the system configuration in the 1st example. The block diagram which illustrates the hardware constitutions of each apparatus in each Example. The figure which illustrated the sequence in case the communication apparatus 51 and the communication apparatus 52 shown in FIG. 1 perform the login process to a SIP server. FIG. 2 is a diagram illustrating a sequence in a case where the communication device 51 shown in FIG. The figure which illustrated the processing flow of the INVITE message in the SIP server shown in FIG. The figure which illustrated the message for the SIP server shown in FIG. 1 to acquire information required for communication. The figure which illustrated the processing flow of the SIP server search request message in the SIP server shown in FIG. The figure which illustrated the system configuration in the 2nd example. The figure which illustrated the sequence in case the communication apparatus 51 and the communication apparatus 52 shown in FIG. 8 perform the login process to a SIP server. FIG. 9 is a diagram exemplifying a sequence in a case where the communication device 51 shown in FIG. The figure which illustrated the processing flow in a SIP server in case the communication apparatus shown in FIG. 8 logs in. The figure which illustrated the processing flow of the INVITE message in the SIP server shown in FIG. FIG. 9 is a diagram illustrating a sequence when the communication apparatus illustrated in FIG. 8 logs out. The figure which illustrated the processing flow in a SIP server in case the communication apparatus shown in FIG. 8 logs out. The figure which illustrated the system configuration in the 3rd example. The figure which illustrated the sequence in case the communication apparatus 51 shown in FIG. 15 performs the login process to a SIP server. FIG. 16 is a diagram exemplifying a sequence in a case where the communication device 51 shown in FIG.

Explanation of symbols

0: Network, 1, 2: LAN, 11, 12, 13: SIP server, 21, 22, 23: Registrar DB, 30: Load balancer, 40: Management DB, 41, 42, 43: Call information DB, 45 : Shared information management server, 51, 52: Communication device, 81: SIP server search request message, 82: SIP server search response message, 83: SIP server registration request message, 84: SIP server registration response message, 85: Delete SIP server Request message, 86: SIP server deletion response message, 91: CPU, 92: Memory, 93: Hard disk, 94: Network interface, 95: I / O interface.

Claims (14)

A data communication system for managing data communication between a plurality of communication devices,
A plurality of session management servers for managing data communication sessions between the communication devices;
According to a predetermined standard, a communication message from the communication device 1 to the communication device 2 that does not include information for specifying a session management server that manages the communication device 2 is transmitted to any one of the session management messages. A load balancer that distributes to servers,
A data communication system comprising: a session management server that has received the communication message from the load distribution device; and means for acquiring information necessary for communicating with the communication device 2. A data communication system according to claim 1, wherein
The data communication system, wherein the information necessary for communicating with the communication device 2 is identification information for specifying a session management server to which the communication device 2 is logged in. A data communication system according to claim 2, wherein
Means for acquiring information necessary for communicating with the communication device 2 is:
Means for the session management server receiving the session establishment request message to inquire of another session management server whether or not the communication device 2 is logged in;
The session management server to which the communication device 2 is logged in includes means for responding to the session management server that has received the session establishment request message that the communication device 2 is logged in. Data communication system. A data communication system according to claim 2, wherein
Means for acquiring information necessary for communicating with the communication device 2 is:
A shared database in which identification information for identifying a session management server to which the plurality of session management servers are accessible and the communication device is logged in;
A session management server that receives the session establishment request message; and means for searching the shared database. A data communication system according to claim 2,
The data communication system, wherein the communication message is a session establishment request message or a session establishment response message. A data communication system according to claim 1, wherein
The information necessary for communicating with the communication device 2 is an encrypted communication setting used when communicating with the communication device 2,
Means for acquiring information necessary for communicating with the communication device 2 is:
A shared database accessible by the plurality of session management servers for recording encrypted communication settings used when communicating with the communication device 2;
A session management server that receives the session establishment request message; and means for searching the shared database. A data communication system according to claim 6,
The data communication system, wherein the communication message is a call information search request message or a call information search response message. A session management server for managing a data communication session between a plurality of communication devices,
Means for receiving from the load balancer a communication message from the communication device 1 to the communication device 2 that does not specify a session management server that manages the communication device 2;
Means for acquiring information necessary for communicating with the communication device 1 or the communication device 2; and a session management server. The session management server according to claim 8, wherein
The session management server characterized in that the information necessary for communicating with the communication device 1 or the communication device 2 is identification information for identifying the session management server to which the communication device is logged in. A session management server according to claim 9, wherein
Means for acquiring information necessary for communicating with the communication device 1 or the communication device 2
Means for inquiring another session management server whether or not the communication device 1 or the communication device 2 is a logged-in session management server;
Means for receiving from the session management server to which the communication device 1 or the communication device 2 is logged in, that the communication device is logged in. The session management server according to claim 9, wherein
Means for acquiring information necessary for communicating with the communication device 1 or the communication device 2
A session management server comprising means for searching a shared database in which identification information for identifying a session management server to which the plurality of session management servers are accessible and the communication device is logged in is recorded. . A data communication system according to claim 8,
The session management server, wherein the communication message is a session establishment request message or a session establishment response message. The session management server according to claim 8, wherein
The information necessary for communicating with the communication device 2 is an encrypted communication setting used when communicating with the communication device 2,
Means for acquiring information necessary for communicating with the communication device 1 or the communication device 2
A session management server comprising means for searching a database that records encrypted communication settings used when communicating with the communication device. 14. A data communication system according to claim 13, wherein
The session management server, wherein the communication message is a call information search request message or a call information search response message.

Images