WO2008047920A1 - Serveur proxy, système et procédé de communication et programme - Google Patents

Serveur proxy, système et procédé de communication et programme Download PDF

Info

Publication number
WO2008047920A1
WO2008047920A1 PCT/JP2007/070481 JP2007070481W WO2008047920A1 WO 2008047920 A1 WO2008047920 A1 WO 2008047920A1 JP 2007070481 W JP2007070481 W JP 2007070481W WO 2008047920 A1 WO2008047920 A1 WO 2008047920A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
sip
server
failure
function
Prior art date
Application number
PCT/JP2007/070481
Other languages
English (en)
French (fr)
Inventor
Motohiro Suzuki
Hiroshi Kazami
Original Assignee
Nec Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nec Corporation filed Critical Nec Corporation
Priority to EP07830215A priority Critical patent/EP2079024A1/en
Priority to US12/443,360 priority patent/US8374079B2/en
Publication of WO2008047920A1 publication Critical patent/WO2008047920A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/203—Failover techniques using migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2025—Failover techniques using centralised failover control functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component

Definitions

  • Proxy 'server communication system
  • the present invention relates to a proxy sano, a communication system, a communication method, and a program that are suitably used in a communication network that performs signaling using SIP (session initiation protocol).
  • SIP session initiation protocol
  • SIP session initiation protocol
  • SIP network a communication network that performs signaling using SIP
  • a general configuration of a SIP network is described in Document 3.
  • a SIP network consists of a location 'server, a SIP server, and a user' agent (UA).
  • the user's agent is described in 3 ⁇ 76 of Ref. 3 (described later), “SIP is based on the client-server model between end systems! /, !, which corresponds to this end system.
  • S User Agent
  • a user agent is specifically an end system such as a telephone or a PC.
  • a response response (response) are exchanged to realize the service. ”
  • the above-described explanation is called a SIP request, and the response is called a SIP response.
  • the SIP server is used for (1) a proxy server function that relays SIP requests and SIP responses, and (2) for querying the destination of a SIP request, as described in ⁇ ⁇ 77 of Document 3. It has a redirect server function and (3) a registration server function that accepts registration of user 'agent information on the SIP network.
  • the user / agent information is, for example, a URI (uniform resource identifier) that is an identifier for accessing the user's agent or an IP address used by the user / agent.
  • the user 'agent information registered in the SIP server by the user' agent is called registration information. This registration information is updated using the REGISTER request for SIP requests.
  • Fig. 12 shows the operation sequence for communication between user and agent in a general SIP network.
  • This figure includes the user-agent authentication method (digest authentication) that is adopted when a general information carrier establishes a SIP network, as described in Reference 4 (described later). is there.
  • the user agent sends an INVITE request to the SIP server.
  • the INVITE request that this user agent (calling party) first sends to the SIP server is called the initial INVITE request.
  • the SIP server Upon receiving the initial INVITE request from the user agent (calling side), the SIP server calculates the nonce used for digest authentication and applies the nonce value to the SIP response (407 proxy authentication required)! ] And return to user's agent (calling party J). The user agent (calling party) hashes the secret (user identifier and password) using the received nonce as a key. This result is stored in the Authorization header of the INVITE request and transferred to the SIP server. In this specification, an INVITE request with a header added to this Authorization is called an authentication INVITE request.
  • the SIP server that has received the INVITE request performs authentication processing for the user 'agent (calling side). Specifically, (1) As with the user agent (calling side), the user identifier and password of the user 'agent (calling side) are hashed using the nonce value generated by itself. (2) Authentication from user agent (calling side) Compare with the Authorization header value stored in the INVITE request, and if it is the same, it is determined that the authentication INVITE request is from a valid user agent.
  • the SIP server determines that the authentication INVITE request from the legitimate user / agent as a result of this authentication process, the SIP server receives the authentication INVITE request in the To field (see FIG. 12). Forward to user agent (calling party)
  • the user agent (calling side) Authentication A temporary response (100 rying and 180 Ringing in Fig. 12) indicating that the INVITE request is being processed is returned to the SIP server and the caller is called.
  • the user agent (calling side) returns a SIP response (200 OK) indicating that the processing of the authentication IN VITE request is completed to the SIP server.
  • the user agent sends an ACK request to inform the user agent (calling side) that the SIP response (200 OK), which is the final response of the authentication INVITE request, has been received.
  • This establishes a session for a call between the user 'agent (calling party) and the user' agent (calling party).
  • a BYE request to end the session is issued from the user's agent who wishes to end the call (in Fig. 12, the user's agent (calling side)).
  • the user agent (calling side) that has received the BYE request via the SIP server sends a SIP response (200 OK) after the BYE request is processed to inform that the session end processing has been completed.
  • a SIP response 200 OK
  • call flow The series of flows from the initial INVITE request to the SIP response (200 OK) indicating the completion of processing of the BYE request shown in FIG. 12 is generally called "call flow (call flow)". It is identified by the value of the Call—ID header stored in the SIP request and SIP response. That is, all SIP requests and SIP responses shown in Fig. 12 hold the same Call-ID header value. In addition, general information carriers need to manage who and who is busy to charge for calls. For this reason, the SIP server is realized as a call stateful proxy that manages the state in which the generated call is in the call flow. As a result, as shown in FIG. 12, all SIP requests and SIP responses in the call flow are routed through the same SIP server.
  • FIG. 13 is a diagram showing a configuration of the proxy response device shown in Document 1.
  • Fig. 13 is a diagram showing a configuration of the proxy response device shown in Document 1.
  • the proxy response device shown in Document 1 monitors the occurrence of failures on multiple servers, and when a failure occurs on one server, it has a function to take over the processing of the failed server on other servers. providing. In order to realize this function, the proxy response device is described as having the following means.
  • the proxy response device of the present invention holds the address of a monitoring target server that monitors the occurrence of a failure and the address of a spare server that can respond in place of the monitoring target server, and transmits a message that the monitoring target server transmits and receives.
  • a means for rewriting the source address to the address of the proxy response device and transmitting it to the spare server The source address of the response message from the spare server is monitored. It has means to relay to the rewritten client at the address of the server to be viewed "(quoting paragraph 1 of reference 1).
  • FIG. 14 shows a hardware configuration of an information processing apparatus that realizes such a proxy response apparatus.
  • this configuration is described as follows.
  • “An information processing device that implements the proxy response device 1 includes a processor 100, a storage device 108, an input circuit interface 105 and an output circuit interface 107 for connection to the IP network 6b, and an input circuit interface.
  • Receive buffer 104 for temporarily accumulating the IP packets received at 105
  • transmission buffer 106 for temporarily accumulating the IP packets to be transmitted by the output circuit interface 107, and a bus connecting them
  • the storage device 108 stores a program memory 101, a packet buffer 102, and a server management table 103.
  • the program memory 101 is executed by the processor 100 and is a proxy response device. 1 is recorded, and the packet buffer 102 stores IP packets exchanged between the client 3 and the servers 2a and 2b.
  • Storage device 108 a semiconductor memory device, or constitute an external storage device such as a hard disk. "(Citing paragraph 0019 of Document 1).
  • the proxy response device having such a configuration is different from the processing content of the server in which the failure has occurred.
  • the processing status of the server is grasped by introducing the following packet buffer management function, which is explained as follows.
  • the proxy response device 1 includes a packet buffer 102 for managing messages exchanged between the client 3 and the servers 2a and 2b, and the request message transmitted by the client 3 and the corresponding servers 2a and 2b. Response messages are collectively managed as a single unit (hereinafter referred to as a session) .Sessions are registered in the session management entries 110-1 and 110-2 in the packet buffer 102. (Refer to paragraph 1 of reference 1).
  • a configuration example of this packet buffer is as shown in FIG. 15, and is described as follows.
  • Each entry of the packet buffer 102 includes a session identifier 111, a client address 112, a server address 113, a client transmission packet buffer 114, and a server transmission packet buffer 115.
  • the session identifier 111 identifies each entry.
  • the client address 112 is set to the IP address of the client 3 that sent the request
  • the server address 113 is set to the IP address of the server 2a that received the request.
  • All IP packets sent by client 3 to server 2a are stored as is in client send packet buffer 114.
  • All IP packets sent by server 2a to client 3 are stored in server send packet buffer 115. It is stored as it is "(paragraphs 0024 and 00 of document 1 (Quoting 25)
  • FIG. 16 is a flowchart showing the operation of the proxy response device. This operation is described as follows.
  • step 170 “All IP packets flowing in the IP network 6b to which the proxy response device 1 is connected are acquired by the input circuit interface 105 and stored in the reception buffer 104.
  • the processor 100 stores the above IP in the reception buffer 104. If there is a packet, one is acquired (step 170), and whether the acquired IP packet is related to the monitored server 2a is determined by the server address 150 or the destination address 151 of the IP packet. It is determined whether it matches the monitored server address 1 21 in Table 103. If the IP buffer is not acquired in step 170, the process proceeds to step 175 (step 171).
  • the processor 100 determines whether the packet type 153 of the IP packet is a disconnect request (step 172), and if it is not a disconnect request, stores the IP packet in the corresponding entry of the packet buffer 102 (step 173).
  • the corresponding entry is determined by the strength of the combination of the source address 150 and the destination address 151 of the IP packet, the strength that matches the pair of the client address 112 and the server address 113 (even if they are in no particular order, they are regarded as a match).
  • the storage destination is the client transmission packet buffer 114 if the transmission destination of the IP packet is a server, and the server transmission packet buffer 115 if the transmission source of the IP packet is a server. At this time, if there is no corresponding entry, a new entry is created.
  • the processor 100 determines whether there is a failure in the server having the monitored server address 121 of each entry of the server management table 103 (step 175), and executes a proxy response process if a failure has occurred (step 175). 177).
  • the method for determining the presence or absence of a server failure is not particularly limited. For example, all the sessions stored in the packet buffer 102 are monitored, and if a session with no response for a certain time is found from the server, the above server It is determined that a failure has occurred.
  • the server executes a program that continues to send a message indicating that there is no failure in the proxy response device 1, and when the proxy response device 1 cannot receive the message, the server fails. Is determined to have occurred.
  • the process up to the occurrence of a failure is executed using all received IP packets, and the same state is reproduced. Step 177 is executed for each IP packet, and after execution, the process returns to step 170. (Quoting paragraphs 0036 to 0042 of reference 1)
  • the proxy response device shown in Document 1 stores all IP packets transmitted from the client and server, and when a failure occurs in the server, Instead of the client, the proxy response device sends all the IP packets up to the failure to the other server in order, so that the same state as when the failure occurred on the server is reproduced on the other server. That is. By this means, processing of requests from clients that have not been completed on the server is handed over to other servers.
  • FIG. 17 is a diagram showing a principle configuration of the server backup device described in Document 2. The configuration of this server backup device is explained as follows. In addition, “FIG. 1” in the following description corresponds to “FIG. 17” in this specification.
  • FIG. 1 is a block diagram showing the principle configuration of a server backup apparatus according to the present invention.
  • This figure shows a plurality of telephone terminals connected to a network, for example, IP telephone terminals and terminals in the network.
  • the server backup device 1 is located between the server and the server for switching and connecting the call to the outside, and performs the backup of the server.
  • the server backup device 1 includes at least server failure detection means 2, And a message transfer means 3.
  • the server failure detection means 2 detects a server failure, and corresponds to, for example, a call state management section and a SIP message reading section, which will be described later.
  • the destination address in a predetermined message sent from the terminal side for communication between terminals in the network is the address of its own device.
  • the address is rewritten to the address of the partner terminal, and the message is directly transferred to the partner terminal without going through the server, and corresponds to, for example, a SIP message rewrite unit.
  • the backup device 1 corresponds to each of a plurality of IP telephone terminals, and further stores an end point storage device, for example, an end point table that stores an end point name and an IP address as a terminal identifier.
  • the message transfer means 3 can also transfer a message based on the contents stored in the end-point storage means, and a predetermined message can be sent to request a call establishment from the other terminal side.
  • the server backup device according to the present invention includes a server failure detection method and a server failure detection method.
  • a message generation means for generating a response message to the message in response to a predetermined message sent from a terminal in the network during the occurrence period, and transmitting the response message to a transmission source terminal of the predetermined message, for example,
  • the predetermined message may be a register message transmitted from the terminal side for registration of the own terminal, or in the embodiment, the server backup device. Is the predetermined message from the same terminal
  • a predetermined message reception number storage means for storing the number of receptions of, for example, an active call table, and when the server failure detection means exceeds the predetermined number of received messages, It is also possible to detect a failure of the server. (Quoting paragraphs 0010 to 0014 of document 2).
  • the server described so far corresponds to the IP Centrex Server in FIG. As shown in Fig. 18, the IP Centrex server's backup system is not specified.
  • the server knock-up device covers all signaling from the user agent.
  • the server backup device forwards the SIP request from the calling user's agent to the called user.agent. Therefore, in the embodiment of the server backup device, in order to determine the IP address from the identifier of the called user agent such as a telephone number, a user agent corresponding to each of a plurality of user agents is used.
  • An end-point storage means for storing the end-point name and the IP address of the user agent is used.
  • FIG. 19 shows the operation when the IP Centrex server operates normally
  • FIG. 20 shows the operation when an IP Centrex server failure occurs.
  • FIG. 4 is a more detailed explanatory diagram of the operation in the system at the normal operation of the Centrex server.
  • the IP address of the backup device 10 is 111. 1. 1. 10
  • the IP address of the terminal 121 or 111. 1. 1. 1
  • the IP address of the terminal 122 or 111. 1. 1. 2, or the IP cent
  • the IP address and address of the lex sano 16 is 133. 1. 1. 1.
  • the session 'initiation' protocol for establishing, maintaining and terminating the session is sent from the terminal 121.
  • SIP SIP
  • register messages and invite messages which will be described later
  • the data is transferred to the backup device 10 through a route to the backup device 10 and further transferred from the backup device 10 to the terminal 122 via the LAN 13.
  • the actual audio signal after the call connection between the terminals that is, the exchange of the media stream by the real-time 'transport' protocol (RTP), is performed directly via the LAN 13 without the backup device 10. Between. In the normal operation of the IP Centrex server 16, the actual voice signal is also exchanged directly between the terminals.
  • FIG. 5 is a detailed explanatory diagram of the operation when the Centrex server failure occurs.
  • the backup device 10 receives the IP as described later.
  • the failure of the Centrex server 16 has been detected. Therefore, the backup device 10 does not forward the message to the IP Centrex server 16 side, but directly forwards it to the other party's IP phone terminal 122 (2). Call between two terminals becomes possible.
  • the actual audio signal after the call connection between the terminals is completed, that is, the exchange of the media stream by the real-time 'transport' protocol is performed directly between the terminals via the LAN 13 without going through the backup device 10. .
  • the actual voice signal is also directly exchanged between the terminals. (Quoting paragraph 2 0022-0024 of ref. 2).
  • the server backup device described in Document 2 changes the destination of the received SIP request by referring to the information of the end point name and IP address when a failure occurs in the IP Centrex server.
  • the backup device forwards the SIP request directly to the user's agent, thereby avoiding a call interruption due to an IP Centrex server failure.
  • Patent Document 1 Japanese Unexamined Patent Application Publication No. 2004-280738
  • Patent Document 2 Japanese Patent Laid-Open No. 2005-229273
  • Non-Patent Document 1 Yasuaki Chimura and Toshifumi Murata “Revised SIP Textbook” P. 77, P. 78 Patent Publication 2004
  • Non-patent document 2 Formulated by Information and Communication Technology Committee Specification No. TS—1006 “Technical specifications of basic connection interface for SIP terminals connected to service provider SIP network” 2004 Invention Disclosure
  • the first problem is that in the related technology taking the technology described in Document 1 as an example, a call flow that encounters a failure of the working SIP server cannot be terminated normally.
  • FIG. 21 is a sequence diagram showing an example in which the status of the active SIP server cannot be reproduced by the spare SIP server when the proxy response device is applied to the SIP network.
  • the proxy response device transmits an initial INVITE request transmitted from a user agent (calling side) that reproduces the state of the working SIP server to the spare SIP server.
  • the spare SIP server newly calculates a nonce value, and transmits a SIP response (407 proxy authentication required) including the nonce value to the proxy response device.
  • the proxy response device sends the authentication INVITE request received from the user's agent (calling side) to the backup SIP server.
  • the value stored in the Authentication header of this authentication INVITE request is hashed using the nonce value generated by the working SIP server, and the nonce value generated by the backup SIP server is used. Since it is different from the one that was used and hashed, authentication processing on the spare SIP server fails.
  • the proxy response device that does not retain the user identifier and password of the user 'agent (calling side) received from the user' agent (calling side) Authentication It is necessary to analyze the Authentication header value of the INVITE request and extract the user identifier and password of the user's agent (calling side). However, this means breaking digest authentication and is not possible.
  • the user's agent (calling side) and the user's agent (calling side) are actually talking, even though the user's agent (calling side) is busy.
  • the call session between the calling party and the user's agent (the called party) is established and recognized as! /, NA! /.
  • the standby SIP server does not have a session to be terminated, so the BYE request is not executed. In this way, a call flow that encounters a failure of the working SIP server is not terminated normally.
  • the second problem is that in the related technology taking the technology described in Document 2 as an example, digest authentication is not performed when a user's agent calls when an IP center server failure occurs. It can't be done!
  • the SIP server calculated a nonce value for the initial INVITE request from the user agent (calling side) and added the result.
  • the server backup device described in Document 2 also has a function to calculate the nonce value even though the SIP response (407 proxy authentication required) must be returned to the user agent. This is because the SIP response (407 proxy authentication required) cannot be generated because the function that holds the password is not held.
  • the third problem is that in the related technology in which the technology described in Document 2 is taken as an example, the server backup device has poor response to an increase in the number of user agents.
  • the related technology has a form in which the server backup device itself holds information on the identifier of the user's agent and the IP address in order to determine the IP address of the user agent (calling side). Power.
  • the disk and memory capacity for storing this information must be expanded.
  • the fourth problem is that in the related technology taking the technology described in Document 2 as an example, the user stored in the server backup device, the user described in the information of the agent identifier and IP address The SIP request cannot be forwarded to the 'non-agent' agent.
  • the purpose of the present invention is to ensure that even if a failure of the active SIP server is encountered before the call flow involving digest authentication is terminated, the corresponding call flow ends normally and the newly generated call digest is detected even when the active SIP server fails. It is to provide a proxy server in a SIP network that performs authentication, can flexibly cope with the increase in the number of users' agents, and has no restrictions on the forwarding destination of SIP requests.
  • the proxy server of the present invention for solving the above-described problems is a SIP proxy server function that mediates a SIP message transmitted and received between a user terminal, a working SIP server, and a spare SIP server, and a proxy.
  • the message type determination function that determines the type of message received by the server function, the forwarding destination fault detection function that detects and notifies that a failure has occurred in the active SIP server, and the notification from the forwarding destination fault detection function Based proxy
  • the message received by the server function is the call flow that encountered the failure of the working SIP server. Receives notifications from the call failure encounter detection function and the transfer destination failure detection function to determine the power of the device belonging to the same, and the message according to the failure status of the active SIP server and the type of message received by the proxy server function And a destination setting function for setting the transfer destination.
  • the present invention for solving the above-described problems includes a working and spare SIP server that transmits and receives SIP messages to and from a user terminal, and a proxy server that mediates transmission and reception of SIP messages.
  • SIP proxy server function that mediates SIP messages sent and received between the user terminal and the active SIP server and backup SIP server to the proxy and server, and the type of received message The message received by the proxy server function based on the notification from the message type judgment function, the forwarding destination fault detection function that detects and notifies that a failure has occurred in the active SIP server, and the forwarding destination fault detection function Call failure encounter determination function that determines the power belonging to the call flow that encountered a failure of the working SIP server, and notification from the transfer destination failure detection function On the basis of
  • the present invention for solving the above-described problem is a proxy that mediates transmission / reception of SIP messages to / from active and spare SIP servers that perform transmission / reception of SIP messages to / from external user terminals.
  • the forwarding destination failure detection step that detects and notifies that a failure has occurred in the working SIP server, and the notification received from the forwarding destination failure detection step and the message received in the mediation step is the working SIP server. From the call failure encounter determination step and the transfer destination failure detection step to determine the power belonging to the call flow that encountered the failure. Receives, working s
  • a destination setting step for setting a forwarding destination of the message according to the failure occurrence state of the IP server and the type of message received in the mediation step.
  • the first effect is that the processing of a call flow that encounters a failure of the working SIP server is terminated normally. It is to end.
  • SIP request and SIP response message belonging to a call flow that encountered a failure of the working SIP server is received, the contents of the SIP request and SIP response are referred to, and the corresponding SIP request and This is to identify and forward the destination to which the SIP response message should be sent next.
  • the second effect is that a call with digest authentication can be made even when the working SIP server fails.
  • the proxy server detects the failure of the active SIP server and changes the forwarding destination of the SIP request message according to the failure occurrence state of the active SIP server.
  • a proxy server receives a SIP request message that includes digest authentication, such as an initial INVITE request or initial REGISTER request, when the failure occurs in the active SIP server, it is forwarded to the backup SIP server to generate a digest. Authentication can be performed.
  • the third effect is that it is possible to flexibly cope with an increase in the number of user agents.
  • next transfer destination of the message belonging to the call flow that encountered the failure of the working SIP server is determined based on the type of the received message.
  • a disk or memory to store information that resolves the IP address of the user's agent to which the SIP request message is forwarded.
  • the increase in the number of forwarding destinations for SIP request messages from users' agents and the processing for resolving forwarding destination IP addresses are irrelevant.
  • the fourth effect is that there is no restriction on the message transfer destination.
  • FIG. 1 is a block diagram showing a configuration of a communication system according to a first embodiment of the present invention.
  • FIG. 2 is a block diagram showing the configuration of the proxy server according to the first embodiment.
  • FIG. 3 is a diagram showing an example of an implementation form of a call identifier list held by the call failure encounter determination function in the proxy server according to the first embodiment.
  • FIG. 4 is a block diagram showing a hardware configuration of the proxy server of the communication system according to the first embodiment.
  • FIG. 5 is a flowchart showing the operation of the proxy server according to the first embodiment.
  • FIG. 6 is a sequence diagram showing the operation of the entire system including the proxy server according to the first embodiment.
  • FIG. 7 is a flowchart showing the operation of the entire system including the proxy server according to the first embodiment.
  • FIG. 8 is a block diagram showing a configuration of the proxy server according to the second exemplary embodiment of the present invention.
  • FIG. 9 is a flowchart showing the operation of the proxy server according to the second embodiment.
  • FIG. 10 is a sequence diagram showing the operation of the entire system including the proxy server according to the second embodiment.
  • FIG. 11 is a flowchart showing the operation of the entire system including the proxy server according to the second embodiment.
  • FIG. 12 is an operation sequence diagram in the case where communication is performed between users' agents in a general SIP network in the related art.
  • FIG. 13 is a block diagram showing the configuration of the entire system including a proxy response device in the related art.
  • FIG. 14 is a block diagram showing a configuration of related technology.
  • FIG. 15 is a diagram illustrating a configuration example of a packet buffer in the related art.
  • FIG. 16 is a flowchart showing the operation of the related art.
  • FIG. 17 is a diagram showing a principle configuration of a related-art server backup device.
  • FIG. 18 is a diagram showing a configuration of the entire system including a server backup device of related technology.
  • FIG. 19 is a diagram showing an operation in a normal operation of the IP Centrex server in the related-art server backup device.
  • FIG. 20 is a diagram showing the operation when an IP Centrex server failure occurs in the related-art server backup device.
  • FIG. 21 is a sequence diagram showing an example in which the state of the active SIP server cannot be reproduced on the spare SIP server when the related technology is applied to the SIP network.
  • FIG. 1 shows a block diagram of a communication system according to the first embodiment of the present invention.
  • the communication system includes a working SIP server 30 having registration information 31 and a standby SIP server 40 having hot standby and registration information 41. Communicating with user 'agent 20' via network 50
  • the SIP system 1 includes a proxy server 10, a working SIP server 30, and a backup SIP server 40, and is connected to the network 50.
  • FIG. 2 shows a block diagram of the proxy server 10 according to the first exemplary embodiment of the present invention.
  • the proxy server 101 has the above-described functions of the general SIP proxy server (the SIP proxy server machine in FIG. 2). 11), SIP proxy 'message function received function 12 to determine the type of message received by server function 11 and SIP proxy' server function 11 received a call that encountered a failure of the working SIP server 30 Call failure encounter determination function 13 that determines whether it belongs to the flow, and destination setting function that sets the forwarding destination of the message according to the failure occurrence status of the SIP server and the type of message received by the SIP proxy server function 11 1 4 and detecting that the failure of the working SIP server 30 has occurred, the destination setting function 14 and the call failure It includes a transfer destination failure detection function 15 that notifies the harm encounter determination function 13 to that effect.
  • SIP proxy 'message function received function 12 to determine the type of message received by server function 11
  • SIP proxy' server function 11 received a call that encountered a failure of the working SIP server 30
  • Call failure encounter determination function 13 that determines whether it belongs to the flow
  • the destination setting function 14 holds, as information, a standard transfer destination (hereinafter referred to as a standard transfer destination) that is transferred when there is no special designation.
  • this standard forwarding destination is set as “working SIP server 30” when the working SIP server 30 is operating, and “standby SIP server 40” when a failure occurs in the working SIP server 30. Has been.
  • the change of the standard transfer destination is executed by the transfer destination failure detection function 15 notifying the destination setting function 14 of the failure of the working SIP server 30.
  • the detection of the occurrence of a failure of the active SIP server 30 in the transfer destination failure detection function 15 can be realized by, for example, the following means.
  • the user agent 20 periodically sends a REGISTER request to the SIP server so that the registration information updated by the REGISTER request and the registration information managed by the SIP server will not expire. Send.
  • the SIP server processes these REGISTER requests every second, for example, and returns the processing result to the user agent 20 as a SIP response.
  • the forwarding failure detection function 15 cannot detect a SIP response from the SIP server by monitoring the REGISTER request and SIP response sent and received between the SIP server and the user's agent 20 per second. Therefore, it is possible to determine that a failure has occurred in the SIP server or network 50).
  • the call failure encounter determination function 13 holds a call identifier (Call—ID header value) 131 of the initial INVITE request.
  • This call identifier 131 is a call identifier (Call—ID header value) of the initial INVITE request received from the outside by the message type determination function 12, and the call failure encounter determination function 13 is notified from the message type determination function 12. Is.
  • FIG. 3 shows an example of an implementation of the call identifier 131 stored in the call failure encounter determination function 13.
  • this list of stored call identifiers 131 is referred to as “call identifier list 132”.
  • FIG. 4 shows the hardware configuration of the proxy server 10 in the communication system according to the present embodiment. It is a block diagram which shows composition.
  • the proxy server 10 can be realized by a hardware configuration similar to that of a general computer device, and includes a CPU (Central Processing Unit) 401, a RAM (Random Access Memory). ) Etc., main memory unit 402 used for data work area and temporary data save area, communication control unit 403 for sending and receiving data via network 50, liquid crystal display, printer, speaker, etc.
  • a CPU Central Processing Unit
  • RAM Random Access Memory
  • main memory unit 402 used for data work area and temporary data save area
  • communication control unit 403 for sending and receiving data via network 50, liquid crystal display, printer, speaker, etc.
  • auxiliary storage unit 407 which is a device, and a system bus 408 for interconnecting the above-described components of the information processing device are provided.
  • the proxy server 10 operates as a circuit component composed of hardware components such as LSI (Large Scale Integration) in which a program for realizing such a function is incorporated in the proxy server 10.
  • LSI Large Scale Integration
  • it can be implemented by hardware by executing the program that provides each function of each component described above by the CPU 401 on the computer processing apparatus. That is, the CPU 401 loads the program stored in the auxiliary storage unit 407 to the main storage unit 402 and executes it, and controls the operation of the proxy server 10 to realize each function described above in software. .
  • FIG. 5 is a flow chart showing the operation of the proxy server according to the first exemplary embodiment of the present invention.
  • the SIP proxy server function 11 receives a message from the outside (step S501).
  • the message type determination function 12 investigates the type of message received by the SIP proxy server function 11 (step S 502).
  • step S502 If the result of step S502 is that the received message is a SIP request (ACK or BYE)
  • the call failure encounter determination function 13 further investigates whether the received message belongs to a call flow that has encountered a failure of the working SIP server 30 (step S503).
  • step S503 can be realized by the following means, for example.
  • the message type determination function 12 notifies the call failure encounter determination function 13 of the call identifier (Call—ID header value) 131 of the initial INVITE request received from the outside, and the call failure encounter determination function 13 The received call identifier 131 is held.
  • the call failure encounter determination function 13 stores a call identifier list 132 as shown in FIG.
  • the contents of the call identifier list 132 are all recorded by the call failure encounter determination function 13 received from the transfer destination failure detection function 15 when the transfer destination failure detection function 15 detects the failure of the active SIP server 30. Once erased.
  • the call identifier (Call-ID header value) 131 of the call flow newly generated during the operation of the active or backup SIP server is described in the call identifier list 132.
  • the call failure encounter determination function 13 receives a SIP request (ACK or BYE) or SIP response holding a call identifier 131 not included in the call identifier list 132 from the message type determination function 12, the call failure encounter determination function 13
  • the call flow identified by the identifier 131 can be determined to have encountered a failure of the working SIP server 30.
  • step S503 if the message received in step S501 has not encountered a failure in the working SIP server 30, the destination setting function 14 performs standard transfer of the destination of the message received as a result of step S501. Set first (step S504).
  • step S503 If it is determined as a result of step S503 that the message received in step S501 belongs to a call flow that has encountered a failure in the working SIP server 30, a new transfer destination of the message is determined (step S505).
  • the SIP request (ACK or BYE) and SIP response have a header (Via header or Record-Route header) that stores the message transfer route.
  • ACK or BYE SIP request and SIP response that encountered a failure in the working SIP server 30
  • the address of the working SIP server 30 is written in this header. Therefore, the address described next to the working SIP server 30 (for example, the address of the called user's agent 20) is extracted from this header, and the address is extracted.
  • the address to which the message should be directly transferred is set as the next transfer destination.
  • this step S 505 can be realized by the following processing, for example.
  • the destination header (To header) of the SIP request and SIP response is described with a fully qualified domain name (FQDN)
  • the destination determination function ignores the header value that stores the transfer route, and DNS The next transfer destination is determined by resolving the To header address from an external system such as (Domain Name System) again.
  • step S501 If the message received in step S501 is a SIP response as a result of step S502, the call failure encounter determination function 13 further investigates whether the received message belongs to a call flow that has encountered a failure ( Step S506). Note that the processing in step S506 is the same as the processing in step S503, and thus the description thereof is omitted.
  • step S506 when it is determined that the message received in step S501 belongs to the call flow that encountered the failure of the working SIP server 30, a new message transfer destination is determined (step S505).
  • the processing in step S505 is as described above.
  • step S506 when the message received in step S501 has not encountered a failure in the active SIP server 30, the destination setting function 14 determines the destination of the message received as a result of step S501. Determine the destination described in the message (step S507).
  • step S502 when the message received in step S501 is not a SIP request (ACK or BYE) or SIP response, the destination setting function 14 determines the destination of the message received as a result of step S501. Specify standard destination (step S504).
  • the SIP proxy server function 11 transfers the message received in step S501 to the destination set by the destination determination function in steps S504, S505, and S507 (step S508).
  • FIG. 6 is an operation sequence diagram showing the operation of the entire system including the proxy server according to the first exemplary embodiment of the present invention
  • FIG. 7 is the flowchart. Shown in Fig. 6 and Fig. 7.
  • the proxy server 10 uses the spare SIP server 40 as the standard transfer destination. Set (step S702), and then forward the SIP request (ACK and BYE) to the backup SIP server 40.
  • the next forwarding destination of the SIP request (in Fig. 6, user agent 20 (calling side) )) Directly (Step S703).
  • the first effect is that the processing of the call flow that encounters the failure of the working SIP server 30 can be terminated normally.
  • the second effect is that a call with digest authentication can be made even when the working SIP server 30 fails.
  • the proxy server 10 detects the failure of the active SIP server 30 and changes the transfer destination of the SIP request in accordance with the failure occurrence status of the active SIP server 30.
  • a SIP request with digest authentication such as an initial INVITE request or initial REGISTER request is received by the proxy server 10.
  • Digest authentication can be executed.
  • the third effect is that the number of user agents 20 can be flexibly accommodated.
  • the fourth effect is that there is no restriction on the forwarding destination of the SIP request.
  • FIG. 8 shows a block diagram of the proxy server 10 according to the second exemplary embodiment of the present invention.
  • the proxy server 10 according to the second embodiment of the present invention has a retransmission request generation function in the configuration of the proxy server 10 according to the first embodiment of the present invention. 16 is added to the configuration!
  • This retransmission request generation function 16 prompts the user's agent 20 to retransmit the initial IN VITE request when a failure occurs in the working SIP server 30 when the authentication INVITE request arrives. Next, it generates a retransmission request to be transferred to the user agent 20. For example, a SIP response (500 Server Internal Error) with a Retry-After header inserted is used for this retransmission request. As a result of receiving this SIP response, the user agent 20 retransmits the initial INVITE request again after the period described in the Retry—After header according to the general process for receiving a SIP response.
  • a SIP response 500 Server Internal Error
  • FIG. 9 is a flow chart showing the operation of the proxy server according to the second exemplary embodiment of the present invention.
  • step S903 to S905 including the retransmission function generation processing of the generation function 16 are added.
  • step S901 is a step other than the step including the retransmission request generation processing of the present embodiment
  • step S901 is step S501 shown in FIG. 5 of the first embodiment
  • step S504 is step S908. Since step S909 is the same as step S506, the description thereof will be omitted, and the operation from step S903 to step S905 will be mainly described.
  • step S902 if the message received in step S901 is an authentication INVITE request, the call failure encounter determination function 13 investigates whether the received message belongs to the call flow that encountered the failure (step S903). Note that the processing in step S903 is the same as the operation step S503 in the proxy server 10 according to the first embodiment of the present invention, and thus the description thereof is omitted.
  • step S903 If the result of step S903 is that the message received in step S901 belongs to a call flow that encountered a failure, the retransmission request generation function 16 generates a retransmission request to be sent to the user'agent 20 (step S904). ).
  • This process is executed as follows, for example. If the retransmission request to be generated is a SIP response (500 Server Inernal Error) with the Retry—After header inserted, use the value of the message received in step S901 for the header other than the Retry—After header. Use a value such as “30 seconds” in the header.
  • the destination setting function 14 sets the transfer destination of the retransmission request as the user agent 20 (step S905).
  • the SIP proxy server function 11 transfers the retransmission request generated in step S904 to the user agent 20 (step S911).
  • FIG. 10 is a sequence diagram showing the operation of the entire system including the proxy server according to the second embodiment of the present invention
  • FIG. 11 is the flowchart.
  • the proxy server 10 receives the authentication INVITE request and the failure occurs in the working SIP server 30
  • the proxy according to the first embodiment of the present invention •
  • a retransmission request is generated (step S1103) and sent to the user'agent 20 (step S1104). ).
  • the user's agent 20 determines that it can be used again after the Retry-After, as specified in the SIP protocol rules! /, And issues the initial INVITE request again after the corresponding period. (Step SI 1 05).
  • the operation of 10 is similar to the REGISTER request, and the initial REGISTER request can be sent again to the user's agent 20 side.
  • the call flow in which the failure of the working SIP server 30 is encountered on the user-agent 20 side is changed to a normal new call flow. As an effect, it can be automatically regenerated.
  • the retransmission request generation function 16 receives the authentication received from the user agent 20. This is because an INVITE request is used to generate a SIP response including the Retry—After header and send it to the user agent 20. As a result, the user's agent 20 determines that the caller is out of service after the time-out (usually 32 seconds) described in the SIP protocol, and does not attempt to call again manually after an arbitrary time. This is because the initial INVITE request can be automatically sent to the proxy server 10 again after the Retry—After header value in accordance with the general SIP response processing.
  • the proxy server of the present invention can be used for a SIP network having a plurality of user terminals and a plurality of SIP servers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

明 細 書
プロキシ 'サーバ、通信システム、通信方法及びプログラム
技術分野
[0001] 本発明は、 SIP (session initiation protocol)を使用してシグナリングを行う通 信網に好適に利用されるプロキシ ·サーノ 、通信システム、通信方法及びプログラム に関する。
背景技術
[0002] 近年、 VoIP (voice over IP)に見られるように、 IP網を使用したリアルタイム.コミ ュニケーシヨンが普及している。例えば、電話端末やパソコンなどの、リアルタイム'コ ミュニケーシヨンを行う両端の端末間接続を確立する国際標準プロトコルとして SIP (s ession initiation protocol)を採用する状況が多くなつている。なお、本明細書で は、 SIPを使用してシグナリングを行う通信網を SIPネットワークと呼ぶ。
[0003] SIPネットワークの一般的な構成は、文献 3に記載されている。 SIPネットワークは、 ロケーション 'サーバと、 SIPサーバと、ユーザ'エージェント（UA : user agent)と 力、ら構成されている。ユーザ'エージェントは、文献 3 (後述）の Ρ· 76に、「SIPは、ェ ンド ·システム間のクライアント サーバ ·モデルに基づ!/、て!/、ます。このエンド ·シス テムに相当するの力 S、ユーザ.エージェント（UA : User Agent)です。ユーザ'ェ ージェントとは、具体的には電話機やパソコンなどのエンド 'システムのことです力 こ れらのエンド.システム間でリクエスト（要求）とレスポンス（応答）をやり取りすることによ つて、サービスを実現します」と説明されている。本明細書では、上記説明文記載のリ タエストを SIP要求、レスポンスを SIP応答と呼ぶ。
[0004] SIPサーバは、文献 3の Ρ· 77に記載されているように、（1) SIP要求や SIP応答 を中継するプロキシ ·サーバ機能と、 (2) SIP要求の宛先の問合せに利用するリダイ レクト.サーバ機能と、 (3) SIPネットワーク上のユーザ 'エージェント情報の登録を 受け付ける登録サーバ機能とを有する。ここで、ユーザ ·エージェント情報とは、例え ば、ユーザ'エージェントにアクセスするための識別子である URI (uniform resour ce identifier)やユーザ.エージェントが使用する IPアドレスである。なお、本明細 書では、ユーザ'エージェントによって SIPサーバに登録されたユーザ'エージェント 情報を登録情報と呼ぶ。この登録情報は、 SIP要求の REGISTERリクエストを用い て更新される。
[0005] 一般的な SIPネットワークにおいて、ユーザ ·エージェント間で通信する場合の動作 シーケンスを図 12に示す。この図では、文献 4 (後述）に記載されているように、一般 的な情報通信事業者が SIPネットワークを構築する場合に採用するユーザ ·エージェ ントの認証方式 (ダイジェスト認証）を含んだものである。
[0006] まず、ユーザ.エージェント（発呼側）が SIPサーバに対して INVITEリクエストを送 信する。本明細書では、このユーザ.エージェント (発呼側）が最初に SIPサーバに送 信する INVITEリクエストを initial INVITEリクエストと呼ぶ。
[0007] ユーザ.エージェント（発呼側）からの initial INVITEリクエストを受信した SIPサー ノ は、ダイジェスト認証で使用する nonceを算出し、その nonce値を SIP応答（407 proxy authentication required)に付力！]してユーザ'エージェント (発呼佃 J)に返 信する。ユーザ ·エージェント (発呼側）では、受信した nonceを鍵にシークレット（ュ 一ザ識別子とパスワード）をハッシュする。この結果を INVITEリクエストの Authoriza tionヘッダに格納し、 SIPサーバに転送する。本明細書では、この Authorizationへ ッダを付加した INVITEリクエストを認証 INVITEリクエストと呼ぶ。
[0008] 認証 INVITEリクエストを受信した SIPサーバは、ユーザ'エージェント（発呼側）の 認証処理を行う。具体的には、 (1) ユーザ ·エージェント (発呼側）と同様、自身が生 成した nonce値を使用して、ユーザ'エージェント (発呼側）のユーザ識別子とパスヮ ードをハッシュする。 (2) ユーザ.エージェント（発呼側）からの認証 INVITEリクエス トに格納された Authorizationヘッダ値と比較し、同一の場合には、正当なユーザ. エージェントからの認証 INVITEリクエストであると判断する。
[0009] SIPサーバは、この認証処理の結果、正当なユーザ.エージェントからの認証 INVI TEリクエストと判断した場合は、認証 INVITEリクエストを Toフィールドで指定された 着呼側のユーザ .エージェント（図 12でのユーザ ·エージェント（着呼側） )へ転送する
〇
[0010] その後、ユーザ.エージェント（着呼側）では、認証 INVITEリクエスト受信後、その 認証 INVITEリクエストの処理を継続中であることを示す暫定応答（図 12での 100 t ryingと 180 Ringing)を SIPサーバに返し、通話者を呼び出す。
[0011] 通話者が応答した場合に、ユーザ ·エージェント（着呼側）は SIPサーバに、認証 IN VITEリクエストの処理が完了した旨を示す SIP応答（200 OK)を返す。ユーザ'ェ ージヱント（発呼側）は、認証 INVITEリクエストの最終応答である SIP応答（200 O K)を受信した旨をユーザ ·エージェント (着呼側）に伝達するために ACKリクエストを 発信する。これにより、ユーザ'エージェント (発呼側）とユーザ'エージェント (着呼側） での通話のためのセッションが確立される。通話終了時には、通話終了を希望する ユーザ'エージェント（図 12ではユーザ'エージェント（発呼側））から、セッションを終 了する BYEリクエストが発行される。 SIPサーバ経由で BYEリクエストを受信したユー ザ.エージェント（着呼側）では、 BYEリクエスト処理後、 SIP応答（200 OK)を返答 することで、セッションの終了処理が完了したことを伝達する。この結果、ユーザ'エー ジェント (発呼側）とユーザ'エージェント (着呼側）の通話が終了する。
[0012] なお、この図 12に示した、 initial INVITEリクエストから BYEリクエストの処理完了 を示す SIP応答（200 OK)までの一連の流れは、一般的に「コールフロー（呼び出 しの流れ）」と呼ばれ、 SIP要求および SIP応答に格納される Call— IDヘッダの値で 識別される。つまり、図 12で示した全ての SIP要求と SIP応答は同一の Call— IDへッ ダ値を保持することになる。さらに、一般的な情報通信事業者では、通話の課金のた めに、誰と誰が話中なの力、を管理する必要がある。そのため、 SIPサーバは、発生し た呼がコールフローにおけるどの状態かを管理するコール'ステートフル.プロキシと して実現される。この結果、図 12に示すように、コールフロー中の SIP要求および SI P応答は全て同一の SIPサーバを経由する形態となる。
[0013] 上述した SIPサーバにおける呼の状態など、クライアントから送信される一連のリク ェストの処理状態を管理するサーバの高可用性を実現するために、サーバでの処理 内容を、サーバの障害時に他サーバで引き継ぐ手段としては、特開 2004- 28073 8 (文献 1)で示される手段がある。以降では、この関連技術の 1例である文献 1に関し て図表を参照して詳細に説明する。なお、関連技術を示す図に記載された各構成要 素を指す符号は、本願明細書に示す各構成要素を指す符号とは異なるものである。 [0014] 図 13は、文献 1で示される代理応答装置の構成を示す図である。図 13において、 文献 1で示される代理応答装置は、複数サーバの障害発生を監視し、あるサーバに 障害が発生した場合には、他のサーバに、障害が発生したサーバの処理を引き継ぐ 機能を提供している。この機能を実現するために、代理応答装置は以下に示す手段 を有すると説明されている。
[0015] 「本発明の代理応答装置は、障害発生を監視する監視対象サーバと上記監視対 象サーバの代りに応答できる予備サーバのアドレスを保持し、上記監視対象サーバ が送受信するメッセージを通信ネットワークから取得する手段と、上記監視対象サー バの障害を検知する手段と、上記監視対象サーバの障害を検知した際には、上記取 得したクライアントからの要求のメッセージのうち応答して!/、な!/、メッセージにつ!/、て、 送信元アドレスを上記代理応答装置のアドレスに書き換え、上記予備サーバに送信 する手段を有し、上記予備サーバからの応答メッセージの送信元アドレスを上記監 視対象サーバのアドレスに書き換えクライアントに中継する手段を有する。」（文献 1 の段落 0012を引用）。
[0016] このような代理応答装置を実現する情報処理装置のハードウェア構成を図 14に示 す。図 14において、この構成は下記のように説明されている。
[0017] 「代理応答装置 1を実現する情報処理装置は、プロセッサ 100と、記憶装置 108と、 IP網 6bに接続するための入力回路インタフェイス 105および出力回路インタフェイス 107と、入力回路インタフェイス 105で受信された IPパケットを一時的に蓄積するた めの受信バッファ 104と、出力回路インタフェイス 107で送信すべき IPパケットを一時 的に蓄積するための送信バッファ 106と、これらを接続するバスなどの内部通信線か らなる。記憶装置 108は、プログラムメモリ 101と、パケットバッファ 102と、サーバ管理 表 103を格納している。プログラムメモリ 101には、プロセッサ 100が実行し、代理応 答装置 1を実現する各種制御プログラムが記録され、ノ ケットバッファ 102には、クラ イアント 3とサーバ 2a、 2bがやりとりする IPパケットが蓄積される。記憶装置 108は、 半導体記憶装置、または、ハードディスクなどの外部記憶装置で構成する。」（文献 1 の段落 0019を引用）。
[0018] また、このような構成の代理応答装置は、障害が発生したサーバの処理内容を他 サーバに引き継がせるために、下記のパケットバッファの管理機能を導入することに よってサーバの処理状況を把握しており、以下のように説明されている。
[0019] 「代理応答装置 1は、クライアント 3とサーバ 2a、 2bでやりとりされるメッセージを管理 するためのパケットバッファ 102を備え、クライアント 3が送信した要求のメッセージと それに対応するサーバ 2a、 2bの応答のメッセージをまとめて一つの単位（以下、セッ シヨンと呼ぶ）として管理する。セッションは、パケットバッファ 102のセッション管理工 ントリ 110— 1、 110— 2、 · · ·に登録される。」（文献 1の段落 0022を引用）。
[0020] このパケットバッファの構成例は、図 15のようになっており、下記のように説明されて いる。
[0021] 「パケットバッファ 102の各エントリは、セッション識別子 111、クライアントアドレス 11 2、サーバアドレス 113、クライアント送信パケットバッファ 114、サーバ送信パケットバ ッファ 115とからなる。セッション識別子 111には、各エントリを識別するために、一意 な識別子を与えられる。クライアントアドレス 112には、要求を送信したクライアント 3の IPアドレスが設定される。サーバアドレス 113には、上記要求を受信したサーバ 2aの IPアドレスが設定される。クライアント送信パケットバッファ 114には、クライアント 3が サーバ 2aに送信したすべての IPパケットがそのまま格納される。サーバ送信パケット バッファ 115には、サーバ 2aがクライアント 3に送信したすべての IPパケットがそのま ま格納される。」（文献 1の段落 0024、 0025を引用）
[0022] 次に、代理応答装置の動作を図表を参照して詳細に説明する。
[0023] 図 16は、代理応答装置の動作を示すフローチャートである。この動作は、以下のよ うに説明されている。
[0024] 「代理応答装置 1が接続する IP網 6bに流れるすべての IPパケットが、入力回路イン タフェイス 105により取得され、受信バッファ 104に格納される。プロセッサ 100は、受 信バッファ 104に上記 IPパケットがあれば、一つ取得し（ステップ 170)、取得した IP パケットが監視対象のサーバ 2aに関係するか否かを、上記 IPパケットの送信元ァドレ ス 150または送信先アドレス 151が、サーバ管理表 103の監視対象サーバアドレス 1 21に一致しているかで判定する。もし、ステップ 170で受信バッファ 104力も IPバケツ トを取得しなかった場合は、ステップ 175に進む (ステップ 171)。一致している場合 プロセッサ 100は、上記 IPパケットのパケット種別 153が切断要求か判定し（ステップ 172)、切断要求でないなら上記 IPパケットをパケットバッファ 102の該当するエントリ に格納する（ステップ 173)。該当するエントリは、上記 IPパケットの送信元アドレス 15 0と送信先アドレス 151の組力 クライアントアドレス 112とサーバアドレス 113の組と 一致する力、 (順不同でも一致と見なす)で判定する。格納先は、上記 IPパケットの送 信先がサーバならクライアント送信パケットバッファ 114に、上記 IPパケットの送信元 がサーバならサーバ送信パケットバッファ 115となる。この際、該当するエントリが無い 場合には、新しくエントリを作成する。ステップ 172にてパケット種別 153が切断要求 の場合には、該当するエントリを削除する（ステップ 174)。プロセッサ 100は、サーバ 管理表 103の各エントリの監視対象サーバアドレス 121を持つサーバの障害の有無 を判定し (ステップ 175)、障害が発生している場合には、代理応答処理を実行する（ ステップ 177)。サーバの障害の有無の判定方法は、特に限定されないが、一例とし ては、パケットバッファ 102に格納されたすベてのセッションを監視し、サーバから一 定時間応答が無いセッションを見つけたら上記サーバに障害が発生したと判定する 。他の例としては、サーバで、代理応答装置 1に障害がないことを意味するメッセージ を送信し続けるプログラムを実行させ、代理応答装置 1が上記メッセージを受信でき なくなったときに、上記サーバに障害が発生したと判定する。あるセッションにおいて 、最初に代理応答処理を行う場合は、受信している全ての IPパケットを用いて、障害 発生までの処理を実行し、同じ状態を再現する。また、ステップ 177は一つの IPパケ ット毎に実行され、実行後は、ステップ 170に戻る。」（文献 1の段落 0036〜0042を 引用）
[0025] このように、関連技術の 1例である文献 1で示される代理応答装置の特徴は、クライ アントおよびサーバから送信される IPパケットを全て格納しておき、サーバでの障害 発生時には、代理応答装置がクライアントの代わりに、障害発生までの IPパケットを、 全て、かつ、順番に他サーバに対して送信することで、サーバでの障害発生時と同 様の状態を他サーバに再現することである。この手段により、サーバで未完了であつ たクライアントからのリクエストの処理を、他サーバに引き継ぐのである。
[0026] 次に、本願発明の技術範囲と同様の電話システムにおいて、サーバの障害発生時 に電話の不通状態を回避する関連技術としての方式が特開 2005— 229273 (文献 2)に記載されている。
[0027] 図 17は、文献 2に記載のサーババックアップ装置の原理構成を示す図である。この サーババックアップ装置の構成は下記のように説明されている。なお、下記説明にお ける「図 1」は、本明細書での「図 17」に相当する。
[0028] 「図 1は本発明のサーババックアップ装置の原理構成ブロック図である。同図はネッ トワークに接続された複数の電話端末、例えば IP電話端末と、そのネットワークの内 部の端末相互間の通話、および外部との通話の切換接続を行うサーバとの間に位置 し、そのサーバのバックアップを行うサーババックアップ装置の原理構成を示し、サー ババックアップ装置 1は、少なくともサーバ障害検出手段 2、およびメッセージ転送手 段 3を備える。サーバ障害検出手段 2はサーバの障害を検出するものであり、例えば 後述する呼状態管理部と SIPメッセージ読取部に相当する。メッセージ転送手段 3は 障害の発生期間中にネットワーク内での端末間の通信のために端末側から送られる 所定のメッセージ内の宛先アドレスを、自装置のアドレスから相手側端末のアドレス に書き換えて、そのメッセージをサーバを経由することなく相手側端末に直接に転送 するものであり、例えば SIPメッセージ書き換え部に相当する。発明の実施の形態に おいては、バックアップ装置 1が複数の IP電話端末のそれぞれに対応して、端末の 識別子としてのエンド ' ·ポイント名称と IPアドレスとを記憶するエンド ' ·ポイント記憶手 段、例えばエンド '·ポイント 'テーブルをさらに備え、メッセージ転送手段 3がエンド '·ポ イント記憶手段の記憶内容に基レ、てメッセージの転送を行うこともできる。また所定の メッセージは、相手端末側に呼の確立を要求するために送られるインバイトメッセ一 ジであることもできる。また本発明のサーババックアップ装置は、サーバ障害検出手 段と、サーバ障害の発生期間中に、前記ネットワーク内の端末から送られる所定のメ ッセージに対応して該メッセージに対する応答メッセージを生成し、該応答メッセージ を前記所定のメッセージの送信元端末に送信するメッセージ生成手段、例えば SIPメ ッセージ生成部とを備える。実施の形態においては、所定のメッセージは端末側から 自端末の登録のために送信されるレジスタメッセージであることもできる。また実施の 形態においては、サーババックアップ装置が、同一端末からの前記所定のメッセージ の受信回数を記憶する所定メッセージ受信回数記憶手段、例えばアクティブ 'コール •テーブルをさらに備え、前記サーバ障害検出手段が、該記憶されたメッセージの受 信回数があらかじめ定められた数を超えたとき、前記サーバの障害を検出することも できる。」（文献 2の段落 0010〜0014を引用）。
[0029] さらに、文献 2に記載のサーババックアップ装置を含むシステム全体の構成図を図
18に示す。なお、これまで記載してきたサーバは、図 18における IPセントレックスサ ーバ（IP Centrex Server)に相当する。図 18に示すように、 IPセントレックスサー バの予備系は明示されておらず、 IPセントレックスサーバの障害発生時には、サーバ ノ ックアップ装置がユーザ.エージェントからのシグナリングを全て賄う形態となってい る。つまり、サーババックアップ装置が、発呼側ユーザ'エージェントからの SIP要求を 着呼側ユーザ.エージェントへ転送するのである。そこで、サーババックアップ装置で の実施の形態では、電話番号などの着呼側ユーザ ·エージェントの識別子から IPアド レスを決定するために、複数のユーザ'エージェントの各々に対応して、ユーザ'エー ジェントの識別子であるエンド 'ポイント名称とユーザ.エージェントの IPアドレスとを記 憶するエンド 'ポイント記憶手段を保持する形態が採用されている。
[0030] 次に、文献 2に記載のサーババックアップ装置の動作を図表を参照して説明する。
図 19は、 IPセントレックスサーバ正常動作時の動作を、図 20は、 IPセントレックスサ ーバ障害発生時の動作を示す図である。
[0031] これらの動作は、文献 2にて下記のように説明されている。なお、下記引用中の「図
4」が本明細書での「図 19」に、「図 5」が本明細書での「図 20」に相当する。
[0032] 「図 4は、セントレックスサーバ正常動作時のシステム内動作のさらに詳細な説明図 である。ここでは端末 121からの発呼によって端末 122との間で通話が行われるもの とする。なおここでバックアップ装置 10の IPアドレスは 111. 1. 1. 10、端末 121の IP アドレス (ま 111. 1. 1. 1、端末 122の IPアドレス (ま 111. 1. 1. 2、また IPセントレック スサーノ 16の IPアド、レスは 133. 1. 1. 1とする。図 4において、端末 121力、ら送られ る、セッションの確立、維持、終了を行うためのセッション 'イニシエーション 'プロトコ ノレ（SIP)メッセージ、例えば後述するレジスタメッセージ、インバイトメッセージなどは 、 （1)で LAN13を介してバックアップ装置 10に至り、バックアップ装置 10から LAN1 3、ルータ 14、 IPネットワーク 15を経由して IPセントレックスサーバ 16に至る経路によ つて（2)で転送され、その後（3)で IPセントレックスサーバ 16から IPネットワーク 15、 ルータ 14、 LAN13を介してバックアップ装置 10に至る経路によってバックアップ装 置 10に転送され、さらにバックアップ装置 10から LAN13を介して端末 122に転送さ れる。なお端末間で呼の接続が完了した後の実際の音声信号、すなわちリアルタイ ム 'トランスポート 'プロトコル（RTP)によるメディアストリームのやりとりは、バックアップ 装置 10を介することなぐ LAN13を介して直接に端末間で行われる。 IPセントレック スサーバ 16の正常動作時にも、実際の音声信号は同様に端末間で直接にやり取り される。図 5はセントレックスサーバ障害発生時の動作の詳細説明図である。図 4に おけると同様に、端末 121から LAN13を介して（1)でバックアップ装置 10に対して 呼確立のための、例えばインバイトメッセージが転送されると、バックアップ装置 10は 後述するように IPセントレックスサーバ 16の障害発生を検出しており、そのためバック アップ装置 10はそのメッセージを IPセントレックスサーバ 16側に転送することなく直 接に相手側の IP電話端末 122に（2)で転送し、 2つの端末間の通話が可能となる。 なお端末間で呼の接続が完了した後の実際の音声信号、すなわちリアルタイム 'トラ ンスポート'プロトコルによるメディアストリームのやりとりは、バックアップ装置 10を介 することなぐ LAN13を介して直接に端末間で行われる。 IPセントレックスサーバ 16 の正常動作時にも、実際の音声信号は同様に端末間で直接にやり取りされる。」（文 献 2の段落 0022〜0024を引用）。
このように、文献 2に記載のサーババックアップ装置では、 IPセントレックスサーバで の障害発生時には、エンド 'ポイント名称と IPアドレスとの情報を参照して、受信した S IP要求の宛先を変更し、サーババックアップ装置が SIP要求をユーザ'エージェント に直接転送することで、 IPセントレックスサーバの障害による電話の不通状態を回避 している。
特許文献 1 :特開 2004— 280738号公報
特許文献 2：特開 2005— 229273号公報
非特許文献 1 :千村保文 ·村田利文 監修 「改訂版 SIP教科書」 P. 77、 P. 78特 許出版 2004年 非特許文献 2 :社団法人情報通信技術委員会 策定 仕様書番号 TS— 1006 「 事業者 SIP網に接続する SIP端末基本接続インタフェース技術仕様」 2004年 発明の開示
発明が解決しょうとする課題
[0034] 第 1の課題は、文献 1に記載の技術を 1例とする関連技術においては、現用 SIPサ ーバの障害に遭遇したコールフローを正常に終了できないことである。
[0035] その理由は、現用 SIPサーバの障害発生時点の状態を予備 SIPサーバに再現でき ないためである。
[0036] この予備 SIPサーバに現用 SIPサーバの障害発生時点の状態を再現できない場 合を具体的に例示する。図 21は、 SIPネットワークに代理応答装置を適用した場合 に、予備 SIPサーバで現用 SIPサーバの状態を再現できない例を示すシーケンス図 である。
[0037] この図では、ユーザ.エージェント（着呼側）での認証 INVITEリクエスト処理完了を 示す SIP応答（200 OK)を、現用 SIPサーバ経由でユーザ ·エージェント (発呼側） へ転送した後に、現用 SIPサーバに障害が発生した場合を示している。
[0038] この場合、代理応答装置は、予備 SIPサーバに、現用 SIPサーバの状態を再現す ベぐユーザ.エージェント（発呼側）から送信された initial INVITEリクエストを予備 SIPサーバに送信する。
[0039] すると、予備 SIPサーバでは、新規に nonce値を計算し、この nonce値を含んだ SI P応答（407 proxy authentication required)を代理応答装置に送信する。代 理応答装置は、ユーザ'エージェント (発呼側）から受信した認証 INVITEリクエストを 予備 SIPサーバに送信する。
[0040] し力、し、この認証 INVITEリクエストの Authenticationヘッダに格納された値は、 現用 SIPサーバが生成した nonce値を使用してハッシュされたものであり、予備 SIP サーバが生成した nonce値を使用してハッシュしたものとは異なるため、予備 SIPサ ーバでの認証処理で失敗する。
[0041] ユーザ 'エージェント (発呼側）のユーザ識別子とパスワードを保持しない代理応答 装置が、この状況を回避するためには、ユーザ'エージェント (発呼側）から受信した 認証 INVITEリクエストの Authenticationヘッダ値を解析し、ユーザ'エージェント ( 発呼側）のユーザ識別子とパスワードを抽出する必要がある。しかし、これは、ダイジ ェスト認証を破ることを意味しており、不可能である。
[0042] 以上の結果、予備 SIPサーバでは、実際には、ユーザ'エージェント (発呼側）とュ 一ザ.エージェント (着呼側）間で通話中であるにも係らず、ユーザ'エージェント (発 呼側）とユーザ'エージェント（着呼側）の通話のセッションは確立されて!/、な!/、と認識 される。この状態でユーザ'エージェント (発呼側）が通話を終了する BYEリクエストを 送信しても、予備 SIPサーバは、終了対象のセッションが存在しないため、 BYEリク エストは実行されない。このように、現用 SIPサーバの障害に遭遇したコールフローは 、正常に終了されないのである。
[0043] また、第 2の課題は、文献 2に記載の技術を 1例とする関連技術においては、 IPセ ントレックスサーバ障害発生時において、ユーザ'エージェントが発呼した場合、ダイ ジェスト認証が実施できな!/、ことである。
[0044] この理由は、図 12に示したように、ダイジェスト認証では、ユーザ.エージェント（発 呼側）からの initial INVITEリクエストに対し、 SIPサーバで nonce値を算出し、そ の結果を付加した SIP応答（407 proxy authentication required)をユーザ'ェ ージェントに返答しなければならないにも係らず、文献 2に記載のサーババックアップ 装置では、 nonce値を算出する機能もユーザ.エージェントのユーザ識別子とパスヮ ードを保持する機能も保持していないため、 SIP応答（407 proxy authenticatio n required)が生成できな!/、ためである。
[0045] また、第 3の課題は、文献 2に記載の技術を 1例とする関連技術においては、ユー ザ.エージェント数増加に対するサーババックアップ装置の対応性が乏しいことである
〇
[0046] この理由は、関連技術は、ユーザ ·エージェント（着呼側）の IPアドレスを決定するた めに、サーババックアップ装置自身がユーザ'エージェントの識別子と IPアドレスとの 情報を保持する形態だ力 である。この結果、サーババックアップ装置が管理すべき ユーザ.エージェント数の増加につれ、この情報を格納しておくためのディスクやメモ リ容量の拡張が必要となるのである。 [0047] また、第 4の課題は、文献 2に記載の技術を 1例とする関連技術においては、サー ノ バックアップ装置が保持するユーザ.エージェントの識別子と IPアドレスとの情報に 記載されたユーザ'エージェント以外のユーザ'エージェントに、 SIP要求を転送でき ないことである。
[0048] この理由は、関連技術は、サーババックアップ装置が保持する情報に基づ!/、て、 SI P要求の転送先の IPアドレスを解決しているためである。なお、この課題は、文献 2に 、「これに対してエンド'ポイント'テーブル 23内のエンド'ポイント'ネームの値と一致 しなかった場合には、 Server Keep Aliveの値を参照し、その値が 6以上であ れば、例えば外部との通話ができないことを示す 404Not Foundというコードを生 成し、 SIPメッセージの送信元アドレスを送信先アドレスとしてセットし、 SIPメッセージ 生成部 26にその送信先アドレス、コード、および SIPメッセージを渡す。 SIPメッセ一 ジ生成部 26により、 SIPメッセージの送信元の端末に、通信相手側端末との接続が できないことを示すメッセージが生成されて送信される。」（文献 2の段落 0054を引用 )と記載がある通り、サーババックアップ装置での解決は図られておらず、 SIP要求が 転送できな!/、ことをユーザ ·エージェントに通知する方式を採用して!/、る。
[0049] (目的）
本発明の目的は、ダイジェスト認証を伴うコールフローが終了前に現用 SIPサーバ の障害に遭遇した場合でも、該当コールフローを正常に終了し、かつ、現用 SIPサー バ障害時でも新規発生呼のダイジェスト認証を実施し、かつ、ユーザ'エージェント数 の増加に柔軟に対応でき、かつ、 SIP要求の転送先に制限がない、 SIPネットワーク におけるプロキシ 'サーバを提供することである。
課題を解決するための手段
[0050] 上述した課題を解決するための本発明のプロキシ ·サーバは、ユーザ端末と現用 S IPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセージを仲介する SIP プロキシ.サーバ機能と、プロキシ.サーバ機能が受信したメッセージの種類を判別す るメッセージ種別判定機能と、現用 SIPサーバの障害が発生したことを検知して通知 する転送先障害検出機能と、転送先障害検出機能からの通知に基づいて、プロキシ
'サーバ機能が受信したメッセージが、現用 SIPサーバの障害に遭遇したコールフロ 一に属するもの力、を判定する呼障害遭遇判定機能と、転送先障害検出機能からの 通知を受信し、現用 SIPサーバの障害発生状況やプロキシ 'サーバ機能で受信した メッセージの種類に応じてメッセージの転送先を設定する宛先設定機能とを含む。
[0051] また、上述した課題を解決するための本発明は、ユーザ端末との間で SIPメッセ一 ジの送受信を行う現用及び予備の SIPサーバと、 SIPメッセージの送受信を仲介する プロキシ ·サーバとを含む通信システムであって、プロキシ，サーバに、ユーザ端末と 現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセージを仲介す る SIPプロキシ 'サーバ機能と、受信したメッセージの種類を判別するメッセージ種別 判定機能と、現用 SIPサーバの障害が発生したことを検知して通知する転送先障害 検出機能と、転送先障害検出機能からの通知に基づいて、プロキシ 'サーバ機能が 受信したメッセージが、現用 SIPサーバの障害に遭遇したコールフローに属するもの 力、を判定する呼障害遭遇判定機能と、転送先障害検出機能からの通知に基づいて
、現用 SIPサーバの障害発生状況やプロキシ 'サーバ機能で受信したメッセージの 種類に応じてメッセージの転送先を設定する宛先設定機能とを含む。
[0052] また、上述した課題を解決するための本発明は、外部のユーザ端末との間で SIPメ ッセージの送受信を行う現用及び予備の SIPサーバに対し、 SIPメッセージの送受信 を仲介するプロキシ ·サーバにおける通信方法であって、ユーザ端末と現用 SIPサー バ及び予備 SIPサーバとの間で送受信される SIPメッセージを仲介する仲介ステップ と、仲介ステップで受信したメッセージの種類を判別するメッセージ種別判定ステップ と、現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出ステツ プと、転送先障害検出ステップからの通知を受信し、仲介ステップでが受信したメッ セージが、現用 SIPサーバの障害に遭遇したコールフローに属するもの力、を判定す る呼障害遭遇判定ステップと、転送先障害検出ステップからの通知を受信し、現用 s
IPサーバの障害発生状況や仲介ステップで受信したメッセージの種類に応じてメッ セージの転送先を設定する宛先設定ステップとを含む。
発明の効果
[0053] 以上説明したように、本発明によれば以下の効果を達成することができる。
[0054] 第 1の効果は、現用 SIPサーバの障害に遭遇したコールフローの処理を正常に終 了でさることである。
[0055] これは、通話を行う両端のユーザ.エージェントに SIP要求および SIP応答が規約 通りに到着すれば、コールフローの処理が継続可能という SIPのプロトコル規約の特 性に着目し、プロキシ 'サーバが、現用 SIPサーバの障害に遭遇したコールフローに 属する SIP要求と SIP応答のメッセージを受信した場合に、当該 SIP要求と SIP応答 の中身を参照し、現用 SIPサーバに代わって、該当 SIP要求と SIP応答のメッセージ が次に送信されるべき宛先を特定し、転送するためである。
[0056] 第 2の効果は、現用 SIPサーバの障害時でもダイジェスト認証を伴った発呼が可能 なことである。
[0057] これは、プロキシ 'サーバが、現用 SIPサーバの障害発生を検知し、現用 SIPサー バの障害発生状況に合わせて SIP要求のメッセージの転送先を変更するためである 。この結果、現用 SIPサーバでの障害発生時に、 initial INVITEリクエストや initial REGISTERリクエストなど、ダイジェスト認証を伴う SIP要求のメッセージをプロキシ •サーバが受信した場合には、予備 SIPサーバへ転送することで、ダイジェスト認証が 実行可能となるのである。
[0058] 第 3の効果は、ユーザ.エージェントの数の増加に柔軟に対応可能なことである。
[0059] これは、現用 SIPサーバの障害に遭遇したコールフローに属するメッセージの次の 転送先を、受信したメッセージの種類に基づいて決定するためである。この結果、 SI P要求のメッセージの転送先となるユーザ'エージェントの IPアドレスを解決する情報 を格納するディスクやメモリが不要となる。このように、ユーザ'エージェントなどの SIP 要求のメッセージの転送先数の増加と、転送先の IPアドレスの解決処理とが無関係 となるのである。
[0060] 第 4の効果は、メッセージの転送先に制限がないことである。
[0061] これは、前述したように、現用 SIPサーバの障害に遭遇したコールフローに属するメ ッセージの次の転送先を、受信したメッセージの種類に基づ!/、て決定して!/、るためで ある。この結果、プロキシ 'サーバ内に転送先の IPアドレスを解決するための情報を 保持する必要がなくなるため、その情報記載の転送先以外には転送できないといつ た事態がそもそも発生しなレ、のである。 図面の簡単な説明
[図 1]図 1は、本発明の第 1の実施の形態に係る通信システムの構成を示すブロック 図である。
[図 2]図 2は、第 1の実施の形態に係るプロキシ ·サーバの構成を示すブロック図であ
[図 3]図 3は、第 1の実施の形態に係るプロキシ ·サーバにおける、呼障害遭遇判定機 能が保持する呼識別子一覧表の実現形態の 1例を示す図である。
[図 4]図 4は、第 1の実施の形態に係る通信システムのプロキシ ·サーバのハードゥエ ァ構成を示すブロック図である。
[図 5]図 5は、第 1の実施の形態に係るプロキシ 'サーバの動作を示すフローチャート である。
[図 6]図 6は、第 1の実施の形態に係るプロキシ ·サーバを含む、システム全体の動作 を示すシーケンス図である。
[図 7]図 7は、第 1の実施の形態に係るプロキシ ·サーバを含む、システム全体の動作 を示すフローチャートである。
園 8]図 8は、本発明の第 2の実施の形態に係るプロキシ ·サーバの構成を示すブロッ ク図である。
[図 9]図 9は、第 2の実施の形態に係るプロキシ 'サーバの動作を示すフローチャート である。
[図 10]図 10は、第 2の実施の形態に係るプロキシ ·サーバを含む、システム全体の動 作を示すシーケンス図である。
園 11]図 11は、第 2の実施の形態に係るプロキシ ·サーバを含む、システム全体の動 作を示すフローチャートである。
[図 12]図 12は、関連技術における一般的な SIPネットワークにおいて、ユーザ'エー ジェント間で通信する場合の動作シーケンス図である。
[図 13]図 13は、関連技術における代理応答装置を含むシステム全体の構成を示す ブロック図である。
[図 14]図 14は、関連技術の構成を示すブロック図である。 [図 15]図 15は、関連技術におけるパケットバッファの構成例を示す図である。
[図 16]図 16は、関連技術の動作を示すフローチャートである。
[図 17]図 17は、関連技術のサーババックアップ装置の原理構成を示す図である。
[図 18]図 18は、関連技術のサーババックアップ装置を含むシステム全体の構成を示 す図である。
[図 19]図 19は、関連技術のサーババックアップ装置における、 IPセントレックスサー バ正常動作時の動作を示す図である。
園 20]図 20は、関連技術のサーババックアップ装置における、 IPセントレックスサー バ障害発生時の動作を示す図である。
[図 21]図 21は、関連技術を SIPネットワークに適用した場合に、予備 SIPサーバへ現 用 SIPサーバの状態を再現できない例を示すシーケンス図である。
符号の説明
1： SIPシステム
10:プロキシ 'サーバ
11: SIPプロキシ 'サーバ機能
12:メッセージ種別判定機能
13:呼障害遭遇判定機能
131:呼識別子
132:呼識別子一覧
14:宛先設定機能
15:転送先障害検出機能
16:再送要求生成機能
20:ユーザ'エージェント
30:現用 SIPサーバ
31:登録情報
40:予備 SIPサーバ
41:登録情報
50:ネットワーク 401 : CPU
402 :主記憶部
403 :通信制御部
404 :提示部
405 :入力部
406 :インタフェースき
407 :補助記憶部
408 :システムバス
発明を実施するための最良の形態
[0064] (第 1の実施の形態）
本発明の第 1の実施の形態について、図表を参照して詳細に説明する。
[0065] (第 1の実施の形態の構成）
図 1に、本発明の第 1の実施の形態に係る通信システムのブロック図を示す。
[0066] 図 1に示すように、本発明の第 1の実施の形態に係る通信システムは、登録情報 31 を有する現用 SIPサーバ 30及びホットスタンバイしており登録情報 41を有する予備 S IPサーバ 40と接続されるプロキシ 'サーバ 10力 ネットワーク 50を介してユーザ 'ェ ージェント 20との通信を行う。ここで、 SIPシステム 1は、プロキシ.サーバ 10と、現用 SIPサーノ 30と、予備 SIPサーバ 40とを備え、ネットワーク 50に接続する。
[0067] 図 2に、本発明の第 1の実施の形態に係るプロキシ ·サーバ 10のブロック図を示す
[0068] 図 2に示すように、本発明の第 1の実施の形態に係るプロキシ ·サーバ 101は、前述 した、一般的な SIPプロキシ ·サーバが有する機能（図 2での SIPプロキシ ·サーバ機 能 11)に加え、 SIPプロキシ 'サーバ機能 11が受信したメッセージの種類を判別する メッセージ種別判定機能 12と、 SIPプロキシ 'サーバ機能 11が受信したメッセージが 、現用 SIPサーバ 30の障害に遭遇したコールフローに属するものかを判定する呼障 害遭遇判定機能 13と、 SIPサーバの障害発生状況や SIPプロキシ ·サーバ機能 11 で受信したメッセージの種類に応じてメッセージの転送先を設定する宛先設定機能 1 4と、現用 SIPサーバ 30の障害が発生したことを検知し、宛先設定機能 14及び呼障 害遭遇判定機能 13にその旨を通知する転送先障害検出機能 15とを備える。
[0069] なお、宛先設定機能 14は、特段の指定がない場合に転送する標準的な転送先（ 以下、標準転送先と呼ぶ）を情報として保持している。例えば、この標準転送先として は、現用 SIPサーバ 30が動作している場合には「現用 SIPサーバ 30」、現用 SIPサ ーバ 30に障害が発生した場合には「予備 SIPサーバ 40」と設定されている。
[0070] さらに、この標準転送先の変更は、転送先障害検出機能 15が宛先設定機能 14に 対して現用 SIPサーバ 30の障害発生を通知することにより実行される。
[0071] また、この転送先障害検出機能 15における現用 SIPサーバ 30についての障害発 生検出は、例えば、下記の手段により実現可能である。例えば、 SIPでは、一般的に 、 REGISTERリクエストにより更新され、かつ、 SIPサーバで管理される登録情報の 有効期限が切れないように、ユーザ ·エージェント 20が定期的に SIPサーバに対して REGISTERリクエストを送信する。このため、一台の SIPサーバが管理する登録情 報の数が数千〜数万となる状況では、一秒間に SIPサーバに到着する REISTERリ タエストは平均数百程度となる。さらに、 SIPサーバは、これらの REGISTERリクエス トを例えば毎秒処理し、処理結果を SIP応答としてユーザ ·エージェント 20に返す。 そこで、転送先障害検出機能 15は、この毎秒当たりに SIPサーバとユーザ'エージェ ント 20とで送受信される REGISTERリクエストと SIP応答を監視することで、 SIPサー ノくからの SIP応答を検出できない場合には、 SIPサーバほたはネットワーク 50)に障 害が発生したと判断することが可能となる。
[0072] 呼障害遭遇判定機能 13は、 initial INVITEリクエストの呼識別子（Call— IDへッ ダ値） 131を保持する。この呼識別子 131は、メッセージ種別判定機能 12が外部から 受信した initial INVITEリクエストの呼識別子（Call— IDヘッダ値）であって、呼障 害遭遇判定機能 13がメッセージ種別判定機能 12から通知されたものである。
[0073] 呼障害遭遇判定機能 13に保存された呼識別子 131の実現形態の 1例を図 3に示 す。なお、本明細書では、この保存された呼識別子 131の一覧を「呼識別子一覧 13 2」と呼ぶ。
[0074] ここで、プロキシ.サーバ 10のハードウェア構成の説明をする。
[0075] 図 4は、本実施の形態による通信システムのプロキシ ·サーバ 10のハードウェア構 成を示すブロック図である。
[0076] 図 4を参照すると、本発明によるプロキシ.サーバ 10は、一般的なコンピュータ装置 と同様のハードウェア構成によって実現することができ、 CPU (Central Processin g Unit) 401 , RAM (Random Access Memory)等のメインメモリであり、データ の作業領域やデータの一時退避領域に用いられる主記憶部 402、ネットワーク 50を 介してデータの送受信を行う通信制御部 403、液晶ディスプレイ、プリンタやスピーカ 等の提示部 404、キーボードやマウス等の入力部 405、周辺機器と接続してデータ の送受信を行うインタフェース部 406、 ROM (Read Only Memory)、磁気デイス ク、半導体メモリ等の不揮発性メモリから構成されるハードディスク装置である補助記 憶部 407、本情報処理装置の上記各構成要素を相互に接続するシステムバス 408 等を備えている。
[0077] 本発明によるプロキシ.サーバ 10は、その動作を、プロキシ.サーバ 10内部にその ような機能を実現するプログラムを組み込んだ、 LSI (Large Scale Integration) 等のハードウェア部品からなる回路部品を実装してハードウェア的に実現することは 勿論として、上記した各構成要素の各機能を提供するプログラムを、コンピュータ処 理装置上の CPU401で実行することにより、ソフトウェア的に実現することができる。 すなわち、 CPU401は、補助記憶部 407に格納されているプログラムを、主記憶部 402にロードして実行し、プロキシ 'サーバ 10の動作を制御することにより、上述した 各機能をソフトウェア的に実現する。
[0078] (第 1の実施の形態の動作）
次に、本発明の第 1の実施の形態に係るプロキシ ·サーバの動作について図表を 参照して詳細に説明する。
[0079] 図 5は、本発明の第 1の実施の形態に係るプロキシ ·サーバの動作を示すフローチ ヤートでめる。
[0080] いま、 SIPプロキシ ·サーバ機能 11が外部からメッセージを受信したとする（ステップ S501)。次に、メッセージ種別判定機能 12が、 SIPプロキシ ·サーバ機能 11によって 受信したメッセージの種類を調査する（ステップ S 502)。
[0081] ステップ S502の結果、受信したメッセージが SIP要求（ACKまたは BYE)の場合 には、さらに、呼障害遭遇判定機能 13が、上記受信したメッセージが現用 SIPサー ノ 30の障害に遭遇したコールフローに属するかを調査する（ステップ S503)。
[0082] このステップ S503の処理は、例えば、以下に示す手段により実現できる。まず、メッ セージ種別判定機能 12が、外部から受信した initial INVITEリクエストの呼識別子 (Call— IDヘッダ値） 131を呼障害遭遇判定機能 13に対して通知し、呼障害遭遇判 定機能 13は、受信した呼識別子 131を保持する。
[0083] 呼障害遭遇判定機能 13は、図 3に示すような呼識別子一覧 132を保存する。この 呼識別子一覧 132の内容は、転送先障害検出機能 15が現用 SIPサーバ 30の障害 発生を検出した際に、その旨を転送先障害検出機能 15から受信した呼障害遭遇判 定機能 13により全て一旦消去される。この動作により、この呼識別子一覧 132には、 現用または予備 SIPサーバの動作時に新規に生成されたコールフローの呼識別子（ Call— IDヘッダ値） 131のみが記載されることになる。つまり、呼障害遭遇判定機能 13は、この呼識別子一覧 132に記載のない呼識別子 131を保持する SIP要求 (AC Kまたは BYE)または SIP応答をメッセージ種別判定機能 12から受信した場合、当 該呼識別子 131で識別されるコールフローは現用 SIPサーバ 30の障害に遭遇したと 判別できるのである。
[0084] ステップ S503の結果、ステップ S501で受信したメッセージが現用 SIPサーバ 30の 障害発生に遭遇していない場合には、宛先設定機能 14がステップ S501の結果受 信したメッセージの送信先を標準転送先に設定する (ステップ S504)。
[0085] ステップ S503の結果、ステップ S501で受信したメッセージが現用 SIPサーバ 30の 障害に遭遇したコールフローに属すると判別された場合には、メッセージの転送先を 新規に決定する (ステップ S505)。
[0086] この処理は、例えば、以下に示す手段により実現可能である。 SIP要求 (ACKまた は BYE)および SIP応答には、メッセージの転送経路を格納するヘッダ (Viaヘッダま たは Record— Routeヘッダ）が存在する。現用 SIPサーバ 30の障害発生に遭遇し た SIP要求および SIP応答の場合、このヘッダに、現用 SIPサーバ 30のアドレスが記 載されている。そこで、このヘッダから、現用 SIPサーバ 30の次に記載されているアド レス（例えば、着呼側のユーザ'エージェント 20のアドレス）を抽出し、当該アドレスへ メッセージを直接転送すベぐ当該アドレスを次転送先とするのである。
[0087] また、このステップ S 505は、例えば、以下の処理によっても実現可能である。 SIP 要求および SIP応答の宛先ヘッダ（Toヘッダ）が完全修飾ドメイン名（FQDN： Fully Qualified Domain Name)で記載されている場合、宛先決定機能が、転送経路 を格納するヘッダ値を無視して、 DNS (Domain Name System)等の外部システ ムから再度 Toヘッダのアドレス解決を実行することで、次転送先を決定するのである
[0088] ステップ S502の結果、ステップ S501で受信したメッセージが SIP応答の場合には 、さらに、呼障害遭遇判定機能 13が、上記受信したメッセージが障害に遭遇したコー ルフローに属するかを調査する（ステップ S506)。なお、このステップ S506の処理は 、ステップ S503の処理と同様であるため説明を省略する。
ステップ S506の結果、ステップ S501で受信したメッセージが現用 SIPサーバ 30の 障害に遭遇したコールフローに属すると判別された場合には、メッセージの転送先を 新規に決定する（ステップ S505)。このステップ S505の処理は前述した通りである。
[0089] ステップ S506の結果、ステップ S501で受信したメッセージが現用 SIPサーバ 30の 障害発生に遭遇していない場合には、宛先設定機能 14が、ステップ S501の結果受 信したメッセージの送信先を当該メッセージに記載された送信先に決定する (ステツ プ S507)。
[0090] ステップ S502の結果、ステップ S501で受信したメッセージが SIP要求（ACKまた は BYE)または SIP応答以外の場合には、宛先設定機能 14が、ステップ S501の結 果受信したメッセージの送信先を標準転送先に指定する (ステップ S504)。
[0091] ステップ S504、ステップ S505およびステップ S507において宛先決定機能が設定 した送信先に対し、 SIPプロキシ 'サーバ機能 11が、ステップ S501で受信したメッセ ージを転送する（ステップ S 508)。
[0092] 次に、本発明の第 1の実施の形態に係るプロキシ.サーバ 10を含むシステム全体 の動作について図表を参照して詳細に説明する。
[0093] 図 6は、本発明の第 1の実施の形態に係るプロキシ ·サーバを含むシステム全体で の動作を示す動作シーケンス図、図 7は、同フローチャートである。図 6及び図 7に示 すように、コールフローの途中（図 6では呼設立後）で現用 SIPサーバ 30に障害が発 生した場合には (ステップ S701)、プロキシ'サーバ 10が、予備 SIPサーバ 40を標準 転送先として設定し (ステップ S 702)、それ以後の SIP要求 (ACKと BYE)を予備 SI Pサーバ 40に転送するのではなぐ SIP要求の次の転送先（図 6ではユーザ'エージ ヱント 20 (着呼側） )に直接転送する（ステップ S 703)。
[0094] (第 1の実施の形態の効果）
このように、本実施の形態によれば、以下の効果を達成することができる。
[0095] 第 1の効果は、現用 SIPサーバ 30の障害に遭遇したコールフローの処理を正常に 終了できることである。
[0096] これは、通話を行う両端のユーザ.エージェント 20に SIP要求および SIP応答が規 約通りに到着すれば、コールフローの処理が継続可能という SIPのプロトコル規約の 特性に着目し、プロキシ 'サーバ 10が、現用 SIPサーバ 30の障害に遭遇したコール フローに属する SIP要求と SIP応答を受信した場合に、当該 SIP要求と SIP応答の中 身を参照し、現用 SIPサーバ 30に代わって、該当 SIP要求と SIP応答が次に送信さ れるべき宛先を特定し、転送するためである。
[0097] 第 2の効果は、現用 SIPサーバ 30の障害時でもダイジェスト認証を伴った発呼が可 能なことである。
[0098] これは、プロキシ 'サーバ 10が、現用 SIPサーバ 30の障害発生を検知し、現用 SIP サーバ 30の障害発生状況に合わせて SIP要求の転送先を変更するためである。こ の結果、現用 SIPサーバ 30での障害発生時に、 initial INVITEリクエストや initial REGISTERリクエストなど、ダイジェスト認証を伴う SIP要求をプロキシ.サーバ 10 が受信した場合には、予備 SIPサーバ 40へ転送することで、ダイジェスト認証が実行 可能となるのである。
[0099] 第 3の効果は、ユーザ ·エージェント 20の数の増加に柔軟に対応可能なことである
〇
[0100] これは、現用 SIPサーバの障害に遭遇したコールフローに属する SIP要求と SIP応 答の次の転送先を、受信した SIP要求と SIP応答に格納されたヘッダの内容から決 定するためである。この結果、 SIP要求の転送先となるユーザ ·エージェント 20の IP アドレスを解決する情報を格納するディスクやメモリが不要となる。このように、ユーザ 'エージェント 20などの SIP要求の転送先数の増加と、転送先の IPアドレスの解決処 理とが無関係となるのである。
[0101] 第 4の効果は、 SIP要求の転送先に制限がないことである。
[0102] これは、前述したように、現用 SIPサーバ 30の障害に遭遇したコールフローに属す る SIP要求と SIP応答の次の転送先を、受信した SIP要求と SIP応答に格納されたへ ッダの内容から決定しているためである。この結果、プロキシ ·サーバ 10内に転送先 の IPアドレスを解決するための情報を保持する必要がなくなるため、その情報記載の 転送先以外には転送できなレ、とレ、つた事態がそもそも発生しな!/、のである。
[0103] (第 2の実施の形態）
次に、本発明の第 2の実施の形態に係るプロキシ ·サーバに関して図表を参照して 詳細に説明する。
[0104] (第 2の実施の形態の構成）
図 8は、本発明の第 2の実施の形態に係るプロキシ ·サーバ 10のブロック図を示す
〇
[0105] 図 8に示すように、本発明の第 2の実施の形態に係るプロキシ 'サーバ 10は、本発 明の第 1の実施の形態に係るプロキシ ·サーバ 10の構成に再送要求生成機能 16が 追加された構成となって!/、る。
[0106] この再送要求生成機能 16は、認証 INVITEリクエスト到達時において現用 SIPサ ーバ 30に障害が発生していた場合に、ユーザ'エージェント 20に対して initial IN VITEリクエストの再転送を促すために、ユーザ ·エージェント 20へ転送する再送要 求を生成する。例えば、この再送要求には、 Retry— Afterヘッダを揷入した SIP応 答（500 Server Inernal Error)が使用される。この SIP応答を受信した結果、ュ 一ザ.エージェント 20は一般的な SIP応答受信時の処理に従い、 Retry— Afterへッ ダ記載の期間後、再度 initial INVITEリクエストを送信することになる。
[0107] (第 2の実施の形態の動作）
次に、本発明の第 2の実施の形態に係るプロキシ ·サーバ 10の動作について図表 を参照して詳細に説明する。 [0108] 図 9は、本発明の第 2の実施の形態に係るプロキシ ·サーバの動作を示すフローチ ヤートでめる。
[0109] 図 9に示すように、本発明の第 2の実施の形態に係るプロキシ ·サーバ 10の動作は 、本発明の第 1の実施の形態に係るプロキシ ·サーバ 10の動作に、再送要求生成機 能 16の再送要求生成処理を含むステップ S903からステップ S905が追加された形 態となつている。なお、本実施の形態の再送要求生成処理を含むステップ以外のス テツプである、ステップ S901は第 1の実施の形態の図 5に示すステップ S501と、ステ テツプ S504と、ステップ S908はステップ S505と、ステップ S909はステップ S506と 容であるので説明を省略し、ステップ S903からステップ S905の動作を中心に説明 する。
[0110] ステップ S902の結果、ステップ S901で受信したメッセージが認証 INVITEリクエス トであった場合、呼障害遭遇判定機能 13は、受信したメッセージが障害に遭遇した コールフローに属するかを調査する（ステップ S903)。なお、ステップ S903の処理は 、本発明の第 1の実施の形態に係るプロキシ ·サーバ 10における動作ステップ S503 と同様であるため、説明を省略する。
[0111] ステップ S903の結果、ステップ S901で受信したメッセージが障害に遭遇したコー ルフローに属する場合には、再送要求生成機能 16が、ユーザ'エージェント 20に送 信する再送要求を生成する（ステップ S904)。この処理は、例えば、以下のようにして 実行される。生成する再送要求が、 Retry— Afterヘッダを揷入した SIP応答（500 Server Inernal Error)の場合、 Retry— Afterヘッダ以外のヘッダにはステップ S 901で受信したメッセージの値を使用し、 Retry— Afterヘッダには「30秒」等の値を 使用する。その後、宛先設定機能 14が再送要求の転送先をユーザ ·エージェント 20 と設定する（ステップ S905)。その後、 SIPプロキシ ·サーバ機能 11が、ステップ S90 4で生成された再送要求をユーザ ·エージェント 20に転送する（ステップ S911 )。
[0112] 次に、本発明の第 2の実施の形態に係るプロキシ ·サーバを含むシステム全体の動 作について図表を参照して詳細に説明する。 [0113] 図 10は、本発明の第 2の実施の形態に係るプロキシ.サーバを含むシステム全体 の動作を示すシーケンス図、図 11は、同フローチャートである。図 10及び図 11に示 すように、プロキシ ·サーバ 10が認証 INVITEリクエストを受信した際に現用 SIPサー バ 30において障害が発生している場合、本発明の第 1の実施の形態に係るプロキシ •サーバ 10と同様に、標準転送先を予備 SIPサーバ 40に変更した後（ステップ S110 1、ステップ S1102)、再送要求を生成し（ステップ S1103)、ユーザ'エージェント 20 に送信している（ステップ S1104)。この結果、ユーザ'エージェント 20は、 SIPのプロ トコル規約に規定されて!/、るように、 Retry— After経過後に再度利用可能になると 判断し、該当期間経過後、再度 initial INVITEリクエストを発行する（ステップ SI 1 05)。
[0114] なお、上記の説明は、 INVITEリクエストに関して説明してある力 プロキシ 'サーバ
10の動作は REGISTERリクエストに関しても同様の動作により、ユーザ'エージェン ト 20側に再度 initial REGISTERリクエストを送信させることが可能である。
[0115] (第 2の実施の形態の効果）
このように、本実施の形態によれば、第 1の実施の形態での効果に加えて、ユーザ- エージェント 20側で、現用 SIPサーバ 30の障害に遭遇したコールフローを正常な新 規コールフローとして自動的に再生成することが可能という効果がある。
[0116] これは、プロキシ 'サーバ 10がユーザ'エージェント 20の認証 INVITEリクエスト送 信後に現用 SIPサーバ 30の障害発生を検知した場合に、再送要求生成機能 16が、 ユーザ.エージェント 20から受信した認証 INVITEリクエストを使用し、 Retry—Afte rヘッダを揷入した SIP応答を生成してユーザ.エージェント 20に送信するためである 。これにより、ユーザ'エージェント 20は、 SIPのプロトコル規約に記載されたタイムァ ゥト（通常 32秒)後に、通話者が不通状態と判断し、任意の時間後に人手で再度通 話を試みるのではなぐ一般的な SIP応答の処理に従い、 Retry— Afterヘッダ値後 に再度 initial INVITEリクエストをプロキシ 'サーバ 10に向けて自動的に送信する ことが可能となるためである。
[0117] 以上好ましい実施の形態をあげて本発明を説明したが、本発明は必ずしも、上記 実施の形態に限定されるものでなぐその技術的思想の範囲内において様々に変形 して実施すること力でさる。
[0118] この出願 (ま、 2006年 10月 20曰 ίこ出願された曰本出願特願 2006— 286189を基 礎とする優先権を主張し、その開示の全てをここに取り込む。
産業上の利用可能性
[0119] 本発明のプロキシ 'サーバは、複数のユーザ端末及び複数の SIPサーバを有する SIPネットワークに利用できる。

Claims

請求の範囲
ザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ
Figure imgf000029_0001
受信したメッセージの種類を判別するメッセージ種別判定機能と、
前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出機 能と、
前記転送先障害検出機能からの通知に基づいて、前記プロキシ 'サーバ機能が受 信したメッセージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するも のかを判定する呼障害遭遇判定機能と、
前記転送先障害検出機能からの通知に基づいて、前記現用 SIPサーバの障害発 生状況や前記プロキシ ·サーバ機能で受信したメッセージの種類に応じてメッセージ の転送先を設定する宛先設定機能とを備えることを特徴とするプロキシ 'サーバ。
[2] ユーザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ ージを仲介するプロキシ.サーバ機能と、
受信したメッセージの種類を判別するメッセージ種別判定機能と、
前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出機 能と、
前記転送先障害検出機能からの通知に基づいて、前記プロキシ 'サーバ機能が受 信したメッセージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するも のかを判定する呼障害遭遇判定機能と、
前記転送先障害検出機能からの通知に基づいて、前記現用 SIPサーバの障害発 生状況や前記プロキシ ·サーバ機能で受信したメッセージの種類に応じてメッセージ の転送先を設定する宛先設定機能と、
前記ユーザ端末に対し initial INVITEリクエストを再転送することを促すために前 記ユーザ端末へ転送する再送要求を生成する再送要求生成機能とを備えることを特 徴とするプロキシ 'サーバ。
[3] 前記宛先設定機能は、
前記転送先障害検出機能が通知する前記現用 SIPサーバの障害発生通知により 更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を情報 として保持する機能を備えることを特徴とする請求項 1又は請求項 2に記載のプロキ シ.サーバ。
[4] 前記転送先障害検出機能は、
前記現用 SIPサーバと前記ユーザ端末とで送受信される REGISTERリクエストと S IP応答を監視し、前記現用 SIPサーバからの SIP応答を検出できない場合には、前 記現用 SIPサーバに障害が発生したと判断する機能を備えることを特徴とする請求 項 1又は請求項 2に記載のプロキシ 'サーバ。
[5] 前記呼障害遭遇判定機能は、
外部から受信した前記 SIPメッセージに格納された呼識別子を保持しており、かつ、 前記現用 SIPサーバの障害発生を検出した際に全て一旦消去される、呼識別子一 覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは 前記現用 SIPサーバの障害に遭遇したと判別する機能を備えることを特徴とする請 求項 1又は請求項 2に記載のプロキシ 'サーバ。
[6] 前記宛先決定機能は、
前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用
SIPサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接 転送すベぐ当該アドレスを次転送先とする機能を備えることを特徴とする、請求項 1 又は請求項 2に記載のプロキシ 'サーバ。
[7] 前記宛先決定機能は、
前記メッセージに格納されている、転送経路に関する情報を無視して、外部システ ムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する機能を備 えることを特徴とする請求項 1又は請求項 2に記載のプロキシ 'サーバ。
[8] 前記再送要求生成機能は、
前記ユーザ端末が、通常の SIP応答受信時の処理に従い、ある一定期間後、再度 メッセージを送信するよう誘導する SIP応答を生成する機能を備えることを特徴とする 請求項 2に記載のプロキシ 'サーバ。
[9] 外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージが SIP 要求である場合には、更に、受信したメッセージが現用 SIPサーバの障害に遭遇した コールフローに属するかを調査し、受信したメッセージが前記現用 SIPサーバの障害 に遭遇したコールフローに属すると判別された場合には、メッセージの内容を参照し てメッセージの転送先を新規に決定する機能を備えることを特徴とするプロキシ'サ ーバ。
[10] 外部からメッセージを受信後、メッセージ種類を調査し、受信したメッセージが認証 I NVITEリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査 し、障害に遭遇したコールフローに属する場合には、ユーザ端末に再度 initial IN VITEリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要 求を生成し、前記ユーザ端末に転送する機能を備えることを特徴とするプロキシ 'サ ーバ。
[11] 請求項 9及び請求項 10の機能を備えることを特徴とするプロキシ 'サーバ。
[12] ユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサーバと、前 記 SIPメッセージの送受信を仲介するプロキシ 'サーバとを含む通信システムであつ て、
前記プロキシ 'サーバに、
ユーザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ ージを仲介する SIPプロキシ ·サーバ機能と、
受信したメッセージの種類を判別するメッセージ種別判定機能と、
前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出機 能と、
前記転送先障害検出機能からの通知に基づいて、前記プロキシ 'サーバ機能が受 信したメッセージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するも のかを判定する呼障害遭遇判定機能と、
前記転送先障害検出機能からの通知に基づいて、前記現用 SIPサーバの障害発 生状況や前記プロキシ ·サーバ機能で受信したメッセージの種類に応じてメッセージ の転送先を設定する宛先設定機能とを備えることを特徴とする通信システム。
[13] ユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサーバと、前 記 SIPメッセージの送受信を仲介するプロキシ 'サーバとを含む通信システムであつ て、
前記プロキシ 'サーバに、
ユーザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ ージを仲介するプロキシ.サーバ機能と、
受信したメッセージの種類を判別するメッセージ種別判定機能と、
前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出機 能と、
前記転送先障害検出機能からの通知に基づいて、前記プロキシ 'サーバ機能が受 信したメッセージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するも のかを判定する呼障害遭遇判定機能と、
前記転送先障害検出機能からの通知に基づいて、前記現用 SIPサーバの障害発 生状況や前記プロキシ ·サーバ機能で受信したメッセージの種類に応じてメッセージ の転送先を設定する宛先設定機能と、
前記ユーザ端末に対し initial INVITEリクエストを再転送することを促すために前 記ユーザ端末へ転送する再送要求を生成する再送要求生成機能とを備えることを特 徴とする通信システム。
[14] 前記プロキシ ·サーバの前記宛先設定機能は、
前記転送先障害検出機能が通知する前記現用 SIPサーバの障害発生通知により 更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を情報 として保持する機能を備えることを特徴とする請求項 12又は請求項 13に記載の通信 システム。
[15] 前記プロキシ 'サーバの前記転送先障害検出機能は、
前記現用 SIPサーバと前記ユーザ端末とで送受信される REGISTERリクエストと S IP応答を監視し、前記現用 SIPサーバからの SIP応答を検出できない場合には、前 記現用 SIPサーバに障害が発生したと判断する機能を備えることを特徴とする請求 項 12又は請求項 13に記載の通信システム。
[16] 前記プロキシ 'サーバの前記呼障害遭遇判定機能は、 外部から受信した前記 SIPメッセージに格納された呼識別子を保持しており、かつ 、前記現用 SIPサーバの障害発生を検出した際に全て一旦消去される、呼識別子一 覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは 前記現用 SIPサーバの障害に遭遇したと判別する機能を備えることを特徴とする請 求項 12又は請求項 13に記載の通信システム。
[17] 前記プロキシ ·サーバの前記宛先決定機能は、
前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用
SIPサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接 転送すベぐ当該アドレスを次転送先とする機能を備えることを特徴とする、請求項 1
2又は請求項 13に記載の通信システム。
[18] 前記プロキシ ·サーバの前記宛先決定機能は、
前記メッセージに格納されている、転送経路に関する情報を無視して、外部システ ムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する機能を備 えることを特徴とする請求項 12又は請求項 13に記載の通信システム。
[19] 前記プロキシ 'サーバの前記再送要求生成機能は、
前記ユーザ端末が、通常の SIP応答受信時の処理に従い、ある一定期間後、再度 メッセージを送信するよう誘導する SIP応答を生成する機能を備えることを特徴とする 請求項 13に記載の通信システム。
[20] ユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサーバと、前 記 SIPメッセージの送受信を仲介するプロキシ 'サーバとを含む通信システムであつ て、
前記プロキシ 'サーバに、
外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージが SI P要求である場合には、更に、受信したメッセージが現用 SIPサーバの障害に遭遇し たコールフローに属するかを調査し、受信したメッセージが前記現用 SIPサーバの障 害に遭遇したコールフローに属すると判別された場合には、メッセージの内容を参照 してメッセージの転送先を新規に決定する機能を備えることを特徴とする通信システ ム。 ユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサーバと、前 記 SIPメッセージの送受信を仲介するプロキシ 'サーバとを含む通信システムであつ て、
前記プロキシ 'サーバに、
外部からメッセージを受信後、メッセージ種類を調査し、受信したメッセージが認証 I NVITEリクエストの場合には、更に、障害に遭遇したコールフローに属するかを調査 し、障害に遭遇したコールフローに属する場合には、ユーザ端末に再度 initial IN VITEリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要 求を生成し、前記ユーザ端末に転送する機能を備えることを特徴とする通信システム
[22] 請求項 20及び請求項 21の機能を前記プロキシ ·サーバに備えることを特徴とする通 信システム。
[23] 外部のユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサー バに対し、前記 SIPメッセージの送受信を仲介するプロキシ ·サーバにおける通信方 法であって、
ユーザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ
Figure imgf000034_0001
前記仲介ステップで受信したメッセージの種類を判別するメッセージ種別判定ステ 前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出ス 前記転送先障害検出ステップからの通知を受信し、前記仲介ステップでが受信し たメッセージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するものか を判定する呼障害遭遇判定ステップと、
前記転送先障害検出ステップ力 の通知を受信し、前記現用 SIPサーバの障害発 生状況や前記仲介ステップで受信したメッセージの種類に応じてメッセージの転送 先を設定する宛先設定ステップとを含むことを特徴とする通信方法。
[24] 外部のユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサー バに対し、前記 SIPメッセージの送受信を仲介するプロキシ ·サーバにおける通信方 法であって、
ユーザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ
Figure imgf000035_0001
前記仲介ステップで受信したメッセージの種類を判別するメッセージ種別判定機能 と、
前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出ス 前記転送先障害検出ステップからの通知を受信し、前記仲介ステップで受信したメ ッセージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するものかを 判定する呼障害遭遇判定ステップと、
前記転送先障害検出ステップ力 の通知を受信し、前記現用 SIPサーバの障害発 生状況や前記仲介ステップで受信したメッセージの種類に応じてメッセージの転送 先を設定する宛先設定ステップと、
前記ユーザ端末に対し initial INVITEリクエストを再転送することを促すために前 記ユーザ端末へ転送する再送要求を生成する再送要求生成ステップとを含むことを 特徴とする通信方法。
[25] 前記宛先設定ステップは、
前記転送先障害検出ステップが通知する前記現用 SIPサーバの障害発生通知に より更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を 情報として保持するステップを含むことを特徴とする請求項 23又は請求項 24に記載 の通信方法。
[26] 前記転送先障害検出ステップは、
前記現用 SIPサーバと前記ユーザ端末とで送受信される REGISTERリクエストと S
IP応答を監視し、前記現用 SIPサーバからの SIP応答を検出できない場合には、前 記現用 SIPサーバに障害が発生したと判断するステップを含むことを特徴とする請求 項 23又は請求項 24に記載の通信方法。
[27] 前記呼障害遭遇判定ステップは、 外部から受信した前記 SIPメッセージに格納された呼識別子を保持しており、かつ 、前記現用 SIPサーバの障害発生を検出した際に全て一旦消去される、呼識別子一 覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは 前記現用 SIPサーバの障害に遭遇したと判別するステップを含むことを特徴とする請 求項 23又は請求項 24に記載の通信方法。
[28] 前記宛先決定ステップは、
前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用
SIPサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接 転送すベぐ当該アドレスを次転送先とするステップを含むことを特徴とする請求項 2
3又は請求項 24に記載の通信方法。
[29] 前記宛先決定ステップは、
前記メッセージに格納されている、転送経路に関する情報を無視して、外部システ ムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する機能を備 えることを特徴とする請求項 23又は請求項 24に記載の通信方法。
[30] 前記再送要求生成ステップは、
前記ユーザ端末が、通常の SIP応答受信時の処理に従い、ある一定期間後、再度 メッセージを送信するよう誘導する SIP応答を生成する機能を備えることを特徴とする 請求項 24に記載の通信方法。
[31] 外部のユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサー バに対し、前記 SIPメッセージの送受信を仲介するプロキシ ·サーバにおける通信方 法であって、
外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージが SI P要求である場合には、更に、受信したメッセージが現用 SIPサーバの障害に遭遇し たコールフローに属する力、を調査するステップと、
受信したメッセージが前記現用 SIPサーバの障害に遭遇したコールフローに属する と判別された場合には、メッセージの内容を参照してメッセージの転送先を新規に決 定するステップを有することを特徴とする通信方法。
[32] 外部のユーザ端末との間で SIPメッセージの送受信を行う現用及び予備の SIPサー バに対し、前記 SIPメッセージの送受信を仲介するプロキシ ·サーバにおける通信方 法であって、
外部からメッセージを受信後、メッセージ種類を調査するステップと、
受信したメッセージが認証 INVITEリクエストの場合には、更に、障害に遭遇したコ ールフローに属する力、を調査するステップと、
障害に遭遇したコールフローに属する場合には、ユーザ端末に再度 initial INVI TEリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求 を生成し、前記ユーザ端末に転送するステップを有することを特徴とする通信方法。
[33] 請求項 31及び請求項 32のステップを有することを特徴とする通信方法。
[34] 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装 置に対し、前記メッセージの送受信を仲介するプロキシ.サーバに実行させるための プログラムであって、
ユーザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ ージを仲介する仲介処理と、
前記仲介処理で受信したメッセージの種類を判別するメッセージ種別判定処理と、 前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出処 理と、
前記転送先障害検出処理からの通知を受信し、前記仲介処理でが受信したメッセ ージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するものかを判定 する呼障害遭遇判定処理と、
前記転送先障害検出処理からの通知を受信し、前記現用 SIPサーバの障害発生 状況や前記仲介処理で受信したメッセージの種類に応じてメッセージの転送先を設 定する宛先設定処理を、
前記プロキシ ·サーバに実行させることを特徴とするプログラム。
[35] 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装 置に対し、前記メッセージの送受信を仲介するプロキシ.サーバに実行させるための プログラムであって、
ユーザ端末と現用 SIPサーバ及び予備 SIPサーバとの間で送受信される SIPメッセ ージを仲介する仲介処理と、
前記仲介処理で受信したメッセージの種類を判別するメッセージ種別判定処理と、 前記現用 SIPサーバの障害が発生したことを検知して通知する転送先障害検出処 理と、
前記転送先障害検出ステップ力 の通知を受信し、前記仲介処理で受信したメッ セージが、前記現用 SIPサーバの障害に遭遇したコールフローに属するものかを判 定する呼障害遭遇判定処理と、
前記転送先障害検出処理からの通知を受信し、前記現用 SIPサーバの障害発生 状況や前記仲介処理で受信したメッセージの種類に応じてメッセージの転送先を設 定する宛先設定処理と、
前記ユーザ端末に対し initial INVITEリクエストを再転送することを促すために前 記ユーザ端末へ転送する再送要求を生成する再送要求生成処理を、
前記プロキシ ·サーバに実行させることを特徴とするプログラム。
[36] 前記宛先設定処理は、
前記転送先障害検出処理が通知する前記現用 SIPサーバの障害発生通知により 更新される、特段の指定がない場合にメッセージを転送する標準的な転送先を情報 として保持する処理を含むことを特徴とする請求項 34又は請求項 35に記載のプログ ラム。
[37] 前記転送先障害検出処理は、
前記現用 SIPサーバと前記ユーザ端末とで送受信される REGISTERリクエストと S IP応答を監視し、前記現用 SIPサーバからの SIP応答を検出できない場合には、前 記現用 SIPサーバに障害が発生したと判断する処理を含むことを特徴とする請求項 34又は請求項 35に記載のプログラム。
[38] 前記呼障害遭遇判定処理は、
外部から受信した前記 SIPメッセージに格納された呼識別子を保持しており、かつ 、前記現用 SIPサーバの障害発生を検出した際に全て一旦消去される、呼識別子一 覧を使用し、この呼識別子一覧に記載のない呼識別子を保持する前記メッセージは 前記現用 SIPサーバの障害に遭遇したと判別する処理を含むことを特徴とする請求 項 34又は請求項 35に記載のプログラム。
[39] 前記宛先決定処理は、
前記メッセージに格納された、メッセージの転送経路に関する情報から、前記現用
SIPサーバの次に記載されているアドレスを抽出し、当該アドレスへメッセージを直接 転送すベぐ当該アドレスを次転送先とする処理を含むことを特徴とする請求項 34又 は請求項 35に記載のプログラム。
[40] 前記宛先決定処理は、
前記メッセージに格納されている、転送経路に関する情報を無視して、外部システ ムと連携し、前記メッセージの宛先情報から宛先のアドレス解決を実行する処理を含 むことを特徴とする請求項 34又は請求項 35に記載のプログラム。
[41] 前記再送要求生成処理は、
前記ユーザ端末が、通常の SIP応答受信時の処理に従い、ある一定期間後、再度 メッセージを送信するよう誘導する SIP応答を生成する処理を含むことを特徴とする 請求項 35に記載のプログラム。
[42] 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装 置に対し、前記メッセージの送受信を仲介するプロキシ.サーバに実行させるための プログラムであって、
外部からメッセージを受信後、メッセージの種類を調査し、受信したメッセージが SI P要求である場合には、更に、受信したメッセージが現用 SIPサーバの障害に遭遇し たコールフローに属するかを調査する処理と、
受信したメッセージが前記現用 SIPサーバの障害に遭遇したコールフローに属する と判別された場合には、メッセージの内容を参照してメッセージの転送先を新規に決 定する処理を、
前記プロキシ ·サーバに実行させることを特徴とするプログラム。
[43] 外部のユーザ端末との間でメッセージの送受信を行う現用及び予備の通信制御装 置に対し、前記メッセージの送受信を仲介するプロキシ.サーバに実行させるための プログラムであって、
外部からメッセージを受信後、メッセージ種類を調査する処理と、 受信したメッセージが認証 INVITEリクエストの場合には、更に、障害に遭遇したコ ールフローに属するかを調査する処理と、
障害に遭遇したコールフローに属する場合には、ユーザ端末に再度 initial INVI TEリクエストを再転送することを促すために、前記ユーザ端末へ転送する再送要求 を生成し、前記ユーザ端末に転送する処理を、
前記プロキシ ·サーバに実行させることを特徴とするプログラム。
請求項 42及び請求項 43の処理を有することを特徴とするプログラム。
PCT/JP2007/070481 2006-10-20 2007-10-19 Serveur proxy, système et procédé de communication et programme WO2008047920A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP07830215A EP2079024A1 (en) 2006-10-20 2007-10-19 Proxy server, communication system, communication method, and program
US12/443,360 US8374079B2 (en) 2006-10-20 2007-10-19 Proxy server, communication system, communication method and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006-286189 2006-10-20
JP2006286189A JP4470934B2 (ja) 2006-10-20 2006-10-20 プロキシ・サーバ、通信システム、通信方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2008047920A1 true WO2008047920A1 (fr) 2008-04-24

Family

ID=39314130

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/070481 WO2008047920A1 (fr) 2006-10-20 2007-10-19 Serveur proxy, système et procédé de communication et programme

Country Status (4)

Country Link
US (1) US8374079B2 (ja)
EP (1) EP2079024A1 (ja)
JP (1) JP4470934B2 (ja)
WO (1) WO2008047920A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114338343A (zh) * 2021-12-30 2022-04-12 海能达通信股份有限公司 通信方法及集群服务系统

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI393425B (zh) * 2008-11-20 2013-04-11 Inst Information Industry 使一網路分機撥打一傳統分機之方法、裝置及其電腦程式產品
US8601139B2 (en) * 2008-11-26 2013-12-03 Cavium, Inc. Multiple core session initiation protocol (SIP)
KR101333164B1 (ko) 2009-04-13 2013-11-27 블랙베리 리미티드 Ｓｉｐ 메세지에 대한 신뢰를 결정하는 시스템 및 방법
US20100284284A1 (en) * 2009-05-08 2010-11-11 Qualcomm Incorporated VOICE OVER INTERNET PROTOCOL (VoIP) ACCESS TERMINAL
US9515849B2 (en) * 2009-12-22 2016-12-06 At&T Intellectual Property I, L.P. Method and apparatus for managing communication faults
JP5693065B2 (ja) * 2010-07-06 2015-04-01 キヤノン株式会社 通信端末、通信端末の制御方法及びプログラム
JP5322312B2 (ja) * 2010-09-07 2013-10-23 Ｎｅｃエンジニアリング株式会社 Ｐｂｘバックアップシステム
JP5842657B2 (ja) * 2012-02-15 2016-01-13 日本電気株式会社 呼制御装置
KR101368693B1 (ko) * 2012-03-08 2014-03-03 텔코웨어 주식회사 Ｉｍｓ망에서 트래픽 처리 방법 및 장치
US9419953B2 (en) 2012-12-23 2016-08-16 Mcafee, Inc. Trusted container
US8955075B2 (en) 2012-12-23 2015-02-10 Mcafee Inc Hardware-based device authentication
JP6104766B2 (ja) * 2013-09-11 2017-03-29 株式会社東芝 通信制御装置、制御装置および通信システム
US9729492B2 (en) * 2014-06-16 2017-08-08 Genesys Telecommunications Laboratories, Inc. Intelligent resource manager service recovery including request retransmissions
US10623983B2 (en) * 2014-12-23 2020-04-14 Telefonaktiebolaget Lm Ericsson (Publ) Service aware overload handling in a communication network
CN107005559B (zh) * 2015-03-30 2021-08-31 华为技术有限公司 一种无线通信的方法、远程用户设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002149439A (ja) * 2000-11-15 2002-05-24 Nec Soft Ltd 分散処理システムにおけるサーバ切替え方法及びサーバ装置
JP2003076623A (ja) * 2001-09-05 2003-03-14 Mitsubishi Electric Corp ネットワークシステム、サーバ装置及び通信端末並びにサーバ切り替え方法
JP2004280738A (ja) 2003-03-19 2004-10-07 Hitachi Ltd 代理応答装置
JP2004287945A (ja) * 2003-03-24 2004-10-14 Nippon Telegr & Teleph Corp <Ntt> オブジェクト内部状態の一貫性確認方法、情報処理システム、プログラム、および記録媒体
JP2005229273A (ja) 2004-02-12 2005-08-25 Fujitsu Ltd サーババックアップ装置
JP2006286189A (ja) 2006-06-16 2006-10-19 Tdk Corp 光記録媒体へのデータ記録方法、データ記録装置および光記録媒体

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6446127B1 (en) * 1998-10-30 2002-09-03 3Com Corporation System and method for providing user mobility services on a telephony network
US6992974B1 (en) * 2000-10-10 2006-01-31 3Com Corporation System and method for providing fault tolerance in a network telephony system
JP3883452B2 (ja) * 2002-03-04 2007-02-21 富士通株式会社 通信システム
US6857053B2 (en) * 2002-04-10 2005-02-15 International Business Machines Corporation Method, system, and program for backing up objects by creating groups of objects
US7298733B2 (en) * 2002-07-29 2007-11-20 Ip Talk Corporation Internet communication system, internet communication method, session management server, radio communication device, communication relay server, and program
JP2004348647A (ja) * 2003-05-26 2004-12-09 Hitachi Ltd ヒューマン・コミュニケーション・システム
US8024476B2 (en) 2004-05-21 2011-09-20 Microsoft Corporation Efficient message routing when using server pools
US7506369B2 (en) * 2004-05-27 2009-03-17 Microsoft Corporation Secure federation of data communications networks
JP2006087016A (ja) * 2004-09-17 2006-03-30 Fujitsu Ltd 通信端末、通信システム及び通信方法
TWI252027B (en) * 2004-12-30 2006-03-21 Ind Tech Res Inst System and method for accelerating call setup by caching
JP4983599B2 (ja) * 2005-02-10 2012-07-25 日本電気株式会社 情報システム管理装置
US20070041327A1 (en) * 2005-08-16 2007-02-22 Cisco Technology, Inc. Multicast heartbeat signaling
US8125888B2 (en) * 2005-08-23 2012-02-28 Multi-Tech Systems, Inc. Session initiation protocol survivable server
US20070157016A1 (en) * 2005-12-29 2007-07-05 Dayan Richard A Apparatus, system, and method for autonomously preserving high-availability network boot services

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002149439A (ja) * 2000-11-15 2002-05-24 Nec Soft Ltd 分散処理システムにおけるサーバ切替え方法及びサーバ装置
JP2003076623A (ja) * 2001-09-05 2003-03-14 Mitsubishi Electric Corp ネットワークシステム、サーバ装置及び通信端末並びにサーバ切り替え方法
JP2004280738A (ja) 2003-03-19 2004-10-07 Hitachi Ltd 代理応答装置
JP2004287945A (ja) * 2003-03-24 2004-10-14 Nippon Telegr & Teleph Corp <Ntt> オブジェクト内部状態の一貫性確認方法、情報処理システム、プログラム、および記録媒体
JP2005229273A (ja) 2004-02-12 2005-08-25 Fujitsu Ltd サーババックアップ装置
JP2006286189A (ja) 2006-06-16 2006-10-19 Tdk Corp 光記録媒体へのデータ記録方法、データ記録装置および光記録媒体

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Technical Specification No. TS-1006", 2004, THE TELECOMMUNICATION TECHNOLOGY COMMITTEE, article "Technical Specifications on Basic Call Interface for SIP Terminals Connecting with Provider's SIP Network"
"Toshifumi MURATA", 2004, IMPRESS R&D INCORPORATION, pages: 77 - 78

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114338343A (zh) * 2021-12-30 2022-04-12 海能达通信股份有限公司 通信方法及集群服务系统
CN114338343B (zh) * 2021-12-30 2023-12-12 海能达通信股份有限公司 通信方法及集群服务系统

Also Published As

Publication number Publication date
EP2079024A1 (en) 2009-07-15
US8374079B2 (en) 2013-02-12
US20100074100A1 (en) 2010-03-25
JP2008102823A (ja) 2008-05-01
JP4470934B2 (ja) 2010-06-02

Similar Documents

Publication Publication Date Title
WO2008047920A1 (fr) Serveur proxy, système et procédé de communication et programme
EP2501119B1 (en) A gateway for the survivability of an enterprise network using sip
US8296447B2 (en) Method for copying session information, call control server for executing the same, and computer product
US20070041327A1 (en) Multicast heartbeat signaling
JP2005229273A (ja) サーババックアップ装置
KR20070010693A (ko) Ｓｉｐ를 이용한 통신 시스템에서 호 해제 요청/응답메시지를 이용한 네트워크 상태 관리 방법
US20070115806A1 (en) Methods, systems, and computer program products for session initiation protocol (SIP) fast switchover
US8972586B2 (en) Bypassing or redirecting a communication based on the failure of an inserted application
JP5841262B2 (ja) Ｓｉｐプロキシ・フェイルオーバ方法
JP2008219461A (ja) 通信履歴情報管理システム、ｓｉｐクライアント端末、履歴サーバおよび通信履歴情報管理方法
US8189764B2 (en) Server for transferring a communication message
JP5202383B2 (ja) 通信ネットワークシステムとその呼制御装置及び発信規制方法
JP2006087016A (ja) 通信端末、通信システム及び通信方法
US7899040B2 (en) Synchronization of event processing at a media gateway
JP4329747B2 (ja) ＶｏＩＰサーバ、ＶｏＩＰサーバの冗長システム及びそのメンテナンス方法
JP5609519B2 (ja) Ｓｉｐ機器
JP2009239550A (ja) ＶｏＩＰネットワークの輻輳制御システム、、方法、及びプログラム
US20240073123A1 (en) Alternative route propogation
WO2023276001A1 (ja) 負荷分散システム、負荷分散方法、および、負荷分散プログラム
KR101368693B1 (ko) Ｉｍｓ망에서 트래픽 처리 방법 및 장치
JP2022123672A (ja) パケット制御システム
JP2005080176A (ja) ゲートウェイ装置及びその制御方法
JP2007274160A (ja) プロキシサーバ及びｉｐネットワークの特定信号転送方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07830215

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12443360

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2007830215

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE