JP5216249B2 - Call control apparatus and call control method - Google Patents

Description

  The present invention relates to a call control apparatus and a call control method for performing processing for connecting a call between a caller and a callee in a VoIP (Voice over Internet Protocol) network.

  FIG. 11 is a network configuration diagram in which a public telephone network (PSTN) and a VoIP network are connected via a gateway device. The public telephone network is composed of a circuit switch 1 such as a PBX or a central office switch, and the VoIP network is composed of a soft switch 2 corresponding to the central office switch. The circuit switch 1 and the soft switch 2 accommodate a plurality of user terminals, respectively. For example, when a call is made from the calling user terminal 4 accommodated in the soft switch 2 to the destination 5 accommodated in the circuit switch 1, the request regarding the call request received from the calling user terminal 4 by the soft switch 2 is transmitted to the public telephone network. To the circuit switch 1 of When the line switch 1 of the public telephone network receives an incoming call to the accommodation terminal, it makes an incoming call to the corresponding destination 5. At this time, when entering the public telephone network from the VoIP network, the gateway device 6 converts the signal from the VoIP protocol to a signal format corresponding to the public telephone network protocol. The circuit switch 1 and the soft switch 2 can also be equipped with a transfer function. For example, a call to the accommodation terminal 4 of the soft switch 2 can be set to be transferred to the accommodation terminal of the circuit switch 1. Conversely, a call to the accommodation terminal of the circuit switch 1 can be set to be transferred to the accommodation terminal of the soft switch 2. When an incoming call from a certain transmitting terminal to the accommodation terminal 4 of the soft switch 2 occurs, the soft switch 2 does not receive the incoming call to the accommodation terminal 4 but transfers the incoming call to the circuit switch 1 to receive the incoming call to the accommodation terminal 5. be able to.

  By the way, when it is set to transfer a call with the receiving terminal 5 of the circuit switch 1 to the receiving terminal 4 of the soft switch 2, the call sent from the soft switch 2 to the circuit switch 1 Will come back again. Since the soft switch 2 transfers again to the accommodating terminal 5 of the circuit switch 1 according to the transfer setting, a phenomenon occurs in which a call loops between the soft switch 2 and the circuit switch 1. Even if the circuit switch 1 is set to transfer a call to the accommodation terminal 5 to an accommodation terminal other than the soft switch 2, the soft switch 2 is connected via another soft switch or a circuit exchange. May come back.

  As described above, when a loop is formed between the soft switch 2 of the VoIP network and the circuit switch 1 of the public telephone network and call transfer is repeated, the accommodated lines of the gateway device 6 are sequentially consumed and the number of used lines is increased. However, when the maximum number of accommodated lines is reached, processing becomes impossible. In addition, there is a risk that the software switch 2 and the circuit switch 1 may cause a communication load to be disabled due to a significant increase in load related to call processing (loop) that is originally unnecessary.

  In the case of a SIP-compatible soft switch, the loop formed by the transfer of a call can be prevented by using the unique characteristic of the dialog ID or the Max-Forwards header. The SIP-compatible soft switch assigns transfer source information to the transfer call using a Referred-By header or the like. Therefore, it is possible to detect the number of transfers from the Referred-By header attached to the incoming call, for example, so that the transfer is not performed after the fifth time. If the transfer process is interrupted when the Max-Forwards decrement value reaches the lower limit, a call loop can be prevented.

In an exchange system that performs connection-less exchange processing by segmenting and transmitting communication data messages into segment data of a predetermined data length, such as an ATM (Asynchronous Transfer Mode) exchange system or a frame relay exchange system, congestion, etc. When discarding message information during transmission due to the occurrence of a failure, message information is proactively selected rather than indiscriminately discarded, and some of the messages being transmitted are selectively ensured. It has been proposed to improve the substantial transmission efficiency of the system (for example, see Patent Document 1).
JP-A-9-116558

However, the loop prevention function using the unique characteristic of the dialog ID or the Max-Forwards header of the above-mentioned prior art is when there is a gateway device or B2BUA (Back To Back User Agent) type entity between PSTN protocol and VoIP protocol. Cannot be used because the dialog ID changes each time and the Max-Forwards decrement value is cleared. The above loop prevention function is based on the premise that the soft switch gives the Referred-By header to the forwarded call, but some carriers may not give the Referred-By header even for forwarded calls. Therefore, there is a problem that the loop prevention function does not always function.
In addition, the gateway device between SIP and PSTN is not limited to MGCP.
(Media Gateway Control Protocol) -SIP or H.264. A gateway device that performs trunking between H.323 and SIP, and a device that handles voice even between SIP and SIP (for example, SBC (Session Boarder
Even in the case where there is a controller)), a problem occurs in which resources (accommodated lines) are exhausted due to repeated transfer of calls in a loop.

  There have also been reports of attacks that intentionally concentrate a large number of calls to specific destinations accommodated in a soft switch or circuit switch, overload the soft switch or circuit switch, and stagnate the switching function. Yes. However, the current defense functions including the loop prevention function cannot sufficiently prevent these attacks.

  The present invention has been made in view of the above circumstances. On the one hand, it is possible to limit the number of incoming calls to the same user regardless of whether or not a loop is formed. It is an object of the present invention to provide a call control device and a call control method that can prevent the exhaustion of resources (accommodated lines) and the overload of a circuit switch or a soft switch.

The call control device according to the present invention comprises: a call processing means for performing a process for connecting a call between a caller and a callee on a VoIP network based on SIP (Session Initiation Protocol); Remove the the destination information from the to header of the INVITE request even if the header is not added to indicate that a transferred call in the INVITE request, has been received several times an INVITE request of the same call to each destination And a call restriction that restricts the transfer operation of the INVITE request when the count value reaches the upper limit for the destination specified in the To header of the INVITE request received by the call processing means. And means.
Further, the call control device of the present invention is H.264. Based on H.323, call processing means for performing a process for connecting a call between the calling side and the called side on the VoIP network, and extracting the destination information from the Called Party Number of the Setup request received by the call processing means Te, counting means for counting whether it has received a Setup request of the same call times for each destination, said call processing means and said count value is an upper limit value for the specified destination on the called Party Number in the Setup request received by the And call restriction means for restricting the transfer operation of the Setup request.

  According to the call control device configured as described above, when a large number of requests specifying the same destination are generated, the count value reaches the upper limit for the destination and the transfer operation is not performed. It is possible to prevent a large number of calls from being concentrated on the destination and to prevent overload of the soft switch. In addition, because the destination information of the request does not change even if the transfer is repeated, the count value reaches the upper limit for the destination even if the transfer call loops with a call processing server on a different protocol. Thus, the transfer operation is not performed, and it is possible to prevent a problem that the resources (accommodated lines) are exhausted in the gateway device or the like disposed between the call processing servers of different protocols.

  Further, the present invention is characterized in that in the call control device, the count value is written to and read from an internal memory accessible at high speed.

  Thus, by writing and reading the count value to / from the internal memory that can be accessed at high speed, the waiting time during memory access can be shortened, so even if frequent access to the internal memory occurs, the request The processing load required for determining whether the counter value has reached the upper limit value for the destination specified in (2) can be reduced.

  Further, the present invention is characterized in that, in the call control device, a sweep interval is set for each count value, and a count value that has not changed within the sweep interval period is cleared to zero.

  As a result, the count value that has not changed during the sweep interval period is cleared to 0, so that the count value can be sorted for destinations other than destinations where calls are concentrated in a short time.

Furthermore, INVITE request call control method of the present invention, in the call control method which performs processing for connecting the call between the calling party on the VoIP network based of SIP (Session Initiation Protocol) and the terminating side, the received Remove the destination information from the to header of the INVITE request even if the header is not added to indicate that a transfer call, counts the received the INVITE request with the same call number of times for each destination And a step of determining whether or not the count value has reached the upper limit for the destination specified in the To header of the received INVITE request, and as a result of the determination, the count value has reached the upper limit. And a step of restricting the transfer operation of the INVITE request.
Also, the call control method of the present invention is based on H.264. In the call control method which performs processing for connecting the call between the calling and called party on the VoIP network, based on 323 retrieves the destination information from the Called Party Number in the Setup request received, each destination Counting the number of times the same call setup request has been received, determining whether the count value has reached an upper limit for the destination specified in the Called Party Number of the received setup request, A step of restricting a transfer operation of the Setup request when the count value has reached an upper limit value as a result of the determination.

  According to the call control method configured in this way, when a large number of requests specifying the same destination occur, the count value reaches the upper limit for the destination and the transfer operation is not performed. It is possible to prevent a large number of calls from being concentrated on the destination, and it is possible to avoid a communication disabled state due to an increase in call processing load.

  According to the present invention, it is possible to limit the number of incoming calls to the same user regardless of whether or not a loop is formed and to prevent overloading of the soft switch, while it is possible to avoid loops and prevent depletion of resources (accommodated lines) and It is possible to prevent overloading of circuit switches and soft switches.

Hereinafter, a SIP-compatible soft switch will be described as a call control device according to an embodiment of the present invention, but the present invention is not limited to a SIP-compatible soft switch.
FIG. 1 is a network configuration diagram including a VoIP network provided with a soft switch according to the present embodiment and a different protocol network connected through a gateway device. The VoIP network 10 includes a plurality of soft switches 13-1 to 13-n that perform call processing based on SIP, and the different protocol network 11 includes one or a plurality of call processing servers. The different protocol network 11 shown in FIG. 1 illustrates one call processing server. The VoIP network 10 and the different protocol network 11 are connected via a gateway device 12 that converts each other's protocol. The soft switches 13-1, 13-2 and the like accommodate user terminals 15-1 to 15-n and 16-1 to 16-n, which are subscriber terminals, respectively, and set transfer destinations for each subscriber. It is configured to be able to. The call processing server 14 accommodates user terminals 17-1 to 17-n serving as subscriber terminals, and is configured so that a transfer destination and the like can be set for each subscriber.

  FIG. 2 is a conceptual diagram of the soft switch 13-1. The soft switch 13-1 includes call processing means 20 that performs processing for connecting a call between a caller and a callee on the VoIP network based on SIP. Further, the soft switch 13-1 includes a counting means 21 for extracting destination information from the INVITE request and counting each destination, and a destination user count memory 22 for recording a count value counted for each destination. The call restriction means 23 for restricting calls concentrated on the same destination and the destination information (at least including the count value) that has not changed within the sweep interval period in the called user count memory 22 are cleared to zero. And clearing means 24. The counting means 21 takes out the user part from the To header of the INVITE request received from another soft switch or circuit switch, and counts it for each destination set in the user part. FIG. 4 is a conceptual diagram of an INVITE request. The INVITE request used in SIP mainly includes a start line 31, a header field 32, a blank line, and a body 33. The To header 34 in the header field 32 is provided with a user part 35 indicating the destination of the request. Each part of the parameters set in the request shown in FIG. 4 is rewritten each time it is transferred, but the user part 35 of the To header 34 does not change even if it is transferred. In the present embodiment, focusing on the fact that the user part 35 of the To header 34 does not change even if it is transferred, it is detected that the same call request is repeatedly transferred, and calls are concentrated on a specific destination. It was made to detect that it is doing.

  The other soft switches 13-2 to 13-n are configured in the same manner as the soft switch 13-1.

  FIG. 3 is a conceptual diagram of write information written in the destination user count memory 22. The called user count memory 22 is written with the destination subscriber number 25, the count value 26 of the same destination, and the latest update time 27 of the count value 26. When the count value 26 reaches a predetermined value within a predetermined time, the call restriction means 23 interrupts the transfer of the request.

Next, the operation of the present embodiment configured as described above will be described.
FIG. 5 is a flowchart for restricting call transfer in the soft switch 13-1. The soft switch 13-1 receives an INVITE request from the other soft switches 13-2 to 13-n of the VoIP network 10, or receives an INVITE request from the call processing server 14 of the different protocol network 11 via the gateway device 12. .

  When the call processing means 20 of the soft switch 13-1 receives INVITE (step S1), in the case of a call that needs to be transferred to another soft switch or another call processing server, the counting means 21 causes the To header 34 of the INVITE to be included. The user part 35 is acquired from (step S2). It is determined whether or not the same destination (subscriber number 25) as the “destination” indicated by the user part 35 acquired this time is present in the called user count memory 22 (step S3). If the same called party is not registered in the called user count memory 22, the subscriber number 25 is additionally registered in the called user count memory 22 as the currently received "destination" (step S4), and further the count value 1 is set to 26 (step S5). In the present embodiment, the update time 27 is also registered at the same time in order to obtain an opportunity to clear the count value to zero.

  On the other hand, if it is determined in step S3 that the same destination is registered in the called user count memory 22, the upper limit value set in advance by reading the count value 26 of the called destination from the called user count memory 22 It is judged whether it has reached | attained (step S6). If the count value 26 has not reached the upper limit value, the count value 26 of the destination is increased by one (step S7).

  As described above, when the same destination as the “destination” acquired this time is not registered in the destination user count memory 22 (steps S3, S4, S5), the count value 26 of the destination is the upper limit. If the value has not been reached (steps S6 and S7), the call processing means 20 is given transfer permission and transferred to another soft switch or another call processing server (step S8). As a result, when calls are not concentrated on a specific destination, transfer processing can be performed as usual.

  On the other hand, if the destination count value 26 has reached the upper limit value in the determination in step S6, a 403 response is returned to the INVITE transmission source, and no transfer operation is performed (step S9). Thus, when the count value of the same destination reaches the preset upper limit value within a predetermined time, the count value 26 of the destination is routed through the soft switch 13-1 until the count value 26 of the destination is cleared to zero. Thus, the call cannot be transferred to another soft switch or circuit switch that accommodates the destination. For example, in the case where INVITE having the user terminal 16-1 accommodated in the soft switch 13-2 as a destination is concentrated in a short time, the surrounding soft switch 13-1 or the like that transfers INVITE to the soft switch 13-2 Thus, the transfer restriction is applied and the load on the soft switch 13-2 can be prevented from increasing.

  Next, a description will be given of the trigger for zero-clearing the count value 26 stored for each destination in the called user count memory 22.

  FIG. 6 is a flowchart showing an operation of clearing the count value of the called user count memory 22 to zero. In the present embodiment, the count value is cleared to zero when a final response is transmitted to the calling side (step S20) and when the sweep interval has elapsed (step S21). When the call processing means 20 transmits a final response to the calling side (step S20), the counter means 21 acquires the user part 35 from the To header 34 of the request (step S22) and stores it in the called user count memory 22. It is determined whether the same destination (subscriber number 25) as the acquired user part 35 is registered (step S23). If the same destination is registered, the clear unit 24 is instructed to clear the destination destination count value 26 in the destination user count memory 22 to zero (step S24).

  Further, the clearing unit 24 detects an incoming call destination that has passed a preset sweep interval from the latest update time 25 for the incoming call destination registered in the called user count memory 22 (step S21). If there is a count value 26 that has passed the sweep interval, it is cleared to 0 (step S24).

  In step S24, not only the count value 26 but all the destination information (subscriber number 25, count value 26 and update time 27) may be deleted.

  Thus, since the count value is cleared to zero when the final response is transmitted to the calling side (step S20) and when the sweep interval has elapsed (step S21), calls are concentrated on a specific accommodating terminal within a predetermined time (short time). Only when this is done, transfer of INVITE in which the destination is specified can be restricted. Further, since the count value is cleared to zero when the sweep interval elapses (step S21), it is possible to prevent the inconvenience that the count value remains unsorted when the zero clearing event such as no final response is made.

  Next, an operation for interrupting call transfer when a loop for repeating call transfer between two soft switches is formed will be described based on a specific example.

  FIG. 7 is a sequence diagram of the soft switch A and the soft switch B that are set so as to form a call transfer loop. The soft switch A and the soft switch B are assumed to have the same configuration as the soft switch 13-1.

  In FIG. 7, a call is made from a calling terminal (subscriber number = 012345678) to a user terminal (subscriber number = 05011110001) accommodated in the soft switch A, and the soft switch A sets the user terminal (05011110001). Based on the setting of the user terminal (09011110001), the soft switch B transfers the call to the user terminal (subscriber number = 09011110001) accommodated in the other soft switch B based on the user terminal (09011110001) setting. 05011110001) shows an example of transferring a call.

When a call is made from the calling terminal accommodated in the circuit switch to the accommodating terminal (05011110001) of the soft switch A, the soft switch A receives INVITE shown in FIG. The soft switch A determines from the received INVITE request URI that the user terminal (05011110001) accommodated by itself is the destination. Since the transfer destination is set in the user terminal (05011110001), an INVITE in which the transfer destination user terminal (09011110001) is set as the destination (To header) is generated and the incoming call is transferred to the destination user terminal ( 09011110001) is transmitted to the soft switch B that houses it. FIG. 8B shows the INVITE header structure for transferring a call from the soft switch A to the soft switch B. “09011110001” <sip: 09011110001@172.17.19.25: 5060> indicating the destination is set in the user part of the To header. Also, Referred-By indicating that the call is a transfer call from the user terminal (05011110001):
<sip: 05011110001@172.17.19.25> is added.

  The soft switch B receives INVITE shown in FIG. The soft switch B determines that the destination of the quest is the user terminal (09011110001) accommodated by itself from the request line of the reception INVITE. Since the transfer destination is set in the user terminal (09011110001), an INVITE in which the transfer destination user terminal (05011110001) is set as the destination (To header) is generated and the incoming call is transferred to the destination user terminal ( 05011110001) is transferred to the soft switch A that houses it. FIG. 9A shows the INVITE header structure when a call is transferred from the soft switch B to the soft switch A. FIG. “09011110001” <sip: 09011110001@172.17.19.25: 5060> indicating the destination is set in the user part of the To header. That is, the user part of the To header does not change even for a transfer call. Further, the soft switch B is not set to add a Referred-By header even when a call is transferred, and the Referred-By header is deleted. The decrement value of the Max-Forwards header is also initialized. Therefore, the soft switch A that has received this INVITE cannot prevent a loop even if the Referred-By header and the Max-Forwards header are used.

  In this embodiment, as described above, the user part (“09011110001” <sip: 09011110001@172.17.19.25: 5060>) of the To header is taken out and counted how many times INVITE of the same call is received for each destination. doing. In the sequence shown in FIG. 7, since the transfer is the first time, the count value for the destination (“09011110001” <sip: 09011110001@172.17.19.25: 5060>) is 1.

  As shown in FIG. 7, the INVITE of the same call is transferred again from the soft switch A to the soft switch B, and the soft switch B receiving the INVITE transfers the INVITE of the same call to the soft switch A again. FIG. 9B shows the INVITE header configuration during the second transfer from the soft switch B to the soft switch A. “09011110001” <sip: 09011110001@172.17.19.25: 5060> indicating the destination is set in the user part of the To header. Since this is the second transfer, the count value for the same destination ("09011110001" <sip: 09011110001@172.17.19.25: 5060>) is incremented by 1 to 2.

  If the upper limit of the called user count value is set to 5 in the soft switch A, “09011110001” <sip: 09011110001@172.17.19.25: 5060> is set in the user part of the To header from the soft switch A. The transfer is interrupted for the fifth and subsequent calls.

  As described above, each soft switch can reliably prevent a loop without using the Referred-By header and the Max-Forwards header.

  In the present embodiment, the called user count memory 22 is used as an internal storage medium that can be accessed at high speed so that the call restriction means 23 records the count value for each destination in the soft switch. Therefore, it is possible to limit incoming calls without increasing the load on the soft switch.

  However, even if a database composed of hard disks is used in place of the called user count memory 22, it is possible to limit the number of incoming calls to the same user and avoid loops. When the count value for each destination is recorded in the database, the access speed is lower than that of the called user count memory 22, but if the decrease in the access speed is not a problem, the database may be used. it can.

  The present invention is not limited to a SIP-compatible soft switch, and can be similarly applied to a call control device that operates based on a VoIP protocol other than SIP (for example, H.323).

  FIG. 3 is a sequence diagram illustrating a state in which a loop is formed between a gatekeeper on a H.323 network and a soft switch on a SIP network. FIG. H. A gatekeeper 31 is shown as a call control device that operates based on H.323. As a call control device on the SIP network, the soft switch 32, H. A gateway device 33 is shown as a device that performs protocol conversion between the H.323 network and the SIP network. H. In the H.323 network, a setup request is used as a request for a call request.

  H. If the destination is a terminal accommodated in a soft switch 32 of a different protocol, the gatekeeper 31 that has received the setup request from the originating terminal in the H.323 network sets up the subscriber number of the destination in the Called Party Number. Is transmitted to the soft switch 32 via the gateway device 33. The Setup request is converted into an INVITE request by the gateway device 33, but the Called Party Number is not rewritten.

  It is assumed that the setting contents of the destination to be accommodated by the soft switch 32 are to transfer a call to the terminal to the terminal accommodated by the gatekeeper 31. In this case, as shown in FIG. 10, the call is transferred by an INVITE request addressed to the terminal accommodated by the gatekeeper 31. At this time, as described above, the destination information in the To header is maintained as it is. In this way, a loop occurs on the SIP network side.

  The gatekeeper 31 also receives the Setup request converted from the INVITE request from the SIP network side. However, since the transfer setting for the destination is not changed, the Setup request is generated again with the same terminal accommodated by the soft switch 32 as the destination. Then, the data is transmitted to the soft switch 32 via the gateway device 33. At this time, the Called Party Number designating the destination on the Setup request is maintained without being rewritten. In this way, H.C. A loop also occurs on the H.323 network side.

  In the present invention, in both the gatekeeper 31 and the soft switch 32, based on the configuration shown in FIG. 2 and the processing content shown in FIG. 5, the gatekeeper 31 counts the same destination from the Called Party Number of the received Setup request. Limit transfers when the value is reached. The soft switch 32 counts the same destination from the To header of the received INVITE request and restricts the transfer when the upper limit is reached.

  In this way, H.C. Even in the gatekeeper 31 which is a call processing server on the H.323 network, when a loop in which a call is transferred repeatedly with another different protocol call processing server occurs, a problem that the gateway device 33 runs out of resources in advance. Can be prevented.

  In the above description, the case of occurrence of a loop in which call transfer is repeated mainly between call processing servers has been described as an example, but the present invention is not limited to such a loop avoidance purpose. The present invention is equipped with a function for checking and counting destination information (a To header of an INVITE request, a Called Party Number of a Setup request) related to a call request on a VoIP network. Regardless of the presence or absence of a loop, the number of incoming calls to the same user can be limited. Therefore, even if it is not set to form a loop between call processing servers, the function of limiting the number of incoming calls to the same user can be exhibited, and it is difficult to protect with a simple method in the prior art. Even an attack that intentionally concentrates a large number of calls to a specific destination can be surely protected with a simple configuration as described above.

1 is a network configuration diagram including a VoIP network and a public telephone network including a soft switch according to an embodiment of the present invention. Conceptual diagram of soft switch in the above embodiment Conceptual diagram of write information written to the called user count memory in the above embodiment The figure which shows the structural example of a SIP request Flow chart for restricting call forwarding in the soft switch of the above embodiment Flow chart for clearing the count value to 0 in the soft switch of the above embodiment Sequence diagram between soft switches when receiving a request from the calling terminal (A) Configuration diagram of INVITE transmitted from the calling terminal to the soft switch A, (b) Configuration diagram of INVITE transmitted from the soft switch A to the soft switch B in the first transfer. (A) Configuration diagram of INVITE transmitted from software switch B to software switch A in the first transfer, (b) Configuration diagram of INVITE transmitted from software switch B to software switch A in the second transfer H. 323 is a sequence diagram showing a state in which a loop is formed between a gatekeeper on the H.323 network and a soft switch on the SIP network. Network configuration diagram in which a public telephone network and a VoIP network are connected via a gateway device

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... VoIP network 11 ... Public telephone network 12 ... Gateway apparatus 13-1 to 13-n ... Soft switch 14 ... Circuit switch 15-1-15-n, 16-1-16-n, 17-1-17-n ... User terminal 20 ... Call processing means 21 ... Counting means 22 ... Destination user count memory 23 ... Call restriction means 24 ... Clearing means 25 ... Subscriber number 26 ... Count value 27 ... Update time

Claims (6)

Call processing means for performing processing for connecting a call between a caller and a callee on a VoIP network based on SIP (Session Initiation Protocol);
The call processing unit retrieves the destination information from the To header of the INVITE request even if the header is not added to indicate that a transferred call in the INVITE request received is, INVITE the same call to each destination A counting means to count how many times the request has been received ,
Call restriction means for restricting the transfer operation of the INVITE request when the count value reaches the upper limit for the destination specified in the To header of the INVITE request received by the call processing means. A call control device. H. Call processing means for performing processing for connecting a call between a calling side and a called side on the VoIP network based on H.323,
Counting means for taking out the destination information from the Called Party Number in the Setup request the call processing unit receives and counts the it has received a Setup request of the same call times for each destination,
Call restriction means for restricting the transfer operation of the Setup request when the count value has reached the upper limit for the destination specified in the Called Party Number of the Setup request received by the call processing means. A call control device.   3. The call control apparatus according to claim 1, wherein the count value is written to and read from an internal memory accessible at high speed.   4. The call control device according to claim 1, wherein a sweep interval is set for each count value, and a count value that has not changed within the sweep interval period is cleared to zero. In a call control method for performing processing for connecting a call between a caller and a callee on a VoIP network based on SIP (Session Initiation Protocol),
Received retrieves the destination information from the To header of the INVITE request even if the header is not added to indicate that a transferred call in the INVITE request, many times receive an INVITE request of the same call to each destination A process of counting whether or not
Determining whether the count value has reached an upper limit for the destination specified in the To header of the received INVITE request;
And a step of restricting the transfer operation of the INVITE request when the count value has reached an upper limit value as a result of the determination. H. In a call control method for performing processing for connecting a call between a caller and a callee on a VoIP network based on H.323,
Remove the destination information from the Called Party Number of the received Setup request, the steps of counting it has received a Setup request of the same call times for each destination,
Determining whether or not the count value has reached an upper limit for the destination specified in the Called Party Number of the received Setup request;
And a step of restricting the transfer operation of the Setup request when the count value has reached an upper limit value as a result of the determination.

Images