A real-time endpoint represents an addressable entity that can be used for real-time collaboration with other endpoints. The phrase "real-time" refers to communications that occur quasi-instantaneously, in constrast to slower forms of communication such as e-mail. The endpoint provides the local context for all real-time services such as subscription sessions and signaling sessions. Every endpoint can be identified by a unique URI and an endpoint ID. The endpoint ID must be unique within the scope of this URI. Several endpoints that share the same URI can exist at the same time (the concept multiple points of presence (MPOP) describes this situation), and can be distinguished from each other by their endpoint IDs. Another way to uniquely identify an endpoint is by its Globally Routable User Agent URI (GRUU).

A real-time endpoint is implemented in the abstract class, RealTimeEndpoint. Because this class is abstract, it cannot be instantiated. Two other classes, SipEndpoint and SipPeerToPeerEndpoint, are derived from RealTimeEndpoint, and are described in the following sections.

The SipEndpoint is a real-time endpoint that can be used when there is a server available for discovering and communicating with other users. The SipEndpoint class inherits from, and provides implementations of the members of its abstract base class, RealTimeEndpoint. In addition to the capabilities defined in the base class, SipEndpoint is the endpoint that is exposed by the Unified Communications Managed API that is able to register with Office Communications Server 2007.

After a SipEndpoint instance has been created, an application can register the endpoint with a SIP server. The SipEndpoint class has been designed to be registered with Office Communications Server 2007, and has been tested only against this platform. For more information, see Registering an Endpoint. Although registration is not required, it is highly recommended because some functionality might not be present if the endpoint is not registered. For example, an unregistered endpoint might not be able to receive incoming invitations. After a successful registration, an application can unregister an endpoint at any time. When the endpoint functionality is no longer needed, it can be terminated.

A SipEndpoint supports both TCP and TLS transport to the server. The connection created to communicate with the server is normally cached by the endpoint for use for all outgoing messages. If the connection is disconnected for some reason, a new one is automatically created when the next message is sent out, unless automatic register refresh is disabled for a registered endpoint. In this case a new connection is not created. Note that all outgoing messages are delivered to the server directly for routing. Because servers can require users to authenticate, a SipEndpoint supports user authentication by either the NT LAN Manager (NTLM) or Kerberos authentication protocols. The application can use a default log-on crediential or can specify a credential.

The SipPeerToPeerEndpoint is a real-time endpoint that can be used when there is no server infrastructure available. This type of endpoint also can be used when a proxy server that does not require registration is available.The SipPeerToPeerEndpoint class also inherits from, and provides implementations of the members of the abstract base class, RealTimeEndpoint.

In addition to the capabilities of the RealTimeEndpoint base class, a SipPeerToPeerEndpoint can be used when there is no registration server available. It can also be used, when a server infrastructure is available, to send messages through a SIP outbound proxy. These endpoints can communicate directly with other similar endpoints or can use an outbound proxy server.

A SipPeerToPeerEndpoint can receive messages only if listening on a port is enabled. When listening is enabled, a SipPeerToPeerEndpoint receives messages by using the connection manager.

A SipPeerToPeerEndpoint can send messages if the endpoint is configured to use an outbound proxy server, but it can also send messages directly to other SipPeerToPeerEndpoints without first passing them through a server. All of the messages that the SipPeerToPeerEndpoint sends are delivered to the proxy unless it is inside a session, in which case the session-specific connection is used. The session-specific connection is likely to be with the proxy as well unless the proxy is configured so that it is not in the path for every message inside a session. This type of endpoint supports only the server connection manager.

A SipPeerToPeerEndpoint supports the concept of a default transport type. The default transport type is used for outgoing messages unless the message URI overrides the transport type using the transport URI parameter.

This type of endpoint does not support user authentication. If the endpoint is used in the context of a server that can challenge requests,the server must be configured to trust the machine that uses this endpoint to communicate with the server by setting an outbound proxy server.

Unlike SipEndpoint, a SipPeerToPeerEndpoint does not cache a connection. For example, if a message is sent to another remote endpoint, a connection is created dynamically and used. After the message sending operation is complete, the connection is released, which causes the connection to be removed after about a minute. Unless another message is sent within a minute, the connection is disconnected and removed. However, if a session is established with a remote endpoint, the session will cache the connection during the lifetime of the session and thus the connection will stay alive. If there is no traffic on the connection for a long time (the default time is 15 minutes, but this time limit can be set individually or for all connections in the connection manager) it might be disconnected as well. Connection management is further discussed in Creating a Connection Manager.

The SipEndpoint constructors that have a connection manager parameter can be called with an argument that is a RealTimeClientConnectionManager or one of the RealTimeServerConnectionManager implementations.

Requests can be routed to a SipPeerToPeerEndpoint, provided that the application is listening on a port on the server connection manager. Requests can also be routed to a SipPeerToPeerEndpoint via a static route from Office Communications Server 2007.