JP6549526B2 - Inter-network control method for matching dialog based on forking, SIP server and program - Google Patents

Description

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

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

  The IMS mainly includes a session control function (CSCF (Call Session Control Function)), an application service control function (AS (Application Server) and a user information storage function (HSS (Home Subscriber Server)). It is a function to control the session that is the core of control of control network, and realizes setting up and release of communication session between user terminals (UA (User Agent)), and CSCF is SIP (Session Initiation Protocol: session control). The messages are exchanged by the protocol (SDP) or 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 mainly provided by the circuit switching system, but fixed telephone carriers operate IP telephones, and mobile telephone carriers operate VoLTE (Voice over LTE). In the case where a mobile phone carrier or a fixed phone carrier provides voice telephone service only by the IP system, it is necessary to mutually connect IP networks (such as IMS and NGN (Next Generation Network)) of different carriers.

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

  For IMS services, optional functions installed on each of the core network side and the terminal side are also defined (see, for example, non-patent publication 2). Optional functions are described in SIP / SDP, for example, have multiple dialog attributes. The "dialog" is component information indicating the end-to-end relationship of a session between the request source terminal and the request destination terminal. This is optimally selected according to the IMS service provided only in the network operated by each carrier. For IMS services called CAT (Customized Alerting Tones) and CDiv (Communication Diversion), it is possible to select an option that generates a plurality of dialogs (see, for example, non-patent documents 3 and 4).

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" 3GPP TS 24.182 "IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT); Protocol specification" 3GPP TS 24.604 "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification"

  According to SIP, there is a method called forking in which a proxy server generates and transmits a plurality of requests from one request. For example, by making the fixed telephone and the mobile telephone having the same telephone number the same priority, it is possible to ring both ringing when an incoming call is received. Then, it is possible to specify only the terminal off hooked by the user as the request destination terminal. Note that forking helps to improve mobility for mobile terminals and redundancy for networks.

  However, depending on the network to which the request source terminal is connected, the optional function may be "multiple dialog not used". In this case, the request source terminal can not be used even if a plurality of responses are sent in response to transmission of one request, and a session can not be established, or even if it can be established, a timing defect May occur.

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

  Therefore, according to the present invention, an inter-network control method, SIP server and network control method capable of matching the dialogs of a plurality of request destination terminals based on forking even if the request source terminal is an optional function “multiple dialog not used”. The purpose is to provide a program.

According to the present invention, there is provided an inter-network connection method of a SIP (Session Initiation Protocol) server disposed between a multimedia network to which a request source terminal is connected and a multimedia network to which a request destination terminal is connected,
SIP server is
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 transmitting a response based on the dialog for the first request destination terminal to the request source terminal when receiving the response from the first request destination terminal;
When the response is received from the second request destination terminal, the optional function “multiple dialog not used” of the request source terminal in the session, and the dialog for the first request destination terminal and the second request destination terminal And a third step of not transmitting the response to the request source terminal if the predetermined element is the same in comparison with the dialog.
And a fourth step of executing a sequence with the request source terminal as the dialog for the second request destination terminal as the dialog for the first request destination terminal.

According to another embodiment of the inter-network connection method of the present invention,
The predetermined element may be an element predefined in any of the response code, the header field, and the type of SDP (Session Description Protocol) included in the body.

According to another embodiment of the inter-network connection method of the present invention,
The first step request is a session start request,
The response of the second step is also preferably a provisional response.

According to another embodiment of the inter-network connection method of the present invention,
The first step request is a session start request,
The response of the second step is also preferably a ringing response.

According to another embodiment of the inter-network connection method of the present invention,
For the third step, the SIP server
When the dialog for the first request destination terminal and the dialog for the second request destination terminal are compared and the predetermined element is different, the dialog for the second request destination terminal is the dialog for the first request destination terminal It is also preferable to transmit the message (request or response) to the request source terminal.

According to another embodiment of the inter-network connection method of the present invention,
The first step request is a session start request,
The response of the second step is a provisional response,
The response of the third step is a provisional response,
It is also preferred that the message of the third step is an update request.

According to another embodiment of the inter-network connection method of the present invention,
For the third step, the SIP server
After receiving the provisional response from the request destination terminal, transmit a provisional response confirmation request to the second request destination terminal,
Thereafter, when a session start response is received from the second request destination terminal, it is also preferable to transmit an update request to the request source terminal.

According to another embodiment of the inter-network connection method of the present invention,
For the third step, the SIP server
When a session start response including the first dialog is received from the first request destination terminal and a session start response including the second dialog is received from the second request destination terminal, predetermined elements of both dialogs are different. It is also preferable to send the update request to the requesting terminal only if it is the case.

According to another embodiment of the inter-network connection method of the present invention,
For the third step, the SIP server
It is also preferable to send a session start response to the request source terminal after sending the update request to the request source terminal and receiving the update response from the request source terminal.

According to another embodiment of the inter-network connection method of the present invention,
The predetermined element is registered as a transfer required header,
The first step request is a session start request,
The response of the second step is a provisional response,
The response of the third step is a provisional response that includes a transfer required header,
It is also preferred that the message of the third step is a provisional response including a transfer required header.

According to another embodiment of the inter-network connection method of the present invention,

For the first step, it is also preferred that the request is forked to a plurality of request destination terminals in the multimedia network to which the request destination terminals are connected.

According to another embodiment of the inter-network connection method of the present invention,
SIP server is
Regarding the third step, in order to determine whether or not the optional function “multiple dialog not used” of the request source terminal in the session,
The response received from the second request destination terminal is transmitted as it is to the request source terminal as a response based on the dialog for the second request destination terminal,
It is also preferable to execute such that when the failure sequence is executed with the request source terminal, it is determined that the optional function “multiple dialog not used” of the request source terminal in the session.

According to another embodiment of the inter-network connection method of the present invention,
SIP server is
In the first step, upon receiving a request from a request source terminal, obtain a request source option of a session update request (UPDATE),
In the third step, if the request source option of the request source terminal is “session update request not used” and “multiple dialog not used”, a disconnection sequence is executed,
It is also preferable to execute the first step to the third step again after storing "a plurality of dialogs not used" of the request source terminal.

According to another embodiment of the inter-network connection method of the present invention,
SIP server is
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,
It is also preferable that the request destination terminal is a UA or network communication device of the request destination.

According to the present invention, in the SIP server disposed between the multimedia network to which the request source terminal is connected and the multimedia network to which the request destination terminal is connected,
Request transfer means for transferring the request to the request destination terminal when receiving the request from the request source terminal;
Response transmission means for transmitting a response based on the dialog for the first request destination terminal to the request source terminal when receiving the response from the first request destination terminal;
When the response is received from the second request destination terminal, the optional function “multiple dialog not used” of the request source terminal in the session, and the dialog for the first request destination terminal and the second request destination terminal Dialog determination means which does not send the response to the request source terminal if the predetermined element is the same in comparison with the dialog;
A dialog for the second request destination terminal is used as a dialog for the first request destination terminal, and dialog exchange means for executing a sequence with the request source terminal.

According to the present invention, in a program that causes a computer installed in a SIP server disposed between a multimedia network to which a request source terminal is connected and a multimedia network to which a request destination terminal is connected,
Request transfer means for transferring the request to the request destination terminal when receiving the request from the request source terminal;
Response transmission means for transmitting a response based on the dialog for the first request destination terminal to the request source terminal when receiving the response from the first request destination terminal;
When the response is received from the second request destination terminal, the optional function “multiple dialog not used” of the request source terminal in the session, and the dialog for the first request destination terminal and the second request destination terminal Dialog determination means which does not send the response to the request source terminal if the predetermined element is the same in comparison with the dialog;
A dialog for the second request destination terminal is used as a dialog for the first request destination terminal, and the computer is made to function as a dialog exchange means for executing a sequence with the request source terminal.

  According to the inter-network control method, SIP server and program of the present invention, even if the request source terminal is an optional function "multiple dialog not used", the dialogs of a plurality of request destination terminals based on forking can be matched. . In particular, it can be consistent with the optional features of multiple dialogs not specified in the request or response.

It is a system configuration figure in the present invention. It is a sequence diagram in the present invention. It is a sequence diagram of 1st Embodiment based on FIG. It is a sequence diagram of 2nd Embodiment based on FIG. It is the 2nd basic sequence figure in this invention. It is a sequence diagram of 1st Embodiment based on FIG. It is a sequence diagram of 2nd Embodiment based on FIG. It is a sequence diagram of 3rd Embodiment based on FIG. It is a first sequence diagram for recognizing that the request source terminal is not using a plurality of dialogs. It is a 2nd sequence diagram for recognizing that a request origin terminal is not using multiple dialogs. It is a functional 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 in the present invention.

According to FIG. 1, the SIP server 1 is disposed 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. The SIP server 1 is an AS or IBCF connected between different CSCFs, or
It may be TrGW connected between different IMS-AGWs. In the following embodiments, the SIP server arranged between different multimedia networks will be described as an AS.

According to FIG. 1, session requests and responses can be transferred between the request source terminal 21 and the request destination terminal 22 via the AS 1. According to FIG. 1, it is assumed that the request source terminal 21 is an optional function “multiple dialog not used”.
Request source terminal 21 = optional function "not using multiple dialogs"

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

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

[First step]
(S11) The request source terminal 21 transmits a request to the request destination terminal. This request is forwarded to the AS 1 via the CSCFs of the request source network.
(S12) The AS 1 transfers the received request to the request receiving terminal 22 as it is. Here, according to FIG. 2, the request is forked by the CFCF group to which the request destination terminal 22 is connected, and is simultaneously transferred to the plurality of request destination terminals 22.

[Second step]
(S21) The request receiving terminal 221 returns a response based on the first dialog [D1] to AS1. In response to the received response, the AS 1 stores the optional function of the request receiving terminal 221 as a first dialog [D1].

(S22) Then, the AS 1 transfers the response received from the request destination terminal 221 to the request source terminal 21 as it is. At this time, the dialog is based on the first dialog [D1] for the first request destination terminal.

[Third step]
(S31) The request receiving terminal 222 also receives the session start request by forking. Therefore, the request receiving terminal 222 also sends a response back to the AS 1. The response is based on the second dialog [D2].

(S32) AS1 recognizes that responses have been received from the plurality of request destination terminals 221 and 222. Here, if the request source terminal 21 is an optional function “use a plurality of dialogs”, the AS 1 can directly transfer the response received from the request destination terminal 222 to the request source terminal 21 (not shown in FIG. 2). . It should be noted that whether the request source terminal 21 is the option function “use of multiple dialogs” or “not in use” may be preset by the communication carrier or may be determined according to FIG. 9 described later It is also good.

(S33) AS1 compares the dialog for the first request receiving terminal 221 with the dialog for the second request receiving terminal 222 when the request source terminal 21 has the option function “not using multiple dialogs”. When the predetermined elements of both dialogs are the same, the response is not transmitted to the request source terminal 21.

  The dialog is, for example, an ID that is a combination of a call identifier (Call-ID), a local tag, and a remote tag. The dialog ID is represented by the To tag, the From tag, and the Call-ID in the header information. Here, the predetermined element is an element predefined in any one of the response code, the header field, and the type of SDP contained in the body.

  The AS 1 stores the dialog for the request receiving terminal 222 as the dialog for the request receiving terminal 221. Then, the AS 1 terminates the second and subsequent dialog information so as not to transmit the plurality of pieces of dialog information to the request source terminal 21. However, even in the second and subsequent dialog information, it is transmitted as the first dialog information only when the predetermined element is registered as the transfer essential header.

[The fourth step]
(S4) The AS 1 executes the sequence with the request source terminal 21 with the dialog [D2] for the request destination terminal 222 as the dialog [D2] for the request destination terminal 221. Of course, the AS 1 executes a sequence with the request receiving terminal 222 based on the dialog [D 2] for the request receiving terminal 222.

  FIG. 3 is a sequence diagram of the first embodiment based on FIG.

According to FIG. 3, in comparison with FIG. 2, it corresponds as follows.
The request of S1 is a session start request.
The response of S2 is a provisional response.

(S11) The request source terminal 21 transmits a session start request (SIP: INVITE) with the URI (Uniform Resource Indicator) of the request destination terminal as the destination information. This request is forwarded to the AS 1 via the CSCFs of the request source network.

(S12) The AS 1 transfers the received session start request to the request receiving terminal 22 as it is. According to FIG. 2, the session start request is forked by the CFCF group to which the request destination terminal 22 is connected, and is simultaneously transferred to the plurality of request destination terminals 22.
Here, when the request source terminal 21 is a UA, SIP URI or tel URI included in the User-Agent header, P-Asserted-Identity header, or From header may be used to specify the terminal type. When the request source terminal 21 is a network communication device, the domain part of the SIP URI included in the ioi parameter of the P-Charging-Vector header, the P-Asserted-Identity header or the From header to specify the network type. You may use.

[Second step]
(S21) The request receiving terminal 221 sends a provisional response (SIP: 183 (INVITE)) including the SDP to the AS1. In response to the received provisional response, the AS 1 stores the optional function of the request receiving terminal 221 as a first dialog [D1].
Here, when the request destination terminal 22 is a UA, SIP URI or tel URI included in the User-Agent header, P-Asserted-Identity header, or To header may be used to specify the terminal type. When the request destination terminal 22 is a network communication device, the domain portion of the SIP URI included in the ioi parameter of the P-Charging-Vector header, the P-Asserted-Identity header, or the To header is specified to specify the network type. You may use.

(S22) Then, the AS 1 transfers the provisional response received from the request destination terminal 221 to the request source terminal 21 as it is. At this time, the dialog is based on the first dialog [D1] for the first request destination terminal.

[Third step]
(S31) The request receiving terminal 222 also receives the session start request by forking. Therefore, the request receiving terminal 222 also sends a provisional response (SIP: 183 (INVITE)) including the SDP back to the AS 1. The provisional response is based on the second dialog [D2].
At this time, the AS 1 can also acquire the request destination option of the session update request (UPDATE) at the request destination terminal 222 from the provisional response.

(S32) The AS 1 recognizes that provisional responses (SIP: 183 (INVITE)) have been received from the plurality of request destination terminals 221 and 222. Here, if the request source terminal 21 is an optional function “multiple dialog not used”, the dialog for the request destination terminal 222 is stored as the dialog for the request destination terminal 221.

(S33) AS1 compares the dialog for the first request receiving terminal 221 with the dialog for the second request receiving terminal 222 when the request source terminal 21 has the option function “not using multiple dialogs”. If the predetermined elements of both dialogs are the same, the response is not transmitted to the request source terminal 21. Here, when the predetermined element is the same, the provisional response code (SIP: 183 (INVITE)) is the same, and the predetermined element (the header field, SDP included in the body) included in the signal is Types are the same. That is, there is no need to notify the request source terminal 21.

[The fourth step]
(S4) The AS 1 executes a sequence with the request source terminal 21 as the dialog [D 2] for the request destination terminal 222 as the dialog [D 2] for the request destination terminal 221, and with the request destination terminal 222. , The sequence is executed based on the dialog [D2] for the request receiving terminal 222.

  FIG. 4 is a sequence diagram of the second embodiment based on FIG.

According to FIG. 4, in comparison with FIG. 2, it corresponds as follows.
The request of S1 is a session start request.
The response of S2 is a ringing response.

(S11 to S12) This is the same sequence as S11 to S12 in FIG.
(S21) The request receiving terminal 221 sends a ringing response (SIP: 180 (INVITE)) back to the AS1. The ringing response indicates, for example, that the ringing tone is played back at the request source terminal during call connection. The AS 1 stores the optional function of the request receiving terminal 221 as the first dialog [D 1] according to the received ringing response.

(S22) Then, AS1 transfers the ringing response received from the request destination terminal 221 to the request source terminal 21 as it is. At this time, the dialog is based on the first dialog [D1] for the first request destination terminal.

(S31) The request receiving terminal 222 also receives the session start request by forking. Therefore, the request receiving terminal 222 also sends a ringing response (SIP: 180 (INVITE)) back to the AS 1. The ringing response is based on the second dialog [D2].

(S32) The AS 1 recognizes that the ringing response (SIP: 180 (INVITE)) has been received from the plurality of request destination terminals 221 and 222. Here, if the request source terminal 21 is an optional function “multiple dialog not used”, the dialog for the request destination terminal 222 is stored as the dialog for the request destination terminal 221.

(S33) When the predetermined elements of the dialogs of both the first request destination terminal 221 and the second request destination terminal 222 are the same, the AS 1 does not transmit the response to the request source terminal 21. Here, when the predetermined element is the same, the ringing response code (SIP: 180 (INVITE)) is the same, and the predetermined element (the header field, SDP included in the body) included in the signal is Types are the same. That is, there is no need to notify the request source terminal 21.

(S4) The AS 1 executes a sequence with the request source terminal 21 as the dialog [D 2] for the request destination terminal 222 as the dialog [D 2] for the request destination terminal 221, and with the request destination terminal 222. , The sequence is executed based on the dialog [D2] for the request receiving terminal 222.

  FIG. 5 is a second basic sequence diagram in the present invention.

(S11 to S33) This is the same sequence as S11 to S33 in FIG. According to FIG. 5, only S34 is added as compared to FIG.
(S34) AS1 determines that the dialog [D2] for the request destination terminal 222 is the dialog [D1 for the request destination terminal 221] when the predetermined elements of both the dialogs for the request destination terminal 221 and the request destination terminal 222 are different. ] Is sent to the request source terminal 21.
The message here may be a request or a response, depending on the embodiment. As seen from the request source terminal 21, it is based on the dialog [D1] for the request destination terminal 221.

  FIG. 6 is a sequence diagram of the first embodiment based on FIG.

According to FIG. 6, in comparison with FIG. 5, it corresponds as follows.
The request of the first step is a session start request.
The response of the second step is a provisional response from the first request destination terminal.
The response of the third step is a provisional response from the second request destination terminal.
The message of the third step is an update request.

(S11 to S31) This is the same sequence as S11 to S31 in FIG.
(S32) When the AS1 receives the response from the request destination terminal 222, if the optional function “multiple dialog not used” in the session of the request source terminal 21 in the session, the dialog for the first request destination terminal 221 and the second And the dialog for the request destination terminal 222 of FIG.
(S33) If the predetermined elements of the dialogs of both the first request destination terminal 221 and the second request destination terminal 222 are the same, the AS 1 does not transfer the provisional response to the request source terminal 21.
(S34) AS1 transmits, to the request source terminal 21, an update request (SIP: UPDATE) including the SDP of the optional function of the request destination terminal 222 when the predetermined elements of both dialogs are different. This update request is based on the first dialog information [D1]. That is, it appears that the request source terminal 21 has received the update request based on the dialog for the request destination terminal 221. In addition, the predetermined element is updated to one adapted to the second request destination terminal 221.
(S35) In response to the update request, the request source terminal 21 sends an update response (SIP: 200 (UPDATE)) including the SDP to the AS1.

(S4) The AS 1 executes a sequence with the request source terminal 21 as the dialog [D 2] for the request destination terminal 222 as the dialog [D 2] for the request destination terminal 221, and with the request destination terminal 222. , The sequence is executed based on the dialog [D2] for the request receiving terminal 222.

  FIG. 7 is a sequence diagram of the second embodiment based on FIG.

(S11 to S32) This sequence is the same as S11 to S32 in FIG.
(S33) If the predetermined elements of the dialogs of both the first request destination terminal 221 and the second request destination terminal 222 are the same, the AS 1 does not transfer the provisional response to the request source terminal 21.
(S34) Then, if the 100 rel option is specified in the Require header of the provisional response, the AS 1 transmits a provisional response confirmation request (SIP: PRACK) to the request destination terminal 222. The provisional response confirmation request is based on the second dialog [D2]. As a result, the AS 1 tries to establish a session with the request destination terminal 222. Although not shown, when the Require header including the 100 rel option is specified in the transfer required header, the provisional response is transferred to the request source terminal 21.
(S35) In response to this, the request destination terminal 222 transmits a provisional response confirmation response (SIP: 200 (PRACK)) to the provisional response confirmation request to the AS1.

(S36) Then, the request destination terminal 222 transmits a session start response (SIP: 200 (INVITE)) to the AS1. The session start response is based on the second dialog [D2].

(S37) When a session start response (SIP: 200 (INVITE)) including the second dialog [D2] is received only from the request target terminal 222, the AS 1 transmits the first request target terminal 221 and the second It is determined that predetermined elements of both dialogs for the request receiving terminal 222 are different.
On the other hand, although not shown, when the AS 1 receives a session start response (SIP: 200 (INVITE)) including the first dialog [D1] from the request destination terminal 221, the response is the request source terminal as it is. Transfer to 21 Thereafter, when a session start response (SIP: 200 (INVITE)) including the second dialog [D2] is received from the request destination terminal 222, it is determined whether or not predetermined elements of both dialogs are the same. In the first dialog [D1] and the second dialog [D2], for example, codecs used in the result of SDP negotiation may be different.

(S38) When predetermined elements of both dialogs are different, in order to establish a session between the request source terminal 21 and the request destination terminal 222, the AS 1 updates the request including the SDP of the optional function of the request destination terminal 222 SIP: UPDATE) is sent to the request source terminal 21. The update request is based on the first dialog information [D1]. That is, as seen from the request source terminal 21, the update request based on the dialog for the request destination terminal 221 is received.
(S39) In response to the update request, the request source terminal 21 sends an update response (SIP: 200 (UPDATE)) including the SDP to the AS1.

(S3A) The AS1 confirms that the second dialog information [D2] and the optional function of the request destination terminal 222 have succeeded in updating the session start response (SIP: 200 (INVITE)) to the first dialog [D1]. ] And transmit to the request source terminal 21. The request source terminal 21 can establish a session by transmitting a session start response to the request source terminal after matching it to the optional function of the request destination terminal 222 by the update request.

(S3B) The request source terminal 21 transmits a confirmation request (SIP: ACK) to the AS 1 in response to the session start response.
(S3C) AS1 transfers the confirmation request (SIP: PRACK) in which the first dialog information is transferred to the second dialog information to the request destination terminal 222.

(S4) The AS 1 executes a sequence with the request source terminal 21 as the dialog [D 2] for the request destination terminal 222 as the dialog [D 2] for the request destination terminal 221, and with the request destination terminal 222. , The sequence is executed based on the dialog [D2] for the request receiving terminal 222.

  FIG. 8 is a sequence diagram of the third embodiment based on FIG.

According to FIG. 8, FIG. 5 corresponds as follows.
The request of S1 is a session start request.
The response of S2 is a provisional response.
The response of S3 is a provisional response including a transfer essential header.
The message of S3 is a provisional response including a transfer required header.

  According to FIG. 8, AS 1 registers the transfer required header in the header of the provisional response. Specifically, for example, the header of P-Early Media may be used. P-Early Media is a function to flow media between terminals before establishing a session. This medium is like, for example, a ringing tone played back at the requesting terminal during call connection. For this purpose, P-Early Media is preferably registered as a transfer mandatory header.

(S11 to S22) This is the same sequence as S11 to S22 in FIG.
(S31) The request receiving terminal 222 also returns a provisional response (SIP: 183 (INVITE)) including the SDP to the AS1. Here, the response is based on the second dialog [D2] and includes P-Early Media in the header.
(S32) AS1 recognizes that responses have been received from the plurality of request destination terminals 221 and 222. Here, if the request source terminal 21 is an optional function “use a plurality of dialogs”, the dialog for the request destination terminal 222 is stored as the dialog for the request destination terminal 221.
(S33) AS1 determines whether or not predetermined elements of the dialogs of both the first request destination terminal 221 and the second request destination terminal 222 are different when the transfer essential header is included.
(S34) When predetermined elements of both dialogs are different and P-Early Media is included in the header of the provisional response received in S31, the AS 1 transmits the provisional response to the dialog for the request destination terminal 222. The dialog is replaced with the dialog [D1] for the request receiving terminal 221 from [D2], and is transmitted to the request issuing terminal 21.
(S35) The request source terminal 21 returns a provisional response confirmation request PRACK to the AS1.
(S4) The AS 1 executes a sequence with the request source terminal 21 as the dialog [D 2] for the request destination terminal 222 as the dialog [D 2] for the request destination terminal 221, and with the request destination terminal 222. , The sequence is executed based on the dialog [D2] for the request receiving terminal 222.

  FIG. 9 is a first sequence diagram for recognizing that the request source terminal is not using a plurality of dialogs.

According to FIG. 9, it can be determined whether or not the optional function “multiple dialog not used” of the request source terminal in the session.
(S11 to S31) This is exactly the same as S11 to S31 in FIG.

(S32) According to FIG. 9, the AS 1 returns the provisional response (SIP: 183) based on the second dialog received from the request destination terminal 222 to the request source terminal 21 as it is. Here, the request source terminal 21 has received both the provisional response based on the first dialog [D1] and the provisional response based on the second dialog [D2].

(S33) At this time, the request source terminal 21 executes a failure sequence with the AS 1 because of the optional function “not using multiple dialogs”. As a failure sequence, it is possible to do nothing but just discard the signal, or to send a session cancel signal (SIP: CANCEL) to end the session, and various operations can be assumed. .
When a failure response occurs, the failure sequence may be limited to a specific error type (identified by the SIP Status Code), or all error types may be targets.

(S34) When the failure sequence is executed with the request source terminal 21, the AS 1 determines that the request source terminal 21 is the optional function “not in use of multiple dialogs”.

(S35) Then, the AS 1 executes a session disconnection sequence between the request source terminal 21 and the request destination terminals 221 and 222.

  As a result, after recognizing that the request source terminal 21 is not using a plurality of dialogs, the AS 1 can execute the above-described sequence of FIG. 9 again.

  According to S11 to S35, even if the optional function “multiple dialogs” of the request source terminal 21 can not be specified explicitly, if a failure sequence occurs in the request-response exchange, the optional function is not It can be matched as use. That is, even if the request source terminal 21 is “not in use of multiple dialogs”, the AS 1 need not notify the request source terminal 21 to that effect. The AS1 can immediately match the request destination terminal and the optional function as a single dialog.

  FIG. 10 is a second sequence diagram for recognizing that the request source terminal is not using a plurality of dialogs.

(S11) When receiving a session start request (SIP: INVITE) from the request source terminal 21, the AS 1 acquires a request source option of a session update request (UPDATE). Here, the AS 1 can know that the request source terminal 21 is the optional function “not in use of multiple dialogs”.
(S12-S22) This is exactly the same as S12-S22 in FIG.
(S31) The AS 1 recognizes that the provisional response has been received from the plurality of request destination terminals 221 and 222.
(S32) AS1 executes the disconnection sequence when the session update request (UPDATE) is not used and the multiple dialogs of the session are not used for the request source option of the request source terminal 21.
Then, after storing that the plurality of dialogs of the session is not in use for the request source terminal 21, the AS 1 can execute the sequence of FIG. 2 again.

  FIG. 11 is a functional block diagram of the application server in the present invention.

According to FIG. 11, the application server 1 includes a request transfer unit 11, a response transmission unit 12, a dialog determination unit 13, and a dialog exchange unit 14. These functional components are realized by executing a program that causes a computer installed in a server disposed between multimedia networks to function.
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 in FIG. 2).
When the response transmission unit 12 receives a response from the request destination terminal 221, the response transmission unit 12 transmits a response based on a dialog for the request destination terminal 221 to the request source terminal 21.
When the dialog determination unit 13 receives a response from the request destination terminal 222, the dialog determination unit 13 is an optional function “do not use multiple dialogs” of the request source terminal 21 in the session, and the dialog for the request destination terminal 221 and for the request destination terminal 222 Control is performed so as not to transmit the response to the request source terminal if the predetermined element is the same in comparison with the dialog of FIG. In addition, when the dialog for the request destination terminal 221 and the dialog for the request destination terminal 222 are compared and the predetermined element is different, a message (a request or a request message for setting the dialog for the request destination terminal 222 as the dialog for the request destination terminal 221 Response) to the request source terminal.
The dialog exchange unit 14 executes a sequence with the request source terminal 21 using the dialog for the request destination terminal 222 as the dialog for the request destination terminal 221.

  As described above in detail, according to the inter-network control method, the SIP server, and the program of the present invention, even if the request source terminal is the optional function “do not use multiple dialogs”, a plurality of request destinations based on forking Terminal dialogs can be coordinated. In particular, it can be consistent with the optional features of multiple dialogs not specified in the request or response.

  This makes it possible to avoid failures based on inconsistencies in session-based multiple dialog options and to improve interoperability. Specifically, the mobile operator can improve the interoperability of the own network service with a terminal (for example, a SIM free terminal) not optimized for the own network service.

  Moreover, according to the present invention, the carrier only needs to install the application server (or IBCF) in the IMS without installing a special function in the terminal. Therefore, there is no need for the request source terminal and the request destination terminal of the session to recognize the optional function “multiple dialog use / not use”. That is, from the viewpoint of the terminal, there is no need to change the existing sequence via IMS. Also, it can be used universally for IMS and IP networks operated by different operators.

  For the various embodiments of the present invention described above, various modifications, corrections and omissions of the scope of the technical idea and aspect 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 limiting in any way. The present invention is limited only as defined in the following claims and the equivalents thereto.

1 AS, IBCF, TrGW
11 request transfer unit 12 response transmission unit 13 dialog determination unit 14 dialog exchange unit 21 request source terminal 22, 221, 222 request destination terminal

Claims (16)

In an inter-network connection method of a SIP (Session Initiation Protocol) server disposed between a multimedia network to which a request source terminal is connected and a multimedia network to which a request destination terminal is connected,
The SIP server is
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 transmitting a response based on the dialog for the first request destination terminal to the request source terminal when receiving the response from the first request destination terminal;
When the response is received from the second request destination terminal, the optional function “multiple dialog not used” of the request source terminal in the session, and the dialog for the first request destination terminal and the second request destination terminal And a third step of not transmitting the response to the request source terminal if the predetermined element is the same in comparison with the dialog.
And a fourth step of executing a sequence with the request source terminal as the dialog for the second request destination terminal as the dialog for the first request destination terminal. The inter-network connection according to claim 1, wherein the predetermined element is an element predefined in any of a response code, a header field, and a type of SDP (Session Description Protocol) included in a body. Method. The first step request is a session start request,
The inter-network connection method according to claim 2, wherein the response of the second step is a provisional response. The first step request is a session start request,
The inter-network connection method according to claim 2, wherein the response of the second step is a ringing response. For the third step, the SIP server:
When the dialog for the first request destination terminal and the dialog for the second request destination terminal are compared and the predetermined element is different, the dialog for the second request destination terminal is the dialog for the first request destination terminal The method according to claim 2, characterized in that the message (request or response) is transmitted to the request source terminal. The first step request is a session start request,
The response of the second step is a provisional response,
The response of the third step is a provisional response,
The inter-network connection method according to claim 5, wherein the message of the third step is an update request. For the third step, the SIP server:
After receiving the provisional response from the request destination terminal, a provisional response confirmation request is sent to the second request destination terminal,
7. The method according to claim 6, further comprising the step of transmitting the update request to the request source terminal when receiving a session start response from the second request destination terminal. For the third step, the SIP server:
When a session start response including the first dialog is received from the first request destination terminal and a session start response including the second dialog is received from the second request destination terminal, predetermined elements of both dialogs are different. The inter-network connection method according to claim 7, wherein the update request is transmitted to a request source terminal only in the case. For the third step, the SIP server:
9. The method according to claim 7, further comprising the step of transmitting the update request to the request source terminal and receiving an update response from the request source terminal, and then transmitting a session start response to the request source terminal. The predetermined element is registered as a transfer essential header,
The first step request is a session start request,
The response of the second step is a provisional response,
The response of the third step is a provisional response including the transfer required header,
The method according to claim 2, wherein the message in the third step is a provisional response including the transfer essential header. 11. The first step according to any one of claims 1 to 10, wherein the request is forked to a plurality of request destination terminals in a multimedia network to which the request destination terminals are connected. Inter-network connection method. The SIP server is
Regarding the third step, in order to determine whether or not the optional function “multiple dialog not used” of the request source terminal in the session,
The response received from the second request destination terminal is transmitted as it is to the request source terminal as a response based on the dialog for the second request destination terminal,
12. The method according to claim 1, wherein, when a failure sequence is executed with the request source terminal, execution is performed to determine that the optional function “multiple dialog not used” of the request source terminal in the session. An inter-network connection method according to any one of the items. The SIP server is
In the first step, upon receiving a request from a request source terminal, obtain a request source option of a session update request (UPDATE),
In the third step, if the request source option of the request source terminal is “session update request not used” and “multiple dialog not used”, a disconnection sequence is executed,
The inter-network connection according to any one of claims 1 to 12, characterized in that, after storing "not in use of plural dialogs" of the request source terminal, the first step to the third step are executed again. Method. The SIP server is
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 network connection method according to any one of claims 1 to 13, wherein the request destination terminal is a request destination UA or a network communication device. In the SIP server disposed between the multimedia network to which the request source terminal is connected and the multimedia network to which the request destination terminal is connected,
Request transfer means for transferring the request to the request destination terminal when receiving the request from the request source terminal;
Response transmission means for transmitting a response based on the dialog for the first request destination terminal to the request source terminal when receiving the response from the first request destination terminal;
When the response is received from the second request destination terminal, the optional function “multiple dialog not used” of the request source terminal in the session, and the dialog for the first request destination terminal and the second request destination terminal Dialog determination means which does not send the response to the request source terminal if the predetermined element is the same in comparison with the dialog;
A SIP server comprising: a dialog for the second request destination terminal as the dialog for the first request destination terminal; and a dialog exchange means for executing a sequence with the request source terminal. In a program that causes a computer installed in a SIP server disposed between a multimedia network to which a request source terminal is connected and a multimedia network to which a request destination terminal is connected,
Request transfer means for transferring the request to the request destination terminal when receiving the request from the request source terminal;
Response transmission means for transmitting a response based on the dialog for the first request destination terminal to the request source terminal when receiving the response from the first request destination terminal;
When the response is received from the second request destination terminal, the optional function “multiple dialog not used” of the request source terminal in the session, and the dialog for the first request destination terminal and the second request destination terminal Dialog determination means which does not send the response to the request source terminal if the predetermined element is the same in comparison with the dialog;
A program for causing a computer to function as dialog exchange means for executing a sequence with a request source terminal as the dialog for the second request destination terminal as the dialog for the first request destination terminal.