JP5210223B2 - Network control apparatus, BacktoBackUserAgent, call control apparatus, and network control method - Google Patents

Description

  The present invention relates to a technique for controlling the operation of a Back to Back User Agent that establishes a Session Initiation Protocol (SIP) session on an IMS (IP Multimedia Subsystem) network.

  Conventionally known SIP (Session Initiation Protocol) is a protocol used for call control on IP (Internet Protocol) and negotiates IP addresses, port numbers, encoding, etc. necessary for communication between communicating terminals. It is used for controlling outgoing calls and incoming calls. In addition, IMS (IP Multimedia Subsystem) performs network resource allocation and gate control necessary for communication based on the SIP information. Conventionally, SIP is a peer-to-peer type protocol that performs client-driven call control. However, SIP is adopted as call control in IMS, and operation by a communication operator is started.

  Under such circumstances, network-led control such as session handover, transmission of a control request from the network, and absorption of differences between terminals is required, but originally a peer-to-peer type is required. Since it is difficult to control SIP by network initiative, it is called Back to Back User Agent (hereinafter referred to as “B2BUA”) that once terminates the SIP session with equipment in the communication operator and constructs a new SIP session again. ) Is often used. This B2BUA receives a request from an IMS client, and is positioned as a logical entity that processes it as a user agent server (UAS). Acts as a user agent client (UAC) to generate a request to determine how the request should be answered. B2BUA, unlike a proxy server, maintains a dialog state and is responsible for all requests sent over the dialog it has established. B2BUA can generally be defined as a combination of UAC and UAS.

3GPP TS23.228 IP Multimedia Subsystem (IMS) RFC3261 6.Definitions (http://www.ietf.org/rfc/rfc3261.txt)

  However, there are many functions such as session handover and format absorption provided that a high-performance UA (User Agent) is not performed by the network. Therefore, it is inefficient to perform control uniformly over the network. Therefore, a technique is desired in which network-led control is performed only on UAs that require network-driven processing, and processing for UAs that do not require processing is reduced.

  In the prior art, B2BUA technology has been used to perform session handover, transmission of a control request from a network, absorption of differences between terminals, and the like. However, B2BUA is required to perform SIP control processing equivalent to that of UA, and a large amount of equipment is required when processing is performed for all terminals.

  On the other hand, there are many high-function UAs that have functions in the UA itself without performing network-led control. In the current method, it is possible to perform an efficient operation by providing a partially dedicated function in the UA, but it also depends on the operation of the UA.

  The present invention has been made in view of such circumstances, and by setting a SIP route via the Back to Back User Agent only to a UA that requires the Back to Back User Agent, the network equipment is provided. An object of the present invention is to provide a network control device, a Back to Back User Agent, a call control device, and a network control method that can reduce the load on the network.

  (1) In order to achieve the above object, the present invention takes the following measures. In other words, the network control apparatus of the present invention is a network control apparatus that controls the operation of a Back to Back User Agent that establishes a Session Initiation Protocol (SIP) session on an IMS (IP Multimedia Subsystem) network. When there is a SIP request from the IMS client to be connected, the IMS client that confirms whether the IMS client and the IMS client to which the SIP request is transmitted have a function required in the session to be established When the function confirmation unit and the IMS client do not have the function required in the session to be established, the SIP route is set via the Back to Back User Agent, while the IMS client Session to be established If a required function is characterized in that and a selective SIP route setting unit for setting the SIP route which does not pass through the Back to Back User Agent.

  As described above, when the IMS client does not have the function required in the session to be established, the IMS client sets the SIP route via the Back to Back User Agent, while the IMS client attempts to establish. If the session has the required function, the SIP route that does not go through the Back to Back User Agent is set, so only the UA (User Agent) that requires the Back to Back User Agent is set to Back. It is possible to set a SIP route via the to Back User Agent. As a result, since the UA that does not require the Back to Back User Agent does not go through the Back to Back User Agent, the processing amount in the Back to Back User Agent can be reduced. In addition, it is possible to establish a requested session without adding a function extension to the UA. Furthermore, since it can be implemented with the function of the existing Back to Back User Agent, it can be realized without changing the existing IMS system.

  (2) In addition, the network control device of the present invention further includes an IMS client function information holding unit that holds a confirmation result by the IMS client function confirmation unit, and the selective SIP route setting unit receives a new SIP request. In this case, the SIP route is set by using the stored confirmation result.

  As described above, when there is a new SIP request, the SIP route is set using the stored confirmation result, so that the function confirmation in the IMS client function confirmation unit can be omitted. As a result, it is possible to speed up the processing.

  (3) Further, the Back to Back User Agent of the present invention is characterized by including the network control device described in (1) or (2) above and a SIP proxy unit that exhibits a SIP proxy function.

  With this configuration, when the IMS client does not have the function required for the session to be established, the IMS client sets the SIP route via the Back to Back User Agent, while the IMS client attempts to establish If the session has the required function, the SIP route that does not go through the Back to Back User Agent is set, so only the UA (User Agent) that requires the Back to Back User Agent is set to Back. It is possible to set a SIP route via the to Back User Agent. As a result, since the UA that does not require the Back to Back User Agent does not go through the Back to Back User Agent, the processing amount in the Back to Back User Agent can be reduced. In addition, it is possible to establish a requested session without adding a function extension to the UA. Furthermore, since it can be implemented with the function of the existing Back to Back User Agent, it can be realized without changing the existing IMS system.

  (4) Moreover, the call control device of the present invention is characterized by including the network control device described in the above (1) or (2).

  With this configuration, when the IMS client does not have the function required for the session to be established, the IMS client sets the SIP route via the Back to Back User Agent, while the IMS client attempts to establish If the session has the required function, the SIP route that does not go through the Back to Back User Agent is set, so only the UA (User Agent) that requires the Back to Back User Agent is set to Back. It is possible to set a SIP route via the to Back User Agent. As a result, since the UA that does not require the Back to Back User Agent does not go through the Back to Back User Agent, the processing amount in the Back to Back User Agent can be reduced. In addition, it is possible to establish a requested session without adding a function extension to the UA. Furthermore, since it can be implemented with the function of the existing Back to Back User Agent, it can be realized without changing the existing IMS system.

  (5) The network control method of the present invention is a network control method for controlling the operation of a Back to Back User Agent that establishes a Session Initiation Protocol (SIP) session on an IMS (IP Multimedia Subsystem) network. In the client function confirmation unit, when there is a SIP request from an IMS client connected to the IMS network, the IMS client and the IMS client that is the destination of the SIP request are requested by the session to be established. And in the selective SIP route setting unit, if the IMS client does not have the function required in the session to be established, it passes through the Back to Back User Agent While setting the SIP route to be The IMS client, if it has the functions required in the session to be established, is characterized by comprising a step of setting the SIP route which does not pass through the Back to Back User Agent, at least.

  As described above, when the IMS client does not have the function required in the session to be established, the IMS client sets the SIP route via the Back to Back User Agent, while the IMS client attempts to establish. If the session has the required function, the SIP route that does not go through the Back to Back User Agent is set, so only the UA (User Agent) that requires the Back to Back User Agent is set to Back. It is possible to set a SIP route via the to Back User Agent. As a result, since the UA that does not require the Back to Back User Agent does not go through the Back to Back User Agent, the processing amount in the Back to Back User Agent can be reduced. In addition, it is possible to establish a requested session without adding a function extension to the UA. Furthermore, since it can be implemented with the function of the existing Back to Back User Agent, it can be realized without changing the existing IMS system.

  According to the present invention, when the IMS client does not have the function required in the session to be established, the SIP client sets the SIP route via the Back to Back User Agent, while the IMS client tries to establish it. If there is a function required for the session, the SIP route that does not go through the Back to Back User Agent is set, so only for the UA (User Agent) that requires the Back to Back User Agent The SIP route via the Back to Back User Agent can be set. As a result, since the UA that does not require the Back to Back User Agent does not go through the Back to Back User Agent, the processing amount in the Back to Back User Agent can be reduced. In addition, it is possible to establish a requested session without adding a function extension to the UA. Furthermore, since it can be implemented with the function of the existing Back to Back User Agent, it can be realized without changing the existing IMS system.

It is a figure which shows the network structure which concerns on this embodiment. It is a block diagram of the element which comprises a network. It is a figure which shows the form in which S-CSCF23 has "IMS client function confirmation function 21c, selective SIP route setting function 21d, and IMS client function information holding function 21e". In this embodiment, when an IMS client transmits and receives a SIP message, it is a sequence chart in the case of using both B2BUA after confirming both functions and judging use of B2BUA. In this embodiment, when IMS clients transmit and receive a SIP message, it is a sequence chart when both functions are confirmed and B2BUA is determined to be used, and B2BUA is not used. It is a sequence chart which shows the operation | movement which investigated the function of a client, using a normal SIP request as it is, and using result B2BUA. It is a sequence chart which shows the operation | movement which investigates the function of a client using a normal SIP request as it is, and does not use result B2BUA.

  In the present invention, when both IMS clients (SIP UA) communicate with each other, the function of the IMS client is confirmed, it is determined whether or not processing in B2BUA (Back to Back User Agent) is necessary, and B2BUA is efficiently performed. To reduce the amount of processing and traffic. For this purpose, the B2BUA is provided with an IMS client function confirmation function and a holding function, and a function that operates as a SIP proxy according to circumstances.

  FIG. 1 is a diagram illustrating a network configuration according to the present embodiment. This network includes IMS clients 1a to 1c, an access network 10, an IMS core network 20, a P-CSCF (Proxy Call Session Control Function) 22, an S-CSCF (Serving Call Session Control Function) / I-CSCF (Interrogating Call Session Control). Function) 23 and HSS (Home Subscriber Server) 24.

  As shown in FIG. 1, IMS clients 1 a to 1 c are connected to an IMS core network 20 via an access network 10 to establish a SIP session. Communication is performed between the high-function IMS clients 1a and 1b without going through the selective B2BUA 21 according to the present invention. On the other hand, if the necessary function is not provided, it passes through the selective B2BUA 21 to assist it.

  FIG. 2 is a block diagram of elements constituting the network. The IMS clients 1a to 1c, the P-CSCF 22, and the S-CSCF 23 adopt the same configuration as the conventional one. That is, the IMS clients 1a to 1c have an IMS client function 1d, and the P-CSCF 22 has a conventional function 22a. Further, the S-CSCF 23 has a conventional function 23a.

  The selective B2BUA 21 includes a conventional B2BUA function 21a, a SIP Proxy function 21b, an IMS client function confirmation function 21c, a selective SIP route setting function 21d, and an IMS client function information holding function 21e. .

  The IMS client function confirmation function 21c is a function for confirming whether an IMS client has a function for requesting a session to be established. A method using OPTIONS and a method included in a normal SIP message when OPTIONS cannot be used.

  Based on the function information of the IMS client confirmed above, the selective SIP route setting function 21d sets the SIP route for operating as a B2BUA, and sets the SIP route so that it operates as a SIP Proxy and does not pass through the B2BUA. This is a function to be performed.

  The IMS client function information holding function 21e is a function for holding the IMS client function confirmed by the IMS client function checking function.

  The network component configured as described above performs the following operation in order for the B2BUA to select an operation in accordance with the function of the IMS client.

  (A) Upon receipt of the SIP message, the selective B2BUA 21 checks the extension function requested by the selective B2BUA 21 and confirms whether or not it can cope with it.

  (B) If the selective B2BUA 21 is a function supported by itself, the selective B2BUA 21 confirms the function with the OPTIONS request to the partner IMS client.

  (C) If the OPTIONS request cannot be used, the function is confirmed by adding a confirmation function to the Request header in the normal SIP request.

  (D) Based on the confirmed IMS client function, the selective B2BUA designates the SIP route passing through itself and the SIP route omitting itself.

  The S-CSCF 23 can also have the “IMS client function confirmation function 21c, the selective SIP route setting function 21d, and the IMS client function information holding function 21e” that the selective B2BUA 21 has. FIG. 3 is a diagram showing a form in which the S-CSCF 23 has “IMS client function confirmation function 21c, selective SIP route setting function 21d, and IMS client function information holding function 21e”. In this case, the function confirmation and determination are performed by the S-CSCF, and the transfer to the conventional B2BUA 21 'is performed only when necessary.

  FIG. 4 and FIG. 5 are sequence charts for confirming the functions of both of the IMS clients and determining whether to use B2BUA when IMS clients transmit and receive SIP messages in this embodiment. FIG. 4 shows a sequence chart when using B2BUA.

  (1) The IMS client (A) transmits a SIP request to the IMS client (B). At this time, a necessary function is designated in the Request header. If it is not essential, the function supported by itself is specified in the Supported header. In this sequence, A is specified as a necessary function, but it may be left unspecified.

  (2) The SIP request is transferred from the S-CSCF to the selective B2BUA by iFC (initial Filter Criteria).

  (3) Selective B2BUA is set in order to absorb when the terminal does not have the function required by the IMS system. For example, a replace function is required for handover of a SIP session. If the function to be supported is not included in the supported header of the SIP request, the selective B2BUA records itself in the Record-Route so that it passes immediately and performs the B2BUA operation.

  (4) In this sequence chart, selective B2BUA supports function A. If A is supported in the Supported header of the SIP request, the function of the destination IMS client (B) is confirmed. This is confirmed by sending an OPTIONS request to the IMS client (B).

  (5) If the function A is not specified in the Supported header in the OPTIONS response message of the IMS client (B), the selective B2BUA sets Record-Route so as to pass through itself and performs the B2BUA process.

  (6) In the process of B2BUA, in order to support the function A, if A is specified in the Request header of the SIP request transmitted to the IMS client (B), it is excluded.

  (7) The subsequent communication between the IMS clients (A) and (B) is performed via the selective B2BUA. Further, the subsequent new SIP request can be operated by omitting the function confirmation based on the function of the held terminal.

  FIG. 5 shows a sequence chart when B2BUA is not used because both IMS clients have functions.

  (1) The IMS client (A) transmits the SIP request to the IMS client (B), and until the function is confirmed using OPTIONS, it is the same as the case where the B2BUA is used.

  (2) In the OPTIONS response of the IMS client (B), when the function A is specified in the Supported header, the processing in B2BUA is not necessary. Therefore, the selective B2BUA acts as a normal SIP proxy for SIP requests and does not add itself to Record-Route.

  (3) When the SIP request is transferred from the selective B2BUA to the IMS client (B), SIP messages are transmitted / received without going through the selective B2BUA. Further, the subsequent new SIP request can be operated by omitting the function confirmation based on the function of the held terminal.

  OPTIONS is an effective function for examining the function of the SIP client, but may not be used for security reasons. Therefore, next, an operation for examining the function of a client using a normal SIP request as it is will be described.

  FIG. 6 and FIG. 7 are sequence charts showing an operation for examining a client function using a normal SIP request as it is. FIG. 6 shows a sequence chart when using B2BUA.

  (1) The IMS client (A) transmits a SIP request to the IMS client (B). At this time, a required function is specified in the Request header, and if it is not essential, a function supported by itself is specified in the Supported header. In this sequence, nothing is specified in the Request header, but it may be specified.

  (2) The SIP request is transferred from the S-CSCF to the selective B2BUA by iFC (initial Filter Criteria).

  (3) The selective B2BUA confirms that its function A is supported from the received SIP request. If it is not supported, it records itself in the Record-Route so as to pass through itself, and performs the B2BUA operation.

  (4) When A, which is a selective B2BUA function, is supported in the Supported header of the SIP request, the function of the destination IMS client (B) is confirmed. For this purpose, the function A to be checked is designated in the Request header without being recorded in the Record-Route, and transmitted to the IMS client (B).

  (5) If the IMS client does not support the function A, 420 Bad Extension is returned for the SIP request. The B2BUA holds the function of the IMS client in response to the error, and responds to the IMS client (A) by specifying an error such as 503 Service Unavailable and a retry in the Retry-after header. In this case, the time of Retry-after may be as short as possible.

  (6) The IMS client (A) that has received the error transmits the SIP request again after the time specified by Retry-after.

  (7) Upon receiving the second SIP request, the selective B2BUA judges from the record that the IMS client (B) does not support the function A, and designates the Record-Route header to pass through itself. Then, the B2BUA process is performed.

  (8) In order to support the function A in the B2BUA process, if A is specified in the Request header from the SIP request transmitted to the IMS client (B), it is excluded.

  (9) Subsequent communications are performed via the selective B2BUA for both the IMS clients (A) and (B). Further, the subsequent new SIP request can be operated by omitting the function confirmation based on the function of the held terminal.

  FIG. 7 shows a sequence chart when B2BUA is not used because both IMS clients have functions.

  (1) The IMS client (A) transmits the SIP request to the IMS client (B) and performs the same function as when using the B2BUA until the function confirmation is performed using the Request header.

  (2) When 200 OK is returned in the response to the SIP request in which A is added to the Request header to the IMS client (B), it can be determined that the IMS client (B) supports the function A, and the selective B2BUA The message is transferred as it is to the IMS client (A). At this time, the selective B2BUA is not recorded in the Record-Route.

  (3) Thereafter, the SIP message is transmitted and received between the IMS clients without going through the selective B2BUA. Further, the subsequent new SIP request can be operated by omitting the function confirmation based on the function of the held terminal.

  As described above, according to the present embodiment, it is possible to reduce the processing amount in B2BUA. Further, selection based on the function of the SIP UA is possible without adding an extended function to the SIP UA. Furthermore, since it can be realized by the function of a single B2BUA, it is not necessary to change the existing IMS system.

1a to 1c IMS client 1d IMS client function 10 access network 20 IMS core network 21 selective B2BUA
21b SIP proxy function 21c IMS client function confirmation function 21d Selective SIP route setting function 21e IMS client function information holding function 22 P-CSCF
23 S / I-CSCF (S-CSCF / I-CSCF)

Claims (5)

A network control device that controls the setting of a SIP (Session Initiation Protocol) route on an IMS (IP Multimedia Subsystem) network,
When there is a SIP request from the first IMS client connected to the IMS network, the first IMS client and the second IMS client to which the SIP request is transmitted are requested in the session to be established. An IMS client function confirmation unit for confirming whether or not it has a function to
If at least one of the first IMS client or the second IMS client does not have the function required in the session to be established, the SIP route setting via the Back to Back User Agent is set. On the other hand, if both the first IMS client and the second IMS client have a function required in the session to be established, the SIP route that does not pass through the Back to Back User Agent And a selective SIP route setting unit for setting the network. An IMS client function information holding unit for holding a check result by the IMS client function check unit;
2. The network control device according to claim 1, wherein the selective SIP route setting unit sets a SIP route by using the held confirmation result when there is a new SIP request. . The network control device according to claim 1 or 2,
A Back to Back User Agent, comprising: a SIP proxy unit that exhibits a SIP proxy function.   A call control device comprising the network control device according to claim 1. A network control method for controlling setting of a SIP (Session Initiation Protocol) route on an IMS (IP Multimedia Subsystem) network,
In the IMS client function confirmation unit, when there is a SIP request from the first IMS client connected to the IMS network, the first IMS client and the second IMS client to which the SIP request is transmitted are established. Checking if the session being attempted has the required functionality;
In the selective SIP route setting unit, when at least one of the first IMS client and the second IMS client does not have a function required in the session to be established, the Back to Back User Agent When the SIP route passing through the network is set while the first IMS client and the second IMS client both have a function required for the session to be established, the Back to And a step of setting a SIP route that does not go through the Back User Agent.

Images