JP2005159581A - Interworking method for different protocol (sip/h.323) for ip telephone - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an interworking method capable of providing services while interlocking with between ITU-T protocol (H.323) as a basic protocol of Internet telephone service and IETF protocol (SIP) as a next-generation protocol whose popularization is gradually expanded. <P>SOLUTION: The following blocks are classified by function and executed: an IHP block for interlocking with a network gate keeper via a stack 1 (H.323); an ISP block for interlocking with an SIP network proxy server by driving an SIP stack; an ITP block for converting a protocol while interlocking with both the blocks; and an IMP block for generating and driving slave processing corresponding to the above blocks, monitoring the status, and re-driving the slave processing at the time of stopping the process to maintain a continuous call service. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention includes an ITU-U protocol (H.323) that is already used as a basic protocol for IP telephone service, and an IETF protocol (SIP: Session Initiation Protocol), which is a next-generation protocol that has been increasingly popularized. It is related with the interworking method which enables service in conjunction with.

  The IP telephone protocol is divided into ITU-T protocol 1 (H.323) and IETF protocol 2 (SIP). Protocol 1 is already defined and has national standards. That is, a basic service is provided by a gateway connected to the PSTN, a gatekeeper that manages and connects a protocol 1 application terminal, and a protocol 1 terminal.

  On the other hand, IETF has completed the latest standard (RFC. 3261) with Protocol 2 (SIP) suitable for transmission of multimedia contents such as voice, video, text, etc., with shorter call control time than Protocol 1. Currently, IP telephone service providers and VoIP equipment developers are also accelerating the transition to protocol 2. Both protocols are independent of each other and are not linked to each other. Protocol 1 (H.323) is set up only between protocol 1 terminals via the gatekeeper, and protocol 2 (SIP) terminals are set up only between SIP terminals via the proxy server.

Although the standardization work on the part of interworking is proceeding with IETF, only drafts are occasionally published via IP. Protocol 1 (H.323) is call forwarding to protocol (H.450), Since the call hold and call transfer functions are defined, protocol 2 (SIP) has functions defined in the draft over the Internet, but the definition is still unknown, and this can be used for interworking. A lot of research is needed on how to apply it.
Research on network management, quality (QoS) assurance, and billing is necessary, as well as defining and implementing functions for the safety certification field to ensure safe services for users.

  Therefore, the present invention has been made to solve the above-described problems, and the purpose of the present invention is to enable the service provider to use the protocol 1 (H.323) network that has already been constructed while continuously using the next generation protocol. It is possible to shift to the protocol 2 (SIP) network.

  Another object of the present invention is to enable linkage between an operator having only a protocol 1 (H.323) network and an operator having only a protocol 2 (SIP) network.

  Still another object of the present invention is to allow the interworking server to satisfy protocol 1 and protocol 2 and to reduce the cost by reducing the investment cost.

  In order to achieve the above-mentioned object, the present invention provides a continuous interworking service. Therefore, when a process error occurs, a function for automatically recovering the process error and various protocol 1 terminal call settings are provided. Protocol-based protocol 2 A method for implementing a modularized server for ensuring smooth call setup between terminals is presented.

  That is, the present invention relates to an IHP block that is linked to the protocol 1 network via the protocol 1 (H.323) stack, an ISP block that is driven by the SIP stack and linked to the SIP network, and is linked between the blocks. An ITP block that converts a protocol, and an IMP block that generates and drives a child process corresponding to the block, monitors a state, and is driven again by a child processor to maintain a call service when the process is stopped. Provided is a heterogeneous protocol (SIP / H.323) interworking method for Internet telephones, which is executed by function.

  The IMP block stores the processes of the ISP block, the IHP block, and the ITP block in a child processor, and monitors this when the processing of the ISP block, the IHP block, and the ITP block is stopped due to the occurrence of an abnormal operation during call processing. Simultaneously with the stop, the automatic recovery function based on the child processor is executed sequentially.

  In the present invention, when the heterogeneous protocol for Internet telephone (SIP / H.323) is interworked, the call setting of the protocol 1 terminal (H.323 protocol terminal) is fast start (Fast Start) or When the normal start (Normal Start) is confirmed, and when the fast start is performed, the SPD information is transmitted when the invite message is transmitted to the protocol 2 (SIP) terminal, and the SPD information is included in the ACK message. When the transmission is not started and the normal start, the SPD information is not transmitted when the invite message is transmitted to the SIP terminal, and the heterogeneous protocol (SIP / IP protocol) for transmitting and processing the SDP information for the ACK message. H.323) Provide an interworking method.

  The present invention operates on a UNIX operating workstation, drives the Protocol 1 (H.323) stack to drive the Protocol 1 (H.323) network and the Protocol 2 (SIP) stack. Then, the ISP block that works with the protocol 2 network, the ITP block that works by analyzing the message between the two blocks, the block is driven, the state is monitored, and the drive is stopped when the process is stopped. And an IMP block for maintaining a continuous call service. The IMT block outputs the current call setup status and the like by remote monitoring.

  According to the present invention as described above, a continuous service can be realized by automatically recovering an abnormal state when an abnormal state occurs by a modularized process in linking between both protocols of VoIP. By accurately linking the call setting procedure of protocol 1 (H.323) and the call setting procedure of protocol 2 (SIP), it is possible to provide a service regardless of the procedure of the call control.

  According to the present invention, the service provider can reduce the operating cost by providing a stable service, and the user can use the stable service.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
FIG. 1 shows the overall network structure in which the present invention is implemented. The left side of FIG. 1 is a protocol 1 (H.323) domain in which call processing is performed according to ITU-T protocol 1 (H.323). The terminal 11 on which the protocol 1 (H.323) is mounted can make a call with only the protocol (H.323) terminal 11 via the gatekeeper 12. The right side of FIG. 1 is a protocol 2 (SIP) domain in which call processing is performed according to protocol 2 (SIP) of IETF. The terminal 21 equipped with the SIP protocol (protocol 2) can make a call with only the SIP terminal 21 via the proxy server 22.

  However, according to the present invention, call processing is performed between different protocols by using an IWF (Inter Working Function) 30 that enables such interworking. That is, as indicated by the solid line arrow, the protocol 1 terminal 11 (H.323 phone 0) is converted by the IWF 30 via the gatekeeper 12 and then the protocol 2 terminal 21 (SIP phone 0) via the proxy server 22. To call. On the contrary, as indicated by the dotted arrow, the protocol 2 terminal 21 (SIP phone n) is converted by the IWF 30 through the proxy server 22 and then converted into the protocol 1 terminal 11 (H.323 phone n) via the gatekeeper 12. To call. The contents of the protocol to be converted and the contents of the protocol (H.323, SIP) are already defined in the standard document and are not elements of the new invention. Therefore, the detailed explanation is omitted, and the contents newly embodied by the present invention are used. An emphasis will be placed on FIG.

  FIG. 2 shows the structure of the internal process of the IWF 30. This is in charge of communication with the proxy server 22 with protocol 2 (SIP protocol), and an ISP (IWF SIP Process) block 31 for exchanging messages to an ITP (IWF Tunneling Process) block 32 for protocol conversion, and Protocol 1 (H.323) is built in and is in charge of communication with the gatekeeper 12, ITP (IWF H.323 Process) block 33, and ITP which receives a message between both the blocks 31 and 33, converts the protocol and transmits it (IWF Tunneling Process) block 32 and IMP (IWF Management) that maintains the continuous call service by driving the blocks 31, 32, and 33, monitoring the status, and re-driving when the process is stopped Process) block 34. In this way, the process is modularized according to function, so that the expertise of the implementation can be ensured and the complexity of the program can be reduced.

  In addition, it is easy to investigate the cause of problems that occur during operation. A double-headed arrow is a flow up to call setting. Communication is performed between the IHP block 33 and the ITP block 32, and between the ISP block 31 and the ITP block 32 using a message queue that is a communication protocol between internal processes on Unix. The IMP block 34 generates child processes inside as indicated by arrows, and drives the ISP block 31, the ITP block 32, and the IHP block 33, respectively.

  In other words, the IMP block 34 continuously monitors the abnormal state of each of the blocks 31, 32, and 33. When the process is stopped and the service is stopped, the child process generated inside is used in real time. Re-driving allows continuous call service. Such functions have significant advantages in terms of operation and maintenance.

3a to 3c are flowcharts for setting a call in a protocol 1 terminal (H.323 terminal), and are divided into a fast start (Fast Start) and a normal start (Normal Start).
It goes without saying that a call must be made regardless of the procedure of call setup. The present invention has been made to support such functions. This is linked between the IHP block 33, the ITP block 32, and the ISP block 31, which are blocks related to call processing.

3a is a flowchart of the IHP block for carrying out the present invention, FIG. 3b is a flowchart of the ITP block, and FIG. 3c is a flowchart of the ISP block.
First, a description will be given with reference to a flowchart when call setup is performed in the Fast Start procedure. The IHP block of FIG. 3a runs a daemon process and waits for a call from the Protocol 1 telephone (H.323 telephone) network (S1). When the setup message is received from the gatekeeper 12, the IHP block 33 starts the procedure analysis work first. Fast start (determines whether it is (S2). If it is determined to be fast start (Send message is sent to ITP block 32 to request protocol conversion. At this time, the codec of the terminal (H.323), The IP address and the port number information are transmitted (S3).

  It is detected whether there is ITP block codec information that has received the node (a11) message of FIG. 3B (S10), and if there is codec information, protocol conversion is performed using Invite (S11). At this time, the protocol 1 terminal (H.323 terminal) 11 including the codec, IP address, and port number information is transmitted to the node (a12).

  The ISP block 31 shown in FIG. 3c receives the node (a12) message and checks whether there is codec information (S20). If the codec information is present, the protocol 1 terminal received from the ITP (when transmitting to the SIP network) ( H.323 terminal) 11 codec, IP, and port number information is included in SDP information and transmitted to proxy server 22 (S21). The SIP terminal 21 through the proxy server 22 performs codec negotiation in comparison with its own codec information. When one of them is selected and a message (for example, 200 OK) is transmitted to the ISP (S22), the ISP transmits the final codec to the ITP block 32 again to request protocol conversion (S23), and the node (b21) is transmitted. To the ITP block 32.

  Since the ITP received via the node (b21) in FIG. 3b has received the codec that has been negotiated, it is assumed that call setup has been completed, and the information is stored in the database (S12), the protocol is converted, and the Connect internal message is transmitted. The data is transmitted to the IHP block 33 through 2-2 (S13).

  The IHP block that has received the data via the node (b22) of FIG. 3a transmits the determined codec to the network (H.323) (S4). When such a process is completed, a call is made between the protocol 1 terminal (H.323 terminal) 11 and the protocol 2 terminal (SIP terminal) 21 and the call setting is completed by the fast start procedure.

  Next, a flow when a call is set up by a normal start procedure will be described. Initiating a call at the Protocol 1 terminal (H.323 terminal) is the same as Fast Start. As shown in FIG. 3a, the IHP block 33 detects a normal start if it is not a fast start in step S2, and sends a message to the ITP block 32 without information on the codec, IP address, and port number. A conversion is requested (S5). Then, since the ITP block 32 of FIG. 3b is also normally started via the node (a11), protocol conversion is performed in bytes without codec information (S14), and a message is transmitted to the ISP block 31 at the node (a12) .

  The ISP block 31 received from the node (a12) in FIG. 3c does not generate SDP (Session Description Protocol) information, but transmits an invite message to the proxy server 22 forming the SIP network (S24). Since the SIP terminal that has received this has no SDP information, the codec negotiation is not performed and the codec list information that can be used is included in the SDP message and the codec transmitted from the proxy server 22 by the message (200 OK) is displayed in the ISP block. 31 receives (S25). The ISP block 31 that has received a large number of codec information transmits a large number of codec information to the ITP block 32 via the node (b23) in an internal message (200 OK) for codec negotiation (S26).

  In FIG. 3b, the ITP block 32 received the internal message (200 OK) via the message via the node (b23), but since the codec negotiation has not been completed, it is not considered that the call setup has been completed. The protocol is converted and a plurality of codec information is transmitted to the IHP block 33 via the node (b24) (S15).

  The IHP block 33 of FIG. 3a receives the message via the node (b24), and performs codec negotiation with the protocol 1 terminal (H.323 terminal) 11 using the protocol (H.245) (S6). When the codec (H.245) negotiation is completed, the IHP block 33 transmits the codec determined after the negotiation is completed to the ITP block 32 by an internal message (H.245 complete) via the node (c31) (S7).

The ITP block 32 of FIG. 3b considers that the call setup has been completed for the first time, stores information in the database, converts the protocol with an ACK message, and transmits the final codec to the ISP block 31 via the node (c32) (S16). .
In the ISP block 31 of FIG. 3c, the codec determined after the negotiation is completed is included in the SDP information and transmitted to the proxy server 22 of the SIP network as an ACK message (S27). The protocol 2 terminal (SIP terminal) 21 received from the proxy server 22 can perform a call by setting a call with the selected codec.

If an error occurs in any one of the above processes, the call setup fails. In this way, the present invention provides services to various customers by naturally performing call conversion at the protocol 2 terminal (SIP terminal) regardless of the protocol 1 terminal (H.323 terminal) procedure. Has the advantage of being easy to do.
The present invention as described above is not limited to the description of the above-described embodiments and the drawings, and those skilled in the art can make various substitutions, modifications, and changes without departing from the technical idea of the present invention. Will become apparent.

1 is a diagram illustrating the overall network structure in which the present invention is implemented; FIG. It is a figure which shows the internal process structure of IWF. It is a flowchart of call setting according to procedure of an IHP block. It is a flowchart of call setting according to procedure of an ITP block. It is a flowchart of call setting according to procedure of an ISP block.

Explanation of symbols

11 ... Protocol 1 terminal 12 ... Gatekeeper 21 ... Protocol 2 terminal 22 ... Proxy server 30 ... IWF
31 ... ISP block 32 ... ITP block 33 ... IHP block 34 ... IMP block

Claims (3)

An IHP block that interfaces with the protocol 1 network via the protocol 1 (H.323) stack;
An ISP block that drives the SIP stack and works with the SIP network;
An ITP block for converting a protocol in conjunction with the two blocks;
The child process corresponding to the block is generated and driven, the state is monitored, and when the process is stopped, the child processor is redriven to maintain the call service, and the IMP block is divided into functions and executed. Feature heterogeneous protocol for SIP (SIP / H.323) interworking method.   The IMP block stores the processes of the ISP block, the IHP block, and the ITP block in a child processor, and monitors this when the processing of the ISP block, the IHP block, and the ITP block is stopped due to the occurrence of an abnormal operation during call processing. The IP telephone heterogeneous protocol (SIP / H.323) interworking method according to claim 1, wherein the function of automatically restoring based on the child processor is sequentially executed simultaneously with the stop. When interworking heterogeneous protocol for IP phone (SIP / H.323), call setting of protocol 1 terminal (H.323 protocol terminal) is Fast Start or Normal Start The stage of confirming whether or not
If it is fast start, the SPD information is transmitted when an invite message is transmitted to a protocol 2 (SIP) terminal, and the SPD information is not transmitted to the ACK message;
When starting normally, SPD information is not transmitted when an invite message is transmitted to a SIP terminal, and SDP information is transmitted and processed in an ACK message. Protocol (SIP / H.323) interworking method.

Images