JP2006303754A - Composite session control apparatus and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a composite session control apparatus and method capable of accommodating scalable SIP terminals by avoiding an extended URI. <P>SOLUTION: A SIP control system for processing a connection request from a SIP terminal connected via an IP network on the basis of the SIP procedures includes: a gateway for referring to header contents of a SIP protocol packet from the SIP terminal and controlling transfer of the SIP protocol packet to one of a plurality of SIP servers on the basis of at least part of the information of the header; and a database for revising part of the information. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a composite session control apparatus and method, and more particularly to a composite session control server and a control method therefor for efficiently processing control requests from a large number of terminals in communication session control in a network using the Internet protocol.

  In a network based on an IP protocol such as the Internet, a session initiation protocol (hereinafter abbreviated as SIP) is known as a method for dynamically controlling a communication session. In SIP, a server system called a SIP server establishes a communication session between terminals interconnected via an IP network by processing and relaying a session connection request from the terminal. The user on the SIP protocol is identified by a uniform resource identifier (Universal Resource Identifier, hereinafter abbreviated as URI), and the user registers the own URI and the IP address used in the location server via the SIP server, Registers its own position on the IP network, that is, the correspondence between the URI of its own device and the IP address.

  For example, Japanese Patent Laid-Open No. 2002-152805 (Patent Document 1) discloses a technique that enables bidirectional communication on a network by specifying a call destination position in a communication system using SIP. In particular, it uses two servers, a SIP server that holds correspondence information between a SIP address and an IP address, and a SIP server that holds a relationship between the SIP address and the location information of the terminal. Session control is performed by specifying the above.

JP 2002-152805 A

  The SIP server is understood as a single logical function in the technical standard related to SIP and the above-described conventional technology. That is, the functions of the SIP server are defined in a configuration that does not depend on numerical parameters such as the number of terminals accommodated and the frequency of session control requests. However, in actual application, the number of terminals accommodated by the SIP server and the frequency of session control requests are limited due to the physical processing capacity limit of the SIP server.

  In a Web server or the like, generally, a plurality of equivalent servers are installed by a load balancer technique, and processing requests from a terminal are distributed to a plurality of servers according to the server load. However, in the case of a SIP server, the terminal and the location server that holds the position information need to correspond one-to-one. Therefore, when SIP communication is started between terminals, a message requesting the start of communication must be transmitted to a SIP server connected to a location server that registers the communication partner's location information. Unlike a load balancer, processing requests cannot be distributed to any server according to the load status.

  Further, as another means for increasing the number of terminals accommodated, a method of dividing a server into a plurality of parts as usual in a mail server and assigning a subdomain name to each of them can be considered. However, from the point of view of a user who uses a SIP-based service, it is desirable that the URI has a simple format that is as easy to memorize as possible, and it is important to avoid a URI that is long like a subdomain name + domain name. is there.

  An object of the present invention is to provide a composite session control apparatus and method that can accommodate a scalable SIP terminal while avoiding an increase in the length of a URI, and that can use a SIP service with a simple URI from the user's perspective. There is to do.

  The present invention preferably refers to the header content of the SIP protocol packet from the SIP terminal in the SIP control apparatus that processes a connection request from the SIP terminal connected via the IP network based on the SIP procedure, A gateway that performs control for transferring a SIP protocol packet to a SIP server having a plurality of SIP servers based on at least a part of the information, and a database that registers information for changing a part of the information. Configured to have.

Further, the present invention provides a SIP control apparatus that processes a connection request from a SIP terminal connected via an IP network based on a SIP procedure, wherein a plurality of SIP servers and any of the plurality of SIP servers are connected from the SIP terminal. Transfer means for transferring the SIP protocol packet, and storage means for registering the correspondence relationship between the session ID to which the SIP protocol packet transferred to the plurality of SIP servers belongs and the forwarded SIP server. Control for selecting one of the plurality of SIP servers is performed with reference to the correspondence relationship.
Also, in one example, the function of transferring a SIP protocol packet is a resolver function for analyzing a part of the SIP protocol packet, information for acquiring address information and rewriting part of the SIP protocol packet or other part of the information Is configured to include a redirector for acquiring the SIP protocol packet based on the address information.

  The SIP control method according to the present invention includes a SIP protocol packet transmitted from a SIP terminal in a SIP control method for processing a connection request from a SIP terminal connected via an IP network based on a SIP procedure. Extracting a URI specifying a destination to be transmitted, referring to a database with respect to the extracted URI, acquiring a VURI virtually associated with the URI, and acquiring a URI in the SIP protocol packet A step of replacing the received VURI, a step of transmitting a SIP protocol packet including the VURI to a certain SIP server selected from a plurality of SIP servers, and processing of a dialog regarding the received SIP protocol packet in the selected SIP server. And on the location server , Registering the location information of the SIP terminal, referring to the database regarding the VURI, obtaining a URI associated with the VURI, and replacing the VURI in the SIP protocol packet with the obtained URI And a step of transmitting the created SIP protocol packet to the destination SIP terminal.

In a preferred example, the step of acquiring the VURI includes acquiring the IP address of the SIP server that processes the VURI, and transmits the SIP protocol packet to the SIP server selected based on the IP address. .
In a preferred example, the database registers a URI, a VURI, a registered IP address, and an IP address of an accommodation SIP server that are transmitted in a SIP protocol packet in association with the user name of the SIP terminal.

  The present invention can be configured to interpret the contents of the SIP protocol and distribute the session control request message to a plurality of SIP servers.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 shows a configuration example of a communication system using a SIP terminal according to an embodiment.
A SIP terminal 15 is connected to the SIP gateway 2 via the Internet 10. FIG. 1 shows an example in which one SIP terminal 15 is connected to the Internet 10, but in reality, a large number of SIP terminals 15 are connected, and between those SIP terminals 15 through the SIP gateway 2. Communication takes place.

  Connected to the SIP gateway 2 are a plurality of SIP servers 121, 122, 123 (hereinafter, representatively represented by the number 12) and a subdomain distribution database (DB) 3. Each SIP server 12 is connected with location servers 131, 132, and 133 (hereinafter, representatively represented by the number 13). Here, each SIP server 12 is configured by, for example, a SIP proxy. The configurations of the SIP gateway 2 and the subdomain distribution database 3 will be described later with reference to FIGS.

A SIP protocol packet according to the SIP protocol is input from the SIP terminal 15 to the SIP gateway 2 via the Internet 10.

In this case, the SIP terminal 15 obtains the IP address of the SIP gateway as a logical SIP server address by a mechanism such as DNS or DHCP (Dynamic Host Configuration Protocol), and the destination IP address of the SIP protocol packet is SIP. It is the IP address of the gateway.

  The SIP gateway 2 analyzes a part of the content of the input SIP protocol packet and acquires, for example, a URI. The SIP gateway refers to the subdomain distribution database 4 using the acquired SIP-URI as a key. Here, in the sub-domain distribution database, VURI (Virtual URI), which is a virtual URI in which the domain portion of each URI is represented as a sub-domain, is stored in association with each URI. This VURI has a one-to-one correspondence with the SIP server, and the IP address of the SIP server corresponding to each VURI is also stored in the subdomain distribution database.

  The SIP gateway 2 refers to the subdomain distribution database 4 to acquire the VURI and IP address stored in association with the URI included in the received SIP protocol packet. Then, the SIP gateway 2 redirects the SIP protocol packet to the SIP server 12 having the VURI and IP address. The SIP server 12 processes the redirected SIP protocol packet with reference to the location server 13. Redirection by the SIP gateway 2 is performed by referring to the subdomain distribution database 14.

FIG. 2 shows a configuration example of the SIP gateway 2.
In FIG. 2, the resolver 21 analyzes the URI portion of the SIP protocol packet and transfers it to the redirector 23. The redirector 23 refers to the subdomain distribution database 3 via the connection line 104 and transfers the acquired VURI to the SIP resolver 21. The SIP resolver 21 changes the URI of the SIP protocol packet to the obtained VURI. Similarly, the redirector 23 controls the switch 22 based on the acquired IP address, and outputs the SIP protocol packet to the connection line 201 to the SIP server (for example 121).

FIG. 3 shows the database structure of the subdomain distribution DB 3.
The subdomain distribution DB 3 registers relevant information for indexing the VURI from the URI included in a part of the SIP protocol packet or vice versa. That is, corresponding to the user name 31, a URI 32, a VURI 33, a registration address 34, and a accommodated SIP server IP address 35 are registered.

  Here, the user name refers to a portion of the SIP-URI before @. The VURI is described in the URI subdomain format. For example, if the URI is A@XX.co.jp, the VURI corresponding to this is expressed in a form in which the domain hierarchy is increased, such as A@xx1.XX.co.jp. The accommodated SIP server IP address refers to the IP address of the SIP server assigned to actually process the SIP protocol packet having the SIP-URI.

  The SIP gateway 2 selects the SIP server 12 to be accommodated by the user using the URI based on the VURI 33 obtained from the subdomain distribution DB 3 and the IP address 35 of the accommodated SIP server, and transfers the SIP protocol packet to that server. At that time, the SIP gateway 2 converts the URI into a VURI.

  The selected SIP server (eg, 121) processes or interrupts the forwarded SIP protocol packet according to a normal SIP processing procedure. The location server 131 connected to the SIP server 121 is for registering the location of the SIP terminal 15 in accordance with the SIP protocol. In this case, the location server 131 registers the correspondence between the VURI and the accommodated SIP server IP address.

  The SIP protocol packet relayed by the SIP server 12 is characterized by the VURI, and the SIP gateway 2 to which the SIP protocol packet is input refers to the subdomain distribution database 3 again and corresponds to the VURI from the database structure shown in FIG. Get URI and registered IP address. The SIP gateway 2 converts the VURI into a URI based on the acquired data, stores the converted pair in its own storage unit, and transmits it to the registered IP address. That is, for example, this is performed by replacing the SIP-URI portion of the packet received from the SIP terminal 15 with the VURI in the SIP gateway 2, processing it with the SIP server 12, and then rewriting it with the SIP-URI again in the SIP gateway 2.

Next, with reference to FIG. 4, the communication operation of SIP messages between SIP terminals will be outlined.
In this example, a request message is transmitted from the SIP terminal 150 to the SIP terminal 151 to perform communication.
Here, for example, the request message is as follows.
INVITE sip: bob@biloxi.com SIP / 2.0
Via: SIP / 2.0 / UDP pc33.atlanta.com; branch = z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip: bob@biloxi.com>
From: Alice <sip: alice@atlanta.com>; tag = 1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip: alice@pc33.atlanta.com>
Content-Type: application / sdp
Content-Length: 142
The response message from the SIP terminal 151 is, for example, as follows.
SIP / 2.0 200 OK
Via: SIP / 2.0 / UDP server10.biloxi.com
; branch = z9hG4bKnashds8; received = 192.0.2.3
Via: SIP / 2.0 / UDP bigbox3.site3.atlanta.com
; branch = z9hG4bK77ef4c2312983.1; received = 192.0.2.2
Via: SIP / 2.0 / UDP pc33.atlanta.com
; branch = z9hG4bK776asdhds; received = 192.0.2.1
To: Bob <sip: bob@biloxi.com>; tag = a6c85cf
From: Alice <sip: alice@atlanta.com>; tag = 1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip: bob@192.0.2.4>
Content-Type: application / sdp
Content-Length: 131
In FIG. 4, when the SIP server 12 receives the request message “INVITE” transmitted from the SIP terminal 150, the SIP server 12 analyzes the content of the message and sends it to the SIP terminal 151 corresponding to the destination SIP / 2.0. Send a request message.
On the other hand, the response message “200 OK” is returned from the SIP terminal 151. The SIP server 12 transmits this response to the SIP terminal 150 that is the transmission source.

  As a result, a session is established between both SIP terminals 150 and 151, and thereafter, communication according to normal RTP (Real-time Transport Protocol) such as transmission of ACK from the SIP terminal 150 is performed.

Next, with reference to FIG. 5, an operation for establishing a session in communication between SIP terminals will be described.
It is assumed that the request message transmitted from the SIP terminal 150 includes INVITE and URI-B that designates the SIP terminal 151 that is the destination.
First, when the SIP gateway 2 receives this request message, it extracts the URI from the message and sends the URI-B to the subdomain distribution DB 3 (S501).

  As shown in FIG. 3, since the URI / VURI correspondence table is registered for each user name in the sub-domain distribution DB 3, referring to the user name in this correspondence table, the VURI corresponding to URI-B, The SIP server IP address is acquired (S502).

  The SIP gateway 2 rewrites the URI to the acquired VURI (S503), and further registers the correspondence between the URI and the VURI in the database (S504). Further, a corresponding SIP server (for example, 121) is selected from the acquired SIP server IP address. Then, a request message INVITE including VURI-B is transmitted to the corresponding SIP server 121.

Dialog processing is performed in the SIP server 121 (S505). That is, the location server 131 is inquired about the address of the VURI-B and acquires the VURI-B address of the SIP terminal 151 (S506).
The acquired VURI-B address is transmitted from the SIP server 121 to the SIP gateway 2, where the VURI is rewritten to a URI (S507). Then, the request message packet is transferred to the target SIP terminal 151 indicated by URI-B.

The SIP terminal 151 that has received the request message generates a response message, creates a message including its user name, 200K, and the destination SIP terminal URI-A, and returns it to the SIP gateway 2.
In the SIP gateway 2, message analysis and conversion processing for transmitting a response message to the SIP terminal 150 are performed. This process is a URI-to-VURI conversion process for URI-A, and is the same process as described in steps S501 to S507 (S510). That is, the VURI stored in the transmission source URI is changed to the URI, and the accommodation SIP server IP address of the transmission source is changed to the IP address of the SIP gateway.

  Then, a response message including 200 OK and URI-A is transmitted from the SIP gateway 2 to the SIP terminal 150. Thereafter, communication based on RTP is performed between the SIP terminals 150 and 151 (S520).

  For the entry erasure process after the end of communication, the SIP gateway 2 receives a message including BYE and the destination URI-B transmitted from the SIP terminal 150. The SIP gateway 2 extracts URIs (S531), rewrites the extracted URIs to VURIs (S532), and transmits them to the corresponding SIP server 121 in the same manner as described above.

  In the SIP server 121, dialog processing is performed (S533) in the same manner as the previous operation, and thereafter, the SIP gateway 2 performs processing for deleting the registration of the correspondence between the URI and VURI (S534). That is, the URI / VURI correspondence registered in relation to the user name shown in FIG. 3 is deleted.

  In this embodiment, it is assumed that the subdomain distribution database 3 and the plurality of SIP servers 12 are in the same location. However, it is clear that some or all of these exist in geographically different locations, and the processing procedure is not changed even in a configuration in which a network is connected between them, and the same effect can be obtained.

  According to the present embodiment, by combining the SIP gateway 2 having a function of analyzing only a part of the SIP protocol with the normal SIP server 12, it is possible to increase the capacity and conceal the user from the subdomain processing. is there.

Next, another embodiment will be described with reference to FIG.
Another embodiment described below is an example in which information such as an address related to a SIP terminal is dynamically accommodated. That is, in the above embodiment, information related to the SIP terminal is fixedly stored in a database corresponding to each SIP server, that is, a location server, but in the following embodiment, information related to the SIP terminal is integrated into the load balancing DB. The SIP server performs session control with reference to this load balancing DB. This will be described in detail below.

  A SIP terminal 15 is connected to the SIP load balancer 7 via the Internet 10. The SIP load balancer 7 redirects the SIP protocol packet to any of the SIP servers 121 to 123 by analyzing a part of the content of the SIP protocol packet from the SIP terminal 15. The SIP server 12 processes the redirected SIP protocol packet with reference to the location server 13. Redirection by the SIP load balancer 7 is performed by referring to the location server 13.

  A SIP protocol packet according to the SIP protocol is input from the SIP terminal 15 to the SIP load balancer 7 via the Internet 10. In this case, the SIP terminal 15 acquires the IP address of the SIP load balancer 7 as a logical SIP server address by a mechanism such as DNS or DHCP.

  The SIP load balancer 7 analyzes a part of the content of the input SIP protocol packet and acquires, for example, a URI. The SIP load balancer 7 refers to the location server 13 using the acquired SIP-URI as a key, and acquires a URI (VURI) associated with the virtual URI represented in the subdomain.

FIG. 7 shows a configuration example of the SIP load balancer 7.
The resolver 71 analyzes the URI portion of the SIP protocol packet and transfers it to the redirector 73. The redirector 73 refers to the location server 13 via the connection line 704 and transfers the acquired VURI to the SIP resolver 71. The SIP resolver 71 changes the URI of the SIP protocol packet to the obtained VURI. In addition, the redirector 73 grasps the load state of the SIP server group 12 (121 to 123) composed of a plurality of SIP servers from the load distribution database 74, and the SIP protocol packet so that the load on each SIP server 12 is smoothed. A certain SIP server (for example, 121) for processing is selected. Here, the load on the SIP server is smoothed by, for example, counting the number of session IDs being processed for each SIP server 12 and comparing the number of session IDs with each other.
The switch 72 is controlled based on the IP address of the selected SIP server 121, and the SIP protocol packet is output to the connection line 701 to the SIP server 121. The database structure of the location server 31 is as shown in FIG.

FIG. 8 shows the structure of the load balancing database 74.
In this DB 74, basic information of the session identified by the session ID 60, that is, the user name 61, URI 62, VURI 63, registered IP address 64, the IP address 65 of the SIP server responsible for processing corresponding thereto, and the SIP server A load state 66 is registered. The SIP server in charge of processing can be selected using the URI as a key or the session ID as a key. The load state of each SIP server is obtained by totaling and comparing the number of session IDs being processed in each SIP server.

The SIP load balancer 7 selects the SIP server 12 that should accommodate the user using the URI based on the VURI obtained from the location server 13 and the IP address of the accommodating SIP server, and transfers the SIP protocol packet. At that time, the SIP load balancer converts the URI into a VURI.
The selected SIP server (eg, 121) relays or processes the transferred SIP protocol packet according to a normal SIP processing procedure. The location server 13 registers the location of the SIP terminal 15 according to the SIP protocol.

  The SIP protocol packet relayed by the SIP server (for example, 122) is characterized by the VURI, and the SIP load balancer 7 to which the SIP protocol packet has been inputted refers to the location server 13 again and changes from the database shown in FIG. 6 to the VURI. Get the corresponding URI and registered IP address. Based on the acquired data, the SIP load balancer 7 converts the VURI into a URI and transmits it to the registered IP address.

Next, an operation for establishing a session in communication between SIP terminals in another embodiment with reference to FIGS. 6 to 8 will be described with reference to FIG.
Many operations in this example are similar to the operations shown in FIG. The main difference from the example of FIG. 5 is the operation in the SIP resolver 71 and the load distribution DB 74. In the following description, differences from FIG. 5 will be described focusing on the operations in the SIP resolver 71 and the load distribution DB 74.

  When the SIP resolver 71 receives a request message from the SIP terminal 150, the URI is extracted from the message (S901), and the URI-B is sent to the location server 13.

As shown in FIG. 3, the location server 13 maintains a URI / VURI correspondence table for each user name. By referring to the user name in this correspondence table, the VURI corresponding to URI-B is extracted. The VURI-B is transmitted to the load balancing DB 74 (S902).
In the load distribution DB 74, the correspondence relationship between the URI, the acquired VURI-B and the SIP server IP address is registered. Further, the VURI-B and the SIP server IP address are transmitted to the SIP resolver 71, where the URI is rewritten to the VURI (S904).

  The subsequent operation is the same as the operation of FIG. Regarding the registration deletion process, the difference from the above example is that the SIP resolver 71 and the load distribution DB 74 perform the registration deletion process of the correspondence between the URI and the VURI (S934, 93 ′). ).

  What is characteristic in this example is that in the processing S903 of the load distribution DB 74, the dialog processing of the session is assigned to the SIP server according to the load state (large to small) of the plurality of SIP servers 12. Here, the load state “large” means that the number of connected sessions is large, and conversely “small” means that the number of sessions is small.

  According to the present embodiment, the SIP load balancer 7 having a function of analyzing only a part of the SIP protocol is combined with a normal SIP server, so that the capacity of the SIP server can be dynamically processed with respect to the URI. There is an effect that it becomes possible in the form of allocation.

Next, a communication system using the SIP management server 110 according to another embodiment will be described with reference to FIG. In this example, the SIP management server 110 realizes the function of the SIP gateway 2 shown in FIG.
The SIP management server 110 includes a CPU 112 connected to an internal bus 118, a storage unit 114, and an interface unit 116. The sub-domain distribution DB 3 is connected to the internal bus 118 via a SCSI interface or the like. In addition, a plurality of SIP servers 12 (FIG. 1) are connected to the network interface 116, and perform data transmission / reception with a communication partner according to a predetermined protocol. The CPU 112 realizes the functions of the SIP header analysis unit 1122, the SIP header conversion unit 1124, and the database (DB) inquiry unit 112 by executing programs.

  The SIP header analysis unit 1122 extracts the destination or transmission source URI from the SIP protocol packet received from the SIP terminal 15 and passes it to the DB inquiry unit 1126. The DB inquiry unit 1126 inquires the sub-domain distribution DB 3 for the extracted URI, and acquires the corresponding VURI and IP address. The SIP header conversion unit 1124 converts the destination or transmission source URI of the received SIP protocol packet into a VURI, and converts the destination IP address into a returned IP address. The storage unit 114 stores a table including the correspondence relationship between the URI used for the inquiry and the VURI returned from the subdomain distribution DB 3 and the IP address.

  Next, a communication system using the SIP management server 110 'according to another embodiment will be described with reference to FIG. In this example, the function of the SIP load balancer 7 shown in FIG. 7 is realized by the SIP management server 110 ′. 11, the same reference numerals as those in FIG. 10 denote the same parts. In the configuration of FIG. 11, a load management unit 1128 is added, thereby managing the information on the load state registered in the load distribution DB 74. Furthermore, in order to manage the load state, the storage unit 114 stores a load management table 1200 as shown in FIG.

  In FIG. 12, the load management table 1200 stores the current number of sessions 1202 corresponding to the accommodated SIP server IP address 1201, and compares the current number of sessions with a reference value to determine the load level 1203. It is decided. That is, since the number of sessions allocated to the SIP server 12 changes from moment to moment, if the number of sessions increases by one for each IP address, the current number of sessions is incremented by +1, and conversely by one, it decreases by one. The current session number 1202 is reflected and held. The four-digit number shown indicates the current number of sessions. Then, based on the specifications for the SIP server 12, for example, the number of sessions of 4000 is standard, and the number of sessions is divided into 1000 units so that the load state can be set in a plurality of stages. For example, the current number of sessions up to 999 is level I, 1000 to 1999 is level II, and the load level is shown as I to V (illustrated example).

FIG. 13 shows an operation sequence in the communication system using the SIP management server 110 of FIG. The operation of the communication system of FIG. 11 will be described with reference to the sequence diagram of FIG.
The difference between FIG. 9 and FIG. 9 is that load level confirmation (S1301) and load level update (S1302) steps are added in the SIP management server 110 ′ of FIG.

  That is, when the SIP management server 110 ′ extracts the URI (S901), the load management unit 1128 refers to the load state level 1203 of the load management table 1200 and confirms the load state level (S1301). Then, for example, the accommodated SIP server IP address corresponding to the lowest load state level 1203 is acquired. The subsequent processing is the same as in FIG.

  A series of processes in the sequence of FIG. 13 is finished, and the last process includes an update operation of the load state level 1203 of the load management table 1200. This is because the number of sessions with respect to each SIP server 12 increases or decreases during the series of processes in FIG. 13 and the current number of sessions 1202 also changes, so the load state level 1203 is also changed accordingly. .

The figure which shows the structure of the communication system using the SIP terminal by one Example. The figure which shows the structure of the SIP gateway 2 in one Example. The figure which shows the structure of the subdomain distribution database 3 in one Example. The figure which shows the example of communication of the SIP message between the SIP terminals by one Example. The sequence diagram which shows the operation example for session establishment in communication between the SIP terminals by one Example. The figure which shows the structure of the communication system using the SIP terminal by another Example. The figure which shows the structure of the SIP load balancer 7 in another Example. The figure which shows the structure of the load distribution database 74 in another Example. The sequence diagram which shows the operation example for session establishment in communication between the SIP terminals by another Example. The figure which shows the structure of the communication system using the SIP management server 110 by another Example. The figure which shows the structure of the communication system using SIP management server 110 'by another Example. The figure which shows the structure of the load management table 1200 in the communication system using SIP management server 110 'by another Example. The sequence diagram which shows the operation example for the session establishment in communication between the SIP terminals in another Example using SIP management server 110 '.

Explanation of symbols

2: SIP gateway 121-123: SIP server 131-133: Location server 3: Subdomain distribution database 15: SIP terminal 7: SIP load balancer 110, 110 ': SIP management server.

Claims (11)

In a SIP control apparatus that processes a connection request from a SIP terminal connected via an IP network based on the procedure of a session initiation protocol (SIP), refer to the header content of the SIP protocol packet from the SIP terminal, Based on at least a part of the information in the header, a gateway that performs control for transferring the SIP protocol packet to a SIP server having a plurality of SIP servers, and information for changing the part of the information are registered. A combined session control device. A SIP control apparatus for processing a connection request from a SIP terminal connected via an IP network based on a SIP procedure, wherein a plurality of SIP servers and a SIP from a SIP terminal are connected to one of the plurality of SIP servers. Having a function of transferring a protocol packet, wherein the transfer function acquires address information for selecting one of the plurality of SIP servers by using a part of information of the SIP protocol packet as a key, and the SIP protocol packet A composite session control apparatus characterized by acquiring information for rewriting the information of the part or the information of the other part. In a SIP control apparatus that processes a connection request from a SIP terminal connected via an IP network based on a SIP procedure, a plurality of SIP servers and a SIP protocol from the SIP terminal to any of the plurality of SIP servers Transfer means for transferring packets, and storage means for registering a correspondence relationship between a session ID to which a SIP protocol packet transferred to the plurality of SIP servers belongs and a transferred SIP server,
A composite session control apparatus, characterized in that the transfer means performs control to select one of the plurality of SIP servers with reference to the correspondence relationship of the storage means. 4. The composite session control apparatus according to claim 3, wherein a location server is referred to from the transfer unit of the SIP protocol packet. 3. The function of transferring a SIP protocol packet according to claim 2, wherein the function of transferring the SIP protocol packet is a resolver function of analyzing a part of the SIP protocol packet, acquiring the address information and using the information of the part of the SIP protocol packet or the information of the other part. A composite session control apparatus comprising: a redirector for acquiring information for rewriting; and a switch for transferring the SIP protocol packet based on the address information. 4. The SIP protocol packet transfer means according to claim 3, wherein a resolver function for analyzing a part of the SIP protocol packet, individual SIP protocol sessions being processed in the composite session control server, and the plurality of SIP servers The SIP server address sharing the SIP protocol session of each of the SIPs, the redirector that determines the SIP server that forwards the SIP protocol packet based on the correspondence, and the SIP protocol based on the determination of the redirector A composite session control device having a function of transferring a packet to the SIP server. The SIP server is configured by a SIP proxy,
Further, the database registers a URI, a VURI, a registered IP address, and an IP address of an accommodation SIP server which are transmitted in a SIP protocol packet in association with a user name of a SIP terminal. 1 composite session controller. In a SIP control method for processing a connection request from a SIP terminal connected via an IP network based on a SIP procedure,
Extracting a URI designating a transmission destination included in a SIP protocol packet transmitted from the SIP terminal;
With respect to the extracted URI, referring to a database, obtaining a VURI virtually associated with the URI;
Replacing the URI in a SIP protocol packet with the obtained VURI;
Transmitting the SIP protocol packet including the VURI to a SIP server selected from a plurality of SIP servers;
The selected SIP server performs a dialog process on the received SIP protocol packet, and the location server registers the location information of the SIP terminal;
With respect to the VURI, referring to the database, obtaining a URI associated with the VURI;
Replacing the VURI in a SIP protocol packet with the obtained URI;
And a step of transmitting the created SIP protocol packet to a destination SIP terminal. The step of obtaining the VURI includes obtaining an IP address of an SIP server that processes the VURI,
9. The SIP control method according to claim 8, wherein the SIP protocol packet is transmitted to a SIP server selected based on the IP address. 9. The database registers a URI, a VURI, a registered IP address, and an IP address of an accommodation SIP server that are transmitted in a SIP protocol packet in association with a user name of a SIP terminal. Or 9 SIP control method. Corresponding to the IP address of the accommodated SIP server, refer to a table for managing the current number of sessions and load status, obtain an IP address with a low load, and obtain the VURI for the URI related to the IP address The SIP control method according to claim 9, wherein the load state of the table is updated after the VURI is converted to the URI.

Images