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.
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.
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.
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.
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.
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.
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.
Meanwhile, Jeremy receives a notification from Communicator that Vadim has come online, as shown in Figure 4-11.
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.
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:
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:
SERVICEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=81b8232d08;epid=aa6d968e18To:<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:getPresencexmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip"> <presentityuri="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.0200 OKAuthentication-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=A00From:"Jeremy Los"<sip:[email protected]>;tag=81b8232d08;epid=aa6d968e18To:<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:getPresencexmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip"> <presentityuri="[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="" /> <displayNamedisplayName="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.
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:
SERVICEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=adb5417230;epid=aa6d968e18To:<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:setContactxmlns: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), [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.0200 OKAuthentication-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="A00From:"Jeremy Los"<sip:[email protected]>;tag=adb5417230;epid=aa6d968e18To:<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:
BENOTIFYsip: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: 70To:<sip:[email protected]>;tag=adb5417230;epid=aa6d968e18Content-Length: 305From:<sip:[email protected]>;tag=D1972B5B Call-ID: 46670f6cf7854110888a68bf9d4fef8c CSeq: 3 BENOTIFY Content-Type: application/vnd-microsoft-roaming-contacts+xmlEvent:vnd-microsoft-roaming-contactssubscription-state:active;expires=48415 <contactDeltadeltaNum="3" prevDeltaNum="2" > <addedContacturi="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.
A presence subscription is sent out to the contact of interest (Vadim), as follows:
SUBSCRIBEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=944c2873c1;epid=aa6d968e18To:<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 <batchSubxmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe" uri="sip:[email protected]" name=""> <actionname="subscribe" id="1170624"> <adhocList> <resourceuri="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).
Examining What Happens During Presence Authorization For our example, the server responds with a 200 OK response containing presence details, as follows:
SIP/2.0200 OKContact: <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="A00From:"Jeremy Los"<sip:[email protected]>;tag=944c2873c1;epid=aa6d968e18To:<sip:[email protected]>;tag=A4F5416B Call-ID: 85b56acd9b374c70baa50bf89a09b867 CSeq: 1 SUBSCRIBEExpires:30384 Content-Type: text/xml+msrtc.pidfEvent:presencesubscription-state:active;expires=30384 ms-piggyback-cseq: 1 Supported: ms-benotify, ms-piggyback-first-notify <presentityuri="[email protected]" xmlns="http://schemas.microsoft.com/2002/09/sip/presence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > <availabilityaggregate="0" description="" /> <activityaggregate="0" description="" /> <displayNamedisplayName="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.)
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.0200 OK...From:"Vadim N. Korepin"<sip:[email protected]>;tag=e32b927182;epid=6fe87e039bTo:<sip:[email protected]>;tag=6C3D0080 Call-ID: 5bf9529db3b14cc08a3bdeeb166f0615 CSeq: 1 SUBSCRIBEExpires:47303... Event: vnd-microsoft-roaming-self... ... <subscribersxmlns="http://schemas.microsoft.com/2006/09/sip/presence-subscribers"> <subscriberuser="[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).
SERVICEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.101:1073 Max-Forwards: 70From:<sip:[email protected]>;tag=6e3dba1e93;epid=6fe87e039bTo:<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 <setSubscribersxmlns= "http://schemas.microsoft.com/2006/09/sip/presence-subscribers"> <subscriberuser="[email protected]" acknowledged="true"/> </setSubscribers>
The request is accepted by Vadim's home server, as follows:
SIP/2.0200 OKAuthentication-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=C00From:"Vadim N. Korepin"<sip:[email protected]>;tag=6e3dba1e93;epid=6fe87e039bTo:<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 [email protected], who is now being subscribed to, as follows:
BENOTIFYsip: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: 70To:<sip:[email protected]>;tag=f64cbe4fb6;epid=6fe87e039b Content-Length: 165From:<sip:[email protected]>;tag=BE9E675E Call-ID: c1737cc0857a4be4b6fb40aead466060 CSeq: 3 BENOTIFY Content-Type: application/vnd-microsoft-roaming-contacts+xmlEvent:vnd-microsoft-roaming-contactssubscription-state:active;expires=32134 <contactDeltadeltaNum="3" prevDeltaNum="2" > <addedContacturi="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:
<categoriesxmlns="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"> <contactCardxmlns="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"> <statexsi: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.
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:
SERVICEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=0b8629457f;epid=aa6d968e18To:<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 <setContainerMembersxmlns= "http://schemas.microsoft.com/2006/09/sip/container-management"> <containerid="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.