download.microsoft.comdownload.microsoft.com/.../Chapter_10_Instant_Messagi… · Web viewIn her...

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Copyright © 2011 Microsoft Corporation. All rights reserved.

Microsoft, Lync, and Windows PowerShell are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

Microsoft Lync Server 2010 Resource Kit Instant Messaging Page 2

This chapter is part of the Microsoft® Lync™ Server 2010 Resource Kit book that is currently being developed. Chapters will be available for download while this book is being completed. To help us improve it, we need your feedback. You can contact us at [email protected]. Please include the chapter name.

For information about the continuing release of chapters, check the DrRez blog at http://go.microsoft.com/fwlink/?LinkId=204593.


Contributors

Project Manager: Susan S. BradleyContent Architect: Rui MaximoChapter Lead: Jared GradleContributing Writer: Rick KingslanTechnical Reviewers: Brian R. Ricks, Conal Walsh, Joe Schaeffer, Moustafa NoureddineLead Editor: Alexandra LiseArt Manager: Jim BradleyProduction Editor: Kelly Fuller Blue


Table of Contents

Contributors................................................................................................................................................4

Introduction.................................................................................................................................................6

IM Scenarios................................................................................................................................................6

Basic IM Conversation (Including Discovery, Logon, the Contacts List, and Provisioning).......................6

Program Sharing and File Transfer During an IM Conversation...............................................................6

Turning an IM Conversation into an IM Conference (Adding a Third Person).........................................7

IM Internals.................................................................................................................................................7

Enabling Lync 2010 Client Logging...........................................................................................................7

Lync Server Discovery Process.................................................................................................................9

User Logon.............................................................................................................................................10

Initial Contacts List.................................................................................................................................15

Client Provisioning.................................................................................................................................16

Basic IM Conversation...........................................................................................................................20

Program Sharing and File Transfer During an IM Conversation.............................................................24

Turning an IM Conversation into an IM Conference..............................................................................29

Summary...................................................................................................................................................30

Additional Resources.................................................................................................................................30


IntroductionThe foundation of Microsoft Lync Server 2010 communications software is the Session Initiation Protocol (SIP). The SIP implementation is based an Internet Engineering Task Force (IETF) standard: Request for Comments (RFC) 3261. It is used for signaling and messaging. Signaling serves to locate a target endpoint and to establish, maintain, and terminate communication sessions. Messaging involves the exchange of text messages as payloads in SIP messages and is used for conducting text-based conversations, also known as instant messaging (IM), and for relaying presence information between two communication partners.

This chapter describes how SIP is used for IM in a Lync Server 2010 deployment. It begins by describing collaboration scenarios that use IM and then goes into detail about the internal processes that support these scenarios.

Note. For details about how SIP is used for presence, see the Enhanced Presence chapter at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=22644.

IM ScenariosBob and Alice communicate frequently. Bob is a project manager for Contoso, Ltd, and Alice is one of his employees. Carol is a system administrator who frequently works with Bob and Alice on projects. Carol also manages the Lync Server infrastructure at Contoso, Ltd.

Basic IM Conversation (Including Discovery, Logon, the Contacts List, and Provisioning)Bob starts his client, Microsoft® Lync™ 2010, which logs him on to the Lync Server at Contoso, Ltd. His presence information for contacts shows that Alice is online. Bob double-clicks Alice’s name in his Contacts list and chooses to start an IM conversation with her. Alice responds to Bob’s instant message, and she and Bob discuss details about their current project. They finish their conversation and close their Conversation windows.

Program Sharing and File Transfer During an IM ConversationAlice is logged onto Lync 2010. She needs to discuss details about a project with Carol. Alice notes that Carol is online and available. She double-clicks Carol’s name on her Contacts list, types her questions to Carol, and Carol responds. Then Alice tells Carol that she needs her advice on a project document. In her Conversation window, Alice clicks the Share menu, clicks Program, and then clicks the Microsoft Word document that is open on her computer. Carol is able to see the document in her client. Alice and Carol exchange instant messages about the document, and Carol asks Alice to send a copy to her so that she can review it in detail. Alice sends the file to Carol by clicking the Send a File button in the upper-right corner of her Conversation window. Carol also asks Alice to send an executable file, but Alice’s attempt to send it is rejected because the administrative policy for IM filtering forbids sending .exe files. Alice compresses the file into a .ZIP file and this time is able to send it. Carol receives the file, thanks Alice, and ends the conversation.


Turning an IM Conversation into an IM Conference (Adding a Third Person)Bob is logged on and sees that Alice is also online. Alice’s presence indicator shows that she is available. Bob double-clicks her name in his Contacts list and starts a conversation with her about the project that he is leading. Alice is performing one part of the project, and Carol is performing another part. Alice asks Bob if it’s OK to invite Carol to join the conversation. Bob agrees, and, in her Conversation window, Alice clicks the People Options menu in the upper-right corner. She clicks Invite by Name or Phone Number and types Carol’s name. Carol is added to the conversation. (Note that instead Alice could have opened the Lync main window and dragged Carol’s name from her Contacts list into the Conversation window.) Bob, Alice, and Carol exchange instant messages about the current project and then end their conversation.

IM InternalsUnderstanding how IM works in Lync Server deployments amounts to understanding how the client software signs in, subscribes to the users’ Contacts lists, receives server configurations and policy settings, and starts IM sessions. In this section, we use the scenarios described in the previous section to illustrate the internal workings of IM in Lync Server. To facilitate the discussion, we use trace files that Lync Server and Lync 2010 log and begin by explaining how to enable client logging.

Enabling Lync 2010 Client Logging To capture and view the logon process, it’s necessary to use tools that are well suited to capturing and viewing the communication between the server and clients. For this chapter, we used OCSLogger to capture all the trace files of client and server communication and Snooper.exe to examine them. OCSLogger captures message information in a trace file format, and Snooper is a Lync Server Resource Kit tool that parses and presents this data in an easily consumable fashion.

To capture packet trace files at the network level, we used Microsoft Network Monitor 3.4. Microsoft Network Monitor allows you to view details at the network packet layer, such as the Domain Name System (DNS) calls that the client uses to locate the servers and other clients.

If you are capturing trace files on a busy network or server, it is extremely helpful to use the SIP Uniform Resource Identifier (URI) filter in OCSLogger to reduce the amount of traffic that is collected. If you are capturing network traffic by using Network Monitor, you can also use capture and display filters to reduce the amount of traffic that you capture or display to only the traffic that is interesting in relation to what you are looking for.

Note. Logging performed by OCSLogger is on the server. OCSLogger is found on the Start menu of any Lync Server. To start Snooper, select Analyze after collecting a log trace. For details about these tools, see the troubleshooting chapters at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=22644.

For details about and to download Network Monitor, see Microsoft Network Monitor 3.4 at http://www.microsoft.com/download/en/details.aspx?id=4865.

To capture trace files with OCSLogger, you must first enable client logging by doing the following:

1. Open Lync 2010.2. In the upper-right corner of the Lync main window, click the Show Menu arrow, click

File, and then click Options.


Figure 1. Accessing Lync 2010 Options

3. In the Lync - Options dialog box, click General.4. Under Logging, select the Turn on logging in Lync check box.

Figure 2. Setting logging options

5. (Optional) Select the Turn on Windows Event Logging for Lync check box.6. Use Snooper.exe to view these logs.


Figure 3. Opening files from Snooper

Lync Server Discovery ProcessBefore Lync 2010 can log on to Lync Server, the client needs to locate the user’s Lync Server. When the client is set to use automatic configuration, it uses the domain portion of the SIP URI provided by the user to discover which Lync Server it should sign in to. This discovery process involves querying DNS SRV records. The client attempts to resolve the following SRV records in the following order:

1. _sipinternaltls._tcp.<sip domain>.com (5061)2. _sipinternal._tcp.<sip domain>.com (5060)3. _sip._tls.<sip domain>.com (443)4. _sip._tcp.<sip domain>.com (5060)

If the client fails to resolve the preceding SRV records, it queries the following A records in the following order:

5. sipinternal.<sip domain>.com (5061 and 443)6. sip.<sip domain>.com (5061 and 443)7. sipexternal.<sip domain>.com (5061 and 443)Note. For internal communication, Transport Layer Security (TLS) defaults to port 5061, and Transmission Control Protocol (TCP) defaults to port 5060. External TCP communication defaults to port 443.

After an SRV or A record query resolves and a fully qualified domain name (FQDN) is returned, the client will not process any more DNS records. At this point, the client queries DNS again for the A record of the returned FQDN. This A record resolves the FQDN to an IP address. Then, Lync 2010 connects to the Lync Server, and the authentication process begins.


User Logon When the client locates a Lync Server, it signs-in the user, and the authentication process begins. The following figures details at a high level the call flows that takes place. In the rest of this section, we will dive deeper into this process.


Figure 4. Lync Server call flow


In the following SIP message, Bob’s client initiates a TLS connection to establish an encrypted channel between the client (192.168.0.51) and the server running Microsoft Lync Server 2010, Front End Server (192.168.0.3).LogType: connection Severity: informationText: TLS negotiation startedLocal-IP: 192.168.0.3:5061Peer-IP: 192.168.0.51:51344Connection-ID: 0x4F900Transport: TLSBob’s client sends a REGISTER request and indicates the SIP methods it supports. Methods represent functions that a client can request on the server.

Note. In the trace files throughout this chapter, sections of the SIP message that provide no value in helping you understand the messaging and how the client or server responds are removed and replaced with an ellipsis (…).

Direction: IncomingPeer: 192.168.0.51:51344Message-Type: requestStart-Line: REGISTER sip:contoso.com SIP/2.0From: <sip:[email protected]>;tag=97152a1f83;epid=f4bced5b3aTo: <sip:[email protected]>CSeq: 1 REGISTERCall-ID: 1b7168b487f5445c97d3674dc0d4c2ac…Contact: <sip:192.168.0.51:51344;transport=tls;ms-opaque=f6005201e2>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:E0233F84-0D8B-5465-8381-252C60B5B65C>"User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)…Event: registrationContent-Length: 0Message-Body: –

Note. Messages that show “incoming” in the Direction header are messages inbound to the server, while messages that show “outgoing” are outbound to the target. In our scenario, the target for outgoing messages are Bob and Alice’s clients.

Note. The From header is set to Bob’s SIP URI and includes a tag (that is chosen by the client and that identifies the SIP dialog) and the endpoint identifier, or epid. The epid is a unique alphanumeric string that the Registrar assigns to a client. The epid, combined with the client’s address of record (SIP URI), provides unique identification in cross-domain and federated scenarios, when addressing calls to a specific SIP endpoint. For details about the epid and its uses, see “[MS-SIPREGE]: Session Initiation Protocol (SIP) Registration Extensions” at http://msdn.microsoft.com/en-us/library/cc431491(v=office.12).aspx.

Because the client does not indicate the authentication type, the server responds with a 401 Unauthorized message that lists the authentication methods that the server accepts and the version number of the server (Lync Server is version 4). The following authentication methods are accepted:

WWW-Authenticate: Kerberos Used for domain members. This method uses the domain controller’s Key Distribution Center (KDC) for Kerberos tickets.


WWW-Authenticate: NTLM Used for domain members, typically when a client cannot connect to a domain controller. This method is commonly used with externally connected clients.WWW-Authenticate: TLS-DSK (Transport Layer Security – Derived Shared Key) Used as the default authentication protocol for Lync Server clients. This method can be used internally or when connecting externally. It uses a mechanism to mathematically deduce a session key to be used by the client and server without actually passing the shared key. TLS-DSK utilizes a client certificate that is issued by the user’s pool. The certificate that the client uses is a self-signed certificate that the Lync Server certificate provisioning service issues.Direction: outgoing;source="local"Peer: 192.168.0.51:51344Message-Type: responseStart-Line: SIP/2.0 401 UnauthorizedFrom: <sip:[email protected]>;tag=97152a1f83;epid=f4bced5b3aTo: <sip:[email protected]>;tag=B69C844CB75A152A278AE2F0D9791097CSeq: 1 REGISTERCall-ID: 1b7168b487f5445c97d3674dc0d4c2acDate: Mon, 17 May 2010 14:09:40 GMTWWW-Authenticate: NTLM realm="SIP Communications Service", targetname="LabPool.contoso.com", version=4WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/Lab-Pool.contoso.com", version=4WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="Lab-Pool.contoso.com", version=4, sts-uri="https://int cspool.contoso.com:443/CertProv/CertProvisioningService.svc"Via: SIP/2.0/TLS 192.168.0.51:51344;ms-received-port=51344;ms-received-cid=4F900Content-Length: 0Message-Body: –The client responds with another REGISTER request, incrementing the CSeq (sequence) header to 2, which means that this is the second REGISTER request the client has sent in this sequence. The REGISTER request contains a Proxy-Authorization header that specifies the authentication method. In this example, Kerberos is the authentication protocol that the client specifies. The authentication data is encoded by using base-64 encoding and provided in the gssapi-data attribute. (The actual content of the gssapi-data attribute has been stripped for brevity.)Direction: incomingPeer: 192.168.0.51:51344Message-Type: requestStart-Line: REGISTER sip:contoso.com SIP/2.0From: <sip:[email protected]>;tag=97152a1f83;epid=f4bced5b3aTo: <sip:[email protected]>CSeq: 2 REGISTERCall-ID: 1b7168b487f5445c97d3674dc0d4c2ac…Contact: <sip:192.168.0.51:51344;transport=tls;ms-opaque=f6005201e2>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:E0233F84-0D8B-5465-8381-252C60B5B65C>"User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)…


Event: registrationms-subnet: 192.168.0.0Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", targetname="sip/Lab-Pool.contoso.com", version=4, gssapi-data="…", crand="3f00eea3", cnum="1", response="040400ffffffffff0000000000000000858957d8cf09fd1a4754d919"Content-Length: 0Message-Body: –The server responds with a 200 OK message after successfully authenticating the user. Of important note are the Proxy-Authorization method and the following Proxy Authorization attributes:

Proxy-Authorization: Carries the signature of the SIP message and a unique token for the security association (SA).realm: Identifies which set of credentials and which SA were used to sign the message. version: Indicates the version of the authentication protocol used.gssapi-data: Contains the credential information used to establish the SA.crand: Identifies which SALT (an additional random quantity used to increase the strength of encryption) is used in the signature. cnum: Identifies the sequence number and is maintained on a per-SA basis and used to keep track of what data has been sent. This value is incremented each time data is exchanged with the server. Note that in the following message, the client has been assigned a Globally Routable User Agent URI (GRUU) (see the gruu attribute), which means that the user has successfully registered and subscribed to self-presence. The GRUU uniquely identifies this specific endpoint. The epid attribute used earlier to uniquely identify the client is now a part of the GRUU and the epid, and the SIP URI is no longer used after the GRUU is assigned. Direction: outgoing;source="local"Peer: 192.168.0.51:51344Message-Type: responseStart-Line: SIP/2.0 200 OKFrom: "Bob"<sip:[email protected]>;tag=97152a1f83;epid=f4bced5b3aTo: <sip:[email protected]>;tag=B69C844CB75A152A278AE2F0D9791097CSeq: 2 REGISTERCall-ID: 1b7168b487f5445c97d3674dc0d4c2ac…Proxy-Authentication-Info: Kerberos qop="auth", opaque="2DB9A9B6", srand="81029DF3", snum="1", rspauth="040401ffffffffff00000000000000002fc046ceea2c17edfc39fdcc", targetname="sip/Lab-Pool.contoso.com", realm="SIP Communications Service", version=4…Contact: <sip:192.168.0.51:51344;transport=tls;ms-opaque=f6005201e2;ms-received-cid=4F900>;expires=7200;+sip.instance="<urn:uuid:e0233f84-0d8b-5465-8381-252c60b5b65c>";gruu="sip:[email protected];opaque=user:epid:hD8j4IsNZVSDgSUsYLW2XAAA;gruu"presence-state: register-action="added";primary-cluster-type="central";is-connected-to-primary="yes"Expires: 7200


Allow-Events: vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,vnd-microsoft-roaming-ACL,presence,presence.wpending,vnd-microsoft-roaming-self,vnd-microsoft-provisioning-v2Supported: adhoclistServer: RTC/4.0…Content-Length: 0Message-Body: –The presence-state and Allow-Events headers specify the features advertised by the server, such as presence and other rich features. The following section provides a detailed example about processing the vnd-microsoft-roaming-contacts event.

Initial Contacts ListImmediately after a successful logon, Lync 2010 requests Bob’s pinned contacts, by doing the following:

1. Bob’s client sends a SUBSCRIBE request. 2. The Event header is set to vnd-microsoft-roaming-contacts; this header identifies a

roaming Contacts list. 3. The Accept header is set to application/vnd-microsoft-roaming-contacts+xml.4. The server responds with a Content Type application/vnd-microsoft-roaming-

contacts+xml and an Event message vnd-microsoft-roaming-contacts.5. The server populates the Message-Body with Bob’s Contacts list by using the XML

format described in application/vnd-microsoft-roaming-contacts+xml.6. The server sets the Expires header to 26,639 seconds.7. The server sets the subscription state to active;expires=26639, indicating that the

subscription is active and will expire in 26,639 seconds unless refreshed and re-subscribed to.

Note. Expirations and stale data are a usual part of establishing contact information. Contact information, like all information in the system, is subject to becoming stale. Setting an expires timer helps to ensure that stale data persists no longer than the maximum time that the timer is set for. If a refresh and reset of the timer has not occurred before the timer reaches zero, a refresh of the information will occur, and a new expires timer will be set. The timer does not reach zero often because the information and events that the client subscribes to are typically active with new registrations that update the state, causing the data to refresh and the timer to reset before it reaches zero.

The following SUBSCRIBE request illustrates Step 1.Direction: incomingPeer: 192.168.0.51:52848Message-Type: requestStart-Line: SUBSCRIBE sip:[email protected] SIP/2.0From: <sip:[email protected]>;tag=47d7d0882a;epid=f4bced5b3aTo: <sip:[email protected]>CSeq: 1 SUBSCRIBECall-ID: e6befddced82439298f37b91333d7d54…Contact: <sip:[email protected];opaque=user:epid:hD8j4IsNZVSDgSUsYLW2XAAA;gruu>User-Agent: UCCAPI/4.0.7337.0 OC/4.0.7337.0 (Microsoft Lync 2010)Event: vnd-microsoft-roaming-contactsAccept: application/vnd-microsoft-roaming-contacts+xml…


The preceding message is a request from Bob to retrieve his own Contacts list and referred to as a self-subscribe. This request contains the Event attribute vnd-microsoft-roaming-contacts and the Accept attribute application/vnd-microsoft-roaming-contacts+xml. These attributes indicate that this is a roaming Contacts list subscription. When the self-subscribe request is received, the server queries the roaming types to determine the scope of what Bob is subscribed to. It will either create a new self-subscription dialog or refresh and update the current dialog. The server will return all data within the scope of the subscription, regardless of a new dialog creation or the update of an existing dialog. The Contacts list is communicated in an XML format, defined by application/vnd-microsoft-roaming-contacts+xml (Step 5). For details about the creation and maintenance of the self-subscribe request and dialog, see Processing a Self Subscribe Request at http://msdn.microsoft.com/en-us/library/dd945064(office.12).aspx.

The server responds to the client self-subscribe request with a 200 OK message that includes confirmation that the Content-Type was set to application/vnd-microsoft-roaming-contacts+xml as requested, the subscription-state is active, and the expire timer is set to 26,639 seconds (7.4 hours). In the message body, the only contact that Bob is currently subscribed to appears in the contact uri attribute and is [email protected]: responseStart-Line: SIP/2.0 200 OKFrom: "Bob"<sip:[email protected]>;tag=47d7d0882a;epid=f4bced5b3aTo: <sip:[email protected]>;tag=FA6D7960CSeq: 1 SUBSCRIBECall-ID: e6befddced82439298f37b91333d7d54Contact: <sip:cspool.contoso.com:5061;transport=tls;ms-fe=Lab-Pool.contoso.com>Content-Length: 347…Expires: 26639Content-Type: application/vnd-microsoft-roaming-contacts+xmlEvent: vnd-microsoft-roaming-contactssubscription-state: active;expires=26639…Message-Body: <contactList deltaNum="4" ucsMode="disabled" ><group id="1" name="~" externalURI="" /><group id="2" name="Pinned Contacts" externalURI="<groupExtension groupType="pinnedGroup"><email/></groupExtension>" /><contact uri="[email protected]" name="" groups="1" subscribed="true" externalURI="" /></contactList>

Client ProvisioningClient provisioning occurs each time a user logs on with a SIP client. The purpose of provisioning is to configure the client with the current policies and server configuration information and to ensure that the client can communicate effectively with all features available in the organization. What is provisioned on the client is managed by administrative policy. Most policies, previously managed by Group Policy Objects (GPOs) in the domain and forest, have been moved to an in-band policy that you manage by using the Client settings in the Lync Server Control Panel or by using Windows PowerShell® cmdlets. The GPO settings that remain are the policies for provisioning the client to indicate automatic


or manual logon and the associated settings. Until the client is logged on and registered, it can’t receive in-band policy.

The client provisioning process follows these steps:

1. Bob’s client sends a SUBSCRIBE request to itself, where the To and From headers are set to the same URI, and the To header doesn’t include the tag attribute.

2. The client sets the Event header to vnd-microsoft-provisioning-v2, indicating an in-band request.

3. The Accept and Content Type headers are set to application/vnd-microsoft-roaming-provisioning-v2+xml.

4. The Expires header is set to 0 (that is, to expire immediately) because the subscription does not require a dialog.

Note. A request like this—where the To header doesn’t include the tag attribute, and the Expired header is set to zero—is referred to as a “polling subscribe.” In this case the client is querying for the applicable in-band provisioning policy information.

5. The server responds to the SUBSCRIBE request with the results from the in-band query, which are returned in a SIP 200 OK response.

6. After the receipt and processing of the message, the client is provisioned.

Bob’s client formats and prepares the SUBSCRIBE request with the Event header set to vnd-microsoft-provisioning-v2 and the Accept header set to application/vnd-microsoft-roaming-provisioning-v2+xml, which is the format that the client expects the responses to be sent in. The following message illustrates Steps 1- 4 from the preceding list.Message-Type: requestStart-Line: SUBSCRIBE sip:[email protected] SIP/2.0From: <sip:[email protected]>;tag=16d713b581;epid=f4bced5b3aTo: <sip:[email protected]>CSeq: 1 SUBSCRIBECall-ID: ca891f5ed7494bd4947230c4c433e03b…Contact: <sip:[email protected];opaque=user:epid:hD8j4IsNZVSDgSUsYLW2XAAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Event: vnd-microsoft-provisioning-v2Accept: application/vnd-microsoft-roaming-provisioning-v2+xml…Expires: 0Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xmlContent-Length: 625Message-Body: <provisioningGroupList xmlns="http://schemas.microsoft.com/2006/09/sip/provisioninggrouplist" subnet="192.168.0.0"><provisioningGroup name="endpointConfiguration"/><provisioningGroup name="locationPolicy"/><provisioningGroup name="mediaConfiguration"/><provisioningGroup name="meetingPolicy"/><provisioningGroup name="presencePolicyV2"/><provisioningGroup name="privacyPublicationGrammar"/><provisioningGroup name="publicationGrammar"/><provisioningGroup name="ServerConfiguration"/>


<provisioningGroup name="ucPhoneSettings"/><provisioningGroup name="ucPolicy"/><provisioningGroup name="userSetting"/></provisioningGroupList>$$end_recordThis provisioning request contains 11 sets of settings defined in the provisioningGroupList XML element. Note that the provisioningGroupList contains a subnet attribute that identifies the logical network that Bob’s client is on (192.168.0.0). The subnet is used for defining the correct location policy, media configuration, and other network-dependent services that the client must be configured to use.

The following table describes the 11 sets of settings, or provisioningGroup names, in Bob’s SUBSCRIBE request.Table 1. ProvisioningGroup names

provisioningGroup Name

Description

endpointConfiguration Configuration information that is endpoint-specific and that defines the behavior of client features

locationPolicy Policy settings that define location settings for the usermediaConfiguration Configuration information that defines the settings required for media featuresmeetingPolicy Policy settings for meetings that apply globally and are defined by the administratorpresencePolicyV2 Policy settings that define presence featuresprivacyPublicationGrammar Rules for presence containers and membership information that are defined by the

administratorpublicationGrammar Rules that describe publication information, presence containers, and membership

information, as defined by the administratorServerConfiguration Configuration information and provisioning data from the server that applies globallyucPhoneSettings Settings for a unified communications (UC) phone, if the user is enabled for

Enterprise VoiceucPolicy Policy settings for UC that apply globallyuserSetting Settings that are specific to the user

The server responds with a series of 200 OK messages that contain the data for the 11 provisionGroupNames described in the preceding table. The following is the main header of the first message.Message-Type: responseStart-Line: SIP/2.0 200 OKFrom: "Bob"<sip:[email protected]>;tag=16d713b581;epid=f4bced5b3aTo: <sip:[email protected]>;tag=AE560080CSeq: 1 SUBSCRIBECall-ID: ca891f5ed7494bd4947230c4c433e03bContact: <sip:cspool.contoso.com:5061;transport=tls;ms-fe=Lab-Pool.contoso.com>Content-Length: 49221Via: SIP/2.0/TLS 192.168.0.51:52848;ms-received-port=52848;ms-received-cid=CF100Expires: 0Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xmlEvent: vnd-microsoft-provisioning-v2


subscription-state: terminated;expires=0The 200 OK message indicates that this is a response message. Content-Type and Event headers indicate this is a response to the polling subscribe request (Step 6). In the payload of the first message, the presencePolicyV2 data is returned:<provisionGroup name="presencePolicyV2" ><propertyEntryList ><property name="EnablePrivacyMode" >false</property><property name="AutoInitiateContacts" >true</property><property name="PublishLocationDataDefault" >true</property><property name="DisplayPublishedPhotoDefault" >true</property><property name="PersonalNoteHistoryDepth" >3</property></propertyEntryList></provisionGroup>These policies can be administered by using the Lync Server Control Panel or cmdlets such as Set-CsClientPolicy, New-CsClientPolicy, New-CsPrivacyConfiguration, and Set-CsPrivacyConfiguration from the Lync Server Management Shell.

Note. It is possible for a user to exceed the default number of subscribers to a presence policy. The default number of followers or subscribers is 1,000. The maximum numbers of subscribers can be increased to 3,000. If your users report that they are seeing the message “Max Followers Reached,” you can increase the maximum number to 3,000. To increase the maximum number, use the Set-CsPresencePolicy cmdlet to modify the existing policy.

<provisionGroup name="meetingPolicy" ><instance ><property name="AllowIPAudio" >true</property><property name="AllowIPVideo" >true</property><property name="EnableAppDesktopSharing" >true</property><property name="AllowAppSharingForExternalMeeting" >None</property><property name="RetainPPTForExternalMeeting" >true</property><property name="AllowPresenterToRecord" >false</property><property name="EnableDataCollaboration" >true</property><property name="MeetingSize" >200</property><property name="EnablePSTNConferencing" >true</property><property name="TrustedConferencingPinRequired" >false</property><property name="AllowParticipantControl" >true</property><property name="AllowAnnotations" >true</property><property name="AllowAnonymousParticipants" >true</property><property name="AllowExternalUserControl" >false</property><property name="AllowExternalUserToSaveContent" >true</property><property name="AllowExternalUserRecording" >false</property><property name="AllowRecording" >false</property><property name="AllowFileTransfer" >true</property><property name="MaxConferenceVideoResolution" >VGA</property><property name="AllowUserToScheduleMeetingsWithAppSharing" >true</property><property name="EnableP2PFileTransfer" >true</property><property name="AllowedAppDesktopSharingLevel" >Desktop</property><property name="AudioBitRate" >200</property><property name="VideoBitRate" >50000</property><property name="AppSharingBitRate" >50000</property><property name="FileTransferBitRate" >50000</property></instance></provisionGroup>


For example, one of the other provisioning groups that are sent to Bob’s client is the Meeting Policy group. The bold in the preceding message indicates the relevant Meeting Policy settings. The elements within this provisioning group will configure Bob’s client to participate in and lead conferences. The policy also sets the audio and video bitrate for his client when Bob is using voice and video in a conference and the program sharing settings that allow him to present his desktop or a program during a conference. These policies can be administratively configured by using the Lync Server Control Panel or the Lync Server Management Shell.

Other results from in-band provisioning include publication grammars, which can be reviewed by examining the Lync 2010 trace file. By default, the trace file is logged into the %userProfile%\tracing directory. For details about publication grammars, see “[MS-PRES]: Presence Protocol Specification” at http://msdn.microsoft.com/en-us/library/cc431501(v=office.12).aspx.

Basic IM ConversationWhen Bob opens a Conversation window and types a message to Alice, a series of events takes place:

1. An INVITE message is sent to Alice. This message indicates that Bob’s client can send IM data in one of three formats:

o Ms-Text-Format: text/plain; charset=UTF-8o Ms-IM-Format: text/html; charset=UTF-8 o Ms-IM-Format: text/rtf; charset=UTF-8 Note. These formats indicate the type of content. HTML and RTF allow for richer formatting options than plain text.

2. SIP/2.0 100 TRYING messages are issued by Alice’s client, indicating to Bob’s client that the connection attempt to Alice is in progress.

3. The connection between Bob and Alice is established, and Bob’s client issues an ACK message.

4. INFO messages are sent to indicate to Alice that Bob is typing. (Keyboard activity is indicated in Alice’s Conversation window).

5. Bob’s message to Alice arrives as a MESSAGE message.6. Alice responds; her client sends an INFO message (and keyboard activity is indicated

in Bob’s Conversation window) followed by a MESSAGE message with her response. 7. To end the session, BYE messages are sent when Bob and Alice close their

Conversation windows.

Let’s examine this call flow in more details. In Step 1 of the conversation, Bob double-clicks Alice’s contact and an INVITE message is created.Message-Type: requestStart-Line: INVITE sip:[email protected] SIP/2.0From: <sip:[email protected]>;tag=fc002012b6;epid=4daf6bec22To: <sip:[email protected]>CSeq: 1 INVITE…Contact: <sip:[email protected];opaque=user:epid:E3SNaSgYBFGz-yYlV6paigAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Ms-Text-Format: text/plain; charset=UTF-8;msgr=; ms-body=<data removed for brevity> ==Ms-IM-Format: text/html; charset=UTF-8; ms-body=<data removed for brevity>Ms-IM-Format: text/rtf; charset=UTF-8; ms-body=<data removed for brevity>…


Ms-Conversation-ID: AcsjBL38qvaXih5iSrGxIc7K57/R0A==…Roster-Manager: sip:[email protected]: <sip:[email protected]>, <sip:[email protected]>Supported: com.microsoft.rtc-multipartyms-keep-alive: UAC;hop-hop=yesAllow: INVITE, BYE, ACK, CANCEL, INFO, MESSAGE, UPDATE, REFER, NOTIFY, BENOTIFYSupported: ms-conf-inviteContent-Type: application/sdpContent-Length: 223Message-Body: v=0o=- 0 0 IN IP4 192.168.0.51s=sessionc=IN IP4 192.168.0.51t=0 0m=message 5060 sip nulla=accept-types:text/plain multipart/alternative image/gif text/rtf text/html application/ms-imdn+xml text/x-msmsgsinvite In the preceding message trace, there are a number of interesting things that take place while initiating an IM session with Alice’s client. Note the three message format types. The Ms-Conversation-ID is present and is maintained throughout this session. After the session ends, the ID is no longer used. The ID ensures that the same conversation can be escalated to other media forms (conference, voice call, and so on) without the original list of participants being lost. The originator of the IM session, Bob, is set as the roster manager, and the endpoints are listed by their address of record (SIP URI). For certain types of information, Session Description Protocol (SDP) is used. The Content-Type: application/sdp event begins a short string of SDP attributes. The following table defines the SDP attributes used to communicate the session characteristics.Table 2. SDP Attributes

SDP Attribute Descriptionv= Version of SDP. Currently, this is always “0.”o= Originator of the message and the session identifier, expressed as the address type and

unicast-address of the computer from which the session was created. In the example, this is “IN IP4”; “IN” means Internet, and IP4 means IPv4 addressing.

s= Session name.c= Connection data, in the form <nettype> (Internet type), <addrtype> (address type), and

<connection-address>.t= Time the session started and stopped. A start-stop time of “0 0” is deemed permanent,

that is, until the session is terminated by both parties.m= Media description defines the type of session and the port, protocol, and format. Format is

the media descriptor parameter; NULL is used for message sessions that carry no media stream.

a= Attributes meant for extending SDP. In the trace file, the accept-types are the same as the XML format types seen previously.

Alice’s client immediately responds with a SIP/2.0 100 TRYING message even before Alice acknowledges the IM request.Message-Type: responseStart-Line: SIP/2.0 100 TryingFrom: "Bob"<sip:[email protected]>;tag=fc002012b6;epid=4daf6bec22To: <sip:[email protected]>


CSeq: 1 INVITECall-ID: e8bc2528b2b4455a8647e8ff5ed5f94dVia: SIP/2.0/TLS 192.168.0.51:49164;ms-received-port=49164;ms-received-cid=2200Server: http%3A%2F%2Fwww.microsoft.com%2FLCS%2FDefaultRoutingContent-Length: 0Message-Body: –$$end_recordThe TRYING message indicates that Bob’s client is waiting for Alice’s client to establish its side of the session. Alice’s client assigns a Call-ID to uniquely identify this session. The Server header specifies the server component responsible for routing the message.Message-Type: responseStart-Line: SIP/2.0 200 OKFrom: "Alice"<sip:[email protected]>;tag=dc4dda06c6;epid=086d298fb1To: <sip:[email protected]>;epid=4daf6bec22;tag=a2bab57e61CSeq: 1 INVITECSeq: 1 INVITECall-ID: e8bc2528b2b4455a8647e8ff5ed5f94dVia: SIP/2.0/TLS 192.168.0.50:50779;ms-received-port=50779;ms-received-cid=600Record-Route: <sip:pool1.contoso.com:5061;transport=tls;ms-fe=Contoso-FE1.contoso.com;opaque=state:T:F:Eu:Ci.R600;lr;ms-route-sig=aaqy0puSGIgiO0JTO91hUMCb058R2HeYH14i08xkxGiyHSgSmMy-OQWQAA>Contact: <sip:[email protected];opaque=user:epid:E3SNaSgYBFGz-yYlV6paigAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Message-Body: v=0The invite successfully reaches Alice’s client. When Alice accepts the invite, a 200 OK response is returned to Bob.Message-Type: requestStart-Line: INFO sip:[email protected];opaque=user:epid:E3SNaSgYBFGz-yYlV6paigAA;gruu SIP/2.0From: "" <sip:[email protected]>;epid=086d298fb1;tag=9b345de484To: "Bob"<sip:[email protected]>;tag=fc002012b6;epid=4daf6bec22CSeq: 1 INFOCall-ID: e8bc2528b2b4455a8647e8ff5ed5f94d…Route: <sip:pool1.contoso.com:5061;transport=tls;ms-fe=Contoso-FE1.contoso.com;opaque=state:T:F:Ci.R600;lr;ms-route-sig=aaocQ-WQaY20uXFfmt3yPK_v4RT3wZgpWPmXc6JnhBZM4jBpgynBDewwAA>;tag=8C5C5AE036F02D2629B30503F8D03970User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Supported: ms-dialog-route-set-updateSupported: timerContent-Type: application/xmlContent-Length: 87Message-Body: <?xml version="1.0"?><KeyboardActivity> <status status="type" /></KeyboardActivity>INFO messages indicate a flow of information between clients. In this case, the INFO message contains a Content-Type header set to application/xml with status information that Alice is typing at the keyboard, as indicated in the KeyboardActivity attribute.


Alice sends a MESSAGE message to Bob, which contains the actual communication stream listed in the Message-Body header.Direction: incomingPeer: 192.168.0.50:51253Message-Type: requestStart-Line: MESSAGE sip:[email protected];opaque=user:epid:E3SNaSgYBFGz-yYlV6paigAA;gruu SIP/2.0From: "" <sip:[email protected]>;epid=086d298fb1;tag=9b345de484To: "Bob"<sip:[email protected]>;tag=fc002012b6;epid=4daf6bec22CSeq: 4 MESSAGECall-ID: e8bc2528b2b4455a8647e8ff5ed5f94dVia: SIP/2.0/TLS 192.168.0.50:51253Max-Forwards: 70Route: <sip:pool1.contoso.com:5061;transport=tls;ms-fe=Contoso-FE1.contoso.com;opaque=state:T:F:Ci.R600;lr;ms-route-sig=aaocQ-WQaY20uXFfmt3yPK_v4RT3wZgpWPmXc6JnhBZM4jBpgynBDewwAA>;tag=8C5C5AE036F02D2629B30503F8D03970User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Supported: ms-dialog-route-set-updateSupported: timerContent-Type: text/htmlContent-Length: 126Message-Body: <DIV style="font-size: 9pt;font-family: Segoe UI;color: #000000;direction: ltr">It's going fine.... How about you?</DIV>To end the IM session, a BYE message is sent by either party. Closing the Conversation windows ends the session. The Ms-client-diagnostics indicate the reason the session was ended, in this case, “Action initiated by user.”Message-Type: requestStart-Line: BYE sip:192.168.0.51:49164;transport=tls;ms-opaque=ab36ac04a7;ms-received-cid=2200;grid SIP/2.0From: "" <sip:[email protected]>;epid=086d298fb1;tag=9b345de484To: "Bob"<sip:[email protected]>;tag=fc002012b6;epid=4daf6bec22CSeq: 5 BYECall-ID: e8bc2528b2b4455a8647e8ff5ed5f94dVia: SIP/2.0/TLS 192.168.0.3:5061;branch=z9hG4bK6DD6BAE6.806A1626BA247707;branched=FALSE;ms-internal-info="baBjbLJA8Tfjkby9WR6LVh1JQPtTNtvPzvVVIpvyxe7ZsmFmqAlJxYggAA"Max-Forwards: 69Via: SIP/2.0/TLS 192.168.0.50:51253;ms-received-port=51253;ms-received-cid=600User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Ms-client-diagnostics: 51004; reason="Action initiated by user"Content-Length: 0Message-Body: –By default, Lync Server and Lync 2010 logs do not record the actual message content (typed by the IM participants) sent between communicating endpoints. The message body is deleted when the SIP traffic is written to the logs and replaced with the text “message body deleted.” This measure is for privacy purposes. However, you can turn on message-body logging by changing the registry key in the Lync Server 2010, Front End pool. Do this only for testing purposes or in a lab. You should not enable message-body logging in a production environment and cannot enable it in the client software.

To enable message body logging, do the following on each server in a Front End pool:


1. Click Start, click Run, and then type Regedit.2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RtcSrv\

Parameters.3. Right-click the right pane of Registry Editor, and click New, and then, in DWORD

(32-bit), type EnableLoggingAllMessageBodies (no spaces).4. Set EnableLoggingAllMessageBodies to the value 1.5. Close RegEdit, and restart the pool server(s) or restart the RTCSrv service (Lync

Server Front-End service) by doing one of the following:

At an administrator cmd.exe prompt, run the following command:net stop rtcsrv && net start rtcsrv In the Lync Server Management Shell, run the following command:Stop-CsWindowsService –Name RtcSrv –VerboseStart-CsWindowsService –Name RtcSrv -Verbose

Program Sharing and File Transfer During an IM ConversationProgram sharing and file transfer allows users to collaborate by using Lync 2010. The process flow that enables this functionality is as follows:

1. Alice and Carol have an IM conversation established. 2. Alice wants to share a program with Carol. Alice clicks the Share menu, clicks

Program, and then chooses the program she wants to share. 3. Alice’s client sends a SIP INVITE message that initiates media sharing by using the

Interactive Connectivity Establishment (ICE) protocol over SDP.4. Selection of candidate pairs is performed.5. A second INVITE message is sent with selected candidate pairs.6. Alice and Carol successfully share a program. 7. During the program share Alice wants to send Carol a file. An attempt is made to

send a file with a blocked extension, which fails.8. Alice compressing the file and is able to successfully transfer the file because

compressed files are not blocked.9. The session is terminated.

The following ms-client-diagnostics code details the nature of the request. In this case, the client specifies application-sharing as the media type (CalleeMediaDebug=application-sharing), the local candidate (192.168.0.52), the remote candidate (192.168.0.50), and the relay candidate (12.1.1.3). ms-client-diagnostics: 51007;reason="Callee media connectivity diagnosis info";CalleeMediaDebug="application-sharing:ICEWarn%3d0x0,LocalSite%3d192.168.0.52:8615,LocalRelay%3d12.1.1.3:51131,RemoteSite%3d192.168.0.50:18467,RemoteRelay%3d12.1.1.3:53069,PortRange%3d1024:65535,LocalRelayTCPPort%3d51131,RemoteRelayTCPPort%3d53069"Before going into the details of the ICE protocol and SDP definitions, note that the IP address for Alice’s client is 192.168.0.51, and Carol is 192.168.0.52. The following is a portion of a SIP message showing the SDP information exchanged between the two clients that are trying to establish a program (application) sharing session. Content-Type: application/sdpContent-Length: 1138Message-Body: v=0o=- 0 0 IN IP4 12.1.1.3


s=sessionc=IN IP4 12.1.1.3b=CT:99980t=0 0m=applicationsharing 51131 TCP/RTP/SAVP 127a=ice-ufrag:D76Na=ice-pwd:CE62qdTyp+WjfXl+YThqFG/Pa=candidate:1 1 TCP-PASS 2120613887 192.168.0.52 8615 typ host a=candidate:1 2 TCP-PASS 2120613374 192.168.0.52 8615 typ host a=candidate:2 1 TCP-ACT 2121006591 192.168.0.52 5974 typ host a=candidate:2 2 TCP-ACT 2121006078 192.168.0.52 5974 typ host a=candidate:3 1 TCP-PASS 6556159 12.1.1.3 51131 typ relay raddr 192.168.0.52 rport 33241 a=candidate:3 2 TCP-PASS 6556158 12.1.1.3 51131 typ relay raddr 192.168.0.52 rport 33241 a=candidate:4 1 TCP-ACT 7076607 12.1.1.3 51131 typ relay raddr 192.168.0.52 rport 33241 a=candidate:4 2 TCP-ACT 7076094 12.1.1.3 51131 typ relay raddr 192.168.0.52 rport 33241 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:jul1ZZbo6I7tFnBGzIJcdr9c4f9k7zEr5sj2NgC5|2^31|1:1a=setup:activea=connection:existinga=rtcp:51131a=mid:1a=rtpmap:127 x-data/90000a=x-applicationsharing-session-id:1a=x-applicationsharing-role:viewera=x-applicationsharing-media-type:rdp a=x-capabilities:request-control="sendrecv"ICE protocol version 19 is the protocol used to resolve the best path to the peer system. In the preceding trace file, Alice’s client sends the initial INVITE message to Carol’s client. The Content-Type is set to application/sdp, and Alice’s client sends all possible IP addresses that the other party can use to reach it to establish the program-sharing session. This includes paths through the server running Microsoft Lync Server 2010, Edge Server because it’s not possible to know if the best path is actually using a path supplied by the Traversal Using Relay network address translation (NAT) (TURN) server on the server running Lync Server 2010, Edge Server. There are two distinct types of ICE protocol candidate pairs. One active candidate pair indicated by TCP-ACT and one passive candidate pair indicated by TCP-PASS. The following table details the information that is passed by using one set of candidate pairs, as an example.Table 3. ICE protocol version 19 candidates with no TURN

1 2 3 4 5 6a=candidate:1 1 TCP-PASS 2120613887 192.168.0.52 8615 typ host

a=candidate:1 2 TCP-PASS 2120613887 192.168.0.52 8615 typ host

In the preceding table, the column headings mean the following:

1: The first column after “a=candidate” is called the foundation. The foundation is used to optimize ICE protocol performance in the “frozen” algorithm. For details, see “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols” at http://tools.ietf.org/html/draft-ietf-mmusic-ice-19.


2: Transport protocol, where 1 indicates real-time transport protocol (RTP), and 2 indicates real-time transport control protocol (RTCP). 3: TCP/IP passive or active connection, where “ACT” indicates active, meaning Lync Server will attempt to open connections but not allow inbound connections, and “PASS” indicates passive, meaning Lync Server will allow inbound connections but will not open outbound connections.4: Weighting and priority, where a lower number has higher priority and weighting over other candidate pairs.5: Target IP address and port pair.6: Type identifier, where “host” indicates a local address, “relay” indicates an address that is returned from the TURN server, and “srflx” indicates a server reflexive (network-address translated IP) address.Table 4. ICE protocol version 19 with TURN

1 2 3 4 5 6 7 8a=candidate:3 1 TCP-

PASS6556159

12.1.1.3 51131

typ relay raddr 192.168.0.52 rport 33241

The second distinct set of candidate pairs has more definitions as is required when a TURN server (that is, an Edge Server) is providing information for other potential candidate paths. The first four columns are identical to the non-TURN example. The next four columns are described as follows:

5: IP Address and port of the TURN server6: Type identifier; “relay” indicates that the TURN server is used7: Remote IP address, in context to the TURN server8: Remote port, in context to the TURN serverAfter the candidate list, we define other attributes to establish the program sharing connection parameters. Program sharing always uses TCP. The SDP attribute ‘m=’ was discussed previously, but the usage here is more verbose.

‘m=applicationsharing 51131 TCP/RTP/SAVP 127’: Indicates that this is a program-sharing session in negotiation, that the port offered is 51131, and that the protocol is RTP over TCP. a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:jul1ZZbo6I7tFnBGzIJcdr9c4f9k7zEr5sj2NgC5|2^31|1:1: Defines the type of encryption used (AES 128-bit, with a SHA1 hash); the inline header defines the SALT value or key, and 2^31 is the lifetime.Of even further interest are the five lines near the end of the trace. The SDP attribute a= allows for extension of the base protocol. We make use of this to define specifics for the use of program sharing and the use of Remote Desktop Protocol (RDP).

a=rtpmap:127 x-data/90000: Defines the RTdata payload for program sharing streams at a clock rate of 90,000.a=x-applicationsharing-session-id:1: Used to uniquely identify a particular sharing session. If this parameter is missing, the session will connect to the first available session.


a=x-applicationsharing-role:viewer: Defines the initial role of a participant as “viewer” or “sharer.”a=x-applicationsharing-media-type:rdp: Used to negotiate the media type (RDP) to be used.a=x-capabilities:request-control="sendrecv": Allows the receiver to request control. If “recv,” the user can view only.

Note. For a detailed discussion of the SDP contained in these messages and the processes that take place in this transaction using ICE protocol, Session Traversal Utilities for NAT (STUN), and TURN, see “How Communicator Uses SDP and ICE to Establish a Media Channel” at http://blogs.technet.com/b/nexthop/archive/2009/04/22/how-communicator-uses-sdp-and-ice-to-establish-a-media-channel.aspx.

After the initial negotiation of possible candidates, the candidates are tested. The candidates with the shortest path, least latency, and best performance are selected. The preceding trace file is from the re-INVITE (that is, the second INVITE) message that contains only the selected candidates. One candidate is used for the RTP traffic, and the other candidate is for the RTCP traffic. The RTP traffic provides end-to-end communications. The RTCP traffic enables monitoring of the RTP traffic.

a=candidate:2 1 TCP-ACT 2121006591 192.168.0.50 10839 typ host a=candidate:2 2 TCP-ACT 2121006078 192.168.0.50 10839 typ host a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:slB/STZQ+eua1ri+lNUZ8mQbuvU9/7IAhnBV4ToN|2^31|1:1a=remote-candidates:1 192.168.0.52 8615 2 192.168.0.52 8615a=setup:activea=connection:existinga=rtcp:10839The session between Carol and Alice changes to a peer-to-peer connection. Logs from the Front End Server will not show any further conversations until the RDP session concludes.

File Send to IM PeerWhen sending a file to a peer in an IM session, the file is sent by using the file transfer application. To establish this session, a streaming media connection, much like program sharing, must be used. The same negotiation of SDP, the ICE protocol candidates, and TURN relay is leveraged.Content-Type: application/sdpContent-Transfer-Encoding: 7bitContent-ID: <d744b9d0e67b4f13adfa775cf726638b>Content-Disposition: session; handling=optional; ms-proxy-2007fallbacka=candidate:1 1 TCP-PASS 2120613887 192.168.0.50 21708 typ host a=candidate:1 2 TCP-PASS 2120613374 192.168.0.50 21708 typ host a=candidate:2 1 TCP-ACT 2121006591 192.168.0.50 3788 typ host a=candidate:2 2 TCP-ACT 2121006078 192.168.0.50 3788 typ host a=candidate:3 1 TCP-PASS 6556159 12.1.1.3 57551 typ relay raddr 192.168.0.50 rport 2148 a=candidate:3 2 TCP-PASS 6556158 12.1.1.3 57551 typ relay raddr 192.168.0.50 rport 2148 a=candidate:4 1 TCP-ACT 7076607 12.1.1.3 57551 typ relay raddr 192.168.0.50 rport 2148 a=candidate:4 2 TCP-ACT 7076094 12.1.1.3 57551 typ relay raddr 192.168.0.50 rport 2148


a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:Tqo5d57HrFAATD+rNUIqR8mVNqxrPrswGoD8zog+|2^31|1:1a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:SvRcjh+i8tdJk9DGiUf20hMH3U9q1MKiNaQvLjsq|2^31|1:1a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:mDbPTkCgDgauVRtUnBlleDiJdllyX/Iln/s7tA7U|2^31a=setup:activea=connection:newa=rtcp:57551a=mid:1a=sendonlya=rtpmap:127 x-data/90000…Content-Type: application/ms-filetransfer+xmlContent-Transfer-Encoding: quoted-printableContent-ID: <1ecc2293567c47d0bffaeea160041ed9>Content-Disposition: render; handling=optional<request xmlns=3D"http://schemas.microsoft.com/rtc/2009/05/filetransfer" =requestId=3D"3"><publishFile><fileInfo><id>{7894F55F-CAF9-435E-A46A-742A273174EB}</id><name>LPSetupUI.exe</name><size>207616</size></fileInfo></publishFile></request>Alice attempts to send the file LMSetupUI.exe to Carol. The attempt is blocked by the intelligent instant messaging (IIM) filter on the Front End Server. The administratively set policy prevents sending a file with specific extension –including executable types. The SIP/2.0 606 and the Ms-client-diagnostics message clearly indicate the problem with the file transfer.Start-Line: SIP/2.0 606 Not AcceptableFrom: "Alice"<sip:[email protected]>;tag=acefb00001;epid=086d298fb1To: <sip:[email protected]>;epid=0dec2f63d6;tag=db1a927b54CSeq: 1 INVITECall-ID: 00e157f71d8c4a6193fa38c46217ff80Via: SIP/2.0/TLS 192.168.0.50:53179;ms-received-port=53179;ms-received-cid=1D7000User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Ms-client-diagnostics: 52050; reason="File Type Disabled By Policy"Alice compresses the file into a .ZIP file, and she sends LPSetupUI.ZIP. The .ZIP extension is not explicitly blocked by the IIM filter. The transfer is reported as successful to the Front End Server by the endpoints.Message-Body: <request xmlns="http://schemas.microsoft.com/rtc/2009/05/filetransfer" requestId="6"><downloadFile><fileInfo><id>{42E198EF-989F-4476-8B08-FBB090CA2890}</id><name>LPSetupUI.zip</name></fileInfo></downloadFile></request>Content-Type: application/ms-filetransfer+xml


Content-Length: 104Message-Body: <response xmlns="http://schemas.microsoft.com/rtc/2009/05/filetransfer" requestId="6" code="success"/>

Turning an IM Conversation into an IM Conference The difference between how a two-party IM session (an IM conversation) works and a multiparty IM session (an IM conference) works is described in this section.

In an IM conversation, the session is peer-to-peer. The two clients manage the IM session as shown in the following trace file. Via: SIP/2.0/TLS 192.168.0.51:49164;ms-received-port=49164;ms-received-cid=2200User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)In the case of an IM conference, the session is managed by the Lync Server IM Conferencing service (also known as the IM multipoint control unit or IM MCU) as shown in the following trace file.Via: SIP/2.0/TLS 192.168.0.3:52801;branch=z9hG4bK31628a3b;ms-received-port=52801;ms-received-cid=2300CONTENT-LENGTH: 87USER-AGENT: OCS-IMMCU/4.0.7358.0The Lync Server IM Conferencing service runs on the Front End Server of the initiator.

In our example, Bob initiates the session with Alice, and Alice invites Carol. This process flow is as follows:

1. Initiator (Bob) invites first IM attendee (Alice).2. Lync handles the session.3. First IM attendee (Alice) invites third IM attendee (Carol).4. IM is raised to an IM conference, and the peer-to-peer conversation is moved to run

on the Lync Server IM Conferencing service hosted on the initiator’s pool.

Peer: 192.168.0.50:50779Message-Type: responseStart-Line: SIP/2.0 200 OKFrom: "Alice"<sip:[email protected]>;tag=dc4dda06c6;epid=086d298fb1To: <sip:[email protected]>;epid=4daf6bec22;tag=a2bab57e61CSeq: 1 INVITECall-ID: 1bf38e48e6a74edf8f849391544a1038Proxy-Authentication-Info: Kerberos qop="auth", opaque="2528E6E4", srand="ABF1D66A", snum="97", rspauth="040401ffffffffff00000000000000009e773d767c1908f4c442df76", targetname="sip/Contoso-FE1.contoso.com", realm="SIP Communications Service", version=4Via: SIP/2.0/TLS 192.168.0.50:50779;ms-received-port=50779;ms-received-cid=600Record-Route: <sip:pool1.contoso.com:5061;transport=tls;ms-fe=Contoso-FE1.contoso.com;opaque=state:T:F:Eu:Ci.R600;lr;ms-route-sig=aaqy0puSGIgiO0JTO91hUMCb058R2HeYH14i08xkxGiyHSgSmMy-OQWQAA>Contact: <sip:[email protected];opaque=user:epid:E3SNaSgYBFGz-yYlV6paigAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Peer: 192.168.0.52:49826Message-Type: responseStart-Line: SIP/2.0 200 OK


From: "Carol"<sip:[email protected]>;tag=a97b2b1151;epid=0dec2f63d6To: <sip:[email protected];gruu;opaque=app:conf:chat:id:XGMUZUMW>;tag=3e2883b98CSeq: 1 INVITECall-ID: c5f1b70aaac84463bf63d664a0e91e23Proxy-Authentication-Info: Kerberos qop="auth", opaque="9EDF8069", srand="9ACD0033", snum="96", rspauth="040401ffffffffff0000000000000000f5cde0abf9d9afc8f47993a1", targetname="sip/Contoso-FE1.contoso.com", realm="SIP Communications Service", version=4Via: SIP/2.0/TLS 192.168.0.52:49826;ms-received-port=49826;ms-received-cid=800RECORD-ROUTE: <sip:pool1.contoso.com:5061;transport=tls;ms-fe=Contoso-FE1.contoso.com;opaque=state:T:Tc.YsrCE869DlCqFTzSbvSYdsYT:F:Fc.YsrCE869DlCqFTzSbvSYdsYT:Eu:Ci.R800;lr;ms-route-sig=aaf4BEBe8Oa9NzWNY7RutS5Pikd_jGGScq2UlXOyHbvZLE9Tfay-OQWQAA>CONTACT: <sip:[email protected];gruu;opaque=app:conf:chat:id:XGMUZUMW>;isFocusCONTENT-LENGTH: 108SUPPORTED: timerCONTENT-TYPE: application/sdpALLOW: UPDATEREQUIRE: timerSERVER: OCS-IMMCU/4.0.7358.0

SummaryBefore Lync 2010 signs in to Lync Server, the client must discover the Lync Server through DNS queries, and then it must authenticate the user with the server. After the client is logged on, it retrieves the user’s Contacts list and in-band provisioning settings. These steps are explained in detail in this chapter, which also dissects the SIP traffic that results from users starting an IM conversation and illustrates what’s involved in escalating the conversation into an IM conference. Adding in program sharing is also covered.

Additional ResourcesFor more information, see the following:

SIP: Session Initiation Protocol, http://www.ietf.org/rfc/rfc3261.txt SDP: Session Description Protocol, http://www.ietf.org/rfc/rfc4566.txt A Model for Presence and Instant Messaging, http://tools.ietf.org/rfc/rfc2778.txt Session Initiation Protocol (SIP)-Specific Event Notification,

http://tools.ietf.org/rfc/rfc3265.txt A Watcher Information Event Template-Package for the Session Initiation Protocol

(SIP), http://tools.ietf.org/rfc/rfc3857.txt Presence Information Data Format (PIDF), http://tools.ietf.org/rfc/rfc3863.txt TCP Candidates with Interactive Connectivity Establishment (ICE),

http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-07 Interactive Connectivity Establishment (ICE): A Protocol for Network Address

Translator (NAT) Traversal for Offer/Answer Protocols, http://tools.ietf.org/html/draft-ietf-mmusic-ice-19

[MS-ICE]: Interactive Connectivity Establishment (ICE) Extensions, http://msdn.microsoft.com/en-us/library/cc431495(v=office.12).aspx


[MS-ICE2]: Interactive Connectivity Establishment (ICE) Extensions 2.0, http://msdn.microsoft.com/en-us/library/cc431504(v=office.12).aspx

[MS-SIPAE]: Session Initiation Protocol (SIP) Authentication Extensions, http://msdn.microsoft.com/en-us/library/cc431510(v=office.12).aspx

[MS-SIPREGE]: Session Initiation Protocol (SIP) Registration Extensions, http://msdn.microsoft.com/en-us/library/cc431491(v=office.12).aspx


Date post:	10-Jun-2018
Category:	Documents
Upload:	lecong
View:	226 times
Download:	0 times

download.microsoft.comdownload.microsoft.com/.../Chapter_10_Instant_Messagi… · Web viewIn her...

Documents