KR20120009587A - System and method for providing sip service - Google Patents

Abstract

PURPOSE: A sip service system and a control method thereof are provided to enable normal call processing regardless of network environment such as a public network and a private network using different IP address. CONSTITUTION: Terminals(10,20) transmit registration request message establishing terminal binding information including a destination address. A message convert server(100) creates the unique key of a terminal by receiving the registration request message. The message convert server transmits the SIP message to the destination address of the terminal using the terminal binding information corresponding to the unique key. A call session control device(200) registers the unique key and server binding information by receiving the changed registration request message from the message convert server. The call session control device transmits the server binding information to the message convert server according to the server binding information.

Description

SIP service system and its control method {SYSTEM AND METHOD FOR PROVIDING SIP SERVICE}

The present invention relates to a SIP service system and a control method thereof, and more particularly, to a terminal and a call session control function (CSCF) in an IP multimedia subsystem (IMS) network using a session initiation protocol (SIP). By converting the binding information of the SIP message transmitted and received between the two to relay the transmission and reception of the SIP message, it is possible to perform normal call processing regardless of the network environment such as public network and private network using different IP addresses. The present invention relates to a SIP service system and a control method thereof.

IMS (IP Multimedia Subsystem) is a communication platform defined by 3GPP (The 3rd Generation Partnership Project) to provide multimedia services based on the Session Initiation Protocol (SIP) protocol in an all IP network environment.

In an IMS-based network, an IP address is assigned to each terminal to identify a sender and a receiver for communication. IP addresses include public IP addresses commonly used around the world and private IP addresses used on private networks.

Private networks can be configured using Network Address Translation (NAT). NAT is an address translation technology of a communication network that converts a private IP address into a public IP address, and allocates a private IP address that can be used only in a local network to a terminal. When a terminal of a private network uses another network or a public network, NAT converts the private IP address assigned to the terminal into a public IP address and transmits the data to the outside, and converts the public IP address of the received data into the public terminal. Provides translation to private IP address.

Meanwhile, in an IMS-based network, terminals register a public ID and binding information with a call session control function (CSCF) to use a network. The binding information registered in the call session controller is used to transmit or receive a SIP message or establish a session with the terminal, including access information such as a destination IP and a port of the terminal.

However, the NAT constituting the private network can analyze only the headers of the third and fourth layers of the OSI model and cannot analyze the headers of the upper layer. In other words, only the UDP / TCP header and the port value are converted in the address converted through NAT, and the destination address of the terminal set as binding information in the SIP message header is not converted.

Therefore, when the terminal located in the private network establishes a call with the terminal of the external network, the private IP is set in the binding information of the terminal located in the private network, and thus there is a problem in that incoming routing from the outside becomes impossible.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-described problem, and is a SIP message transmitted and received between a terminal and a call session control function (CSCF) in an IMS (IP Multimedia Subsystem) network using a Session Initiation Protocol (SIP). SIP service that converts binding information and relays SIP messages so that normal call processing can be performed regardless of network environment such as public network and private network using different IP addresses. There is a technical problem to provide a system and a control method thereof.

The SIP service system of the present invention for achieving the above object is a terminal for transmitting a registration request message is set terminal binding information including a destination address; Receiving the registration request message, generating a unique key of the terminal, transmitting the changed registration request message by changing the terminal binding information to the server binding information which is the unique key and its binding information, and including the unique key; A message conversion server for transmitting the SIP message to a destination address of the terminal by using the terminal binding information corresponding to the unique key when a SIP message is received; And receiving the changed registration request message from the message conversion server, registering the unique key and the server binding information, and transmitting a SIP message generated based on the unique key to the message conversion server according to the server binding information. It may include a session controller.

Message conversion server of the present invention for achieving the above object, the transmission and reception interface for transmitting and receiving SIP messages; Unique key generation unit for generating a unique key based on the information contained in the SIP message; And generating a unique key of the terminal by controlling the unique key generation unit when a registration request message of a predetermined terminal is received through the transmission / reception interface, and converts binding information of the terminal included in the registration request message into the unique key and It may include a control unit for transmitting the changed registration request message through the transmission and reception interface by changing to the server binding information of its own binding information.

Here, the registration request message includes the terminal binding information, or a contact header for setting the unique key and the server binding information, and the controller controls the terminal binding information stored in the contact header of the registration request message. It is possible to change the registration request message by changing the key and the server binding information.

The unique key generation unit substitutes a public ID and a contact canonical form of a terminal included in the registration request message into a message-digest algorithm 5 (MD5) hash function. You can generate a key.

The terminal may further include a database storing the unique key of the terminal, a public ID included in the registration request message, a contact canonical form, a receiving IP, and receiving port information. .

On the other hand, when the re-registration request message of a predetermined terminal is received through the transmission / reception interface, the controller retrieves a unique key of the terminal from the database based on the information included in the re-registration request message, and re-registers the terminal. By changing the binding information of the terminal included in the request message to the searched unique key and the server binding information, it is possible to transmit the changed registration request message through the transmission and reception interface.

When the call request message of a predetermined terminal is received through the transmission / reception interface, the controller searches for information on the terminal corresponding to the unique key from the database based on the unique key included in the call request message. It is possible to change the call request message according to the information and transmit the changed call request message to the receiving IP of the terminal and the receiving port.

According to another aspect of the present invention, there is provided a SIP service method comprising: transmitting, at a terminal, a registration request message in which terminal binding information including a destination address is set; Receiving the registration request message at a message conversion server to generate a unique key of the terminal, and storing information of the registration request message and a unique key of the terminal; Changing, by the message conversion server, the terminal binding information of the registration request message to the server binding information which is the unique key and its own binding information, and transmitting the changed registration request message to request registration of the terminal; Receiving the changed registration request message at a call session controller, registering the unique key and the server binding information, and transmitting a SIP message generated based on the unique key to the message conversion server according to the server binding information; Receiving the SIP message at the message conversion server and converting the SIP message according to the information of the registration request message of the terminal corresponding to the unique key; And transmitting the converted SIP message to the destination address included in the terminal binding information.

Here, the generating of the unique key of the terminal in the message conversion server may include a public ID and a contact canonical form included in the registration request message as a message-digest algorithm 5 (MD5) hash ( hash) to generate the unique key.

The changing of the terminal binding information of the registration request message to the server binding information of the unique key and its own binding information may include: converting the terminal binding information stored in the contact header of the registration request message. It is possible to include the step of changing to a unique key and the server binding information.

And, in the NAT (Network Address Translation), giving a private IP address as a destination address of the terminal, and assigning a public IP address to the registration request message sent by the terminal and transmitting to the message translation server further comprising: It is possible.

The transmitting of the converted SIP message to the destination address included in the terminal binding information may include transmitting the converted SIP message to the destination address of the terminal set to the private IP.

The control method of the message conversion server of the present invention for achieving the above object comprises the steps of: receiving a registration request message is set the terminal binding information including the destination address of the terminal; Generating a unique key based on information included in the registration request message; Storing the information of the registration request message and the unique key; Converting the terminal binding information included in the registration request message into the unique key and server binding information; Transmitting the converted registration request message; And when the SIP message including the unique key is received, searching for information on the registration request message of the terminal corresponding to the unique key and transmitting the SIP message to a destination address of the terminal.

The generating of the unique key based on the information included in the registration request message may include: public ID and contact canonical form of the terminal included in the registration request message; Digest algorithm 5) It is possible to include the step of generating a unique key by substituting a hash function.

The storing of the information of the registration request message and the unique key may include: the unique key, a public ID, a contact canonical form included in the registration request message, a reception IP, And storing receiving port information.

The converting of the terminal binding information included in the registration request message into the unique key and the server binding information may include converting the terminal binding information stored in the contact header of the registration request message to the unique key and the server binding information. It may include the step of changing to.

On the other hand, if the re-registration request message is received, extracting the terminal binding information contained in the re-registration request message; Retrieving a unique key corresponding to the terminal binding information from previously stored information; Converting the terminal binding information included in the re-registration request message into the retrieved unique key and server binding information; And transmitting the converted registration request message.

In addition, when the call request message is received, extracting the terminal binding information contained in the call request message; Retrieving a unique key corresponding to the terminal binding information from previously stored information; Converting the terminal binding information included in the call request message into the retrieved unique key and server binding information; And transmitting the converted call request message.

The method may further include converting the call-ID and the originating tag included in the call request message into a form capable of controlling B2BUA (Back-To-Back User Agent).

On the other hand, if the incoming call request message is received, extracting a unique key of the called terminal included in the incoming call request message; Retrieving terminal binding information of a called terminal corresponding to the unique key from previously stored information; Converting a destination address included in the incoming call request message into terminal binding information of the called terminal; The method may further include transmitting the converted call request message to a destination address of the called terminal.

The method may further include converting a call-ID and an outgoing tag included in the incoming call request message into a form capable of controlling B2BUA (Back-To-Back User Agent).

The transmitting of the SIP message to the destination address of the terminal may include transmitting the SIP message to the destination address of the terminal set to the private IP.

As described above, the SIP service system and control method thereof according to the present invention are transmitted and received between a terminal and a call session control function (CSCF) in an IMS (IP Multimedia Subsystem) network using a Session Initiation Protocol (SIP). By converting the binding information of the SIP message and relaying transmission and reception of the SIP message, normal call processing can be performed regardless of a network environment such as a public network and a private network using different IP addresses.

1 is a configuration diagram of a SIP service system according to a first embodiment of the present invention;
2 is a block diagram of a SIP service system according to a second embodiment of the present invention;
3 is a control block diagram of a message conversion server according to an embodiment of the present invention;
4 is a data structure diagram of the database of FIG. 3;
5 is a control flowchart of a message conversion server according to an embodiment of the present invention;
6 is a control flowchart of a message conversion server according to another embodiment of the present invention;
7 is a signal flow diagram of a SIP service system according to an embodiment of the present invention;
8 is a signal flow diagram of a SIP service system according to another embodiment of the present invention.

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

1 is a block diagram of a SIP service system according to a first embodiment of the present invention.

As shown in FIG. 1, the SIP service system according to the first embodiment includes a public network 3, a first private network 1, and a second private network 5 having different IP addresses. It may include. In the first private network 1, a network address translation (NAT) 50 and a first terminal 10 for address translation are located, and in the public network 3, a second terminal 20 and terminals 10 and 20 are provided. Message conversion server 100 for converting the SIP message to be transmitted and received is located, the second private network (5) Call Session Control Function (CSCF) for storing the registration information of the terminals (10, 20) ( 200) is located.

The public network 3 is an area using a public IP address, and unique IP addresses are assigned to the second terminal 20, the NAT 50, and the message conversion server 100, respectively. In the following description, the case where the IP address of the public network 3 is 222.106.XX will be exemplified.

The private networks 1 and 5 use private IP addresses and use private IP addresses that can only be used in the local area in order to efficiently use a limited public IP address. The private IP of the first private network 1 is assigned to the first terminal 10 and the NAT 50, and the private IP of the second private network 5 is assigned to the call session control unit 200 and the message conversion server 100. do. In the following description, an IP address of the first private network 1 is 10.10.XX, and an IP address of the second private network 5 is 192.168.XX.

The first terminal 10 and the second terminal 20 may transmit / receive multimedia data such as audio and video by SIP signaling. Each of the first terminal 10 and the second terminal 20 may be assigned an IP address to transmit and receive a multimedia data packet through a network. The first terminal 10 and the second terminal 20 using the SIP transmit a register request message (REGISTER) to register their location. In the contact header of the registration request message, binding information for allowing the terminals 10 and 20 to receive a SIP message is set. The contact header may store FQDN (Fully Qualified Doman Name) information of each terminal including an IP address, an access port, and the like. The first terminal 10 and the second terminal 20 may include an internet dedicated telephone, an internet telephone connected to a computer, and the like.

The NAT 50 converts a private IP address into a public IP address and a public IP address into a private IP address. When the first terminal 10 using the private IP address transmits data to another network, the NAT 50 converts the private IP address of the first terminal 10 into a public IP address and transmits the data.

The message conversion server 100 transmits a registration request message received from the terminals 10 and 20 to the call session controller 200 so that the information of each terminal 10 and 20 is registered in the call session controller 200. Here, the message conversion server 100 converts the contact header of the registration request message transmitted by the terminals 10 and 20 into binding information of the message conversion server 100 and then transmits the message to the call session controller 200. do. In the contact header of the registration request message, binding information is stored in a contact canonical form. The contact standard format may be expressed in the form of "user @ host-port". Therefore, the destination IP of each terminal 10, 20 is set in the host area in the contact header of the registration request message. The message conversion server 100 sets the destination IP of the terminals 10 and 20 set in the host area of the contact header as its own IP, and converts the binding information of the contact header into the binding information of the message conversion server 100.

The message conversion server 100 generates a unique key of the corresponding terminal based on the public ID included in the registration request message and the binding information of the contact header in order to set a user area of the contact header. Here, the unique key is uniquely assigned to each terminal, and it is possible to distinguish each terminal through the unique key.

The message conversion server 100 sets a unique key in the user area user in the binding information of the contact header and sets the IP of the call session controller 200 in the host area host to bind the message conversion server 100. Convert to information. Accordingly, the binding information of the terminal set in the contact header of the registration request message may be converted into the binding information of the message conversion server 100.

The message conversion server 100 transmits the registration request message converted from the contact header to the call session controller 200. In addition, the message conversion server 100 may include information included in the original registration request message, for example, a public ID, terminal binding information of a contact canonical form, a reception IP, a reception port, and the like. Is stored with the unique key. Accordingly, the message conversion server 100 may set the contact header of the message to be transmitted and received as binding information of the terminals 10 and 20 or change the binding header of the message conversion server 100 as necessary. The function of the message conversion server 100 described above may be implemented using a session border controller (SBC).

The call session controller 200 receives a registration request message from the message conversion server 100 and registers information of the corresponding terminals 10 and 20. Here, the registration request message received by the call session controller 200 is a message in which the contact header is changed to the unique key and binding information of the message conversion server 100. The call session controller 200 stores the binding information by using the contact headers of the terminals 10 and 20, so that the terminals 10 and 20 are classified by the unique key and registered to be bound to the message conversion server 100. . Accordingly, the call session controller 200 recognizes each of the terminals 10 and 20 as a unique key and transmits all the messages for the call setup of the terminals 10 and 20 to the message conversion server 100.

As such, the SIP service system according to the present invention receives a registration request message transmitted from each terminal 10 or 20 in the message conversion server 100 to generate a unique key, and generates a unique header and a contact header of the registration request message. The message is converted into binding information of the message conversion server 100 and registered in the call session controller 200. The message conversion server 100 stores the unique keys of the terminals 10 and 20 and the contents of the registration request message. The call session controller 200 distinguishes each terminal 10 and 20 by a unique key, and all messages provided by the call session controller 200 to the terminals 10 and 20 are received by the message conversion server 100. Accordingly, the message conversion server 100 delivers the SIP message to each terminal 10, 20 based on the unique key transmitted from the call session controller 200 and the information of the pre-stored registration request message. Therefore, the message conversion server 100 may relay transmission and reception of SIP messages regardless of the network environment of the terminals 10 and 20, such as the private networks 1 and 5, the public network 3, and the like.

2 is a block diagram of a SIP service system according to a second embodiment of the present invention. In the description of the second embodiment of the present invention, the same components as the first embodiment will be denoted by the same reference numerals and redundant description thereof will be omitted.

The SIP service system according to the second embodiment may include a public network 3 and a private network 1 having different IP addresses.

In the private network 1, a NAT 50 for address translation and a first terminal 10 are located, and the public network 3 converts SIP messages transmitted and received to and from the second terminal 20 and the terminals 10 and 20. The message conversion server 100 and the call session controller 200 storing the registration information of the terminals 10 and 20 are located. The SIP service system according to the second embodiment having such a configuration is different from the first embodiment in that the call session controller 200 is located in the public network 3 and has a public IP. Due to this difference, there may be a difference in the registration request message conversion process of the message conversion server 100.

The message conversion server 100 converts the contact header of the registration request message into binding information of the message conversion server 100 and transmits it to the call session controller 200. The message conversion server 100 generates a unique key of the terminal 10 or 20 based on the public identification ID and the binding information included in the registration request message. The message conversion server 100 sets a unique key in the user area (user) in the contact header displayed in the form of "user @ host-port". Then, a public IP which is the IP of the call session controller 200 is set in the host area host to convert the contact header into binding information of the message conversion server 100.

The message conversion server 100 transmits the registration request message converted from the contact header to the call session controller 200.

As described above, when the call session control unit 200 has only the private IP (first embodiment) when the private IP is set in the host area of the contact header, and the call session control unit 200 has the public IP ( Second Embodiment A registration request message may be converted by setting a public IP in a host area of a contact header.

3 is a control block diagram of a message conversion server 100 according to an embodiment of the present invention.

As shown in FIG. 3, the message conversion server 100 includes a transmission and reception interface 120 for transmitting and receiving a SIP message, a message analyzer 130 for analyzing the contents of the message received through the transmission and reception interface 120, and an analysis. A unique key generation unit 140 for generating a unique key based on the contents of the generated message, a message conversion unit 150 for converting a message using the generated unique key, and information of the original message and the converted message And a controller 110 for controlling each of these components to convert contact headers of messages transmitted and received through the transceiving interface 120.

The transceiving interface 120 transmits and receives a SIP message with the NAT 50, the second terminal 20, the call session controller 200, and the like. The SIP message transmitted and received through the transceiving interface 120 may include various types of messages such as a registration request message (REGISTER), a re-registration request message (Re-REGISTER), a call request message (INVITE), and an incoming call request message.

The message analyzer 130 extracts information for generating a unique key of the terminal by analyzing the contents of the message received by the transmission / reception interface 120 or extracts a unique key that is already included. The registration request message may include information such as a sender (From), a receiver (To), a waypoint Via, a contact, and the like. The message analyzer 130 extracts a public ID from the To header and extracts binding information from the contact header to generate a unique key. Here, the binding information may be extracted in a contact canonical form of "user @ host-port" type. Meanwhile, the incoming call request message transmitted by the call session controller 200 may include a unique key. In this case, the message analyzer 130 may extract the unique key included in the message received by the transmission and reception interface 120.

The unique key generation unit 140 generates a unique key of the terminal 10 or 20 based on the information extracted by the message analyzer 130. The unique keys of the terminals 10 and 20 may be generated by encrypting the unique information for identifying the corresponding terminals 10 and 20. For example, a unique key may be generated by substituting a public ID included in a To header of a registration request message and binding information included in a contact header into a message-digest algorithm 5 (MD5) hash function. The MD5 hash function is a cryptographic hash function that receives a variable-length message and generates an output with a fixed length of 128 bits. RFC 1321 of the Internet Engineering Task Force (IETF) (Request For Comments 1321). It is prescribed in Thus, the unique key generation unit 140 may generate a 128-bit long unique key using the public ID and binding information extracted from the registration request message. Meanwhile, when terminals in different NATs 50 transmit registration request messages using the same private IP, binding information included in the contact header may be the same. Accordingly, in order to generate a unique key having unique characteristics according to the terminals 10 and 20, a unique key may be generated by substituting a public ID and binding information together.

The message conversion unit 150 converts the contact header of the registration request message into binding information of the message conversion server 100. The contact header of the registration request message received from the NAT 50 is set in the form of "user @ host-port" including binding information of the terminal. The message converter 150 sets a unique key in the user area of the contact header, sets the IP of the call session controller 200 in the host area, and converts the contact header into binding information of the message converter 150.

The controller 110 stores the information of the registration request message and the information of the converted registration request message received through the initial transmission / reception interface 120 in the database 160, and transmits the converted registration request message through the transmission / reception interface 120. Send to the session control unit 200.

When the re-registration request message is received through the transmission / reception interface 120, the controller 110 extracts binding information of the contact header included in the re-registration request message through the message analyzer 130. The controller 110 retrieves the binding information and the unique key of the terminals 10 and 20 stored in the database 160 and converts the contact header of the re-registration request message. Accordingly, the contact header of the re-registration request message may include binding information including the same unique key as the registration request message.

Meanwhile, when the call request message of the first terminal 10 is received from the NAT 50, the controller 110 converts the contact header of the call request message into binding information of the message conversion server 100. Here, the calling terminal and the called terminal performing the call by the call request message should proceed with the call in the B2BUA (Back-To-Back User Agent) method. Accordingly, the controller 110 changes the call ID (Call-DI) and the call tag (From tag) of the call request message, and then transmits the changed call request message to the call setting controller 110.

When the incoming call request message for the call request message is received, the controller 110 extracts a unique key of the contact header included in the incoming call request message through the message analyzer 130. The controller 110 retrieves the binding information of the terminal corresponding to the unique key from the database 160 and converts the incoming call request message so that the call proceeds in a B2BUA manner between the calling terminal and the called terminal. The controller 110 transmits the converted incoming call request message to the receiving IP or the receiving port of the called terminal.

4 is a data structure diagram of the database 160 of FIG.

The database 160 stores a binding information table 165 including original information of the registration request message and information of the registration request message after conversion.

The binding information table 165 may store a public ID of a terminal included in the original registration request message, a terminal binding information of a contact canonical form, a reception IP, a reception port, and the like. In addition, the unique key set in the contact header of the registration request message after the conversion is stored.

When the received message includes binding information of the terminal, the controller 110 may search for a unique key corresponding to the corresponding message from the database 160 and convert the contact header of the message.

If a unique key is included in the received message, the controller 110 may retrieve the actual binding information of the corresponding terminal from the database 160 and convert the contact header of the message. In addition, the message can be sent to the terminal by inquiring the receiving IP or the receiving port of the terminal.

FIG. 5 is a control flowchart of the message conversion server 100 according to an embodiment of the present invention. When the registration request message REGISTER is received from the first terminal 10 located in the private network 1, the message conversion server 100 is received. Shows the control flow.

The controller 110 receives a registration request message from the first terminal 10 through the transmission and reception interface 120 (S110). The registration request message transmitted by the first terminal 10 may be converted into a public IP by the NAT 50 and received by the transmission / reception interface 120 of the message conversion server 100.

The message analyzer 130 extracts the binding information set in the public ID and the contact header from the registration request message under the control of the controller 110 (S120).

The unique key generation unit 140 generates a unique key using the extracted public ID and binding information (S130). The unique key generation unit 140 may generate a unique key having a length of 128 bits by substituting the public ID and binding information into the MD5 hash function.

The controller 110 stores the original binding information and the unique key in the database 160 (S140).

The controller 110 converts the contact header of the registration request message into binding information including a unique key to convert the registration request message (S150).

The controller 110 transmits the converted registration request message to the call session controller 200 (S160).

As described above, the message conversion server 100 according to an embodiment of the present invention receives the registration request message from the terminal 10 to generate a unique key, and the contact header of the registration request message to the unique key and the message conversion server It can be converted into the binding information of (100).

6 is a control flowchart of a message conversion server 100 according to another embodiment of the present invention, in which a call session controller 200 returns an incoming call request message to a call request message sent by the message conversion server 100. In one case, the control flow of the message conversion server 100 is illustrated.

When the incoming call request message is received from the call session controller 200 (S210), the controller 110 extracts the unique key included in the incoming call request message (S220). The call session controller 200 stores binding information for each unique key of each terminal. Thus, in the incoming call request message transmitted from the call session controller 200, each terminal 10, 20 may be displayed with a unique key.

The controller 110 retrieves binding information of the called terminal corresponding to the unique key from the database 160 (S230).

The control unit 110 converts the call request message using the retrieved binding information (S240). The controller 110 may change a call-ID, a caller tag, and contact information of the call request message for the B2BUA operation. Here, the contact information is for establishing a session between the called terminal and the message conversion server 100, it is not necessary to use a unique key.

The controller 110 transmits the converted incoming call request message to the receiving IP of the called terminal retrieved from the database 160 or the receiving port (S250). Here, the URI (Uniform Resource Identifier) of the called terminal included in the incoming call request message may be a private IP, and in the case of the private IP, the message is not transmitted. Therefore, in order to increase the possibility of transmitting the call request message, the incoming call request message may be transmitted to the receiving IP or the receiving port which was stored in the database 160 when the registration request message of the called terminal was received.

7 is a signal flow diagram of a SIP service system according to an embodiment of the present invention. In this embodiment, as shown in FIG. 1, the first terminal 10 is located in the first private network 1 and the call session controller 200 is located in the second private network 5. In the case of sending a registration request message, the signal flow will be illustrated.

The first terminal 10 transmits a registration request message (REGISTER) to the message conversion server 100 through the NAT (50) (P100). The private IP of the first terminal 10 is 10.10.0.5 and the public IP assigned to the NAT 50 is 222.106.2.9. The registration request message (REGISTER) transmitted by the first terminal 10 to the message conversion server 100 is as follows.

<Registration Request Message (REGISTER)> (Terminal 1-> Message Conversion Server)

REGISTER sip: sktims.net SIP / 2.0

Via: SIP / 2.0 / UDP 10.10.0.5:5080; received = 222.106.2.9; rport = 4820;

branch = z9hG4bK25dcafbf25dc

From: <sip: 07010002006@sktims.net>; tag = 1bf7

To: <sip: 07010002006@sktims.net>

Contact: <sip: UA@10.10.0.5: 5080> audio; video ..

The message conversion server 100 may extract the public ID "sip: 07010002006@sktims.net" from the To header of the registration request message. In addition, a contact canonical form "sip: UA@10.10.0.5: 5080" may be extracted from a contact header. The message conversion server 100 may obtain the unique key “22f82fa3ee84d01a7edb94eb9797b618” having a 128-bit length by substituting the value of the public ID and the contact header into the MD5 hash function. The message conversion server 100 stores information such as a public ID included in the registration request message, a contact standard type of a contact header, a unique key, a reception IP, a reception port, and the like in the database 160, and stores the contact header in the message conversion server 100. ) Into binding information. Accordingly, in the contact header "sip: UA@10.10.0.5: 5080" of the original message, the UA which is a user area is converted into a unique key, and the IP of the first terminal 10 is converted into an IP of the message conversion server 100. Accordingly, the contact header of the converted message may be converted to "sip: 22f82fa3ee84d01a7edb94eb9797b618@192.168.2.1: 5060".

The message conversion server 100 transmits the converted registration request message to the call session controller 200 (P120). The call session controller 200 has a private IP, and the IP may be set to 192.168.2.2. The registration request message (REGISTER) transmitted by the message conversion server 100 to the call session controller 200 is as follows.

<Converted Registration Request Message (REGISTER)> (Message Conversion Server-> Call Session Control Unit)

REGISTER sip: sktims.net SIP / 2.0

Via: SIP / 2.0 / UDP192.168.2.1: 5060; branch = z9hG4bKd5f2dd06df0baba_114b6

From: <sip: 07010002006@sktims.net>; tag = 1bf7

To: <sip: 07010002006@sktims.net>

Contact: < sip: 22f82fa3ee84d01a7edb94eb9797b618@192.168.2.1: 5060 >;audio; video

As described above, the contact header of the registration request message received by the call session controller 200 may be set in the form of "Unique Key @ Message Translation Server IP; Port" including binding information of the message translation server 100. have. Accordingly, the call session controller 200 stores binding information for each unique key of the terminal 10.

When the storage is completed, the call session controller 200 transmits a registration success message "200 OK" to the message conversion server 100 (P130). The "200 OK" message received by the message conversion server 100 is as follows.

<200 OK> (call session control-> message conversion server)

SIP / 2.0 200 OK

Via: SIP / 2.0 / UDP 92.168.2.1:5060;branch=z9hG4bKd5f2dd06df0baba_114b6

From: <sip: 07010002006@sktims.net>; tag = 1bf7

To: <sip: 07010002006@sktims.net>; tag = 2e04074fa6b0e

Contact: < sip: 22f82fa3ee84d01a7edb94eb9797b618@192.168.2.1: 5060 >;audio;video; expires = 3600

As described above, the "200 OK" message transmitted from the call session controller 200 includes a contact header that distinguishes the first terminal 10 by a unique key. Thus, the contact header is set in the form of " unikey @ message conversion server IP; port ".

The message conversion server 100 receiving the "200 OK" message transmits a "200 OK" message to the first terminal 10 (P140). The "200 OK" message received by the first terminal 10 is as follows.

<200 OK> (message conversion server-> first terminal)

SIP / 2.0 200 OK

Via: SIP / 2.0 / UDP 10.10.0.5:5080; received = 222.106.2.9; rport = 4820;

branch = z9hG4bK25dcafbf25dc

From: <sip: 07010002006@sktims.net>; tag = 1bf7

To: <sip: 07010002006@sktims.net>; tag = 2e04074fa6b0e

Contact: < sip: UA@10.10.0.5: 5080 >;audio;video; expires = 3600

As described above, the "200 OK" message transmitted from the message conversion server 100 includes a contact header having the same format as that transmitted from the first terminal 10. Accordingly, the "200 OK" message includes a contact header (UA@10.10.0.5: 5080) that divides the first terminal 10 into UA.

8 is a signal flow diagram of a SIP service system according to another embodiment of the present invention, in which a first terminal 10 located in a private network 1 attempts to make a call to a second terminal 20 located in a public network 3. It is an example.

The first terminal 10 transmits a call request message (INVITE) to the message conversion server 100 through the NAT (50) to attempt a call to the second terminal 20 side (P200). The call request message of the first terminal 10 transmitted to the message conversion server 100 is as follows.

<Call Request Message (INVITE)> (Terminal 1-> Message Conversion Server)

INVITE sip: 07010002006@sktims.net SIP / 2.0

Call-ID: b2486c323576@211.234.210.3

From: <sip: 07010002005@sktims.net>; tag = 0a34

To: <sip: 07010002006@skb.com>

Contact: <sip: UA1@10.10.0.5: 5080> audio; video

The message conversion server 100 receiving the call request message converts the contact header of the call request message using the unique key (84e42559392a6ea6c666946144500e66) stored when the registration request message is processed. The message conversion server 100 changes the user area of the contact header of the call request message to a unique key and changes the host IP to an IP (192.168.2.1) of the message conversion server 100. In addition, the message conversion server 100 converts the call-ID (Call-ID) and the originating tag (From tag) of the call request message to control the call between each terminal (10, 20) in a B2BAU method.

The message conversion server 100 transmits the converted call request message to the call session controller 200 (P210). The call request message INVITE transmitted by the message conversion server 100 is as follows.

<Converted Call Request Message (INVITE)> (Message Conversion Server-> Call Session Control Unit)

INVITE sip: 07010002006@sktims.net SIP / 2.0

Call-ID: 1257394370-1554755174@211.115.7.252

From: <sip: 07010002005@sktims.net>; tag = 190f01c4b91af

To: <sip: 07010002006@skb.com>

Contact: < sip: 84e42559392a6ea6c666946144500e66@192.168.2.1 : 5060>;audio; video

As described above, the call request message transmitted by the message conversion server 100 is transmitted to the call session controller 200 in a state in which the contact header, the call-ID, and the outgoing tag are converted.

The call session controller 200 receiving the call request message retrieves the information of the second terminal 20, which is the called terminal, and transmits the incoming call request message to the message conversion server 100 (P220). The incoming call request message transmitted by the call session controller 200 to the message conversion server 100 in order to deliver the call request message to the second terminal 20 is as follows.

<Incoming call request message (INVITE)> (call session control-> message conversion server)

INVITE sip: 22f82fa3ee84d01a7edb94eb9797b618@192.168.2.1: 5060 SIP / 2.0

Call-ID: 1257394370-1554755174@211.115.7.252

From: <sip: 07010002005@sktims.net>; tag = 190f01c4b91af

To: <sip: 07010002006@skb.com>

Contact: <sip: 84e42559392a6ea6c666946144500e66@192.168.2.1: 5060 >;audio; video ...

As described above, the request-URI (Request-URI) in the incoming call request message transmitted from the call session controller 200 to the message conversion server 100 includes the unique key "22f82fa3ee84d01a7edb94eb9797b618" of the second terminal 20. The contact header includes the unique key "84e42559392a6ea6c666946144500e66" of the first terminal 1. Accordingly, the message conversion server 100 retrieves the binding information corresponding to the unique key of the second terminal 20 from the database 160 and converts the Request-URI into a contact standard format. In addition, since the call must be controlled by the B2BAU method, the call-ID and the call-out tag of the call request message are converted.

The message conversion server 100 transmits the converted incoming call request message to the second terminal (P230). The call request message INVITE transmitted by the message conversion server 100 to the second terminal is as follows.

<Call Request Message Sent to Second Terminal (INVITE)> (Message Conversion Server-> Second Terminal)

INVITE sip: UA2@10.10.0.7: 5080 SIP / 2.0

Call-ID: 1257394370-570562142@211.115.7.252

From: <sip: 07010002005@sktims.net>; tag = 7e1af183ca25a

To: <sip: 07010002006@skb.com>

Contact: <sip: sbc@222.106.2.1: 5060 >;audio; video

As described above, the call request message sent to the second terminal 20 has a Request-URI set to a contact standard format (UA2@10.10.0.7: 5080), and the contact header is a message conversion server ( 100 is set to the contact standard format (sbc@222.106.2.1: 5060).

The second terminal 20 receiving the call request message from the message conversion server 100 transmits a call signal 180 ring to the message conversion server 100 (P240), and the message conversion server 100 controls the call session controller. The call signal (180 Ring) is transmitted to the step 200 (P250). The call session controller 200 receiving the call signal of the second terminal 20 transmits the call signal 180 ring to the message conversion server 100 (P260), and the message conversion server 100 transmits the first terminal ( 10) transmits a call signal (180 Ring) (P270).

The second terminal 20 transmits a "200 OK" message to the message conversion server 100 to accept the call setup request (P280). The "200 OK" message of the second terminal 20 received by the message conversion server 100 is as follows.

<200 OK> (second terminal-> message conversion server)

SIP / 2.0 200 OK

Call-ID: 1257394370-570562142@211.115.7.252

From: <sip: 07010002005@sktims.net>; tag = 7e1af183ca25a

To: <sip: 07010002006@skb.com>; tag = 5017

Contact: <sip: UA2@10.10.0.7: 5080 >

As described above, the second terminal 20 sets the binding information of the contact standard format UA2@10.10.0.7: 5080 in the contact header and transmits the binding information to the message conversion server 100.

The message conversion server 100 receives the "200 OK" message of the second terminal 20 and transmits a "200 OK" message to the call session controller 200 (P290). The message "200 OK" transmitted by the message conversion server 100 is as follows.

<200 OK> (Message Conversion Server-> Call Session Control Unit)

SIP / 2.0 200 OK

Call-ID: 1257394370-1554755174@211.115.7.252

From: <sip: 07010002005@sktims.net>; tag = 190f01c4b91af

To: <sip: 07010002006@skb.com>; tag = 5017

Contact: < 22f82fa3ee84d01a7edb94eb9797b618@192.168.2.1: 5060 >

As described above, the message conversion server 100 sets and transmits the user area of the contact header to the unique key 22f82fa3ee84d01a7edb94eb9797b618 of the second terminal 20.

After receiving the "200 OK" message from the message conversion server 100, the call session controller 200 returns a "200 OK" message having the same content to the message conversion server 100 (P300).

After receiving the "200 OK" message transmitted from the call session controller 200, the message conversion server 100 transmits a "200 OK" message to the first terminal (P310). A "200 OK" message transmitted to the first terminal is as follows.

<200 OK> (message conversion server-> first terminal)

SIP / 2.0 200 OK

Call-ID: 1257394370-1554755174@211.115.7.252

From: <sip: 07010002005@sktims.net>; tag = 190f01c4b91af

To: <sip: 07010002006@skb.com>; tag = 5017

Contact: < sbc@222.106.2.1: 5060 >

As described above, the contact header of the "200 OK" message transmitted to the first terminal is set in the contact standard format (sbc@222.106.2.1: 5060) of the message conversion server 100.

Through the above process, a session is established between the first terminal and the second terminal through the message conversion server 100 and the call session controller 200, and the message is transmitted and received in a B2BAU method (P320). The ACK message is a message transmitted in a subsequence after session establishment and is transmitted in a B2BAU method according to session information.

As described above, the SIP service system according to the present invention receives the registration request message transmitted from each terminal 10, 20 in the message conversion server 100 to generate a unique key, and uniquely the contact header of the registration request message It is converted into binding information of the key and message conversion server 100 and registered in the call session controller 200. The message conversion server 100 stores the unique keys of the terminals 10 and 20 and the contents of the registration request message. The call session controller 200 distinguishes each terminal 10 and 20 by a unique key, and all messages provided by the call session controller 200 to the terminals 10 and 20 are received by the message conversion server 100. Accordingly, the message conversion server 100 delivers the SIP message to each terminal 10, 20 based on the unique key transmitted from the call session controller 200 and the information of the pre-stored registration request message. Therefore, the message conversion server 100 may relay transmission and reception of SIP messages regardless of the network environment of the terminals 10 and 20, such as the private networks 1 and 5, the public network 3, and the like.

As such, those skilled in the art will appreciate that the present invention can be implemented in other specific forms without changing the technical spirit or essential features thereof. Therefore, the above-described embodiments are to be understood as illustrative in all respects and not as restrictive. The scope of the present invention is shown by the following claims rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts should be construed as being included in the scope of the present invention. do.

The SIP service system and its control method according to the present invention are terminals using a SIP (Session Initiation Protocol) regardless of the environment of a public network and a private network to which a terminal belongs in an IP multimedia subsystem (IMS) network. It can be used to register and establish call between terminals.

1: First private network 3: Public network
2: second private network 10: first terminal
20: second terminal 50: NAT (Network Address Translation)
100: message conversion server 110: control unit
120: transmission and reception interface 130: message analysis unit
140: unique key generation unit 150: message conversion unit
160: database 165: binding information table
200: call session control unit

Claims (22)

A terminal for transmitting a registration request message in which terminal binding information including a called address is set;
Receiving the registration request message, generating a unique key of the terminal, transmitting the changed registration request message by changing the terminal binding information to the server binding information which is the unique key and its binding information, and including the unique key; A message conversion server for transmitting the SIP message to a destination address of the terminal by using the terminal binding information corresponding to the unique key when a SIP message is received; and
A session for receiving the changed registration request message from the message conversion server, registering the unique key and the server binding information, and transmitting a SIP message generated based on the unique key to the message conversion server according to the server binding information. SIP service system including a control unit. A transmission and reception interface for transmitting and receiving SIP messages;
Unique key generation unit for generating a unique key based on the information contained in the SIP message; And
When a registration request message of a predetermined terminal is received through the transmission / reception interface, the unique key generation unit is controlled to generate a unique key of the terminal, and the binding information of the terminal included in the registration request message is stored in the unique key and itself. And a control unit which transmits the changed registration request message through the transmission / reception interface by changing to server binding information which is binding information of. The method of claim 2,
The registration request message includes the terminal binding information or a contact header in which the unique key and the server binding information are set.
And the control unit changes the registration request message by changing the terminal binding information stored in the contact header of the registration request message to the unique key and the server binding information. The method of claim 2,
The unique key generation unit,
Characterized by generating a unique key by substituting the public ID and the contact canonical form of the terminal included in the registration request message to the Message-Digest algorithm 5 (MD5) hash function (MD) Message Conversion Server. The method of claim 2,
The terminal further comprises a unique key, a public ID included in the registration request message, a contact canonical form, a receiving IP, and a database storing receiving port information. Transformation server. The method of claim 5,
The control unit,
When a re-registration request message of a predetermined terminal is received through the transmission / reception interface, the unique key of the terminal is retrieved from the database based on information included in the re-registration request message, and the re-registration request message is included. And converting the binding information of the terminal into the searched unique key and the server binding information and transmitting the changed registration request message through the transmission / reception interface. The method of claim 5,
The control unit,
When a call request message of a predetermined terminal is received through the transmission / reception interface, the terminal searches for information on the terminal corresponding to the unique key from the database based on the unique key included in the call request message, and the call request is performed according to the retrieved information. The message conversion server, characterized in that for changing the message to send the changed call request message to the receiving IP and the receiving port of the terminal. Transmitting, by the terminal, a registration request message in which terminal binding information including a called address is set;
Receiving the registration request message at a message conversion server to generate a unique key of the terminal, and storing information of the registration request message and a unique key of the terminal;
Changing, by the message conversion server, the terminal binding information of the registration request message to the server binding information which is the unique key and its own binding information, and transmitting the changed registration request message to request registration of the terminal;
Receiving the changed registration request message at a call session controller, registering the unique key and the server binding information, and transmitting a SIP message generated based on the unique key to the message conversion server according to the server binding information;
Receiving the SIP message at the message conversion server and converting the SIP message according to the information of the registration request message of the terminal corresponding to the unique key; And
And transmitting the converted SIP message to the destination address included in the terminal binding information. The method of claim 8,
Generating the unique key of the terminal in the message conversion server,
And generating the unique key by substituting a public ID and a contact canonical form included in the registration request message into a message-digest algorithm 5 (MD5) hash function. SIP service method. The method of claim 8,
In the message conversion server, changing the terminal binding information of the registration request message to server binding information including the unique key and its destination address,
Changing the terminal binding information stored in the contact header of the registration request message to the unique key and the server binding information. The method of claim 8,
In NAT (Network Address Translation), further comprising assigning a private IP address as a destination address of the terminal and assigning a public IP address to the registration request message sent by the terminal to transmit to the message translation server. SIP service method. The method of claim 8,
The transmitting of the converted SIP message to the destination address included in the terminal binding information may include:
And transmitting the converted SIP message to a destination address of the terminal set as a private IP. Receiving a registration request message in which terminal binding information including a destination address of the terminal is set;
Generating a unique key based on information included in the registration request message;
Storing the information of the registration request message and the unique key;
Converting the terminal binding information included in the registration request message into the unique key and server binding information;
Transmitting the converted registration request message; and
And when the SIP message including the unique key is received, searching for information on the registration request message of the terminal corresponding to the unique key and transmitting the SIP message to a destination address of the terminal. Way. The method of claim 13,
Generating the unique key based on the information included in the registration request message,
And generating the unique key by substituting a public ID and a contact canonical form of a terminal included in the registration request message into a message-digest algorithm 5 (MD5) hash function. Method of controlling a message conversion server, characterized in that. The method of claim 13,
Storing the information of the registration request message and the unique key,
And storing the unique key, a public ID included in the registration request message, a contact canonical form, a receiving IP, and receiving port information. Control method. The method of claim 13,
Converting the terminal binding information included in the registration request message into the unique key and server binding information,
And changing the terminal binding information stored in the contact header of the registration request message to the unique key and the server binding information. The method of claim 13,
Extracting terminal binding information included in the re-registration request message when a re-registration request message included in the registration request message is received;
Retrieving a unique key corresponding to the terminal binding information from previously stored information;
Converting the terminal binding information included in the re-registration request message into the retrieved unique key and server binding information; and
The control method of the message conversion server further comprising the step of transmitting the converted registration request message. The method of claim 13,
Extracting terminal binding information included in the call request message when a call request message included in the registration request message is received;
Retrieving a unique key corresponding to the terminal binding information from previously stored information;
Converting the terminal binding information included in the call request message into the retrieved unique key and server binding information; and
And transmitting the converted call request message. The method of claim 18,
And converting the call-ID and the out tag included in the call request message into a form capable of controlling B2BUA (Back-To-Back User Agent). . The method of claim 13,
If an incoming call request message is received, extracting a unique key of a called terminal included in the incoming call request message;
Retrieving terminal binding information of a called terminal corresponding to the unique key from previously stored information;
Converting a destination address included in the incoming call request message into terminal binding information of the called terminal;
And transmitting the converted call request message to a destination address of the called terminal. The method of claim 20,
The control of the message conversion server, characterized in that further comprising the step of converting the call-ID and the outgoing tag (From tag) included in the incoming call request message to a form capable of B2BUA (Back-To-Back User Agent) control Way. The method of claim 13,
The step of transmitting the SIP message to the destination address of the terminal,
And transmitting the SIP message to a destination address of the terminal set as a private IP.

Images