JP2016220027A - Repeating device, call control system, call control method, and call control program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To achieve call control reliably without modifying the nodes in a network and the terminals connected with the network, regardless of the operation form of the network.SOLUTION: A SBC1 installed on the boundary of a VoLTE network 4 and a SIP network 5 includes a UAS function unit 11 for receiving a request from a VoLTE terminal 2 connected communicably with the VoLTE network 4, and transmitting a response to the VoLTE terminal 2, a UAC function unit 12 for transmitting a request to an incoming side terminal 3 connected communicably with the SIP network 5, and receiving a response from the incoming side terminal 3, and a call control unit 13 for operating the UAS function unit 11 when the state of an offer set in a request from the VoLTE terminal 2 is a=inactive, but not operating the UAC function unit 12, and operating the UAS function unit 11 and UAC function unit 12 in the case other than a=inactive, and performing call control.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a technique for a call control procedure using SIP (Session Initiation Protocol), and more particularly, to an SBC (Session Border Control) technique for performing boundary control with another network or terminal.

  In communication using SIP (RFC3261), media information such as voice is described in the SDP (Session Description Protocol) format in the body part of a SIP message (hereinafter, sometimes simply referred to as “message”). The media actually used for the communication between the calling terminal and the called terminal is determined by the SDP offer / answer negotiation procedure defined in RFC3264.

  In recent years, LTE (Long Term Evolution) has been introduced as a mobile communication method, and high-quality voice communication (VoLTE: Voice over LTE) services on LTE have also started. SIP is used to control VoLTE voice communication. VoLTE guidelines are defined in GSMA IR.92 ("GSM" is a registered trademark), and specific technical specifications are defined in Non-Patent Document 1 and the like.

  One of the major features of VoLTE technical specifications is SIP preconditions (hereinafter sometimes simply referred to as “preconditions”) defined by RFC3312 / RFC4032 as an extended function of SIP. SIP preconditions refer to QoS (Quality of Service) control (here, the bandwidth and priority class settings for media packets such as voice, SDP for devices such as MGW (Media Gateway) that processes media packets. A terminal connected to a network that has a function (requesting / confirming based on information) exchanges the resource reservation status for communication with the other terminal, determines that the resource reservation has been completed from the SDP, and determines the media packet. This is a mechanism for starting transmission of media packets to each other when communication between the arrival and departure terminals is surely established.

  There are cases where a calling terminal that supports preconditions calls a called terminal that does not support preconditions. In this case, when the calling terminal starts a session with the called terminal, the SDP media is in an active state (a = sendrecv / sendonly / recvonly) (without resource reservation for starting the session). If it is set to (operating state), a call (RTP (Real-time Transport Protocol) transmission) from the called terminal is started. However, the resource reservation at the calling terminal is incomplete, so RTP does not reach the calling terminal (head of talk).

  FIG. 8 shows an example of a procedure for generating the above-mentioned talk break as a sequence. The VoLTE terminal 2 is a calling terminal that supports preconditions but does not reserve resources. The called terminal 3a is, for example, a SIP terminal that does not support preconditions. The IMS (IP Multimedia Subsystem) device 1a is a relay device that processes various messages (requests or responses) transmitted and received between the VoLTE terminal 2 and the called terminal 3a. Since the message types shown in FIG. 8 are well known, description thereof is omitted.

  In section 6.1.2 of Non-Patent Document 1, a procedure considering the case where the called terminal does not support preconditions is defined. Specifically, if the resource reservation necessary for starting the session is not made when the calling terminal starts the SIP session, the SDP offer of the Initial INVITE request sent at the start of the session includes a = This is a procedure for setting inactive (indicating the hold status).

  FIG. 9 shows an example of the procedure defined by Non-Patent Document 1 as a sequence. The IMS device 1a, VoLTE terminal 2, and destination terminal 3a in FIG. 9 are the same as those shown in FIG. In the SDP offer of the Initial INVITE request transmitted by the VoLTE terminal 2 at the start of the session, a = inactive (indicating a pending state) is set (SDP_O1: a = inactive). Upon receiving this SDP offer, the called terminal 3a transmits an SDP answer with a = inactive set in a subsequent SIP request or response according to RFC3264 (SDP_A1: a = inactive), once in an inactive state (a = inactive) for SDP negotiation. After resource reservation of VoLTE terminal 2 is completed (resource reserved), SDP offer / answer is made in active state (operation state) (SDP_O2: a = sendrecv, SDP_A2: a = sendrecv), then RTP (voice packet) ) Will be transmitted (call), so there will be no break in the talk.

"3GPP TS 24.229 V12.6.0 (2014-09)", [Search May 7, 2015], Internet <URL: http://www.3gpp.org/dynareport/24229.htm>

  Depending on the operation mode of the network, it is necessary to make it non-permitted to set a = inactive in the first SDP offer set in Initial INVITE. As such an operation mode, for example, there is an operation mode in which time charging is started when a 200 OK is received for an INVITE request. This mode of operation is employed when it is desired to avoid the inconvenience of being charged for time even if the call could not be made due to a speech break.

  However, as shown in the sequence of FIG. 10, the VoLTE terminal 2 that is not reserved for resources is in the hold state for the SIP network 5 that does not allow a = inactive to be set in the first SDP offer set in the Initial INVITE. When the call is transmitted (SDP_O1: a = inactive), an error response such as 488 (Not Acceptable Here) is returned from the SIP network 5 and the call is lost. In addition, in order to enable connection with a VoLTE terminal, when changing the policy of the SIP network and changing the implementation of all nodes in the SIP network and the terminals accommodated (connected) in the network, A huge cost is required.

  Therefore, in view of the above circumstances, the present invention makes a call without altering the nodes in the network and the terminals connected to the network, regardless of the operation mode of the network. It is an object to reliably realize the control.

  In order to solve the above-mentioned problem, the invention according to claim 1 is a relay device installed at the boundary between the originating network and the terminating network, and is communicably connected to the originating network. Receiving a request from the calling terminal, and transmitting a response to the calling terminal connected to the UAS function unit for transmitting a response to the calling terminal, and transmitting the request to the called terminal, and The UAC function unit that receives a response from the called terminal, and the UAS function unit that operates when the offer state set in the request from the calling terminal is in a pending state, but the UAC function And a call control unit that operates the UAS function unit and the UAC function unit to perform call control when the unit is in an operating state.

  The invention described in claim 4 is a relay apparatus installed at a boundary between the originating network and the terminating network, an originating terminal connected to the originating network, and a connection to the terminating network. A call control system that is communicably connected to the called terminal, wherein the relay device receives a request from the calling terminal and transmits a response to the calling terminal. Set to the offer set in the request from the calling terminal and the UAC function part that performs the transmission to the UAS function unit that performs, the UAC function unit that receives the response from the receiving terminal, and the response from the receiving terminal The UAS function unit is operated when the current status is on hold but the UAC function unit is not operated, and when it is in operation, the UAS function unit and the UAC function unit are operated, and call control is performed. A call control unit for performing To.

  The invention according to claim 5 is a call control method in a relay apparatus installed at a boundary between a calling side network and a called side network, and is connected to the calling side network so as to be communicable. When the offer state set in the request from the terminal is in the hold state, the request is received from the calling terminal and the response is transmitted to the calling terminal. A state set in the UAS step that does not send a request to the destination terminal that is communicably connected to the receiver, and does not receive a response from the destination terminal, and the request offer from the source terminal Is operating, receiving a request from the calling terminal, sending a request to the called terminal, receiving a response from the called terminal, and sending a response to the calling terminal. Performing a UAS / UAC step, the performing, and wherein the.

  According to a sixth aspect of the present invention, there is provided a request from a calling terminal connected to the calling network so as to be able to communicate with a computer as a relay device installed at the boundary between the calling network and the called network. And UAS function means for transmitting a response to the calling terminal, sending a request to the called terminal connected to the called network so as to be communicable, and a response from the called terminal UAC function means for receiving the request, when the offer state set in the request from the originating terminal is in a pending state, the UAS function means is operated, but the UAC function unit is not operated, the operating state Is a call control program for operating the UAS function means and the UAC function means to function as call control means for performing call control.

According to the first, fourth, fifth, and sixth aspects of the present invention, the call control unit of the relay device performs the UAC function when the state set in the offer of the request from the calling terminal is in the hold state. Return the response to the request from the originating terminal and terminate it. As a result, it is possible to avoid a call loss in which the resource of the calling terminal is not reserved and the called terminal cannot be called. In addition, when the state set in the offer of the request from the calling terminal is in operation, the UAC function unit is operated to call the called terminal after the calling terminal resource has been reserved. Normal call control can be realized. At this time, there is no need to change the network policy or change the terminal.
Therefore, regardless of the operation mode of the network, call control can be reliably realized without modifying the nodes in the network and the terminals connected to the network.

  The invention according to claim 2 is the relay apparatus according to claim 1, wherein the UAS function unit responds to the request in which the offer indicating the hold state is set with an answer set Is transmitted to the calling terminal, and a dialog is generated between the calling network and the relay device.

  According to the second aspect of the present invention, the UAS function unit generates a dialog between the originating network and the relay device, so that it is possible to avoid discarding the offer indicating the hold state once received. . Therefore, it is not necessary to receive the same offer again from the originating terminal that has already been reserved for resources, so that it is possible to simplify the processing procedure necessary for starting a session with the terminating terminal.

  The invention according to claim 3 is the relay apparatus according to claim 1 or 2, wherein the originating network is a VoLTE network, the originating terminal is a VoLTE terminal, and the terminating side The network is a SIP network, and the destination terminal is a terminal that does not support preconditions.

  According to the third aspect of the present invention, it is possible to realize call control in which a destination terminal that does not support preconditions is called after a VoLTE terminal resource has been reserved.

  According to the present invention, call control is reliably realized without altering the nodes in the network and the terminals connected to the network, regardless of the network operation mode. be able to.

1 is an overall configuration diagram of a call processing system of an embodiment. It is explanatory drawing of the characteristic of this invention. It is a list of message types of messages (SIP request and SIP response) transmitted and received in the call processing system of the present embodiment. FIG. 11 is a sequence diagram illustrating a processing example 1 based on an SDP setting of pattern 1; FIG. 10 is a sequence diagram showing a processing example 2 based on the SDP setting of pattern 2. FIG. 10 is a sequence diagram illustrating a processing example 3 based on the SDP setting of the pattern 3; It is a figure which shows the computer which executes a call processing program. It is a sequence diagram which shows the head break produced by a prior art. It is a sequence diagram which shows prevention of a talk head break by the technique of a nonpatent literature 1. FIG. 10 is a sequence diagram showing a connection between a VoLTE terminal and a SIP network that is not permitted to set “a = inactive”.

EMBODIMENT OF THE INVENTION The form (embodiment) for implementing this invention is demonstrated in detail, referring drawings.
As shown in FIG. 1, the call processing system of the present embodiment includes an SBC 1 (relay device), a VoLTE terminal 2 (originating terminal), and a called terminal 3. In this embodiment, a case where a call is made from the VoLTE terminal 2 to the called terminal 3 will be described. The VoLTE network 4 in FIG. 1 is the originating network, and the SIP network 5 is the terminating network.

  The SBC 1 is a gateway device arranged at the boundary between the VoLTE network 4 and the SIP network 5. The SBC 1 includes functional units such as a UAS function unit 11, a UAC function unit 12, and a call control unit 13.

  The UAS function unit 11 is a part that causes the SBC 1 to function as a UAS (User Agent Server). Specifically, the UAS function unit 11 receives a SIP request (request) from the VoLTE terminal 2 and transmits a SIP response (response) to the VoLTE terminal 2.

  The UAC function unit 12 is a part that causes the SBC 1 to function as a UAC (User Agent Client). Specifically, the UAC function unit 12 transmits a SIP request to the destination terminal 3 and receives a SIP response from the destination terminal 3.

  The call control unit 13 performs call control necessary for a call between the VoLTE terminal 2 and the called terminal 3.

  The VoLTE terminal 2 is a terminal that performs voice communication over LTE. The VoLTE terminal 2 is compatible with SIP preconditions.

  The called-side terminal 3 is a terminal that performs voice communication over SIP. In this embodiment, it is assumed that the VoLTE terminal 2 does not support SIP preconditions.

  The VoLTE network 4 is a network that connects the SBC 1 and the VoLTE terminal 2 so that they can communicate with each other. In the VoLTE network 4, nodes (for example, bridges, routers, not shown) that transfer SIP requests and SIP responses transferred between the SBC 1 and the VoLTE terminal 2 are arranged. Further, a management device (not shown) for monitoring the traffic of the nodes of the VoLTE network 4 and changing the policy of the VoLTE network 4 is connected to the VoLTE network 4 so as to be communicable.

  The SIP network 5 is a network that connects the SBC 1 and the called terminal 3 so that they can communicate with each other. In the SIP network 5, nodes (for example, bridges, routers, not shown) that transfer SIP requests and SIP responses transferred between the SBC 1 and the called terminal 3 are arranged. Further, a management device (not shown) for monitoring traffic of the nodes of the SIP network 5 and changing a policy of the SIP network 5 is connected to the SIP network 5 so as to be communicable.

  The SBC 1 according to the present embodiment includes a U2 function unit 11 and a UAC function unit 12 that have both functions of a UAS responsible for SIP request reception and SIP response transmission and a UAC responsible for SIP request transmission and SIP response reception. -to-back User Agent)

  As shown in FIG. 2, the SBC 1 that implements the B2BUA function is in a pending state when the direction attribute of the SDP offer of the SIP request received from the VoLTE terminal 2 is a = inactive, that is, the state set in the SDP offer If it is, it operates only as UAS and performs SDP negotiation with VoLTE terminal 2 (steps S101 and S102). Therefore, when the state set in the SDP offer is the hold state, the SBC 1 does not perform processing for establishing a session with the succeeding destination terminal 3.

  Thereafter, the SBC 1 starts the operation as the UAC when the direction attribute of the SDP offer from the calling side is other than a = inactive, that is, a = sendrecv / sendonly / recvonly. That is, when the state set in the SDP offer is in the operating state, the SBC 1 also operates as a UAC and performs SDP negotiation with the called terminal 3 (steps S103 to S106). Therefore, at the stage where the state set in the SDP offer becomes an operation state, the SBC 1 starts a process for establishing a session with the callee terminal 3 that is the rear end.

  The processing of the SBC 1 that implements the B2BUA function shown in FIG. 2 will be described. The process executed by the SBC 1 is handled by the call control unit 13. In the present embodiment, a specific example in which three types of SDP settings of patterns 1 to 3 are made as the processing of SBC 1 will be described. FIG. 3 shows a list of message types of messages (SIP requests and SIP responses) transmitted and received in the call processing system of this embodiment.

  For example, in the pattern 1 process of FIG. 3, an Initial-INVITE message (SIP request) transmitted from the “originating side” (VoLTE terminal 2) to “SBC” (SBC1) is called “offer (1)”. . In the pattern 1 process, a 200 OK (INVITE) message transmitted from the called side (called side terminal 3) to the SBC 1 is referred to as “answer (2)”. Since the meaning of the message type in FIG. 3 is well known, the description thereof is omitted.

(Processing example 1 based on SDP setting of pattern 1)
In this pattern, SBC1 sends 183 (Session Progress) in which an SDP answer including a = inactive is set to the calling side, and then sets the SDP offer that has become active (active) on the early dialog from the calling side. It is an example when receiving the updated UPDATE request. A sequence diagram is shown in FIG.
The SIP network 5 does not permit the setting of a = inactive for the first SDP offer (the same applies to patterns 2 and 3 described later).

  The SBC 1 sends an SDP offer (SDP_O1) (offer (1)) in which a = inactive is set in Initial-INVITE (INVITE request without a tag of the To header) to the VoLTE terminal 2 that has not reserved resources via the VoLTE network 4 (Steps S1, S3). At that time, 100 Trying is transmitted from the VoLTE network 4 to the VoLTE terminal 2 (step S2).

  The SBC 1 sets an SDP answer (SDP_A1) (answer (1)) in which a = inactive direction attribute is set in the 183 (Session Progress) response immediately after 100 Trying transmission to the VoLTE network 4 (step S4). It transmits to the VoLTE terminal 2 (step S5).

  The UAS function unit 11 generates a to-tag of a 183 (Session Progress) response to be transmitted, so that the Dialog-A (Call-ID header received from the VoLTE terminal 2 and from from the VoLTE terminal 2 between the SBC1 and the VoLTE network 4) -tag value and the To-tag value transmitted to the VoLTE terminal 2) are generated (step S6). By generating Dialog-A between the SBC 1 and the VoLTE network 4, the UAS function unit 11 can avoid receiving the SDP offer (SDP_O 1) in which a = inactive is set once. Therefore, since it is not necessary to receive the SDP offer (SDP_O1) again from the VoLTE terminal 2 that has already been reserved for resources, the processing procedure necessary for starting the session with the called terminal 3 can be simplified. it can.

Thereafter, the SBC 1 confirms the arrival of the 183 (Session Progress) response by receiving a PRACK request from the VoLTE terminal 2 (step S7) and transmitting a 200 OK response to the VoLTE terminal 2 in response to the request (step S8). )I do.
For convenience of explanation, “200 OK” may be simply expressed as “200”.

  After resource reservation is completed in VoLTE terminal 2 (resource reserved), SBC1 sets SDP offer (SDP_O2) (offer (2)) with a direction attribute other than a = inactive set on Dialog-A The updated UPDATE request is received (step S9). Then, in order to start a session with the called terminal 3, the SBC 1 sends an Initial INVITE request in which the SDP (SDP_O2) (offer (2)) generated based on the SDP set in the UPDATE request is set to the SIP network. 5 to the destination terminal 3 (steps S10 and S12). At that time, 100 Trying is transmitted from the SIP network 5 to the SBC 1 (step S11).

  The called terminal 3 transmits 100 Trying to the SIP network 5 (step S13), and immediately transmits 180 Ringing to the SBC 1 (step S14). When 180 Ringing is received, Dialog-B (consisting of the value of the transmitted Call-ID header / from-tag and the value of the received to-tag) is generated between the SBC 1 and the called terminal 3 ( Step S15). Thereafter, the SBC 1 performs a PRACK request transmission process to the destination terminal 3 (step S16) and a 200 OK response reception process (step S17) for the request from the destination terminal 3 as arrival confirmation of 180 Ringing. Do.

  Thereafter, the SBC 1 receives the SDP answer (SDP_A2) (answer (2)) with 200 OK (INVITE) from the called terminal 3 (step S18). Then, the SBC 1 sets the SDP (SDP_A2) (answer (2)) generated based on the SDP answer as a 200 OK response to the UPDATE request received from the previous (step S9) VoLTE terminal 2, and the VoLTE terminal 2 (Step S19).

  Immediately after transmitting the 200 OK response to the UPDATE request, the SBC 1 transmits a 180 Ringing response and a 200 OK response to the Initial INVITE request to the VoLTE terminal 2 on Dialog-A (steps S20 and S21). Thereafter, the SBC 1 communicates the ACK received from the VoLTE terminal 2 to the called terminal 3 (step S22), so that the VoLTE terminal 2 and the called terminal 3 start a call.

(Processing example 2 based on pattern 2 SDP setting)
In this pattern, SBC1 sends 183 (Session Progress) in which an SDP answer including a = inactive is set to the calling side, and then sets the SDP offer that has become active (active) on the early dialog from the calling side. This is an example of receiving a received PRACK request. A sequence diagram is shown in FIG.

  SBC 1 sends an SDP offer (SDP_O1) (offer (1)) in which a = inactive is set in Initial INVITE (INVITE request without tag of To header) from VoLTE terminal 2 that has not reserved resources via VoLTE network 4. Received (steps S31 and S33). At that time, 100 Trying is transmitted from the VoLTE network 4 to the VoLTE terminal 2 (step S32).

  SBC1 immediately sets 100 S Trying transmission to the VoLTE network 4 (step S34), and immediately sets an SDP answer (SDP_A1) (answer (1)) in which a = inactive direction attribute is set in the 183 (Session Progress) response. It transmits to the VoLTE terminal 2 (step S35).

  The UAS function unit 11 generates a to-tag of a 183 (Session Progress) response to be transmitted, thereby enabling Dialog-A (the value of the Call-ID header / from-tag received from the VoLTE terminal 2 and the VoLTE terminal). 2 (configured with the value of the To-tag transmitted to 2) (step S36). By generating Dialog-A between the SBC 1 and the VoLTE network 4, the UAS function unit 11 can avoid receiving the SDP offer (SDP_O 1) in which a = inactive is set once. Therefore, since it is not necessary to receive the SDP offer (SDP_O1) again from the VoLTE terminal 2 that has already been reserved for resources, the processing procedure necessary for starting the session with the called terminal 3 can be simplified. it can.

  After resource reservation is completed in VoLTE terminal 2 (resource reserved), SBC1 sets SDP offer (SDP_O2) (offer (2)) with a direction attribute other than a = inactive set on Dialog-A The received PRACK request is received (step S37). Then, the SBC 1 transmits an Initial INVITE request in which an SDP (SDP_O2) generated based on the SDP set in the PRACK request is set to start the session with the called terminal 3 (Step SBC1). S38, S40). At that time, 100 Trying is transmitted from the SIP network 5 to the SBC 1 (step S39).

  The called terminal 3 transmits 100 Trying to the SIP network 5 (step S41), and immediately transmits 180 Ringing to the SBC 1 (step S42). When 180 Ringing is received, Dialog-B (consisting of the value of the transmitted Call-ID header / from-tag and the value of the received to-tag) is generated between the SBC 1 and the called terminal 3 ( Step S43). Thereafter, the VoLTE terminal 2 confirms the arrival of 180 Ringing by transmitting a PRACK request to the destination terminal 3 (step S44) and receiving a 200 OK response to the request from the destination terminal 3 (step S45). )I do.

  Thereafter, the SBC 1 receives the SDP answer (SDP_A2) (answer (2)) with 200 OK (INVITE) from the called terminal 3 (step S46). Then, the SBC 1 sets the SDP (SDP_A2) (answer (2)) generated based on the SDP answer as a 200 OK response to the PRACK request received from the previous (step S37) VoLTE terminal 2, and the VoLTE terminal 2 (Step S47).

  Immediately after transmitting the 200 OK response to the PRACK request, the SBC 1 transmits a 180 Ringing response and a 200 OK response to the Initial INVITE request to the VoLTE terminal 2 on Dialog-A (steps S48 and S49). Thereafter, the SBC 1 causes the ACK received from the VoLTE terminal 2 to communicate with the called terminal 3 (step S50), whereby the VoLTE terminal 2 and the called terminal 3 start a call.

(Processing example 3 based on SDP setting of pattern 3)
In this pattern, SBC1 sends a 200 (OK) response with an SDP answer including a = inactive to the originating side in response to the Initial-INVITE request. This is an example in the case of receiving an UPDATE request in which an SDP offer set to (status) is set. A sequence diagram is shown in FIG.

  SBC 1 sends an SDP offer (SDP_O1) (offer (1)) in which a = inactive is set in Initial INVITE (INVITE request without tag of To header) from VoLTE terminal 2 that has not reserved resources via VoLTE network 4. Receive (steps S61 and S63). At that time, 100 Trying is transmitted from the VoLTE network 4 to the VoLTE terminal 2 (step S62).

  The SBC 1 transmits 100 Trying to the VoLTE network 4 (step S64). After that, the UAS function unit 11 immediately sends a 200 OK response including the SDP answer (SDP_A1) (answer (1)) in which the direction attribute of a = inactive is set to the 180 Ringing and Initial-INVITE request to the VoLTE terminal. 2 (steps S65 and S66). At this stage, Dialog-A (configured similarly to Dialog-A in patterns 1 and 2) is established between SBC1 and VoLTE terminal 2 (step S67). The SBC 1 receives an ACK from the VoLTE terminal 2 (step S68). By establishing Dialog-A between the SBC 1 and the VoLTE network 4, the UAS function unit 11 can avoid receiving the SDP offer (SDP_O 1) in which a = inactive is set once. Therefore, since it is not necessary to receive the SDP offer (SDP_O1) again from the VoLTE terminal 2 that has already been reserved for resources, the processing procedure necessary for starting the session with the called terminal 3 can be simplified. it can.

  After resource reservation is completed in VoLTE terminal 2 (resource reserved), SBC1 sets SDP offer (SDP_O2) (offer (2)) with a direction attribute other than a = inactive set on Dialog-A The updated UPDATE request is received (step S69). Then, in order to start a session with the called terminal 3, the SBC 1 sends an Initial INVITE request in which the SDP (SDP_O2) (offer (2)) generated based on the SDP set in the UPDATE request is set to the SIP network. 5 to the called terminal 3 (steps S70 and S72). At that time, 100 Trying is transmitted from the SIP network 5 to the SBC 1 (step S71).

  The called terminal 3 transmits 100 Trying to the SIP network 5 (step S73), and then immediately transmits 180 Ringing to the SBC 1 (step S74). When 180 Ringing is received, Dialog-B (consisting of the value of the transmitted Call-ID header / from-tag and the value of the received to-tag) is generated between the SBC 1 and the called terminal 3 ( Step S75). Thereafter, the SBC 1 performs transmission processing of a PRACK request to the destination terminal 3 (step S76) and reception processing of a 200 OK response to the request from the destination terminal 3 (step S77) as 180 Ringing arrival confirmation. Do.

  Thereafter, the SBC 1 receives the SDP answer (SDP_A2) (answer (2)) from the called terminal 3 with 200 OK (INVITE) (step S78). Then, the SBC 1 transmits an ACK to the destination terminal 3 (step S79), and the 200 OK response to the UPDATE request received from the VoLTE terminal 2 before (step S69) the SDP (SDP_A2) generated based on the SDP answer. By setting (S80) and transmitting (step S80), the VoLTE terminal 2 and the called terminal 3 start a call.

According to the present embodiment, the call control unit 13 of the SBC 1 operates the UAC function unit 12 when the state set in the request offer from the VoLTE terminal 2 is the hold state (a = inactive). First, a response is returned to the request from the VoLTE terminal 2 and terminated. As a result, it is possible to avoid a call loss in which the resources of the VoLTE terminal 2 are not reserved and the called terminal 3 cannot be called. Moreover, when the state set in the offer of the request from the VoLTE terminal 2 is in the operating state (a = sendrecv / sendonly / recvonly), the resource of the VoLTE terminal 2 is reserved by operating the UAC function unit 12 Then, the normal call control of calling the called terminal 3 can be realized. At this time, there is no need to change the network policy or change the terminal.
Therefore, regardless of the operation mode of the network, call control can be reliably realized without modifying the nodes in the network and the terminals connected to the network.

(program)
It is also possible to create a program in which processing executed by the relay device according to the above embodiment is described in a language that can be executed by a computer. In this case, the same effect as the above-described embodiment can be obtained by the computer executing the program. Further, such a program may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read by a computer and executed to execute the same processing as in the above embodiment. Hereinafter, an example of a computer that executes a call control program that realizes the same function as the relay apparatus will be described.

  FIG. 7 is a diagram illustrating a computer that executes a call control program. As illustrated in FIG. 7, the computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080.

  The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012. The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1090. The disk drive interface 1040 is connected to the disk drive 1100. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100, for example. For example, a mouse 1110 and a keyboard 1120 are connected to the serial port interface 1050. For example, a display 1130 is connected to the video adapter 1060.

  Here, as shown in FIG. 7, the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. Each table described in the above embodiment is stored in the hard disk drive 1090 or the memory 1010, for example.

  Further, the call control program is stored in the hard disk drive 1090 as a program module in which a command executed by the computer 1000 is described, for example. Specifically, a program module describing each process executed by the call control program described in the above embodiment is stored in the hard disk drive 1090.

  Further, data used for information processing by the call control program is stored in the hard disk drive 1090 as program data, for example. Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the hard disk drive 1090 to the RAM 1012 as necessary, and executes the above-described procedures.

  The program module 1093 and the program data 1094 related to the call control program are not limited to being stored in the hard disk drive 1090. For example, the program module 1093 and the program data 1094 are stored in a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. May be issued. Alternatively, the program module 1093 and the program data 1094 related to the call control program are stored in another computer connected via a network such as a LAN (Local Area Network) or a WAN (Wide Area Network), and are transmitted via the network interface 1070. May be read by the CPU 1020.

(Other)
In this embodiment, the SIP network 5 and the VoLTE network 4 are connected as a SIP termination procedure when the SIP network 5 and the VoLTE network 4 that do not permit the first SDP offer in which “a = inactive” is set are interconnected. The procedure of installing SBC1 and terminating at SBC1 has been described, but the arrangement of the procedure itself need not be limited to SBC.

A technique obtained by appropriately combining various techniques described in the present embodiment can also be realized.
The software described in this embodiment can be realized as hardware, and the hardware can also be realized as software.
In addition, hardware, software, flowcharts, and the like can be changed as appropriate without departing from the spirit of the present invention.

1 SBC (relay device)
2 VoLTE terminal (calling terminal)
3 Termination side terminal 4 VoLTE network (origin side network)
5 SIP network (destination side network)
11 UAS function part 12 UAC function part 13 Call control part

Claims (6)

A relay device installed at the boundary between the originating network and the terminating network,
Receiving a request from a calling terminal connected to the calling network so as to be communicable, and transmitting a response to the calling terminal;
Sending a request to a destination terminal communicably connected to the destination network, and receiving a response from the destination terminal; and a UAC function unit,
When the offer state set in the request from the calling terminal is in the hold state, the UAS function unit is operated but the UAC function unit is not operated. And a call control unit that operates the UAC function unit and performs call control,
A relay device characterized by that. In response to the request in which the offer indicating the hold state is set, the UAS function unit transmits a response in which an answer is set to the calling terminal, and between the calling network and the relay device. Create a dialog,
The relay apparatus according to claim 1. The originating network is a VoLTE network,
The calling terminal is a VoLTE terminal,
The destination network is a SIP network;
The called terminal is a terminal that does not support preconditions,
The relay apparatus according to claim 1, wherein the relay apparatus is characterized in that Communication is possible between the relay device installed at the boundary between the originating network and the terminating network, the originating terminal connected to the originating network, and the terminating terminal connected to the terminating network. A call control system connected to
The relay device is
Receiving a request from the calling terminal, and transmitting a response to the calling terminal; a UAS function unit;
Sending a request to the called terminal, and receiving a response from the called terminal; a UAC function unit;
When the offer state set in the request from the calling terminal is in the hold state, the UAS function unit is operated but the UAC function unit is not operated. And a call control unit that operates the UAC function unit and performs call control,
A call control system. A call control method in a relay apparatus installed at a boundary between a calling side network and a called side network,
When the offer state set in the request from the originating terminal that is communicably connected to the originating network is on hold, the reception of the request from the originating terminal, and the originating side Sending a response to the terminal, but sending a request to the called terminal that is communicably connected to the called network, and a UAS step not receiving a response from the called terminal;
When the status set in the offer of the request from the calling terminal is in an operating state, the request is received from the calling terminal, the request is transmitted to the called terminal, and the request from the called terminal is received. Performing a UAS / UAC step for receiving a response and transmitting a response to the calling terminal;
A call control method. A computer as a relay device installed at the boundary between the originating network and the terminating network,
UAS function means for receiving a request from a calling side terminal communicably connected to the calling side network, and transmitting a response to the calling side terminal;
A UAC function means for transmitting a request to a destination terminal that is communicably connected to the destination network, and receiving a response from the destination terminal;
When the offer state set in the request from the calling terminal is in a pending state, the UAS function unit is operated, but the UAC function unit is not operated, and the UAS function unit is operated in an operating state. Call control means for operating the UAC function means and performing call control,
Call control program to function as

Images