KR20090024847A - Communication system - Google Patents

Abstract

A communication system is provided to deal with an error of an application service stably by defining an event processing method according to a state when implementing SIP(Session Initiation Protocol) internet phone communication. A communications system includes a service management unit(100), a protocol stack management unit(200) and a media stack management unit(300). The service management unit handles the UI(User Interface) and the other task(10). The service management unit processes the event generated in the sub module. The protocol stack management unit is connected to the service management unit based on the event. The protocol stack management unit manages the protocol related stack. The protocol related stack decodes the SIP protocol for phone connection. The media stack management unit is connected to the service management unit based on the event. The media stack management unit charges the transmission of the media.

Description

Communication System {Communication System}

The present invention relates to an Internet telephony system based on Session Initiation Protocol (SIP).

A telephone system based on the Internet is being implemented. This communication system, which is called an internet telephone, can generally transmit and receive data as well as transmit and receive voice signals. The Internet phone system performs voice and data communication between terminals based on the Internet. The voice call is implemented through the Internet instead of the PSTN. Since the packet-based network is used as a communication method using the Internet or IP, it is generally possible to make a low-cost call. VoIP is a multimedia that can transmit and receive not only voice but also video using Codec H.323, an ITU-T standard. Communication technology.

The present invention provides a communication system for performing SIP Internet telephony based on event delivery and processing.

The present invention defines a state that changes according to a user's request when SIP-based telephone connection, and the communication that can be applied to the application scenario of call setup (Call-Setup) to the SIP protocol by placing an event to transition each state Provide a system.

The present invention is a SIP Internet telephony system, which classifies (exception) situations occurring according to a proxy server, a terminal, etc. into seven states, and defines a method of processing events for each state. By providing a communication system that can stably cope with errors according to scenarios of application services.

Communication system according to an embodiment of the present invention, the service management unit for handling the UI and other tasks (Task) and receives and processes events occurring in the lower module; A protocol stack manager connected to the service manager based on an event basis and managing a protocol related stack for encoding / decoding a SIP protocol for a telephone connection; A media stack manager connected to the service manager based on an event basis and responsible for transmitting corresponding media when communication is performed based on a telephone connection protocol; Characterized in that it comprises a.

According to an aspect of the present invention, there is provided a communication control method, comprising: determining a defined state to manage telephony communication based on an event when a SIP telephone connection is made; In the defined state, generating and delivering an event message based on the defined event message type and executing a state transition; Controlling SIP telephony based on the forwarded event message; Characterized in that it comprises a.

According to an embodiment of the present invention, in order to efficiently develop an application service in a terminal, an appropriate state may be set, and events that may occur may be applied to all application scenarios in which call-setup is performed using the SIP protocol. In addition, various exceptions occur according to application services and provide a communication system that can stably handle a fatal error of a terminal.

According to an embodiment of the present invention, when a telephone connection is made using the existing SIP protocol, a new application using the SIP protocol is defined from a developer's point of view by defining a state that changes from time to time according to a user's request, and placing an event to transition each state. When developing a service, you can design an object-oriented system.

According to an embodiment of the present invention, when designing an Internet telephony connection system according to a call-setup process in a commercial network, it is possible to solve the problem that an exception may occur and excessive traffic may cause a system error. It is based on the fact that in case of expected event, it can be handled by a formal routine and handle exceptions efficiently.

1 shows the structure of a SIP Internet telephony connection system according to an embodiment. Service Main Manager (SM) 100, which handles UI (User Interface) and other tasks (10) and receives and processes events occurring in lower modules, uses SIP protocol for telephone connection. Protocol Stack Manager (PM) 200 for managing a protocol-related stack for encoding / decoding, a media stack for managing media transmission such as voice or video for communication using a telephony protocol. A management unit (MM: Media Stack Manager) 300 is included.

The service main manager 100 serves as an interface between the UI and other system tasks, generates and processes an event associated with a SIP call, and manages a database related to user information. The service main manager 100 may include a service event process 110, a presence database manager 120, a synchronization controller 130, and a user profile environment manager. Manager (140), Non-Volatile DB (NVDB) 20, the non-volatile database management unit (NVDB Manager: Non-Volatile DB Manager) 150, multimedia codec And an audio / video controller 160 for controlling audio / video encoding / decoding.

The service event process 110 interprets the defined event coming from the UI 10 to another module, interprets the event coming from another module, and informs the UI 10 of the result. When connecting a telephone by SIP, for the specific application performing a desired service, the event is distinguished and managed for which application the SIP telephone connection. To this end, the service event process 110 includes a voice call service process 110a, a video call service process 110b, and a conference call service process 110c. It includes. The voice call service process 110a is to handle voice-based phone connection, the video call service process 100b is to handle video-based phone connection, and the conference call service process 110c is to handle multi-party call connection. will be.

The presence database manager 120 stores and manages the presence and group information of the buddy in the corresponding database 120a. Buddy's presence information includes communication status, group information, name, gender, symbol, etc. Presence information can be added here according to the requirements of the application. have. Group information of Buddy includes group name and group ID, and similarly, group information can be added to the requirements of the application. It consists of functions that can manage Buddy DB and Group DB, which are stored in database form. In addition, Linked-List Mechanism is applied to access, delete, add, and update the database.

The synchronization controller 130 is connected to the CCB / NICB pool 130a to process an overlap transaction and a mid-call transaction. It also distinguishes several transactions or dialogs at the same time and maintains maximum independence between each transaction or dialog processed at the same time.

The user profile configuration manager 140 is connected to the user profile storage 140a to store or initialize provisioning data for each application. For example, it manages an Authentication Parameter and a Registration (Subscription) Expire Value. The protocol stack manager 200 configures initial data of a call object using this profile data.

Non-volatile database manager (NVDB Manager) 150 is connected to the non-volatile database 20, the server connection information (Server URI / IP Address), service control parameters (Service Enable / Disable Parameter), Receiving mode (Receiving) Mode), non-volatile data that determines login process and so on.

The audio / video controller 160 is connected to the multimedia codec 30 to control the multimedia codec 30 to manage encoding or decoding of multimedia data such as audio and / or video.

The protocol stack manager 200 manages a call object used for a SIP dialog or a SIP call process in the protocol stack manager. Using the SIP basic mechanism proposed in RFC 3261, and creates a call based on the user information received from the service main management unit 100. To this end, the protocol stack management unit 200 has a SIP event handler 210, and the SIP call handler 220 and the SIP Non-Call handler (SIP) by the SIP event handler 210. 230, a timer 240, a network manager 250, a protocol manager 260, a session description protocol (SDP) manager 270, an XML manager 280, an environment setup unit ( Configuration 290). The SIP call handlers 220 and 230 manage SIP calls and SIP non-calls, a timer 240 provides and manages time information, and the network manager 250 sets and releases a PPP connection. It performs a status check and performs socket control for SIP and SIP message sending / receiving. The protocol manager 260 manages related protocols, and the SDP manager 270 performs message forming and negotiation for media transmission and reception. The XML manager 280 handles XML information for SIP event handling, and the environment setting unit 290 is in charge of setting and managing environment information for SIP event handling.

The media stack manager 300 includes a media event handler 310 and manages media transmission such as voice or video when a telephone connection is made. To this end, it includes a Real Time Transport Protocol / RTP Control Protocol (RTP) stack manager 320, a Message Session Relay Protocol (MSRP) stack manager 330, and a media profile manager 340. Media transmission management performed by the media stack manager 300 is performed as follows.

When the SIP call connection is established, the two terminals exchange data. At this time, various types of data such as voice, image, and video are supported. The SIP protocol only allows call connection and the channel for data should use another protocol. The media stack manager 30 manages an additional protocol for sending and receiving data. As the data exchange protocol proposed in the present invention, MSRP (Message Session Relay Procotol) is used. Define the protocol to use for data exchange with SDP when negotiating a call and negotiate port numbers. When the network channels are normally opened with each other, data is created and transmitted in the form of MSRP, and the media stack manager 300 checks the event and transmission status. When the SIP call is released, the MSRP channel should be automatically closed, so the service main management unit 100 can send and receive events in real time.

On the basis of the SIP Internet telephone connection system shown in FIG. 1, a telephone connection between terminals is performed as follows.

The MO (calling terminal) and MT (calling terminal) complete the REGISTER process on the proxy server and are initialized to NULL when the telephone connection is valid. When the MO selects the desired partner and calls the MT, it sends 'INVITE request' and becomes 'ESTABLISHING State'. The MT receives the information and interprets the required media information to determine whether the MO and media channel can be connected. At this time, MT becomes 'WAITMEDIAANSWER state'. If the MT requires a media channel or media codec that cannot be interpreted, the MT must send a failure message, so go to the CLEARING state. It does not go to 'NULL' state immediately but filters the message that needs to be sent and received due to the characteristics of SIP signal in 'CLEARING state' to prevent an exception to the system. When the MT requests an interpretable media channel, it sends its response information by putting its system information in the SDP message and the MT transitions to the 'RESPONDING state'. Even if '200 OK response' is sent for 'INVITE', 'ACK' message must be received before the call connection is successful, so wait for 'ACK' message from MO in 'RESPONDING state'. On the other hand, the MO, which receives the response from the MT, prepares to receive data by sending a session creation event to the media stack management unit (MM) that manages the generation and release of the media channel when the message is '200 OK'.

The present invention efficiently handles exceptions that may occur in a terminal making a call (Mobile Originator, hereinafter referred to as MO) and a terminal receiving a call (Mobile Terminator, hereinafter referred to as MT) with seven states. Explain the process. Except for the error situations of MO and MT, which may be indicated by the proxy server or relay server presented in RFC3261, the contents related to the internal error situation of the server system are not covered because they are outside the scope of the present invention. .

First, let's look at the phone connection process of MO.

The MO registers address and session information with a proxy server through a REGISTER process. When the registration process is successful, the user selects the other party to connect to and attempts to connect the phone. The MO encodes the byte message (INVITE MESSAGE or INVITE METHOD) based on the text with the current status information. Proxy Server). Then, depending on the status of the other party, '100 Trying' or '200 OK' response message comes. In addition, by interpreting the SDP message delivered with this to determine whether the call-setup (Call-Setup) succeeded or failed, or whether you need to change the media information and address information of the other party. It then interprets the SDP information and opens the appropriate media channels to send and receive voice or video. When disconnecting a phone, regardless of whether it is MO or MT, one side generates a 'BYE' request message and sends it, and when a '200 OK' response message is received, the media session and SIP Internet call are disconnected. .

Next, look at the MT's telephone connection process.

In the MT, the REGISTER process must be prioritized. If the registration process is successful, a call is received from the other party. The MT must determine whether it can encode and decode according to whether the channel of the other party attempts to connect is voice or video.

For example, it interprets the session information of the SDP sent by the MO to determine whether it is possible to create a media channel, and sends a '200 OK response message'. Otherwise, 'Request Failure 4xx', 'Server Failure 5xx', 'Global Failure' 6xx 'select and send appropriate response message (Response message) that can inform the status of MT. If '200 OK' is sent, wait for 'ACK request message' to check if MO is well received. When it receives 'ACK', it opens a channel for media to send and receive data.

In the embodiment of the present invention, an event naming rule of an event that may occur when a SIP telephone connection is made in the above-described process is classified as follows.

Basically, event naming is based on the structure of 'large classification_mid classification_suffix'. In this case, the 'categorization' item expresses the subject that processes the event, the 'middle classification' item expresses a verb or noun about the operation of the event so that the meaning can be clearly communicated, and the 'suffix' item must match Several cases are expressed as event suffixes that exist alone, not in pairs with event suffixes for cases where this is to be done. Table 1 shows an example of Event Name, Event Contents, and Event Forwarding (Direction) that occur when connecting to SIP Internet Phone according to event naming convention.

Table 1 describes the event name suggested in the present invention and under what circumstances the event occurs. In the direction of occurrence, the left side of the arrow becomes a sender and the right side receives a receiver to send and receive messages. . The transition of each state according to the present invention to be described later will be described based on the above events. In the generation direction, the UI represents a user interface. In the event description, the caller is the person who makes the call, the receiver is the person who receives the call, the caller is the caller terminal (MO), the receiver is the caller terminal (MT), and the caller is the caller or receiver.

The 'classification' item is a subject for processing an event, the main service manager 100 is expressed as 'SM', the protocol stack manager 200 is expressed as 'PM', the media stack manager 300 is 'MM' Express as

The 'middle category' is a verb or noun for the operation of an event so that the meaning is clearly communicated, depending on the message type such as 'ESTABLISH', 'INCOMING', and 'SENDINVITE', for example. Examples of items are shown in more detail.

Event suffixes for the case that must be paired among 'suffix' items are 'REQ (REQuest)', 'RES (RESponse)', 'RPT (RePorT)', and 'CNF (CoNFirm)'. Referring to FIG. 2, 'REQ (REQuest)' represents a case of requesting a specific operation from an upper layer to a lower layer, and 'RES (RESponse)' completes an operation for REQ. Represents a case in which a response is sent afterwards, 'RPT (RePorT)' represents a case of requesting a specific operation from a lower layer to an upper layer, and 'CNF (CoNFirm)' Represents a case in which a response is sent to notify the lower layer that the RPT processing has been completed.

Event suffixes that are not paired among the 'suffix' items are 'IND (Indication)' and 'CMD (Command)'. Referring to FIG. 2, 'IND (Indication)' indicates a specific situation from a lower layer to an upper layer and expresses a case in which an additional event primitive exchange is not necessary. 'CMD (Command)' indicates a case in which a specific situation is notified from an upper layer to a lower layer and an additional event primitive exchange is not required. Therefore, 'CM' is not accompanied by 'RES' and 'IND' is not accompanied by 'CNF'.

In the present invention, a situation in which (exception) occurs depending on a proxy server, a terminal, and the like when a SIP Internet telephone is connected is divided into seven states, and a method of processing an event for each state is determined.

According to the embodiment, seven states are 'NULL', 'CLEARING', 'ESTABLISHING', 'WAITMEDIAANSWER', 'WAITUSERANSWER', 'RESPONDING', and 'ACTIVE'.

The transition process of each state will be described with reference to FIGS. 3 to 9.

First, the NULL state is a state where the MO (calling terminal) and the MT (calling terminal) are initialized after registering with a proxy server and valid user authentication. The transition process of the 'NULL' state is shown in FIG. 3.

In the NULL state, the terminal sends the 'INVITE request' to the MO and the receiving side becomes the MT. The step 'SM_ESTABLISH_CMD' represented by the first step S111 is an event in which a SIP call connection request is started from the UI 10 to the service main manager SM 100, and the step 'represented by the second step S112 is performed. PM_SEDNINVITE_CMD 'is an event for requesting to make an' INVITE message 'from the service main manager (SM) 100 to the protocol stack manager (PM) 200 and to deliver it to the receiver. The step 'PM_RECEIVEINVITE_IND' represented by the third step S113 is an event indicating that the 'INVITE message' has come from the calling party to the service main manager (SM) 100 from the protocol stack manager (PM) 200, and the fourth step (S113). Step 'MM_SESSIONCREATE_REQ' represented by step S114 is an event requesting to create a session in order to receive multimedia data from the service main manager (SM) 100 to the media stack manager (MM) 300. After the second step S112, the state transitions to the 'ESTABLISHING' state, and after the fourth step S114, the state transitions to the 'WAITMEDIAANSWER' state.

The transition process of the 'CLEARING' state is shown in FIG. 4.

SIP signaling suggested in RFC 3261 requires 'ACK' even after sending '200 OK' to finally open a media session. Even if the connection fails due to a system problem other than '200 OK', a corresponding message (Failure message) must be sent and an 'ACK' is received. If not, it must be resent. Therefore, if the telephone connection fails, it can cause a fatal error to the other party's system or server because it can't check whether the 'ACK' is received if the previous state transitions to NULL. Therefore, you must first process the transition to the 'CLEARING' state and then to the 'NULL' state. In FIG. 4, the 'PM_END_RES' step (S211) is an event transmitted from the protoco stack manager (PM) 200 to the service main manager (SM) 100 and a response message for 'BYE' from the receiver. It is an event indicating that it has been received, and the 'PM_ACK_IND' step (S212) is an event transmitted from the protocol stack manager (PM) 200 to the service main manager (SM) 100 and informs that the 'ACK' message has been received from the calling party. It is an event. After S211 and S212, the state transitions to the NULL state.

The transition process of the 'ESTABLISHING' state is shown in FIG. 7. This process is the state where the MO (calling terminal) calls the other party and asks for the connection. When the media information of the MO is loaded on the SDP and sent along with the SIP signal, it indicates whether the MT (phone receiving terminal) can connect. The MO interprets the MT result in the 'ESTABLISING' state and transitions to another state.

The first step S311 (PM_FINALRESPONSE_IND) is an event transmitted from the protocol stack manager (PM) 200 to the service main manager (SM) 100 and indicates that a response message for 'INVITE' has been received from the receiver. , Second step S321 is a step of determining whether or not '200 OK'. If it is '200 OK', the process proceeds to the third step S313 (MM_SESSIONCREATE_REQ) and requests an event to form a session for receiving multimedia data from the service main manager (SM) 100 to the media stack manager (MM) 300. In the fourth step S314 (PM_ACK_CMD), a 'ACK' message is generated and received to inform the protocol stack manager (PM) 200 of the service stack manager (SM) 100 to receive the 200 OK. Send an event requesting delivery to the side. If it is not '200 OK', the process proceeds to the fifth step (S315) (SM_ESTABLISH_IND) to transmit an event indicating that the SIP telephone connection is started from the service main management unit (SM) 100, and to the sixth step (S316) (PM_ACK_CMD). Transmit and send related events. A seventh step S317 (SM_END_CMD) is a step of generating an event in which the caller releases a telephone call from the user interface (UI) to the service main manager (SM) 100. The eighth step S318 (PM_END_REQ) is a step of generating an event for requesting to make a 'BYE' message from the service main manager (SM) 100 to the protocol stack manager (PM) 200 and to deliver it to the counterpart. After the fourth step S314, the state transitions to the 'WAITMEDIAANSWER' state, and after the sixth step S316 and the eighth step S318, the state transitions to the 'CLEARING' state.

The 'WAITMEDIAANSWER' transition process is shown in FIG. 6. 'WAITMEDIAANSWER' refers to a state of determining whether communication with an internal terminal is possible based on capacity, codec information, and performance of a media channel required by an opposite terminal. The MO (calling terminal) is delivered with a '200 OK' response message, and the MT (terminal receiving a call) is carried in the 'INVITE' request message. Therefore, the MO transfers to 'WAITMEDIAANSWER' when '200 OK' is received in the 'ESTABLISHING' state, and otherwise to 'CLEARING'.

The first step S411 (MM_SESSIONCREATE_RES) is an event informing the session creation result from the multimedia stack management unit (MM) 300 to the service main management unit (SM) 100, and the second step (S412) indicates whether the session creation is successful. As a step of determining, if it is successful, the process proceeds to the third step (S413), otherwise it transitions to the 'CLEARING' state. If it is MO (terminal for making a call) in the third step S413, the flow advances to the fourth step S414, and if not, the flow moves to the sixth step S416. The fourth step (S414) (PM_SUBSCRIP_CMD) is an event requesting the server to send a 'SUBSCRIBE' message from the service main management unit (SM) 100 to the protocol stack management unit (PM) 200, the fifth step (S415) (SM_ESTABLISHED_IND) informs the event handling status and transitions to the 'ACTIVE' state. The sixth step S416 is a step of driving the timer 240, and the seventh step S417 (SM_INCOMING_RPT) corresponds to an event indicating that the call is received by the receiver, and then transitions to the 'WAITUSERANSWER' state.

On the other hand, the eighth step (S418) (SM_END_CMD) is the event that the caller releases the call connection, and accordingly according to the ninth step (S419) (PM_END_REQ) to make a 'BYE' message and to deliver to the other party 'CLEARING' state Transition to In the tenth step S420 (PM_END_RPT), the calling party notifies that the 'BYE' message has arrived, and in the eleventh step (S421) (PM_END_CNF), requests to transmit a response to the 'BYE' message to the counterpart; (S422) (PM_FINALRESPONSE_CMD) receives the 'INVITE' message, requests to deliver a response to the other party, and then transitions to the 'CLEARING' state.

The 'WAITUSERANSWER' transition process is shown in FIG. 7. In this process, the MT should request the end-user to make a call even if the media channel can be connected to the media information requested by the other party. The MT generates a failure message other than '200 OK' and sends it to the counterpart.

The first step S511 (SM_USERANSWER_CMD) is a step of generating and delivering an event requesting a decision of whether to make a telephone connection, and the second step (S512) is a step of stopping the timer 240, and a third step Step S513 is a step of determining whether the telephone connection is accepted. If allowed, the process proceeds to the fourth step S514 (PM_FINALRESPONSE_CMD) to receive an 'INVITE' message and to transmit a response to the other party. Then transition to the 'RESPONDING' state. If it is not allowed, move to the fifth step (S515) (PM_FINALRESPONSE_CMD) to receive the 'INVITE' message, request to forward the response to the other party, and then create or receive the multimedia data in the sixth step (S516) (MM_SESSIONDEL_CMD). Request to remove a session. And transition to the 'CLEARING' state. The seventh step S517 (PM_END_RPT) generates an event indicating that the 'BYE' message has arrived from the calling party, and delivers it from the protocol stack manager (PM) 200 to the service main manager (SM) 100, and the eighth step. In step S518 (PM_END_CNF), a request for forwarding a response to the 'BYE' message to the other party is requested. In step 9 (S519) (PM_FINALRESPONSE_CMD), after receiving the 'INVITE' message and requesting to deliver a response to the other party, the process transitions to the 'CLEARING' state. In the tenth step S520 (SM_INCOMING_CNF), the receiver gives an approval response to the incoming call, and it is determined whether or not to answer the call in the eleventh step S511 (S521). If it is not call accept, move to the ninth step (S519). If it is call accept, move to the twelfth step (S512) (PM_END_CNF) to respond to the 'BYE' message. Ask for it. In the thirteenth step (S523), it is determined whether it is in the automatic mode or not, and if it is not in the automatic mode, the state transitions to the 'WAITUSERANSWER' state. In the case of the automatic mode, the process moves to the fourteenth step (S524) (PM_FINALRESPONSE_CMD) to receive the 'INVITE' message. After requesting to forward the response to the other party, it transitions to the 'RESPONDING' state.

The transition process of the 'RESPONDING' state is shown in FIG. 8. The MT (terminal receiving the call) sends a '200 OK' and then receives an 'ACK' from the MO (terminal calling) to open the media channel. Therefore, if '200 OK' is sent but signal data is lost due to network or server error, and MO is not received, MT will timeout after retransmitting several times. At this time, the transition to the 'CLEARING' state.

In the first step S611 (PM_ACK_IND), the caller informs that the 'ACK' message has arrived, and determines whether it is valid information in the second step (S612). That is, if it is '200 OK', the third step S613 (PM_SUBSCRIP_CMD) requests the server to send a 'SUBSCRIBE' message to the server and transitions to the 'ACTIVE' state, and if it times out, the fourth step (S614) (PM_END_REQ) BYE 'message is created and requested to be delivered to the other party, and then transferred to the' CLEARING 'state. In the fifth step S615 (PM_END_RPT), the caller informs that the 'BYE' message has arrived, and in step 6 (S616) (PM_END_CNF), requests to send a response to the 'BYE' message to the counterpart. In step S617 (PM_FINALRESPONSE_CMD), after receiving the 'INVITE' message and requesting to transmit a response to the counterpart, the terminal transitions to the 'CLEARING' state.

The 'ACTIVE' transition process is shown in FIG. 9. In this process, the MO and MT can exchange media data such as voice and video. In addition, it is a state in which a telephone connection can be released by using 'BYE request' among SIP signals. In step S711 (SM_END_CMD), the caller generates and forwards an event for releasing the call, and in step S712 (PM_END_REQ), a message 'BYE' is created and requested to be delivered to the other party, and then 'CLEARING' Transition to state In the third step S713 (PM_END_RPT), the calling party notifies that the 'BYE' message has arrived, and in the fourth step S718 (PM_END_CNF), requests to transmit a response to the 'BYE' message to the counterpart. Then, in step S715 (MM_SESSIONEDL_CMD), a request is made to remove the session created in order to receive or give multimedia data, and in step S716 (SM_RELEASED_IND), the user is informed that the telephone connection is released by the other party. Transition to 'NULL' state.

Event processing for each state described so far is managed by finite state machine (FSM). An FSM is a machine with a finite number of states, one of which is the current state. The FSM receives an input and causes a state transition from the current state to the output state based on some state transition function. The output state becomes the new current state. By defining an event that is valid in the current state by placing an FSM table, when the event is entered, it transitions to the state that meets the condition. FSM can read the previous state, or you can put a preprocessing table to receive events that should be prioritized in the current state in real time to prevent fatal errors in the system. That is, an event related to user termination or network close requires processing and stable recovery in the system, even if not previously defined in all states. Therefore, it is desirable to be processed in the preprocessing table of the FSM.

On the other hand, the 'CLEARING' state allows for the efficient management of complex SIP signals when processing incoming events in real time. Even if the MO makes a call and MT responds OK, if ACK is not received from the MO on the SIP signal, the call is not connected successfully. Therefore, the signal is transferred to the 'CLEARING' state to handle the call failure. To finish. In case of END request during Call-setup due to sudden system error in MO or MT, 'CLEARING' should be handled.

1 illustrates a communication system structure according to an embodiment of the present invention.

2 is a diagram illustrating an example of a naming rule for each event according to an embodiment of the present invention.

3 is a view illustrating a transition process of a NULL state according to an embodiment of the present invention.

4 is a view illustrating a transition process of a 'CLEARING' state according to an embodiment of the present invention.

5 is a view showing a transition process of the 'ESTABLISHING' state according to an embodiment of the present invention

6 is a view showing a transition process of the 'WAITMEDIAANSWER' state according to an embodiment of the present invention

7 is a view showing a transition process of the 'WAITUSERANSWER' state according to an embodiment of the present invention

8 is a view illustrating a transition process of a 'RESPONDING' state according to an embodiment of the present invention.

9 is a view showing a transition process of the 'ACTIVE' state according to an embodiment of the present invention

Table 1 shows an example of an event message type according to an embodiment of the present invention.

Claims (18)

A service manager for handling UI and other tasks and receiving and processing events occurring in a lower module; A protocol stack manager connected to the service manager based on an event basis and managing a protocol related stack for decoding a SIP protocol for a telephone connection; A media stack manager connected to the service manager based on an event basis and responsible for transmitting corresponding media when communication is performed based on a telephone connection protocol; Communication system comprising a. The method of claim 1, wherein the service manager comprises a call service related process manager, a presence manager that manages presence and group information of a buddy, a synchronization controller for managing transactions and dialogs, and user profile management. And a user profile manager, a server address and a service parameter and a reception mode, a database manager to manage a login process, and a controller to manage a multimedia codec. The communication system of claim 1, wherein the protocol stack manager performs SIP call management, timer operation, network management, protocol management, SDP management, and XML management based on a SIP event handler. The communication system of claim 1, wherein the media stack manager manages one or more of an RTP / RTCP, an MSRP, and a media profile based on a media event handler. To manage telephony based on events during SIP telephony, Determining a defined state; In the defined state, generating and delivering an event message based on the defined event message type and executing a state transition; Controlling SIP telephony based on the forwarded event message; Communication control method comprising a. The communication control according to claim 5, wherein the state is at least one of 'NULL', 'CLEARING', 'ESTABLISHING', 'WAITMEDIAANSWER', 'WAITUSERANSWER', 'RESPONDING' and 'ACTIVE'. Way. 7. The communication control according to claim 6, wherein the 'NULL' state is defined as a state in which a terminal for making a call and a terminal for receiving a call are initialized after registering with a proxy server and receiving valid user authentication. Way. The method of claim 6, wherein the 'CLEARING' state is 'NULL' after execution of at least one of an event indicating that a response message for 'BYE' has been received from a receiving terminal or an event indicating that an 'ACK' message has been received from a calling party. Communication control method characterized in that the transition to the state. The method of claim 6, wherein the 'ESTABLISHING' state makes a call from the terminal making the call to confirm the connection intention and transfers the corresponding event message according to the result, and then transitions to the 'WAITMEDIAANSWER' state or the 'CLEARING' state. Communication control method, characterized in that. The method of claim 6, wherein the 'WAITMEDIAANSWER' state determines whether communication is possible according to the capacity (Capacity, Perfoemance) and codec information of the media channel requested by the counterpart terminal, and transmits the corresponding event message according to the result. , 'ACTIVE', 'WAITUSERANSWER', 'CLEARING' state of the communication control method characterized in that the transition. The method of claim 6, wherein the 'WAITUSERANSWER' state determines an end-user's call accept intention and delivers the event message according to the determination result, and then 'RESPONDING' or 'CLEARING'. Communication control method characterized in that the transition to the state. The communication method according to claim 6, wherein the 'RESPONDING' state determines whether or not a response from the counterpart terminal is checked, transfers the corresponding event message according to the result, and then transitions to the 'ACTIVE' or 'CLEARING' state. Control method. The method of claim 6, wherein the 'ACTIVE' state generates and transmits an event message for establishing a state capable of transmitting and receiving media data between terminals, and transitions to a 'CLEARING' or 'NULL' state according to the result. Communication control method characterized in that. The method according to claim 5, wherein the event message type is based on the structure of the major classification _ middle classification _ suffix, wherein the 'large classification' represents a subject that processes an event, and the 'middle classification' is expressed as a verb or noun form for an event. 'Suffix' is a communication control method, characterized in that to represent the type of event. 15. The apparatus of claim 14, wherein the subject for processing an event in the event message type comprises: a service manager responsible for UI / task handling and event processing in a communication system, a protocol stack manager responsible for SIP protocol management for telephony, and media transmission; Communication control method, characterized in that any one of the media stack management unit responsible for the selection. 15. The method of claim 14, wherein the information representing the event message type, 'REQ' requesting a specific operation (Operation) from the upper layer (Upper Layer) to the lower layer (Lower) and the response 'RES' for this, the lower layer 'RPT' requesting a specific operation from the upper layer to the upper layer and 'CNF' to inform the lower layer that the processing for the RPT is completed, 'IND' to inform the specific situation from the lower layer to the upper layer, and the lower layer from the upper layer Communication control method, characterized in that represented by any one of the 'CMD' to inform a specific situation. The communication control method according to claim 5, wherein the event processing for each state is managed based on finite state macnine (FSM). 18. The method of claim 17, wherein the event can be added or deleted based on an FSM table.

Images