This chapter provides an in-depth discussion of the fundamental technologies that Microsoft Office Communications Server 2007 R2 uses. This chapter covers Session Initiation Protocol (SIP), SIP routing, Globally Routable User Agent Uniform Resource Identifier [URI] (GRUU), and authentication.
SIP is an Internet Engineering Task Force (IETF) standard (Request for Comment [RFC] 3261). SIP is an application-layer signaling protocol used for signaling an incoming call, terminating a call, placing a call on hold, joining an audio/video (A/V) conferencing, initiating an instant message conversation, and so on. Just as Signaling System #7 (SS7) is the signaling protocol for the Public Switched Telephone Network (PSTN), SIP is the signaling protocol for the Internet Protocol (IP) network. It is used to establish communication sessions between the server and client endpoints.
SIP routing ensures that communication sessions are established with the right people. Office Communications Server uses routing logic to route all requests inside and outside the enterprise.
The Globally Routable User Agent URI (GRUU) is an IETF standard that extends the SIP protocol designed to make it possible to route reliably to a specific device belonging to an end user anywhere on the IP network.
Authentication is the process of determining whether someone is in fact who she claims to be. Authentication as it applies to SIP enables users to communicate over the Internet securely. Strong authentication protects users and corporate resources (servers) from malicious users and helps enterprises protect their sensitive data.
SIP is an agile, application-layer control protocol for creating, modifying, and terminating sessions. It works independently of the underlying transport protocols and the type of session that is being established.
Many applications that use the Internet require the creation and management of a session. The implementation of these applications is complicated by the practices of participants. For example, users might move between endpoints, be addressable by multiple names, and communicate using 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 to discover one another and to agree on the characterization of a session they want to share.
SIP is a lightweight, text-based protocol, which makes it simpler than many other protocols to debug and troubleshoot. It provides five main functions for establishing and terminating multimedia communications.
User location. The determination of the end system to be used for communication
User availability. The determination of the called party’s willingness to engage in communications
User capabilities. The determination of the media and media parameters to be used
Session setup. The establishment of session parameters at both called and calling parties (also known as ringing)
Session management. The transfer and termination of sessions, modification of session parameters, and invocation of services
Because SIP is a signaling protocol, it is used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures include media protocols such as the Real-Time Transport Protocol (RTP) for transporting real-time data, the Real-Time Control Protocol (RTCP) for providing Quality of Service (QoS) feedback, the Real-Time Streaming Protocol (RTSP) for controlling the delivery of streaming media, the Media Gateway Control (MEGACO) protocol for controlling gateways to the 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 22-1 is an architecture diagram illustrating how SIP fits into the Transmission Control Protocol/Internet Protocol (TCP/IP) networking stack.
In SIP, the server receives requests from client endpoints. Following are the commonly issued SIP requests:
REGISTER
SUBSCRIBE and NOTIFY
SERVICE
INVITE
ACK
CANCEL
BYE
MESSAGE
REGISTER is used for endpoint registration. INVITE, ACK, CANCEL, and BYE are used for session establishment. MESSAGE is used for exchanging messages 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 requests in more detail.
Clients use the REGISTER request to register their endpoints with a SIP registrar server. More than one endpoint can be registered simultaneously for a user. For each endpoint that the user is logged in from, the endpoint client sends a REGISTER request to the server.
The data flow diagram in Figure 22-2 shows an example of a client registering with Office Communications Server. The client sends a REGISTER request, and the server challenges the client for authentication credentials by sending a 401 response with the supported authentication technologies. Then the client initiates a new REGISTER request with authentication credentials. In this example, the client has requested to use Kerberos authentication. More details on authentication technologies, including NT LAN Manager (NTLM) and Kerberos, are discussed in the section titled "Understanding Authentication" later in this chapter.
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 Contact header identifies the endpoint where the client is logging in from.
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 Expires: 0 ...
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 considered a query for the user’s list of registered endpoints.
Remove a registration. If an Expires:0 header is present, the request is interpreted to delete any existing registration for the user endpoint. The endpoint is identified in the +sip.instance parameter of the Contact header in Microsoft Office Communicator 2007 and the epid parameter of the From header in Live Communicator 2005. Office Communicator 2007 also supplies the epid parameter for backward compatibility because +sip.instance is the currently preferred method.
Add or update a registration. If a Contact header is present with a nonempty 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, the server responds with a 200 OK response upon success or with an error response. More details on common error responses can be found in the section titled "Common SIP Responses" later in this chapter.
SUBSCRIBE and NOTIFY requests are used to set up event notifications from the server. The client uses SUBSCRIBE to subscribe to information from the server that is dynamic in nature—that is, the information can change as a result of updates that other clients make or as a result of administrative functions. The server uses NOTIFY to notify clients that information they had previously subscribed to has changed and to deliver the updated information.
In Office Communications Server, these requests are used to subscribe to a contact’s presence and to the user’s own data, such as in-band provisioning information and contact lists. Additionally, these requests are used to specify who the user allows to view his presence. Figure 22-3 shows an example data flow diagram of a client subscribing to get the presence status of his contacts.
Typically, Office Communicator will respond to the NOTIFY request with a 200 response. However, if Office Communicator responds to the NOTIFY request 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 to request a server to perform a particular service or request information, such as changing a user’s presence, fetching a user’s location profile, and creating or modifying conferences. Additionally, a SERVICE request can be used to control access control entries (ACEs), modify contact lists and groups, set personal presence, and retrieve presence information. 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 22-4 shows a typical dataflow from the client to the server for the SERVICE requests. The type of service requested is described in the XML payload Simple Object Access Protocol [SOAP] within the SERVICE request.
After Office Communicator sends a valid SERVICE request, Office Communications Server responds 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 response when it completes the processing.
The INVITE request helps to establish sessions for client-to-client communication, as well as to establish sessions with servers including the A/V Conferencing Server, the IM Conferencing Server, and the Audio Conferencing Provider (ACP) 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 Communicator 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 INVITE request. Office Communicator 2007 supports the following types of sessions:
Instant messaging (IM)
Audio and video
Application sharing
Use of the whiteboard feature
With the exception of IM, these media session types are peer-to-peer sessions. Only the SIP signaling messages related to an INVITE dialog traverse the Office Communications Server, and the media itself is based on peer-to-peer communication of the information exchanged between the users in the SDP. The server does not validate or otherwise consume or modify the SDP payload located in the SIP messages. In the case of A/V conferencing, all conferencing participants establish the media session directly with the A/V Conferencing Server. In this case, media flows directly from the client to the A/V Conferencing Server, where the server mixes the media stream with the conferencing stream and broadcasts to all the participants.
Office Communications Server enables its users to create and manage an INVITE dialog (by using INVITE, ACK, CANCEL, and BYE requests). Office Communications Server does not consume any of these requests itself in a normal scenario; however, in some error cases, Office Communications Server intervenes, such as when redirecting an audio call (INVITE) to the recipient’s voice mail if the caller doesn’t answer the call in a timely fashion.
Important
An INVITE isn’t used when establishing a session with the Web Conferencing Server because it doesn’t support SIP—it uses a proprietary protocol named Persistent Shared Object Model (PSOM) to establish a session. The Web conferencing traffic flows from the client to the Web Conferencing Server, which then fans it out to all the participants.
The 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.
The CANCEL request is used to cancel a session establishment process. For example, if user A sends an INVITE to user B but then decides not to go through with the call, user A’s client sends a CANCEL request to user B.
The BYE request is used to terminate a session. For example, if user A and user B have established a call session and now user A has decided to hang up, user A’s client sends a BYE request to user B.
The MESSAGE request is used for exchanging IM messages within established sessions. IM sessions are not peer-to-peer communication because the body of a MESSAGE request is proxied through Office Communications Server to the destination user. Office Communications Server does not process the contents of a MESSAGE request (or any other client-specific requests) in any special way compared with other general SIP requests. It tries to proxy the requests as usual to the destination based on the registration information of the target user or the routing information present in the request.
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 Hypertext Transfer Protocol (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 is typically followed by another response once the server has finished processing the request.
This response ranges from 200 to 299. This response class indicates that the request was received and processed successfully.
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 represents client errors, such as when a server challenges the client with a password and the password fails.
This response ranges from 500 to 599. This error class represents an error that occurred on the server, such as when the server is down and does not respond.
Office Communications Server uses SIP to register client endpoints, fetch and publish presence information, and help establish communications sessions between clients, such as IM, multiparty conferencing, and Voice over Internet Protocol (VoIP). Office Communications Server acts as a User Agent Server (UAS) and a SIP proxy. A UAS responds to SIP requests sent by clients, whereas a SIP proxy forwards them from one client to another.