A connection manager hosts the SIP stack and provides services to endpoints. In particular, the connection manager is responsible for making connections needed by endpoints and for dispatching incoming messages outside dialogs to the appropriate endpoints. The connection manager can also be configured to share connections among endpoints. There are five connection manager classes, of which two are abstract and three that can be used to create instances: client connection manager, Transport Control Protocol (TCP) server connection manager, and Transport Layer Security (TLS) server connection manager. A developer can choose the type that is appropriate for the application scenario. All five connection manager types are discussed in the remainder of this topic. For information about creating each nonabstract type of connection manager, see Creating a Connection Manager.
Connection Manager Base Class
The base class for all connection managers is RealTimeConnectionManager, an abstract base class from which the four other connection manager classes inherit. The following figure shows the inheritance hierarchy of RealTimeConnectionManager and the classes that are derived from it. The derived classes are discussed later in this topic.
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.
The connection manager design has the following goals:
- Provide a flexible architecture to support various usage
patterns for a server implementation.
- Provide optimal message throughput to a remote server while
keeping TCP and TLS stack resources constrained.
- Provide a mechanism to do connection pooling per destination
tuple (host, port, transport). The application should be able to
set the default number of connections for all pools created or
change it dynamically on a specific pool.
- Be able to enumerate the currently active pools, the
connections inside the pool, and all active incoming
connections.
- Be able to use a pool certificate for a topology consisting of
multiple front ends that are used behind a load balancer, even when
the subject of the certificate does not match the fully-qualified
domain names (FQDNs) of the front ends.
Connection Manager Types
There are three types of connection manager an application can use: client connection manager, TCP server connection manager, and TLS server connection manager. The choice of which to use depends on the scenario needed for the application. It is important to note that the type of connection manager affects only the type of incoming connections. All of the connection managers support making either TCP or TLS outgoing connections.
Client Connection Manager
The simplest type of connection manager is the client connection manager, which is implemented in RealTimeClientConnectionManager. This type of connection manager does not listen for incoming connections, which makes 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 SipEndpoints that require a client connection with the server.
Server Connection Manager
The base class for server connection managers is RealTimeServerConnectionManager, which is also an abstract class. A server connection manager exposes additional functionalities over those of client connection managers, such as the ability to listen for incoming connections. There are two types of server connection managers: the TCP server connection manager and the TLS server connection manager. By default, a server connection manager creates five connections to every destination tuple (host, transport, port). An application can set the number of connections to Int32.MaxValue to disable connection sharing. If a connection manager is not specified when a SipEndpoint is created, a client connection manager that is statically created is used to manage the endpoint. All endpoints that are created without specifying a connection manager will share a single static connection manager.
TCP Server Connection Manager
The TCP server connection manager, an instance of the RealTimeServerTcpConnectionManager class, 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.
A TCP server connection manager is less useful than a TLS server connection manager, due to its less-trusted relationship with Office Communications Server 2007. The host authorization involves an IP address that can frequently change.
TLS Server Connection Manager
The TLS server connection manager, an instance of the RealTimeServerTlsConnectionManager class, 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 machines that have matching subject names in this list are allowed. Each entry in this list is either an FQDN (such as mymachine.com) of the remote machine that can make incoming connections or a domain (with leading period, as in .redmond.com) of machines 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.