This section discusses basic Unified Communications Managed API V1.0 concepts that might be useful to understand how Unified Communications Managed API 2.0 Core SDK works and how its concepts are mapped to UCMA V1.0 concepts.
UCMA V1.0 offers an RFC-based implementation for registration, subscription-based sessions, and invitation-based sessions. It exposes the concept of a connection managerthat can manage incoming and outgoing connections. Outgoing connections belong to a pool that is identified by the host, port, and transport tuple. Every pool can manage a fixed number of connections (the default is 5 but the value is configurable) that helps to load balance across multiple front ends behind a load balancer. The connections to a given Office Communications Server computer (or pool of Office Communications Server computers) are shared across multiple endpoints. If the pool size is set to a very large number, the connection sharing is actually disabled since every request for a connection will indeed create a new connection. In fact, the client connection manager (used for simulating multiple client endpoints) disables connection sharing for all pools. To enable incoming connections, the connection manager must be listening, and it is suggested that the connection manager operate under the best connection security possible (MTLS), to protect against unauthorized access and man-in-the-middle attacks. When MTLS is used, the application can configure the list of FQDNs or domains of computers that are allowed to connect to this connection manager. By default, this list contains only the local FQDN to provide security. It is the responsibility of the application to populate this list with only trusted computers and/or domains, so as to prevent unauthorized or unintentional access. The platform automatically adds the FQDN of the outgoing connections to this list to allow incoming connections from these targets.
UCMA V1.0 offers the concept of subscription session and invite-based session. A subscription session can be used to subscribe to specific events such as contacts/groups or presence notifications. Subscription sessions are normally terminated by the server. There is no support in UCMA V1.0 to consume incoming subscriptions. The invite-based session can be used to communicate with others using instant messages or audio or other modes of communication. The platform can also be used as a back-to-back passthrough of additional modalities, such as video and application sharing over RDP. In addition, UCMA V1.0 supports the ability the send messages from one endpoint to another without creating an invite-based session. Such messages are called Page-Mode messages. The API supports sending and receiving of message, information, options, and service type SIP messages. In addition to these types of messages, the invite-based sessions also supports sending and receiving BeNotify messages which are meant for best effort Notify messages that do not have associated response messages.
UCMA V1.0 is a low level API that does not interpret message bodies (including SDP.) While it enables most scenarios, a large portion of the effort needed to implement functionality can be high depending on the complexity of the solution needed. For example, subscribing to presence information for a list of targets requires knowledge of the presence subscription protocol that involves the concept of batch subscriptions. Depending on how the list of targets are distributed between pools, federated domains, and public domains (such as the Yahoo, AOL, and the MSN networks of Internet services), there can be one or more batch subscriptions involved and zero or more single subscriptions involved to enable the reception of presence notifications for these targets. UCMA 2.0 Core SDK simplifies this process by abstracting away the protocol from the application.