Method for instant scheduling of conference calls

Description of equivalent WO 2007011234 A1

METHOD FOR INSTANT SCHEDULING OF CONFERENCE CALLS

Field of the invention

The present invention relates to managing, scheduling and initiating video conferences. Background of the invention

Conventional videoconferencing systems comprise a number of end-points communicating real-time video, audio and/or data streams over and between various networks such as WAN, LAN and circuit switched networks.

A number of video conference systems residing at different sites may participate in the same conference, most often, through one or more MCU's (Multipoint Control Unit) performing i.a. switching functions to allow the audiovisual terminals to intercommunicate properly.

As videoconferencing involves various recourses and equipment simultaneously interoperating at different localizations and capabilities, there is a need for the possibility to manage the resources involved both for scheduled and ad hoc video conferences .

Videoconferencing systems are therefore often provided with a management system. A management system is a module that is used to schedule or book resources at any given point in time. The management system will allow a user to request resource usage at a given time, and either allow or disallow the usage at that time.

Management systems are often used for scheduling the use of meeting rooms, network resources, video systems etc. The management system must be connected to a database containing updated information regarding all accessible resources like MCU's, gateways, routers, end -points et.c. A management system may e.g. provide system and resource overview, allowing the user to create, edit, and delete reservations, reserve resources for dial-in participants and specify bandwidth and network settings. The management system may also support automatic call routing and automatic selection of point-to-point connection, including one or more MCU's. The management system normally operates with an intuitive web interface requiring no additional installation on the user terminal other than a conventional web browser.

Even if users have audio or videoconferencing equipment available, either as personal or group systems, a large problem with scheduling meetings using audio- and videoconferencing equipment is knowledge of which resources are available to a given participant. In many cases, it is necessary for the one that is booking the conference to ask the participants in person about which localizations and systems etc. axe accessible to them at the particular moment, and which accessories and services they have available or which is preferable. This manual "round-robin" request is added to the use of a management system, causing delay in conference booking and reducing the utilitarian value of the management system. The lack of knowledge regarding the participants' access and preferences is also the main reason that ad-hoc conferences are difficult to set-up — they simply require too much fluctuating knowledge of the far end side from the users.

Another problem regarding ad-hoc scheduling is that even if the management system knows that a certain end-point is available and ready for use, it cannot know whether the participants are present at the different sites, when the video conference is not pre-scheduled. Ad-hoc booking will then normally also require manuals requests in the form of additional calls to the participants in advance, making it behave like a pre-scheduled call.

These problems are now more often met by connecting the management system to a presence application. Presence applications are known as applications indicating whether someone or something is present or not. A so-called "buddy list" on a user terminal shows the presence of the people or systems (buddies) that have been added to the list. The list will indicate if the "buddy" is present or not (logged on the computer, working, available, idle, or another status). The presence functionality creates a feeling of presence also with people or things that are located in other buildings, towns, or countries.

Presence applications are often found in conjunction with Instant Messaging (IM) applications. These applications extend the presence application by adding the possibility of exchanging information between present "buddies". The information exchange may include applications like chat, messaging and conferencing.

In Presence and IM applications, there is a central server keeping track of all the clients in the system, while the client provides the server with information about their own state and location. The server also handles user login and provide information of the "buddies" in respective "buddy list" by using a proprietary protocol. However, information between clients ("buddies") may be transmitted directly as the server provides connection information (IP address and port number) of the client's "buddies". ■

Conventionally, the protocol used in the application layer of IM communication is SIP (Session Initiated Protocols). SIP is an Internet Engineering Task Force (IETF) standard protocol for initiating an interactive user session that involves multimedia elements such as video, voice, chat and gaming. SIP is a request-response protocol, dealing with requests from clients and responses from servers. Participants are identified by SIP URIs. Requests can be sent through any transport protocol, such as UDP, SCTP, or TCP. SIP determines the end system to be used for the session, the communication media and media parameters, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles call transfer and termination. As already indicated, SIP requires a central server i.a. for signalling, registration and policy handling. Such SIP servers are usually integrated with the presence server mentioned above in connection with presence and IM applications.

Microsoft Live Communications Server (LCS) is an example of server software for presence and IM applications, where users can send instant messages and communicate using web cameras through an IM client such as MS Communicator or Windows Messenger.

The connection between the presence application and the management system may appear for the users in many ways. The most convenient would probably be to integrate the management system in the IM/Presence application or vice versa. Hence, allow the user to see the presence of both the user and system. A double click on a "buddy" in a "buddy list" may e.g. execute an immediate initiation of a call set up to the "buddy" using the most preferred idle system associated with the "buddy". A click on further "buddies" preferably includes them in the call constituting a conference, all provided by the functionalities already available in the management system. The management system rriay be instructed by requests from the presence application using the proprietary protocol.

However, management systems and IM applications are developed for different purposes and uses different protocols. The integration of these different "worlds" often requires non-proprietary solutions and additional processing power. This is an obstacle for i.a. interoperability between vendor products, which again is an obstacle for the penetration of communication applications.

Summary of the invention

It is an object of the present invention to provide a method and a . system avoiding the above described disadvantages.

It is a further object of the present invention to provide a method and a system for integrating conventional IM application with conventional management system in a non-proprietary and process effective way.

The method and system according to the invention are defined by the features set forth in the appended, independent claims. Advantageous features are indicated in the dependent claims. In particular, the present invention provides a method for establishing a call in a communication system including an Instant Messaging (IM) application provided by a Session Initiated Protocol (SIP) server connected to a number of IM clients, each associated with at least one conference endpoint managed by one or more management systems at least adapted to schedule and/or investigate possibilities for a conference between two or more individuals, including the steps of transmitting a first SIP invite message from an inviting IM client to the SIP server including a Global Unique Identifier (GUID), first SIP Uniform Resource Identifier (URI) identifying said inviting IM client and a second SIP URI identifying an invited IM client, at reception of said first SIP invite message in the SIP server, investigating in the management system whether the respectively associated endpoint of said inviting IM client and said invited IM client satisfy a set of conditions, at least including whether the respective associated endpoints are idle, if said set of conditions are satisfied, transmitting a second SIP invite message from the SIP ' server to said invited IM client, if said SIP invite message is accepted by said invited IM client, returning a SIP invite accept message to the SIP server and instructing the management system to set up a call between the respectively associated endpoint of said inviting IM client and said invited client.

The invention also relates to a communication system including an Instant Messaging (IM) application provided by a Session Initiated Protocol (SIP) server connected to a number of IM clients, each associated with at least one conference endpoint managed by one or more management systems at least adapted to schedule and/or investigate possibilities for a conference between two or more individuals. In the system, an inviting IM client is arranged for transmitting to the SIP server a first SIP invite message including a Global Unique Identifier (GUID), a first SIP Uniform Resource Identifier (URI) identifying said inviting IM client and a second SIP URI identifying an invited IM client. Also, the SIP server is arranged for, at reception of said first SIP invite message, investigating in the management system whether the respectively associated endpoint of said inviting IM client and said invited IM client satisfy a set of conditions, at least including whether the respective associated endpoints are idle. The SIP server is further arranged for, if said set of conditions are satisfied, transmitting a second SIP invite message to said invited IM client, receiving from said invited IM client if said SIP invite message is accepted by said IM client, a SIP invite accept message, and instructing the management system to set up a call between the respectively associated endpoint of said inviting IM client and said invited client.

Brief description of the drawings In order to make the invention more readily understandable, the discussion that follows will refer to the accompanying drawings,

Figure 1 is a system overview of the combination of a conference management system and an IM application according to prior art, Figure 2 is a system overview of one embodiment of a system according to the present invention,

Figure 3 illustrates the message flow in an accepted call invitation according to one embodiment of the present invention, Figure 4 illustrates the message flow in rejected call invitation according to one embodiment of the present invention.

Best mode of carrying out the invention

In the following, the present invention will be discussed by describing preferred embodiments, and by referring to the accompanying drawings. However, people skilled in the art will realize other applications and modifications within the scope of the invention as defined in the enclosed independent claims.

The present invention introduces a novel mechanism for IM client end users who want to use desktop Video Conferencing System (VCS) instead of an integrated software/web-camera video conferencing solution. This is utilised by using a management system as mentioned above, or in this context, a Video Conference Management Programme (VCMP), to set up video conference calls between any from a IM client, even ISDN based VCS 's. Having a VCMP to manage the call also allows calls between protocols if a network gateway is available for use. In addition, an administrator can monitor the status of the call and the VCMP can store call logs and statistics. This is provided by the present invention by integrating

VCMP' s with presence an IM servers like Microsoft's Live Communication Server (LCS) in a non-proprietary way. The extensibility of e.g. the IM clients MS Communicator and Windows Messenger allows very little customization of the user interfaces. To ease the deployment of such an integration, the present invention preferably makes the installation of the integration a server-side component, with only configuration requirements on the clients.

Conventional IM clients allow a "custom application" to be defined, which uses a protocol where one IM client user invites a buddy to a session of this application, and waits for his approval. According to the present invention, a video - or alternatively, a web conference is defined as such an application, and processing the invites and acceptances of these requests on e.g. an LCS server. A VCMP, with which the LCS server is integrated, will then be instructed to book the VCS 's and set up a call between the VCS 's of the inviter and the invited "buddy".

The IM client users then have to be bound to a specific VCS that is managed by the VCMP. This is done either by logging on to the VCMP server through a web browser, or by adding a custom tab page in the IM client that shows a web page on the VCMP server. The IM clients will, as already indicated, be connected to a SIP server i.a. keeping track of applications, user presence, handling and forwarding SIP messages etc. Further, Registry keys defining the actions that are to be made available from the User Interface (UI) of the IM client are added in the Registry of the IM client computers. Each action then has a unique id (a GUID) that identifies the action, and a name of the action as it is shown to the IM user. In the context of the present invention, an application with the identical unique id must have been defined in the registry on both the inviter and the invitee of a call.

Figure 2 shows the overall architecture of a preferred embodiment of a system according to the present invention. In addition to the IM Clients, the VCMP server and the VCS systems, the SIP Server is added with a VCMP Integration software, and is connected to the VCMP server through a web service interface.

In the following an example of the message flow of an example of the present invention is described, referring to figure 3 and 4. When a user wishes to initiate a video call through his IM client, he may click on a certain call icon associated to the invited "buddy" in his buddy list. This Will trigger a transmission of a SIP invite message containing the unique application id and the SIP uri of both the inviter and invitee to the SIP server. The SIP message is processed by the integration software on the SIP server. This software contacts the VCMP (using web services) to verify that both the users have associated a preferred VCS, that these VCS 's are not currently in use, that the users have permissions to use them and that all (if any) required network components (e.g. an MCU) for the requested call are available.

If any of these conditions are not met, an IM bot, called a 'video conference assistant' (VCA), sends an instant message to the inviter describing the reason for failure and cancels the invitation. An IM bot is a virtual "buddy" in IM application automatically generating IM messages for assistance and information.

However, if all the conditions are met, the invitation is forwarded to the invitee in another SIP invite message. The integration will then preferably tentatively book the systems for use by the inviter. If the invitee accepts the invitation, a SIP accept message is returned to the SIP server and is processed by the VCMP integration software. The VCMP integration software remotely instructs the VCMP to start the call, and to book the resources to be used.

Also, a thread in the SIP server will preferably start polling the VCMP for status of the call. The VCA is then able to inform the parties about the status of the call through the IM application, As an example, if there was an error setting up the call, the reason for this will be reported to the IM user in an instant message from the VCA. The procedure above could also be applicable for establishing a web conference. Then, the SIP invite message will make sure web conferencing is available from the VCMP₅ and the accept message will book a web conference using a predefined or randomly generated password. The url and password needed to join the web conferences will be sent to both the inviter and the invitee from the VCA, in form of instant messages.

In order to select which VCS is to be used (per IM user), an account or user profile may be configured with a primary system in the VCMP (or other means - such as my "virtual (personal) resource. This operation can be incorporated into the IM client by using custom tab pages. These are added by creating a registry key (taburl) that points to an (auto-generated) xml document on the web server of the VCMP. This xml document contains the url of the web page that is to be shown in the IM client as a tab page. When the IM user opens this tab, a log-on to the VCMP web server must be performed, and the VCMP is therefore able to identify and authenticate the user. The page will be rendered in the built in browser of the IM client. The IM user also has the possibility to end any call running on his primary VCS from this page, as well as call any other H320/H323/SIP VCS directly or ' through a gateway.

One of the advantages of the present invention is that from the VCMP point of view it simplifies ad-hoc scheduling of VCS 's for the end users, and makes video conferencing more available to users.

Further, from the SIP point of view, the present invention allows non-SIP VCS 's to be called to and from, directly from the IM client.