KR100838811B1 - Secure session border controller system for voip service security - Google Patents

Abstract

A secure SBC for a safe VoIP(Voice over Internet Protocol) service is provided to ensure call availability in an existing Internet network by providing the VoIP service even in a private IP(Internet Protocol) through an NAT/FW pass function, and to protect equipment within a network by providing a network covert function. A session control module controls session generation, management and data exchange between terminals. The session control module comprises an SIP(Session Initiation Protocol) signaling control server(101), a media relay management server(102) and a media relay worker server(103). A secure module detects and intercepts a malicious call and media. The secure module comprises an SIP detector(104), an SIP filter(105), a media detector(106), a media filter(107) and a policy manager(108). A management module manages element of a system, and reports information about the system. A database(111) stores and manages information so as to assign basic information of detection and interception and to reflect current system resource state information to a secure policy. The management module comprises the followings. An EMS(Element Management System)(109) manages a network of a secure SBC(Session Border Controller) system and manages and operates system elements. An EVTS(Event Server)(110) collects log or state information of each element of the system, and reports the information so as to be reflected to the policy manager.

Description

Secure Session Border Controller System for VoIP Service Security

1 is a block diagram of an apparatus for secure session control of the present invention;

2 is a functional configuration diagram of a security session control apparatus of the present invention;

3 illustrates a detailed configuration of the SSCS and an interface with related modules;

4 is a detailed configuration diagram of a session manager;

5 is a flow chart of SIP message processing in SSCS;

6 illustrates an interface between an MRMW and associated modules;

7 is a data flow diagram in MRMS,

8 illustrates a detailed configuration of an MRWS and an interface with related modules;

9A and 9B are data flow diagrams in MRWS;

10 illustrates a detailed configuration of a policy manager and an interface with related modules;

11 illustrates a functional configuration of a policy manager and an interface with related modules;

12 illustrates a detailed configuration of MGATE and an interface with related modules;

13 is a diagram showing an interface with a detailed module and a related module of a detailed configuration of MGATE;

14 is a data flow diagram in a SIP detector and filter;

15 is a data flow diagram in a SIP detector;

16 is a data flow diagram in MGATE;

17 is a data flow diagram in the MGATE detector.

The present invention relates to a session border controller (SBC) for VoIP services, and more particularly, to a secure session control apparatus for a VoIP service that provides a session control function, an SBC system protection function, and a VoIP denial of service attack response function. Secure SBC).

In the conventional session control system, VoIP traffic does not pass through the firewall and Network Address Translation (NAT) due to issues such as the use of private IP addresses and UDP ports and dynamic allocation of ports. There were vulnerabilities that could not be guaranteed or would not be able to review the security of traffic that bypasses the firewall.

Therefore, various methods for session control aimed at NAT / FW traversal and concealment of network structures have been proposed in various ways such as application level gateway, MIDCOM, and SBC. Among these, the SBC system is the most preferred method for current service providers because NAT / FW traversal problem can be solved without changing the existing network configuration and function and bottlenecks or delays do not occur.

However, the existing SBC system is primarily intended for session control for private IP use, and does not have a VoIP service protection function or provides only basic functions, thereby threatening attacks on SBC systems and VoIP services described below.

Invite Request Flooding attack uses VoIP vulnerability scanner (SiVuS, Ethereal, Cain) to scan major system such as SIP server in specific network band, and then sends a large number of valid request messages (SIP INVITE). By preparing a response message to this, it depletes the resources of the SBC to prevent normal service.

 Media flooding (media flooding or RTP flooding) attacks capture the user's RTP message to obtain the user's IP address and port number, and then generate and send a large number of malicious RTP messages to induce the SBC to process a large amount of data. Cause disability.

In RTP injection attack, the attacker monitors the RTP signal through sniffing and checks the UDP port number and the synchronization source (SSRC) used by the target to guess the increase. When the next session is created, the attack interrupts the call by generating / transmitting a malicious packet along with the normal packet during the call to handle the media traffic of the attacker.

Attacks through message manipulation are typical SIP SQL injection attacks. The attack by SIP SQL injection inserts the manipulated SQL query syntax into the Authorization Header of the SIP message to the SIP Proxy that authenticates using the HTTP Digest mechanism to register the specific user in the database that contains the subscriber information. It is an attack that manipulates, adds, or deletes information.

In addition, VoIP-related threats include system failure attacks that exploit vulnerabilities in OS and security patches. An attacker collects information through accessible system scanning, intrudes the system using OS vulnerabilities, application vulnerabilities, and incorrect configuration, and then causes system failure by changing the access configuration or password to the system with administrator privileges. do.

The present invention has been proposed to solve the above problems, and an object of the present invention is to provide a secure session control apparatus (Secure SBC) for a VoIP service that provides a session control function, SBC system protection function and VoIP denial-of-service attack response function. to be.

The present invention for achieving the above object, the session control module for controlling the creation, management and exchange of data between the terminal; A security module to detect and block malicious calls and media; A management module for managing the components of the system and reporting information of the system; And a DB for assigning basic information of detection and blocking and storing and managing the current system resource state information to be reflected in a security policy.

Hereinafter, a secure session control apparatus (Secure SBC) for VoIP service of the present invention will be described with reference to the accompanying drawings.

The present invention relates to a secure session control apparatus that provides a session control function, an SBC system protection function, and a VoIP denial of service attack response function for a VoIP service.

1 is a configuration diagram of a security session control apparatus of the present invention, Figure 2 is a functional configuration diagram of a security session control apparatus of the present invention, the security SBC of the present invention is largely divided into a session control module, a security module, a management module and a DB do.

Session control module

The session control module includes a SIP signaling control server (SSCS) 101, a media relay management server (MRMS) 102, and a media relay worker server (MRWS) 103. It consists of.

The SSCS 101 is a module for receiving call signals and processing them to manage call setup. The SSCS 101 performs basic validation checks on SIP messages and allows NAT / FW to pass through the B2BUA function. In addition, when call setup is normally performed, information is transmitted to the MRMS 102 to generate a media channel for the call through signaling.

In this case, the B2BUA function is a function of performing a role of a sender and a receiver, and forms a session with a calling terminal, a B2BUA agent, a B2BUA agent, and a receiving terminal. While the byte message from the terminal passes through NAT, the IP / Port is changed, but the channel information in SDP uses a virtual IP / port. SBC interprets this information and maps the mapping table. Create a session to support the normal creation and transfer of data. For the B2BUA function of SBC, SBC equipment is located at the forefront of a specific network to map IP / ports and induce call processing. Therefore, SBC is located at the forefront of the service network. It hides the location, which hides the network.

The MRMS 102 is a module for managing a voice media channel based on the call information received from the SSCS 101, and allocates and removes a media bind port to the MRWS 103. In addition, through periodic communication with the MRWS 103, the channel is allocated / deleted according to the call state, and the channel is managed such as checking whether the remaining channel is allocated.

The MRWS 103 exchanges media data (RTP) of a terminal when a session is connected between SIP terminals and a call is made through RTP / RTCP.

Security module

The security module consists of a SIP detector 104, a SIP filter 105, a media detector 106, a media filter 107, and a policy manager 108.

When the call signal is input to the SSCS 101, the SIP detector 104 checks the validity of the call and identifies the pattern of the call signal and transmits it to the policy manager 108 to check whether there is an abnormality. Use judgment. In particular, the number of transmissions per hour is checked to detect an invite request flooding attack and notify the policy manager 108 to respond.

The SIP filter 105 performs a blocking function based on SIP addresses (from, to, via, caller_ID, etc.). The block list may be received through periodic communication with the policy manager 108, or may be automatically blocked according to the QoS state (available bandwidth status) of the management module.

The media detector 106 updates the detection pattern through communication with the policy manager 108, detects an attack based on a malicious attack pattern (modulated RTP packet insertion, RTP flooding), and detects the attack based on the policy manager 108. ) To determine if there is an error. In addition, through the validity check on the media packet, it detects a media packet in a wrong format, and detects a packet entering an IP / port different from the IP / port of the established session.

The media filter 107 performs filtering based on IP / port / protocol. In the present invention, the media detector 106 and the media filter 107 are collectively referred to as MGATE. Here, the RTP packet detection method of the present invention is not limited to IP / port, and other methods may be applied afterwards.

The policy manager 108 is composed of detection rules, corresponding rules, and blocking rules to deliver effective protection policies to the detectors 104 and 106 and the filters 105 and 107. The protection policy may be changed by an administrator and may be set to automatically update the filter rule by the corresponding rule.

Management module

The management module is composed of an Element Management System (EMS) 109 and an Event Server (EVTS) 110.

The EMS 109 is a system for managing and operating network management and system components of the secure SBC system of the present invention, and provides an administrator interface to manage the secure SBC. The EMS 109 manages basic configuration information, QoS related policies, security policies, and the like, and delivers information related to each component.

The EVTS 110 is a processor that collects log or status information of each component and reports session information and system resource information of the SSCS 101, the MRMS 102, and the MRWS 103 belonging to the session control module. To allow the policy manager 108 to make a policy.

DB

The DB 111 arrives at the security module with basic information on detection / blocking, and in particular, receives session information and system information and shares the session information with the session control module, security module, and management module.

The functional configuration of the secure SBC system of the present invention is as shown in Fig. 2, the following describes the detailed configuration of each module and the data flow in each module constituting the secure SBC system.

3 is a diagram illustrating a detailed configuration of the SSCS 101 and an interface with related modules. As shown in FIG. 3, the SSCS 101 includes a session manager 301 for managing a session, a SIP filter 302, and a SIP detector 303 for detecting and blocking a SIP-based malicious attack. do. In the present invention, the SIP filter 302 and the SIP detector 303 are located inside the SSCS 101, but may be located independently of the SSCS 101 as necessary. The blocking procedure for the SIP signal is as follows. The SIP filtering rules are loaded from the DB 304 to block malicious SIP packets and detect an attack, and then apply them to the filters through the filtering rule compiler 305 and the detection rule compiler 306. The session manager 301 manages new sessions and is responsible for communicating with the MRMS 307. If the invite message is found to be normal, the MRMS 307 connects to the new RTP session and modifies and delivers the invite message to the SIP proxy server according to the B2BUA function so that the call is established.

4 is a detailed configuration diagram of the session manager 301. In order to solve the NAT / FW traversal problem, the session manager 301 provides a B2BUA function as described above, and stores session information as shown in FIG. 4 to allow a normal call. The SIP message is delivered to the receive queue 401 via a SIP filter, and the message delivered to the receive queue 401 is processed by a Call-LEG control 402 for multiple call processing. If the message transmitted to the reception queue 401 is a new SIP invite request, the UA 403 is created to form a separate session with the receiving terminal to perform a B2BUA function. The UA 403 is composed of a UAS 404 and a UAC 405, the UAS 404 serves as a receiver of a session with the transmitting terminal, and the UAC 405 receives a call for a call with the sender. It serves as a sender of a session with the terminal. In addition, the UA 403 stores its state information in the RSDB. In this case, the RSDB refers to a DB that stores session related information generated and discarded in real time.

5 is a flowchart of SIP message processing in the SSCS 101. First, the message passing through the SIP filter is stored in the reception queue (S501). By checking the SIP message stored in the reception queue (S502), if the message is an invite message, the existing session is searched to determine whether the message is a request for an existing session or a new request (S503). If the invite message is a request for a previously generated call, the UAS / UAC information stored in the table is read (S504), and the message is stored in the transmission message queue (S517).

If the SIP message stored in the reception queue is a new request, it is checked whether there is a bandwidth for allocating a corresponding channel (S505), and if the bandwidth does not exist, it is stored in the waiting queue (S508). Before the timer waiting for the response message expires in the terminal checks the additional bandwidth (S511), even if there is no bandwidth transmits a message that the service can not be provided to the terminal and terminates the call generation procedure (S512).

If there is enough bandwidth to allocate a channel for the new request, create a new media session (S506) and store the relevant information (UAS / UAC) (S507), then change the data as if it were UAC ( S516) the message is stored in the transmission message queue (S517). At this time, after creating a new media session (S506), the SBC generates session information (receiving media port, etc.) for operating as UAC (S509) and transmits it to the MRMS 102 to generate a channel (S510). ).

On the other hand, if the message passing through the SIP filter is a call termination, call cancellation (Bye, Cancel) message, and retrieves the corresponding call session information (UAS / UAC) (S513) and the relevant information to release the allocated channel The data is transmitted to the MRMS 102 (S514). In addition, after storing the relevant information (S515), the data is changed to transmit the end message to the terminal (S516) and stored in the transmission message queue (S517).

6 illustrates an interface between the MRMS 601 and related modules. The MRMS 601 serves to allocate and remove a media bind port to the MRWS 602, and one MRMS 601 may manage a plurality of MRWS 602. Accordingly, the MRMS 601 plays a role of load balancing controlling the load of the MRWS 602 processor, and one MRMS 601 is assigned to one SSCS 603.

The MRMS 601 receives a request for a new session from the SSCS 603, generates a new MRWS 602, and transmits RTP IP and port information. The SSCS 603 creates a new session between the secure SBC and the call counter using the new IP and port. The MRMS 601 calculates the available bandwidth from the RSDB and informs the SSCS 603 whether to create an additional session. If there is no available bandwidth, the SSCS 603 makes a call establishment request until the available bandwidth is secured. Reject.

7 is a data flow diagram in the MRMS 601. The MRMS 601 receives media data information from the SSCS 603 through an SSCS interface. The MRMS 601 stores the call_ID and the MRWS ID when the message received from the SSCS interface includes the information on the media session (SDP, Create Call) (S701), and newly generates the MRWS (S702) and the MRWS memory map. The generated MRWS information is stored in step S703. Thereafter, the information on the available bandwidth of the RSDB is changed (S704).

If the message received from the SSCS interface is a call confirmation (200 OK) message, new information is added if media session information exists (S705). After the MRWS search (S706), if the session is found (S707), if it is found, the storage (S703) and the ACK (ACK) are transmitted to the MRWS map (S708). If not, the error result is transmitted to the SSCS.

On the other hand, if the message received from the SSCS interface is a call termination message, it is stored in the corresponding MRWS map (S711) and after receiving a response from the MRWS and deletes the corresponding MRWS (S712). Thereafter, the information on the available bandwidth of the RSDB is changed (S713). In addition, when the MRWS is informed that there is no data flow for a certain time, it is regarded as a call termination and the SSCS is notified of a call termination according to time expiration.

When a new session is created or an existing session is deleted, it reads the current bandwidth from RSDB and decides whether or not to allow the next session and notifies the SSCS.

FIG. 8 is a diagram showing a detailed configuration of the MRWS 801 and an interface with related modules. The MRWS 801 is a processor that exchanges RTP data of a terminal when a session is connected between SIP terminals and a call is made through RTP / RTCP, and the MRMS 802 is dynamically changed according to a connected session. The MRWS 801 is generated.

The MRWS 801 receives an RTP channel request from the MRMS 802, allocates an RTP channel, and transmits a port number. In addition, periodically transmits information (silence time) for the allocated channel, the MRMS 802 is regarded as the remaining channel that did not terminate normally if the silence time of the MRWS 801 exceeds the defined time, the assigned channel Release and notify the SSCS. When the MRWS 801 allocates a channel, the MRWS 801 transmits IP / port information to the policy manager 804 to receive the data channel. In addition, the channel information and the packet amount are transmitted to the RSDB 805, and the MGATE 803 is informed of the IP / port for normally allocated traffic to allow the corresponding voice packet.

9A and 9B are data flow diagrams in the MRWS 801. The MRWS 801 updates the average bandwidth to the RSDB at initialization, requests the policy manager and the IP and port permission related to the media, and updates the IP and port information to the RSDB. In addition, the MRMS interface manages the session related to the media information, and checks whether the media data is transmitted for a predetermined time through the timer, and if no data comes in, generates a timer expiration and deletes the information related to the session.

When the channel generation is received from the MRMS 801, the transmission / reception channel is allocated (S901) and the transmission / reception channel mapping table is changed (S902). Thereafter, the timer is driven (S903), and the result is notified to the MRMS 801 (S904).

When the channel termination is received from the MRMS 801, the transmission / reception channel is released (S905), and the transmission / reception channel mapping table is changed (S906). Thereafter, the result is notified to the MRMS 801 (S907).

When encryption / decryption is required for some sections (transmission terminal to secure SBC section) for the media, media data is converted through the media converter. At this time, the data transmitted from the transmitting terminal to the SBC is decrypted (S909), and the data transmitted from the receiving terminal to the SBC is encrypted (S910). If no encryption is required, forwarding is done without any data conversion.

FIG. 10 is a diagram illustrating the detailed configuration of the policy manager 108 and its interface with related modules. The policy manager 108 may set session management and control message filtering and detection, media message filtering and detection related policies. It is a processor that compiles and allows other processors to apply filtering rules modified by the administrator.

The rule information used by the policy manager 108 includes static information and dynamic information. The static information is information required when the initial policy manager is activated and is stored in the DB 1001. The dynamic information is abnormal data found for intrusions and other rules while the policy manager is running, and these values are added and deleted as the security SBC is running. Therefore, the policy manager 108 reads from the DB the basic filtering rule information which is first applied when the system is running.

11 is a diagram illustrating a functional configuration of the policy manager 108 and an interface with related modules. The interprocessor communication method uses IPC, dynamically creates and manages RTP / RTCP port assignments, and updates log information related to voice packet delivery to RSDB.

The policy manager 1101 obtains RTP information used from the MRWS 1102. It also informs MGATE of the IP and port information of the acquired RTP. The MRWS 1102 informs the policy manager 1101 whether to directly process or forward RTP data. The average bandwidth of the DB is recorded in the RSDB from the RTP information. This is to calculate the bandwidth that can be handled by the SBC. That is, the effective channel information of the MRMS 1103, respectively, processing the function of blocking the new call information to ensure the voice quality currently processed when the total bandwidth of the MRMS 1103 exceeds the limit of the system It is for. That is, it decides whether to connect additional sessions.

The RSDB log informs the processor status of the policy manager 1101 and writes down (start / end / ID) filtering IP / port information. Record the average bandwidth over which the RTP port is allowed.

As the attack response in the policy manager 1101, threshold adjustment, history management, active and passive determination of policies, and addition and deletion of detection methods may be included.

For flexible response, thresholds for detection of VoIP attacks can be defined. At this time, if the threshold value is small, a normal call can be detected as a VoIP attack, and if it is too large, the defense against the attack is low, which may be a problem in system performance. In addition, when a certain level of the threshold is reached, the operator can be notified first so that the operator can set this policy.

The user can define how much information to process for detecting VoIP messages. Therefore, based on this information, a short or long term policy can be established, and a more appropriate response policy for VoIP attacks can be established.

Blocking can be done for various VoIP attacks, either by actively adding or removing blocking for handling such detections, or by detecting and informing the administrator of the VoIP attack situation, and the administrator can directly apply the policy.

When the detection module is needed, it can be easily added without changing the whole module, and the existing detection module can be easily deleted when it is no longer used due to the performance of the system. do.

12 is a diagram illustrating a detailed configuration of the MGATE and an interface with a related module. The MGATE processor performs filtering on IP / port / protocol (TCP / IP, UDP, ICMP) through real time packet monitoring. It operates organically with the policy manager to dynamically block or route the packets input through the network, thereby primarily filtering unnecessary packets that attack the system.

It is a figure which shows the interface with the detailed module of the said MGATE detailed structure, and a related module. The input packet blocking module 1301 primarily blocks entry of an abnormal packet by using a rule set configured as a malicious packet, and information about the filtered packets is written in a message format to the message queue of the packet analyzer 1303. Used to write log information about packet filtering after it has been sent.

The packet filtering information transmitted from the packet filtering module 1304 to the message queue of the packet analyzer 1303 is filtered time and several packets in addition to basic header information such as the protocol and source address and destination port number used by the currently filtered packet. Log information such as whether they are being filtered (counter) is included.

The protocol analyzer 1305 reads header information of all packets transmitted to a higher protocol, prepares it into a message format necessary to detect an intrusion, and transmits it to the message queue of the packet analyzer 1303, and the information transmitted to the message queue is transmitted to the packet analyzer. 1303 reads periodically to detect intrusions. In addition, in order to cope with a DDoS attack, the same number of packet receptions may be calculated per second, and when the predetermined threshold is exceeded, it is notified to the policy manager 1306 and blocked according to the policy of the policy manager 1306.

The packet analyzer 1303 periodically reads the message from the message queue, updates the intrusion status information according to the intrusion type, and passes the detected intrusion information to the policy manager 1306 when the intrusion is detected. Intrusion information includes what kind of data (voice, control, IP, port, etc.), and the level of response (whether it should be blocked immediately, whether it should be logged to the system in the form of an alert message, etc.). In addition, if the host blocked by the packet filtering module 1304 does not send a packet that is considered to be an intrusion for a period of time, the packet is allowed to be sent again, thereby actively preparing for an inaccuracy of intrusion detection and blocking. .

14 is a data flow diagram in the SIP detector and filter. The byte and register message received by the SSCS first checks the block list (S1401) and drops it if applicable (S1402).

If the message does not correspond to the block list, the SSCS first checks the bandwidth (S1403), and if there is an available bandwidth, the SIP message is processed normally (S1404). In addition, it is transmitted to the detector and compared with the attack pattern based on the past history information to check whether there are abnormal symptoms (S1405).

15 is a data flow diagram in the SIP detector. In the case of an in-person attack, if the message is sent to the same VoIP sender (From), the same waypoint (Via), and the same receiver (to), the notification information is transmitted to the system operator before the hourly transfer count threshold is reached. When the threshold is reached, it responds to the message according to the policy manager's policy.

If you leave the normal SIP message state, for example, you are waiting for a 200OK message and you receive an unexpected message, such as a Bye message, you can continue to accumulate this information and block if it is out of range. Make sure In addition, detection of such things as SIP SQL injection attacks can be checked against invalid message checks to analyze whether a SIP message is an appropriate message, and if so, it can block such a message.

16 is a data flow diagram in the MGATE. All messages received by the MGATE check the IP / port-based block list (S1601), and if so, drop the message (S1602). If the message does not correspond to the block list, the allow list is checked in the case of the RTP packet (S1603). If the message is not in the corresponding list, the message is dropped (S1602). Therefore, only voice traffic to which a call is normally established is allowed. Traffic passing through the block / allowed filter is transmitted to the detector to check whether there is an abnormal symptom by comparing with the attack pattern based on past history information (S1604).

17 is a data flow diagram in the MGATE detector. The detection of the RTP message analyzes the header part, checking whether the time stamp, SSRC value is out of a given threshold (defined transmission interval, range of SSRC value), and if it is out of the threshold, notify the policy manager to respond. . In addition, it checks the version, type, etc., and sends an appropriate value to the policy manager to block or notify the operator to respond.

The present invention of the above configuration, by enabling the VoIP service in the private IP through the NAT / FW traversal function to ensure the call availability in the existing Internet network, it is possible to protect the equipment in the network by providing a network concealment function have.

In addition, SBC can provide its own security functions to ensure the safe use of SBC and VoIP services, and can detect and block calls and media traffic through the SBC to defend against threats to VoIP services.

Claims (13)

In the secure session control device (Secure SBC) for the VoIP service that provides the session control function, SBC system protection function and VoIP denial of service attack response function, A session control module for controlling the creation, management, and exchange of data between the terminals; Security modules to detect and block malicious calls and media; A management module for managing the components of the system and reporting information of the system; And It includes DB that provides basic information of detection and blocking, and saves and reflects current system resource status information in security policy. The management module, EMS for network management and system component management and operation of secure SBC systems; And And an EVTS for collecting log or status information of each component of the system, reporting the information, and reflecting the information to the policy manager. The method of claim 1, The session control module, SSCS for receiving and processing call signals to manage call setup; An MRMS for managing a voice media channel based on call information received from the SSCS; And Security session control device for a VoIP service, characterized in that it comprises an MRWS for exchanging the RTP data of the terminal, when a call is made through the RTP / RTCP session is connected between the SIP terminal. The method of claim 1, The security module, A SIP detector for performing a validity check on the call signal, identifying a pattern of the call signal, and transmitting the identified information to the policy manager to determine whether there is an error; A SIP filter for performing filtering based on a SIP address; A media detector for performing a validity check on the media packet and detecting an attack; A media filter for performing filtering based on IP / port / protocol; And And a policy manager for delivering a protection policy to the detector and the filter. The method of claim 3, wherein The SIP detector, Device for secure session control for VoIP services, characterized in that it detects messages that do not match the current session establishment state, verifies errors in SIP messages that do not conform, and detects malicious SIP messages. The method of claim 3, wherein The SIP filter, Applies a blocking policy received from the policy manager, and secure session control device for VoIP service, characterized in that blocking malicious call message with SIP message information. The method of claim 3, wherein The media detector, Detects packets input to IP / port different from the established session IP / port, detects the manipulated RTP packet information packet by verifying RTP packet information, and detects malicious RTP packet. Secure session control device. The method of claim 3, wherein The media filter, Applies a blocking policy received from the policy manager, and secure session control apparatus for VoIP service, characterized in that to block the RTP packet with RTP packet information, such as IP / port, SSRC, time stamp of the RTP packet. The method of claim 3, wherein The policy manager, A detection policy of the SIP message detector and the media detector is set and reached, and a result of the detection of the SIP message detector and the media detector is transmitted to a corresponding module to block the policy of the SIP filter and the media filter according to a preset response rule. Secure session control device for VoIP services, characterized in that for setting up and delivering. The method of claim 8, The corresponding module, Apparatus for responding to the detection result automatically applied through a previously set correspondence application table, the security session control device for VoIP service, characterized in that the filter to automatically cut off by setting a threshold. delete The method of claim 1, The EMS, Secure session control device for VoIP service, characterized by providing a communication interface with an external manager to enable manual operation and management. The method of claim 1, The EVTS, Security session control device for VoIP service, characterized in that the current call setup step information, RTP packet information and IP / port information and system resource information used for communication in real time and transmits to the RSDB. The method of claim 1, The DB, DB which receives initial detection and blocking information and initial value; And Security session control device for VoIP services, characterized in that it comprises an RSDB for storing session-related information that is generated and discarded in real time.

Images