JP2017216584A - Inter-network control method for matching non-use of optional function of request destination terminal, sip server and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an inter-network control method for mutually matching an arbitrary optional function, even if it is used in a request source terminal but not used in a request destination terminal.SOLUTION: A SIP server placed between a multimedia network connected with a request source terminal, and a multimedia network connected with a request destination terminal is used. The SIP server registers a non-use option in such a case where the request destination terminal is non-use for the request source option of the request source terminal in the session, and executes a first step for transferring a request to the request destination terminal when it was received from the request source terminal, a second step of selecting a non-use option for the request source option of the request when an error response was received from the request destination terminal, and a third step of retransmitting the same request based on the selected non-use option to the request destination terminal.SELECTED DRAWING: Figure 2

Description

  The present invention relates to a technology for SIP (Session Initiation Protocol) / SDP (Session Description Protocol) control in IMS (IP Multimedia Subsystem).

  IMS provides IP (Internet Protocol) -based multimedia communication services and is defined as a 3GPP (3rd Generation Partnership Project) international standard (see, for example, Non-Patent Document 1). IMS is a core network that controls the transport of IP packets without depending on the access network. A plurality of access networks called IP-CAN (IP-Connectivity Access Network) are seamlessly accommodated. According to IMS, a common multimedia communication service (for example, IP phone, video phone, IM (Instant Message), etc.) can be provided via different access networks.

  The IMS mainly includes an application service control function (AS (Application Server) and a user information storage function (HSS (Home Subscriber Server))) as well as a session control function (CSCF (Call Session Control Function)). This is a function for controlling a session, which is the core of control network control, and realizes setting and releasing of a communication session between user terminals (UA (User Agent)), and CSCF is SIP (Session Initiation Protocol: session control). Messages are exchanged by SDP (Session Description Protocol), and the CSCF selectively uses the AS according to the service conditions of the connected session.

  As a service using IMS, for example, there is a voice telephone service. The voice telephone service has been provided mainly by a circuit switching system. However, a fixed telephone operator operates an IP telephone, and a mobile telephone operator operates VoLTE (Voice over LTE). When a mobile phone carrier or a fixed phone carrier provides a voice telephone service only by the IP system, it is necessary to interconnect the IP networks (IMS, NGN (Next Generation Network), etc.) of different communication carriers.

  Different IMSs can be connected via, for example, AS (Application Server) or IBCF (Interconnection Border Control Function). The AS mainly communicates with the S-CSCF, and the IBCF is mainly arranged between different carriers. The IBCF functions as transcoding for protocol conversion. Further, different IMS-AGWs (IP Multimedia Subsystem-Access Gateways) can be connected via, for example, TrGWs (Translation Gateways). These AS, IBCF, and TrGW can match the protocols according to the unique SIP parameters that differ from network to network and the media information of SDP, and can eliminate differences between networks as much as possible.

  For the IMS service, optional functions mounted on the core network side and the terminal side are also defined (see, for example, Non-Patent Document 2). Optional functions include, for example, a Direction attribute and a precondition attribute described in SIP / SDP. This is optimally selected according to the IMS service provided only within the network operated by each telecommunications carrier. In addition, there is a technique for performing control so that media clipping of early media in session establishment does not occur even if a session request destination terminal does not support precondition (see, for example, Patent Document 1).

JP, 2015-162827, A

3GPP TS 23.228 `` IP Multimedia Subsystem (IMS); Stage 2 '' 3GPP TS 24.229 `` IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 ''

  However, even if “option A used” is used in the network to which the request source terminal is connected, “option A is not used” may be used in the network to which the request destination terminal is connected. If there is a difference in optional functions between the request source terminal and the request destination terminal of the session, the session cannot be established, or even if it can be established, a timing problem may occur.

  Of course, the process of converting SIP / SDP can also be executed by AS (or IBCF / TrGW) interconnecting different multimedia networks. As a feature of SIP / SDP, it is expected that optional functions are matched between the request source terminal and the request destination terminal. However, while there are optional functions whose use is specified in the request and response, there are optional functions that are not specified.

  According to SIP, the state during session establishment from the start of transmission of a session start request (INVITE) to the final success response (200 OK) is defined as an “early dialog”. As media provided in the early dialog, for example, for PSTN (Public Switched Telephone Network), there is a ring tone that can be heard by the caller before call connection.

  Here, if the session establishment timing does not match between the request source terminal and the request destination terminal, the request source terminal also has a timing inconvenience that the media can be heard from the middle immediately after the resource reservation is completed. . This is a problem that the session request source terminal does not secure the resource (communication path) for flowing the media (resource not yet secured) and the media starts to flow from the request destination terminal.

  As a specific optional function, there is a precondition attribute included in the SDP. This is used to start playing the media after confirming that the request source terminal and the request destination terminal are in a resource secured state. Since the requesting terminal transmits a = inactive, since the resource is not secured, the request source terminal also transmits SIP / SDP that clearly indicates that the resource is not secured in the precondition. Then, at the timing when the resource can be secured, switching to SIP / SDP that clearly indicates that the resource has been secured by a = sendrecv and precondition. However, since it is an optional function, there is a possibility that the requested terminal does not use an optional function such as a = inactive or precondition.

  Moreover, there are an UPDATE method and a PRACK method with SDP as SIP methods used in the SIP / SDP that clearly indicates that resources have been secured. These are also optional functions, and none of them may be used at the request destination terminal. For example, even if the IBCF or TrGW has a SIP method conversion function, there is a possibility that an alternative SIP method does not exist depending on the use state of the optional function of the request destination terminal.

  Therefore, according to the present invention, an inter-network control method, a SIP server, and a program that can match each other even if optional functions are used in a request source terminal and not used in a request destination terminal The purpose is to provide.

According to the present invention, in the inter-network connection method in the SIP server arranged between the multimedia network to which the request source terminal is connected and the multimedia network to which the request destination terminal is connected,
SIP server
A non-use option is registered when the request destination terminal is not used for the request source option of the request source terminal in the session.
A first step of transferring the request to the request destination terminal when receiving the request from the request source terminal;
A second step of selecting an unused option for the request source option of the request when an error response is received from the request destination terminal;
A third step of transmitting the same request based on the selected non-use option to the request destination terminal again.

According to another embodiment of the network connection method of the present invention,
The request is a session start request (INVITE),
The requester option is a = inactive,
The unused option is also preferably a = sendrecv.

According to another embodiment of the network connection method of the present invention,
The request is a provisional response confirmation request (PRACK) with SDP (Session Description Protocol) with precondition,
The requester option is “With SDP”
It is also preferable that the non-use option is “no SDP”.

According to another embodiment of the network connection method of the present invention,
The request is a session change request (Re-INVITE),
The requester option is "No SDP"
It is also preferable that the non-use option is “with SDP”.

According to another embodiment of the network connection method of the present invention,
The request is a session start request (INVITE),
Requester options are "use precondition" and "use 100rel"
The non-use options are “precondition non-use” and “100rel non-use”.
For the second step, when the SIP server receives a successful response (200 OK) from the request destination terminal, the SIP server selects a non-use option for the request source option of the request,
It is also preferable to establish a session without performing the third step.

According to another embodiment of the network connection method of the present invention,
Regarding the second step, the SIP server also preferably transmits a confirmation request (ACK) for the error response to the request destination terminal.

According to another embodiment of the network connection method of the present invention,
SIP server
For the first step, when receiving a request from the request source terminal, obtain the request source option of the session update request (UPDATE),
Regarding the third step, it is also preferable to acquire a request destination option of a session update request (UPDATE) when a success response is received from the request destination terminal.

According to another embodiment of the network connection method of the present invention,
SIP server
AS (Application Server) or IBCF (Interconnection Border Control Function) connected between different CSCFs, or
TrGW (Translation Gateway) connected between different IMS-AGW (IP Multimedia Subsystem-Access Gateway),
The request source terminal is a request source UA (User Agent) or a network communication device,
The request destination terminal is also preferably a request destination UA or a network communication device.

According to the present invention, in the SIP server arranged between the multimedia network to which the request source terminal is connected and the multimedia network to which the request destination terminal is connected,
Option registration means for registering a non-use option when the request destination terminal is not used for the request source option of the request source terminal in the session;
When a request is received from the request source terminal, a request transfer means for transferring the request to the request destination terminal;
An option selection means for selecting an unused option for the request source option of the request when an error response is received from the request destination terminal;
Request re-transmission means for transmitting the same request based on the selected non-use option to the request destination terminal again.

According to the present invention, in a program for functioning a computer mounted on a SIP server arranged between a multimedia network to which a request source terminal is connected and a multimedia network to which a request destination terminal is connected,
Option registration means for registering a non-use option when the request destination terminal is not used for the request source option of the request source terminal in the session;
When a request is received from the request source terminal, a request transfer means for transferring the request to the request destination terminal;
An option selection means for selecting an unused option for the request source option of the request when an error response is received from the request destination terminal;
The computer is caused to function as a request retransmission unit that transmits the same request based on the selected non-use option again to the request destination terminal.

  According to the inter-network control method, SIP server, and program of the present invention, arbitrary optional functions can be matched to each other even if they are used at the request source terminal and not used at the request destination terminal. In particular, it is possible to match differences between optional functions that are not explicitly specified in the request or response, and that are not explicitly specified in the request or response.

It is a system configuration diagram in the present invention. It is a basic sequence diagram in the present invention. It is a sequence diagram based on the 1st Embodiment of this invention. FIG. 4 is a sequence diagram when a success response is returned instead of a failure response for the second step as compared to FIG. 3. It is a sequence diagram based on the 2nd Embodiment of this invention. It is a sequence diagram based on the 3rd Embodiment of this invention. It is a function block diagram of the application server in this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a system configuration diagram according to the present invention.

According to FIG. 1, the SIP server 1 is arranged between the multimedia network to which the request source terminal 21 is connected and the multimedia network to which the request destination terminal 22 is connected. SIP server 1 can be an AS or IBCF connected between different CSCFs, or
It may be a TrGW connected between different IMS-AGWs. In the following embodiment, a description will be given assuming that the SIP server arranged between different multimedia networks is an AS.

According to FIG. 1, a session request and response can be transferred between the request source terminal 21 and the request destination terminal 22 via the AS 1. For example, it is assumed that the request source terminals 21 and 22 have a use / non-use relationship for the function of option A as follows.
Requester terminal 21 = Option A function “use”
Requested terminal 22 = Option A function “not used”

  The request source terminal is not limited to the request source UA (User Agent), but may be a request source network communication device (for example, the request source AS or the request source IBCF). Further, the request destination terminal is not limited to the request destination UA, and may be a request destination network communication apparatus (for example, the request destination AS or the request destination IBCF). For example, the request source AS and the request destination AS may communicate with each other via an IBCF that is a SIP server for network connection.

  FIG. 2 is a basic sequence diagram in the present invention.

(S0) AS1 registers an unused option when the request destination terminal 22 is not used with respect to the request source option of the request source terminal 21 in the session.
(Requester option) <-> (Non-use option)
Option A <-> Option a

[First step]
(S 11) The request source terminal 21 transmits a “request” to the request destination terminal 22. The request includes a request source option indicating “use option A”.
(S12) The AS 1 that has received the request determines that the request source terminal 21 is “use option A”.
(S13) Then, AS1 transfers the request indicating “use of option A” to the request destination terminal 22 as it is.

[Second step]
(S21) On the other hand, the request destination terminal 22 sets “option A non-use”. Therefore, the request destination terminal 22 returns an error response to the AS 1.
(S22) The AS 1 that has received the error response recognizes that the request destination terminal 22 is “option A not used”. Then, the AS 1 selects the “option a” that is a non-use option for the option A for the request destination terminal 22.
(S23) Then, the AS 1 transmits a confirmation request for the error response to the request destination terminal 22.

[Third step]
(S31) Next, the AS 1 transmits the same request indicating “option a” to the request destination terminal 22 again.
(S32) It is assumed that the request destination terminal 22 does not use option A but can use option a. At this time, the request destination terminal 22 returns a success response based on the option a to the AS 1.
(S33) As a result, the AS 1 recognizes that the request destination terminal 22 can use the option a. That is, the AS 1 determines that the request destination terminal 22 is “not using option A”.
(S 34) The AS 1 then returns a success response to the request source terminal 21.

  According to S11 to S34, even if the optional function of the request destination terminal 22 is not specified, if an error response occurs in the request-response exchange, the optional function is matched as non-use. Can do. That is, even when the request destination terminal 22 does not use the request source option A, the AS 1 does not need to notify the request source terminal 21 of the fact. The AS 1 can immediately match the requested function with the requested terminal using the non-use option a.

  In addition, even if the sequence of the present invention is executed, the medium transmitted from one terminal in order to start communication after confirming the transition to the communicable state between the request source terminal and the request destination terminal. Will not be missing.

Examples of optional functions that should be matched at the request source terminal and the request destination terminal include the following.
Direction attribute
Precondition usage and resource allocation status
UPDATE signal
100rel
PRACK signal with SDP
Re-INVITE signal without SDP

The basic sequence in FIG. 2 is executed as, for example, the following three embodiments.
<First embodiment: Session start request based on media direction attribute>
<Second Embodiment: Session Start Request Based on SDP>
<Third Embodiment: Session Change Request Based on SDP>

<First embodiment: Session start request based on media direction attribute>
FIG. 3 is a sequence diagram based on the first embodiment of the present invention.

According to FIG. 3, the request is a session start request (INVITE).
Further, it is assumed that the request source terminal 21 and the request destination terminal 22 use the following optional functions.
(Request source terminal 21) a = inactive use, UPDATE use (Request destination terminal 22) a = inactive non-use (a = sendrecv use), UPDATE non-use

“A =” is included in the media description part and is a Direction attribute representing the directionality of the media. The Direction attribute is used to determine whether or not each terminal can play media to the partner terminal. That is, it does not clearly indicate whether or not Direction is used. The parameters include “sendrecv” (both directions), “sendonly” (transmission only), “recvonly” (reception only), and “inactive” (no transmission / reception).
If the “a =” attribute is omitted, the process is executed assuming that “a = sendrecv” is set.

In response to an SDP Offer request including a = sendrecv, anything can be returned to SDP Answer.
On the other hand, there is a condition that only an SDP Answer with a = inactive must be returned for an SDP Offer request including a = inactive.
Therefore, when the request source terminal 21 transmits a request in which a = inactive is described in the SDP, the request destination terminal 22 needs to return a = inactive.
However, at this time, there is a possibility that the requested terminal 22 is not using a = inactive.

In this case, the AS 1 converts a = inactive of SDP Offer from the request source terminal 21 to the request destination terminal 22 to a = sendrecv, and a = sendrecv of SDP Answer from the request destination terminal 22 to the request source terminal 21 is a. It can also be converted to = inactive.
However, since the request source terminal 21 is a = inactive while the request destination terminal 22 is a = sendrecv, when the request destination terminal 22 immediately plays media, the request source terminal 21 plays the media. Can not do it.

  According to the first embodiment of FIG. 3, the following sequence is specifically executed based on the basic sequence shown in FIG.

(S0) Assume that AS1 registers non-use options for use options in the following list (non-use selection option function list).
(Option A) <-> (Non-use option a)
a = inactive <-> a = sendrecv
This means that “a = sendrecv” matches the request destination terminal 22 of “a = inactive not used”.

  This list may be set in advance by the system operator. Moreover, it is preferable to set a higher priority for an option function that is used less frequently. This list also includes precondition, 100rel, UPDATE, etc.

(S11) The request source terminal 21 transmits a session start request (SIP: INVITE) using the URI (Uniform Resource Indicator) of the request destination terminal 22 as destination information. Here, the request source terminal 21 puts the SIP / SDP parameters in accordance with the use state of its optional function (a = inactive use, precondition use (resource unsecured), UPDATE use, 100rel use).
[SIP: INVITE]
-SIP header
Supported: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local none
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos optional remote sendrecv
a = inactive

(S12) The AS 1 stores optional functions that can be used by the request source terminal 21 based on the SIP / SDP parameters included in the session start request.
Here, when the request source terminal 21 is a UA, a SIP URI or a tel URI included in the User-Agent header, the P-Asserted-Identity header, or the From header may be used to identify the terminal type. Further, when the request source terminal 21 is a network communication device, the domain part of the SIP URI included in the i-i parameter of the P-Charging-Vector header or the P-Asserted-Identity header or the From header is used to specify the network type. May be used.
When the request destination terminal has already recognized “a = inactive non-use”, S13 to S23 may be omitted and the process may proceed to S31.

(S13) The AS1 transfers the received session start request to the request destination terminal 22 as it is.

(S21) The request destination terminal 22 knows “a = inactive use” from the received session start request. Here, since the request destination terminal 22 is “a = inactive not used”, the request destination terminal 22 returns a failure response (SIP: 488 (INVITE)) to the AS 1.

(S22) When AS1 receives the failure response, AS1 selects “a = sendrecv” as a non-use option for a = inactive for the request destination terminal 22.

(S23) Then, the AS 1 transmits a confirmation request (SIP: ACK) for the failure response to the request destination terminal 22. As a result, the AS 1 notifies the request destination terminal 22 of acceptance of the failure response.

(S31) Next, the AS 1 transmits a session start request (SIP: INVITE) in which a = inactive is converted to a = sendrecv to the request destination terminal 22.
[SIP: INVITE]
-SIP header
Supported: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local none
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos optional remote sendrecv
a = sendrecv

(S32) The requested terminal 22 responds to the received session start request based on the use state of its optional function (precondition not used, UPDATE not used, 100 rel used) (SIP: 183 (INVITE) )
[SIP: 183 (INVITE)]
-SIP header
Require: 100rel
Allow: INVITE, ACK, CANCEL, BYE, PRACK
-SDP
a = sendrecv
Then, the request destination terminal 22 shifts to a resource securing completion state.

(S33) AS1 stores the use status of the optional function of request destination terminal 22.
Here, when the request destination terminal 22 is a UA, a SIP URI or a tel URI included in a User-Agent header, a P-Asserted-Identity header, or a To header may be used to identify the terminal type. Further, when the requested terminal 22 is a network communication device, in order to specify the network type, the domain part of the SIP URI included in the i-i parameter of the P-Charging-Vector header, the P-Asserted-Identity header or the To header is used. It may be used.

The AS 1 determines that the failure response has been eliminated by converting a = inactive to a = sendrecv.
Then, the AS 1 determines that the request destination terminal 22 is “a = inactive not used”. If an error response is returned even if a = inactive is converted to a = sendrecv, it is considered that there is a difference in another optional function. In that case, the process returns to S12 to try conversion of another optional function.

(S 34) The AS 1 transmits a provisional response (SIP: 183 (INVITE)) to the request source terminal 21.
[SIP: 183 (INVITE)]
-SIP header
Require: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local none
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = conf: qos remote sendrecv
a = inactive

(S35) In response to the received provisional response, the request source terminal 21 transmits a provisional response confirmation request (SIP: PRACK) to the AS1. The AS 1 transfers the provisional response confirmation request to the request destination terminal 22 as it is.

(S36) In response to the received provisional response confirmation request, the request destination terminal 22 returns a provisional response confirmation success response (SIP: 200 (PRACK)) to the AS1. The AS 1 transfers the temporary response confirmation success response to the request source terminal 21 as it is.

(S37) The request source terminal 21 transmits an update request (SIP: UPDATE) to the AS 1 after the resource reservation is completed.
[SIP: UPDATE]
-SIP header
Require: precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local sendrecv
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = sendrecv

(S38) AS1 returns an update success response (SIP: 200 (UPDATE)) to the request source terminal 21 without transferring the received update request to the request destination terminal 22. Since the request destination terminal 22 is “UPDATE not used”, the AS 1 terminates the UPDATE signal received from the request source terminal 21 and does not transfer the UPDATE signal to the request destination terminal 22.
[SIP: 200 (UPDATE)]
-SIP header
Require: precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local sendrecv
a = curr: qos remote sendrecv
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = sendrecv

  Note that the UPDATE option function acquires a request source option of a session update request (UPDATE) when a session start request is received from the request source terminal 21 in S11. In S32, when a provisional response (success response) is received from the request destination terminal 22, the request destination option of the session update request (UPDATE) is acquired.

  By converting the optional function for the request destination terminal 22 to a = sendrecv according to the sequence of FIG. 3, media can be immediately flowed between the terminals when the resource reservation at the request source terminal 21 is completed.

  FIG. 4 is a sequence diagram when a success response is returned instead of a failure response for the second step as compared to FIG.

According to FIG. 4, it is assumed that the use states of the optional functions of the request source terminal and the request destination terminal are set as follows.
Requester terminal-Use a = inactive-Use precondition and resource not secured-Use UPDATE-Use 100rel Request destination-Use a = inactive-Do not use precondition-Use UPDATE-Do not use 100rel

  FIG. 4A is a sequence diagram executed when the optional function of the request destination terminal is not recognized.

  The precondition in SIP is to exchange the parameters of the resource reservation state between the request source terminal and the request destination terminal using the SDP. Thus, even if resources are not secured when transmitting a session start request between terminals, it is possible to confirm completion of resource securing of the other party.

(S0) Assume that AS1 registers non-use options for use options in the following list (non-use selection option function list).
(Option A) <-> (Non-use option a)
Use precondition <-> Do not use precondition
100rel used <-> 100rel not used This list may be preset by the system operator.

(S11) The request source terminal 21 transmits a session start request (SIP: INVITE) using the URI of the request destination terminal 22 as destination information. The session start request is transferred to the AS 1 via the request source CSCF group. Here, the request source terminal 21 puts the SIP / SDP parameters in accordance with the use state of its optional function (a = inactive use, precondition use (resource unsecured), 100rel use).
[SIP: INVITE]
-SIP header
Supported: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local none
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos optional remote sendrecv
a = inactive

(S12) The AS 1 stores the use status of the optional function of the request source terminal 21 from the received session start request. AS1 can be executed from S11 of FIG. 4B without executing S13 and subsequent steps of FIG. 4A when it is previously stored that the requested terminal 22 is not using 100rel.
In addition, the AS 1 determines the following operation according to the use state of the optional function of the request source terminal 21.
-The precondition process is executed so that the request source terminal 21 is in the resource secured state.
-A session start request (INVITE) is not transmitted to the request destination terminal 22 until the request source terminal 21 is in a resource secured state.
-SDP negotiation with the request source terminal 21 and SDP negotiation with the request destination terminal 22 are managed independently.

(S13) Then, the AS 1 transfers the received session start request (INVITE) to the request destination terminal 22.

(S21) When the precondition is not used and the 100rel is not used, the request destination terminal 22 returns a success response (SIP: 200 (INVITE)) to the AS1. The parameters of the success response are as follows, for example.
[SIP: 200 (INVITE)]
SIP header
Allow: INVITE, ACK, CANCEL, BYE, UPDATE
SDP
a = inactive
The AS 1 transfers the received successful response as it is to the request source terminal 21.

(S22) When the AS1 receives the success response including the SDP, the AS1 stores the optional functions “precondition non-use” and “100rel non-use” (non-use option for the request source option) of the request destination terminal 22. However, 100rel non-use includes a case where 100rel is not used and a case where 100rel is used but is not used in the control signal.

(S23) The request source terminal 21 transmits a confirmation request (SIP: ACK) to the AS 1 assuming that a session has been established.
The AS 1 transfers the received confirmation request to the request destination terminal 22 as it is.

  Here, the request source terminal 21 cannot communicate because it is in the “resource unallocated state and a = inactive state”. Although not shown in FIG. 4, the request source terminal 21 needs to send an update request (SIP: Re-INVITE) including a = sendrecv to the request destination terminal at the timing when the resource reservation is completed, so that the session can be communicated. There is. Until this process is completed, the request source terminal 21 and the request destination terminal 22 cannot communicate with each other.

(S3) Therefore, the AS 1 once executes a disconnection sequence for the request source terminal 21 and the request destination terminal 22 to disconnect the session.

  FIG. 4B is a sequence diagram executed when the optional function of the request destination terminal is already recognized.

(S11) The request source terminal 21 transmits a new session start request (INVITE) to the same request destination terminal 22 again.

(S12) The AS 1 has already recognized the optional functions “no SDP” and “100rel not used” of the request destination terminal 22. Therefore, the AS 1 returns a provisional response (SIP: 183 (INVITE)) for executing precondition processing with the request source terminal 21 to the request source terminal 21.
SIP header
Require: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
SDP
a = curr: qos local none
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = conf: qos remote sendrecv
a = inactive

(S13) When receiving the provisional response (183), the request source terminal 21 transmits a provisional response confirmation request (SIP: PRACK) to the AS1.

(S14) When the AS1 receives the provisional response confirmation request (SIP: PRACK), the AS1 returns a provisional response confirmation success response (SIP: 200 (PRACK)) to the request source terminal 21.

(S15) When the resource reservation is completed, the request source terminal 21 transmits an update request (SIP: UPDATE) notifying that to the AS1.
[SIP: UPDATE]
-SIP header
Require: precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local sendrecv
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = sendrecv

(S16) The AS1 returns an update success response (SIP: 200 (UPDATE)) to the request source terminal 21 without transferring the received update request (UPDATE) to the request destination terminal 22.
[SIP: 200 (UPDATE)]
-SIP header
Require: precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local sendrecv
a = curr: qos remote sendrecv
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = sendrecv

(S17) Then, the AS1 transmits a session start request (SIP: INVITE) to the request destination terminal 22 when the precondition process is completed and the resource securing of the request source terminal 21 is completed.
[SIP: INVITE]
-SIP header
Supported: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local sendrecv
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos optional remote sendrecv
a = sendrecv

(S21) The request destination terminal 22 returns a success response (SIP: 200 (INVITE)) to the AS 1 because “precondition is not used and 100rel is not used”.
[SIP: 200 (INVITE)]
-SIP header
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = sendrecv

(S22) The AS 1 stores the use status of the optional function of the requested terminal 22 from the received successful response (SIP: 200 (INVITE)).
When S13 to S23 of FIG. 4A are executed, the AS 1 avoids the precondition procedure and the 100rel procedure for the request destination terminal 22, and the failure response is eliminated. It is determined that “precondition is not used and 100rel is not used”.
Then, the AS 1 deletes the SDP from the received successful response (SIP: 200 (INVITE)) and transmits it to the request source terminal 21.

(S23) The request source terminal 21 recognizes that the session has been successfully established when it receives a successful response without SDP (SIP: 200 (INVITE)). Then, the request source terminal 21 transmits a confirmation request (SIP: ACK) to the AS 1.
The AS 1 transfers the received confirmation request (SIP: ACK) to the request destination terminal 22 as it is.

  According to FIG. 4, as described above, the request source terminal 21 executes the precondition establishment and enters the resource secured state. Further, as soon as a session is established between the request source terminal 21 and the request destination terminal 22, media can be flowed between the terminals.

<Second Embodiment: Session Start Request Based on SDP>
FIG. 5 is a sequence diagram based on the second embodiment of the present invention.

According to FIG. 5, it is assumed that the use states of the optional functions of the request source terminal and the request destination terminal are as follows.
Requester terminal
Use a = inactive
Precondition used and resource not secured
Use of PRACK with SDP Requested terminal
a = inactive not used
precondition not used
With SDP PRACK not used

(S0) Assume that AS1 registers non-use options for use options in the following list (non-use selection option function list).
(Option A) <-> (Non-use option a)
With SDP <-> Without SDP

  According to FIG. 5, a session start request (SIP: INVITE) is transmitted from the request source terminal 21 to the request destination terminal 22, and a provisional response (183 (INVITE)) is normally returned. Thereafter, the provisional response confirmation request (SIP: PRACK) sequence to which the basic sequence of FIG.

(S11) When the resource reservation is completed, the request source terminal 21 transmits a provisional response confirmation request (SIP: PRACK) notifying that to the AS1.
[SIP: PRACK]
-SIP header
Require: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local sendrecv
a = curr: qos remote none
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = sendrecv
(S12) The AS1 stores the use state of the optional function of the request source terminal 21 (with SDP and PRACK use).
(S13) The AS1 transfers the received provisional response confirmation request (SIP: PRACK) to the request destination terminal 22.

(S21) In response to the provisional response confirmation request (SIP: PRACK), the request destination terminal 22 returns a provisional response confirmation failure response (SIP: 488 (PRACK)) to the AS1 when the SDP is not used.
(S22) When AS1 receives the provisional response confirmation failure response, AS1 selects “PRACK without SDP” as an optional function of the request destination terminal 22. Note that the failure response may be limited to a specific error type (identified by the SIP Status Code), or all error types may be targeted.

(S31) The AS1 transmits a provisional response confirmation request (PRP without SDP) to the request destination terminal 22.
(S32) The request destination terminal 22 returns a provisional response confirmation success response (SIP: 200 (PRACK)) to the AS1.
(S33) The AS1 stores the use state of the optional function of the request destination terminal 22 by the provisional response confirmation success response (SIP: 200 (PRACK)). Here, the AS 1 stores the PRACK with SDP as non-use for the request destination terminal 22.
(S 34) Then, AS 1 transmits a provisional response confirmation success response (SIP: 200 (PRACK)) including SDP Answer to SDP Offer to request source terminal 21.
[SIP: 200 (PRACK)]
-SIP header
Require: 100rel, precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
-SDP
a = curr: qos local sendrecv
a = curr: qos remote sendrecv
a = des: qos mandatory local sendrecv
a = des: qos mandatory remote sendrecv
a = sendrecv

<Third Embodiment: Session Change Request Based on SDP>
FIG. 6 is a sequence diagram based on the third embodiment of the present invention.

According to FIG. 6, it is assumed that the use state of the optional function at the request source terminal and the request destination terminal is set as follows.
Requesting terminal: Use of Re-INVITE without SDP Requesting terminal: Non-use of Re-INVITE without SDP (with SDP)

(S11) The request source terminal 21 transmits a session change request (SIP: Re-INVITE) to the session in communication with the request destination terminal 22. This session change request is transferred to the AS 1 through the requesting CSCF group. Here, the session change request is “no SDP”.
(S12) The AS 1 stores “use of Re-INVITE without SDP” as the use state of the optional function of the request source terminal.
Here, when the optional function of the request destination terminal 22 is set in advance to “non-SDP Re-INVITE non-use”, S13 to S23 are omitted, and the process proceeds to S24. And AS1 determines to perform the following operation | movement.
-Complete the processing of the session change request without SDP with the request source terminal 21.
A session change request to the request destination terminal 22 is executed if there is information to be transferred to the request destination terminal 22 as a result of processing with the request source terminal 21.
(S13) AS1 transfers the session change request (no SDP) to request destination terminal 22.

(S21) The request destination terminal 22 returns a session change failure response (SIP: 400 (Re-INVITE)) in response to the session change request because the optional function with SDP is in use.
(S22) When the AS 1 receives the session update failure response, the AS 1 selects that the optional function “Re-INVITE without SDP” of the request destination terminal 22 is not used. Note that the failure response may be limited to a specific error type (identified by the SIP Status Code), or all error types may be targeted.
(S23) The AS1 returns a confirmation request (SIP: ACK) to the request destination terminal 22.
(S24) Then, AS1 transmits a session change success response with SDP (SIP: 200 (Re-INVITE)) to requesting terminal 21. The SDP included here is the session before transitioning to the communicating state. This is an establishment procedure, and includes all the optional functions that can be used by the request destination terminal 22 recognized by the AS 1.
(S25) Upon receiving a session change success response with SDP, the request source terminal 21 transmits a confirmation request with SDP (SIP: ACK).

(S31) AS1 transmits a session change request (SIP: Re-INVITE) with SDP of request source terminal 21 to request destination terminal 22.
(S32) When receiving the session change request, the request destination terminal 22 returns a session change success response with SDP (SIP: 200 (Re-INVITE)) to the AS1.
(S33) AS1 stores the use status of the optional function of request destination terminal 22. Here, the AS 1 stores “No SDP Re-INVITE Not Used” (SDP present) for the requested terminal 22.
(S 34) The AS 1 transmits a confirmation request (SIP: ACK) to the request destination terminal 22.

  FIG. 7 is a functional configuration diagram of the application server in the present invention.

As shown in FIG. 7, the application server 1 includes an option registration unit 10, a request transfer unit 11, an option selection unit 12, a request retransmission unit 13, and a media transfer unit 14. These functional components are realized by executing a program for causing a computer mounted on a SIP server arranged between multimedia networks to function.
The option registration unit 10 registers a non-use option when the request destination terminal is not used for the request source option of the request source terminal in the session (see S0 described above).
When the request transfer unit 11 receives a request from the request source terminal 21, the request transfer unit 11 transfers the request to the request destination terminal 22 (see S1 described above).
When receiving an error response from the request destination terminal 22, the option selection unit 12 selects a non-use option for the request source option of the request (see S2 described above).
The request retransmission unit 13 transmits the same request based on the selected non-use option again to the request destination terminal 22 (see S3 described above).
The media transfer unit 14 relays and transfers media between the request source terminal 21 and the request destination terminal 22.

  As described above in detail, according to the inter-network control method, SIP server, and program of the present invention, any optional function can be used at the requesting terminal and not used at the requesting terminal. , Can match each other. In particular, it is possible to match differences between optional functions that are not explicitly specified in the request or response, and that are not explicitly specified in the request or response.

  As a result, it is possible to avoid problems based on the mismatch of optional functions based on the session and to improve the interoperability. Specifically, a mobile operator can improve the interoperability between a terminal (for example, a SIM free terminal) that is not optimized for the company network service and the company network service.

  Further, according to the present invention, a communication carrier need only install an application server (or IBCF) in the IMS without mounting a special function in the terminal. Therefore, it is not necessary for the request source terminal and the request destination terminal of the session to recognize “use / non-use” of the optional function. That is, it is not necessary to change the existing sequence via the IMS as viewed from the terminal. It can also be used for general purposes for IMS and IP networks operated by different operators.

  Various changes, modifications, and omissions of the above-described various embodiments of the present invention can be easily made by those skilled in the art. The above description is merely an example, and is not intended to be restrictive. The invention is limited only as defined in the following claims and the equivalents thereto.

1 AS, IBCF, TrGW
DESCRIPTION OF SYMBOLS 10 Option registration part 11 Request transfer part 12 Option selection part 13 Request re-transmission part 14 Media transfer part 21 Request origin terminal 22 Request destination terminal

Claims (10)

In the inter-network connection method in the SIP server arranged between the multimedia network to which the request source terminal is connected and the multimedia network to which the request destination terminal is connected,
SIP server
A non-use option is registered when the request destination terminal is not used for the request source option of the request source terminal in the session.
A first step of transferring the request to the request destination terminal when receiving the request from the request source terminal;
A second step of selecting a non-use option for the request source option of the request when an error response is received from the request destination terminal;
And a third step of transmitting the same request based on the selected non-use option to the request destination terminal again. The request is a session start request (INVITE),
The requester option is a = inactive,
The inter-network connection method according to claim 1, wherein the non-use option is a = sendrecv. The request is a provisional response confirmation request (PRACK) with SDP (Session Description Protocol) with precondition,
The request source option is “with SDP”,
The inter-network connection method according to claim 1, wherein the non-use option is "no SDP". The request is a session change request (Re-INVITE),
The requester option is “no SDP”,
2. The inter-network connection method according to claim 1, wherein the non-use option is “with SDP”. The request is a session start request (INVITE),
The requester options are “use preconditon” and “use 100rel”,
The non-use options are “preconditon non-use” and “100rel non-use”,
Regarding the second step, when the SIP server receives a success response (200 OK) from the request destination terminal, the SIP server selects a non-use option for the request source option of the request,
The network connection method according to claim 1, wherein a session is established without executing the third step. 5. The network connection according to claim 1, wherein, in the second step, the SIP server transmits an acknowledgment request (ACK) for the error response to the request destination terminal. 6. Method. The SIP server
For the first step, when receiving a request from the request source terminal, obtain the request source option of the session update request (UPDATE),
The network according to any one of claims 1 to 6, wherein a request destination option of a session update request (UPDATE) is acquired when a success response is received from the request destination terminal in the third step. Connection method. The SIP server
AS (Application Server) or IBCF (Interconnection Border Control Function) connected between different CSCFs, or
TrGW (Translation Gateway) connected between different IMS-AGW (IP Multimedia Subsystem-Access Gateway),
The request source terminal is a request source UA (User Agent) or a network communication device,
8. The network connection method according to claim 1, wherein the requested terminal is a requested UA or a network communication device. In the SIP server arranged between the multimedia network to which the request source terminal is connected and the multimedia network to which the request destination terminal is connected,
Option registration means for registering a non-use option when the request destination terminal is not used for the request source option of the request source terminal in the session;
When a request is received from the request source terminal, a request transfer means for transferring the request to the request destination terminal;
Option receiving means for selecting a non-use option for the request source option of the request when an error response is received from the request destination terminal;
A SIP server, comprising: a request retransmission unit that transmits the same request based on the selected non-use option to the request destination terminal again. In a program for functioning a computer mounted on a SIP server arranged between a multimedia network to which a request source terminal is connected and a multimedia network to which a request destination terminal is connected,
Option registration means for registering a non-use option when the request destination terminal is not used for the request source option of the request source terminal in the session;
When a request is received from the request source terminal, a request transfer means for transferring the request to the request destination terminal;
Option receiving means for selecting a non-use option for the request source option of the request when an error response is received from the request destination terminal;
A program that causes a computer to function as a request retransmission unit that transmits the same request based on the selected non-use option to a request destination terminal again.