RU2377640C2 - Architecture for extensible system for real time interoperation - Google Patents

Abstract

FIELD: physics; computer engineering.

SUBSTANCE: group of inventions relates to apparatus for a unified application programming interface for writing application programs which use communication protocols. The architecture has action objects, terminal point objects and several multimedia stacks. These objects can use different communication protocols, such as Session Initiating Protocol or Real-time Transport Protocol, for sending and receiving messages. Each of the action objects, terminal point objects and several multimedia stacks has one or more application programming interfaces (API), which an application developer can use to access or provide functionalities related to interoperation. These objects display API on a basic realisation provided by other objects. Use of action objects enables a developer to provide less amount of application logic than would have been required in a different case to provide complex interoperation services.

EFFECT: provision for additional functions for interoperation in an application in real time.

17 cl, 5 dwg

Description

Cross references to related applications

This application claims the priority of provisional patent application US 60/513790 from 10.23.2003, application 60/599807 from 08/06/2004, application 10/918333 from 08/13/2004 and application 10/918855 from 08/14/2004.

Technical field

The technology described generally relates to data transmission and, more specifically, to the architecture for an extensible real-time collaboration system.

State of the art

Various communication applications and protocols provide communication between software programs or users. As an example, real-time communication applications, such as MICROSOFT WINDOWS MESSENGER (Microsoft Windows messaging service) and Voice over Internet Protocol (VoIP), provide communication between users sending text, video to each other - or voice data. These applications can use various protocols, such as SIP (Session Initiation Protocol), RTP (Real-Time Transmission Protocol), RTCP (Real-Time Control Protocol), to establish sessions and to transfer information related to transmissions. SIP is an application layer control protocol that devices can use to discover each other and to establish, modify, and end sessions between devices. RTP is a protocol for delivering audio and video data over the Internet and is often used in streaming multimedia systems and video conferencing systems in conjunction with other protocols such as RTCP and H.323. RTCP is a protocol that enables a client application to control and manage data transmitted or received using the RTP protocol and is used in conjunction with the RTP protocol. SIP and RTP / RTCP are the standards proposed for the Internet. Their specifications “RFC 3261” and “RFC 3550” are available online at www.ietf.org at /rfc/rfc3261.txt and at www.faqs.org at /rfcs/rfc3550.html, respectively, and are incorporated into this document by in its entirety by reference.

Applications may optionally use other protocols. Applications can use enhanced versions of the above protocols or other different protocols that are designed to send specialized data. As an example, when a new or improved protocol for sending video conferencing information becomes available, it may be desirable for an application developer creating or modifying an application to use a new or improved protocol, for example, to improve performance or provide additional features. To use a new or improved protocol, the application developer may need to modify parts of the application that interact with communication protocols, since a protocol improvement or a new protocol may have an interface that is different from the one that was previously used. As an example, although the protocol may have a NewSession interface for creating a new session, the enhanced version may include the StartSession method, which creates and starts a session and receives additional parameters. Since StartSession receives additional parameters, its interface is different from NewSession, and therefore an application using NewSession may require modification to use StartSession. If the protocol has a different interface, application developers may need to examine this different interface and modify their applications to use this interface to apply the protocol.

Application developers may need to study the detailed features of each of the many communication protocols that they use in developing applications. As an example, if the application developer uses the SIP or RTP / RTCP protocol, the application developer may need to study all three protocols in order to provide the programming logic associated with these protocols. An application developer who is not familiar with all three protocols may need additional training and time to become familiar with all of these protocols. In addition, if an application needs to be modified to work with additional or enhanced protocols, the application developer may need to revise or supplement the programming logic so that the application can function with these protocols. This can lead to additional costs and development difficulties.

In addition, various protocols present many complexities. For example, in order to provide video conferencing functionality in an application, an application developer would need to familiarize themselves with a number of protocols and provide logic to coordinate these protocols to complement the capabilities of video conferencing. Addition to the application of other collaboration features, such as text messaging, voice messaging, etc. presents other similar problems.

Thus, the architecture for an advanced real-time collaboration system would be very useful, which would make it easy to add collaboration features to the application without significant investment in developer training.

SUMMARY OF THE INVENTION

An architecture is proposed for an advanced real-time collaboration system. This architecture provides a unified application programming interface (API) for writing application programs that use communication protocols. Architecture has action objects, endpoint objects, and many multimedia stacks. These objects can use various communication protocols, such as SIP (Session Initiation Protocol), RTP (Real-Time Transmission Protocol), to send and receive messages containing information. Action objects, endpoint objects, and many multimedia stacks can have each one or more application programming interfaces (APIs) that an application developer can use to access or provide collaboration functionality. These objects map the API to the underlying implementations provided by other objects. Using action objects allows the developer to provide less application logic than would otherwise be necessary to provide complex collaboration services.

Brief Description of the Drawings

1 is a block diagram illustrating architecture components for an extensible real-time collaboration system according to a possible embodiment.

FIG. 2 is a block diagram illustrating components of an endpoint object of an expandable real-time collaboration system according to a possible embodiment.

FIG. 3 is a block diagram illustrating objects of actions of an expandable real-time collaboration system according to a possible embodiment.

FIG. 4 is a flowchart illustrating a “Server Endpoint Creation” procedure according to a possible embodiment.

5 is a block diagram illustrating the architecture of an extensible real-time collaboration system according to a possible embodiment.

Detailed description

In a possible embodiment, an architecture is provided for an extensible real-time collaboration system. The architecture provides a high-level application programming interface (API) for writing application programs that use communication protocols to provide collaboration services. An application developer can add collaboration services to an application using an API without having to learn the complexities associated with the various underlying protocols that implement collaboration services.

This architecture contains action objects, endpoint objects, and many multimedia stacks. These entities can use various communication protocols, such as SIP or RTP / RTCP, to send and receive messages. Each of the action objects, endpoint objects, and a plurality of multimedia stacks can have one or more APIs that can be used by the application developer to access the functions or provide the functions provided by the objects. An application developer can choose an option for providing application logic that uses the APIs provided by endpoint objects or multimedia stacks, or can choose an option for providing application logic that uses the API provided by the action object. Through the use of APIs provided by endpoint objects or multimedia stacks, the application developer is able to show a high degree of flexibility, but must provide a significantly larger amount of application logic than if only the action object's API is used. An application developer can choose to use the action object's API for various reasons. The action object API provides a higher level interface than the endpoint object and multimedia stack APIs. In addition, action objects coordinate the endpoint object and the multimedia stack, and thus, application logic is not required to perform coordination.

Action objects provide services for applications and other objects. Action objects are objects that allow an application to participate in many different actions and may include, for example, instant messaging, teleconferencing, video conferencing, application sharing, and other actions. Objects of actions can be considered as objects “in the shell” that provide functions of the underlying (basic) objects, including endpoint objects and multimedia stacks. In particular, action objects coordinate endpoint objects and multimedia stacks to provide a continuous and integrated communication session with other objects using action objects, such as applications.

The following may serve as an example of the benefits of using an action object. An application developer may wish to provide video conferencing capabilities within the application. To do this, the application developer would first need to become familiar with the signaling protocol, such as the SIP protocol, and the multimedia protocol, such as the RTP / RTCP protocol. Then, the application developer would have to provide the application logic for creating the session, determine whether there is currently an online contact with the person with whom video conferencing is desired, send an invitation to join the video conferencing, agree on various parameters regarding the video conferencing, receive audio and video data from the hardware means for receiving audio and video data and, finally, to exchange audio and video data using the RTP / RTCP protocol. In contrast, when using an action object corresponding to video conferencing according to the proposed architecture, many of these steps are excluded, since this action object corresponding to video conferencing is specifically designed to consolidate the application logic into several high-level interfaces. The proposed architecture has similar action objects for a number of other actions related to collaboration. In addition, this architecture provides support for additional action objects, which should be additionally introduced in the future.

The endpoint object provides administration services, such as signaling. An endpoint object includes the components of a profile, publish / subscribe, signaling, and protocol stack. A profile component can provide an abstract description of a user through an API. The publish / subscribe component provides interfaces for tracking presence and availability information related to users. The signaling component can be used to provide or receive rare transactional messages related to establishing or managing communication sessions. The signaling component may also be used to match, for example, transmission medium parameters, for example, a bandwidth limit. The protocol stack component is used by the profile, publish / subscribe, and signaling components to send or receive data and supports various protocols, including SIP.

As described above, the action object provides a tool for application developers that allows you to easily add collaboration services to applications in a simple way. As an example, an application developer desiring to add a video conferencing function to an application can provide logic for creating (or “implementing”) an action object corresponding to a video conferencing. An action object corresponding to video conferencing can then create an endpoint object for signaling (for example, an SIP endpoint object) and a multimedia message stack to send audio / video data. In the process of subsequent videoconferencing actions (for example, when sending or receiving an audio / video stream), an action object can coordinate objects when they are created or implemented (creating an instance). In one embodiment, the application can create objects and further provide an indication of objects for the action object. In this case, the action object does not need to create these objects.

The multimedia stack objects provide content transfer services, such as audio / video stream processing. As an example, a multimedia stack object may use the RTP / RTCP protocol to send or receive audiovisual information related to video conferencing.

1 is a block diagram illustrating architecture components for an extensible real-time collaboration system according to a possible embodiment. The architecture for an extensible real-time collaboration system includes a collaboration service object 102, a plurality of endpoint objects 104, action objects 106 and a plurality of multimedia stacks 108. One or more applications 110 can use the architecture by accessing various methods, properties, and events related with architecture. The application developer creating the application can use the architecture by applying a unified API instead of having to learn and implement different APIs for each multimedia stack, protocol, or other component that the application or architecture can use.

The collaboration service object 102 provides a tool for applications to share multiple endpoint objects, and can provide compatible APIs for a number of endpoint objects. As an example, if the endpoint object 1 provides an interface associated with receiving (or sending) information, the endpoint object 2 similarly provides an interface associated with receiving (or sending) information, but the two interfaces use different names, however, they perform similar functions , then the collaboration service object can provide a common name for both interfaces. If the application developer uses this common name in the application, then the application developer does not need to revise the application when a new or modified object that provides an interface with a different name is used with the collaboration service object.

Objects 104 endpoints provide a tool for signaling other objects. Signaling can be used between two endpoint objects for which a session is taking place, for example, so that the endpoint object can invite or request another endpoint object to take an action or exchange information related to the session. As examples, an endpoint object may invite another endpoint object to a conversation with instant messaging and then can send text messages related to the conversation. The endpoint objects are described in more detail below with reference to FIG.

Action objects are components that enable an application to participate in various collaborative activities. These components provide an API that an application developer can use to coordinate endpoint objects and multimedia stacks. Action objects 106 are described in more detail below with reference to FIG.

The multimedia stack object 108 provides content transfer services, such as processing data streams, and provides an API for other objects to send or receive data. An architecture can support a virtually infinite number of multimedia stacks because the architecture does not need to distinguish between different types of data or media. As a result, new multimedia stacks can be added, or multimedia stacks can be modified as requirements change. An example of a multimedia stack is the RTP / RTCP protocol. This multimedia stack can be used to send audiovisual information.

2 is a block diagram illustrating components of an endpoint object of an extensible real-time collaboration system according to one embodiment. Endpoint objects provide administration services, for example, a tool for signaling about other objects. Signaling can be used between two endpoint objects for which a session is taking place, for example, so that the endpoint object can invite or request another endpoint object to take an action or exchange information related to the session. As examples, an endpoint object may invite another endpoint object in a session to a conversation with instant messaging and then can send text messages related to the conversation.

This architecture can support various endpoint objects, and each endpoint object can be implemented multiple times. As an example, there may be an endpoint object related to a personal user account of an Internet service provider (e.g. MSN.COM) and another endpoint object related to a corporate user account of an Internet service (e.g. MICROSOFT.COM). A user can register with service providers using a personal account on multiple devices (e.g., a portable computing device and a desktop computing device), and can also register using a corporate account on some of the devices (e.g., a desktop computing device). Thus, there may be two instances related to a URI (universal resource identifier) associated with a personal account. Individual instances of endpoint objects can then be uniquely identified by a combination of a universal resource identifier (URI) and an endpoint identifier (EID). As an example, an endpoint object can be identified using a URI of the form user@MSN.COM and an EID of the form “1234”. As described above, an EID can be used to specifically distinguish an instance of an endpoint object from another instance of an endpoint object that is associated with the same URI.

An endpoint object can provide a data interface and an alarm interface. The data interface may include methods, events, properties related to data that are published or subscribed to by the endpoint object. By publishing or subscribing to data, an application can provide data or be notified of changes in data. The signaling interface may provide methods, events, and properties related to signaling management for an endpoint object. As an example, signaling characteristics may include creating or joining sessions, entering or leaving a dialog, accepting invitations, or rejecting invitations and other signals.

The endpoint object 200 shown in the drawing comprises a profile component 201, a publish and subscribe component 202, a signaling component 204, and a protocol stack component 206.

A profile component can provide an abstract description of a user through an API. It supports service-related information for the user, such as an email address (e.g., a URI), a credential (an account with user credentials generated after successful authentication) used for the service provider, the status of the service provider, capabilities and strategies. Users can have more than one profile per service provider. The profile component can be used to create communication sessions with other users, for example, to provide a custom URI. The profile component provides methods for logging in or logging out for the user in connection with the service provider.

The publishing and subscribing component provides interfaces for tracking presence and accessibility information related to users. Accessibility information relates to whether a user is present on a particular computing device. Accessibility information is related to whether the present user is available to receive the message or whether he wants it. As an example, a cell phone user may be present when his cell phone is turned on, but may not be available for a messaging session when the user participates in a phone call. Similarly, a user who has set the busy indication in MICROSOFT WINDOWS MESSENGER may be present but not be available to send messages.

As another example, a presence object may provide information related to a user who is present and available to participate in the MICROSOFT WINDOWS MESSENGER dialog using a computing device, and is also available to participate in a teleconference using a cell phone. If the user is no longer registered with MICROSOFT WINDOWS MESSENGER, the presence object can update this information so that the application using the presence object can determine that the user is no longer present or is not available to participate in the MICROSOFT WINDOWS MESSENGER dialog. Thus, presence information indicates whether users or other objects are present. Different service providers or protocols may use different mechanisms to generate or provide presence information. So that the application developer does not need to know about the many ways of generating or providing presence information, the application developer can use the endpoint object to generate or use the presence information.

The publishing / subscribing component provides a subscription interface for creating a subscription to the publication of another object, a publishing interface for providing subscriptions to other objects, and a notification interface for receiving notifications related to services for which the subscription has been subscribed. These interfaces allow the application to use the component to provide, receive, or track presence information. As an example, if a user participates in a MICROSOFT WINDOWS MESSENGER dialog using a personal computer and participates in a teleconference using a cell phone, the publish / subscribe component can detect and report the presence of the user at both locations. The URI and EID can jointly uniquely identify instances of endpoint objects. Since a user can be present in multiple locations at the same time, a user URI may be indicated as being present in this multiple locations. Adding an EID in conjunction with a given URI provides a mechanism for uniquely identifying a particular presence instance.

Notifications may be provided in connection with various information. As an example, notifications can be provided regarding whether the user is interactive, busy, available, absent at lunch time, etc. Notifications can also be provided in connection with the user's territorial location (for example, as provided by the GPS Global Positioning System), contact information, calendar information, messages outside the office, audio / video mode, etc.

The signaling component may also be used to provide or receive infrequent transactional messages related to establishing or managing communication sessions. This component can also be used to match, for example, transmission medium parameters, such as the number of frames per second.

The protocol stack object is responsible for transmitting and receiving information using the protocol. As an example, SIP can be used to send or receive signaling information. In various embodiments, other protocols may equally be used. In one embodiment, the endpoint entity may be compatible with multiple protocols. In this case, the endpoint object may be able to use, for example, many protocols, if necessary, to send and receive information. Alternatively, an architecture may support multiple combinations of endpoint objects and protocols as separate endpoint objects. In this case, one endpoint object can be used for SIP, and the other for some other protocol.

FIG. 3 is a flowchart illustrating objects of actions of an expandable real-time collaboration system according to a possible embodiment. Action objects provide services for applications and other objects. Action objects are objects that allow an application to participate in many specific actions and may include, for example, instant messaging, teleconferencing, video conferencing, application sharing, and other actions. Action objects can be thought of as shell objects that provide the functionality of basic objects, including endpoint objects and multimedia stacks. In particular, action objects coordinate endpoint objects and multimedia stacks to provide a continuous communication session with objects using action objects, such as applications.

Each action object provides functionality that allows an application using the object to participate in a variety of actions. As an example, an action entity may encapsulate signaling information and transmission media. In this case, the action object can serve as a bridge between the alarm system and the transmission medium, so that the application using the action object is provided in an integrated form. For example, the application developer just needs to request a video conference, and not establish separate connections and SIP and RTP / RTCP protocols. Illustrative examples of actions are described below.

A collaboration session action object 304 allows an application to provide collaboration services for application users. As an example, the action object of a collaboration session can allow two users using two different computers to work together to create a shared document.

An application sharing action object 310 allows an application using an application sharing action object to provide functionality related to application sharing between users using different computing devices. As an example, two users can share a whiteboard application, with which the user can provide visual information that can be viewed and manipulated by another user.

Message passing action object 306 allows applications to provide message passing capabilities to application users. As an example, an application developer may wish to allow messaging in an application that the developer creates. As an example, when two users work together on a document by editing the document at the same time, it may be desirable for users to be able to send text messages to each other or participate in a video conference in a collaborative process. In this case, the application developer can use the object of the action of the collaboration session, as well as the objects of the action of sending messages and video conferencing to enable users to collaborate and exchange messages with each other in the process of collaboration.

A video conferencing action object 308 provides video conferencing tools for an application. Video conferencing may include sending and receiving audiovisual information.

Other action objects that are represented as action objects 312 are also possible.

An application developer can use the architecture objects described above (and those not listed or described) by using the APIs provided by these objects. These objects can provide an easy-to-use API, so the application developer does not need to refer to the APIs provided by the core components that provide the services associated with the action objects. As an example, a messaging service provider can provide an API that a developer can use. To do this, the developer may need to spend time exploring this API, which can be quite complex. Instead, it may be desirable for the developer to use the simpler API provided by the architecture object. In addition, an object may encapsulate steps that may be required to use many other objects. As an example, an application developer who wants to exchange messages with two computers may need to use the API provided by SIP, as well as the API provided by another low-level entity that provides a messaging service. In contrast, the application developer should use only the action object corresponding to the message transfer, and thereby be able to add the message transfer function to the application in a much simpler way. In addition, the architecture can act to coordinate multiple objects, thereby requiring the application developer to create less programming logic.

In one embodiment, the collaboration session contains and uses action objects.

FIG. 4 is a flowchart illustrating a “Server Endpoint Creation” procedure according to a possible embodiment. The procedure is called by the application to create an endpoint object that connects to the server. When an endpoint is created that connects to the server, the information that it publishes may be accessible to entities that have subscribed to it, even after the created endpoint no longer functions. Thus, the endpoint connected to the server can provide information "per URI", which means that the information remains available after the expiration of the life of the object.

The procedure begins at step 402. At step 404, the procedure creates a new endpoint object and indicates that the endpoint is associated with the application. The specified application can be provided as a parameter to create a function that acts to create the endpoint. When creating an endpoint, a “friendly” (convenient) name can be provided so that you can refer to this endpoint by this convenient name. Alternatively, a newly created endpoint can be referenced by a unique identifier associated with the endpoint. This unique identifier can be generated by the system when an object is created.

At 406, after the endpoint is created, the application can register the newly created endpoint object for the server to enable the server to route messages to that endpoint. After receiving the registration request from the endpoint object, the server can forward the authentication request to the endpoint. The authentication request may contain a “scope” used by the server. The scope may indicate the domain name associated with the server. As an example, a server can send an authentication request with the scope “MICROSOFT.com.”

At 408, the procedure responds to the authentication request by providing a credential (e.g., user ID and password) associated with the application. This credential can be entered by the user or provided automatically. The server can authenticate the credential issued by the procedure. A mandate may be associated with an area. For example, if an application provides a credential that is not associated with a server area (“MICROSOFT.com.”), The server may not authenticate the application.

If registration is successful, then the endpoint may be ready to receive messages from other entities. Otherwise, the endpoint may not be able to receive messages.

At step 412, the procedure returns to its initiator.

In a possible embodiment, the server may allow an endpoint that has not been successfully registered to send messages but not receive messages. Alternatively, in a lower security model, the server may allow any endpoint to send or receive messages.

In one embodiment, the server may send an authentication request to the endpoint when the endpoint attempts to send a message, but not when it receives the messages.

An alternative procedure (not shown) may create a peer-to-peer endpoint. A peer endpoint is an endpoint that is not associated with a server. When the endpoint is not associated with a server, the information that the endpoint publishes may not be available when the endpoint ceases to function.

5 is an architecture diagram illustrating the architecture of an extensible real-time collaboration system according to a possible embodiment. The architecture comprises an action object 502, an endpoint object 504, and multimedia stack objects 506. These objects are described above in detail. The architecture diagram shows the relationship between the action object, the endpoint object, and the multimedia stack object in a possible embodiment. More specifically, the architecture diagram shows that the functionality provided by the action object includes the functionality provided by the endpoint and multimedia stack objects.

In one embodiment, a plurality of action objects may be used with corresponding multimedia stack objects.

Applications can call methods of objects of architecture or can directly call methods of base objects that implement the corresponding function. By invoking methods of architecture objects from the application developer, it may be necessary to provide a smaller amount of logic and it may not be necessary to revise the application logic when the underlying components change.

Below are some of the API applications provided by the architecture.

An application can create an endpoint object by creating a new “Collaborative Endpoint”. An application can provide the following parameters: the URI associated with the endpoint object, the server associated with the endpoint object, and an indication of the network credential.

The Network Mandate method provides an indication of the network mandate. This method takes as parameters the user account, password and domain with which the account is associated.

The Enter method registers the endpoint and provides an indication of success or failure. This method does not require parameters.

The Publish method publishes presence information. As an example, the application can show that the user is interactive, busy, talking on the phone, etc. The architecture is quite flexible to provide a virtually unlimited number of presence indications. For example, an application may choose to publish the user's location as determined by GPS.

In contrast, the Subscribe method subscribes to publish an endpoint object.

The Invite method invites the user to a collaboration session. This method receives the indication of the URI to which the invitation should be sent.

The Accept method accepts the invitation. Conversely, the Reject method rejects the invitation.

The messaging action object can be created from the Instant Messaging Action class. This action object supports various methods, including, for example, the method for sending “Send Message” messages.

The Send Message method sends a message. It receives the message sequence as a parameter.

Methods can be provided by a variety of architectural objects. An architecture may further provide methods, properties, and events related to retrieving user properties, adding a user to a contact list, adding or removing participants from dialogs, etc.

The computing device on which this architecture can be implemented includes a central processing unit, memory, input devices (e.g., keyboards and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). Memory devices and storage devices are computer-readable media that may contain instructions that implement the system. In addition, data structures and message structures can be stored or transmitted over a data medium, for example, via a signal or a communication channel. Various communication channels may be used, for example, the Internet, a local area network, a wide area network, a point-to-point dial-up connection.

The architecture can be implemented in a variety of operating environments, including computing devices running the MICROSOFT WINDOWS operating system. This operating environment is just one example of a suitable operating environment and does not impose any restriction on the amount of use of system functionality. Other well-known computing systems, environments, and configurations that are suitable for use may include personal computers, server computers, portable or desktop devices, including smart cell phones, multiprocessor systems, microprocessor based systems, programmable consumer electronics, network personal Computers, general purpose computers, distributed computing environments that include any of the above systems or devices TV and the like.

An architecture may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers or other devices. In general, program modules include standard routines, programs, objects, components, data structures, etc. that perform specific tasks or implement certain abstract data types. In a typical case, the functionality of the software modules can be combined or distributed, as is necessary in various environments.

From the foregoing, it is understood that the specific embodiments of the invention described above are provided to illustrate, and that various modifications can be made without departing from the spirit and scope of the invention. Thus, the invention is limited only by the attached claims.

Claims (17)

1. The method performed in the computing system to provide real-time collaboration services in the application, which consists in the fact that
create an instance of the action object (106, 300, 502), and the action object provides the functionality of the endpoint object (104, 200, 504) and the multimedia stack object (108, 506), both of which are basic for the action object, and contains a programming interface applications for providing a collaboration service, and
invoke application programming interface methods,
moreover, the activated methods provide administration services for an endpoint object that provides an abstraction of a user on a computing device and is identified by a combination of a user's email address and an endpoint identifier, wherein the administration services include providing presence information related to whether the user is present on the computing device; and
moreover, the activated methods additionally provide services for transmitting the contents of a multimedia stack object between applications (110) that transmit information of a collaboration service. 2. The method of claim 1, wherein the endpoint entity uses a Session Initiation Protocol. 3. The method according to claim 2, in which the multimedia stack object uses the Real-Time Transmission Protocol. 4. The method according to claim 2, in which the multimedia stack object uses the Real-Time Control Protocol. 5. The method according to any one of claims 1 to 4, in which the content transfer services include providing a transmission medium. 6. An expandable real-time collaboration system containing many multimedia stack objects (108, 506);
an endpoint object (104, 200, 504) for providing or receiving signaling information, wherein the endpoint object provides an abstraction of a user on a computing device and is identified by a combination of a user's email address and an endpoint identifier, and
a plurality of action objects (106, 300, 502), and the action objects provide the functionality of a plurality of multimedia stack objects and an endpoint object, all of which are basic for a plurality of action objects, provide an application programming interface for applications and use a plurality of multimedia stack objects and an end object points for providing collaboration services, while collaboration services include providing presence information related to whether user on a computing device,
moreover, the application uses the application programming interface and does not require providing logic for coordinating the objects of the multimedia stack and the endpoint object. 7. The expandable real-time collaboration system according to claim 6, wherein the application programming interface provides a compatible interface name, even if two base objects that actually provide associated functionality use different interface names. 8. An expandable real-time collaboration system according to claim 6, in which one of the collaboration services is messaging (306). 9. The expandable real-time collaboration system according to claim 6, wherein one of the collaboration services is video conferencing (308). 10. The expandable real-time collaboration system according to claim 6, wherein one of the collaboration services is application sharing (310). 11. The expandable real-time collaboration system according to claim 6, adding multimedia stack objects. 12. An extensible real-time collaboration system according to claim 6, wherein the endpoint object includes a profile component (201) providing a user abstraction on a computing device, a publishing and subscribing component (202) providing interfaces for providing presence information, a signaling component (204) adapted to provide transactional messages related to establishing or managing a real-time collaboration session, and a protocol stack component (206) designed to th for transmitting and receiving information using the protocol. 13. The expandable real-time collaboration system of claim 12, wherein the protocol stack component uses a Session Initiation Protocol. 14. The expandable real-time collaboration system of claim 12, wherein the protocol stack component uses a signaling protocol. 15. An expandable real-time collaboration system according to any one of claims 6-14, wherein one of the plurality of multimedia stack objects uses a Real-time Transmission Protocol. 16. The expandable real-time collaboration system of claim 15, wherein the action objects coordinate a plurality of multimedia stack objects and an endpoint object under application control. 17. A computer-readable medium having computer-executable instructions for executing a method according to any one of claims 1-5.

Images