KR20070069558A - Multi-party communication system and access method in access grid - Google Patents

Abstract

The present invention relates to a multi-party communication system and an method thereof in an access grid.

The present invention provides a multi-party communication system and a method in an access grid capable of various additional services by implementing a user invitation function and various additional functions necessary for this through a message processing process.

The present invention can be expected to provide an effect of providing a user invitation function and the additional function according to the AG (Access Grid) for remote collaboration.

Description

System and Method for Communicating Muti-User in Access Grid

1 is a block diagram showing the configuration of a multi-party communication system in an access grid according to an embodiment of the present invention.

2 is a diagram illustrating a process of implementing a user invitation function in a multi-party communication system of an access grid according to an embodiment of the present invention.

3 is a diagram illustrating a message processing process when a called client receives an invitation message from an originating client according to an embodiment of the present invention.

4 is a diagram illustrating a message processing process in an originating client when receiving a response message for a message transmitted from an originating client according to an embodiment of the present invention.

5 is a diagram illustrating a message processing process when a message is received by the bypass module of the venue server according to an exemplary embodiment of the present invention.

The present invention relates to a multi-party communication system and method thereof in an access grid, and more particularly, to a multi-party communication system and method in an access grid that provides a user invitation function and an additional function through a message processing process between a client and a server. It is about.

Access Grid (AG) is a distributed collaboration system developed by Argonne National Laboratory (ALN) in the United States, which allows video, voice, and data to be shared and communicated among multiple users on an Internet Protocol (IP) network. It was developed to provide a collaborative work environment.

The access grid is a computer network for applications that require distributed processing. It is a grid that dynamically connects resources according to user's work request, and supports large-scale distributed environment meetings, seminars, lectures, education, and training.

Conventional video conferencing systems provide remote users with an environment for meeting in a virtual space, whereas an access grid does not simply communicate with a face, but uses 3D data or other equipment to actually use the virtual environment. In terms of providing an environment in which a user can feel a sense of reality, there is an advantage that can support various collaborations while being different from the conventional video conferencing system.

Conventional video conferencing systems have conducted meetings by connecting to the Internet at scheduled times through advance appointments regarding meetings between meeting participants.

This means that meeting guidance and convocations take place offline, and attendance takes place online. Therefore, the conventional video conferencing system has a problem that a meeting can be performed only when a meeting reservation is recognized.

In addition, a multi-party communication method on the Internet may be a presence-based conference service system using a Session Initiation Protocol (SIP) protocol.

SIP is an application layer call signaling protocol that provides multimedia session establishment, session information exchange, and termination functions, and is an essential technology for developing various next generation Internet applications such as Internet telephony and multimedia messaging. In addition, SIP technology has become the core standard technology of instant messenger and presence service that is emerging as the next generation killer application after the web as well as Internet phone, and is adopted as the call control protocol in 3rd generation mobile communication service. As a result, R & D and standardization of related technologies and the development of SIP-based equipment and services are competitively pursued.

Here, the presence service refers to a service that provides a user with presence information such as checking location information of a user, checking a user's communication status, that is, checking a user's online or offline status, and checking a media type.

Instant messenger and presence services are a form of service that sends messages to users who are online using presence information.

With this in mind, the Access Grid, which provides a remote collaboration environment, can build a video conferencing system that enables a variety of additional services by adding the invite function and various additional functions required through the message processing process.

In the existing access grid, there was no user invitation function and schedule rejection function.

In order to solve the above problems, the present invention provides a multi-party communication system and a method in an access grid capable of various additional services by implementing a user invitation function and various additional functions required for this through a message processing process.

In order to achieve the above technical problem, a communication method of an originating client that implements a user invitation function in an access grid according to an aspect of the present invention includes (a) generating a first invitation message including information required for an invitation to perform a video conference. Transmitting to a Venue Server controlling the entire conference for doing so; (b) receiving, from the Venue server, an invitation success message generated by searching for an IP address corresponding to a Uniform Resource Identifier (URI) included in the first invitation message; (c) generating a second invitation message through the received invitation success message and transmitting the second invitation message to the called party client which is the IP address included in the invitation success message; And (d) receiving a response message indicating whether to approve the second invitation message.

According to another aspect of the present invention, a communication method of a Venue server implementing a user invitation function between an originating client and an incoming client in an access grid includes: (a) receiving and analyzing a message from the originating client; (b) searching for an IP address of the called client when determining that the analyzed message is an invitation message including information required for an invitation; (c) if it is determined that the analyzed message is a confirmation message, determining whether the set current mode is a registration mode and performing a message processing according thereto; And (d) when determining that the analyzed message is a registration message, changing the set current mode to a registration mode, and generating and transmitting a response message to the registration message.

A communication system for implementing a user invitation function between an originating client and a terminating client in an access grid according to another aspect of the present invention includes: a conference for connecting and receiving the originating client and the terminating client, transmitting and receiving media data, and performing a video conference Venue server to control; A location database server for receiving and storing a URI and an IP address of the originating client or the called client; And receiving the registration message from the originating client, transmitting the URI and IP address to the location database server, and when receiving the invitation message, the URI included in the invitation message. It includes a bypass module for transmitting the search result information of the matching IP (IP) address by transmitting to the location database server.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.

In addition, when a part is said to "include" a certain component, it means that it may further include other components, without excluding other components unless otherwise stated.

In addition, the term module described herein refers to a unit for processing a specific function or operation, which may be implemented in hardware or software, or a combination of hardware and software.

Now, a multilateral communication system and method thereof in an access grid according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram showing the configuration of a multi-party communication system in an access grid according to an embodiment of the present invention.

The multi-party communication system in the Access Grid (AG) includes an originating client 100, an incoming client 110, a Venue Server 120, and a location database 130.

The originating client 100 and the terminating client 110 collectively mean a personal digital assistant, a personal computer system (PC), etc. having an information processing function by wired / wireless communication and data input / output, and / or through a computer and / or Any device may be used as long as it is a terminal that is directly connected to the Internet and performs a call, and a terminal capable of transmitting and receiving wireless data with the Venue server 120 through a communication network.

In the embodiment of the present invention, the originating client 100 refers to a side for transmitting an invitation message, and the called client 110 refers to a side for receiving an invitation message. same.

The originating client 100 and the terminating client 110 include a message processing module 102 and a media stream processing module 104.

The message processing module 102 requests the client for the location of the Venue Server 120 for address retrieval, the Uniform Resource Identifier (URI) and Display Name (URI) to be used, and the path where the media stream processing module 104 is installed.

The message processing module 102 defines a message type such as an invitation message, a registration message, a response message, an acknowledgment message, and a message mode for distinguishing the current state to implement the user invitation function. 110) processes the messages sent and received between. In addition, the message processing module 102 is automatically registered and executed as a tray icon of a window whenever the originating client 100 and the terminating client 110 are executed, which provides an environment that can always respond to an invitation of the other party. .

The media stream processing module 104 transmits / receives voice, video, still image, text, etc. between the venue server 120 and the client to enable real-time playback, and the originating client 100 and the terminating client 110 are connected to the venue server 120. ) To connect.

Venue server 120 controls the entire conference for video conferencing, such as user invitation, multicast security function, event suspension, service matching and media (voice, video, etc.) data processing. In addition, the venue server 120 may additionally configure a redirect module to support a user invitation function and corresponding additional functions.

Here, the bypass module may be included as a component in the interior of the venue server 120, and may be separately configured externally.

The bypass module receives the registration message from the originating client 100 and transmits the registration message to the location database server 130 interworking its URI and IP (Internet Protocol) address included in the message.

When the detour module receives the invitation message from the originating client 100, the detour module transmits the URI included in the invitation message to the location database server 130 linked with the IP address. The bypass module then sends the search result information received from the location database to the originating client 100.

The location database server 130 temporarily stores a message transmitted and received from the client, and stores an IP table in which the IP address of the client is stored.

The location database server 130 receives a message set from the client, an IP address for knowing the location of the client, URI information, and the like, and updates, registers, and stores the database information. In addition, the location database server 130 is automatically registered and stored when the setting information of the originating client 100 or the terminating client 110 changes.

The location database server 130 may be installed separately inside or outside the venue server 120.

The multi-party communication system of the access grid of the present invention may configure the originating client 100, the terminating client 110 and the Venue server 120 in one or more numbers.

2 is a diagram illustrating a process of implementing a user invitation function in a multi-party communication system of an access grid according to an embodiment of the present invention.

When the originating client 100 wants to invite the incoming client 110 to a particular Venue server 120, the originating client 100 includes information necessary for the invitation (such as the URI of the destination Client 110 and the address of the Venue server 120 to access). The invitation message is transmitted to the Venue server 120 (S200).

The Venue server 120 receiving the invitation message transmits the URI included in the invitation message to the location database server 130 interworking with each other, and retrieves the IP address matching the URI from the location database server 130. Search result information is received (S202).

Here, the invitation message is used as a message sent by the calling client 100 to the called client 110 to invite the called client 110 or the IP address of the called client 110 from the bypass module of the Venue server 120 is used. This is a message sent to the Venue Server 120 to find out.

Venue server 120 receiving the search result information from the location database server 130, if the URI cannot be retrieved through the search result information, generates an invitation failure message and transmits to the calling client 100, the search result If the corresponding URI is searched through the information, an invitation success message is generated and transmitted to the calling client 100 (S204). Subsequently, the originating client 100 receiving the invitation success message generates an invitation message and transmits the invitation message to the IP address of the destination client 110 included in the invitation success message (S206).

Upon receiving the invitation message, the called client 110 determines whether a specific schedule is set that does not allow the invitation request of the originating client 100, and when the specific schedule is set, generates an invitation rejection message to generate the invitation client 100. In step S208.

When the called client 110 determines that a specific schedule is not set, the called client 110 outputs a signal for asking whether to accept or reject the invitation.

When the destination client 110 receives the signal for rejecting the invitation, the destination client 110 generates a final invitation failure message and transmits it to the calling client 100 (S208).

When the incoming client 110 receives a signal for approving the invitation, the destination client 110 operates the media stream processing module 104 to access the corresponding Venue server 120 using the information included in the invitation message (S210). The destination client 110 reconnects to the corresponding venue server 120 if the media stream processing module 104 is already executed (S210).

3 is a diagram illustrating a message processing process when an incoming client 110 receives an invitation message from an originating client 100 according to an exemplary embodiment of the present invention.

As shown in FIG. 3, when the destination client 110 receives a message from the originating client 100, the destination client 110 analyzes the type of the received message.

When the called client 110 determines that the received message is the invitation message, the destination client 110 changes the currently set mode to the invitation mode (S300).

Here, the invitation mode is set when the invitation message is transmitted from the originating client 100 or when the invitation server 120 receives the invitation message.

Here, the invitation message is used as a message sent by the calling client 100 to the called client 110 to invite the called client 110 or the IP address of the called client 110 from the bypass module of the Venue server 120 is used. This is a message sent to the Venue Server 120 to find out.

Subsequently, the called client 110 determines whether a specific schedule is set that does not allow the invitation request of the originating client 100 (S302).

If it is determined in step S302 that the specific schedule is set, the destination client 110 compares the time information of the schedule with the time information (one or more of the month, day, hour) of the received invitation message and determines whether it matches ( S304).

If it is determined in step S304 that the time information of the schedule and time information of the received invitation message are compared and matched, the destination client 110 generates an invitation rejection message and transmits it to the calling client 100 (S306).

When it is determined in step S302 that the specific schedule is not set, the destination client 110 generates and outputs an approval request message, and determines whether a response message to the outputted approval request message is received (S308). ).

When it is determined in step S304 that the time information of the schedule and the time information of the received invitation message are not matched, the destination client 110 generates and outputs an approval request message, and responds to the outputted approval request message. It is determined whether is received (S308).

When receiving a response message indicating the rejection of the invitation to the approval request message in step S308 (that is, when rejecting the invitation request of the originating client 100), the destination client 110 generates an invitation rejection message to generate the originating client 100. (S306).

When receiving a response message indicating the invitation approval for the approval request message in step S308 (that is, when the invitation request of the originating client 100 is approved), the destination client 110 generates an invitation approval message to generate the originating client 100. (S310). Subsequently, the called client 110 determines whether the media stream processing module 104 is operating (S312), and if it is determined that the media stream processing module 104 is not operating, the Venue included in the received invitation message is received. The server 120 accesses the corresponding venue server 120 using information such as the location of the server 120 (S314). In addition, when the destination client 110 determines that the media stream processing module 104 is already operating, the destination client 110 reconnects to the corresponding venue server 120 (S316).

4 is a diagram illustrating a message processing process in the originating client 100 when receiving a response message for a message transmitted from the originating client 100 according to an exemplary embodiment of the present invention.

The originating client 100 and the terminating client 110 include a message processing module 102 and a media stream processing module 104. The description thereof will be omitted due to the relationship described with reference to FIG. 1.

The state mode of the message processing module 102 is divided into a ready mode, a register mode, a resolve mode, and an invite mode.

Here, the preparation mode is set to receive a different message after a transaction for processing one message is finished.

Here, the registration mode is set when the registration message is transmitted from the client side or when the registration message is received from the venue server 120.

Here, the resolution mode is when the originating client 100 transmits the invitation message to the bypass module of the Venue server 120 to transmit the invitation message to the destination client 110 or the bypass module of the Venue server 120 is the invitation message. It is set when receiving.

Here, the invitation mode is set when the invitation message is transmitted from the originating client 100 or when the invitation server 120 receives the invitation message.

The originating client 100 receives the message and analyzes the type of the received message (S400).

The originating client 100 determines whether the current mode of the originating client 100 is set to a registration mode, a resolution mode, or an invitation mode (S402).

When the originating client 100 determines that the current mode is the registration mode and receives the response message in the registration mode, the originating client 100 analyzes the received response message (S404).

The originating client 100 checks whether the registration is successful / failed through the received response message, and generates a confirmation message and transmits the confirmation message to the originating side of the response message (the inbound client 110 or the bypass module of the venue server 120). (S406).

Here, the response message receives the invitation message or the registration message and informs the processing result thereof.

Here, the registration message functions to register its own Uniform Resource Identifier (URI) or IP address to the Venue Server 120 so that the partner can search for its current location (Internet Protocol (IP) address).

Here, the confirmation message serves to confirm whether a response message has been received.

When the originating client 100 determines that the current mode is the resolution mode and receives the response message in the resolution mode, the originating client 100 analyzes the received response message (S408).

The originating client 100 transmits the confirmation message to the originating side of the response message (bypassing module of the terminating client 110 or the Venue server 120) (S410), and changes the resolution mode set to the current mode to the preparation mode ( S412).

The originating client 100 analyzes the status code included in the response message to determine whether the address search of the destination client 110 to which the invitation message is to be transmitted is successful (S414).

If it is determined in step S414 that the address search has failed, the originating client 100 ends the timer executed when the invitation message is transmitted, generates and outputs an invitation failure message (S416).

If it is determined in step S414 that the address search is successful, the originating client 100 changes the current mode to the invitation mode (S418), generates an invitation message and transmits it to the address of the retrieved called client 110 (S420).

When the originating client 100 determines that the current mode is the invitation mode and receives the response message in the invitation mode, it indicates that the called client 110 has responded to the invitation message, so the timer is terminated and the received response message is received. Analyze (S422).

The originating client 100 generates a confirmation message and transmits it to the called client 110 (S424), and analyzes the status code included in the received response message to determine whether the invitation request is successful (S426).

The originating client 100 generates and outputs an invitation failure message when the terminating client 110 rejects the invitation request by using the analyzed status code (S428), and when the terminating client 110 approves the invitation request, the invitation is invited. Generate and output a success message (S430).

5 is a diagram illustrating a message processing process when a message is received by the bypass module of the venue server 120 according to an exemplary embodiment of the present invention.

The detour module of the Venue server 120 receives the message and analyzes the type of the received message (S500).

When the bypass module of the Venue server 120 receives the registration message, the bypass module changes the current mode to the registration mode (S502). In addition, the bypass module of the Venue server 120 analyzes the received registration message and transmits a response message to the client which is the sender of the registration message (S504 and S506).

When the bypass module of the Venue server 120 receives the invitation message, the bypass module changes the current mode to the resolution mode (S508). In addition, the bypass module of the venue server 120 analyzes the received invitation message and extracts a URI included in the invitation message (S510).

The bypass module of the Venue server 120 transmits the extracted URI to the coordinated location database, and receives the search result information for searching whether there is an IP address corresponding to the URI in the IP table of the location database.

The bypass module of the venue server 120 determines whether there is an IP address corresponding to the URI by using the search result information (S512).

If it is determined in step S512 that the IP address matching the URI exists, the bypass module of the Venue server 120 generates a search success message containing the IP address and transmits it to the client that is the originator of the invitation message (S514). .

If it is determined in step S512 that the IP address corresponding to the URI does not exist, the bypass module of the Venue server 120 generates a search failure message and transmits it to the client which is the sender of the invitation message (S516).

When the bypass module of the Venue server 120 receives the confirmation message, it determines whether the current mode is set to the registration mode (S520).

If it is determined in step S520 that the current mode is set to the registration mode, the URI and IP address included in the confirmation message are registered and stored in the location database, and the current mode is changed to the ready mode (S522 and S524).

If it is determined in step S520 that the current mode is not set to the registration mode, the bypass module of the venue server 120 performs an exception processing function (S526).

Here, the exception handling function refers to a function of deleting a message when a procedure out of a series of processes such as a registration message-> a confirmation message is performed out of a series of processes such as a registration message-> a response message-> a confirmation message.

The embodiments of the present invention described above are not implemented only through the apparatus and the method, but may be implemented through a program for realizing a function corresponding to the configuration of the embodiment of the present invention or a recording medium on which the program is recorded. Implementation may be easily implemented by those skilled in the art from the description of the above-described embodiments.

Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

According to the above configuration, the present invention can be expected to provide an effect of providing a user invitation function and thereby additional functions in an access grid (AG) for remote collaboration.

The present invention can be expected to provide an effect of providing a user invitation function and additional functions without a separate system change in the conventional AG (Access Grid).

The present invention can expect the effect of connecting the desired partner to the desired Venue server even in a dynamic IP environment in which the IP address is changed.

Claims (15)

In the communication method of the outgoing client to implement the user invitation function in the access grid (a) generating a first invitation message including information required for an invitation and transmitting the same invitation message to a Venue Server that controls the entire conference for a video conference; (b) receiving, from the Venue server, an invitation success message generated by searching for an IP address corresponding to a Uniform Resource Identifier (URI) included in the first invitation message; (c) generating a second invitation message through the received invitation success message and transmitting the second invitation message to the called party client which is the IP address included in the invitation success message; And (d) receiving a response message indicating whether to approve the second invitation message; Multi-party communication method in an access grid comprising a. The method of claim 1, wherein in step (b), (b1) receiving a response message indicating a result of processing the received message, and analyzing the set current mode; (b2) if it is determined that the set current mode is an invitation mode, analyzing the response message to determine whether to allow the invitation request; (b3) generating and transmitting the second invitation message when it is determined that the analyzed current mode is a resolution mode; And (b4) if it is determined that the analyzed current mode is a registration mode, generating and transmitting a confirmation message indicating whether the response message has been received; Multi-party communication method in an access grid comprising a. The method of claim 2, wherein in step (b2), Receiving a response message indicating a result of processing the received message, and analyzing a set current mode; If it is determined that the set current mode is the invitation mode, ending a timer and analyzing the received response message; Analyzing a status code included in the received response message to determine whether the invitation request is successful; And Generating and outputting an invitation success message when the invitation request is approved; and generating and outputting an invitation failure message when the invitation request is rejected Multi-party communication method in an access grid comprising a. The method of claim 2, wherein in step (b3), If it is determined that the analyzed current mode is a resolution mode, generating and transmitting a confirmation message indicating whether the response message has been received, and changing the resolution mode to a ready mode; Analyzing a status code included in the response message to determine whether an address search of the called client to which the invitation message is to be sent is successful; And If it is determined that the address search is successful, changing the current mode to the invitation mode, generating the second invitation message, and transmitting the second invitation message to the called client; Multi-party communication method in an access grid comprising a. A communication method of an incoming client receiving an invitation message from an originating client that implements a user invitation function in an access grid, (a) receiving an invitation message and determining whether to accept the invitation request; (b) generating and outputting an approval request message when the invitation request is allowed in step (a); (c) determining whether a response message to the outputted approval request message is received in step (b); And (d) generating an invitation approval message and transmitting it to the calling client when the response message indicates the invitation approval; Multi-party communication method in an access grid comprising a. The method of claim 5, wherein in step (a), (a1) determining whether a specific schedule is set that does not allow an invitation request from the calling client; And (a2) if it is determined in step (a1) that the specific schedule is set, comparing the time information of the set schedule with the time information of the received invitation message and determining whether or not there is a match Multi-party communication method in an access grid comprising a. The method of claim 5, wherein after step (d), (e) determining whether the media stream processing module is operating; (f) In step (e), if it is determined that the media stream processing module is not operating, a Venue for controlling the entire conference for conducting a video conference using the received invitation message by executing the media stream processing module. Connecting to a server; And (g) re-connecting to the Venue server if it is determined in step (e) that the media stream processing module is operating; The multi-party communication method in the access grid further comprising. The method of claim 5, And in the step (a), disallowing the invitation request or if the response message indicates the invitation rejection, generating and sending an invitation rejection message to the originating client. In the communication method of the Venue server implementing the user invitation function between the originating client and the destination client in the access grid, (a) receiving and analyzing a message from the originating client; (b) searching for an IP address of the called client when determining that the analyzed message is an invitation message including information required for an invitation; (c) if it is determined that the analyzed message is a confirmation message, determining whether the set current mode is a registration mode and performing a message processing according thereto; And (d) if it is determined that the analyzed message is a registration message, changing the set current mode to a registration mode, and generating and transmitting a response message to the registration message; Multi-party communication method in an access grid comprising a. The method of claim 9, wherein in step (b), If it is determined that the analyzed message is an invitation message including information required for an invitation, extracting a URI included in the invitation message; Determining whether an IP address corresponding to the extracted URI is present; And If it is determined that the IP address matching the extracted URI is present, generating and transmitting an invitation success message including the IP address. Multi-party communication method in an access grid comprising a. The method of claim 9, wherein in step (c), (c1) if it is determined that the analyzed message is a confirmation message, determining whether the set current mode is a registration mode; (c2) if it is determined that the set current mode is the registration mode, storing a URI and an IP address included in the confirmation message; And (c3) changing the registration mode to a ready mode Multi-party communication method in an access grid comprising a. The method of claim 11, And if it is determined in step (c1) that the set current mode is the registration mode, deleting the received message. A communication system for implementing a user invitation function between an originating client and an incoming client in an access grid, A Venue server which connects the originating client and the terminating client to transmit and receive media data and control conferences for video conferencing; A location database server for receiving and storing a URI and an IP address of the originating client or the called client; And Receiving a registration message from the originating client to transmit the URI and IP address to the location database server, and when receiving an invitation message, the URI contained in the invitation message Bypass module receiving the search result information of the matching IP (IP) address transmitted to the location database server Multi-party communication system in the access grid comprising a. The method of claim 13, The bypass module is a multi-party communication system in an access grid, characterized in that included as a component in the interior of the Venue server or configured separately externally. The method of claim 13, The originating client or the destination client may define a status mode and a message to implement the user invitation function, process a message processing module that processes the transmitted and received messages, the media data, and the originating client or the destination client. And a media stream processing module performing a function of accessing the venue server.

Images