This chapter introduces the basic login process, presence, and instant messaging (IM), and it discusses the services and capabilities that these provide. The chapter walks through a user-level view of actions taken in Microsoft Office Communicator 2007 for each of these three areas, and then explains in depth the same actions with a view of the protocols, algorithms, and systems that make these processes work. This chapter also provides the core background on basic server and client operations in terms of discovery, connectivity and communications over the Session Initiation Protocol (SIP) and as such is useful to refer back to as reference material when exploring other scenarios.
The login process seems simple from the user perspective, because it involves only starting Office Communicator 2007 and typing in a user name and credentials. However, this section provides a more in-depth understanding of how Microsoft Office Communications Server 2007 and Communicator 2007 interact to help provide security and to establish a reliable communications channel. This information is critical for troubleshooting user logins that fail, as well as providing the technical background to troubleshoot most client connectivity, authentication, or discovery issues.
Presence information can be managed and shared, allowing users to know 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 at his or her desk and finished with a meeting, contact someone without having to initiate a phone conversation in order to get an immediate answer, or 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 while 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 instant messaging, for an individual and a group, 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.
Before walking through the login process, it is important to understand why logging in is important at all, given the fact that it seems like such a simple operation. We will then walk through the login process from the user perspective, based on the steps taken and the feedback Communicator 2007 provides. Then we will walk through the technical steps, decisions, and protocols that are going on in the background. Doing so will provide a rich experiential understanding that will aid in troubleshooting login problems, infrastructure problems, and even extending the system programmatically.
When looking at key usage scenarios for Office Communications Server 2007, simply logging in from Communicator 2007 is a critical step. When this works properly, it seems to be nothing more than a way to get access to interesting scenarios, such as instant messaging and presence. However, when there are problems with the system, logging in might be the key issue. Additionally, understanding the technology details behind the login process can be a key difference between becoming an expert administrator or consultant and simply having experience using Communicator. The simple login process exercises so many key aspects of the technology behind Communicator and the server infrastructure that it is worth understanding in detail.
This scenario walks through a fictitious user, Jeremy Los, using Communicator 2007 to log in to Office Communication Server 2007. Office Communication Server 2007 must have already been installed on the enterprise network, and Jeremy must have already installed Communicator on his workstation. This overview assumes that he 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 overview shows what Jeremy sees during the login process and what steps he takes to complete the login.
Jeremy launches Communicator 2007 and clicks the Sign In button. Communicator asks for the Sign-In Address for his Communicator account, and he enters [email protected], which is the Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) with which his administrator provisioned him, as shown in Figure 4-1. Most administrators use a URI that matches the user's e-mail address, because it is easy for the user to remember. Jeremy then clicks OK.
If the user is not currently logged in to the workstation with domain credentials, Communicator prompts him for sign-in information. Jeremy enters his Windows Server operating system account user name and password, and then clicks Sign In, as shown in Figure 4-2. 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, as shown in Figure 4-3.
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 4-4.
Let's explore what is happening with Communicator 2007 and the Office Communications Server network in technical detail at the network level. We will explore registry settings, logging, Domain Name System (DNS) usage, authentication, connectivity, and the SIP in detail, as they are all involved in the login process. The following diagram 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. As of this release, Communicator logging can now be controlled through the General menu when you select Options from the Tools menu. There are two check boxes on the dialog box to 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
Even if you are a protocol and technical expert, you will likely find only about half of the contents of these log files to be of use, because they contain raw programmer data from the Communicator protocol stack. Because of this, it is best to use a tool to examine the log files, or read through the explanation of client log files provided in Chapter 16. Also important to note is that in Windows Vista, a user must be a member of the Performance Log Users group to enable logging.
Enabling the Communicator Protocol Logs The logging options shown in the Communicator user interface (UI) manage values under the registry key HKEY_CURRENT_USERSoftwareMicrosoftTracingUccpCommunicator. The value EnableFileTracing can be turned on or off by setting it to 0 or 1, respectively. MaxFiles is set to 2 by default, but you can specify that only one file should be created or that many 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. For almost all users, the default settings should be fine and no adjustments will need to be made, but it can be valuable to increase the maximum file size when diagnosing problems. Please note that manually changing these registry values requires a restart of Communicator, in order for them to be read and to take effect.
The default settings create the log in %USERPROFILE% racingCommunicator-uccp-0.uccplog, which is generally in C:Documents and Settings<username> racingCommunicator-uccp-0.uccplog. As previously mentioned, the default settings create two log files with up to 8.3 MB of logs for each. After the first file (mentioned earlier) fills, the second file, Communicator-uccp-1.uccplog, is used. After it fills, the content from it overwrites the first log file, it clears itself, and then it adds new content—until it runs out of space and overwrites the first log file again.
Note
Note that enabling the Turn On Logging In Communicator check box also creates an .etl file, which is used only by Product Support Services (PSS) to troubleshoot issues.
Working with Communicator Application Event Logs Even though the detailed log provides a lot of information, if event logs are enabled in Communicator, it also creates entries in the Application Event logs when there are failures, in order to provide diagnostic information. These entries are useful for diagnosing login problems. A few examples of messages are shown next for reference. They clearly explain the problem, point at the data related to the problem, and explain the steps required for solving the problem.
This first error message shown occurred because Communicator was configured with an invalid server name, IConfiguredAnInvalidServerName.contoso.com. The message explains that Communicator could not find a server with that name anywhere, as follows:
Communicator was unable to resolve the DNS hostname of the login server IConfiguredAnInvalidServerName.contoso.com. Resolution: If you are using manual configuration for Communicator, please check that the server name is typed correctly and in full. If you are using automatic configuration, the network administrator will need to double-check the DNS A record configuration for IConfiguredAnInvalidServerName.contoso.com because it could not be resolved. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
The second 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.contoso.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.contoso.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 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.
Communicator additionally loads up its configuration settings from group policy and the registry, and discovers whether it is set to automatically log in. For this example, it was assumed that it is not set to automatically log in, so it simply waits for the user to prompt login.
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. At any rate, automatic configuration takes over at this point to allow the server to determine where to log in. For additional details, see the "Understanding Client Automatic Configuration and DNS Discovery" section later in this chapter.
After the client discovers the server to connect to, it attempts to connect using TCP or TLS over TCP. This might have its own complications or stumbling points. If the TCP connection comes up and TLS will be used, the server provides a certificate to authenticate itself for the connection, and the client must validate the certificate. Finally, the client might negotiate compression (if using TLS over TCP), and then it will try to initiate a SIP registration. For additional details, see the "Understanding Connectivity Establishment and Optional Compression Negotiation" section later in this chapter.
Next, the client sends a SIP REGISTER message to the server without any credentials. This prompts Office Communications Server to challenge for credentials, and it allows Communicator to discover the authentication protocols that can be used for subsequent logins to this server. Without this step, Communicator does not know which authentication protocols to use, which information can be used for the authentication process (such as Kerberos or NTLM), or which service principal name (SPN) should be used when obtaining a Kerberos ticket. For additional details, see the "Examining the Initial Registration" section later in this chapter.
When it comes to providing credentials, Communicator has two options. Communicator can use the user's current desktop credentials to log in, or it can ask the user for credentials and they can be provided manually through the UI. This second option is what was shown earlier in the Step 2: Supplying Account Credentials (If Prompted) section.
Note
The credentials manager in Windows can also be used to manage credentials. More information on the credentials manager can be found in the Microsoft TechNet article "Windows XP Resource Kit: Understanding Logon and Authentication" at http://technet.microsoft.com/en-us/library/bb457114.aspx, in the "Stored User Names and Passwords" section.
Because of the order in which Communicator tries to satisfy the server's request for credentials, authentication failures can occur during the first part of login processing. This can happen when credentials are not already saved or if the desktop credentials do not match the account that Communicator is trying to use. This can also happen when the SIP URI, account name, or password is typed incorrectly or when credentials and the SIP URI do not match. An example of this is if Jeremy tries to log in with the URI sip:[email protected], but he uses the user account and password for CONTOSOvadim instead of the account owner's own credentials, CONTOSOjeremy. For additional details, see the "Examining the Authenticated Registration" section later in the chapter.
Understanding Client Automatic Configuration and DNS Discovery When the client is set to use automatic configuration, it leverages the SIP URI that was provided to discover where it should log in to. Communicator does this using DNS SRV records published for the domain portion of the SIP URI. For example, if sip:[email protected] is the URI that is provided, Communicator takes contoso.com and tries to discover a SIP server using DNS. Communicator can query for the following SRV records in its search for an appropriate server:
_sipinternaltls._tcp.contoso.com
_sipinternal._tcp.contoso.com
_sip._tls.contoso.com
Failing these, it falls back to host (A) record queries:
The first query looks for an internal server in the contoso.com domain that offers ports supporting TLS over TCP for clients. The second query seeks to discover an internal server in the contoso.com domain that offers TCP ports for clients. Finally, the third query looks for an Internet-reachable server for the contoso.com domain that offers ports supporting TLS over TCP for clients. Communicator never looks for an Internet-reachable server that supports TCP, because use of clear-text SIP on the Internet does not make sense from a security standpoint. In other words, Communicator is not aware whether the network that is being used is internal or external. Communicator queries for all DNS SRV records; however, it tries TLS over TCP connections first. TLS over TCP is forced through an Edge Server (no option to allow for unsecured TCP connections).
Finally, if all the DNS SRV records do not exist (not if they fail to be valid; only if they do not exist at all), the client falls back to sipinternal.<URI domain> and attempts to resolve that hostname. If the hostname resolves to an IP address, Communicator tries to connect using TLS over TCP, TCP, or both, depending on what the policy allows. If this fails, it will try one last time with sipexternal.<URI domain>.
Communicator policies can be put in place to prevent TCP from being used, and this prevents the second query from being issued. Policy can also be specified that requires strict names for the machines discovered. In this case, the only server name allowed is 'sip.' If this limitation is not imposed, any server name of the form <servername>.<URI domain> is allowed. As an example, for sip:[email protected], the host sip.contoso.com is always allowed (strict policy or not). Server77.contoso.com, sipfed.contoso.com, and ap.contoso.com are all also allowed if strict naming policy is not enabled. The following server names are never allowed because they do not tightly fit the domain that the user's URI specified, and therefore, the client does not trust these servers as valid login points: sip.eng.contoso.com, sip.contoso.net, sip.com, sip.contoso.com.cpandl.com, and so on.
This tight validation between the hostname and the URI is done specifically because the only configuration with which the client is provided is the SIP URI. Because of this, the client must be very careful not to allow DNS attacks to allow it to connect to any man-in-the-middle, who could thereby watch Communicator's traffic. By having a tight tie between the URI and the hostnames allowed for login, Communicator has better certainty that the certificate the user is validating actually has authority for the domain to which he is trying to log in.
After the hostname is identified, Communicator also resolves the hostname to an IP address. This usually happens as the result of the DNS SRV request, but until the IP address is resolved, Communicator cannot connect. This can be a problem during login as well.
The latest version of Communicator enables the ability to manually specify both an internal and external server to log in against. Communicator always attempts to connect to the internal server if it is available, but it falls back to the external server. Previously, Communicator had only a single manual entry, which created problems for mobile workers. With the ability to specify an internal and external server, it is now easy for administrators to configure and enable laptop configurations that work across internal and external networks. This increased functionality is also important for companies where the domain in the user's URI is not the same as their SIP enterprise server's domain. Because the administrator can configure Communicator (on a laptop, for example) once, the user does not need to remember the internal or external servers and administrators do not have to publish DNS SRV records for all the domains they want to support for remote access users.
Understanding Connectivity Establishment and Optional Compression Negotiation When a TCP or TLS over TCP connection is established with the server, there are some basic things that can go wrong. To start with, the IP address could be unreachable because of firewalls, service outage, or lack of connectivity. It might be possible to create a connection, but traffic on the connection could be filtered, or the connection could be torn down by an intermediary firewall or proxy.
Note
To verify network connectivity, you can use ping.exe <server_FQDN> to connect to the server and telnet.exe <server_FQDN> 5060 or 5061 to see if the server is listening. As an aside, for Windows Vista workstations the telnet.exe is not installed by default. It can, however, be enabled via the Control Panel by enabling the Windows feature named Telnet Client.
If connectivity is not an issue, TLS negotiation might take place. TLS negotiation involves an exchange of credentials from the server and the exchange of a symmetric encryption key that is used to authenticate and encrypt the secure channel. This can fail when Communicator attempts TLS negotiation to an Office Communications Server port that is configured for only "TCP," when the server's certificate does not pass validation, or when the server wants to support only servers on a mutual transport layer security (MTLS) port and closes the connection when Communicator cannot provide a valid server certificate.
Note
A technical reference for TLS can be found by searching for the Microsoft TechNet article "TLS/SSL Technical Reference" at http://technet.microsoft.com.
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.
Examining the Initial Registration 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:
REGISTERsip:contoso.com SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2060 Max-Forwards: 70From:<sip:[email protected]>;tag=7ad9af1eb1;epid=aa6d968e18To:<sip:[email protected]> Call-ID: 5d2ad5f9e7a24dacaf1075b97a04df91 CSeq: 1 REGISTERContact:<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. A walkthrough of how to enable logging and a pointer to where the log files show up can be found in the "Examining What Happens During the Initial Launch of Communicator 2007 (Pre-Step 1)" section earlier in this chapter.
The server's expected response is to challenge the request for authentication. In the response shown next, the server is asking for Kerberos or 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.contoso.com).
SIP/2.0401 UnauthorizedDate: Fri, 04 May 2007 22:48:06 GMTWWW-Authenticate:NTLM realm="SIP Communications Service", targetname="srv.contoso.com", version=3WWW-Authenticate:Kerberos realm="SIP Communications Service", targetname="sip/srv.contoso.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
Examining the Authenticated Registration 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, because Communicator must submit an anonymous REGISTER again, identify that NTLM is challenged for again, and then specify that it wants to use NTLM in its next REGISTER to prompt the server to 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 utilizing 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 detailed information on Kerberos and NTLM, search for the Microsoft TechNet article "Kerberos Authentication Technical Reference" at http://technet.microsoft.com or the Microsoft Developer Network (MSDN) article "NTLM Authentication" at http://msdn.microsoft.com.
Figure 4-5 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:
REGISTERsip:contoso.com SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70From:<sip:[email protected]>;tag=59e091cf1e;epid=aa6d968e18To:<sip:[email protected]>Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 2 REGISTERContact:<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.contoso.com", gssapi-data= "YIIEmwYJKoZIhvcSAQICAQBuggSKMIIEhqADAgEFoQMCAQ6iBwMFAAAAAACjggOzYYIDrz CCA6ugAwIBBaENGwtDT05UT1NPLkNPTaIhMB+gAwIBAqEYMBYbA3NpcBsPc3J2LmNvbnRvc28uY2 9to4IDcDCCA2ygAwIBF6EDAgECooIDXgSCA1rI7odT+1XkCmcmUku44wiQe9tfZ5/zWmqYhJJuqS l3u1qDE465czd3oazEyfIOOrDHzghrQE+CDtRe88oy2iwcVPHK4fl9QhovQy1xGjszfSBjfwR7O3 0zDlgODRb+1Yvw8zN2viDrc/N2s5vaIJtPyt2XZCV48BQYGBa1P8i4BuMvm52R11H2oc2JGtmAnR qX/25ox9YWh48eGMvE1e3qfVRAkNVjfqDTZ1CfRUzJ6rNMKjuL2bgByyMMR3/VnFGURA0p/tUZxN gUusckeFM2WM8YCJWno2Q2ISZ8TMYVSKeh3WWLSAsxnS71qQmgQ1oXmEfdqAEKXUSmAT+X7NqT2Y u1VVvUYQnFfE9dHEcPE+5KyTM2gRMhAJXzUqVKKDK0dHbzsHqYGbn0kB5+NU+STKvy0V0PGIMIPN FXTyHHFdfBpwykYRr6Nayoxdmv06+EJ9I5GFPV7zFlJHaan1TwDTMUvGW4LZla2wkPQDfiuuTsMl QgaXwD4vEZVPou0vMKiJMGtZawSuxisRTxsiD0n9TJCaBYYiHFntWI1Gk/m+rnMglkOFkgEUybUp 5k9S2lE8zyf1U50+e8rUtGkgIdeJesjBuYXFrYVOYEOL6aR/5Fsm7sAOTjEjtoA/3HyYKm1eHgiv 3GVwMGP8dtSwsIZwT5XQN81VZpkfgihjAcNt9oe/lO2t6z61+Uw/XPFUf43prpqESkWN/7FFyccV K8IkKnyixXeBSRuNDR/SXq7RSm+UEQH2Yfd+JPl4Q67eX1oynvXtb1c9VB0aT7FoOPBMpgxMG/PR 9VdCsSSVU4u+FC2z0gGb/8EDExxX5fI3q05Ge5msgcS8WfZn1D9KphfpFYl7SHki3ddo4A4Eu28T lxS2JjC9lOijwUd3hG4ah1DmpIPNfvL51a2GBG9o/aucJceya0ZhOzwwbx6vfyPPwhIH5/nfQ0rA zsrnj/caCYxA12/IA9j8zXA/4rQoLYv+G9ezv3uMZcGi8t3/UdXhAToFn5g7sTelhRCs7Mw2GjQV 78UbNaIYfD3okEkV6q8oVJAQZrO+HTmzupbBKJSLE52vLDi/xP5zu5vMdiYLC2rK6KVnKRcviQUi QO7y1wqt01LslJgy/hi1/t54fy6g+oo1LEb+h/RB6kgbkwgbagAwIBF6KBrgSBq0IepRK7up8fT8 PamkrLq/cQBwiMqZcoLGt/MMs2bAlQOVZ6alrnK4m50X4PeZtF+YhLf65NnDBt4ye7HhenecTLWN DvH/FHSW1DbvgqnmM8j2KhFQSFrJfuqEYNB159mEfJRp6KE+mYIBASTVR0BqCCoSmsFQiQ3pRr1r yx4ACRI74BzN6ODtncwEnXWQbuJYxsem0Xmf01SZoiDl2upGIvzcKYpFJ2atKgsw==" Supported: gruu-10, adhoclist, msrtc-event-categories Supported: ms-forking ms-keep-alive: UAC;hop-hop=yes Event: registration Content-Length: 0
As the message shows, 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 only reference 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 was in use, as follows:
REGISTERsip:contoso.com SIP/2.0... Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 2 REGISTER...Authorization:NTLM qop="auth", realm="SIP Communications Service", targetname="srv.contoso.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.0401 Unauthorized...WWW-Authenticate:NTLM opaque="33E7D13B", gssapi-data= "TlRMTVNTUAACAAAAAAAAADgAAADzgpjiFRIiVZ/HsigAAAAAAAAAAOQA5AA4AAAABQLODgAAAA8C AA4AUgBFAEQATQBPAE4ARAABABgAUgBFAEQALQBMAEMAUwBEAFIALQAwADEABAA0AHIAZQBkAG0Ab wBuAGQALgBjAG8AcgBwAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQADAE4AcgBlAGQALQBsAG MAcwBkAHIALQAwADEALgByAGUAZABtAG8AbgBkAC4AYwBvAHIAcAAuAG0AaQBjAHIAbwBzAG8AZgB 0AC4AYwBvAG0ABQAkAGMAbwByAHAALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAAAAAAA=", targetname="srv.contoso.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:
REGISTERsip:contoso.com SIP/2.0... Call-ID: 2fd39df030554515a412e3aa2964489f CSeq: 3 REGISTER...Authorization:NTLM qop="auth", opaque="33E7D13B", realm="SIP Communications Service", targetname="srv.contoso.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. Therefore, the following causes are possible:
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 typo in the account 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 typo 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 for when an Access Edge Server was 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 is from 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. (sipfed.contoso.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.contoso.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 hostname 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 here.
In the example login, the server accepts the registration with a 200 OK response, as follows:
SIP/2.0200 OKms-keep-alive:UAS; tcp=no; hop-hop=yes; end-end=no; timeout=300Authentication-Info:Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF5C001B875485F1BC7E66F0006 6537A78", srand="40882645", snum="1", opaque="A7AB18E7", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid=2700From:"Jeremy Los"<sip:[email protected]>;tag=59e091cf1e;epid=aa6d968e18To:<sip:[email protected]>;tag=A1F542AB99D66616F9252CB6DF50257FCall-ID:2fd39df030554515a412e3aa2964489f CSeq: 2 REGISTERContact:<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:7200presence-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
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 for. It must be refreshed within 7200 seconds (2 hours) or it will automatically expire and be cleaned up by the server.
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 4-6 provides an overview of the protocol messages exchanged between Communicator and the server infrastructure during this phase of the login process.
This subscription allows 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:
SUBSCRIBEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70From:<sip:[email protected]>;tag=9099c0ba1d;epid=aa6d968e18To:<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+xmlSupported:com.microsoft.autoextendSupported:ms-benotifyProxy-Require:ms-benotifySupported:ms-piggyback-first-notify Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="3b86002b", cnum="1", targetname="sip/srv.contoso.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 allows 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 41472 seconds (~11.5 hours), as follows:
SIP/2.0200 OKContact: <sip:srv.contoso.com:5061;transport=tls> Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF395B434D61013C132B9A488AA61C861D", srand="1A6EE03C", snum="4", opaque="A7AB18E7", qop="auth", targetname="sip/ srv.contoso.com", realm="SIP Communications Service" Content-Length: 313 Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid="2700From:"Jeremy Los"<sip:[email protected]>;tag=9099c0ba1d;epid=aa6d968e18To:<sip:[email protected]>;tag=0A234943Call-ID:ecb20da4280142d1b69b920276785d2f CSeq: 1 SUBSCRIBEExpires:41472 Content-Type: application/vnd-microsoft-roaming-contacts+xmlEvent:vnd-microsoft-roaming-contactssubscription-state: active;expires=41472ms- piggyback-cseq: 1Supported:ms-benotify, ms-piggyback-first-notify <contactListdeltaNum="17" > <group id="1" name="~" externalURI="" /> <contacturi="[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:
SUBSCRIBEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70From:<sip:[email protected]>;tag=64ecc96946;epid=aa6d968e18To:<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+xmlSupported:com.microsoft.autoextendSupported:ms-benotifyProxy-Require:ms-benotifySupported:ms-piggyback-first-notifyProxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="9c81fb7f", cnum="2", targetname="sip/srv.contoso.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 have much interesting content in it because there are not many contacts or access levels that have been established yet. As the contact list grows and access control settings evolve, this XML document will be expanded. The response shown next is summarized in sections because it is long and actually just repeats information for various access-level containers. Where repetition has occurred, an ellipses (…) is shown with an explanation of what is removed.
Note
On the CD All the protocol messages shown in these examples are on the companion CD, in the Appendixes,Scripts,ResourcesChapter 04CD Protocol Logs folder, and can be viewed in their entirety there.
SIP/2.0200 OKContact: <sip:srv.contoso.com:5061;transport=tls> Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF1E4469D0C0EA14D4EFE584E6B2FB9CC0", srand="1FD3FD44", snum="5", opaque="A7AB18E7", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Content-Length: 7521 Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid="2700From:"Jeremy Los"<sip:[email protected]>;tag=64ecc96946;epid=aa6d968e18To:<sip:[email protected]>;tag=9A750080Call-ID:bb8338fdba864da9bc9875dad6dbec7a CSeq: 1 SUBSCRIBEExpires:51408 Require: eventlistContent-Type: application/vnd-microsoft-roaming-self+xmlEvent:vnd-microsoft-roaming-self subscription-state: active;expires=51408 ms-piggyback-cseq: 1 Supported: ms-benotify, ms-piggyback-first-notify <roamingDataxmlns="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="calendarData" instance="0" publishTime="2007-05-04T18:56:32.670" container="32000" version="1" expireType="static"/> <category name="calendarData" instance="0" publishTime="2007-05-04T18:56:32.670" container="100" version="1" expireType="static"/> <category name="contactCard" instance="0" publishTime="2007-05-03T05:40:44.113" container="32000" version="1" expireType="static"> <contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard" > <identity > <name ><displayName >Jeremy Los</displayName></name> </identity> </contactCard> </category> <category name="contactCard" instance="0" publishTime="2007-05-03T05:40:44.113" container="400" version="1" expireType="static">... (contactCard info repeated for containers 400, 300, 200, 100 and 0)<category name="note" instance="0" publishTime="2007-05-04T18:56:32.670" container="32000" version="1" expireType="static"/> <category name="note" instance="0" publishTime="2007-05-04T18:56:32.670" container="100" version="1" expireType="static"/> <category name="state" instance="0" publishTime= "2007-05-04T18:56:32.670" container="32000" version="1" expireType="static"> <state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false" xsi:type="aggregateState" > <availability >18500</availability> <endpointLocation ></endpointLocation> </state> </category> <category name="state" instance="0" publishTime="2007-05-04T22:47:48.977" container="400" version="1" expireType="static"> <state xsi:type="aggregateState" lastActive= "2007-05-04T22:47:48" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>18000</availability> </state> </category>... (state info repeated for containers 300, 200, 100, 3 and 2)<category name="routing" instance="0" publishTime="2007-05-04T18:56:28.233" container="32000" version="1" expireType="static"> <routing xmlns="http://schemas.microsoft.com/02/2006/sip/routing" name="rtcdefault" version="1" > <preamble xmlns="http://schemas.microsoft.com/02/2006/sip/routing" > <flags name="clientflags" value="block" ></flags> </preamble> </routing> </category> <category name="legacyInterop" instance="0" publishTime="2007-05-03T05:40:44.113" container="32000" version="1" expireType="static"> <legacyInterop availability="18500" /> </category> <category name="legacyInterop" instance="0" publishTime= "2007-05-04T22:47:48.977" container="400" version="1" expireType="static"> <legacyInterop availability="18000" /> </category>... (legacyInterop info repeated for containers 300, 200 and 100)<category name="userProperties" instance="0" publishTime= "2007-05-03T05:40:44.113" container="1" version="1" expireType="static"> <userProperties ><telephonyMode >None</telephonyMode></userProperties> </category> </categories> <containers xmlns="http://schemas.microsoft.com/2006/09/sip/containers"> <container id="32000" version="0"/> <container id="400" version="0"/> <container id="300" version="1"> <member type="user" value="[email protected]"/> </container> <container id="200" version="1"> <member type="sameEnterprise"/> </container> <container id="100" version="1"> <member type="federated"/> </container> <container id="3" version="0"/> <container id="2" version="0"/> <container id="1" version="0"/> <container id="0" version="0"> <member type="everyone"/> </container> </containers> <subscribers xmlns="http://schemas.microsoft.com/2006/09/sip/ presence-subscribers"/></roamingData>
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 allows 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 CD.)
BENOTIFYsip: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.contoso.com", realm="SIP Communications Service" Max-Forwards: 70To:<sip:[email protected]>;tag=64ecc96946;epid=aa6d968e18Content-Length: 7638From:<sip:[email protected]>;tag=9A750080 Call-ID: bb8338fdba864da9bc9875dad6dbec7a CSeq: 2 BENOTIFY Require: eventlist Content-Type: application/vnd-microsoft-roaming-self+xmlEvent:vnd-microsoft-roaming-self subscription-state: active;expires=51410 <roamingDataxmlns="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> ... </categories></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.
SUBSCRIBEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70From:<sip:[email protected]>;tag=e7c43a41fd;epid=aa6d968e18To:<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+xmlSupported:com.microsoft.autoextendSupported:ms-benotifyProxy-Require:ms-benotifySupported:ms-piggyback-first-notifyExpires:0 Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="A7AB18E7", crand="e7e65db3", cnum="3", targetname= "sip/srv.contoso.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, as follows:
SIP/2.0200 OKContact: <sip:srv.contoso.com:5061;transport=tls> Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF506A6B8D20F534E698E78206B898CF44", srand="F08BB38D", snum="2", opaque="A7AB18E7", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Content-Length: 2806 Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid="2700From:"Jeremy Los"<sip:[email protected]>;tag=e7c43a41fd;epid=aa6d968e18To:<sip:[email protected]>;tag=39420176Call-ID:7ea128a6ebe34481b5daa76132607e34 CSeq: 1 SUBSCRIBEExpires:0 Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xmlEvent:vnd-microsoft-provisioning-v2 subscription-state: terminated;expires=0 ms-piggyback-cseq: 1 Supported: ms-benotify, ms-piggyback-first-notify <provisionGroupList xmlns= "http://schemas.microsoft.com/2006/09/sip/provisiongrouplist-notification"> <provisionGroup name="ServerConfiguration" > <absInternalServerUrl>http://srv.contoso.com/Abs/Int</absInternalServerUrl> <organization>Corporation</organization> <consoleDownloadInternalUrl> http://office.microsoft.com/en-us/help/HA101733831033.aspx </consoleDownloadInternalUrl> <consoleDownloadExternalUrl> http://office.microsoft.com/en-us/help/HA101733831033.aspx </consoleDownloadExternalUrl> <helpdeskInternalUrl> https://srv.contoso.com/conf/int/TShoot.html </helpdeskInternalUrl> <dlxInternalUrl> https://srv.contoso.com/GroupExpansion/service.asmx </dlxInternalUrl> <dlxEnabled>true</dlxEnabled> <ucDiffServVoice>40</ucDiffServVoice> <ucVoice802_1p>5</ucVoice802_1p> <ucEnforcePinLock>false</ucEnforcePinLock> <ucMinPinLength>6 </ucMinPinLength> <ucPhoneTimeOut>10</ucPhoneTimeOut> <ucExchangeMWIPoll>3</ucExchangeMWIPoll> <ucPC2PCAVEncryption> Support encryption</ucPC2PCAVEncryption> <ucEnableSIPSecurityMode>High</ucEnableSIPSecurityMode> <updatesServerEnabled>false</updatesServerEnabled> <ucLocationProfile >Redmond</ucLocationProfile> <focusFactoryUri> sip:[email protected];gruu;opaque=app:conf:focusfactory </focusFactoryUri> <voiceMailUri> sip:[email protected];opaque=app:voicemail </voiceMailUri> </provisionGroup> <provisionGroup name="meetingPolicy" instanceId="{6B151D61-D98B-4A16-9D6C-8BBB3111228A}" > <instance> <property name="Name"><![CDATA[Default Policy]]></property> <property name="AllowIPVideo"><![CDATA[false]]></property> <property name="AllowIPAudio"><![CDATA[false]]></property> <property name="EnableAppDesktopSharing"><![CDATA[false]]></property> <property name="ColorDepth"><![CDATA[256]]></property> <property name="AllowAppSharingForExternalMeeting"><![CDATA[None]]></property> <property name="RetainPPTForExternalMeeting"><![CDATA[false]]></property> <property name="MeetingSize"><![CDATA[10]]></property> <property name="EnableDataCollaboration"><![CDATA[false]]></property> <property name="AllowPresenterToRecord"><![CDATA[false]]></property> <property name= "AllowPresenterToDelegateRecording"><![CDATA[false]]></property> </instance> </provisionGroup> <provisionGroup name="ucPolicy" instanceId= "{6B41BE99-5C45-41E5-B34C-F6B8D0079E7B}" > <instance> <property name="Name"><![CDATA[Default Policy]]></property> <property name="AllowUsersToChangeTeamSettings"><![CDATA[true]]></property> <property name="AllowSimultaneousRinging"><![CDATA[true]]></property> <property name="MaxTeamMembers"><![CDATA[5]]></property> <property name="PhoneRouteUsages"> <element> <![CDATA[CN={C491D082-9CD3-4A41-9A79-9DCEE38670EB},CN=Phone Route Usages,CN=RTC Service,CN=Services,CN=Configuration,DC=contoso,DC=com]]> </element> </property> </instance> </provisionGroup></provisionGroupList>
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.contoso.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 allow users to quickly add known contacts in the organization.
Note
An example of using the Address Book Server information is shown in the Step 1: Looking Up a Contact section later in the chapter—which is part of the Overview of the Presence Sharing Scenario section. Following that section, the Examining the Technical Details Behind the Presence Sharing Scenario section 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).
SERVICEsip:[email protected];gruu;opaque=app:conf:focusfactory SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70From:<sip:[email protected]>;tag=43cae3a206;epid=aa6d968e18To:<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.contoso.com", response= "602306092a864886f71201020201011100ffffffff4b8520aacbeee71780ccd31c1f2d1675" Content-Type: application/cccp+xml Content-Length: 302 <?xml version="1.0"?> <requestxmlns="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.0200 OKAuthentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF9C88E2ED809296A76C6F19B1B939F0F8", srand="87A1E1DD", snum="3", opaque="A7AB18E7", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Content-Length: 996 Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid="2700From:"Jeremy Los"<sip:[email protected]>;tag=43cae3a206;epid=aa6d968e18To:<sip:[email protected];gruu;opaque=app:conf:focusfactory>;tag=D7146366Call-ID:2d7ca35fab1c45d1917bbdf754871b0c CSeq: 1 SERVICE Content-Type: application/cccp+xml <responsexmlns="urn:ietf:params:xml:ns:cccp" xmlns:msacp="http://schemas.microsoft.com/rtc/2005/08/acpconfinfoextensions" xmlns:msav="http://schemas.microsoft.com/rtc/2005/08/avconfinfoextensions" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions" xmlns:msdata="http://schemas.microsoft.com/rtc/2005/08/dataconfinfoextensions" xmlns:msim="http://schemas.microsoft.com/rtc/2005/08/imconfinfoextensions" xmlns:ci="urn:ietf:params:xml:ns:conference-info" xmlns:cis="urn:ietf:params:xml:ns:conference-info-separator" xmlns:msls="urn:ietf:params:xml:ns:msls" requestId="17694972" C3PVersion="1" from="sip:[email protected];gruu;opaque=app:conf:focusfactory" to="sip:[email protected]" code="success"> <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.contoso.com", response="0100000033323839c87cccc75ec0b9fe" Content-Type: application/ms-location-profile-definition+xml Content-Length: 2
The response 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).
SIP/2.0 200 OK Authentication-Info: NTLM rspauth="01000000000000000225D5215EC0B9FE", srand="C8E1D4C1", snum="5", opaque="E8DC04B4", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Content-Length: 1277 Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid=2700 From: <sip:[email protected]>;tag=43cae3a206;epid=aa6d968e18 To: <sip:[email protected];gruu;opaque=app:locationprofile:get;default>; tag=D7146366 Call-ID: 0842328998844bbe9602c6576997f359 CSeq: 1 SERVICE Content-Type: application/ms-location-profile-definition+xml Server: APP/TranslationService3.0.0.0 <LocationProfileDescription xmlns= "http://schemas.microsoft.com/2007/03/locationProfileDescription"> <Name>Default</Name> <Rule><Pattern>^([3-7]d{4})$</Pattern><Translation>+142570$1</Translation></Rule> <Rule><Pattern>^([4,5,7,9]11)t?$</Pattern><Translation>+$1</Translation></Rule> <Rule><Pattern>^9([4,5,7,9]11)$</Pattern><Translation>+$1</Translation></Rule> <Rule><Pattern>^0$</Pattern><Translation>+14258828080</Translation></Rule> <Rule><Pattern>^9(d+)$</Pattern><Translation>+$1</Translation></Rule> <Rule><Pattern>^(+?)(d+)(X|x|EXT)(d+)$</Pattern><Translation>$1$2; ext=$4</Translation></Rule> </LocationProfileDescription>
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:
SUBSCRIBEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70From:<sip:[email protected]>;tag=8024faf8af;epid=aa6d968e18To:<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.contoso.com", response= "602306092a864886f71201020201011100ffffffff664a5be74c5546f938944757f539c2ed" Content-Type: application/msrtc-adrl-categorylist+xml Content-Length: 489 <batchSubxmlns="http://schemas.microsoft.com/2006/01/sip/ batch-subscribe" uri="sip:[email protected]" name=""> <actionname="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.0200 OKContact: <sip:srv.contoso.com:5061;transport=tls> Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF77907E97AFD6725C45B116D563B803E5", srand="DB5FE03E", snum="6", opaque="A7AB18E7", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Content-Length: 1576 Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid="2700From:"Jeremy Los"<sip:[email protected]>;tag=8024faf8af;epid=aa6d968e18To:<sip:[email protected]>;tag=EE220080Call-ID:a1eeb9389b0b445d93eafcf531533371 CSeq: 1 SUBSCRIBE Expires: 27360 Require: eventlist Content-Type: multipart/related; type="application/rlmi+xml";start=resourceList; boundary=f018561c40be4d03b799bff0e31ca241Event: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 <listxmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:[email protected]" version="0" fullState="false"/>--f018561c40be4d03b799bff0e31ca241Content- Transfer-Encoding: binaryContent-Type: application/msrtc-event-categories+xml <categoriesxmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"> <category name="calendarData"/> <categoryname="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> <categoryname="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, phone-Number, 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:
SERVICEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:2062 Max-Forwards: 70From:<sip:[email protected]>;tag=7ae5f901b8;epid=aa6d968e18To:<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.contoso.com", response="602306092a864886f71201020201011100ffffffff2a567bb3a6d1ce598e39074 cf9e13419"Content-Type: application/msrtc-category-publish+xml Content-Length: 1392 <publishxmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence"> <publicationsuri="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> <publicationcategoryName="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> <publicationcategoryName="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.0200 OKAuthentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF7F95AF99B5AA4135D9873CEDF9F8C192", srand="9D59FA63", snum="7", opaque="A7AB18E7", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Content-Length: 7638 Via: SIP/2.0/TLS 192.168.3.100:2062;ms-received-port=2062;ms-received-cid="2700From:"Jeremy Los"<sip:[email protected]>;tag=7ae5f901b8;epid=aa6d968e18To:<sip:[email protected]>;tag=A1F542AB99D66616F9252CB6DF50257FCall-ID:d661a29ddb364c61ab1009edbe5e2b95 CSeq: 1 SERVICE Content-Type: application/vnd-microsoft-roaming-self+xml <roamingDataxmlns="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"> <categoriesxmlns="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> <category name="services" instance="0" publishTime="2007-05-04T22:48:10.357" container="2" version="1" expireType="user"> <services xmlns="http://schemas.microsoft.com/2006/09/sip/service"> <service uri="sip:[email protected]"> <capabilities> <text render="true" capture="true" publish="false" preferredEndpointId="6bf396ba-a7d6-5247-89fb-c13b52f5840d" deviceAvailability="3500" /> <gifInk render="true" capture="false" publish="false" preferredEndpointId="6bf396ba-a7d6-5247-89fb-c13b52f5840d" deviceAvailability="3500" /> <isfInk render="true" capture="false" publish="false" preferredEndpointId="6bf396ba-a7d6-5247-89fb-c13b52f5840d" deviceAvailability="3500" /> </capabilities> </service> </services> </category> <category name="state" instance="1" publishTime="2007-05-04T22:48:10.357" container="3" 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="817733007" publishTime="2007-05-04T22:48:10.357" container="3" 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="state" instance="1" publishTime="2007-05-04T22:48:10.357" container="100" 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="legacyInterop" instance="1" publishTime="2007-05-04T22:48:10.357" container="100" version="1" expireType="user"> <legacyInterop availability="3500" /> </category> <category name="services" instance="0" publishTime="2007-05-04T22:48:10.357" container="100" version="1" expireType="user"> <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> <category name="state" instance="1" publishTime="2007-05-04T22:48:10.357" container="200" 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="legacyInterop" instance="1" publishTime="2007-05-04T22:48:10.357" container="200" version="1" expireType="user"> <legacyInterop availability="3500" /> </category> <category name="services" instance="0" publishTime="2007-05-04T22:48:10.357" container="200" version="1" expireType="user"> <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> <category name="state" instance="1" publishTime="2007-05-04T22:48:10.357" container="300" 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="legacyInterop" instance="1" publishTime="2007-05-04T22:48:10.357" container="300" version="1" expireType="user"> <legacyInterop availability="3500" /> </category> <category name="services" instance="0" publishTime="2007-05-04T22:48:10.357" container="300" version="1" expireType="user"> <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> <category name="state" instance="1" publishTime="2007-05-04T22:48:10.357" container="400" 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="legacyInterop" instance="1" publishTime="2007-05-04T22:48:10.357" container="400" version="1" expireType="user"> <legacyInterop availability="3500" /> </category> <category name="services" instance="0" publishTime="2007-05-04T22:48:10.357" container="400" version="1" expireType="user"> <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></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 allows 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.