KR20050079882A - Sip presence based instant message and internet telephony service client system - Google Patents

Abstract

The present invention relates to a SIP presence based instant messaging and Internet telephony service client system (hereinafter referred to as a 'client system') that enables instant messaging or Internet telephony services such as messengers via the Session Initiation Protocol (SIP). . The SIP presence based instant messaging and Internet telephony service client system disclosed herein includes a user agent (UA) extension application module functioning as a SIP user agent; And generating a SIP message stream suitable for API calls from the UA extension application module and transmitting it to another client system, parsing the SIP message stream received from the other system to provide an appropriate callback function for the received SIP message. Including the SIP transaction module to call and notify the UA extension application module to achieve the object and technical problem of the present invention.

Description

SIP presence based instant message and internet telephony service client system

The present invention relates to a SIP presence based instant messaging and Internet telephony service client system (hereinafter referred to as a client system) that enables instant messaging or Internet telephony services such as messengers via the Session Initiation Protocol (SIP). .

VoIP has emerged as a strong rival to traditional telephony services in the technical sense of providing integrated services and architecture. VoIP services based on the Session Initiation Protocol (SIP) were the first people interested in Internet telephony. Most Internet telephony services or service-related equipment were developed using the H.323 protocol developed by ITU-T.

SIP, on the other hand, is a very simple text-based application layer control protocol developed by the Internet Engineering Task Force's SIP workgroup as part of the RFC3261 standard. SIP is a protocol that allows one or more participants to create, modify, and terminate a session together. Sessions include meetings over the Internet, telephone calls, meetings, event notifications, instant messages, and the like. SIP is independent of the underlying packet protocols (TCP, UDP, etc.).

SIP was developed after the advent of text-based HTTP. SIP is based on a client-server structure where clients initiate a call and the server responds to the call. SIP adheres to these existing text-based Internet standards, making it easy to manage, such as troubleshooting and debugging your network.

Another prominent feature of SIP is that it provides user mobility, allowing users to deliver call setup requests for them wherever they are. In SIP, each user is identified by a SIP URI. This is similar to an e-mail address (eg SIP: username @ domainname).

Many carriers require the creation of VoIP services using SIP, which is now standardized by the IETF. Accordingly, SIP-based VoIP equipment is developed or SIP is installed as a dual stack on existing H.323-based VoIP equipment. There are many cases.

SIP-based VoIP services are not intended to replace only existing telephony services. SIP has received a lot of attention because the telephony service provides its infrastructure when providing a converged service integrated with other multimedia services.

In response to this, the proposed service is an instant messaging service and a presence service, and a representative service thereof is a messenger service. Instant messaging services and presence services start with simple presence services such as online and offline services of users, and are now expanding to services that deliver various types of presence information.

However, most instant messaging and presence services (messenger services) currently being developed or operated use self-defined operating mechanisms to provide minimal compatibility even if they are difficult or interoperable with other messenger services. To this end, it only provides compatibility with messengers (typically MSN Messenger), which have a large user base.

In addition, some messenger services may develop a component that combines VoIP services using the SIP protocol defined by the Internet Engineering Task Force (IETF), and instant messaging and presence services to verify its functionality. There is a problem that the availability of the messenger service is degraded because the structure is simplified and processed, such as providing or limiting an instance of each SIP Uniform Resource Identifier (SIP URI) to one.

Accordingly, the present invention was made to solve the above problems, and the object and technical problem of the present invention is SIP presence-based instant messaging and Internet telephony services that can improve the utilization of instant messaging and presence services In providing a client system.

In order to achieve the above object and technical problem, the SIP presence-based instant messaging and Internet telephony service client system disclosed herein includes a user agent (UA) extension application module functioning as a SIP user agent; And generating a SIP message stream suitable for API calls from the UA extension application module and transmitting it to another client system, parsing the SIP message stream received from the other system to provide an appropriate callback function for the received SIP message. Including the SIP transaction module to call and notify the UA extension application module to achieve the object and technical problem of the present invention.

First, the operation method is briefly referred to in order to facilitate the understanding of the present invention.

According to the present invention, when instant messaging and Internet telephony services are performed based on SIP presence, other users (hereinafter referred to as 'buddy') knowing their own presence information management (generation, change, update, and termination) functions and presence information. SIP presence-based messaging and Internet telephony in charge of presence information management (subscription, period change, unsubscription) function for '), and notification management function according to the change of the status of presence information to buddies who have allowed to inform the presence information. A service client system and an interface therefor are proposed.

The SIP presence-based related processing proposed in the present invention utilizes PUBLISH, SUBSCRIBE, NOTIFY, and MESSAGE methods, which are SIP extension methods, and uses XML () to express the presence information in the body part of each message. extensible Markup Language schema supports Presence Info Data Format (PDF) format.

It also supports the XPIDF (eXtensible Presence Info Data Format) format to enable interoperability with messengers that have a large user base and allows users to choose which format to use.

In addition, when VoIP services such as SIP presence-based instant messaging or Internet telephony are performed, communication between clients (user-to-user) is generally possible via a specific server (an inter-client communication medium server) or (via server communication mode). For example, IMPP clients may exchange presence information with each other without directly passing through a specific server and may directly communicate with each other (direct communication mode). In order to support this, the SIP presence-based messaging and Internet telephony service client system disclosed herein can support both communication modes and allow the user to directly select which method to use.

The SIP presence-based messaging and Internet telephony service client system disclosed herein is designed to be modularized by function, and the interface between each module is provided in the form of a detailed function or a library.

At the bottom of the client system, on the other hand, there is a transaction layer defined by SIP. Below this layer, syntex check and parsing and creation functions for SIP messages, management of the corresponding transport location information, retransmission of messages for transactions, timeouts, and so on, can be used by the SIP User Agent to operate independently of the transport layer. It provides a response message matching function for the request message.

In addition, as an interface between the UA extension application module and the transaction layer, an API (Application Program Interface) provided by the transaction layer and a callback function for informing SIP transaction received from another client system to the UA extension application module which is a transaction user. There is.

The SIP presence-based messaging and Internet telephony service client system proposed by the present invention not only enables communication between terminals via a server, but also provides flexibility for enabling direct communication between terminals. This can be specified through configuration.

In addition, XPIDF and PIDF are commonly supported as a body format, which can be specified through configuration. By adopting a structure for parsing and generating body parts according to a specified format, it also enables interoperability with messengers that have a large user base, and supports forms that can be grafted in the direction of the standard. have. Therefore, after acquiring the presence information of a specific user through the communication mode and the body format, each instance included in the presence information of the user, the status information of each instance, and the exact location information of the instance may be contacted. Based on the information, it is used as a basic material for integrating various VoIP services such as instant messaging or Internet telephony.

Hereinafter, the configuration and operation of the present invention will be described in detail with reference to the accompanying drawings, but the same reference numerals refer to the same elements, even if on the other drawings in the same reference numerals to the components of the drawings. Numbers have been given and it is noted that in the description of the drawings, components of other drawings may be cited if necessary.

1 is a configuration diagram of a client system disclosed by the present invention.

Referring to FIG. 1, a client system is largely divided into two modules, and includes a user agent extension application module 10 (hereinafter, UA extension application module) and a SIP transaction module 11. The UA extension application module 10 functions as a SIP user agent and includes a user information registration service module 101, a presence service module 102, an instant message service module 103, and an internet telephony service module 104.

The SIP transaction module 11 performs an internal operation according to the API call of the UA extension application module 10, generates an appropriate SIP message stream for the API, and transmits it to another client system, and receives a SIP message stream received from another system. It is responsible for parsing and informing the UA extension application module 10 by calling an appropriate callback function in the SIP message. The UA extension application module 10 may provide an appropriate service by using the API provided by the SIP transaction module 11 and the callback function transmitted in the transaction layer.

The internal operation of the SIP transaction module 11 includes syntax check, parsing and generation functions for SIP messages, and corresponding transmission location information so that the SIP terminal can operate in a form independent of a transport layer. Includes management, message retransmission for transactions, timeouts, and response message matching for request messages. In other words, it plays the role of transaction layer defined in SIP standard.

Table 1 is a table showing the configuration information that the user can set when the client system is running.

Classification Possible information More details User Information Registration Identifier to distinguish registered users, specifying IP address, port, and transport protocol as SIP URI and current location information If there is a separate Registrar for user registration information, specify the IP address, port, and transport protocol of the Registrar Server. Communication mode setting Select from [Direct Communication Mode, Server Communication Mode] If you select the server-through-communication mode, you can specify the server's IP address and port. Presence body format settings Select from [PIDF, XPIDF] Generate or receive presence information and reflect it when parsing.

Referring to Table 1, the client system disclosed herein provides a user information registration function, a communication mode setting function, and a presence body format setting function. The user information registration function may register the SIP URI and the current location information of the user who uses the client system, and if there is a server that manages the user registration information, setting the information thereof may be performed.

The communication mode setting function may be set in a direct communication mode that enables direct communication between a terminal and a terminal and a communication mode via a server that enables communication between terminals via a relay server. The presence body format is user selectable between XPIDF and PIDF. The setting of the communication mode and the setting of the presence body format are used in the process of registering their own presence information and transmitting and receiving information related to the presence in the future.

FIG. 2 is a detailed configuration diagram of the UA extension application module shown in FIG. 1.

The user information registration service module 101 is the first module to be executed when the client system is driven. The user information registration service module 101 is configured to provide information on the configuration information such as the SIP URI and the current IP address, port, transport protocol, etc. of the user using the client system. Responsible for registering user information based on the specified value. The user information registration service module 101 calls the API of the SIP transaction module to generate a REGISTER message and delivers it to the registrar server 20 that manages current location information for each SIP URI.

The presence service module 102 includes an Event Publication Agent (EPA) module 1021, a Presence User Agent (PUA) module 1022, an Event State Compositor (ESC) module 1023, and a Presence Agent (PA) module 1024. It consists of.

In particular, the EPA module 1021, the PUA module 1022, the ESC module 1023, and the PA module 1024 related to the presence service function may be used when the user sets the environment such as the communication mode and the presence body format shown in Table 1. Based on the information set, the detailed processing function is affected.

The EPA module 1011 is responsible for generating, changing, updating, and deleting the user's own presence information. To this end, the EPA module 1011 generates a PUBLISH message and transmits the presence information to the ESC module 1023 managing the presence information. . At this time, depending on whether the communication mode shown in FIG. 2 is set to the direct communication mode or the communication mode via the server, whether to transmit a PUBLISH message to the ESC module 1023 provided in the client system, or the API of the SIP transaction module. Call to determine whether to send to the ESC module 1013 in the server (40).

The EPA module 1021, when in server-to-server communication mode (when the ESC module is outside the client system (shown in Figures 4 and 5)), encodes and sends a PUBLISH message in the form of a text stream to the IP address and port. Call the API of the SIP transaction module. In the case of the direct communication mode, the ESC module 1023 exists in the same client system, and the semantic information of the PUBLISH message is delivered to the ESC module 1023 in a structure of an internally defined SIP message.

The ESC module 1023 stores the presence information for the corresponding SIP URI if the PUBLISH message received via the communication network (direct communication mode) or from the EPA module in the same client system (via the server communication mode) is in a domain managed by the ESC module 1023. In charge of doing. At this time, the PUBLISH message transmitted through the communication network is parsed to be delivered to the SIP transaction module in the form of a stream and delivered to the ESC module as an internal structure.

The PUA module 1022 generates a SUBSCRIBE message for a user who is currently registered with a client system to register a subscription request (called a buddy), renew a period, and delete a user's presence information. Alternatively, the user's presence information is transmitted to the PA module of the client system that manages the user's presence information. After joining as a buddy, the NOTIFY message containing the presence information of the buddy is received from the PA module of another client system and presented to the user. .

The PA module 1024 receives a SUBSCRIBE message (from the PUA module of another client system) related to a buddy subscription request for a user registered on the client system to determine whether to allow the user who sent the subscription request as a buddy, If allowed, if a presence information of the corresponding user is changed, a NOTIFY message for periodically notifying the changed presence information to a user who is subscribed as a buddy is generated and transmitted to the PUA module of another client system.

The instant message service module 102 generates a MESSAGE message for exchanging instant messages, calls and transmits the API of the SIP transaction module to the destination client system, and parses the MESSAGE message stream received from another client system in the SIP transaction module. If you put it as an internal structure and pass it through the callback function, it handles the function. At this time, for a service having a high success rate, the MESSAGE message transmits the contact information to the destination when the presence information of the presence information acquired for the instance is online and there is contact information on the current location of the user.

The Internet telephony service module 103 is an RFC3261 User Agent (RFC3261 UA) module. The Internet telephony service module 103 transmits / receives messages such as INVITE, ACK, CANCEL, and BYE to / from the Internet telephony service module of another client system to provide a corresponding service. In this case, like the instant messaging service, if the presence information is online and the contact information on the current location of the user is obtained, the message is transmitted to the destination.

FIG. 3 shows the SIP message for each functional module of the UA extension application module 10 when the client system communicates directly with another client system without passing through the server, that is, when the communication mode shown in Table 1 is the direct communication mode. 4 is a diagram illustrating a transmission / reception relationship, and FIG. 4 shows each function of the UA extension application module 10 when the client system communicates with another client system via a server, that is, when the communication mode shown in Table 1 is an indirect communication mode. A diagram showing a transmission / reception relationship of SIP messages for each module.

3 and 4, in the communication mode via the server, the ESC module and the PA module are excluded from the UA extension application module 10, and these modules are embedded in the server 40 that mediates communication between client systems. It can be seen that. In the direct communication mode as shown in FIG. 3, the presence status information and the contact information of the current location of the other party are acquired by directly exchanging SUBSCRIBE and NOTIFY messages between client systems. In the communication mode, the presence status information and the contact information of the current location of the counterpart are acquired between the client systems through the exchange of SUBSCRIBE and NOTIFY messages through the presence server 40.

5 is a detailed functional module for a case where a client system directly communicates between client systems without passing through a server, and a transmission / reception relationship (shown in solid line) of SIP messages for each functional module and a communication between client systems via a server. It describes the transmission / reception relationship (marked with a dotted line) of each SIP message. That is, the message transmission / reception relations shown in FIGS. 3 and 4 are fused and presented.

Table 2 shows the presence related information managed by the client system.

Classification Meaning of each field SIP URI Information that uniquely identifies a user User instance identifier (InstanceID) Information to distinguish between multiple instances of the same user's SIP URI Presence status information Status information about the user's instance: online (registered and available for communication) and offline (unregistered, not available), and busy (registered but busy for other reasons). ), Members (registered, but unable to communicate due to empty work) can be expanded. Contact Information The current location information of the user instance can be used as a destination for the transmission of related messages in an additional extension service such as an instant message or an internet phone when the presence information is obtained. Presence information management identifier by user instance This information is used to change the presence status information for each user instance. It is allocated from the PA for version management and used for registration, change request, period change, and state change for the presence information of the corresponding user instance.

As shown in Table 2, the presence related information includes a SIP URI that can uniquely distinguish each user, a user instance identifier to distinguish each user's instance, presence status information for each user's instance, and an instance of each user. It is composed of contact information indicating the current location for and inducing future contact, presence information management identifier for each user instance, and the like.

Presence related information managed in the client system is used as the following criteria between the methods to be transmitted and received. The SUBSCRIBE and NOTIFY messages serve as a subscription and notification function for the user's SIP URI as the main destination, and the information delivered to the body contains information about all instances in the presentity SIP URI.

The PUBLISH message is a function for registering presence information on a user SIP URI and a user instance identifier. Information transmitted to a body includes information on a specific instance in a corresponding user SIP URI.

6A to 6D illustrate detailed function processing procedures of the EPA module 1021, the PUA module 1022, the ESC module 1023, and the PA module 1024.

It can be divided into four layers, and the GUI part of the application is responsible for interfacing with the user, and the upper layer of the application stores and manages the information in temporary structures that are delivered through the GUI or communication modules and the client system. It is responsible for passing information between internal structures. The lower layer of the application is responsible for transferring information between the internal structure information stored in the client system and the structure that can accommodate SIP messages used as interfaces in the SIP transaction layer of FIG. At the bottom of the SIP transaction, there are APIs provided by the SIP transaction, which start with TR, and there are functions that start with APP as the callback function of the UA extension application called by the SIP transaction.

In the EPA module of FIG. 6A, the user's presence state information is generated, changed, updated, and deleted. GUI_UpdatePresenceInfo () provides a changed state to the user, and EPA_UpdatePresenceInfo () provides his SIP URI in PresenceInfo of Table 3a. To store and maintain the most recent information about the presence status, EPA_SendPublish () allocates the necessary information for the PUBLISH message for transmission from PresenceInfo to the ESC module managing the user's own presence information, and TR_SendRequest ( ) Forwards the PUBLISH Request SIP message to the specified destination.

When a response (acceptance, rejection, error, etc.) to a PUBLISH SIP message sent from an ESC module managing user's presence information comes, it is first received by the SIP transaction module and transmitted to the application through APP_ReceiveResponse (). Responses to PUBLISH messages are handled through EPA_RecvResponse (), which stores the most recent information about the presence state change request in PresenceInfo through EPA_UpdatePresenceInfo () and keeps the most recent state changed to the user through GUI_UpdatePresenceInfo (). to provide.

In the ESC module of FIG. 6B, when a PUBLISH SIP message transmitted from the ESC module is received, the SIP transaction module first receives it and is delivered to the application through APP_ReceiveRequest (). The PUBLISH message is processed through ESC_RecvPublish (). If the received PUBLISH message is from a domain managed by the user, if the user is authenticated by applying AuthenticateInfo, etc. of Table 3d, the EBS_UpdatePresenceInfo () is used for the presence status change request. Save and maintain the most recent information, and provide the administrator with the most recent changed status through GUI_UpdatePresenceInfo (). In addition, a response (acceptance, rejection, error, etc.) to the PUBLISH SIP message is transmitted through ESC_SendResponse (), and a response is transmitted to the EPA through TR_SendResponse ().

In the PUA module of FIG. 6C, a request is made to subscribe to a specific user's presence information, and a subscription period is updated and deleted. GUI_UpdateSubscribeInfo () provides a changed state to a user, and PUA_UpdatePresenceInfo () is assigned to PresenceInfo of Table 3a. SUBSCRIBE message for allocating the SIP URI of the other party to subscribe to the SIP URI and SubscriberInfo to store and maintain the most recent information about the subscription request, and PUA_SendSubscribe () transmits to the other party's PA module from the SubscriberInfo of PresenceInfo. TR_SendRequest () sends the SUBSCRIBE SIP message to the designated destination.

When a response (acceptance, rejection, error, etc.) to a SUBSCRIBE SIP message sent from a PA module of a partner to join comes, it is first received by the SIP transaction module and transmitted to the application through APP_ReceiveResponse (). The response to the SUBSCRIBE message is processed through PUA_RecvResponse (), and the most recent information on the subscription status is stored in SUBSCRIBERInfo of PresenceInfo through PUA_UpdatePresenceInfo (). If you receive a NOTIFY message containing the presence information of the buddy after joining the buddy from the other party, it is first received by the SIP transaction module and transmitted to the application through APP_ReceiveResponse ().

The NOTIFY message is processed through PUA_RecvNotify (), saves and maintains the opponent's most recent presence status information in PresenceInstanceInfo list of PresenceInfo through PUA_UpdatePresenceInfo (), and provides the user with the most recent changed status through GUI_UpdatePresenceInfo (). . In addition, a response message indicating that the received NOTIFY message is well received is transmitted to the other PA module through PUA_SendResponse () and TR_SendResponse ().

In the PA module of FIG. 6D, when receiving a SUBSCRIBE message related to a buddy subscription request from the PUA module of another client system, the SIP transaction module first receives the SUBSCRIBE message and is delivered to the application through APP_ReceiveRequest ().

SUBSCRIBE message is processed through PA_RecvSubscribe (). If the received Subscribe message is from the domain that is managed by him, if the user is allowed by applying AcceptanceInfo of Table 3e, etc., it is impersonated to subscribe to SubscriberInfo of PresenceInfo through PA_UpdateSubscribeInfo (). It stores and keeps the latest information and provides the administrator with the most recent changed status through GUI_UpdateSubscribeInfo (). In addition, a response (acceptance, rejection, error, etc.) to the SUBSCRIBE SIP message is transmitted through PA_SendResponse (), and a response is transmitted to the PUA through TR_SendResponse ().

If you allow subscription to buddy, forward NOTIFY message containing your presence information to PUA module subscribed through PUA_SendResponse () and TR_SendResponse (), receive response to NOTIFY message from SIP transaction module, and APP_ReceiveResponse () Is passed to the application. The response message recognizes that the sent NOTIFY message was well processed through PA_RecvResponse ().

Tables 3a to 3e are information stored and managed by the client system mainly used in the upper and lower layers of the application. The services provided include registration, change and deletion of my status (presence information), addition and deletion of buddy-related functions, permission and prohibition of buddy requests from other parties, and the function of sending and receiving messages. Is done through.

PresenceInfo structure is largely maintained in list form. In Presenceinfo, PresenceTupleInfo structure, which is information about each instance, is in a list, and subscriber information is in list form of SubscribeInfo structure. In addition, it maintains AuthenticateInfo for authenticating subscriber and AcceptanceInfo for granting subscription.

PresenceInfo Classification Meaning of each field SIP URI Information that uniquely identifies a user List of PresenceInstanceInfo Since multiple instances may exist in a SIP URI of the same user, a presence information structure for each instance of the user is provided in a list form. List of SubscriberInfo Since there may be a plurality of subscribers who have requested the presence information for the designated user, the subscriber information structure for the user is provided in the form of a list. Subscription expiration information Information on the subscription period for which the presence information for the designated user is requested. It is basically designated as 1 hour, and it is used to request for re-registration periodically before the expiration of 1 hour if desired. Presence information management identifier by user instance This information is used to change the presence status information for each user instance. It is allocated from the PA for version management and used for registration, change request, period change, and state change for the presence information of the corresponding user instance.

PresenceInstanceInfo Classification Meaning of each field User instance identifier Information to distinguish between multiple instances of the same user's SIP URI Presence status information Status information about the user's instance: online (registered and available for communication) and offline (unregistered, not available), and basically busy (registered but busy for other reasons). ), Members (registered but not available for communication due to other work) can be expanded. Contact Information The current location information of the user instance can be used as a destination for the transmission of related messages in an additional extension service such as an instant message or an internet phone when the presence information is obtained.

SubscriberInfo Classification Meaning of each field SIP URI Information that uniquely identifies subscribers to be notified of presence information Subscription Status Information Subscription status of subscribers to be notified of presence information Subscription expiration information Period of validity of subscription, if subscriber is allowed to receive presence information Notification Event Unit Package It is possible to identify the case where the user wants to be notified of the presence information, and to expand the case where the presence information is notified to other groups. Instance related dialog information between two users allowed to join Dialog maintenance defined by SIP through two user instances for subscription and notification

AuthenticateInfo Classification Meaning of each field SIP URI Information that identifies the user involved in authentication Realm Realm information of HTTP Digest method to authenticate Domain HTTP Digest domain information to authenticate User ID User ID to be authenticated Password Password according to user ID to be authenticated

AcceptanceInfo Classification Meaning of each field SIP URI Information identifying the subscriber who requested to be notified of the presence information Allowed List List of Subscribers Allowed to Join Blocked List List of subscribers not allowed to join

So far I looked at the center of the preferred embodiment for the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

According to the present invention, a function of managing the presence information for the user himself and a package function for providing the subscription and notification of the presence information of other users by extending the function of the SIP user agent and providing the presence of other users Information (when the status information is online and there is contact information for the instance) is used to provide a more successful service when providing VoIP services such as instant messaging and Internet telephony. In particular, when resources are limited, such as a wireless network, it also provides an effect of reducing waste of resources.

In addition, the detailed structure of the SIP presence-based instant messaging and VoIP service client system proposed in the present invention is designed to be modularized by function, and the interface of each step provides a step-by-step procedure in the form of a detailed function or a library and is shown in FIG. As such, by providing a separate interface on the SIP transaction layer, the user can concentrate on the application independently of the transport protocol or the parsing and generation of SIP messages.

1 is a configuration diagram of a system disclosed in the present specification.

FIG. 2 is a detailed configuration diagram of the UA extension application module shown in FIG. 1.

3 is a diagram illustrating a transmission / reception relationship of SIP messages for respective functional modules of the UA extension application module when the communication mode is a direct communication mode.

4 is a diagram illustrating a transmission / reception relationship of SIP messages for respective functional modules of the UA extension application module when the communication mode is a communication mode via a server.

5 is a diagram illustrating a transmission / reception relationship of SIP messages for respective functional modules of the UA extension application module when two communication modes shown in FIGS. 3 and 4 are converged.

6A to 6D illustrate detailed function processing procedures of an EPA module, an ESC module, a PUA module, and a PA module.

Claims (7)

A user agent (UA) extension application module functioning as a SIP user agent; And Generate and send a SIP message stream suitable for API calls from the UA extension application module to another client system, and parse the SIP message stream received from the other system to provide a suitable callback function for the received SIP message. SIP presence module for instant messaging and Internet telephony service, characterized in that it comprises a SIP transaction module to call to notify the UA extension application module. The method of claim 1, wherein the extension application module A user information registration service module; Presence service module; An instant message service module for generating and transmitting a MESSAGE message for exchanging an instant message, or receiving and processing the MESSAGE message from another client system; And SIP presence based messaging and Internet telephony service client system comprising an internet telephony service module. The method of claim 3, wherein the presence service module An EPA module that generates a PUBLISH message to generate, change, renew, and delete the user's own presence related information; An ESC module that receives the PUBLISH message and stores presence information for a corresponding SIP URI if the PUBLISH message is in a domain managed by the user; Create a SUBSCRIBE message to request, renew or delete a subscription request to a buddy to know the presence information of a specific user, and receive a NOTIFY message containing the presence information of the buddy from another client system after joining the buddy. PUA module to present to the user; And Receiving the SUBSCRIBE message related to the buddy subscription request for the user managed by the user from the PUA module of the other client system to determine whether to allow the subscription to the buddy, and if the presence information for the user is changed to the buddy SIP presence based message and Internet telephony service client system comprising a PA module for generating a NOTIFY message for notifying the subscribed user of the changed presence information. 3. The method of claim 2, wherein the communication between the client system and another client system is SIP presence based message and Internet telephone service, wherein the PUBLISH message, the SUBSCRIBE message, and the NOTIFY message are exchanged directly between the two systems, or the messages are indirectly exchanged through a communication medium server between client systems. Client system. The method of claim 4, wherein the communication system between the two systems is SIP presence based message and Internet telephony service client system characterized in that it is determined by the user selected whether to use the direct exchange method or the indirect exchange method of the message. The SIP presence-based message and Internet telephony client according to claim 3, wherein the presence body format for processing the presence-related information supports PIDF and XPIDF to enable interoperation with various messenger services. system. 7. The SIP presence based message and Internet telephony client system of claim 6, wherein the presence body format is determined by the user.