Collaboration Platform

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

The collaboration platform, an instance of the CollaborationPlatform class, provides capabilities for managing connections to and from the platform, guarantees a trust relationship with Microsoft Office Communications Server 2007 R2, and provides a mechanism whereby developers can extend the capabilities of the platform beyond the built-in media types that are supported in Unified Communications Managed API 2.0 Core SDK.

Depending on the constructor used, a CollaborationPlatform instance is created either as a client platform or as a server platform. A typical use for a client platform is to permit the creation of a number of clients that can be used to simulate users connected to an application.

Connection Management

The connection manager encapsulates the SIP stack and is used to provide services for endpoints. Every endpoint is associated with a single connection manager. The connection manager provides connection sharing, certificate management, and takes care of outgoing and incoming connections for the endpoint. In UCMA 2.0 Core SDK there are three nonabstract connection manager types: a client connection manager and two server connection managers, with one of the server connection managers using TCP as the transport type, and the other server connection manager using TLS as the transport type.

The ConnectionManager property on a CollaborationPlatform instance enforces connection policy and provides connection throttling, ensures that incoming connections come from trusted servers, and hosts authentication authority. In addition, the ConnectionManager listens only on well-known ports.

The following illustration shows the relationship between a UCMA 2.0 Core SDK application and Office Communications Server 2007 R2.

Client Connection Manager

The simplest type of connection manager is the client connection manager, which is implemented by the RealTimeClientConnectionManager class. This type of connection manager, which is associated with a client platform, does not listen for incoming connections, thereby making it inherently more secure. An example application scenario that can use a client connection manager is a simple Office Communicator-like client. Such a client normally uses a single endpoint, and makes a single outbound connection to a server, and reuses that connection for incoming traffic from the server. Typically, a server throttles such a connection thereby making it unwise to share connections between endpoints. For this reason connection sharing is not supported for a client connection manager.

The client connection manager is intended for use with UserEndpoint instances that require a client connection with the server.

TCP Server Connection Manager

The TCP server connection manager, which is associated with a server platform, is an instance of the RealTimeServerTcpConnectionManager class. The TCP server connection manager is intended for applications that need to allow incoming TCP connections.

The TCP server connection manager has the ability to listen for incoming TCP connections. Otherwise, it inherits all the features of the server connection manager.

It is not recommend that you use a TCP connection manager, as the less-trusted relationship with the server is not as secure and is more prone to failure, especially given that the owner of a given IP address can frequently change, or be spoofed.

TLS Server Connection Manager

The TLS server connection manager, which is also associated with a server platform, is an instance of the RealTimeServerTlsConnectionManager class. The TLS server connection manager has the ability to listen for incoming TLS connections. The application optionally can set a flag to indicate whether MTLS is needed. This type of server connection manager allows an application to supply a list of hosts and domains that can be trusted for incoming connections. Incoming connections from any other host or domain are not allowed. The subject or alternate subject (if the subject is empty) in the remote certificate is used to look up in the list of allowed hosts and domains. By default, the allowed host and domain list contains the local host name. If this list is cleared, any incoming connection is allowed. If the list is non-empty, only computers that have matching subject names in this list are allowed. Each entry in this list is either an FQDN (such as adatum.com) of the remote machine that can make incoming connections or a domain (with leading period, as in .redmond.com) of computers that can connect.

The allowed host and domain list is used only when mutual TLS is enabled, because the remote certificate is needed for verification. By default, the connection manager automatically adds the remote host of an outgoing connection to the list of allowed domains if mutual TLS is enabled and the list is nonempty.

The TLS server connection manager is used by applications that are intended to allow incoming TLS connections. These applications also can be configured for mutual TLS.

Managing Trust with Office Communications Server

When the CollaborationPlatform instance is created, a trusted GRUU is assigned to it, which ensures that the platform is trusted at the SIP level (that is, by the SIP stack). To confer this trust relationship, Office Communications Server 2007 R2 reads the Active Directory trusted service object (msRTCSIP-TrustedService) and assigns the associated GRUU to the platform. This GRUU is unique per process.

Extensible Communication Framework

The CollaborationPlatform contains all of the factories that are required for the media types supported in UCMA 2.0 Core SDK. In other words, factories for the InstantMessagingCall, InstantMessagingProvider, InstantMessagingMcuSession, AudioVideoCall, AudioVideoProvider, and AudioVideoMcuSession classes are already registered with CollaborationPlatform. Developers who wish to implement custom media types can do so by creating custom call, media provider, and MCU session classes that inherit from, respectively, the Call, MediaProvider, and McuSession abstract base classes. For more information, see the topics in Advanced Concepts.