This chapter describes the basic login, presence, and instant messaging (IM) scenarios by first providing a user-level view of actions taken in Microsoft Office Communicator 2007 R2 and then explaining in depth the protocols, algorithms, and systems that make these processes work. This chapter also provides background on basic server and client operations in terms of discovery, connectivity, and communications over Session Initiation Protocol (SIP) and as such is a useful reference when exploring other scenarios.
The login process seems simple from the user perspective because it involves only starting Office Communicator 2007 and typing a user name and credentials. However, a number of complex interactions between Microsoft Office Communications Server 2007 and Communicator 2007 help provide security and establish a reliable communications channel. Understanding these interactions is critical for troubleshooting user login failures, as well as client connectivity, authentication, and discovery issues.
Presence information can be managed and shared, allowing users to see if contacts are available, all available means to reach the contact, and how the contact might best be reached based on the contact’s current activity level. This capability is critical for many enterprises, especially distributed or mobile organizations. Being able to receive notification when someone is back at his or her desk, contact someone for an immediate answer without having to initiate a phone conversation, and locate someone’s contact information (including private information, if the contact allows it) all simplify communications in secure and productive ways. This section shows some of the user operations that control requesting presence information from others, publishing presence information, and managing and controlling how presence information is shared.
Instant messaging is a useful tool for getting quick answers from colleagues, reaching someone who is in a meeting without distracting others, or receiving and acting on a message while in a meeting (rather than stepping out to take a phone call). This section provides an overview of IM for individuals and groups, as well as pointers for sending hyperlinks and emoticons. Even though these are relatively simple user scenarios, technical details on how these are accomplished and how content-filtering works are provided to help with troubleshooting or configuration.
In this chapter, you first walk through the login process from the user perspective. Then you walk through the technical steps, decisions, and protocols that are going on in the background. Doing so provides a rich understanding that will aid in troubleshooting login problems and infrastructure problems.
When looking at key usage scenarios for Office Communications Server 2007, logging in from Communicator 2007 is a critical step. When the system has problems, logging in is likely to be the first indication of an issue. Additionally, understanding the technology details behind the login process provides technical insight in becoming an expert administrator or consultant. The simple login process exercises many key aspects of the technology behind Communicator and the Office Communications Server infrastructure, so it is worth understanding in detail.
This scenario walks through a fictitious user, Jeremy Los, using Communicator 2007 R2 to log in to Office Communications Server 2007. This scenario assumes that Jeremy has just finished installation and is logging in for the first time. However, much of what will be shown applies to subsequent logins as well. The scenario shows what Jeremy sees during the login process and what steps he takes to complete the login.
Jeremy launches Communicator 2007 and clicks Sign In. Communicator asks for the sign-in address of his Communicator account, and he enters [email protected], which is the Session Initiation Protocol (SIP) Uniform Resource Identifier (URI). His administrator provisioned this URI. Most administrators use a SIP URI that matches the user’s e-mail address so that it is easy for users to remember. Jeremy then clicks OK.
If Jeremy is not currently logged in to the workstation with domain credentials, Communicator prompts him for sign-in information. Jeremy enters his Active Directory domain account user name and password, and then clicks Sign In, as shown in Figure 5-1. If Jeremy is logged in to his workstation with domain credentials, this step is not necessary.
After Jeremy enters his credentials, Communicator begins the login process to Office Communications Server.
After the login process completes, Communicator shows Jeremy’s presence information, call-forwarding details (if phone control is set up), and contact list, as shown in Figure 5-2.
Let’s explore what is happening with Communicator 2007 and the Office Communications Server network in detail at the network level. Figure 5-3 provides an overview of the steps involved in the login process, which we will analyze.
When Communicator is first launched, it determines if a log of its actions and activity needs to be written. Communicator logging can be controlled through the General menu when you select Options from the Tools menu. Two check boxes on the dialog box control logging and event log messages. All of the protocol messages for the remainder of this section were captured by enabling logging in Communicator and gathering protocol messages from the log.
Note
Only the relevant portions of the protocol messages are shown in the figures. For full event log messages, enable logging and examine the output. Also important to note is that in Microsoft Windows Vista, a user must be a member of the Performance Log Users group to enable logging.
The logging options shown in the Communicator user interface (UI) are stored under the registry key HKEY_CURRENT_USERSoftwareMicrosoftTracingUccpCommunicator. The value EnableFileTracing can be turned on or off by setting it to 0 or 1, respectively. The valid range for MaxFiles is 1 or 2. It is set to 2 by default. This value specifies whether only one file should be created or multiple files should exist to maintain more history when the log file is recycled. MaxFileSize is set to 0x800000 (8.3MB) by default. It determines how large the log file can get before it is cleared and starts over. FileDirectory determines the directory where log files are stored. It is set to %USERPROFILE%Tracing by default. When diagnosing problems, it can be valuable to increase the maximum file size. Note that manually changing these registry values requires a restart of Communicator for them to take effect.
The default settings create the login %USERPROFILE% racingCommunicator-uccapi-0.uccapilog. When this file reaches its maximum size, log data begins writing to the second file, Communicator-uccp-1.uccplog. New data continues to write to the second file until it becomes full, overwrites the first file, and clears itself. The second file continues to receive new log file data and the cycle repeats.
Enabling event logs in Communicator creates entries in the Application Event logs when there are failures. These entries are useful for diagnosing login problems. An example is shown next for reference. It clearly explains the problem, points to the data related to the problem, and explains the steps required to solve the issue.
The following event log error occurred because Communicator was configured to connect to an invalid port (9999) on the server instead of a valid port (5061, for example). The message explains that Communicator was unable to connect and by using a tool such as winerror.exe or lcserror.exe, the error code can be interpreted. Error 10065 is the Windows sockets error code for WSAEHOSTUNREACH, which means the host was unreachable.
Communicator failed to connect to server srv.litwareinc.com (192.168.3.1) on port 9999 due to error 10065. The server is not listening on the port in question, the service is not running on this machine, the service is not responsive, or network connectivity doesn't exist. Resolution: Please make sure that your workstation has network connectivity. If you are using manual configuration, please double-check the configuration. The network administrator should make sure that the service is running on port 9999 on server srv. litwareinc.com (192.168.3.1). For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Note
Winerror.exe is part of the Microsoft Windows Server 2003 Resource Kit Tools, and Lcserror.exe is part of the Office Communications Server 2007 Resource Kit Tools. Both of these can be found at http://www.microsoft.com/downloads with a search for either one of the Resource Kit Tools.
At this point, Communicator must determine which server it should log in to by using the user’s URI ([email protected]) and any manual settings configured on the client. If manual settings were provided, the server to use is clear, but if the URI was the only thing provided, some discovery is necessary. The way in which Communicator does discovery varies based on configuration because Communicator can be instructed to allow only Transport Layer Security (TLS) over Transmission Control Protocol (TCP), to allow only strict server names, or both.
After the client discovers the server to connect to, it attempts to connect using TCP or TLS over TCP. If TLS is used, the server provides a certificate to authenticate itself to the client. The client must validate the certificate before proceeding. The client might negotiate compression (if using TLS over TCP), and then it initiates a SIP registration.
Next, the client sends a SIP REGISTER message to the server without any credentials. This prompts Office Communications Server to challenge for user credentials and specifies to the Communicator client the authentication protocols that it accepts. For additional details, see the section titled "Initial Registration" later in this chapter.
When it comes to providing credentials, Communicator has two options. Communicator can use the user’s current Windows credentials to log in, or it can prompt the user for credentials.
Note
The credentials manager in Windows can also be used to manage user names and passwords. More information about the credentials manager can be found in the Microsoft TechNet article "Windows XP Professional Resource Kit: Understanding Logon and Authentication" at http://go.microsoft.com/fwlink/?LinkID=133674, in the "Stored User Names and Passwords" section. For specific information about changes for Windows Vista and credential management, please see "New Authentication Functionality in Windows Vista" at http://go.microsoft.com/fwlink/?LinkId=137130.
If Communicator validates the server certificate, Communicator might request compression on the connection. Communicator enables compression only on encrypted links, and it determines whether to enable compression based on Group Policy settings (which defaults to enabling compression when there is less than or equal to a 128-Kb link speed). Communicator negotiates compression by using a NEGOTIATE request immediately after TLS is established. This message is only sent hop-to-hop for a given connection. The server can accept or reject this request based on its configuration. By default, the server accepts client compression requests.
After connectivity is established, the initial registration from the client is made to ensure that SIP is allowed on this port and to discover what authentication mechanism should be used with the server. A SIP REGISTER message is used for this purpose, and here is an example of that request:
REGISTER sip:litwareinc.com SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2060 Max-Forwards: 70 From: <sip:[email protected]>;tag=7ad9af1eb1;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: 5d2ad5f9e7a24dacaf1075b97a04df91 CSeq: 1 REGISTER Contact: <sip:192.168.3.100:2060;transport= tls;ms-opaque=aacb364544>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip. instance= "<urn:uuid:6BF396BA-A7D6-5247-89FB-C13B52F5840D>" User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Supported: gruu-10, adhoclist, msrtc-event-categories Supported: ms-forkingms-keep-alive: UAC;hop-hop=yes Event: registrationContent-Length: 0
Note
Access to raw protocol logs is available in Communicator with this release simply by selecting a check box in the configuration process.
The server’s expected response is to challenge the client request for authentication. In the response shown next, the server is asking for Kerberos or NT LAN Manager (NTLM) authentication so that Communicator knows what authentication mechanisms can be used and also knows (for this connection) which server it needs to authenticate against (srv.litwareinc.com).
SIP/2.0 401 Unauthorized Date: Fri, 04 May 2007 22:48:06 GMT WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="srv.litwareinc.com", version=3 WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/srv.litwareinc.com", version=3 Via: SIP/2.0/TLS 192.168.3.100:2060;ms-received-port=2060;ms-received-cid=2600 From: <sip:[email protected]>;tag=7ad9af1eb1;epid=aa6d968e18 To: <sip:[email protected]>;tag=A1F542AB99D66616F9252CB6DF50257F Call-ID: 5d2ad5f9e7a24dacaf1075b97a04df91 CSeq: 1 REGISTER Content-Length: 0
After Communicator has the credentials, it is ready to start authenticating with the server.
At this point, Communicator can simply use the credentials it has available to respond to the authentication challenge.
For NTLM, this takes three handshaking steps. Communicator must submit another anonymous REGISTER, specifying that it wants to use the NTLM authentication protocol in its next REGISTER so that the server will generate a true NTLM challenge (instead of just stating that NTLM authentication is required as it did in the previous 401 response). The server then provides an NTLM challenge to which Communicator can respond by using the user’s credentials. As an aside, the server does not generate a true NTLM challenge unless the client prompts for one by asking for NTLM, because generating challenges is an expensive operation for the server. When the REGISTER message is sent this time, with the NTLM challenge response, the server can verify the user and will actually process the REGISTER request.
For Kerberos, this takes only two handshaking steps because Communicator always submits an anonymous REGISTER, identifies that Kerberos is challenged for, and then provides a Kerberos response in the REGISTER message that is sent next. The server can directly verify this response and process the REGISTER request. Kerberos has one less step because simply knowing the server name is enough for the client to request a Kerberos ticket to validate itself against the server.
Note
For more information about Kerberos and NTLM, see the Microsoft TechNet article "Kerberos Authentication Technical Reference" at http://go.microsoft.com/fwlink/?LinkID=133675 or the Microsoft Developer Network (MSDN) article "NTLM Authentication" at http://go.microsoft.com/fwlink/?LinkID=133676.
Figure 5-4 shows the protocol messages exchanged by the client and the server during initial registration. An example using Kerberos authentication is shown in the upper half. The lower half shows the handshaking process when NTLM is used. This diagram also provides an overview to help in interpreting the actual protocol messages that are shown later.
In this example, the client provides its REGISTER request with a Kerberos ticket for the server that issued the original challenge, as follows:
REGISTER sip:litwareinc.com SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=59e091cf1e;epid=aa6d968e18 To: <sip:[email protected]>Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 2 REGISTER Contact: <sip:192.168.3.100:2062;transport= tls;ms-opaque=4d8a610d50>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip. instance= "<urn:uuid:6BF396BA-A7D6-5247-89FB-C13B52F5840D>" User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Authorization: Kerberos qop="auth", realm="SIP Communications Service", targetname="sip/srv.litwareinc.com", gssapi-data="... (Kerberos ticket info) Supported: gruu-10, adhoclist, msrtc-event-categories Supported: ms-forking ms-keep-alive: UAC;hop-hop=yes Event: registration Content-Length: 0
The Kerberos credentials can be a relatively large portion of the protocol message for the initial handshake, but it is a relatively minimal cost for the security provided for this and all future messages. Because subsequent messages will reference only the credentials and pass minimal data to validate the keys embedded in this exchange, this is a fairly minimal one-time, up-front cost.
For clarity and completeness, the authentication headers are shown as snippets for an exchange if NTLM were in use, as follows:
REGISTER sip:litwareinc.com SIP/2.0... Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 2 REGISTER... Authorization: NTLM qop="auth", realm="SIP Communications Service", targetname="srv. litwareinc.com", gssapi-data=""...
The server responds by offering a true NTLM challenge that Communicator can respond to by using user credentials. This true challenge is easy to see because it is rather large (380 bytes) and starts with a standard header "TlRMTVN...", as follows:
SIP/2.0 401 Unauthorized... WWW-Authenticate: NTLM opaque="33E7D13B", gssapi-data="... "TlRMTVNTUAACAAAAAAAAADgAAADzgpjiFRIiVZ/HsigAAAAAAAAAAOQA5AA4AAAABQLODgAAAA8C AA4AUgBFAEQATQBPAE4ARAABABgAUgBFAEQALQBMAEMAUwBEAFIALQAwADEABAA0AHIAZQBkAG0Ab wBuAGQALgBjAG8AcgBwAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQADAE4AcgBlAGQALQBsAG MAcwBkAHIALQAwADEALgByAGUAZABtAG8AbgBkAC4AYwBvAHIAcAAuAG0AaQBjAHIAbwBzAG8AZgB 0AC4AYwBvAG0ABQAkAGMAbwByAHAALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAAAAAAA=", targetname="srv.litwareinc.com", realm="SIP Communications Service"... Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 2 REGISTER...
Communicator can now use this NTLM challenge to generate an NTLM response, and it packages this in the next REGISTER message that it sends, as follows:
REGISTER sip:litwareinc.com SIP/2.0... Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 3 REGISTER... Authorization: NTLM qop="auth", opaque="33E7D13B", realm="SIP Communications Service", targetname="srv.litwareinc.com", gssapi-data="... "TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAAA4ADgBIAAAACgAKAFYAAAAYABgAYAAAABAAEACo AAAAVYKQQgUBKAoAAAAPUgBFAEQATQBPAE4ARABqAGIAdQBjAGgARABFAEwATAAtAFgAUABTAC0AN AAwADAARYHHoHZkV6SMRG47yl+zcIrUcTec6pSnLajtPCReLpIB6dFgYb0k9fWgnTl9Lg6N+wo5vP ltIFyxOX6CU6kP3g=="...
Either way authentication was received, the server now has an authenticated REGISTER message and must respond to it. The server’s response to the REGISTER message can fall into one of the following categories:
301 Redirect. In this case, the server tells Communicator what the user’s home server is so that the user can directly connect and register most efficiently, as follows:
The existing connection will be closed, and the client will go through the connection process to connect to the server to which it was redirected.
The entire authentication and registration process will repeat with the new server to get back to this point, where a 200 OK message from the server (accepting the registration) would be expected.
200 OK. In this case, the server directly accepts the registration because it is the user’s home server, or it is acting as a proxy because a redirect would fail as a result of Communicator not having direct connectivity to the home server. (Access Edge Servers will proxy registrations.)
403 Forbidden. In this case, the client is not allowed to log in because the SIP URI exists, but it is owned by a different user than the credentials that were supplied. The following are possible causes:
The user account is not enabled for Office Communications Server.
The user account is disabled, or the password is expired.
The credentials are invalid, or there was a typing error in the user name or password.
Communicator is logging in from the Internet, and the user is not enabled for remote access with Office Communications Server.
404 Not Found. In this case, the client is not allowed to log in because the user URI that was specified does not exist, even though valid user credentials were provided. (This failure could be because of a typing error in the URI.)
504 Server Time-Out. In this case, the server handling the request (probably an Access Edge Server) had difficulty routing the message, and there is either a configuration problem in the network or a service outage is occurring.
If Communicator receives a 504 or 403 error, it reports to the user that a general error has occurred and provides more details in the trace log. The event log should also provide a detailed description of the problem, along with hints to help understand how to resolve the problem. An example of one of the event log messages that can occur when an Access Edge Server is unable to route a message is shown next. This problem can be replicated easily on your own domain if your network has an Access Edge Server installed with Open Federation enabled. Simply try to send a message to a user in a domain that does not exist. (The example involves sending a message to [email protected], which is a fictitious domain that does not support SIP.) The nice thing about the log shown next is that it even tells you which server in the network failed. (The server sipfed.litwareinc.com identifies itself in the ms-diagnostics field from the 404 response and explains what failed: "Unable to resolve DNS SRV record.")
A SIP request made by Communicator failed in an unexpected manner (status code404). More information is contained in the following technical data: RequestUri: sip:[email protected] From: sip:[email protected];tag=a7e16ad66d To: sip:[email protected];tag=498ED6D80FE772442E7B51A625FB667E Call-ID: 7ff2d267efa846778d741480d85fd522 Content-type: application/sdp v=0 o=- 0 0 IN IP4 157.57.6.160 s=session c=IN IP4 157.57.6.160 t=0 0 m=message 5060 sip null a=accept-types:text/rtf application/x-ms-ink image/gif multipart/alternative application/ms-imdn+xml Response Data: 100 Trying 404 Not Found ms-diagnostics: 1008;reason="Unable to resolve DNS SRV record";source="sipfed. litwareinc.com" Resolution: If this error continues to occur, please contact your network administrator. The network administrator can use a tool like winerror.exe from the Windows Resource Kit or lcserror.exe from the Office Communications Server Resource Kit in order to interpret any error codes listed above. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
If Communicator receives a 301 response, the connection process starts again by resolving the host name it received in the Contact header and attempting to connect and register with this server.
Note
Communicator has proof to allow it to trust the server it is registering against in the form of authentication signatures in the response and possibly even a validated certificate used by the first-hop server. Because of this, Communicator honors an authenticated redirect response from a server in its domain, even if the name does not line up with the SIP URI of the user. However, if Communicator receives a 200 response, the initial registration is complete and login processing continues from this point.
In the example login, the server accepts the registration with a 200 OK response, as follows:
SIP/2.0 200 OK ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=300 Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF5C001B875485F1BC7E66F0006 6537A78", srand="40882645", snum="1", opaque="A7AB18E7", qop="auth", targetname="sip/srv.litwareinc.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid=2700 From: "Jeremy Los"<sip:[email protected]>;tag=59e091cf1e;epid=aa6d968e18 To: <sip:[email protected]>;tag=A1F542AB99D66616F9252CB6DF50257F Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 2 REGISTER Contact: <sip:192.168.3.100:2062;transport=tls;ms-opaque=4d8a610d50; ms-received-cid=00002700>;expires=7200;+sip.instance="<urn:uuid:6bf396ba- a7d6-5247-89fb-c13b52f5840d>"; gruu="sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu" Expires: 7200 presence-state: register-action="added" Allow-Events: vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,vnd- microsoft-roaming-ACL,presence,presence.wpending,vnd-microsoft-roaming-self, vnd-microsoft-provisioning-v2 Supported: adhoclistServer: RTC/3.0 Supported: msrtc-event-categories Content-Length: 0
Note
Because the same header information is repeated in each 200 OK response, the Authentication-Info, From, To, and Call-ID headers are left out in the remaining examples.
While we are looking at this example, the final 200 OK response has other interesting information to examine. First, the server provides credentials for itself that also prove to the client that the server can be trusted. This proof is especially important for TCP connections, where this is the only means of authentication the client has. The rspauth and targetname fields in the Authentication-Info header provide cryptographic proof that the authenticating server identifies itself with the name specified. Second, the single Contact header in the response tells Communicator that only the contact address that was just registered is currently logged on (that is, no other clients are active for Jeremy’s account). Third, the ms-keep-alive and Allow-Events headers provide information to the client to help it understand how to stay connected and synchronized with the server, as well as what services are available. Finally, the Expires header tells Communicator how long the registration is valid. It must be refreshed within 7,200 seconds (2 hours), or it will automatically expire and be cleaned up by the server.
Real World: Troubleshooting Client Connections
Thomas Laciano
Program Manager, RTC Customer Experience
Troubleshooting the first client connection can be approached in a systematic way. Begin your troubleshooting with Active Directory Users and Computers and Office Communications Server 2007 Management Consoles. Is the user showing that she is enabled? If she is enabled here, you actually have one more place to check, because these views are showing what is configured but not necessarily what is in the database used by Office Communications Server.
Open a command prompt and navigate to the directory you installed the Office Communications Server Resource Kit Tools to. (You installed the Resource Kit Tools, right?) The default location is C:Program FilesMicrosoft Office Communications Server 2007Reskit. Typing dbanalyze /? provides the available switches, as well as sample syntax. For example, say you are interested in determining if the database includes the SIP URI of the user you are testing with. (Note that we are not covering the elements of the output here, merely referencing the tool for the purpose of validating the presence of a user in the database.) In this situation, you use the following command:
dbanalyze.exe /report:user /user:[email protected]
An example of output you might get from running this command follows:
Snooper Version: 3.0.6237.0 Report created at 5/30/2007 2:31:00 PM on sip.litwareinc.com. User : [email protected] ------------------------------------------------ Resource Id : 5 Home server : sip.litwareinc.com GUID : 2e324a4b-c048-420f-9c8d-1d86bb9fc266 SID : S-1-5-21-3158251299-35245958-1667159398-1173 Display Name : Jeremy Los OptionFlags : 256 ArchivingFlags : 0 Enabled : True MovingAway : False Unavailable : False RichMode : True Contact Version : 2 Permission Version : 1 Email : [email protected] Phone : Presence data : Contact Groups -------------- 1 Group Number : 1 Display Name : ~ External Uri : Containers ---------- 1 Container Number : 0 Container Version : 0 SameEnterprise : False Federated : False PublicCloud : False Everyone : True Member User : Member Domain : ...
On the Companion Media
For a full example of command output from dbanalyze, see the file dbanalyze-jeremy.txt on the companion media, located in the Appendixes,Scripts,ResourcesChapter 05 folder.
After you confirm that the user is enabled, also confirm that the global settings include the domain you selected for the SIP URI. This is a common issue for customers who have a SIP URI that does not match their Active Directory namespace or who have multiple SIP domains.
For example, the deployment for Litware might have used Litwareinc.local or Litwareinc.corp as the Active Directory namespace, which would require that we manually add Litwareinc.com to the list of domains supported by the configuration. If the server is listening with TCP, supported domains are no longer configured by default and therefore must be added. The benefit of adding TCP is that we can use the Internet Protocol (IP) address and a network analyzer in addition to the existing logs. Use the IP address first in the client configuration to eliminate any host name resolution problems. After confirmation, switch to the fully qualified domain name (FQDN) of the server to confirm host name resolution is working and, finally, configure for TLS over TCP with the FQDN of the server. After all of this has been verified, you can add the option of automatic configuration, which requires the Domain Name Service (DNS) Service Record Locator (SRV) records described later in Chapter 19.
Finally, new to Office Communications Server is diagnostics in the Office Communications Server Management Console. You can test connectivity and client sign-in, receiving a rather verbose output of the tests and status. If this still fails to provide you with a resolution to your problem, enable the client logs as described previously in this chapter and contact the support services team.
After registration is complete, a complex set of queries and notifications takes place between the client and the server as Communicator gathers information from the server and the rest of the network. Communicator gathers its own configuration information and then gathers presence information about users on the contact list. To speed things up, Communicator issues the first four subscriptions in parallel and receives the server responses as they come in. For simplicity, the requests and the responses are shown one by one, but keep in mind that this ordering is not precisely what is happening at the network level. Requests can be sent out in parallel by the client, and responses can come back in an unrelated order, based on network delays to and from each destination. Figure 5-5 provides an overview of the protocol messages exchanged between Communicator and the server infrastructure during this phase of the login process.
This subscription enables Communicator to see the contact list, but it also enables it to identify whether contacts are added on other clients with which the user might be logged in. If the contact list changes, the server sends a notification containing the change. A SUBSCRIBE message is sent to the server to initiate the subscription to the contact list, as follows:
SUBSCRIBE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=9099c0ba1d;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: ecb20da4280142d1b69b920276785d2f CSeq: 1 SUBSCRIBE Contact: <sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Event: vnd-microsoft-roaming-contactsAccept: application/vnd-microsoft-roaming- contacts+xml Supported: com.microsoft.autoextend Supported: ms-benotify Proxy-Require: ms-benotify Supported: ms-piggyback-first-notify Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="3b86002b", cnum="1", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff6150d616a8e990a9b9971b4585bea994" Content-Length: 0
The Event header identifies that the request is to get back the contact list (called roaming contacts). Other headers (such as the Supported and Proxy-Require headers) provide optional enhancements or specify capabilities to allow for more functionality to be put to use, specifically protocol optimizations. These optimizations include the use of BENOTIFY (which is a best-effort notification that does not require a response to confirm receipt), sending first notifications as part of the response to the subscription request, and automatic server extensions for subscriptions.
The response immediately includes information in the body because both the client and server support ms-piggyback-first-notify. This feature enables the information that typically needs to be sent in a subsequent NOTIFY message to simply be sent in the 200 response.
The server accepts the subscription to the contact list with a 200 response in which it also confirms protocol optimizations will be used and specifies that the subscription will be maintained for 41,472 seconds (11.5 hours), as follows:
SIP/2.0 200 OK Contact: <sip:srv.litwareinc.com:5061;transport=tls> ... (header info) CSeq: 1 SUBSCRIBE Expires: 41472 Content-Type: application/vnd-microsoft-roaming-contacts+xml Event: vnd-microsoft-roaming-contactssubscription-state: active;expires=41472ms- piggyback-cseq: 1 Supported: ms-benotify, ms-piggyback-first-notify <contactList deltaNum="17" > <group id="1" name="~" externalURI="" /> <contact uri="[email protected]" name="" groups="1" subscribed="true" externalURI="" > <contactExtension> <contactSettings contactId="0a1d4375-32d1-42b1-be25-41a6720d2dde"> </contactSettings> </contactExtension> </contact></contactList>
The response contains the user’s contact list (also called a buddy list). Because the ms-piggyback-first-notify extension was supported, the server provides the first notification in the body of the 200 response. Contacts and groups are identified, along with information about what groups they are in and whether they are maintained with an active subscription or just kept in the contact list.
Next, Communicator issues a subscription request for presence information about the user (Jeremy Los in this case), access-level settings that have already been configured by the user to control who has access to what information, and the list of contacts who currently have outstanding subscriptions.
SUBSCRIBE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=64ecc96946;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: bb8338fdba864da9bc9875dad6dbec7aCSeq: 1 SUBSCRIBE Contact: <sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Event: vnd-microsoft-roaming-selfAccept: application/vnd-microsoft-roaming-self+xml Supported: com.microsoft.autoextend Supported: ms-benotify Proxy-Require: ms-benotify Supported: ms-piggyback-first-notifyProxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="9c81fb7f", cnum="2", targetname="sip/srv.litwareinc.com", response="602306092a864886f71201020201011100ffffffffc33ae8f9e62252efa3320f9e3 99828e9" Content-Type: application/vnd-microsoft-roaming-self+xml Content-Length: 174 <roamingList xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self"> <roaming type="categories"/> <roaming type="containers"/> <roaming type="subscribers"/> </roamingList>
The Event header identifies the request as a subscription to information that pertains to the user (called roaming self). Again, Communicator identifies that it can support several protocol optimizations.
The server accepts the subscription with a 200 OK response. The body of the response contains a list of information about the user, established access levels that contacts have been granted, and users with current subscriptions. These messages are quite large and detailed, and this one does not contain much interesting content because not many contacts or access levels have been established yet. As the contact list grows and access control settings evolve, this XML document is expanded.
On the Companion Media
All the protocol messages referenced in these examples are on the companion media, in the Appendixes,Scripts,ResourcesChapter 05CD Protocol Logs folder, and can be viewed in their entirety there.
This user information is stored on the user’s home server in the SQL (MSDE) database and is used by the client and server to determine whether subscriptions from other users are accepted and whether messages for the client will be delivered or rejected. This subscription also lets Communicator know if other clients the user might have running on other machines change authorization settings, because the server sends a notification of the changes. This subscription also enables Communicator to be notified when new subscriptions from other users come in so that the user can decide how to handle them.
After the subscription is initiated, a notification is eventually sent out by the server. An example of that best-effort notification is shown next for reference. (The majority of the XML body was removed for brevity, but it can be viewed from the protocol logs on the companion media.)
BENOTIFY sip:192.168.3.100:2062;transport=tls;ms-opaque=4d8a610d50;ms- received-cid=00002700 SIP/2.0 Via: SIP/2.0/TLS 192.168.3.1:5061;branch=z9hG4bK0F226A22.4AC8062C;branched=FALSE Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFFF85D8DA4A3CF277F582B4D4AF1AEBED6", srand="88553BCA", snum="8", opaque="A7AB18E7", qop="auth", targetname="sip/srv.litwareinc.com", realm="SIP Communications Service" Max-Forwards: 70 To: <sip:[email protected]>;tag=64ecc96946;epid=aa6d968e18Content-Length: 7638 From: <sip:[email protected]>;tag=9A750080 Call-ID: bb8338fdba864da9bc9875dad6dbec7a CSeq: 2 BENOTIFY Require: eventlist Content-Type: application/vnd-microsoft-roaming-self+xml Event: vnd-microsoft-roaming-self subscription-state: active;expires=51410 <roamingData ... </roamingData>
Communicator next issues a subscription for provisioning information to help with initial configuration. This subscription is a one-time query (denoted by the Expires header, which asks for 0 seconds for the subscription lifetime). This subscription asks for server configuration, meeting policies, and policy settings that Communicator must enforce.
SUBSCRIBE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=e7c43a41fd;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: 7ea128a6ebe34481b5daa76132607e34 CSeq: 1 SUBSCRIBE Contact: <sip:[email protected];opaque= user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu>User-Agent: UCCP/2.0.6093.0 OC/ 2.0.6093.0 (Microsoft Office Communicator) Event: vnd-microsoft-provisioning-v2 Accept: application/vnd-microsoft-roaming-provisioning-v2+xml Supported: com.microsoft.autoextend Supported: ms-benotify Proxy-Require: ms-benotify Supported: ms-piggyback-first-notify Expires: 0 Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="e7e65db3", cnum="3", targetname= "sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff4dca80cf37e7ee6998209ab5923fc3cd" Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xml Content-Length: 242 <provisioningGroupList xmlns= "http://schemas.microsoft.com/2006/09/sip/provisioninggrouplist"> <provisioningGroup name="ServerConfiguration"/> <provisioningGroup name="meetingPolicy"/> <provisioningGroup name="ucPolicy"/> </provisioningGroupList>
The server accepts the one-time provisioning query with a 200 OK response, which contains a rich set of configuration and provisioning information for the client.
The provisioning information contains information about the Computer Telephony Integration (CTI) gateway for the user (one does not exist in this example) and the Address Book Server (ABS) URL for the user: http://srv.litwareinc.com/Abs/Int. Additional information about phone integration and the CTI gateway can be found in Chapter 9. The Address Book Server URL offers Communicator a location where it can download basic information about enterprise users so that Communicator can search across these names to enable users to quickly add known contacts in the organization.
Note
An example of using the Address Book Server information is shown in the section titled "Step 1: Looking Up a Contact" later in the chapter, which is part of the section titled "A Presence Sharing Scenario." Following that section, the section titled "Technical Details Behind the Presence Sharing Scenario" covers the related technical details.
This response contains information about how to find the ABS, which enables fast and remote lookups of the corporate address book, provisioning information, and meeting and unified communications policy settings.
Next, Communicator issues a one-time query to identify which media types the server infrastructure can support for multiparty conferences. It sends a SERVICE request asking for the available multipoint control units (MCUs) to determine the media types that are available (IM, phone, and audio/video).
SERVICE sip:[email protected];gruu;opaque=app:conf:focusfactory SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=43cae3a206;epid=aa6d968e18 To: <sip:[email protected];gruu;opaque=app:conf:focusfactory> Call-ID: 2d7ca35fab1c45d1917bbdf754871b0c CSeq: 1 SERVICE Contact: <sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="0ca09d1a", cnum="4", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff4b8520aacbeee71780ccd31c1f2d1675" Content-Type: application/cccp+xml Content-Length: 302 <?xml version="1.0"?> <request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:[email protected];gruu;opaque=app:conf:focusfactory" from="sip:[email protected]" requestId="17694972"> <getAvailableMcuTypes/> </request>
The server responds successfully and specifies that audio and video (audio-video), data conferencing and application sharing (meeting), instant messaging (chat), and phone conferencing (phone-conf) MCUs are available for use as shown in the body of the 200 OK response, as follows:
SIP/2.0 200 OK ... (header info) CSeq: 1 SERVICE Content-Type: application/cccp+xml <response xmlns="urn:ietf:params:xml:ns:cccp" ... <getAvailableMcuTypes> <mcu-types> <mcuType>audio-video</mcuType> <mcuType>meeting</mcuType> <mcuType>chat</mcuType> <mcuType>phone-conf</mcuType> </mcu-types> </getAvailableMcuTypes> </response>
Communicator also queries for its location profile to get dialing rules. It issues another SERVICE request, as follows:
SERVICE sip:[email protected];gruu;opaque=app:locationprofile:get;default SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=43cae3a206;epid=aa6d968e18 To: sip:[email protected];gruu;opaque=app:locationprofile:get;default Call-ID: 0842328998844bbe9602c6576997f359 CSeq: 1 SERVICE Contact: sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu User-Agent: UCCP/2.0.6249.0 OC/2.0.6249.0 (Microsoft Office Communicator) Accept: application/ms-location-profile-definition+xml Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="E8DC04B4", crand="d93f8137", cnum="4", targetname="sip/srv.litwareinc.com", response="0100000033323839c87cccc75ec0b9fe" Content-Type: application/ms-location-profile-definition+xml Content-Length: 2
A 200 OK response from the server shows the dialing plan that is in place that the client should use, and it provides guidance on how extensions listed on a contact should be dialed in the last rule. This chapter simply points out these items. Additional information is provided in later chapters covering telephony and Voice over IP (VoIP).
Communicator now uses the contact list that was received during the query for roaming contacts and issues a batch subscription against all contacts. (There happens to be only one in this example, but there could be tens and even hundreds, depending on the user.) The subscription also lists the things that are of interest from the remote contacts (calendar information, notes, presence state, and so on). The batch subscription is sent in the body of a SUBSCRIBE message, as follows:
SUBSCRIBE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=8024faf8af;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: a1eeb9389b0b445d93eafcf531533371 CSeq: 1 SUBSCRIBE Contact: <sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Event: presence Accept: application/msrtc-event-categories+xml, application/xpidf+xml, text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/related Supported: com.microsoft.autoextend Supported: ms-benotify Proxy-Require: ms-benotify Supported: ms-piggyback-first-notify Require: adhoclist, categoryList Supported: eventlist Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="e396cb73", cnum="5", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff664a5be74c5546f938944757f539c2ed" Content-Type: application/msrtc-adrl-categorylist+xml Content-Length: 489 <batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/ batch-subscribe" uri="sip:[email protected]" name=""> <action name="subscribe" id="18640544"> <adhocList><resource uri="sip:[email protected]"/></adhocList> <categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist"> <category name="calendarData"/><category name="contactCard"/> <category name="note"/> <category name="services"/> <category name="sourcenetwork"/> <category name="state"/> </categoryList> </action> </batchSub>
The server responds with a successful response to the batch subscription in the form of a 200 OK response, as follows:
SIP/2.0 200 OK Contact: <sip:srv.litwareinc.com:5061;transport=tls> ... (header info) CSeq: 1 SUBSCRIBE Expires: 27360 Require: eventlist Content-Type: multipart/related; type="application/rlmi+xml";start=resourceList; boundary=f018561c40be4d03b799bff0e31ca241 Event: presence subscription-state: active;expires=27360 ms-piggyback-cseq: 1 Supported: ms-benotify, ms-piggyback-first-notify-- f018561c40be4d03b799bff0e31ca241Content-Transfer-Encoding: binary Content-ID: resourceList Content-Type: application/rlmi+xml <list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:[email protected]" version="0" fullState="false"/>--f018561c40be4d03b799bff0e31ca241Content- Transfer-Encoding: binaryContent-Type: application/msrtc-event-categories+xml <categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"> <category name="calendarData"/> <category name="contactCard" instance="0" publishTime= "2007-05-03T05:37:43.843"> <contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard" > <identity > <name ><displayName >Rui Raposo</displayName></name> </identity> </contactCard> </category> <category name="note"/> <category name="state" instance="1" publishTime="2007-05-04T22:46:17.583"> <state xsi:type="aggregateState" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> </state> </category> <category name="services" instance="0" publishTime="2007-05-04T22:46:17.583"> <services xmlns="http://schemas.microsoft.com/2006/09/sip/service"> <service uri="sip:[email protected]"> <capabilities> <text render="true" capture="true" deviceAvailability="3500" /> <gifInk render="true" capture="false" deviceAvailability="3500" /> <isfInk render="true" capture="false" deviceAvailability="3500" /> </capabilities> </service> </services> </category> </categories> --f018561c40be4d03b799bff0e31ca241--
The server is actually returning presence information for users that it maintains information for. In this example, the only existing contact, Rui, happened to be maintained on the same server, so his subscription is already confirmed (subscribed="true"). Because of this, Communicator itself does not need to issue any subscription requests directly. The server can accept all subscriptions locally. If some of the contacts are not maintained on the same server, Communicator manages to send a separate subscription directly to each contact (to which the remote contact’s home server responds).
The rich presence schema shows the user’s availability, activity, displayName, e-mail, phoneNumber, userInfo, and devices. The availability section identifies whether the user is busy either because his calendar currently has an appointment or because he manually set his availability. This information is combined, interpreted, and stored in an aggregate numeric value that determines availability. It is worth knowing that these number values are compared to known ranges that Communicator uses to aggregate activity and availability levels into states. The activity section is similar and combines information from all workstations to track whether the user is active, idle, or logged out. The userInfo section contains global information for the user that is used to compose the underlying data that contacts can view (depending on their level of access). The devices section contains a list of devices and the information that each of these devices publish. This information is merged by the server to give a singular view of the user and offer means for connectivity.
Finally, Communicator generates presence information for the client and publishes that information by sending a SERVICE request to the server with an embedded XML publish command, as follows:
SERVICE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70 From: <sip:[email protected]>;tag=7ae5f901b8;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: d661a29ddb364c61ab1009edbe5e2b95 CSeq: 1 SERVICE Contact: <sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="8ddc94ae", cnum="6", targetname="sip/srv.litwareinc.com", response="602306092a864886f71201020201011100ffffffff2a567bb3a6d1ce598e39074 cf9e13419"Content-Type: application/msrtc-category-publish+xml Content-Length: 1392 <publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence"> <publications uri="sip:[email protected]"> <publication categoryName="device" instance="198826231" container="2" version="0" expireType="endpoint"> <device xmlns="http://schemas.microsoft.com/2006/09/sip/device" endpointId="6BF396BA-A7D6-5247-89FB-C13B52F5840D"> <capabilities preferred="false" uri="sip:[email protected]"> <text capture="true" render="true" publish="false"/> <gifInk capture="false" render="true" publish="false"/> <isfInk capture="false" render="true" publish="false"/> </capabilities> <timezone>00:00:00-06:00</timezone> <machineName>OC-CLIENT</machineName> </device> </publication> <publication categoryName="state" instance="817733007" container="3" version="0" expireType="endpoint"> <state xmlns="http://schemas.microsoft.com/2006/09/sip/state" manual="false" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="machineState"> <availability>3500</availability> <endpointLocation></endpointLocation> </state> </publication> <publication categoryName="state" instance="817733007" container="2" version="0" expireType="endpoint"> <state xmlns="http://schemas.microsoft.com/2006/09/sip/state" manual="false" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="machineState"> <availability>3500</availability> <endpointLocation></endpointLocation> </state> </publication> </publications> </publish>
The server accepts this presence publication with a 200 OK response that contains the complete presence document for the user across all devices, after the published presence information for this workstation is taken into account, as follows:
SIP/2.0 200 OK ... (header info) CSeq: 1 SERVICE Content-Type: application/vnd-microsoft-roaming-self+xml <roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self" xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories" xmlns:con="http://schemas.microsoft.com/2006/09/sip/containers" xmlns:sub="http://schemas.microsoft.com/2006/09/sip/presence-subscribers"> <categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"> <category name="state" instance="1" publishTime="2007-05-04T22:48:10.357" container="2" version="1" expireType="user"> <state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> </state> </category> <category name="state" instance="268435456" publishTime="2007-05-04T22:48:10.357" container="2" version="1" expireType="user"> <state xsi:type="aggregateMachineState" endpointId="6bf396ba-a7d6-5247-89fb-c13b52f5840d" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> </state> </category> <category name="state" instance="817733007" publishTime="2007-05-04T22:48:10.357" container="2" version="1" expireType="endpoint" endpointId="6BF396BA-A7D6-5247-89FB-C13B52F5840D"> <state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false" xsi:type="machineState" > <availability >3500</availability> <endpointLocation ></endpointLocation> </state> </category> <category name="device" instance="198826231" publishTime="2007-05-04T22:48:10.357" container="2" version="1" expireType="endpoint" endpointId="6BF396BA-A7D6-5247-89FB-C13B52F5840D"> <device xmlns="http://schemas.microsoft.com/2006/09/sip/device" endpointId="6BF396BA-A7D6-5247-89FB-C13B52F5840D" > <capabilities preferred="false" uri="sip:[email protected]" > <text capture="true" render="true" publish="false" ></text> <gifInk capture="false" render="true" publish="false" ></gifInk> <isfInk capture="false" render="true" publish="false" ></isfInk> </capabilities> <timezone >00:00:00-06:00</timezone> <machineName >OC-CLIENT</machineName> </device> </category> ... (additional presence information for each category) </categories></roamingData>
For all users who are not maintained on the same server that the user is, the bulk subscription response tells Communicator to resubscribe. After Communicator finishes registering and establishing subscriptions for basic user settings and local contacts on its server, it moves into the logged-in state and enables the user to start issuing commands and viewing presence information.
To prevent delays because of slower links, Communicator waits to gather presence information for users who are not maintained on the same server until after the client UI is presented and the user is logged in. Communicator then issues individual subscriptions for all the remaining users by issuing a small set of subscriptions and issuing the next subscriptions as the previous subscriptions complete. The scenarios described do not have additional contacts that are not homed on the same server, so this is not presented in detail. However, a simple subscription dialog is established for each contact, and notifications of presence changes occur directly with the server where the contact is maintained.
At this point, the login process is complete. It is worth understanding that this login section simply establishes connectivity and an authenticated relationship with the infrastructure, gathers information about the user and the Office Communications Server infrastructure, and establishes the subscriptions used to get real-time updates. Additional work is required of Communicator to maintain these subscriptions to prevent them from expiring over time and to refresh the authenticated registration established with the infrastructure. The following sections discuss features and functionality provided by Communicator 2007 after it is logged in.