The collaboration platform, an instance of the CollaborationPlatformclass, 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 CollaborationPlatforminstance 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 ConnectionManagerproperty on a CollaborationPlatforminstance enforces connection policy and provides connection throttling, ensures that incoming connections come from trusted servers, and hosts authentication authority. In addition, the ConnectionManagerlistens 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 RealTimeClientConnectionManagerclass. 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 UserEndpointinstances 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 RealTimeServerTcpConnectionManagerclass. 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 RealTimeServerTlsConnectionManagerclass. 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 CollaborationPlatforminstance 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 CollaborationPlatformcontains 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 AudioVideoMcuSessionclasses 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 McuSessionabstract base classes. For more information, see the topics in Advanced Concepts.