Understanding How Presence Information Is Shared

To explain how presence information is shared, presence is first defined and explained. Usage examples are explained 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.

What Is Presence?

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. Communicator 2007 and Office Communications Server provide much more than these basics, however. Communicator allows 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 allow authorized partners to view calendar details. In this way, presence in Office Communications Server is about the ability and willingness to communicate, but it also contains information about the partner that goes beyond communication with the partner.

Overview of the Presence Sharing Scenario

This scenario walks Jeremy Los through using 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 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.

Step 1: Looking Up a Contact

Jeremy clicks in the contact search box at the top of the Communicator 2007 window and types in the name of a local colleague he wants to contact, Vadim N. Korepin. Information on Vadim is retrieved and displayed. (See Figure 4-7.) 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.

Communicator 2007—Contact lookup and contact card

Figure 4-7. Communicator 2007—Contact lookup and contact card

Step 2: Adding a Contact

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 4-8.

Communicator 2007—Adding a contact

Figure 4-8. Communicator 2007—Adding a contact

Step 3: Receiving an Offline Indication

Jeremy looks on the main Communicator 2007 window and sees that Vadim is currently offline, as shown in Figure 4-9. Jeremy proceeds with other work while waiting for Vadim to become available.

Communicator 2007—Contact offline

Figure 4-9. Communicator 2007—Contact offline

Step 4: Logging In the Contact and Receiving Updated Presence Information

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 4-10. Vadim decides to add Jeremy as a contact during authorization, and clicks OK.

Communicator 2007—Added to contact list

Figure 4-10. Communicator 2007—Added to contact list

Meanwhile, Jeremy receives a notification from Communicator that Vadim has come online, as shown in Figure 4-11.

Communicator 2007—Presence update

Figure 4-11. Communicator 2007—Presence update

Step 5: Controlling the Access Level of a Contact

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 on Vadim's contact listing and Change Level Of Access, and he switches it to Team, as shown in Figure 4-12. This change grants Vadim rights to see details about Jeremy's schedule and availability.

Communicator 2007 Control access level

Figure 4-12. Communicator 2007 Control access level

Examining the Technical Details Behind the Presence Sharing Scenario

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 Session Initiation Protocol (SIP) are covered as they relate to these presence scenarios. The following diagram provides an overview of the steps involved in the presence sharing scenario that we will analyze:

Examining the Technical Details Behind the Presence Sharing Scenario

Examining What Happens During Looking Up a Contact (Step 1)

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 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 from the Examining the Technical Details Behind the Login Process section earlier in the chapter shows the Address Book Server publishing URL received, as follows:

<absInternalServerUrl>http://srv.contoso.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.contoso.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 did not exist (either locally, remotely, or because the domain could not be routed to).

  • 504 Server Time-Out In this case, a server (probably the Access Edge 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, a network outage, or simply because the domain has a typo or 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 there is an unexpected issue with the network.

In the example, the server sends a 200 OK response showing Vadim to be offline but sharing some of his contact information, as follows:

SIP/2.0 200 OK
Authentication-Info: Kerberos rspauth=
"602306092A864886F71201020201011100FFFFFFFF46E1CA29B5AB2E8D38D0560422E9CC23",
srand="CBB0F6C9", snum="12", opaque="E8EA7EDD", qop="auth",
targetname="sip/srv.contoso.com", realm="SIP Communications Service"
Content-Length: 537
Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid=A00
From: "Jeremy Los"<sip:[email protected]>;tag=81b8232d08;epid=aa6d968e18
To: <sip:[email protected]>;tag=A1F542AB99D66616F9252CB6DF50257F
Call-ID: c31cb9c85d564f15b96a7faf253bd8f0
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 user indicated that she is "available." The availability aggregate and activity aggregate values present this information numerically, and 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.

Examining What Happens When Adding a Contact (Step 2)

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.contoso.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 in order to add the Uniform Resource Identifier (URI), , 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
Authentication-Info: Kerberos rspauth=
"602306092A864886F71201020201011100FFFFFFFF7FD058163D53A47D7C264267B9B0BFA8",
srand="563A1C58", snum="17", opaque="E8EA7EDD", qop="auth",
targetname="sip/srv.contoso.com", realm="SIP Communications Service"
Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid="A00
From: "Jeremy Los"<sip:[email protected]>;tag=adb5417230;epid=aa6d968e18
To: <sip:[email protected]>;tag=D1972B5B
Call-ID: 46670f6cf7854110888a68bf9d4fef8c
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.contoso.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, received confirmation of the change, and is ready to subscribe to the new contact.

Examining What Happens When Subscribing for Presence and Receiving an Offline Notification (Step 3)

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.contoso.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 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).

Examining What Happens During 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.contoso.com:5061;transport=tls>
Authentication-Info: Kerberos rspauth=
"602306092A864886F71201020201011100FFFFFFFF355750633369457F8A07BF7FDEA9B9F3",
srand="A6BCBB5B", snum="20", opaque="E8EA7EDD", qop="auth",
targetname="sip/srv.contoso.com", realm="SIP Communications Service"
Content-Length: 307
Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid="A00
From: "Jeremy Los"<sip:[email protected]>;tag=944c2873c1;epid=aa6d968e18
To: <sip:[email protected]>;tag=A4F5416B
Call-ID: 85b56acd9b374c70baa50bf89a09b867
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, very 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.)

Examining What Happens When the Contact Logs In and Updated Presence Is Received (Step 4)

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 Examining What Happens During Login Processing (Step 3) within the Examining the Technical Details Behind the Login Process section 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.contoso.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
Authentication-Info: Kerberos rspauth=
"602306092A864886F71201020201011100FFFFFFFFC99CE686EDBB3A2B07A9D09CF0F1A936",
srand="17DFA698", snum="18", opaque="8FFADC36", qop="auth",
targetname="sip/srv.contoso.com", realm="SIP Communications Service"
Via: SIP/2.0/TLS 192.168.3.101:1073;ms-received-port=1073;ms-received-cid=C00
From: "Vadim N. Korepin"<sip:[email protected]>;tag=6e3dba1e93;epid=6fe87e039b
To: <sip:[email protected]>;tag=A1F542AB99D66616F9252CB6DF50257F
Call-ID: 0ea64766096741cd92dd4296d3703988
CSeq: 1 SERVICE
Content-Length: 0

The server sends notification that the list changed and indicates that there was a contactDelta because of an addedContact event for , 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.contoso.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, as 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.

Note

On the CD These protocol messages are part of the complete set of protocol messages on the companion CD for this chapter, in the Appendixes,Scripts,ResourcesChapter 04CD Protocol Logs folder, and you can view them in their entirety there.

Examining What Happens When Controlling the Access Level of a Contact (Step 5)

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 CD 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.contoso.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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.239.235