To explain how presence information is shared, in this section we first need to define and explain presence. Then we can explain usage examples that involve presence information as the user sees it, based on the steps taken and the feedback Communicator 2007 provides. Finally, the technical steps, decisions, and protocols that are going on in the background are explained to provide a rich experiential understanding that will aid in troubleshooting presence problems and setting presence authorization properly based on your needs.
Virtual communication systems must provide the same information that people typically have if they are sitting next to each other or working in the same office. Is the other person there, is she busy, and is she able to talk? Presence information attempts to capture and identify whether a remote user is willing to communicate and what means that user has to communicate. Office Communicator 2007 R2 and Office Communications Server 2007 R2 provide much more than these basics, however. Communicator enables publishing of location on a per-client basis (home, office, or custom location) and publishing of custom informational notes (which can be kept in sync with "out of office" e-mail auto-responses from Microsoft Office Outlook). It even ties this in with scheduling information to enable authorized partners to view calendar details. In this way, presence in Office Communications Server 2007 R2 is about the ability and willingness to communicate, but it also contains information about the partner that goes beyond communication with the partner.
This scenario walks Jeremy Los through using Office Communicator 2007 to gather presence information from Office Communications Server and control the level of access another person has to his presence information. Office Communications Server must have already been installed on the enterprise network, and Jeremy must have already installed Communicator on his workstation and have completed a successful login. The overview will show what Jeremy (and his remote contact, Vadim N. Korepin) sees from the Communicator user interface and what steps he and his remote contact take.
Jeremy clicks the contact search box at the top of the Communicator 2007 window and types the name of a local colleague he wants to contact, Vadim N. Korepin. Information on Vadim is retrieved and displayed. (See Figure 5-6.) Note that a contact card with information can be shown by clicking the small arrow that appears to the left of the presence icon when you hover over this area with the mouse. From this list, contacts can be called (using a phone or computer on either end, if support is provided) by clicking on the phone icon to the right of the contact name, or an instant message can be sent by simply double-clicking the name.
Because Jeremy works regularly with Vadim, he wants to make Vadim’s contact information readily available. He right-clicks the contact listing and selects Add To Contact List, which brings up a menu of contact groups he has set up. Jeremy selects All Contacts to add Vadim to the list of contacts that are readily available on the main Communicator window, as shown in Figure 5-7.
Jeremy looks in the main Communicator 2007 window and sees that Vadim is currently offline, as shown in Figure 5-8. Jeremy proceeds with other work while waiting for Vadim to become available.
Vadim logs in to his office workstation when he arrives at work. Vadim receives an alert telling him that Jeremy added him as a contact, as shown in Figure 5-9. Vadim decides to add Jeremy as a contact during authorization and clicks OK.
Meanwhile, Jeremy receives a notification from Communicator that Vadim has come online, as shown in Figure 5-10.
Jeremy has worked previously with Vadim and trusts him with more detailed contact information about himself. He wants to share details from his calendar with Vadim to make sure they stay in sync. Jeremy right-clicks Vadim’s contact listing and Change Level Of Access, and he switches it to Team, as shown in Figure 5-11. This change grants Vadim rights to see details about Jeremy’s schedule and availability.
This section provides technical background on what is happening with Communicator 2007 and the network of Office Communications Servers. Reviewing this section should aid you in understanding the product and thinking through troubleshooting presence-related scenarios later, if the need arises. Presence queries, presence notifications, contact lists, authorization, routing, and the SIP are covered as they relate to these presence scenarios. Figure 5-12 provides an overview of the steps involved in the presence sharing scenario that we will analyze.
When Communicator is asked to look up a contact, it leverages the contact list it synchronizes with Office Communications Server and the address book that it synchronizes from Office Outlook on the local machine or the address book that it downloads from the Address Book Server–publishing URL. The Address Book Server–publishing URL is handed to the client as a result of the subscription step for provisioning and configuration information during login. Step 3: What Happens When Subscribing for Presence and Receiving an Offline Notification from the section titled "The Technical Details Behind the Login Process" earlier in this chapter shows the Address Book Server–publishing URL received, as follows:
<absInternalServerUrl>http://srv.litwareinc.com/Abs/Int</absInternalServerUrl>
With these contact lists combined, Communicator simply indexes the list and is ready to quickly provide search results. As a user types in a contact name, the list is searched by e-mail address, SIP URI, and first/last name. If the name is not recognized and typing pauses, an entry is created (which might or might not be a valid contact at the moment). If an entry exists that is not already in Communicator’s list of subscriptions, there is no existing knowledge of the presence information for the new contact entry. This unknown entry results in a presence query in an attempt to determine if this account exists and, if it does, the contact’s presence status.
The presence query that would have been made in the example while looking up Vadim’s information is shown next. It involves making a SERVICE request with an XML body that issues a getPresence query, as follows:
SERVICE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70 From: <sip:[email protected]>;tag=81b8232d08;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: c31cb9c85d564f15b96a7faf253bd8f0 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="E8EA7EDD", crand="fccc07aa", cnum="8", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff7be3d5766e71b585c2b165da61edf9ee" Content-Type: application/SOAP+xml Content-Length: 261 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <m:getPresence xmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip"> <presentity uri="sip:[email protected]"/> </m:getPresence> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
The server could respond in several ways to this SERVICE request, as follows:
200 OK. In this case, the server network responds with whatever contact and presence information is available for the user. Most enterprises enable presence within the company automatically, but if you go outside of the corporate network to get presence for a remote contact, this is not always the case.
404 Not Found. In this case, the server network identifies that the contact does not exist (either locally, remotely, or because the domain could not be routed to).
504 Server Time-Out. In this case, a server (if the user is external, the Access Edge Server is most likely; if internal, the front-end server) was unable to forward the message, or a valid remote domain could not be found. This could be because of a network configuration problem, because of a network outage, or simply because of a mistyped domain name or because the domain does not exist currently.
For any failure cases, the ms-diagnostics header should have information about the failure to help you understand whether there is a problem with the URI specified by the user or whether the network has an unexpected issue.
In this example, the server sends a 200 OK response. The response shows that Vadim is offline and it also shares some of his contact information, as follows:
SIP/2.0 200 OK ... (header info) CSeq: 1 SERVICE Content-Type: application/SOAP+xml <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <m:getPresence xmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip"> <presentity uri="[email protected]" xmlns="http://schemas.microsoft.com/2002/09/sip/presence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > <availability aggregate="0" description="" /> <activity aggregate="0" description="" /> <displayName displayName="Vadim N. Korepin" /> </presentity> </m:getPresence> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
This response not only shows us that the user exists (because the response did not fail), but it provides information about the user’s availability (how he specified his presence state) and his activity (which is programmatically determined). Together, this activity information helps other clients understand whether an online client is really away even though the client indicates that he is "available." The availability aggregate and activity aggregate values present this information numerically: a 0 means that the user is unavailable and has no activity information. Additionally, e-mail, phone number, and calendar availability can be provided, but they were not offered in this initial response.
When Communicator is asked to add a contact, it has two things to do. First, it must update the contact list that is stored on the server. This ensures that other (presumably idle) logged-in clients for this user know to update their contact lists, and it also ensures that future client logins remember that this contact is added. The second thing Communicator must do is set up a subscription with that contact so that she can receive presence information and notifications of presence changes in the future. All subscription requests are time limited. Communicator does the bookkeeping to keep the subscription continually renewed before it expires each time.
An example of the SERVICE request to update the contact list follows.
SERVICE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70 From: <sip:[email protected]>;tag=adb5417230;epid=aa6d968e18 To: <sip:[email protected]>;tag=D1972B5B Call-ID: 46670f6cf7854110888a68bf9d4fef8c CSeq: 2 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="E8EA7EDD", crand="49aff62c", cnum="13", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff22e9b5b8a4d8711e7d02c5ffe0af30d7" Content-Type: application/SOAP+xml Content-Length: 483 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <m:setContact xmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip"> <m:displayName/> <m:groups>1 </m:groups> <m:subscribed>true</m:subscribed> <m:URI>[email protected]</m:URI> <contactExtension> <contactSettings contactId="db48d962-7878-44d6-a469-2f976b7aace3"/> </contactExtension> <m:externalURI></m:externalURI> <m:deltaNum>2</m:deltaNum> </m:setContact> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
The SERVICE request sends a SETCONTACT request (in XML) to the server to add the URI, [email protected], to the contact list. It also labels this contact with a contactId to reference it specifically in future change notifications. The server confirms the change with a 200 OK response, as follows:
SIP/2.0 200 OK ... (header info) CSeq: 2 SERVICE Content-Length: 0
Next, the server must notify all watchers for the contact list that the contact list has changed. Because Communicator subscribed to the user’s contact list during login, it receives a notification of the change that it just made, as follows:
BENOTIFY sip:192.168.3.100:1467;transport=tls; ms-opaque=7c11559fb8;ms-received-cid=00000A00 SIP/2.0 Via: SIP/2.0/TLS 192.168.3.1:5061;branch=z9hG4bK50F66FF8.FD5CCE8F;branched=FALSE Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF010DB5FD2506B119E77AEBF785DD1084", srand="D5844BEE", snum="18", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.litwareinc.com", realm="SIP Communications Service" Max-Forwards: 70 To: <sip:[email protected]>;tag=adb5417230;epid=aa6d968e18Content-Length: 305 From: <sip:[email protected]>;tag=D1972B5B Call-ID: 46670f6cf7854110888a68bf9d4fef8c CSeq: 3 BENOTIFY Content-Type: application/vnd-microsoft-roaming-contacts+xml Event: vnd-microsoft-roaming-contacts subscription-state: active;expires=48415 <contactDelta deltaNum="3" prevDeltaNum="2" > <addedContact uri="sip:[email protected]" name="" groups="1 " subscribed="true" externalURI="" > <contactExtension> <contactSettings contactId="db48d962-7878-44d6-a469-2f976b7aace3" > </contactSettings> </contactExtension> </addedContact> </contactDelta>
As an aside, this notification is only a change notification, which means that it shows only what has changed—not the whole contact list. This efficient means of notification avoids extra parsing and data passing on the network, but it can also run into problems when updates occur from multiple sources at the same time. To avoid this, the deltaNum and prevDeltaNum fields are used to denote which version of the document this notification was built from. When Communicator sent the original request to add a contact, it specified a deltaNum of 2, and this request is indicating that the latest update was built off of this change. If Communicator sent another update that is not processed yet, Communicator can still interpret this notification.
At this point, Communicator has successfully added the contact, has received confirmation of the change, and is ready to subscribe to the new contact.
A presence subscription is sent out to the contact of interest (Vadim), as follows:
SUBSCRIBE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70 From: <sip:[email protected]>;tag=944c2873c1;epid=aa6d968e18 To: <sip:[email protected]>Call-ID: 85b56acd9b374c70baa50bf89a09b867 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 Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="E8EA7EDD", crand="dc7167ba", cnum="15", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff6f653032d2c6d18a6b15cf4edf3dfc33" Content-Type: application/msrtc-adrl-categorylist+xml Content-Length: 519 <batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe" uri="sip:[email protected]" name=""> <action name="subscribe" id="1170624"> <adhocList> <resource uri="sip:[email protected]"> <context></context> </resource> </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>
This request uses the XML body to query for presence information. It is asking for all the presence information on [email protected] that is available—calendaring information, contact card information, notes, services available, network location (enterprise network, federated network, and so on), and current presence state. The remote contact’s home server responds to the request (based on presence authorization).
For our example, the server responds with a 200 OK response containing presence details, as follows:
SIP/2.0 200 OK Contact: <sip:srv.litwareinc.com:5061;transport=tls> ... (header info) CSeq: 1 SUBSCRIBE Expires: 30384 Content-Type: text/xml+msrtc.pidf Event: presence subscription-state: active;expires=30384 ms-piggyback-cseq: 1 Supported: ms-benotify, ms-piggyback-first-notify <presentity uri="[email protected]" xmlns="http://schemas.microsoft.com/2002/09/sip/presence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > <availability aggregate="0" description="" /> <activity aggregate="0" description="" /> <displayName displayName="Vadim N. Korepin" /> </presentity>
This response from the remote contact’s home server tells us only that the contact is offline. An availability and activity aggregate of 0 means that the contact is unreachable. Because Vadim has not authorized Jeremy Los to see presence information, minimal information is shared. (This information is ambiguous; it could be because Jeremy is actually denied access or because Vadim has not authorized him yet.)
When Vadim logs in, he receives a notification from the server that Jeremy is waiting for presence authorization, because his list of pending watchers includes Jeremy. This was shown in the section titled "Step 3: What Happens During Login Processing" within the section titled "The Technical Details Behind the Login Process" earlier in this chapter. In Vadim’s case, the list the server sends is not empty and instead contacts Jeremy’s URI, as follows:
SIP/2.0 200 OK... From: "Vadim N. Korepin"<sip:[email protected]>;tag=e32b927182;epid=6fe87e039b To: <sip:[email protected]>;tag=6C3D0080 Call-ID: 5bf9529db3b14cc08a3bdeeb166f0615 CSeq: 1 SUBSCRIBE Expires: 47303... Event: vnd-microsoft-roaming-self... ... <subscribers xmlns="http://schemas.microsoft.com/2006/09/sip/presence-subscribers"> <subscriber user="[email protected]" displayName="Jeremy Los" acknowledged="false" type="sameEnterprise"/></subscribers>...
When Vadim allows Jeremy to see his presence information (and asks to add him as a contact as well), a SERVICE request is sent to the server to acknowledge Jeremy as a subscriber and to change the authorization list. Vadim’s clients are all notified that the authorization list changed (to alert inactive clients that might still be logged in).
SERVICE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.101:1073 Max-Forwards: 70 From: <sip:[email protected]>;tag=6e3dba1e93;epid=6fe87e039b To: <sip:[email protected]> Call-ID: 0ea64766096741cd92dd4296d3703988 CSeq: 1 SERVICE Contact: <sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;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="8FFADC36", crand="d723fdf4", cnum="12", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff8819cae15eaa9fd62e5730ad9d757ebf" Content-Type: application/msrtc-presence-setsubscriber+xml Content-Length: 164 <setSubscribers xmlns= "http://schemas.microsoft.com/2006/09/sip/presence-subscribers"> <subscriber user="[email protected]" acknowledged="true"/> </setSubscribers>
The request is accepted by Vadim’s home server, as follows:
SIP/2.0 200 OK ... (header info) CSeq: 1 SERVICE Content-Length: 0
The server sends notification that the list changed and indicates that there was a contact-Delta event because of an addedContact event for [email protected], who is now being subscribed to, as follows:
BENOTIFY sip:192.168.3.101:1073;transport=tls; ms-opaque=3f6ee3c2ab;ms-received-cid=00000C00 SIP/2.0 Via: SIP/2.0/TLS 192.168.3.1:5061;branch=z9hG4bK3038528D.91797EAB;branched=FALSE Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF0E7982BDD363E7034027E38D915280AC", srand="ACCB75D8", snum="17", opaque="8FFADC36", qop="auth", targetname="sip/srv.litwareinc.com", realm="SIP Communications Service" Max-Forwards: 70 To: <sip:[email protected]>;tag=f64cbe4fb6;epid=6fe87e039b Content-Length: 165 From: <sip:[email protected]>;tag=BE9E675E Call-ID: c1737cc0857a4be4b6fb40aead466060 CSeq: 3 BENOTIFY Content-Type: application/vnd-microsoft-roaming-contacts+xml Event: vnd-microsoft-roaming-contacts subscription-state: active;expires=32134 <contactDelta deltaNum="3" prevDeltaNum="2" > <addedContact uri="sip:[email protected]" name="" groups="1 " subscribed="true" externalURI="" /> </contactDelta>
After authorization is allowed, a more complete view of Vadim’s presence is sent to Jeremy through BENOTIFY messages. For brevity, only the content of the message is shown, simply to highlight the availability and capability information that was made available, as follows:
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"> <category xmlns="http://schemas.microsoft.com/2006/09/sip/categories" name="contactCard" instance="0" publishTime="2007-05-03T05:37:43.113"> <contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard" > <identity > <name ><displayName >Vadim N. Korepin</displayName></name> </identity> </contactCard> </category> <category xmlns="http://schemas.microsoft.com/2006/09/sip/categories" name="state" instance="1" publishTime="2007-05-04T19:30:25.930"> <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 xmlns="http://schemas.microsoft.com/2006/09/sip/categories" name="services" instance="0" publishTime="2007-05-04T19:30:25.930"> <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>
The presence information shown here is still simplistic, because it does not integrate with Outlook for calendar details, nor has any Note field been set. The device availability is presented as a numeric value that Communicator calculates and interprets to present a textual or graphical indication of a user’s presence.
When the level of access is changed for a given contact, a SERVICE request is sent to tell the server to change the authorization container in which the contact is maintained. These containers receive varying levels of detail about presence changes, and all contacts in each container are given the details available for their authorization level. The response and subsequent notification from the server identifying that the list changed are left out here for brevity’s sake. These are available on the companion media for reference, but an example of the SERVICE request follows.
SERVICE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70 From: <sip:[email protected]>;tag=0b8629457f;epid=aa6d968e18 To: <sip:[email protected]> Call-ID: 045284d5f9d7439c8df7fb629be00dca 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="E8EA7EDD", crand="f4595ce8", cnum="18", targetname="sip/srv.litwareinc.com", response= "602306092a864886f71201020201011100ffffffff2a3751d364162d072028848f060005a5" Content-Type: application/msrtc-setcontainermembers+xml Content-Length: 219 <setContainerMembers xmlns= "http://schemas.microsoft.com/2006/09/sip/container-management"> <container id="300" version="0"> <member action="add" type="user" value="[email protected]"/> </container> </setContainerMembers>
Various access levels are defined by the containers. Each container has a predefined level of access to presence information, and contacts can simply be added to or removed from these containers to easily manage the level of information a contact receives. Containers increase complexity for the protocol messages and make it more difficult to understand what the system is doing. However, they simplify managing and authorizing contacts, eliminating authorization as a customization step for each contact.
All the presence information is maintained through subscriptions, which send updates when things change and eventually expire over time if they are not regularly renewed. (Communicator handles this automatically for the user.) The next section shows examples for instant messaging scenarios and talks about the technical details involved.