JP4751937B2 - Transaction occurrence method and transaction occurrence system - Google Patents

Description

  The present invention relates to a technique for generating a transaction in a SIP device.

  In telephone terminals and exchange systems that support SIP (Session Initiation Protocol), call control such as session start / end is performed by repeatedly exchanging a request signal and a response signal using a SIP message. Is realized.

  Communication between SIP devices such as telephone terminals and switching systems corresponding to SIP is performed in units of transactions including request signals and response signals. The SIP device has a transaction layer for managing transactions, holds a retransmission timer when a SIP message is lost, and performs processing such as retransmitting a message at an appropriate interval.

  A transaction is generated when a request signal is transmitted or received, and is released after a final response signal is transmitted or received. However, in preparation for requesting retransmission of the same final response signal, the transaction is awaited for release for a certain time after the final response signal is transmitted. In addition, for the transaction that has transmitted the request signal, the release of the transaction is awaited for a certain period of time after the final response signal is received in preparation for receiving the final response signal to be retransmitted.

Akira Kurokawa, 1 other, “ETSI TISPAN NGN Standardization Trend”, NTT Technical Journal, Nippon Telegraph and Telephone Corporation, April 2006, p.71-73 J. Rosenberg, 7 others, "RFC3261, SIP: Session Initiation Protocol" [online], June 2002, IETF, Internet <URL: http://www.ietf.org/rfc/rfc3261.txt> R. Sparks, “Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests draft-sparks-sip-invfix-02”, [online], July 2008, IETF, Internet <URL: http: //tools.ietf .org / id / draft-sparks-sip-invfix-02.txt>

  However, when the exchange of the request signal and the final response signal is continuously performed a plurality of times, for example, when holding and releasing the hold continuously in the telephone terminal, etc., holding the transaction after the final response transmission / reception, Since it becomes necessary to simultaneously hold a large number of transactions, there is a problem in that the amount of memory allocated for transaction management increases according to the occurrence of the transaction. Alternatively, as an SIP transaction management method, when an upper limit is set for a transaction per dialog, there is a problem that a transaction cannot be generated when the upper limit is exceeded, and as a result, a request signal cannot be accepted. .

  The present invention has been made in view of the above, and the problem is that even when there is a memory limitation or when the number of transactions is limited, a transaction is generated as much as possible and a request signal is generated. Is to accept the process.

  A transaction generation method according to a first aspect of the present invention is a transaction generation method of a SIP device that performs call signal control by a transaction including a request signal and one or more response signals to the request signal, and generates a new transaction. If there is a transaction for which a final response signal for the request signal has been transmitted or a final response signal for the request signal has already been received, one of the transactions is released and a new one is released. A step of generating a new transaction.

  A transaction generation method according to a second aspect of the present invention is a transaction generation method of a SIP device that performs call signal control by a transaction including a request signal and one or more response signals to the request signal, and generates a new transaction. In the case where a resource for acquisition cannot be captured, the transaction includes a step of releasing one of existing transactions and generating a new transaction when the transaction is a disconnected system.

  In the transaction occurrence method, the transaction to be released is the transaction having the oldest occurrence among the transactions corresponding to the condition.

  A transaction generation system according to a third aspect of the present invention is a transaction generation system of a SIP device that performs call signal control by a transaction including a request signal and one or more response signals to the request signal, and generates a new transaction. If there is a transaction for which a final response signal for the request signal has been transmitted or a final response signal for the request signal has already been received, one of the transactions is released and a new one is released. And transaction processing means for generating a simple transaction.

  A transaction generation system according to a fourth aspect of the present invention is a transaction generation method of a SIP device that performs call signal control by a transaction including a request signal and one or more response signals to the request signal, and generates a new transaction. In the case where the resource for acquisition cannot be captured, the transaction processing means for releasing any of the existing transactions and generating a new transaction when the transaction is a disconnected system is provided.

  In the transaction occurrence system, the transaction to be released is the transaction having the oldest occurrence among the transactions corresponding to the condition.

  In the present invention, when a resource for generating a new transaction cannot be captured, a new transaction can be generated using a resource of the released transaction by releasing a transaction that satisfies a predetermined condition. It becomes.

  As described above, according to the present invention, even when the memory is limited or the number of transactions is limited, it is possible to generate a transaction as much as possible and accept the processing of the request signal.

It is a schematic diagram which shows one structural example of an IP telephone service system. It is a block diagram which shows the example of 1 structure of the SIP apparatus used for the said IP telephone service system. It is a flowchart which shows the flow of a process when the transaction occurrence system in one Embodiment produces a transaction. It is explanatory drawing for demonstrating the state transition of an INVITE client transaction. It is explanatory drawing for demonstrating the state transition of an INVITE server transaction. It is explanatory drawing for demonstrating the state transition of a non-INVITE client transaction. It is explanatory drawing for demonstrating the state transition of a non-INVITE server transaction.

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

  FIG. 1 is a schematic diagram showing a configuration example of an IP telephone service system. As shown in the figure, the IP telephone service system includes a subscriber SIP server 20, a relay SIP server 30, a VoIP gateway device 40, and a terminal device 50. Each of the SIP devices provides a call connection service by transmitting and receiving a SIP message.

  The subscriber SIP server 20 is arranged on the IP network 100 and accommodates the terminal device 50 of the IP telephone service subscriber.

  The relay SIP server 30 does not directly accommodate the terminal device 50 but relays the SIP messages of the subscriber SIP server 20, the other relay SIP server 30, and the VoIP gateway device 40.

  The VoIP gateway device 40 converts analog voice data into digital data, converts the digital data into analog voice data, and relays between the PSTN (Public Switched Telephone Networks) 200 and the IP network 100. Do.

  The terminal device 50 is a communication terminal for IP telephone service and can perform call signal control by SIP.

  Next, the configuration of the subscriber SIP server 20, the relay SIP server 30, the VoIP gateway device 40, and the terminal device 50 will be described. The SIP device that performs call signal control by SIP includes the transaction occurrence system according to the present embodiment. FIG. 2 is a block diagram illustrating a configuration example of the SIP device. The SIP device 10 shown in the figure includes an application processing unit 11 that performs call processing, a transaction processing unit 12 that manages transaction of call processing signals, and a transport processing unit 13.

  The transaction processing unit 12 generates a transaction when a request signal is received from the transport processing unit 13 and when a request signal transmission instruction is received from the application processing unit 11, and holds a retransmission timer when the SIP message is lost. Process to resend the message at appropriate intervals. If the transaction processing unit 12 cannot capture a resource for generating a new transaction, and there is a releasable transaction that satisfies a predetermined condition in the existing transaction, the transaction having the oldest transaction is included. And start a new transaction using that resource. Details of the process for generating the transaction will be described later.

  The transport processing unit 13 enables communication with other SIP devices 10 using UDP (User Datagram Protocol), TCP (Transmission Control Protocol), and SCTP (Stream Control Transmission Protocol).

  When the SIP device 10 transmits a request signal, the application processing unit 11 requests the transaction processing unit 12 to transmit the request signal. The transaction processing unit 12 generates a transaction and requests the transport processing unit 13 to transmit a request signal. Then, the transport processing unit 13 transmits a request signal. A response signal to the request signal is received by the transport processing unit 13 and passed to the transaction processing unit 12, and the transaction processing unit 12 passes it to the application processing unit 11.

  On the other hand, when the SIP device 10 receives the request signal, the transport processing unit 13 passes the received request signal to the transaction processing unit 12. The transaction processing unit 12 generates a transaction and passes a request signal to the transport processing unit 13. Then, the application processing unit 11 requests the transaction processing unit 12 to transmit a response signal to the request signal, and the transaction processing unit 12 requests the transport processing unit 13 to transmit a response signal, The processing unit 13 transmits a response signal.

  Next, processing when the transaction processing unit 12 generates a transaction will be described. FIG. 3 is a flowchart showing a processing procedure when a transaction occurs. The upper limit number N of transactions per dialog is determined, and the number of transactions currently held in the dialog is n.

  First, when the transaction processing unit 12 tries to generate a transaction in order to receive or transmit a request signal, it is determined whether the number n of transactions in the already held dialog is smaller than the transaction upper limit number N (step) S1).

  If the transaction number n is smaller than the transaction upper limit number N, a transaction is generated (step S2), 1 is added to the transaction number n (step S3), and the process is terminated.

  When the transaction number n has reached the transaction upper limit number N, it is determined whether there is a transaction that has received the final response or has transmitted the final response (step S4).

  If there is a final response received transaction or a final response transmission transaction, the transaction with the oldest occurrence is released, and the transaction number n is decremented by 1 (step S5). Then, a transaction is generated (step S2), 1 is added to the transaction number n (step S3), and the process is terminated.

  If there is no transaction for which the final response has been received or the final response has been transmitted, it is determined whether the transaction to be generated is a disconnection method (step S6).

  If the transaction to be generated is a disconnect method, the transaction with the oldest occurrence is released and the transaction number n is decremented by 1 (step S7). Then, a transaction is generated (step S2), 1 is added to the transaction number n (step S3), and the process is terminated.

  On the other hand, if the transaction to be generated is not a disconnect method, an error process is performed (step S8), and the process is terminated.

  Next, transaction state transitions defined in Non-Patent Documents 2 and 3 will be described. The transaction managed by the transaction processing unit 12 provides its function by holding a state machine. A transaction has a client side and a server side, and is known as a client transaction and a server transaction, respectively. The client transaction sends a request signal and the server transaction sends a response signal. There are two types of state transitions for client transactions and server transactions, respectively. One is for INVITE requests, and the other is for all requests (request signals) other than INVITE requests.

  FIG. 4 is a diagram for explaining the state transition of the INVITE client transaction. When there is an INVITE request transmission request from the application processing unit 11, the transaction processing unit 12 passes the INVITE request to the transport processing unit 13 and enters the Calling (calling) state. At this time, a timer A for resending the INVITE request and a timer B for detecting a timeout are started.

  When timer A expires in the Calling state, timer A is reset and the INVITE request is retransmitted. When the timer B expires or a transport error occurs, the application processor 11 is notified and enters a terminated state.

  When a 1xx response is received in the Calling state, the application processing unit 11 is notified of this and enters the Proceeding state. When a 1xx response is received in the Proceeding state, the application processing unit 11 is notified of this.

  When the 2xx response is received in the Calling state or the Proceeding state, the application processing unit 11 is notified to that effect, enters the Accepted state, and starts the timer M. When a 2xx response is received in the Accepted state, the application processing unit 11 is notified of this. When timer M expires, the Terminate state is entered.

  On the other hand, when a 300-699 response is received in the Calling state or the Proceeding state, the application processing unit 11 is notified of this, and the transaction processing unit 12 generates an ACK and sends it to the transport processing unit 13. Pass, enter the Completed state, and start timer D.

  When the 300-699 response is received in the Completed state, the application processing unit 11 is notified accordingly. When timer D expires, the Terminate state is entered. If a transport error occurs in the Completed state, the application processing unit 11 is notified to that effect and enters the Terminated state.

  In FIG. 4, the condition for releasing the transaction is a completed state or an accepted state after receiving a final response (2xx response, 300-699 response). Note that the condition for releasing the transaction may be not after the final response is received but after the ACK is transmitted.

  FIG. 5 is a diagram for explaining the state transition of the INVITE server transaction. When the INVITE request is received, it is notified to the application processing unit 11 and enters the Proceeding state. If there is no request from the application processing unit 11 within 200 ms, the transaction processing unit 12 generates a 100 response and passes it to the transport processing unit 13.

  When there is a 101-199 response transmission request from the application processing unit 11 in the Proceeding state, the 101-199 response is passed to the transport processing unit 13. If an INVITE request that matches the transaction is received, the INVITE request is a retransmission and a response signal is transmitted.

  If a transport error occurs in the Proceeding state, the application processing unit 11 is notified of this and a Terminated state is entered.

  If there is a 2xx response transmission request from the application processing unit 11 in the Proceeding state, the 2xx response is passed to the transport processing unit 13 to enter the Accepted state, and the timer L is started. When there is a 2xx response transmission request from the application processing unit 11 in the Accepted state, the 2xx response is passed to the transport processing unit 13. When the timer L expires, the Terminate state is entered.

  On the other hand, if there is a 300-699 response transmission request from the application processing unit 11 in the Proceeding state, the 300-699 response is passed to the transport processing unit 13 to enter the Completed state. When entering the Completed state, timer G and timer H are started. When the timer G expires, the timer G is reset, and a 300-699 response is passed to the transport processing unit 13 for retransmission. Further, when the retransmission of the INVITE request is received in the Completed state, the response signal is retransmitted. When the ACK is received in the Completed state, the Confirmed state is entered, the timer I is started, and when the Timer I expires, the Terminate state is entered. When the timer H expires or a transport error occurs in the completed state, the application processing unit 11 is notified and enters the terminated state.

  In FIG. 5, the condition for releasing the transaction is a completed state, a confirmed state, or an accepted state after the final response (2xx response, 300-699 response) is transmitted. Note that the condition for releasing the transaction may be after receiving the ACK instead of after sending the final response.

  FIG. 6 is a diagram for explaining the state transition of the non-INVITE client transaction. When there is a request for transmitting a request from the application processing unit 11, the transaction processing unit 12 passes the request to the transport processing unit 13 and enters a Trying state. At this time, a timer E for request retransmission and a timer F for detecting a timeout are started.

  When the timer E expires in the trying state, the timer E is reset and the request is retransmitted. When the timer F expires or a transport error occurs, the application processor 11 is notified and enters a terminated state.

  If a 1xx response is received in the Trying state, the application processing unit 11 is notified of this and a Proceeding (processing) state is entered.

  When a 1xx response is received in the Proceeding state, the application processing unit 11 is notified of this. When the timer E expires in the Proceeding state, the timer E is reset and the request is retransmitted. When the timer F expires or a transport error occurs in the Proceeding state, the application processing unit 11 is notified and enters a terminated state.

  On the other hand, when a 200-699 response is received in the Trying state or the Proceeding state, the application processing unit 11 is notified to that effect, enters the Completed state, and starts the timer K. When timer K expires, the Terminate state is entered.

  In FIG. 6, a condition for releasing a transaction is a completed state after receiving a final response (200-699 response).

  FIG. 7 is a diagram for explaining the state transition of the non-INVITE server transaction. When the request is received, the application processing unit 11 is notified and a Trying state is entered.

  If there is a 1xx response transmission request from the application processing unit 11 in the Trying state, the 1xx response is passed to the transport processing unit 13 to enter the Proceeding state.

  When there is a 1xx response transmission request from the application processing unit 11 in the Proceeding state, the 1xx response is passed to the transport processing unit 13. If a request retransmission is received, the response signal is retransmitted.

  If there is a 200-699 response transmission request from the application processing unit 11 in the Trying state or the Processing state, the 200-699 response is passed to the transport processing unit 13 to enter the Completed state. To start. When timer J expires, it enters a terminated state. If a request retransmission is received in the completed state, the response signal is retransmitted.

  If a transport error occurs in the Proceeding state or the Completed state, the application processing unit 11 is notified to that effect and enters the Terminated state.

  In FIG. 7, the condition for releasing the transaction is the Completed state after sending the final response (200-699 response).

  As described above, according to the present embodiment, even in a transaction holding period, a condition for releasing a transaction is determined, and if there is a transaction corresponding to the condition, the transaction can be released. Thus, it is possible to preferentially capture the transaction that occurs. Specifically, when a transaction is generated, if the number of transactions n has reached the upper limit number N of transactions, if there is a transaction in which a final response has been transmitted or a final response has been received, When the oldest transaction is released and the new transaction is a disconnect method, the oldest transaction among the existing transactions is released, and the new transaction is released. Transaction can occur.

  This ensures that signal processing continues normally even within limited resources without performing memory depletion or error processing due to memory constraints, even in situations where hold / hold release continues. Can do.

  In addition, since it is necessary to manage a large number of dialogs, such as a SIP device used in a carrier, the continuity of signal processing can be improved in a device that needs to limit the number of transactions per dialog.

  Furthermore, the continuity of signal processing can be improved in an apparatus in which the number of transactions per dialog is limited due to large hardware restrictions such as a user terminal apparatus.

DESCRIPTION OF SYMBOLS 10 ... SIP apparatus 11 ... Application processing part 12 ... Transaction processing part 13 ... Transport processing part 20 ... Subscriber SIP server 30 ... Relay SIP server 40 ... VoIP gateway apparatus 50 ... Terminal apparatus 100 ... IP network 200 ... PSTN

Claims (6)

A transaction generation method for a SIP device that performs call signal control by a transaction comprising a request signal and one or more response signals to the request signal,
If resources for generating a new transaction cannot be captured, if there is a transaction that has transmitted a final response signal for the request signal or has received a final response signal for the request signal, A method of generating a transaction, comprising the step of releasing any of the above and generating a new transaction. A transaction generation method for a SIP device that performs call signal control by a transaction comprising a request signal and one or more response signals to the request signal,
A transaction generation method characterized by having a step of releasing one of existing transactions and generating a new transaction when the resource for generating a new transaction cannot be captured when the transaction is disconnected .   3. The transaction occurrence method according to claim 1, wherein the transaction to be released is a transaction having the oldest occurrence among the transactions corresponding to the condition. A SIP transaction generation system that performs call signal control by a transaction comprising a request signal and one or more response signals to the request signal,
If resources for generating a new transaction cannot be captured, if there is a transaction that has transmitted a final response signal for the request signal or has received a final response signal for the request signal, A transaction generation system comprising transaction processing means for releasing any of the above and generating a new transaction. A transaction generation method for a SIP device that performs call signal control by a transaction comprising a request signal and one or more response signals to the request signal,
A transaction characterized by having a transaction processing means for generating a new transaction by releasing any of the existing transactions when resources for generating a new transaction cannot be captured and the transaction is disconnected. Occurrence system.   6. The transaction occurrence system according to claim 4, wherein the transaction to be released is a transaction having the oldest occurrence among the transactions corresponding to the condition.

Images