KR20130085556A - Method for authenticating of message and ip-pbx system for the same - Google Patents

Abstract

PURPOSE: A method for message authentication and an IP-PBX system for the same are provided to perform message authentication that is suitable for detecting packet interception and/or replay attack using a source IP address. CONSTITUTION: An IP-PBX system (200) comprises a call server (210) for call processing, a plurality of non-NAT (non-network address translation) routers (220,240), an NAT router (230), a simple traversal of user datagram protocol through NATs (STUN) client (250), an IP phone (260), and various gateways (270,280) including a station line or private branch gateways. The IP-PBX system has a client-to-server structure having the call server at the center. A call signaling for call processing is carried out between the call server and the IP phone, which is a client, or among the call server and gateways. A server integration of the call server and a STUN server and a channel integration of a message channel for call processing and a STUN message channel are required for bidirectional communications among the call server, the IP phone, and the gateways in the NAT environment.

Description

Message authentication method and IP-PB system for it {METHOD FOR AUTHENTICATING OF MESSAGE AND IP-PBX SYSTEM FOR THE SAME}

The present invention provides a message authentication method for detecting integrity of packets transmitted and received between voice over internet protocol (VoIP) devices in a network address translation (NAT) environment, in particular, packet interception and retransmission attacks using a source IP address, and a method for the same. It relates to an IP-PBX system.

Network Addressable Translation (NAT) is a network address translator used to translate private IP addresses into public IP addresses at the network layer, the third layer of the OSI (open system interconnection) model. Is limited, so it is necessary to be able to share it as much as possible. By using NAT, you can use private IP addresses and convert them with public IP addresses, which can be saved by allowing multiple public IP addresses to be used together. It is.

Packet communication in a NAT environment disables bidirectional packet exchange between network devices in certain configurations due to address translation in the NAT router. As a method to partially solve this problem, a simple traversal of UDP through NATs (STUN) protocol has been proposed.

1 to 4 are exemplary views showing the configuration of an IP-PBX system.

The STUN system is composed of a STUN server 10 having a public IP address and a STUN client 40 having a private IP address installed behind the NAT router 30. Packets sent to the outside by the STUN clients 40 are mapped to a Transport Layer (TCP or UDP) port number that is dynamically allocated along with the public IP address of the NAT router 30 through the NAT router 30. do. As an example, if a packet sent from STUN Client-1 40a had source IP address 192.168.100.1 and source UDP port number 1000, then the packet would pass through NAT Router-1 30a and the source IP address would To 110.110.110.1 and the source UDP port number is dynamically assigned (eg 2000) so that the source UDP port number is changed to the dynamically assigned value.

Since this address translation is performed when the first packet transmitted from the STUN client 40 passes through the NAT router 30, a mapping table entry is generated. Thus, STUN Client-1 (40a) and STUN Client-2 ( 40b) does not know in advance which IP address and port number will be mapped, and for this reason it is impossible to send a packet directly to the other party.

The STUN client 40 installed behind the NAT router 30 sends a binding request message to the STUN server 10 to obtain its NAT mapping information. The STUN server 10 sends a MAPPED-ADDRESS field. The IP address / port number mapped and changed by the NAT router 30 is input to transmit a binding response message to the STUN client 40 to provide address mapping information. Therefore, the STUN client 40 can go through this process to know which IP address and port number the packet transmitted to the outside is mapped to.

NAT is largely classified into Cone NAT and Symmetric NAT. In Cone NAT, packet exchange can be performed regardless of the other party's IP address and port as long as the STUN client's source IP and port are the same. In Symmetric NAT, address mapping is performed for a specific source IP address and port and destination IP address port. Therefore, different mappings are made for different destination IP addresses and ports.

As an example, in the case of Cone NAT, 110.110.100.1:2000, which is an address mapping generated when the STUN client-1 (40a) is transmitted from the 192.168.100.1:1000 of the STUN server 10 as described above, to the STUN client- A packet transmitted from STUN client-2 40b to 110.110.100.1:2000 may also be delivered to STUN client-1 40a, as applied to packets from two 40b.

In the case of Symmetric NAT, the existing address mapping 110.110.110.1:2000 is for the packet between 192.168.100.1:1000 of STUN client-1 (40a) and STUN server 10, so it is 110.110 from STUN client-2 (40b). A packet transmitted to .110.1.: 2000 is discarded from NAT router-1 30a because there is no address mapping table entry on NAT router-1 30a.

Since a symmetric NAT is generally used rather than a Cone NAT in a real network environment, the scope of application of the STUN protocol is limited to some extent, and there is a problem in that it is a limiting factor in the installation and operation of VoIP devices.

Korean Patent Publication No. 10-2004-0058641 (published Jul. 5, 2004)

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to packet security. The present invention relates to integrity checking of packets transmitted and received between voice over internet protocol (VoIP) devices in a network address translation (NAT) environment, particularly for detecting packet interception and retransmission attacks using source IP addresses. A message authentication method and an IP-PBX system therefor are provided.

The IP-PBX system of the present invention integrates a STUN server and a call server so that the STUN (Simple Traversal of UDP Through NATs) protocol and the communication protocol for call processing use the same communication channel to perform authentication of an IP address-based message. .

In addition, the message authentication method of the present invention comprises the steps of: a) integrating a STUN server and a call server such that a simple traversal of UDP Through NATs (STUN) protocol and a communication protocol for call processing use the same communication channel; And b) authenticating an IP address-based message using the integrated STUN server and call server.

According to the present invention, an appropriate message authentication is performed to detect packet interception / retransmission attacks using integrity check of packets transmitted and received between VoIP devices in a network address translation (NAT) environment, especially source IP address. can do.

1 to 4 are exemplary views showing the configuration of an IP-PBX system.
5 and 6 are exemplary views showing a message authentication method according to an embodiment of the present invention.
7 to 10 are exemplary views showing the configuration of an IP-PBX system according to an embodiment of the present invention.
11 is an exemplary view showing a method of classifying packets according to an embodiment of the present invention and distributing them to a call processing module and a STUN processing module.
12 is an exemplary view showing a configuration of a virtual protocol packet header according to an embodiment of the present invention.
13 to 16 are exemplary views showing the configuration of an IP-PBX system according to an embodiment of the present invention.
17 is an exemplary view showing a message transmitted and received between the STUN server and the client according to an embodiment of the present invention.
18 is an exemplary view showing a configuration of a virtual protocol packet header according to an embodiment of the present invention.
19 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.
20 is an exemplary view showing a message transmitted and received between the STUN server and the client according to an embodiment of the present invention.
21 is an exemplary view showing a message flow in a client according to an embodiment of the present invention.
22 is an exemplary view showing a message flow in a server according to an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, well-known functions or constructions will not be described in detail if they obscure the subject matter of the present invention.

Message Authentication is a method of checking the integrity of a message. Instead of encrypting the message itself, Message Authentication calculates the code value specific to the message using a hash function for the message. . To calculate the code value, a secret key is required, and network devices sharing the same secret key use the same calculation on the transmitted message to check whether the message reaches the receiver as sent by the sender. . Various cryptographic hash functions (Cryptographic Hash Function) can be used to calculate the message authentication code (MAC), and various methods can be used to exchange secret keys. This embodiment is applicable regardless of a specific hash function or secret key exchange method.

5 is an exemplary view showing a message authentication method according to an embodiment of the present invention.

Referring to FIG. 5, when a message is changed in the middle, the MAC value calculated and inserted by the sender and the MAC value calculated by the receiver are different, and thus the receiver may detect the message. Since this MAC value is calculated as a secret key value that is shared only between the sender and the receiver, other network devices can intercept the message and calculate and reinsert the correct MAC value after changing the message. Since message authentication reduces the load on the network device rather than encrypting the message, integrity checking is used alone when sufficient, and encryption is sometimes used in conjunction with encryption because it does not guarantee integrity.

6 is an exemplary view showing a message authentication method according to an embodiment of the present invention.

Referring to FIG. 6, when the MAC is calculated using the sender's source IP address, a third party intercepts the packet in the middle, changes the packet, transmits the packet again, and then detects an attack of receiving a packet leading to its own IP address. You can do it. To do this, you can always include the source IP address in the message, but in this case you need to send additional source IP addresses unnecessarily, so you can use a secret key and source IP address to generate a new key value. . The receiving side extracts the source IP address from the IP header of the received packet, generates a new key value like the sender, and calculates and compares the MAC.

-Source address based message authentication in NAT / STUN environment

7 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

In a NAT environment, the source IP address of a packet sent by the sender device is changed by the NAT router, so if the sender device uses its own IP address (typically a private IP address) to compute the MAC, the receiver will use the NAT router. Message authentication fails because the MAC is calculated using the source IP address (generally the public IP address) in the IP header changed by (30). Therefore, in a NAT environment, a MAC is calculated using a mapped address (MAPPED-ADDRESS) transmitted through a binding response from a STUN server 10 using STUN, and then a peer PC 60 as a destination. Since the packet is forwarded to the packet, and the mapped address is the same as the source IP address changed by the NAT router 30, message authentication at the receiving peer PC 60 succeeds.

8 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

As shown in FIG. 8, when NAT routers 30a and 30b are connected in series, message authentication may not be normally performed. When the STUN client 40 receives the binding response from the STUN server 10, the mapped address has the source IP changed by NAT router-1 30a, the final NAT router between the STUN client 40 and the STUN server 10. The address is included. Therefore, the MAC address in STUN client 40 uses the mapped address, but in the case of peer PC-1 60a located inside NAT router-1 30a, the final NAT router, NAT router-2 ( Message authentication fails because the MAC is calculated from the source IP address changed in 30b).

9 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

As shown in FIG. 9, the IP-PBX system 200 includes a call server 210, non-NAT routers 220 and 240, a NAT router 230, and a STUN client (Call Server) for call processing. Various types of gateways 270 and 280 including 250, IP telephone 260, trunk line or extension gateway, and the like. The IP-PBX system 200 has a client / server structure around the call server 210. Call signaling for call processing is performed only between the call server 210 and the client IP phone 260 or gateways 270 and 280.

For two-way communication between the call server 210 and the IP phone 260 or gateways 270 and 280 in a NAT environment, STUN server integration and call processing message channel and STUN message channel to the call server 210 without limitation of the existing technology. Need integration.

The limitation of Cone NAT environment among NAT types can be solved by using the existing STUN protocol. However, in case of commonly used Symmetric NAT, STUN protocol cannot be used. To solve this problem, IP address and port of STUN server are solved. The number must match the IP address and port number of the actual destination network device.

10 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

As shown in FIG. 10, in order to allow the same communication channel to be shared between the call processing message and the STUN message, the STUN server must be integrated with the call server, and the STUN protocol itself can be connected to a communication channel such as a VoIP call signaling protocol. Should be integrated for use. In this method of integration, a module for call processing and a STUN processing module are separately operated, and the packets are divided and distributed in front of these two modules, and the STUN protocol message itself is integrated into a communication protocol for call processing. There may be a way to implement it.

The method of classifying packets and distributing them to the call processing module and the STUN processing module is suitable for standard VoIP signaling protocols such as Session Initiation Protocol (SIP). Classify and distribute. This method is inefficient because the system load is required to classify and distribute the message, but it can be applied without modifying the existing standard VoIP protocol. If it can't be modified, it can be the only way to implement it. 11 illustrates a method of dividing packets into a call processing module and a STUN processing module.

In case of using non-standard (proprietary) protocol by VoIP equipment manufacturer, it is efficient to integrate all or part of STUN protocol.

12 is an exemplary view showing a configuration of a virtual protocol packet header according to an embodiment of the present invention.

As shown in FIG. 12, the virtual protocol packet header has a format for exchanging data and meaning of a call processing message for each protocol. Among these, a field for indicating a type and type of a message may be additionally defined to define items for a STUN message. Can be. Using this method, it is tightly coupled with the existing VoIP signaling protocol so that an overload does not occur so that call processing and STUN messages can be integrated.

In the case of message authentication, when a new hash function key value is generated by combining a secret key and a source IP address, an authentication failure may occur when using an existing technique. Some of these cases are solved by integrating the call server with the STUN server.

13 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

As shown in FIG. 13, since the call server and the STUN server are integrated, a binding response including an appropriate mapped address is transmitted to the STUN client regardless of a binding request sent from any location of the NAT environment. In the case of IP-telephone-1 340a and IP-telephone-2 340b, both are mapped in NAT-router-2 330b to receive the changed IP address as the mapped address. In the case of 340c), the changed IP address mapped to the NAT-router-3 330c is received. However, introducing additional elements and changing the configuration may not solve even the integration of the call server and STUN server.

14 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

As shown in FIG. 14, in the case of a VoIP-based IP-PBX system, although it is located on a public domain and gives a public IP for packet communication with the outside, a NAT-based firewall ( The firewall 420a may be installed in front of the call server 410. In this case, due to the dynamic NAT mapping problem, packet communication with the outside cannot be performed. Port forwarding is set in the NAT router (firewall) 420a to enable packet communication. This indicates that only the destination address is changed and transmitted to port 1000 of the NAT server (firewall) IP address 110.100.100.50 to port 1000 of the 192.168.100.50 IP address of the call server 410. Therefore, in this case, the devices in the remote network know the address of the call server 410 as 110.100.100.50:1000 and transmit the packet, and the IP-telephone-2 in the call server network-2 In the case of 430b, the packet is transmitted to the original call server 410 IP address 192.168.100.50:1000.

FIG. 15 is a view illustrating an IP-PBX system according to an embodiment of the present invention, wherein a packet transmitted from an IP-telephone-1 530a to a NAT router (firewall) 520a 110.100.100.50:1000 is port-transmitted to the call server 510. ) Is the process of translating and forwarding an IP address to 192.168.100.50:1000.

16 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

In the MAC calculation of the packet transmitted from the reverse call server to the IP-phone as shown in FIG. 16, the source IP for the MAC calculation for IP-telephone-1 630a located outside the NAT router (firewall) 620a. The address must apply the IP address translated from NAT router (firewall) 620a, and the original call server 610 IP address for IP-telephone-2 (630b) located inside NAT router (firewall) 620a. Should be applied when calculating MAC. Since the existing STUN protocol transmits only the mapped IP address of the STUN client through the mapped address, NAT mapping information on the STUN server 610 side is not exchanged. Therefore, the STUN server 610 side determines the NAT environment for itself. Can not. This is a limitation of the STUN protocol itself. To solve this problem, additional fields must be defined and passed from the STUN client to the STUN server 610. In other words, there is a need for a method capable of delivering information on the NAT-mapped address of the STUN server 610 from the STUN client side to the STUN server 610.

Information delivery about NAT-mapped addresses includes a method of defining an additional STUN message and a method of delivering the information through the first message of VoIP call signaling (in most cases, a device registration message) after the STUN message exchange.

17 is an exemplary view showing a message transmitted and received between the STUN server and the client according to an embodiment of the present invention.

As shown in FIG. 17, additional STUN message definitions for the delivery of information about NAT-mapped addresses are appropriate for standard VoIP protocols such as SIP, which are not easy to modify the VoIP signaling protocol, and are called new messages called Binding Reports. To make the STUN client (SC) send to the STUN server (SS). The STUN client (SC) includes source IP information extracted from the IP header of the binding response packet received from the STUN server (SS) together with its mapped address received from the binding response in a new field called SERVER-MAPPED-ADDRESS. Deliver to server (SS) side. SERVER-MAPPED-ADDRESS contains the result of address translation from the NAT router (firewall) of the binding response message sent from the STUN server (SS), so that the STUN server (SS) is able to resolve its NAT to a specific mapped address. The IP address is known.

18 is an exemplary view showing the configuration of a virtual protocol packet header according to an embodiment of the present invention.

As shown in FIG. 18, in the case of the registered VoIP signaling protocol, a new command or event called a binding report is defined in a STUN message type, and an address mapped in the binding report message is defined. Include and send the SERVER-MAPPED-ADDRESS field.

19 is an exemplary view showing the configuration of an IP-PBX system according to an embodiment of the present invention.

As shown in FIG. 19, when the call server (STUN server) 710 receives the binding report message, the call server (STUN server) 710 stores and manages SERVER-MAPPED-ADDRESS information for a specific mapped address separately, and manages IP-telephone and gateway (STUN client). The MAC is calculated using the corresponding SERVER-MAPPED-ADDRESS when sending a packet to the network.

As described so far, the integration of call and STUN servers, sharing of packet communication channels, binding reports and additional definitions of SERVER-MAPPED-ADDRESS are necessary elements for source IP address-based message authentication of VoIP devices in a NAT environment. Are explained.

The operation of protocol using STUN message and call processing message is as follows. The conventional STUN message was intended to deliver NAT mapping information to the STUN client side, but in the present invention, the STUN message transmits NAT mapping information to each of the client and the server, and at the same time, a packet for call processing message exchange that is made later. The purpose is to establish a communication path.

An address mapping table entry is created at the NAT router on the client side while sending a binding request from the client device such as an IP-phone or a gateway to the call server (STUN server). The same packet communication channel is generated.

In this embodiment, the NAT communication channel generated through the STUN message exchange is used as it is for the call processing message, and the flow of messages related thereto is as follows.

20 is an exemplary view showing a message transmitted and received between the STUN server (SS) and the client (SC) according to an embodiment of the present invention.

As shown in FIG. 20, when the binding request message is transmitted from the IP phone / gateway SC to the call server SS (S110), the IP address is changed when the packet is sent while passing through the client-side NAT router. An address mapping table is generated at the NAT router to create a NAT packet communication channel between the IP phone / gateway (SC) and the call server (SS). The STUN processing module of the call server SS inserts the changed IP address into the MAPPED-ADDRESS field and transmits a binding response message to the IP phone / gateway SC (S120). The IP-telephone / gateway (SC) extracts the source IP address from the IP header of the binding response message packet and inserts it in the SERVER-MAPPED-ADDRESS field and transmits the binding report message to the call server SS (S130).

At the same time a NAT packet communication channel is established between the IP phone / gateway (SC) and the call server (SS), both sides receive and store NAT address mapping information for themselves. In general, NAT routers delete the mapping table entries after about 3 to 5 minutes, although they vary slightly from product to product since the last packet has passed through the created NAT-mapped channel. That is, if there is no traffic to the channel for 3 to 5 minutes, the NAT matching channel is released. Therefore, it is necessary to periodically transmit packets to maintain the NAT mapping table inside the NAT router.

Therefore, the time between the exchange of STUN messages and the exchange of call processing messages must be within this time limit, and the NAT mapping must be maintained using device polling messages afterwards.

In most cases immediately after the STUN message exchange, the call processing message will be exchanged, but even if the exchange of the call processing message is not feasible, the present invention recommends that the call processing message exchange be started within 1 minute. If the call processing message could not be sent within this time, the STUN message exchange process starts again.

In the case of a VoIP-based IP-PBX system, message exchange is performed only when a call is generated or when control information such as LCD / LED is required. Therefore, there may be no packet exchange for more than 5 minutes when NAT mapping is released. In such a case, the device polling message is transmitted in a period of 1 minute or less to maintain NAT mapping. If the IP-PBX system already has a device polling message scheme (Scheme), the interval is less than 1 minute. Set it to be.

The overall flowchart for each of the client device such as an IP-telephone / gateway and the server device such as a call server is shown in FIGS. 21 and 22.

Each flowchart shows the flow of the process leading to STUN message exchange and call processing message exchange. However, the process after device registration may be different for each product and is briefly indicated because it is outside the scope described in the present invention.

21 is an exemplary view illustrating a message flow in a client according to an embodiment of the present invention.

As shown in FIG. 21, the client device such as an IP-telephone / gateway starts to exchange STUN messages after initialization. First, it sends a binding request message to the call server and waits for a binding response message to be received. If it does not come within one minute, it is determined that the packet is missing or there is a temporary problem with the call server, and resends the binding request message, and when a binding response message is received, it locates and stores the mapped address inside the message for future MAC processing of the call processing message. use. In addition, the source IP address of the binding response packet is extracted and put in the SERVER-MAPPED-ADDRESS field and transmitted to the call server with its mapped address.

Subsequently, for the device registration request call processing message to be transmitted, a new key value is generated by combining the mapped address and the secret key received and stored in the binding response, and the MAC is calculated and transmitted to the call server. When the device registration request message is received from the call server, the MAC is checked. If the generated key value is incorrect, the call server starts again from the binding request message transmission step. If the message authentication succeeds with the generated key value, the call processing process is started, and the device polling acknowledgment message is responded to the periodic device polling message, and the message authentication using the MAC is performed for all received messages.

22 is an exemplary view illustrating a message flow in a server according to an embodiment of the present invention.

As shown in FIG. 22, when the call request message is received, the call server extracts the source IP address from the IP header of the packet, constructs a MAPPED-ADDRESS field, and transmits it to the client through the binding response message. Wait for 1 minute to receive the binding report message. When the binding report message is received, the mapped address and the SERVER-MAPPED-ADDRESS field are checked to store and manage the corresponding address mapping information.

After the device registration request message is received, the MAC is examined and message authentication is performed. If the authentication fails, all processes are invalidated and the process returns to the step of waiting for the reception of the binding request message. If the message is normally authenticated, the device is allowed to register by sending a Device Registration Response message, then the call processing process is performed, and periodic device polling and message authentication using MAC for all call processing messages are performed. .

Although the present invention is designed for a VoIP-based IP-PBX system, it can be modified and applied to other client / server systems that require source address-based message authentication in a NAT environment.

While the above methods have been described through specific embodiments, the methods may also be implemented as computer readable code on a computer readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and may be implemented in the form of a carrier wave (for example, transmission over the Internet) . In addition, the computer-readable recording medium may be distributed over network-connected computer systems so that computer readable codes can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the above embodiments can be easily deduced by programmers of the present invention.

Although the present invention has been described in connection with some embodiments thereof, it should be understood that various changes and modifications may be made therein without departing from the spirit and scope of the invention as understood by those skilled in the art. something to do. It is also contemplated that such variations and modifications are within the scope of the claims appended hereto.

10, 210, 310, 410, 510, 610, 710: STUN server
20, 50, 220, 240, 320: non-NAT router
30, 230, 330, 420, 520, 620, 720: NAT router
40,250: STUN Client 60: Peer PC
260,340,430,530,630,730: IP Phone 270,280: Gateway
SC: IP Phone / Gateway SS: Call Server

Claims (20)

As an IP-PBX system,
An IP-PBX system that performs authentication of IP address-based messages by integrating a STUN server and a call server such that the Simple Traversal of UDP Through NATs (STUN) protocol and the communication protocol for call processing use the same communication channel. The method of claim 1,
Integration of the STUN server and the call server,
And separately operating and distributing packets in front of the module for call processing and the module for STUN processing and the module for call processing and the module for STUN processing. The method of claim 2,
Classification and distribution of the packet,
IP-PBX system using the difference in the packet form of the STUN protocol and the communication protocol for the call processing. The method of claim 3,
IP-PBX system integrating all or necessary portions of the STUN protocol when using a non-Standard / Proprietary protocol by VoIP equipment manufacturers as the communication protocol for the call processing. The method of claim 1,
Integration of the STUN server and the call server,
Integrating and performing the STUN protocol message with the communication protocol for call processing to integrate the STUN server and the call server. The method of claim 5,
The method of integrating the STUN protocol message into a communication protocol for the call processing,
And further defining a field for the STUN protocol message in a field indicating a message type and a type of a communication protocol packet header for call processing. The method of claim 1,
When installing a network address translation (NAT) -based firewall in front of a call server, IP-PBX system for transmitting information about the NAT-mapped address on the STUN server side from the STUN client to the STUN server. The method of claim 7, wherein
Information about the NAT mapped address,
An IP-PBX system, further defining a STUN message and forwarding from the STUN client to the STUN server. 9. The method of claim 8,
The additionally defined STUN message is
And a source IP information extracted from its mapped address received by the STUN client and an IP header of a packet received from the STUN server, in the new field. The method of claim 7, wherein
Information about the NAT mapped address,
IP-PBX system for transferring from the STUN client to the STUN server using the first message of signaling for call processing after the STUN message exchange. As a message authentication method,
a) integrating the STUN server and the call server such that the Simple Traversal of UDP Through NATs (STUN) protocol and the communication protocol for call processing use the same communication channel; And
b) performing authentication of an IP address based message using the integrated STUN server and call server. 12. The method of claim 11,
The step a)
And separately operating a module for call processing and a module for STUN processing and separating and distributing packets in front of the module for call processing and the module for STUN processing. The method of claim 12,
The step a)
And classifying and distributing the packets using a difference between packet types of the STUN protocol and a communication protocol for call processing. The method of claim 13,
The step a)
Integrating all or necessary portions of the STUN protocol when using a non-Standard / Proprietary protocol by VoIP equipment manufacturers as the communication protocol for the call processing, Message authentication method. 12. The method of claim 11,
The step a)
Incorporating the STUN protocol message into a communication protocol for call processing to integrate the STUN server and the call server. 16. The method of claim 15,
The step a)
And defining a field for the STUN protocol message in a field indicating a message type and a type of a communication protocol packet header for the call processing. 12. The method of claim 11,
The step a)
If a network address translation (NAT) -based firewall is installed in front of the call server, transmitting the information about the NAT mapped address on the STUN server side from the STUN client to the STUN server. 18. The method of claim 17,
The step a)
And further defining a STUN message to convey information about the NAT mapped address from the STUN client to the STUN server. 19. The method of claim 18,
The step a)
And transmitting the source IP information extracted from the mapped address received from the STUN client and the IP header of the packet received from the STUN server to the STUN server by including it in a new field of the additionally defined STUN message. Message authentication method. 18. The method of claim 17,
The step a)
And transmitting information on the NAT mapped address from the STUN client to the STUN server using the first message of signaling for call processing after the STUN message exchange.

Images