This chapter provides a more in-depth discussion of six fundamental areas for Office Communications Server 2007 technology. This chapter covers the Session Initiation Protocol (SIP), SIP routing, the Globally Routable User-Agent URI (GRUU), enhanced presence, authentication, and security.
SIP is the protocol used between the server and the clients to establish communication sessions between client endpoints. Clients and servers need to use a standard protocol so that they know how to communicate with each other. SIP routing is the means of ensuring that communication sessions are established with the right people at the right locations. Office Communications Server 2007 uses routing logic to route all requests inside and outside the enterprise. The GRUU is an extension of SIP that is specifically designed to implement reliable routing to a specific device for an end user.
Presence is a combination of a user's ability and willingness to communicate. Live Communications Server 2005-enabled client applications to publish and subscribe to basic presence information such as name, e-mail address, and presence state (such as online, offline, or busy). Enhanced presence is an infrastructure element that enables client applications to publish and subscribe to extended, or enhanced, presence information. With enhanced presence, client applications can subscribe to more granular presence information such as calendar information or device state, and they can choose which presence information to publish and whom to publish to.
Authentication is the process of determining if someone is in fact who he says he is. Because SIP is used to communicate with people over the Internet, it is important for users to know who they are communicating with. Knowing this helps users protect themselves from malicious users, and it helps enterprises protect their sensitive data.
Finally, the last part of this chapter introduces some security features of Office Communications Server 2007 that should be considered before you begin your deployment.
As described in RFC3261, there are many applications that use the Internet and that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users might move between endpoints, be addressable by multiple names, and communicate in several different media (sometimes simultaneously). Numerous protocols have been authored that carry various forms of real-time multimedia session data, such as voice, video, or text messages. SIP works in concert with these protocols by enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they want to share. For locating prospective session participants and for other functions, SIP enables the creation of an infrastructure of network hosts to which user agents can send registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independent of underlying transport protocols and without dependency on the type of session that is being established.
SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions. Participants can be invited to already-existing sessions using SIP. Media can be added to or removed from an existing session. SIP transparently supports name mapping and redirection services, which means users can maintain a single, externally visible identifier regardless of their network location.
SIP is lightweight, providing five main functions for establishing and terminating multimedia communications as defined in RFC3261:
User location The determination of the end system to be used for communication
User availability The determination of the willingness of the called party to engage in communications
User capabilities The determination of the media and media parameters to be used
Session setup The "ringing," which is the establishment of session parameters at both called and calling parties
Session management Includes transfer and termination of sessions, modifying session parameters, and invoking services
SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in Session Description Protocol (SDP), for example, the endpoints can agree on the parameters of a session.
SIP can be used with other Internet Engineering Task Force (IETF) protocols to build a complete multimedia architecture. Typically, these architectures include protocols such as the Real-Time Transport Protocol (RTP) for transporting real-time data and providing quality of service (QoS) feedback, the Real-Time Streaming Protocol (RTSP) for controlling the delivery of streaming media, the Media Gateway Control Protocol (MEGACO) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) for describing multimedia sessions. Although SIP can be used with other IETF protocols to build a complete multimedia architecture, the basic functionality and operation of SIP does not depend on any of these protocols.
Figure 18-1 shows an architecture diagram illustrating how SIP fits into the Transmission Control Protocol/Internet Protocol (TCP/IP) networking stack.
Office Communications Server 2007 and Office Communicator 2007 use SIP to register client endpoints, fetch and publish presence information, and help establish communications sessions, such as Instant Messaging, multiparty conferencing, and Voice over Internet Protocol (VoIP) between clients. Office Communications Server acts as a User Agent Server (UAS) and proxy, and it responds to the SIP requests issued by the client as well as forwards them from one client to another.
In SIP, there are commonly used verbs, which are shown in the following list:
REGISTER is used for endpoint registration. INVITE, ACK, CANCEL, and BYE are used for session establishment. MESSAGE is used for exchanging messages and within the session. SUBSCRIBE and NOTIFY are used for watching someone's presence. SERVICE requests are used for changing your information, such as your contact list and presence information. The following sections describe each of the verbs in more detail.
The first step a user takes when using an instant messaging application such as Office Communications Server 2007 is to log in. When a user signs in to her instant messaging application, for instance, her client sends a REGISTER request to the server. Additionally, if the user changes locations—from her desktop to her laptop, for example—the new client sends a REGISTER request to let the server know that she has changed locations.
The following data flow diagram (Figure 18-2) shows an example of a client registering to her Office Communications Server 2007 server. You see the user logging in and the server challenging the client for authentication credentials. In this example, the client has requested to use Kerberos authentication. More details on authentication technologies, including NTLM and Kerberos, are discussed later in this chapter in the Overview of NTLM and Kerberos section.
The client first sends a REGISTER request to the server. The following block of code is an example of a REGISTER packet. Notice that the From and To headers are the same and the GRUU identifies the endpoint where the client is logging in. More details about the GRUU are covered later in this chapter in the "Understanding the Globally Routable User Agent URI" section.
REGISTER sip:example.com SIP/2.0 From: Callee <sip:[email protected]>;tag=calee1111;epid=01010101 To: Callee <sip:[email protected]> Call-ID: [email protected] CSeq: 1 REGISTER Supported: gruu-10 Contact: <sip:[email protected]:1111;msopaque=1111>; proxy- replace;+sip.instance="<urn:uuid:4b1682a8-f968-5701-83fc-7c6741dc6697>" Via: SIP/2.0/TLS 192.0.1.1:1111;branch=z9hG4bK1111 ...
After receiving a REGISTER request, Office Communications Server can do one of the following:
Query If a Contact header is not present, the request is deemed to be a query for the list of registrations for all endpoints of the user.
Remove a registration If an Expires:0 header is present, the request is deemed to delete any existing registration for the user endpoint specified in the epid parameter of the From header in Live Communicator 2005 or the +sip.instance parameter of the Contact header in Office Communicator 2007. Live Communicator 2005 and Office Communicator 2007 also supply this epid parameter for backward compatibility.
Add or update a registration If a Contact header is present with a non-empty value other than "*", Office Communications Server updates any existing registration for the user endpoint or adds a new registration if no previous registration is present.
After removing, adding, or updating a registration or querying the server, you will typically receive a response with a "200 OK" message. Otherwise, the server will return an error response. More details on common error responses can be found later in this chapter in the Common SIP Responses section.
SUBSCRIBEs and NOTIFYs are used for watching for event notifications from the server. They are used for presence as well as the user's own data, such as in-band provisioning information, contact lists, and specifying who the user wants to allow to watch his presence. Figure 18-3 shows an example data flow of a client subscribing to get the presence status of his contacts.
SUBSCRIBE is used by the user to subscribe to information from the server that is dynamic in nature—that is, the information can change as a result of updates made by other users or as a result of administrative functions. NOTIFY is used by the server to notify users that information they had previously subscribed to has changed and to deliver the updated information.
Typically, Office Communicator will respond to the NOTIFY request with a "200" response. However, if Office Communicator responds to the NOTIFY message with a "404," "480," or "481" response, Office Communications Server assumes that the corresponding subscription is invalid and deletes the subscription from its records.
SERVICE requests are used when you want to change your information on the server as well as create and modify conferences. For example, if you want to add or change your presence information, the client sends a SERVICE request to the server to perform this operation. Figure 18-4 shows a typical dataflow from the client to the server for the SERVICE requests. The (SOAP) envelope inside the SERVICE requests tells the server what the client is requesting the server to do. SOAP is a protocol for exchanging XML-based messages. For details about SOAP, see http://msdn2.microsoft.com/en-us/library/ms995800.aspx.
After Office Communicator sends a valid SERVICE request, Office Communications Server responds to the user with one of the following responses: "100 Trying," "200 OK," or "4xx error." If the initial response is "100 Trying," Office Communications Server responds with a "200 OK" or a "4xx error" message when it completes the processing.
The SOAP/XML envelope in the body of the SERVICE request describes the service to be executed by Office Communications Server. You can use a SERVICE request to do things such as control access control entries (ACEs), modify your contact list and groups, set your own presence, and retrieve presence information.
The INVITE request helps establish sessions for client-to-client communication, as well as establish sessions with the A/V Conferencing Server and the IM Conferencing Server. For instance, when User A wants to send an instant message to User B, User A's client sends an INVITE request to User B.
Office Communications Server follows the guidelines provided in RFC 3261 to allow its users to create and manage an INVITE dialog (by using INVITE, ACK, CANCEL, and BYE messages). Office Communications Server does not consume any of these messages itself in a normal scenario, except in some error cases where Office Communications Server is forced to intervene and respond to these messages.
A Microsoft Office Communicator 2007 user uses the INVITE dialog to establish various types of sessions with other users. The user negotiates what type of session she wants to create in the SDP payload of the SIP INVITE request. These sessions can be one of the following types:
With the exception of instant messaging, these session types are peer-to-peer sessions. Only the SIP signaling (SIP messages related to an INVITE dialog) traverses the Office Communications Server. The media itself is peer-to-peer communications based on the information exchanged between the users in the SDP. The server does not validate or otherwise consume or modify this SDP information.
IM sessions are not peer-to-peer communications because the user sends the IM text to the destination user in the body of SIP MESSAGEs proxied through Office Communications Server. Office Communications Server does not process the contents of a MESSAGE request (or any other client-specific requests) in any special way compared to other general SIP requests. It tries to proxy them as usual to the destination based on the registration information of the target user or the routing information present in the request.
An ACK request is used in a three-way handshake, similar to TCP. If User A sends an INVITE to User B, User B accepts the session and sends a "200 OK" response back to User A. Then User A's client responds with an ACK. This is the three-way handshake process to establish a session between endpoints.
Following a SIP request, the server sends a SIP response back to the client. The SIP responses are almost a one-to-one mapping to HTTP responses. In general, the following SIP responses will be sent back to the client:
Informational
Success
Redirection
Client error
Server error
Global failure
This response ranges from 100 to 199. This response class indicates that the server is trying to process the client's request.
This response ranges from 200 to 299. This response class indicates that the request was received and processed.
This response ranges from 300 to 399. This error class indicates that a response is being redirected to another server.
This response ranges from 400 to 499. This error class indicates that a client error occurred, such as the server challenged with a password and the password is bad.
This response ranges from 500 to 599 and represents an error that occurred on the server, such as the server might be down and not responding.