Chapter 09 External User Access

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 doesnt 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, MSN, Windows, 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 External User Access
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 nexthop@microsoft.com. 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.
Page 3
Contributors
Project Manager: Susan S. Bradley Content Architect: Rui Maximo Chapter Lead: Randy Wintle Writer: Dustin Hannifin Contributing Writer: Steven van Houttum Technical Reviewers: Byron Spurlock, Conal Walsh, Prasad Thota, William Looney Lead Editor: Kelly Fuller Blue Art Manager: Jim Bradley Production Editor: Kelly Fuller Blue
Page 4
Table of Contents
Contributors................................................................................................................ 4 External User Access Scenarios...................................................................................7 Instant Messaging and Presence Scenarios..............................................................7 Remote User Access Scenario Overview................................................................7 Federation Scenario Overview...............................................................................7 Public IM Connectivity Scenario Overview.............................................................8 Conferencing Scenarios............................................................................................8 Enterprise Voice Scenarios.......................................................................................8 Peer-to-Peer Calls Scenario Overview....................................................................8 Remote Access User Call to PSTN Gateway Scenario Overview.............................9 Remote Access Call from a User to a Federated User Scenario Overview..............9 Interactive Connectivity Establishment (ICE) Protocol................................................10 Media Relay Authentication Service (MRAS)..............................................................15 Enterprise Voice ....................................................................................................... 19 Remote User to the PSTN Gateway........................................................................19 Call Flow.............................................................................................................19 Remote User to a Federated User.......................................................................34 Peer-to-Peer........................................................................................................ 38 Conferencing .........................................................................................................42 Application Sharing.............................................................................................42 Audio and Video Conferencing............................................................................50 IM and Presence ....................................................................................................56 Remote Access................................................................................................... 56 Federation.......................................................................................................... 60 Public IM Connectivity.........................................................................................63 Ms-diagnostics.......................................................................................................65 Remote User Access (IM and Presence)...............................................................66 Federation.......................................................................................................... 66 Public IM Connectivity.........................................................................................67
Page 5
Application Sharing.............................................................................................67 Audio and Video Conferencing............................................................................67 Media Relay Authentication Service (MRAS)........................................................68 Enterprise Voice..................................................................................................70 Summary.................................................................................................................. 70 Additional Resources.................................................................................................70
Page 6
External User Access Scenarios

Microsoft Lync Server 2010 communications software allows users to connect to each other remotely. This chapter describes the most common remote access scenarios, and then provides detailed call flow diagrams and related ms-diagnostics codes.
Note. All the scenarios in this chapter were created with access only from outside the corporate firewall.
The types of remote access that are covered in this chapter are described in the following sections. Overviews of the basic scenarios are provided, giving context for how users make various connections. Internals (technical details of remote user access capabilities) are discussed in depth in this chapter and figure prominently in the scenarios. An introduction to the Interactive Connectivity Establishment (ICE) protocol, Simple Traversal Underneath NAT (STUN), and Traversal Using Relay NAT (TURN) implementations in Lync Server are provided.
Instant Messaging and Presence Scenarios

Lync Server 2010 allows users to access instant messaging (IM) and presence remotely by using the Lync Server Access Edge service. The following scenario overviews describe remote IM and presence in remote user access, federation, and public IM connectivity.
Remote User Access Scenario Overview

Remote user access is used to allow corporate users of Lync Server to remotely access the Lync Server 2010 infrastructure without a virtual private network (VPN) connection. Remote user access is supported by Microsoft Lync Server 2010, Edge Server. It provides users with all the features that Lync 2010 has to offer, including IM and presence, conferencing, and Enterprise Voice. The following scenario overview describes how IM and presence are accomplished between two users (who are in the same company) by using remote user access. Bob is working from home and through the Lync Server 2010, Edge Server. Alice is working in the office and can directly connect to the corporate Lync Front Server Pool. Bob starts Lync 2010 and sees Alices presence status. Bob then initiates an IM conversation with Alice using the Lync 2010 Client. She receives Bobs IM in the Lync 2010 Client, and then replies by sending an IM.
Federation Scenario Overview

Federation is a server-role configuration between organizations, based on Lync Server or Microsoft Office Communications Server deployment. Federation allows Lync 2010 users to communicate with users in other organizations that have Lync Server or Office Communications Server deployed. Federation is made possible when these organizations use the Lync Server Edge Server (or Office Communications Server Access Edge Server). The following scenario overview describes how IM and presence occurs between two users (who are from two different companies) by using federation. Bob works for Contoso, Ltd and is connected to the Contoso, Ltd Lync Server infrastructure. Alice works for Fabrikam, Inc. and is connected to the Fabrikam, Inc. Lync Server infrastructure. Contoso, Ltd and Fabrikam, Inc. are federated with each other. Alice has Bob on her Contacts list. She opens Lync 2010, and sees that Bobs
Page 7
presence status is Available. Alice starts an IM conversation with Bob. Bob receives the IM in his Lync 2010 client and then replies.
Public IM Connectivity Scenario Overview

Public IM connectivity is a type of federation. Here, an organization federates with public IM networks such as AOL, Yahoo!, and the MSN network of Internet services. Using public IM connectivity, Lync 2010 users can see presence status and also send and receive instant messages to users on public IM networks. The following scenario overview describes how public IM connectivity allows users (who are from two different companies) to communicate outside a Lync Server deployment. Bob works for Contoso, Ltd and is connected to its Lync Server infrastructure. Sally works for a company that doesnt have Lync Server deployed. Sally uses Windows Live Messenger. Bob has Sally on his Lync 2010 Contact list and can see her presence status. Bob initiates an IM conversation with Sally. She receives the IM on her Windows Live Messenger client, and then replies. Bob receives the reply in Lync 2010.
Conferencing Scenarios
Lync Server allows users without a VPN connection to remotely participate in audio and video conferences that are hosted by Lync 2010. Remote conferencing features are supported by the Web Conferencing Edge service and the Audio/Video Edge service. The following scenario overview describes audio and video conferences for users that work for the same company but are in different locations. Bob and Alice both work for Contoso, Ltd. Bob is working from home. Alice is working from an office location on the corporate network. Alice schedules an audio and video conference, and then invites Bob to the call. Bob joins the conference by clicking the join URL in the invitation to the meeting. Bobs Lync 2010 client connects to the audio and video conference through the Audio/Video Edge service.
Enterprise Voice Scenarios

Users who are outside the corporate network can make and receive Enterprise Voice calls. Enterprise Voice calls are classified as any audio call from Lync 2010, including calls to the PSTN gateway.
Peer-to-Peer Calls Scenario Overview

Peer-to-peer calls involve two Lync 2010 users who are using the Lync 2010 client or Microsoft Lync 2010 Phone Edition to place an IP-to-IP call. This scenario doesnt involve the PSTN gateway. The following scenario overview shows that Bob and Alice are working from their respective home offices and have connectivity to Lync Server through their companys Lync Server Edge Servers. Bob initiates a Lync 2010 call to a Lync 2010 audio call with Alice. She ends the call when the conversation is finished.
Page 8
Remote Access User Call to PSTN Gateway Scenario Overview

Calls occur from a remote access user to a PSTN gateway when a Lync 2010 user placing a call out to the PSTN gateway while they are remotely connected to Lync Server. Following is an overview of that scenario. Bob is working from home and places a call to Alices mobile phone. The call is sent through the Lync Server infrastructure and out to the PSTN gateway.
Remote Access Call from a User to a Federated User Scenario Overview

Calls from a remote access user to a federated user happens when a Lync 2010 user who is working remotely and connected to their Lync Server infrastructure places a call to a federated contact. Following is an overview of that scenario. Bob works for Contoso, Ltd; Alice works for Fabrikam, Inc. Both Contoso, Ltd and Fabrikam, Inc. allow federation to the others Lync Server infrastructure. In this scenario, Bob is working from his home office. He places a call to Alice.
Page 9
Interactive Connectivity Establishment (ICE) Protocol

An important component to Lync 2010 Enterprise Voice and Conferencing scenarios are the ICE protocols and STUN/TURN. All Enterprise Voice and conferencing remote access scenarios use the ICE protocol and STUN/TURN for media connectivity. ICE protocol connectivity checks are referenced in all the call flows in this chapter. It is important to have a general understanding of what is happening during an ICE protocol connectivity check, including how the ICE protocol candidates are identified prior to performing connectivity checks. Figure 1 shows the ICE protocol/STUN process for a basic peer-to-peer call.
Figure 1. ICE protocol
The following numbered headings describe the ICE protocol sequence that is shown in Figure 1. The heading numbers correspond to the sequence numbers (connectors) in Figure 1.
1 SIP INVITE
Figure 1 shows that when a remote Lync 2010 user sends a SIP INVITE to establish an audio call with an internal Lync 2010 user, a list of candidates for media connectivity is sent. These candidates are a combination of available IP version 4 (IPv4) addresses and randomly allocated Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) ports within the configured port ranges that are on the client. In the simplest scenario, a user at home behind a home router has the following candidates:
Page 10
Internal IP address: The IP address assigned to the network interface of the client computer. Reflexive IP address: The IP address of the public address assigned to the home router. Media relay address: The public IP address of the Audio/Video Edge service that is associated with the internal Lync 2010 users pool. Each candidate is sent in the SIP INVITE with a dynamic TCP and UDP media port.
2 SIP 200 OK
The internal Lync 2010 client that is receiving the call responds with a 200 OK that contains that clients candidate list.
3 STUN binding requests

ICE protocol connectivity checks are performed to establish the most direct media path possible between the two Lync endpoints (that is, caller and callee). The ICE protocol candidates are tested in the following ordered pairs of IP addresses and ports: UDP direct: A connectivity check on the UDP ports of each users computer IP addresses, testing direct connectivity. UDP NAT: Applies only to two users who are outside the corporate firewall that connects to the Lync infrastructure through the Edge Server. This scenario involves trying connectivity through the reflexive IP addresses for each home user. The reflexive IP Address is the public IP address of the home router. UDP relay: Between two external users, or an external user and an internal user. This connectivity would be relayed through the public IP address of the Audio/Video Edge service. TCP relay: The relay address (Audio/Video Edge public interface) if connectivity isnt available on UDP, TCP Relay would be a last resort. The ICE protocol connectivity checks are sequences of STUN packets that are sent between port pairs in the order shown in the previous list. A STUN response indicates connectivity. Connectivity checks are stopped after a valid bidirectional path has been achieved.
4 SIP INVITE
The caller sends another SIP INVITE containing a validated remote candidate (search for a=remote-candidate in the traces logs).
5 SIP 200 OK
The callee then responds with a SIP 200 OK with the callers validated remote candidate.
6 Media
At this point, media flows between the two clients over the negotiated IP and port pairing. Table 1 shows the important components of ICE protocol phases to look for when analyzing SIP traces of Lync 2010 media sessions.
Page 11
Table 1. Most important components of ICE protocol phases
ICE Protocol Phases

AVEdgeProvisioning
Unified Communications Client Platform (UCCP) Log Item

Search mrasuri for a SIP 200OK provisioning response. Confirms that that pool is configured with the Audio/Video Edge service. Search credentialsRequestID for SIP SERVICE. Confirms that the Audio/Video Edge service is running and reachable on TCP5062. The UCCP log Item. Search a=candidate to find the first INVITE/200OK. Check IP addresses of UDP/TCP for candidate pairs in INVITE. Confirms local endpoint can reach the Audio/Video Edge service. Search a=candidate to find the first INVITE/200OK. Check the IP address of the UDP/TCP candidate pairs in 200OK. Confirms remote endpoint can reach the Audio/Video Edge service. Check RE-INVITE (see Candidate promotion for the connectivity check result. Confirms that the connectivity check is complete. Search for a=remote-candidate. INVITE and 200OK should have only one candidate pair. Confirms that candidate promotion is complete and the path that the ICE protocol was negotiated.
AVEdgeCredentials
ICE Protocol negotiation address discovery
Address exchange
Connectivity checks
Candidate promotion
Table 2 describes what happens when these ICE protocol warning flags occur. These flags are displayed in the MSDIAGNOSTICS sections of SIP messages that relate to call set-up. Examples of these warning flags are discussed later in this chapter. Use Table 2 as a reference when you troubleshoot call scenarios that involve remote user access. In the following table, flags are described as expected or not expected. Flags that are not expected result in a call failure. Flags that are expected may not result in a complete call failure.
Table 2. ICE protocol warning flags
ICE Protocol Warning Flags

0x0 0x1
Description
There were no failures or the ICE protocol was not used. TURN server is unreachable.
Actions for the Administrator

None. This flag is not expected. Administrator need to ensure that the right ports (443/3478by default) are open on the firewall or the TURN server is running. This may result in an ICE protocol failure. This flag may be expected if the client is behind a UDP blocking firewall. This may result in an ICE protocol failure. This flag may be expected if the client is behind a UDP blocking firewall. This may result in an ICE protocol failure. This flag isnt expected. The administrator needs to check the
0x2
An attempt to allocate a UDP port on the TURN server failed.
0x4
An attempt to send UDP on the TURN server failed.
0x8
An attempt to allocate a TCP port on the TURN server failed.
Page 12
firewall policy, and ensure that Audio/Video Edge service is reachable. If the client is behind an HTTP proxy, the administrator needs to ensure that the proxy isnt failing the TLS attempt. This failure may result in an ICE protocol failure. 0x10 An attempt to send TCP on the TURN server failed. This flag isnt expected. The administrator needs to check the firewall policy, and ensure that Audio/Video Edge service is reachable. If the remote client is behind an HTTP proxy, the admin needs to ensure that the proxy isnt failing the TLS attempt. This failure may result in an ICE protocol failure. This flag can occur if the direct connection between clients isnt possible due to NAT/firewalls. This may result in an ICE protocol failure. This flag can occur if the direct connection between clients isnt possible due to NAT/firewalls. This may result in an ICE protocol failure. This flag can occur if one of the clients is behind a UDP blocking firewall/HTTP proxy. This may result in an ICE protocol failure. This flag is expected. If local-to-local connectivity succeeded, the TCP NAT connectivity check may not have been tried. Or there is no direct TCP connection possible. TCP NAT connectivity failing may result in an ICE protocol failure. This flag is expected. If local-to-local connectivity succeeded, the TCP TURN connectivity check may not have been tried. Or one side didnt have TURN server allocation. If connectivity checks were successful for the rest of the call, ignore this ICE protocol warning. Otherwise, investigate why the TCP path was not possible. TCP TURN server connectivity failing may result in an ICE protocol failure. This flag isnt expected. If the admin sees this flag, it indicates some security attack. This may result in an ICE protocol failure. This flag is expected if there is a bandwidth policy configured on the call link. If there is a call failure with this flag, increase the allocated bandwidth on the failed link. This flag isnt indicating any ICE protocol failure, simply that there was a bandwidth policy applied to this call.
0x20
Local connectivity failed. (local UDP for audio/video and local TCP for application sharing and file transfer). UDP NAT connectivity failed.
0x40
0x80
UDP TURN server connectivity failed.
0x100
TCP NAT connectivity failed.
0x200
TCP TURN server connectivity failed.
0x400
Message integrity failed in connectivity check request.
0x1000
A policy server was configured.
Page 13
0x2000
Connectivity check requested failed because of a memory problem or other reasons that prevented sending packets.
This flag is unexpected and may indicate that a computer is over capacity This may result in an ICE protocol failure.
0x4000
TURN server credentials have expired or are unknown.
This flag is unexpected and may indicate that Audio/Video Edge service authorization service is down. This may result in an ICE protocol failure. If there is an ICE protocol failure with this flag set, this indicates that the policy server topology is misconfigured. In this configuration the policy was configured to route over another connection, but the other connection failed. (Possibility of internal NATs in the org). This flag may result in an ICE protocol failure. This flag indicates that the bandwidth being used on this call isnt optimal quality (may be using a narrow-band codec or may not be capable of HD video). This flag does not indicate any ICE protocol failure. This is unexpected. The call continues but the bandwidth used by this call may not be reported properly to the Bandwidth Policy Core Service. This can occur because the policy server or the TURN server have failed. This flag does not indicate any ICE protocol failure. This flag is indicating that the policy server rejected the client to use a media path through two Audio/Video Edge services (relay to relay). This may result in an ICE protocol failure. This flag is indicating that there was no TURN server configured or there is a Domain Name System (DNS) resolution failure, resulting in a communication issue between the client and the TURN server. This may result in a protocol ICE failure. This flag is expected. This is indicating that there were multiple TURN servers configured (due to DNS load balancing). This flag does not indicate any ICE protocol failure. This is indicating that the administrator manually configured ports on the client or the media server. A/V needs a minimum of 20 ports per call to start the call. Application sharing/file transfer needs a minimum of 3 ports. The port range being exhausted may
0x8000
Bandwidth policy restriction has removed some candidates.
0x10000
Bandwidth policy restriction decreases the bandwidth.
0x20000
Bandwidth policy keep-alive failed.
0x40000
Bandwidth policy allocation failure.
0x80000
No TURN server configured.
0x100000
Multiple TURN servers configured.
0x200000
Port range exhausted.
Page 14
result in an ICE protocol failure. 0x400000 Received alternate server . This is indicating that the TURN server is overloaded or preventing new connections. This may result in an ICE protocol failure if the alternate server isnt running This is indicating that the HTTP proxy is performing deep Secure Sockets Layer (SSL) inspection and failing the connection with the TURN server. This is not supported by Microsoft and may result in an ICE protocol failure. This is indicating that the HTTP proxy is configured This flag does not indicate any ICE protocol failure. This is indicating that the HTTP proxy failed the authentication. This isnt expected and indicates that the HTTP proxy didnt recognize the users credentials or authentication mode. This may result in an ICE protocol failure. This is indicating that TURN TCPTCP connectivity check was tried and it failed. The failure indicates that port 443 was not opened on the firewall. If one of the TURN servers was 2007 A/V Edge Server. The administrator needs to open ports from 50,000 through 59,999 TCP to all external Audio/Video Edge services in the environment. This flag isnt expected and may result in an ICE protocol failure. This is indicating that after receiving some packets the client didnt receive the rest of the packets. This may happen on a client because of a third Winsock layered service providers (LSPs). These LSPs should be removed. This flag isnt expected and may result in an ICE protocol failure.
0x800000
Pseudo-TLS failure.
0x1000000
HTTP proxy configured.
0x2000000
HTTP proxy authentication failed.
0x4000000
TCP-TCP connectivity checks failed over the TURN Server.
0x80000000
Use candidate checks failed.
Media Relay Authentication Service (MRAS)

The Media Relay Authentication Service (MRAS) generates credentials required for external media scenarios for Lync users. Before a remote user can initiate Enterprise Voice calls, or join conferences, the users client must first obtain credentials to connect to the Audio/Video Edge service. This allows the Edge Server to relay the media traffic internally. To obtain this credential, the remote client sends a SIP request to the users pool. The pool then forwards the request to MRAS, which runs on the Edge Server internal interface. MRAS generates a credential for the user. This credential is valid for up to 8 hours by default (this duration is configurable). MRAS sends the response back to the Front End pool. It then
Page 15
forwards the response back to the client. At this point, the remote client can connect to the Audio/Video Edge service and establish a media path through the Edge Server. MRAS runs on the internal interface of the Edge Server and listens for requests on TCP port 5062. When deploying Front End pools that have remote access enabled, an Edge pool is associated with the Front End pool for external audio and video scenarios. Figure 2 outlines the previously described process.
Figure 2. MRAS request sequence
The following numbered headings describe the MRAS request sequence that is shown in Figure 2. The heading numbers correspond to the sequence numbers (connectors) in Figure 2.
1 SIP REGISTER
The user signs in to Lync 2010 through the Access Edge service, and signs in to the appropriate Front End pool.
2 MRAS REQUEST
The Lync 2010 client requests MRAS credentials by using the users Front End pool. The following SIP trace shows the user <userName>@contoso.com, requesting MRAS credentials to the server edgeinternalfqdn.contoso.com. In the following SIP message, the content (highlighted) outlines that this is an MRAS request. The SIP URI of the requesting user is provided in addition to the location (Internet or intranet) and the duration.
Page 16
02/09/2011|10:00:41.608 1B9C:A24 INFO :: Sending Packet - 208.115.110.XXX:443 (From Local Address: 192.168.1.138:54415) 1334 bytes: 02/09/2011|10:00:41.608 1B9C:A24 INFO :: SERVICE sip:edegeinternalfqdn.contoso.com@Contoso.com;gruu;opaque=srvr:MRAS:v6H_IuZa1irVldx3Z_CdgAA SIP/2.0 Via: SIP/2.0/TLS 192.168.1.138:54415 Max-Forwards: 70 From: <sip:<userName>@contoso.com>;tag=6adfd24c1b;epid=92a17ee2ce To: <sip:edgeinternalfqdn.contoso.com@Contoso.com;gruu;opaque=srvr:MRAS:v6H_IuZa1irVldx3Z_CdgAA> Call-ID: 0ba8a0c30bf74534a7d94a182b4d72f8 CSeq: 1 SERVICE Contact: <sip: <userName>@contoso.com;opaque=user:epid:1dRPOJppUlGQszig4EXYgAA;gruu> User-Agent: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010) Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="6436AC83", targetname="edgeinternalfqdn.contoso.com", crand="eee9b681", cnum="7", response="63d56f98d452b3e25266ba340e88dfb47e96c7de" Content-Type: application/msrtc-media-relay-auth+xml Content-Length: 478 <request requestID="128326152" version="2.0" to="sip: EDGEINTERNALFQDN.Contoso.com@Contoso.com;gruu;opaque=srvr:MRAS:v6H_IuZa1irVldx3Z_CdgAA" from="sip: user@contoso.com " xmlns="http://schemas.microsoft.com/2006/09/sip/mrasp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><credentialsRequest credentialsRequestID="128326152"><identity>sip: <userName>@contoso.com </identity><location>internet</location><duration>480</duration></credentialsRequest> </request> 02/09/2011|10:00:41.608 1B9C:A24 INFO :: End of Sending Packet - 208.115.110.XXX:443 (From Local Address: 192.168.1.138:54415) 1334 bytes
3 MRAS RESPONSE
Stage 3 is an MRAS response. The MRAS service on the Edge Server responds to the Edge pools request, sent on behalf of the client. The response includes the password to be used and the user name to calculate message integrity for. Both the client and the Audio/Video Edge service use this password for encrypting and decrypting media traffic. The following example SIP message displays the password within the password tag. A single media relay server FQDN (Audio/Video Edge service) and a direct IP for the client to use are also provided in the MRAS response. The example list of the servers contains the external FQDNs of the Audio/Video Edge service in the environment, and the UDP and TCP ports to connect to when initiating audio or video calls. An example list of servers that are returned is shown in the following SIP message within the hostname tag. 02/09/2011|10:00:41.873 1B9C:A24 INFO :: Data Received - 208.115.110.XXX:443 (To Local Address: 192.168.1.138:54415) 1727 bytes: 02/09/2011|10:00:41.873 1B9C:A24 INFO :: SIP/2.0 200 OK ms-user-logon-data: RemoteUser Via: SIP/2.0/TLS 192.168.1.138:54415;received=69.193.68.XXX;ms-received-port=54415;msreceived-cid=4113100
Page 17
Authentication-Info: TLS-DSK qop="auth", opaque="6436AC83", srand="1AC2087B", snum="7", rspauth="bce6a22dbb2280197210fa2a30a440dbfa1e689d", targetname="FRONTEND.Contoso.com", realm="SIP Communications Service", version=4 FROM: "User"<sip:<userName>@contoso.com>;tag=6adfd24c1b;epid=92a17ee2ce TO: <sip:edgeinternalfqdn.contoso.com@contoso.com;gruu;opaque=srvr:MRAS:v6H_IuZa1irVldx3Z_CdgAA>;tag=109dbc90a0 CSEQ: 1 SERVICE CALL-ID: 0ba8a0c30bf74534a7d94a182b4d72f8 CONTENT-LENGTH: 973 CONTENT-TYPE: application/msrtc-media-relay-auth+xml SERVER: RTCC/4.0.0.0 MRAS/2.0 <?xml version="1.0"?> <response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" requestID="128326152" version="2.0" serverVersion="2.0" to="sip:edgeinternalfqdn.contoso.com@contoso.com;gruu;opaque=srvr:MRAS:v6H_IuZa1irVldx3Z_CdgAA" from="sip:<userName>@contoso.com" reasonPhrase="OK" xmlns="http://schemas.microsoft.com/2006/09/sip/mrasp"> <credentialsResponse credentialsRequestID="128326152"> <credentials> <userName>AgAAJEqlo9QBy8itWiOmR2d4zw8ZJqfwTPDagP7i95AAAAAAbdyNu23CueVPKAj FdxLksF0ihSk=</userName> <password>eulmSPLxOMZZAYZvkq78HBo2uSk=</password> <duration>480</duration> </credentials> <mediaRelayList> <mediaRelay> <location>internet</location> <hostName>AVEDGEEXTERNAL.contoso.com</hostName> <udpPort>3478</udpPort> <tcpPort>443</tcpPort> </mediaRelay> </mediaRelayList> </credentialsResponse> </response> 02/09/2011|10:00:41.873 1B9C:A24 INFO :: End of Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:54415) 1727 bytes
4 MRAS RESPONSE to user

The pool sends the MRAS response information to the client by sending a SIP 200 OK message through the Access Edge service.
Page 18
Enterprise Voice
This section provides details about call flows and the diagnostics codes for each Enterprise Voice scenario that was described earlier in this chapter. These scenarios include peer-topeer calls, remote-user-to-PSTN gateway calls, and remote-user-to-federated-user calls.
Remote User to the PSTN Gateway

Call Flow
When a remote user initiates a call to the PSTN gateway, their Lync 2010 signaling (SIP traffic) traverses the Edge Server to the Director (if one is deployed), to the users Front End pool to the Mediation Server, and then finally to the PSTN gateway. In the case of the media, the remote users Lync 2010 media traverses the Edge Server to the Mediation Server before it reaches the PSTN gateway/Session Border Controller (SBC) as shown in Figure 3.
Figure 3. Remote user to PSTN gateway call flow
The following numbered headings describe the remote user to PSTN gateway call flow sequence that is shown in Figure 3. The heading numbers correspond to the sequence numbers (connectors) in Figure 3 (sequence 4 has been omitted). The MRAS credential process must be successfully completed before a remote user can initiate a call. For detailed MRAS information, see the beginning of this chapter. Briefly, MRAS credentials contain Audio/Video Edge service information, including encryption passwords, and the server FQDN and STUN ports to connect to. Assuming the user has
Page 19
completed the MRAS credential process, it first makes a STUN request to the Audio/Video Edge service to allocate ports for the call before sending the SIP INVITE. This initial SIP trace (shown in Figure 4) outlines the allocation request from the client to the Edge Server.
Figure 4. Initial SIP trace
This initial transmission from the client to the server contains UserName. The Edge Server stores this Username for future credential matches. Because the initial allocation request didnt contain a Message-Integrity attribute, the Edge Server responds with an allocate error response. This is normal; its the way to prove physical connectivity between the client and the server. The Message-Integrity attribute is used by the server and client when relaying media traffic as an authentication method for decrypting the media. The Message-Integrity attribute is an MD5 hash of the UserName and password credentials. They were provided by the MRAS service that was running on the Edge Server to the client upon sign-in during the clients initial MRAS credentials request and the Realm attribute that was provided to the client by the servers allocate response. Formatting of the Message-Integrity attribute is shown in Figure 5. Message-Integrity = MD5(username ":" realm ":" SASLPrep(password))
Figure 5. Formatting the Message-Integrity attribute
After this message is received by the client, it now has to send a proper allocate request packet to the Audio/Video Edge service that contains the Message-Integrity attribute. The credentials provided to the remote Lync 2010 client by the MRAS server in the initial request through the Access Edge service are valid for 480 minutes by default (this duration can be configured). If the A/V session lasts for 480 minutes, the credentials are updated and the new credentials are passed to Lync 2010 through the SIP channel. Figure 6 shows the subsequent STUN allocation request from Lync 2010. The SIP message, also shown in Figure 6, shows the client sending a new allocate request with the newly created Message-Integrity attribute.
Page 20
Figure 6. Client sending a new allocate request with the newly created Message-Integrity attribute
After the Message-Integrity attribute has been negotiated, the Edge Server responds to the remote client with an allocate response packet. The packet provides the remote client with the information it needs for additional STUN requests and the subsequent media stream between the remote user and the Mediation Server for a PSTN gateway session. This includes media relay addresses and port mappings for media traversal. Be aware that, as part of the STUN protocol, the MagicCookie attribute is always the first attribute in each STUN packet, and the Message-Integrity is the last attribute. The MagicCookie attribute is used to obfuscate the XORMappedAddress attribute. Figure 7 defines this attribute in more detail.
Figure 7. XORMappedAddress attribute
The server response is shown in Figure 7. The allocate response contains IP and port information of the Audio/Video Edge service that has been dynamically allocated specifically for this media stream. It also contains the following attributes: Lifetime: A default time-out of 60 seconds. Bandwidth: The decimal value equivalent to the networks default frame size. Mapped-Address: The IP address of the Audio/Video Edge service and a port that is available for the client to connect to for media traffic. XORMappedAddress: Contains the mapped-address and port values after they have been obfuscated by the client in the following ways: o If the IP address is IPv4, XOR-Address is computed by taking the mapped IP address in host BYE order, XORing it with the MagicCookie attribute, and converting the result to network BYTE order, XORing it with the concatenation of the MagicCookie attribute and the 96-bit transaction ID, and then converting the result to network BYTE order.
Page 21
X-Port is computed by taking the mapped port in host BYTE order, XORing it with the most significant 16 bits of the MagicCookie attribute, and then converting the result to network BYTE order. Some NAT devices have been found to rewrite binary encoded IP addresses and ports that are present in protocol payloads. This behavior interferes with the operation of STUN. By providing the mapped address in an obfuscated form, STUN can continue to operate through these devices that use Deep Packet Inspection.
The XORMappedAddress attribute also contains Port and IP values that represent the reflexive IP address and port combination on the client. This address is best defined as the IP address of the client or the IP address of the closest NAT address to the Audio/Video Edge service that the STUN/TURN allocate request packet from the client has passed through. Because this is included, the Lync 2010 client has the absolute IP address of the Audio/Video Edge service, and the IP address of the closest NAT IP address to the Audio/Video Edge service.
1 SIP INVITE
Now that the client has the IP and port information of the Audio/Video Edge service, it sends a SIP INVITE to the Access Edge service to initiate the call. The following SIP trace shows the process of the client sending the initial SIP INVITE. The trace has been shortened to include only relevant information. Important information is highlighted in the following trace. The TO: field shows the PSTN gateway destination number that is being called. This number is normalized by the Lync 2010 client. This SIP request is initially forwarded by the Access Edge service to the Front End pool for routing purposes. Next, there are two sets of candidate information shown as a=candidate fields. This is part of the ICE protocol, the protocol that allows external clients to use NAT traversal for media connectivity. For details about the ICE protocol, see the ICE Protocol section earlier in the chapter. In Lync 2010, two sets of ICE protocol information are sent, one for ICE protocol version 6 (for backward-compatibility) and one for ICE protocol version 19. The ICE protocol candidates show local IP addresses, reflexive addresses (the closest NAT address to the Audio/Video Edge service) in addition to relay IP addresses (the Audio/Video Edge service interface). These addresses are shown with pairs of TCP and UDP ports. These addresses are tried in order to test media connectivity between the Audio/Video Edge service and the Lync 2010 client on these ports. After connectivity succeeds, the candidate list is negotiated to a single IP address for each endpoint (in this scenario, server and client). This process is outlined in a trace later in this chapter. For reference, the following trace uses these addresses: Local IP: 192.168.1.145 Reflexive IP: 69.193.68.231 Relay: 208.115.110.145
Lastly, the media codec capabilities of the client are also included. Like the IP addresses, these capabilities are provided by both the server and the client, and are then negotiated to a single codec later in the process. 02/09/2011|09:29:53.518 17F8:14CC INFO :: Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 7473 bytes:
Page 22
02/09/2011|09:29:53.518 17F8:14CC INFO :: INVITE sip: +12075550184@contoso.com;user=phone SIP/2.0 Via: SIP/2.0/TLS 192.168.1.138:49383 Max-Forwards: 70 From: <sip:<userName>@contoso.com>;tag=38849ad51a;epid=92a17ee2ce To: <sip:+12075550184@contoso.com;user=phone> Call-ID: b611ecca854b47c78b82aade563ef0d0 CSeq: 1 INVITE Contact: <sip: <userName>@contoso.com;opaque=user:epid:1dRPOJppUlGQszig4EXYgAA;gruu> Content-Disposition: session; handling=optional; ms-proxy-2007fallback v=0 o=- 0 0 IN IP4 208.115.110.145 s=session c=IN IP4 208.115.110.145 b=CT:99980 t=0 0 m=audio 56796 RTP/AVP 114 9 112 111 0 8 116 115 4 97 13 118 101 a=candidate:RVe1AuhxobPEwFDgYqBzJ8nl5vntofS4rnotr5E8Z1U 1 p6ws7wYJioXkgVwF0sQzyw UDP 0.830 192.168.1.145 2002 a=candidate:RVe1AuhxobPEwFDgYqBzJ8nl5vntofS4rnotr5E8Z1U 2 p6ws7wYJioXkgVwF0sQzyw UDP 0.830 192.168.1.145 2003 a=candidate:kmclxGgIOHZ5uHpiwod6Paa7GuZhvObH9645kR57fJw 1 vHMsvL8TfBDYplWUcT1Iaw TCP 0.190 208.115.110.145 51100 a=candidate:kmclxGgIOHZ5uHpiwod6Paa7GuZhvObH9645kR57fJw 2 vHMsvL8TfBDYplWUcT1Iaw TCP 0.190 208.115.110.145 51100 a=candidate:ARSbz17KVDCKJsVk1FEI8yds49P7hdS7Pz7unidpn+0 1 U8jWmquvW+usL6V4dRpPFw UDP 0.490 208.115.110.145 56796 a=candidate:ARSbz17KVDCKJsVk1FEI8yds49P7hdS7Pz7unidpn+0 2 U8jWmquvW+usL6V4dRpPFw UDP 0.490 208.115.110.145 58970 a=candidate:hX1xn5LNhrXdUYZeJBi0TMahMVdn0YhYoO4xSgJIgSc 1 n3WhQS9pjzIdzKnSwUe2eQ TCP 0.250 69.193.68.231 19114 a=candidate:hX1xn5LNhrXdUYZeJBi0TMahMVdn0YhYoO4xSgJIgSc 2 n3WhQS9pjzIdzKnSwUe2eQ TCP 0.250 69.193.68.231 19114 a=candidate:FCn6Kmwij+Fzz87HpJ27MqlofJLD2iQwjO6pK+vKvd8 1 6MH8o37XC6WebAwkJ/zqmw UDP 0.550 69.193.68.231 20176 a=candidate:FCn6Kmwij+Fzz87HpJ27MqlofJLD2iQwjO6pK+vKvd8 2 6MH8o37XC6WebAwkJ/zqmw UDP 0.550 69.193.68.231 20177 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:LdrtV/jRXmdUtT4B7q4wf0H2nnoULlwIYA3Pjesw|2^31|1:1 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Ov/D89GRsNLnGhLvmzKHBeZd4OgZaqaTsiGpGfFC|2^31|1:1 a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:EWaGm7ejfZREz2lh678C3N4EGMj7lMeWx0AFQEYA|2^31 a=maxptime:200 a=rtcp:58970 a=rtpmap:114 x-msrta/16000 a=fmtp:114 bitrate=29000 a=rtpmap:9 G722/8000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:111 SIREN/16000
Page 23
a=fmtp:111 bitrate=16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:116 AAL2-G726-32/8000 a=rtpmap:115 x-msrta/8000 a=fmtp:115 bitrate=11800 a=rtpmap:4 G723/8000 a=rtpmap:97 RED/8000 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:101 telephone-event/8000 a=ice-ufrag:o/Xc a=ice-pwd:y+C/OjaDVBa1dNY7s2qLJpW6 a=candidate:5 1 UDP 2130704383 192.168.1.145 12734 typ host a=candidate:5 2 UDP 2130703870 192.168.1.145 12735 typ host a=candidate:6 1 TCP-PASS 6556159 208.115.110.145 58943 typ relay raddr 69.193.68.231 rport 23371 a=candidate:6 2 TCP-PASS 6556158 208.115.110.145 58943 typ relay raddr 69.193.68.231 rport 23371 a=candidate:7 1 UDP 16648703 208.115.110.145 56825 typ relay raddr 69.193.68.231 rport 19204 a=candidate:7 2 UDP 16648702 208.115.110.145 54147 typ relay raddr 69.193.68.231 rport 19205 a=candidate:8 1 UDP 1694233599 69.193.68.231 19204 typ srflx raddr 192.168.1.138 rport 19204 a=candidate:8 2 UDP 1694232062 69.193.68.231 19205 typ srflx raddr 192.168.1.138 rport 19205 a=candidate:9 1 TCP-ACT 7074303 208.115.110.145 58943 typ relay raddr 69.193.68.231 rport 23371 a=candidate:9 2 TCP-ACT 7073790 208.115.110.145 58943 typ relay raddr 69.193.68.231 rport 23371 a=candidate:10 1 TCP-ACT 1684795391 69.193.68.231 23371 typ srflx raddr 192.168.1.138 rport 23371 a=candidate:10 2 TCP-ACT 1684794878 69.193.68.231 23371 typ srflx raddr 192.168.1.138 rport 23371 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:LdrtV/jRXmdUtT4B7q4wf0H2nnoULlwIYA3Pjesw|2^31|1:1 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Ov/D89GRsNLnGhLvmzKHBeZd4OgZaqaTsiGpGfFC|2^31|1:1 a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:EWaGm7ejfZREz2lh678C3N4EGMj7lMeWx0AFQEYA|2^31 a=maxptime:200 a=rtcp:54147 a=rtpmap:114 x-msrta/16000 a=fmtp:114 bitrate=29000 a=rtpmap:9 G722/8000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000
Page 24
a=rtpmap:116 AAL2-G726-32/8000 a=rtpmap:115 x-msrta/8000 a=fmtp:115 bitrate=11800 a=rtpmap:4 G723/8000 a=rtpmap:97 RED/8000 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=encryption:optional ------=_NextPart_000_0159_01CBC83B.E83D0590-02/09/2011|09:29:53.519 17F8:14CC INFO :: End of Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 7473 bytes This INVITE is processed at the Front End Server for number manipulation and routing. Each Front End Server processes incoming calls by using the configured normalization rules in the dial plan. The Front End Server also acts as a routing mechanism for PSTN gateway calls, identifying which gateway and or Mediation Server to route the outbound call to. The following packet, a SIP 101 Progress Report, shows the server identifying a route, and a next hop gateway to route the PSTN gateway call. The route being identified is highlighted. 02/09/2011|09:29:53.944 17F8:14CC INFO :: Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 824 bytes: 02/09/2011|09:29:53.944 17F8:14CC INFO :: SIP/2.0 101 Progress Report ms-user-logon-data: RemoteUser Authentication-Info: TLS-DSK qop="auth", opaque="A4F8937E", srand="AB7AAF72", snum="639", rspauth="84d3431ade0f862db4856530ffc6b95b845d5c67", targetname="frontendfqdn.contoso.com", realm="SIP Communications Service", version=4 Content-Length: 0 Via: SIP/2.0/TLS 192.168.1.138:49383;received=69.193.68.231;ms-received-port=49383;msreceived-cid=40C0A00 From: "bob"<sip:bob@contoso.com>;tag=38849ad51a;epid=92a17ee2ce To: <sip:+12075550184@contoso.com;user=phone> Call-ID: b611ecca854b47c78b82aade563ef0d0 CSeq: 1 INVITE ms-diagnostics: 12006;reason="Trying next hop";source="mediationfqdn.contoso.com";PhoneUsage="Local";PhoneRoute="ContosoAll";G ateway="192.168.5.20";appName="OutboundRouting" Server: OutboundRouting/4.0.0.0 02/09/2011|09:29:53.944 17F8:14CC INFO :: End of Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 824 bytes
2 SIP 200 OK
Now that the Front End Server has identified which Mediation Server and PSTN gateway the call must be routed to and relayed that information to the Lync 2010 client, the client must send a STUN request to bind to the Mediation Server. The same STUN allocation process (as previously outlined) for the Audio/Video Edge service is repeated for the Mediation Server. The client then receives a SIP 183 Session Progress message (as follows), which contains candidate information for the Mediation Server. This message is sent from the Mediation Server to the user through the Edge Server. 02/09/2011|09:29:54.242 17F8:14CC INFO :: Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 2993 bytes:
Page 25
02/09/2011|09:29:54.242 17F8:14CC INFO :: SIP/2.0 183 Session Progress ms-user-logon-data: RemoteUser Via: SIP/2.0/TLS 192.168.1.138:49383;received=69.193.68.231;ms-received-port=49383;msreceived-cid=40C0A00 Authentication-Info: TLS-DSK qop="auth", opaque="A4F8937E", srand="4E8E7B51", snum="640", rspauth="215e208a7b1848072d5efbd1a5876e5af38bb5df", targetname="frontendfqdn.contoso.com", realm="SIP Communications Service", version=4 FROM: "bob"<sip:bob@contoso.com>;tag=38849ad51a;epid=92a17ee2ce TO: <sip:+12075550184@contoso.com;user=phone>;tag=6ec3e129b2;epid=E79516971F CSEQ: 1 INVITE CALL-ID: b611ecca854b47c78b82aade563ef0d0 RECORD-ROUTE: <sip:mediationfqdn.contoso.com:5061;transport=tls;opaque=state:F;lr> CONTACT: <sip:mediationfqdn.contoso.com@contoso.com;gruu;opaque=srvr:MediationServer:ncplWOC7 OlG_RwF7QhCWbwAA>;isGateway CONTENT-LENGTH: 1467 SUPPORTED: replaces SUPPORTED: ms-safe-transfer SUPPORTED: ms-bypass SUPPORTED: gruu-10 CONTENT-TYPE: application/sdp ALLOW: CANCEL ALLOW: BYE ALLOW: UPDATE ALLOW: PRACK REQUIRE: 100rel SERVER: RTCC/4.0.0.0 MediationServer ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet Ms-Accepted-Content-ID: <93911717f5d94b1ca0732250ccafee98@contoso.com> Rseq: 1 Record-Route: <sip:frontendfqdn.contoso.com:5061;transport=tls;lr;received=10.0.1.62;msreceived-cid=3E75E03> Record-Route: <sip:lsaccess.contoso.com:443;transport=tls;opaque=state:Ci.R40c0a00;lr;ms-route-sig=dinrttD7wakD3Y30lzThir5VsuLRpFNL6pKASwJjjXFSfZ_MGN-iegAAA> v=0 o=- 1124 0 IN IP4 192.168.5.72 s=session c=IN IP4 192.168.5.72 b=CT:4294967 t=0 0 m=audio 57340 RTP/SAVP 0 8 115 13 118 97 101 c=IN IP4 192.168.5.72 a=rtcp:57341 a=ice-ufrag:g+yd a=ice-pwd:E5nNQP4RVbs5PLi/kfPEk6iq a=candidate:1 1 UDP 2130706431 192.168.5.72 57340 typ host a=candidate:1 2 UDP 2130705918 192.168.5.72 57341 typ host a=candidate:2 1 tcp-pass 6555135 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707 a=candidate:2 2 tcp-pass 6555134 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707
Page 26
a=candidate:3 1 UDP 16647679 208.115.110.145 58745 typ relay raddr 192.168.5.72 rport 56854 a=candidate:3 2 UDP 16647678 208.115.110.145 58162 typ relay raddr 192.168.5.72 rport 56855 a=candidate:4 1 tcp-act 7076863 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707 a=candidate:4 2 tcp-act 7076350 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707 a=candidate:5 1 tcp-act 1684797951 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport 51707 a=candidate:5 2 tcp-act 1684797438 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport 51707 a=label:main-audio a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:B+8cuezdQGjtYxuYMgwl+fsul/jXZ3UjDuk15eWm|2^31|1:1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:115 x-msrta/8000 a=fmtp:115 bitrate=11800 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:97 RED/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16,36 a=encryption:rejected 02/09/2011|09:29:54.242 17F8:14CC INFO :: End of Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 2993 bytes

In this case, 192.168.5.72 is the IP address of the Mediation Server. The candidate information for ICE protocol connectivity to that device is shown. After ICE protocol connectivity has been tested and established, the caller hears ringing. While this is happening, the Mediation Server sends an INVITE and an outbound call through the PSTN gateway or SIP trunking provider SBC. The SIP 180 Ringing is as follows. 02/09/2011|09:29:56.569 17F8:14CC INFO :: Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 1457 bytes: 02/09/2011|09:29:56.569 17F8:14CC INFO :: SIP/2.0 180 Ringing ms-user-logon-data: RemoteUser Via: SIP/2.0/TLS 192.168.1.138:49383;received=69.193.68.231;ms-received-port=49383;msreceived-cid=40C0A00 Authentication-Info: TLS-DSK qop="auth", opaque="A4F8937E", srand="56EC18EC", snum="643", rspauth="5e7437268b36259f1831c588cce6e05bff5ea97c", targetname="frontendfqdn.contoso.com", realm="SIP Communications Service", version=4 FROM: "bob"<sip:bob@contoso.com>;tag=38849ad51a;epid=92a17ee2ce TO: <sip:+12075550184@contoso.com;user=phone>;tag=6ec3e129b2;epid=E79516971F CSEQ: 1 INVITE CALL-ID: b611ecca854b47c78b82aade563ef0d0 RECORD-ROUTE: <sip:mediationfqdn. contoso.com:5061;transport=tls;opaque=state:F;lr> CONTACT: <sip:mediationFQDN. contoso.com@contoso.com;gruu;opaque=srvr:MediationServer:ncplWOC7OlG_RwF7QhCWbwA A>;isGateway CONTENT-LENGTH: 0
Page 27
SUPPORTED: replaces SUPPORTED: ms-safe-transfer SUPPORTED: ms-bypass SUPPORTED: gruu-10 ALLOW: CANCEL ALLOW: BYE ALLOW: UPDATE ALLOW: PRACK SERVER: RTCC/4.0.0.0 MediationServer ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet Ms-Accepted-Content-ID: <93911717f5d94b1ca0732250ccafee98@contoso.com> Record-Route: <sip:frontendfqdn. contoso.com:5061;transport=tls;lr;received=10.0.1.62;ms-received-cid=3E75E03> Record-Route: <sip:accessedgefqdn.contoso.com:443;transport=tls;opaque=state:Ci.R40c0a00;lr;ms-routesig=dinr-ttD7wakD3Y30lzThir5VsuLRpFNL6pKASwJjjXFSfZ_MGN-iegAAA> 02/09/2011|09:29:56.569 17F8:14CC INFO :: End of Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 1457 bytes
5 SIP 200 OK
When the PSTN gateway user answers, a SIP 200 OK will be sent to the remote Lync 2010 client to signal that the call was answered as shown in the following trace. 02/09/2011|09:30:02.421 17F8:14CC INFO :: Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 3753 bytes: 02/09/2011|09:30:02.421 17F8:14CC INFO :: SIP/2.0 200 OK ms-user-logon-data: RemoteUser Via: SIP/2.0/TLS 192.168.1.138:49383;received=69.193.68.231;ms-received-port=49383;msreceived-cid=40C0A00 Authentication-Info: TLS-DSK qop="auth", opaque="A4F8937E", srand="1DFEB414", snum="645", rspauth="f145049956f1192fd3826215733b72b0c59e2ce9", targetname="frontendFQDN. contoso.com", realm="SIP Communications Service", version=4 FROM: "bob"<sip:bob@contoso.com>;tag=38849ad51a;epid=92a17ee2ce TO: <sip:+12075550184@contoso.com;user=phone>;tag=6ec3e129b2;epid=E79516971F CSEQ: 1 INVITE CALL-ID: b611ecca854b47c78b82aade563ef0d0 RECORD-ROUTE: <sip:mediationFQDN. contoso.com:5061;transport=tls;opaque=state:F;lr> CONTACT: <sip:mediationFQDN.contoso.com@contoso.com;gruu;opaque=srvr:MediationServer:ncplWOC 7OlG_RwF7QhCWbwAA;grid=c10e6dbff3374014a10d91ac8c1a5f74>;isGateway CONTENT-LENGTH: 1467 SUPPORTED: replaces SUPPORTED: ms-safe-transfer SUPPORTED: ms-bypass SUPPORTED: ms-dialog-route-set-update SUPPORTED: gruu-10 SUPPORTED: timer SUPPORTED: 100rel CONTENT-TYPE: application/sdp ALLOW: ACK P-ASSERTED-IDENTITY: <sip:+12075550184@contoso.com;user=phone>
Page 28
SERVER: RTCC/4.0.0.0 MediationServer ms-diagnostics: 10032;source="mediationfqdn.contoso.com";reason="Media diagnostic information";component="MediationServer";ICEWarningFlags="Audio:ICEWarn=0x0,LocalSite =192.168.5.72:51707,LocalMR=208.115.110.145:54945,RemoteSite=69.193.68.231:23371,R emoteMR=208.115.110.145:58943,PortRange=49152:57500,LocalMRTCPPort=54945,Remote MRTCPPort=58943,LocalLocation=2,RemoteLocation=1,FederationType=0" ms-diagnostics-public: 10032;reason="Media diagnostic information";component="MediationServer" ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet Ms-Accepted-Content-ID: <93911717f5d94b1ca0732250ccafee98@contoso.com> ms-trunking-peer: 192.168.5.20;User-Agent="PBX-IP Media Gateway/2.1" Allow: CANCEL,BYE,INVITE,REFER,NOTIFY,PRACK,UPDATE Session-Expires: 1800;refresher=uas Min-SE: 90 Record-Route: <sip:frontendfqdn.contoso.com:5061;transport=tls;lr;received=10.0.1.62;msreceived-cid=3E75E03> Record-Route: <sip:lsaccess.contoso.com:443;transport=tls;opaque=state:Ci.R40c0a00;lr;ms-routesig=disYX_oExRQx9zUmbKTE5wbJDc2_CYqYBYbcARGdgVNKCfZ_MGN-iegAAA> v=0 o=- 1124 0 IN IP4 192.168.5.72 s=session c=IN IP4 192.168.5.72 b=CT:4294967 t=0 0 m=audio 57340 RTP/SAVP 0 8 115 13 118 97 101 c=IN IP4 192.168.5.72 a=rtcp:57341 a=ice-ufrag:g+yd a=ice-pwd:E5nNQP4RVbs5PLi/kfPEk6iq a=candidate:1 1 UDP 2130706431 192.168.5.72 57340 typ host a=candidate:1 2 UDP 2130705918 192.168.5.72 57341 typ host a=candidate:2 1 tcp-pass 6555135 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707 a=candidate:2 2 tcp-pass 6555134 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707 a=candidate:3 1 UDP 16647679 208.115.110.145 58745 typ relay raddr 192.168.5.72 rport 56854 a=candidate:3 2 UDP 16647678 208.115.110.145 58162 typ relay raddr 192.168.5.72 rport 56855 a=candidate:4 1 tcp-act 7076863 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707 a=candidate:4 2 tcp-act 7076350 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport 51707 a=candidate:5 1 tcp-act 1684797951 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport 51707 a=candidate:5 2 tcp-act 1684797438 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport 51707 a=label:main-audio a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:B+8cuezdQGjtYxuYMgwl+fsul/jXZ3UjDuk15eWm|2^31|1:1 a=rtpmap:0 PCMU/8000
Page 29
a=rtpmap:8 PCMA/8000 a=rtpmap:115 x-msrta/8000 a=fmtp:115 bitrate=11800 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:97 RED/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16,36 a=encryption:rejected 02/09/2011|09:30:02.421 17F8:14CC INFO :: End of Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 3753 bytes
6 Media
At this point, the PSTN gateway endpoint and the external user have media connectivity. An important message to highlight is ICEWarningFlags. This packet contains very valuable diagnostics information in the ms-diagnostics section of the SIP message. In this case, the call is successful and there are no issues, as indicated by the 0x0 ICEWarn flag. However, if there were connectivity issues, they would be specified in the ms-diagnostics section of the SIP message. The ms-diagnostics information has been extracted as follows. ms-diagnostics: 10032;source="mediationfqdn.contoso.com";reason="Media diagnostic information";component="MediationServer";ICEWarningFlags="Audio:ICEWarn=0x0,LocalSite =192.168.5.72:51707,LocalMR=208.115.110.145:54945,RemoteSite=69.193.68.231:23371,R emoteMR=208.115.110.145:58943,PortRange=49152:57500,LocalMRTCPPort=54945,Remote MRTCPPort=58943,LocalLocation=2,RemoteLocation=1,FederationType=0" If the ICEWarningFlags attribute has any warnings other than 0x0, you can use Table 2 to identify the cause of any connectivity issues. To confirm that the Lync 2010 client is aware that the call was answered from the PSTN gateway endpoint, it sends a SIP ACK to the Mediation Server through the Edge Server and the Front End Server. The ACK message and the route that this packet has taken is highlighted in the following packet. For every SIP proxy that the packet routes through (Front End Server, Director, Access Edge service) a Route: entry is created. MEDIATIONFQDN 02/09/2011|09:30:02.540 17F8:14CC INFO :: Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 1069 bytes: 02/09/2011|09:30:02.540 17F8:14CC INFO :: ACK sip:mediationfqdn.contoso.com@contoso.com;gruu;opaque=srvr:MediationServer:ncplWOC7O lG_RwF7QhCWbwAA;grid=c10e6dbff3374014a10d91ac8c1a5f74 SIP/2.0 Via: SIP/2.0/TLS 192.168.1.138:49383 Max-Forwards: 70 From: <sip:bob@contoso.com>;tag=38849ad51a;epid=92a17ee2ce To: <sip:+12075550184@contoso.com;user=phone>;tag=6ec3e129b2;epid=E79516971F Call-ID: b611ecca854b47c78b82aade563ef0d0 CSeq: 1 ACK Route: <sip:lsaccess.contoso.com:443;transport=tls;opaque=state:Ci.R40c0a00;lr;ms-routesig=disYX_oExRQx9zUmbKTE5wbJDc2_CYqYBYbcARGdgVNKCfZ_MGN-iegAAA> Route: <sip:frontendfqdn.contoso.com:5061;transport=tls;lr;received=10.0.1.62;ms-receivedcid=3E75E03> Route: <sip:frontendfqdn2.contoso.com:5061;transport=tls;opaque=state:F;lr> User-Agent: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010)
Page 30
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="A4F8937E", targetname="frontendfqdn.contoso.com", crand="a89d0874", cnum="630", response="9ec4f5ff45810d4359598a6555cee958e7b2e2bc" Content-Length: 0 02/09/2011|09:30:02.540 17F8:14CC INFO :: End of Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 1069 bytes When the remote Lync 2010 user disconnects the call, the remote Lync 2010 client initiates a BYE message. A trace of the SIP BYE message is as follows. The ms-client-diagnostics is highlighted to show that it was initiated by the user. 02/09/2011|09:30:06.395 17F8:14CC INFO :: Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 1134 bytes: 02/09/2011|09:30:06.395 17F8:14CC INFO :: BYE sip:mediationfqdn.contoso.com@contoso.com;gruu;opaque=srvr:MediationServer:n cplWOC7OlG_RwF7QhCWbwAA;grid=c10e6dbff3374014a10d91ac8c1a5f74 SIP/2.0 Via: SIP/2.0/TLS 192.168.1.138:49383 Max-Forwards: 70 From: <sip:bob@contoso.com>;tag=38849ad51a;epid=92a17ee2ce To: <sip:+12075550184@contoso.com;user=phone>;tag=6ec3e129b2;epid=E79516971F Call-ID: b611ecca854b47c78b82aade563ef0d0 CSeq: 3 BYE Route: <sip:lsaccess.contoso.com:443;transport=tls;opaque=state:Ci.R40c0a00;lr;ms-routesig=disYX_oExRQx9zUmbKTE5wbJDc2_CYqYBYbcARGdgVNKCfZ_MGN-iegAAA> Route: <sip:FRONTENDFQDN.contoso.com:5061;transport=tls;lr;received=10.0.1.62;msreceived-cid=3E75E03> Route: <sip:MEDIATIONFQDN.contoso.com:5061;transport=tls;opaque=state:F;lr> User-Agent: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010) Ms-client-diagnostics: 51004; reason="Action initiated by user" Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="A4F8937E", targetname="frontendfqdn.contoso.com", crand="29ce3c94", cnum="633", response="65d084c1d2b099921b219e921244a81a20dcb017" Content-Length: 0 02/09/2011|09:30:06.395 17F8:14CC INFO :: End of Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 1134 bytes If a Monitoring Server is associated with the users Front End pool to capture call information, a service message is sent by the Mediation Server and the remote Lync 2010 client. This message contains all quality and call detail recording (CDR) data to the Front End Server. It then sends this information to the Monitoring Server through the Microsoft Message Queuing (MSMQ) Service. The SERVICE information is highlighted in the following report. If you are familiar with Lync Server monitoring reports, you will notice this is a plain text version of the information that is included in the Monitoring Server reports. This data is consumed by the Monitoring Server and becomes a record in the Lync Monitoring Database and the Lync CDR Database. 02/09/2011|09:30:06.627 17F8:14CC INFO :: Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 5769 bytes: 02/09/2011|09:30:06.627 17F8:14CC INFO :: SERVICE sip:mediationfqdn.contoso.com@contoso.com;gruu;opaque=srvr:HomeServer:i8hSA SSjHFe4rJJ6SMmzzAAA SIP/2.0 Via: SIP/2.0/TLS 192.168.1.138:49383 Max-Forwards: 70
Page 31
From: <sip:bob@contoso.com>;tag=c8c8d1f7c6;epid=92a17ee2ce To: <sip:mediationfqdn.contoso.com@contoso.com;gruu;opaque=srvr:HomeServer:i8hSASSjHFe4 rJJ6SMmzzAAA> Call-ID: 373cabd122e54082a9b751c129e013d7 CSeq: 1 SERVICE Contact: <sip:bob@contoso.com;opaque=user:epid:1dRPOJppUlG-Qszig4EXYgAA;gruu> User-Agent: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010) Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="A4F8937E", targetname="frontendfqdn.contoso.com", crand="234f1828", cnum="634", response="6a17615d81fd5de70c7c0939a6d37fe1dfa0364b" Content-Type: application/vq-rtcpxr+xml Content-Length: 4921 <?xml version="1.0"?> <VQReportEvent xmlns="ms-rtcp-metrics" xmlns:v2="ms-rtcp-metrics.v2" v2:SchemaVersion="2.0"><VQSessionReport SessionId="b611ecca854b47c78b82aade563ef0d0;from-tag=38849ad51a;totag=6ec3e129b2"><Endpoint xmlns="ms-rtcp-metrics" xmlns:v2="ms-rtcp-metrics.v2" Name="BOB-LENOVO" v2:OS="Windows 6.1.7600 SP: 0.0 Type: 1(Workstation) Suite: 00000100 Arch: x64 WOW64: True" v2:CPUName="CPU Brand GenuineIntel Family 0x6 Model 0x25 EM64T MaxFunc 0xb MaxFuncExt 0x80000008" v2:CPUNumberOfCores="2" v2:CPUProcessorSpeed="2660" v2:VirtualizationFlag="0"/><DialogInfo CallId="b611ecca854b47c78b82aade563ef0d0" FromTag="38849ad51a" ToTag="6ec3e129b2" Start="2011-02-09T14:30:02.0541Z" End="2011-0209T14:30:06.0395Z"><FromURI>sip:bob@contoso.com</FromURI><ToURI>sip: +12075550184@contoso.com;user=phone</ToURI><Caller>true</Caller><LocalContactURI >sip:bob@contoso.com;opaque=user:epid:1dRPOJppUlGQszig4EXYgAA;gruu</LocalContactURI><RemoteContactURI>sip:mediationfqdn.contoso.com @contoso.com;gruu;opaque=srvr:MediationServer:ncplWOC7OlG_RwF7QhCWbwAA;grid=c10e 6dbff3374014a10d91ac8c1a5f74</RemoteContactURI><LocalUserAgent>UCCAPI/4.0.7577.1 08 OC/4.0.7577.108 (Microsoft Lync 2010)</LocalUserAgent><RemoteUserAgent>RTCC/4.0.0.0 MediationServer</RemoteUserAgent><v2:MediationServerBypassFlag>false</v2:MediationS erverBypassFlag><v2:TrunkingPeer>192.168.5.20</v2:TrunkingPeer><v2:Separator/><v2:R egisteredInside>false</v2:RegisteredInside></DialogInfo><MediaLine xmlns="ms-rtcpmetrics" xmlns:v2="ms-rtcp-metrics.v2" Label="main-
audio"><Description><Connectivity><Ice>FAILED</Ice><IceWarningFlags>0</Ice WarningFlags></Connectivity><Security>SRTP</Security><NetworkConnectivityInf o><NetworkConnection>wired</NetworkConnection><VPN>false</VPN><LinkSpee d>0</LinkSpeed></NetworkConnectivityInfo><LocalAddr><IPAddr>192.168.1.138< /IPAddr><Port>19204</Port><SubnetMask>255.255.255.0</SubnetMask><v2:MAC Addr></v2:MACAddr></LocalAddr><RemoteAddr><IPAddr>208.115.110.145</IPAd dr><Port>3478</Port></RemoteAddr><CaptureDev><Name>Headset Microphone (3- BUA-200M)</Name><Driver>Microsoft: 6.1.7600.16385</Driver></CaptureDev><RenderDev><Name>Headset Earphone (3- BUA-200M)</Name><Driver>Microsoft: 6.1.7600.16385</Driver></RenderDev></Description><InboundStream Id="4041492253"><Network><Jitter><InterArrival>3</InterArrival><InterArrivalMa x>3</InterArrivalMax></Jitter><PacketLoss><LossRate>0</LossRate></PacketLos s><BurstGapLoss><BurstDensity>0</BurstDensity><BurstDuration>0</BurstDurati on><GapDensity>0</GapDensity><GapDuration>180</GapDuration></BurstGapLo ss><Utilization><Packets>75</Packets></Utilization><v2:RatioConcealedSamples Microsoft Lync Server 2010 Resource Kit External User Access Page 32
Avg>0</v2:RatioConcealedSamplesAvg><v2:RatioStretchedSamplesAvg>0</v2:Rati oStretchedSamplesAvg><v2:RatioCompressedSamplesAvg>0</v2:RatioCompressed SamplesAvg></Network><Payload><Audio><PayloadType>0</PayloadType><Payl oadDescription>PCMU</PayloadDescription><SampleRate>8000</SampleRate><Si gnal><NoiseLevel>83</NoiseLevel><v2:InitialSignalLevelRMS>1.239027</v2:InitialSignalLevelRMS></ Signal></Audio></Payload></InboundStream><OutboundStream

Id="2727253595"><Network><Jitter><InterArrival>2</InterArrival><InterArrivalMax>3</In terArrivalMax></Jitter><PacketLoss><LossRate>0</LossRate></PacketLoss><Delay><Rou ndTrip>123</RoundTrip><RoundTripMax>132</RoundTripMax></Delay><Utilization><Pac kets>61</Packets></Utilization></Network><Payload><Audio><PayloadType>0</Payload Type><PayloadDescription>PCMU</PayloadDescription><SampleRate>8000</SampleRate> <Signal><NoiseLevel>64</NoiseLevel></Signal><v2:AudioFECUsed>false</v2:AudioFECUsed></Audio></Payload ></OutboundStream><v2:AppliedBandwidthLimit>150800</v2:AppliedBandwidthLimit><v2: AppliedBandwidthSource>StaticMax</v2:AppliedBandwidthSource><v2:LocalClientEvent><v 2:NetworkSendQualityEventRatio>0</v2:NetworkSendQualityEventRatio><v2:NetworkReceiv eQualityEventRatio>0</v2:NetworkReceiveQualityEventRatio><v2:NetworkDelayEventRatio> 0</v2:NetworkDelayEventRatio><v2:NetworkBandwidthLowEventRatio>0</v2:NetworkBand widthLowEventRatio><v2:CPUInsufficientEventRatio>0</v2:CPUInsufficientEventRatio><v2:D eviceHalfDuplexAECEventRatio>0</v2:DeviceHalfDuplexAECEventRatio><v2:DeviceRenderN otFunctioningEventRatio>0</v2:DeviceRenderNotFunctioningEventRatio><v2:DeviceCapture NotFunctioningEventRatio>0</v2:DeviceCaptureNotFunctioningEventRatio><v2:DeviceGlitch esEventRatio>0</v2:DeviceGlitchesEventRatio><v2:DeviceLowSNREventRatio>0</v2:Device LowSNREventRatio><v2:DeviceLowSpeechLevelEventRatio>0</v2:DeviceLowSpeechLevelEv entRatio><v2:DeviceClippingEventRatio>0</v2:DeviceClippingEventRatio><v2:DeviceEchoE ventRatio>0</v2:DeviceEchoEventRatio><v2:DeviceNearEndToEchoRatioEventRatio>0</v2: DeviceNearEndToEchoRatioEventRatio><v2:DeviceMultipleEndpointsEventCount>0</v2:Devi ceMultipleEndpointsEventCount><v2:DeviceHowlingEventCount>0</v2:DeviceHowlingEventC ount></v2:LocalClientEvent></MediaLine></VQSessionReport></VQReportEvent> 02/09/2011|09:30:06.627 17F8:14CC INFO :: End of Sending Packet - 208.115.110.143:443 (From Local Address: 192.168.1.138:49383) 5769 bytes The call ends with a 200 OK message from the Mediation Server, acknowledging that the user ended the call. 02/09/2011|09:30:06.804 17F8:14CC INFO :: Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 691 bytes: 02/09/2011|09:30:06.804 17F8:14CC INFO :: SIP/2.0 200 OK ms-user-logon-data: RemoteUser Via: SIP/2.0/TLS 192.168.1.138:49383;received=69.193.68.231;ms-received-port=49383;msreceived-cid=40C0A00 Authentication-Info: TLS-DSK qop="auth", opaque="A4F8937E", srand="72FBFA69", snum="649", rspauth="1e7cac4153493579083d98545f112421b8713fbd", targetname="frontendfqdn.contoso.com", realm="SIP Communications Service", version=4 FROM: <sip:bob@contoso.com>;tag=38849ad51a;epid=92a17ee2ce TO: <sip:+12075550184@contoso.com;user=phone>;tag=6ec3e129b2;epid=E79516971F CSEQ: 3 BYE CALL-ID: b611ecca854b47c78b82aade563ef0d0 CONTENT-LENGTH: 0 SUPPORTED: ms-dialog-route-set-update SERVER: RTCC/4.0.0.0 MediationServer
Page 33
02/09/2011|09:30:06.804 17F8:14CC INFO :: End of Data Received - 208.115.110.143:443 (To Local Address: 192.168.1.138:49383) 691 bytes
Remote User to a Federated User

Call Flow
When a user makes a call to a federated Lync user, the key difference in call flow is that communications will be proxied between the two federated companys Audio/Video Edge services. As a result, port negotiations must occur on each client in addition to each Audio/Video Edge service. Figure 8 shows the call flow for this scenario.
Figure 8. Remote user to federated user call flow
The following numbered headings describe the remote user to federated call flow sequence that is shown in Figure 8. The heading numbers correspond to the sequence numbers (connectors) in Figure 8. Because much of the technical details of the federated call flow is the same as the PSTN gateway and peer-to-peer call flows, only the differences are covered in this section. The key difference here is that there are STUN binding requests between the two Edge Servers. First, lets review what is happening on the client side during the call process.
1 SIP INVITE
The callee receives a SIP INVITE that contains call information and ICE protocol candidates to start the process. The candidate information sent in the initial INVITE is as follows. m=audio 1046 RTP/AVP 114 9 112 111 0 8 116 115 4 97 13 118 101 a=ice-ufrag:9WAX a=ice-pwd:3y87i/FZPvglzRHCQqa7rTHq
Page 34
a=candidate:1 1 UDP 2130706431 192.168.16.68 1046 typ host a=candidate:1 2 UDP 2130705918 192.168.16.68 1047 typ host a=candidate:2 1 UDP 2130705919 192.168.56.1 29300 typ host a=candidate:2 2 UDP 2130705406 192.168.56.1 29301 typ host a=candidate:3 1 UDP 2130705407 192.168.2.58 28376 typ host a=candidate:3 2 UDP 2130704894 192.168.2.58 28377 typ host a=candidate:4 1 TCP-PASS 6556159 97.75.78.122 53946 typ relay raddr 192.168.16.68 rport 21890 a=candidate:4 2 TCP-PASS 6556158 97.75.78.122 53946 typ relay raddr 192.168.16.68 rport 21890 a=candidate:5 1 UDP 16648703 97.75.78.122 54499 typ relay raddr 192.168.16.68 rport 28180 a=candidate:5 2 UDP 16648702 97.75.78.122 50178 typ relay raddr 192.168.16.68 rport 28181 a=candidate:6 1 TCP-ACT 7075839 97.75.78.122 53946 typ relay raddr 192.168.16.68 rport 21890 a=candidate:6 2 TCP-ACT 7075326 97.75.78.122 53946 typ relay raddr 192.168.16.68 rport 21890 a=candidate:7 1 TCP-ACT 1684796927 192.168.16.68 21890 typ srflx raddr 192.168.16.68 rport 21890 a=candidate:7 2 TCP-ACT 1684796414 192.168.16.68 21890 typ srflx raddr 192.168.16.68 rport 21890 Highlighted and in bold is the callers Audio/Video Edge service relay address that is being sent to the callee.
2 SIP 200 OK
The callee (the person receiving the call) now sends a SIP 183 SESSION PROGRESS message that contains call information and ICE protocol candidates for the client. The candidate information sent in the SESSION PROGRESS as follows. m=audio 56517 RTP/SAVP 114 9 112 111 0 8 116 115 4 97 13 118 101 a=ice-ufrag:RJbR a=ice-pwd:nDrU+gd7LRlA47nauEOhY+PG a=candidate:1 1 UDP 2130706431 192.168.23.1 30590 typ host a=candidate:1 2 UDP 2130705918 192.168.23.1 30591 typ host a=candidate:2 1 UDP 2130705919 192.168.52.254 18266 typ host a=candidate:2 2 UDP 2130705406 192.168.52.254 18267 typ host a=candidate:3 1 UDP 2130705407 192.168.38.1 20244 typ host a=candidate:3 2 UDP 2130704894 192.168.38.1 20245 typ host a=candidate:4 1 UDP 2130704895 192.168.216.1 28006 typ host a=candidate:4 2 UDP 2130704382 192.168.216.1 28007 typ host a=candidate:5 1 UDP 2130704383 192.168.1.108 28680 typ host a=candidate:5 2 UDP 2130703870 192.168.1.108 28681 typ host a=candidate:6 1 TCP-PASS 6556159 208.115.110.145 55726 typ relay raddr 69.193.68.231 rport 14824 a=candidate:6 2 TCP-PASS 6556158 208.115.110.145 55726 typ relay raddr 69.193.68.231 rport 14824 a=candidate:7 1 UDP 16648703 208.115.110.145 56517 typ relay raddr 69.193.68.231 rport 3048 a=candidate:7 2 UDP 16648702 208.115.110.145 52305 typ relay raddr 69.193.68.231 rport 3049 a=candidate:8 1 UDP 1694233599 69.193.68.231 3048 typ srflx raddr 192.168.1.108 rport 3048
Page 35
a=candidate:8 2 UDP 1694232062 69.193.68.231 3049 typ srflx raddr 192.168.1.108 rport 3049 a=candidate:9 1 TCP-ACT 7074303 208.115.110.145 55726 typ relay raddr 69.193.68.231 rport 14824 a=candidate:9 2 TCP-ACT 7073790 208.115.110.145 55726 typ relay raddr 69.193.68.231 rport 14824 a=candidate:10 1 TCP-ACT 1684795391 69.193.68.231 14824 typ srflx raddr 192.168.1.108 rport 14824 Highlighted and in bold is the callees reflexive IP address that is being sent to the caller. At this point, the STUN bind requests are sent as part of the ICE protocol connectivity checks to determine the optimal path for the call.

Priority is still given to UDP direct and UDP reflexive IP addresses for ICE protocol connectivity checks. The trace shown in Figure 9 outlines an attempt by the callers Audio/Video Edge service to connect to the callees private IP address, and then a subsequent failure.
Figure 9. Callers Edge Server attempt to connect to callees private IP address, and then failure
In Figure 10, the callers Audio/Video Edge service public IP address is 97.75.78.122. The callees private IP address is 192.168.1.108. The subsequent packet shows a failure on the attempted connection (see Code: Port Unreachable). As a result, this isnt a valid media path; the ICE protocol checks will move on (see Figure 10).
Figure 10. Packet failure
The Edge Servers communicate between themselves by using tunneled STUN/TURN messages. The STUN binding requests are encapsulated in the tunneled packets. These requests arent shown here; however, they are similar to other STUN/TURN binding requests.
Page 36
The trace in Figure 11 shows the STUN binding request that is made to the reflexive IP address of the callee, where this call ultimately was connected.
Figure 11. STUN binding request to the reflexive IP address of the callee
In the trace shown in Figure 11, the callers Audio/Video Edge service public IP address is 97.75.78.122. The callees reflexive public IP address (home router) is 69.192.68.231.
4 SIP INVITE
After the ICE protocol connectivity checks have been completed, the caller sends another SIP INVITE that contains the final candidate list. The following trace shows the updated candidate list. m=audio 54499 RTP/SAVP 114 9 112 111 0 8 116 115 4 97 13 118 101 a=ice-ufrag:9WAX a=ice-pwd:3y87i/FZPvglzRHCQqa7rTHq a=candidate:5 1 UDP 16648703 97.75.78.122 54499 typ relay raddr 192.168.16.68 rport 28180 a=candidate:5 2 UDP 16648702 97.75.78.122 50178 typ relay raddr 192.168.16.68 rport 28181 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Ueku9L1ArYtiGgr2CtXgXOZHUfCrtTY7SwiiFa3K|2^31|1:1 a=remote-candidates:1 69.193.68.231 28680 2 69.193.68.231 28681 The first candidates that are provided as a=candidate are the callers candidates for RTP and RTCP packets to be sent. The second candidate provided as a=remote-candidates is the callees negotiated IP address and port for media.
5 SIP 200 OK
In response to the SIP INVITE, the callee responds with a SIP 200 OK containing its final candidate list. This is essentially a reversed list of the candidates that were sent from the caller to confirm that media traffic flows over the designated IPs and ports (shown as follows). m=audio 28680 RTP/SAVP 114 9 112 111 0 8 116 115 4 97 13 118 101 a=ice-ufrag:RJbR a=ice-pwd:nDrU+gd7LRlA47nauEOhY+PG a=candidate:11 1 UDP 1862268671 69.193.68.231 28680 typ prflx raddr 192.168.1.108 rport 28680 a=candidate:11 2 UDP 1862268414 69.193.68.231 28681 typ prflx raddr 192.168.1.108 rport 28681 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline: +WS9epy32zB3aXLCOxk9Uiks0QWocDY/TcceMWW+|2^31|1:1
Page 37
a=remote-candidates:1 97.75.78.122 54499 2 97.75.78.122 50178
6 Media
At this point, audio is flowing between the two clients. In Figure 12, the caller is relaying media traffic through their Audio/Video Edge service. The callers Audio/Video Edge service is communicating directly with the callees reflexive public IP address (home router). When the call is complete, the party who hangs up sends a SIP BYE message; all ports will be cleaned up as shown in the following trace. 05/27/2011|10:51:17.946 2A54:2118 INFO :: Sending Packet - 208.115.110.137:443 (From Local Address: 192.168.1.108:59067) 2383 bytes: 05/27/2011|10:51:17.946 2A54:2118 INFO :: BYE sip: alice@fabrikam.com;opaque=user:epid:PTRheATWGFK-z3HXNaHc6gAA;gruu SIP/2.0 Via: SIP/2.0/TLS 192.168.1.108:59067 Max-Forwards: 70 From: "" <sip:bob@contoso.com>;epid=92a17ee2ce;tag=8c4b1f7e5c To: <sip:alice@fabrikam.com>;tag=8386183919;epid=3821b40476 Call-ID: 31112c721df3432eb7755ce1aeeddcfd CSeq: 1 BYE
Peer-to-Peer
The simplest form of a remote user Enterprise Voice call is a peer-to-peer Lync 2010 call. In this scenario, two remote Lync 2010 users initiate on a Voice over Internet Protocol (VoIP) peer-to-peer call. Because of the detail covered in the previous sections, this call flow description simply identifies the differences between the other scenarios. When two remote users communicate directly by using Lync 2010, media is likely to be sent through the reflexive IP address candidate. Referencing the beginning of the chapter, the ICE protocol will first attempt the direct IP addresses, followed by the reflexive IP addresses, and then lastly, the relay (Audio/Video Edge service) IP address. Because two remote users can almost always connect to each other through the reflexive address, media is normally sent between the reflexive IP addresses. If they cannot connect through the reflexive address, the ICE protocol continues to check this connection and eventually relay it through the Audio/Video Edge service.
Call Flow
The call flow for this scenario is straightforward because the users initiate the call by talking directly to each other. The call flow is shown in Figure 12.
Page 38
Figure 12. Peer-to-peer call flow
The following numbered headings describe the peer-to-peer call flow sequence that is shown in Figure 12. The heading numbers correspond to the sequence numbers (connectors) in Figure 12 (sequences 4 and 5 have been omitted). The following traces were taken from the caller (person initiating the call). Lets take a look at whats happening on the client side when these two users call each other and connect over their reflexive IP addresses for media.
1 SIP INVITE
First, the caller sends a SIP INVITE to the other user, which will contain all valid candidates for the call. This can be seen in the following trace. 05/31/2011|16:55:25.856 2D7C:1FF8 INFO :: Sending Packet - 208.115.110.143:443 (From Local Address: 10.180.181.223:62230) 7439 bytes: 05/31/2011|16:55:25.856 2D7C:1FF8 INFO :: INVITE sip:alice@contoso.com SIP/2.0 Via: SIP/2.0/TLS 10.180.181.223:62230 Max-Forwards: 70 From: <sip:bob@contoso.com>;tag=c4a189acf6;epid=92a17ee2ce To: <sip:alice@contoso.com> Call-ID: eb472e8ebc384c68a07b1e5beb70be38 CSeq: 1 INVITE
Page 39
In the INVITE, the user also sends the candidate list (like all other remote calls). In the following trace, the reflexive IP addresses are highlighted. m=audio 55336 RTP/AVP 114 9 112 111 0 8 116 115 4 97 13 118 101 a=ice-ufrag:6QrA a=ice-pwd:LColjpNYVTQVn6KK6Bg7D9k1 a=candidate:1 1 UDP 2130706431 192.168.52.254 33468 typ host a=candidate:1 2 UDP 2130705918 192.168.52.254 33469 typ host a=candidate:2 1 UDP 2130705919 192.168.216.1 15614 typ host a=candidate:2 2 UDP 2130705406 192.168.216.1 15615 typ host a=candidate:3 1 UDP 2130705407 192.168.23.1 31518 typ host a=candidate:3 2 UDP 2130704894 192.168.23.1 31519 typ host a=candidate:4 1 UDP 2130704895 192.168.38.1 25800 typ host a=candidate:4 2 UDP 2130704382 192.168.38.1 25801 typ host a=candidate:5 1 UDP 2130704383 10.180.181.223 25742 typ host a=candidate:5 2 UDP 2130703870 10.180.181.223 25743 typ host a=candidate:6 1 TCP-PASS 6556159 208.115.110.145 50162 typ relay raddr 166.248.0.235 rport 30907 a=candidate:6 2 TCP-PASS 6556158 208.115.110.145 50162 typ relay raddr 166.248.0.235 rport 30907 a=candidate:7 1 UDP 16648703 208.115.110.145 55336 typ relay raddr 166.248.0.235 rport 52259 a=candidate:7 2 UDP 16648702 208.115.110.145 54267 typ relay raddr 166.248.0.235 rport 52282 a=candidate:8 1 UDP 1694233599 166.248.0.235 52259 typ srflx raddr 10.180.181.223 rport 11252 a=candidate:8 2 UDP 1694232062 166.248.0.235 52282 typ srflx raddr 10.180.181.223 rport 11253 a=candidate:9 1 TCP-ACT 7074303 208.115.110.145 50162 typ relay raddr 166.248.0.235 rport 30907 a=candidate:9 2 TCP-ACT 7073790 208.115.110.145 50162 typ relay raddr 166.248.0.235 rport 30907 a=candidate:10 1 TCP-ACT 1684795391 166.248.0.235 30907 typ srflx raddr 10.180.181.223 rport 15645 a=candidate:10 2 TCP-ACT 1684794878 166.248.0.235 30907 typ srflx raddr 10.180.181.223 rport 15645
2 SIP 200 OK
The callee (the person receiving the call) responds with SIP 183 SESSION PROGRESS that contains candidate information for that user as shown in the following trace. 05/31/2011|16:55:28.485 2D7C:1FF8 INFO :: Data Received - 208.115.110.143:443 (To Local Address: 10.180.181.223:62230) 3093 bytes: 05/31/2011|16:55:28.485 2D7C:1FF8 INFO :: SIP/2.0 183 Session Progress ms-user-logon-data: RemoteUser Authentication-Info: TLS-DSK qop="auth", opaque="048E4A6C", srand="C4647BCB", snum="205", rspauth="16d18d7db00493ad9c498174a455d87a2d2e307a", targetname="LYNCFE.contoso.com", realm="SIP Communications Service", version=4 Via: SIP/2.0/TLS 10.180.181.223:62230;received=166.248.0.235;ms-receivedport=30906;ms-received-cid=73BB7D00 From: "bob"<sip:bob@contoso.com>;tag=c4a189acf6;epid=92a17ee2ce To: <sip:alice@contoso.com>;epid=73f1df72ee;tag=ed247c795f Call-ID: eb472e8ebc384c68a07b1e5beb70be38
Page 40
CSeq: 1 INVITE Record-Route: <sip:LYNCFE.contoso.com:5061;transport=tls;opaque=state:T:F;lr;received=10.0.1.62;msreceived-cid=73BB7E00> Contact: <sip:alice@contoso.com;opaque=user:epid:bEfyhOYmMVynmDXlgp2D6gAA;gruu> User-Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.280 (Microsoft Lync 2010) The 183 SESSION PROGRESS will also contain the candidates for that user as seen in the following trace. The reflexive IP address candidates are highlighted. m=audio 57501 RTP/SAVP 114 9 112 111 0 8 116 115 4 97 13 118 101 a=ice-ufrag:zuiy a=ice-pwd:GH1QYT2dK5l0YTr7NQD6I2u9 a=candidate:1 1 UDP 2130706431 10.104.72.9 14700 typ host a=candidate:1 2 UDP 2130705918 10.104.72.9 14701 typ host a=candidate:2 1 TCP-PASS 6556159 208.115.110.145 55275 typ relay raddr 75.98.19.251 rport 4523 a=candidate:2 2 TCP-PASS 6556158 208.115.110.145 55275 typ relay raddr 75.98.19.251 rport 4523 a=candidate:3 1 UDP 16648703 208.115.110.145 57501 typ relay raddr 75.98.19.251 rport 32250 a=candidate:3 2 UDP 16648702 208.115.110.145 56075 typ relay raddr 75.98.19.251 rport 32251 a=candidate:4 1 UDP 1694235647 75.98.19.251 32250 typ srflx raddr 10.104.72.9 rport 32250 a=candidate:4 2 UDP 1694234110 75.98.19.251 32251 typ srflx raddr 10.104.72.9 rport 32251 a=candidate:5 1 TCP-ACT 7076351 208.115.110.145 55275 typ relay raddr 75.98.19.251 rport 4523 a=candidate:5 2 TCP-ACT 7075838 208.115.110.145 55275 typ relay raddr 75.98.19.251 rport 4523 a=candidate:6 1 TCP-ACT 1684797439 75.98.19.251 4523 typ srflx raddr 10.104.72.9 rport 4523 a=candidate:6 2 TCP-ACT 1684796926 75.98.19.251 4523 typ srflx raddr 10.104.72.9 rport 4523

At this point, the clients start the ICE protocol connectivity checks to determine the optimal media path for audio. The following packet shows the caller who is sending a STUN binding request to the callees reflexive IP address. This is the ICE protocol connectivity check (see Figure 13).
Figure 13. STUN binding request for the callees reflexive IP address
The callee then sends a STUN binding response if the connectivity is successful. This validates the media path (see Figure 14).
Page 41
Figure 14. Callee sends a STUN binding response if connectivity is successful
6 Media
From here, the media connected between the two users. The trace in Figure 15 shows a media stream of Microsoft RTAudio speech codec passing between the two remote clients.
Figure 15. Media stream of RT audio passing between the two remote clients
As with all other call flows, media flows between the two users until a user hangs up, which results in a SIP BYE message.
Conferencing
This section describes the SIP call flows that occur when remote users join Lync 2010 conferences from outside the corporate network. For details about schedule and generating conferences, see the Conferencing and Collaboration chapter of the Microsoft Lync Server 2010 Resource Kit, http://go.microsoft.com/fwlink/?LinkId=211003. For conferences of all modalities, the initial join process is the same. Lync Server introduced simple URLs, simplifying the URL that is used to join conferences. These URLs, when configured for external participants, are published through a reverse proxy. The simple URL associated with the meeting join process is the Meet Simple URL. When a conference is generated or a scheduled conference is sent through email, the meeting join URL is shared. When a user clicks the meeting URL or types it into a web browser, it connects to the reverse proxy over HTTPS. The reverse proxy then proxies the web request to the configured Director or Front End pool. For more details on the process that the web browser uses to identify the conference to be joined, see the Conferencing and Collaboration chapter of the Microsoft Lync Server 2010 Resource Kit book, http://go.microsoft.com/fwlink/? LinkId=211003.
Application Sharing
Separate SIP requests are generated for each modality a user attempts to join. The following sections cover each of these conferencing joins after the user has clicked the simple URL.
Call Flow
When a user joins a conference with an application-sharing session, or a user wants to initiate application-sharing, the users Lync 2010 client sends a SIP INVITE to the conference URI. The SIP INVITE is then routed to the Front End pool where the user that scheduled the conference is homed as shown in Figure 16. (Obtaining those URIs is covered in depth in Conferencing and Collaboration, http://go.microsoft.com/fwlink/? LinkId=211003.)
Page 42
Figure 16. Application-sharing conference join flow
The following numbered headings describe the application-sharing sequence that is shown in Figure 16. The heading numbers correspond to the sequence numbers (connectors) in Figure 16.
1 SIP INVITE
The initial SIP INVITE to join an application sharing session is shown in the following trace. TL_INFO(TF_PROTOCOL) [0]12B8.10E0::06/01/2011-02:12:42.558.002a43d5 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record Trace-Correlation-Id: 2262276601 Instance-Id: 00122B24 Direction: incoming;source="external edge";destination="internal edge" Peer: 76.187.107.231:54385 Message-Type: request Start-Line: INVITE sip:bob@contoso.com@contoso.com;gruu;opaque=app:conf:applicationsharing:id:F ZG8SYVR SIP/2.0 From: <sip:bob@contoso.com@contoso.com>;tag=10dc873e91;epid=3821b40476 To: <sip:bob@contoso.com@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR > CSeq: 1 INVITE Call-ID: b85cd18d9e074bdf8c5448ea279651cc
Page 43
Via: SIP/2.0/TLS 192.168.5.202:54385 Max-Forwards: 70 Contact: <sip:bob@contoso.com@contoso.com;opaque=user:epid:PTRheATWGFKz3HXNaHc6gAA;gruu> User-Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.275 (Microsoft Lync 2010) Supported: ms-dialog-route-set-update Supported: timer Supported: histinfo Supported: ms-safe-transfer Supported: ms-sender Supported: ms-early-media ms-keep-alive: UAC;hop-hop=yes Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS ms-subnet: 192.168.5.0 ms-endpoint-location-data: NetworkScope;ms-media-location-type=Internet Supported: ms-conf-invite Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="70B881CC", targetname="SRLYNCFE1.Contoso.com", crand="6a3c0989", cnum="381", response="5558281d9dc2652d9e89ffb8d453b59cde75bde1" Content-Type: application/sdp Content-Length: 1826 Message-Body: v=0 o=- 0 0 IN IP4 97.75.78.122 s=session c=IN IP4 97.75.78.122 b=CT:53980 t=0 0 m=applicationsharing 57929 TCP/RTP/AVP 127 a=ice-ufrag:MakE a=ice-pwd:7iJs2rWVUD5enazDfbf9nSJm a=candidate:1 1 TCP-PASS 2120613887 192.168.56.1 5409 typ host a=candidate:1 2 TCP-PASS 2120613374 192.168.56.1 5409 typ host a=candidate:2 1 TCP-ACT 2121006591 192.168.56.1 12359 typ host a=candidate:2 2 TCP-ACT 2121006078 192.168.56.1 12359 typ host a=candidate:3 1 TCP-PASS 2120612863 192.168.5.202 20564 typ host a=candidate:3 2 TCP-PASS 2120612350 192.168.5.202 20564 typ host a=candidate:4 1 TCP-ACT 2121005567 192.168.5.202 33179 typ host a=candidate:4 2 TCP-ACT 2121005054 192.168.5.202 33179 typ host a=candidate:5 1 TCP-PASS 6556159 97.75.78.122 57929 typ relay raddr 76.187.107.231 rport 22497 a=candidate:5 2 TCP-PASS 6556158 97.75.78.122 57929 typ relay raddr 76.187.107.231 rport 22497 a=candidate:6 1 TCP-ACT 7075583 97.75.78.122 57929 typ relay raddr 76.187.107.231 rport 22497 a=candidate:6 2 TCP-ACT 7075070 97.75.78.122 57929 typ relay raddr 76.187.107.231 rport 22497 a=candidate:7 1 TCP-ACT 1684796671 76.187.107.231 22497 typ srflx raddr 192.168.5.202 rport 22497 a=candidate:7 2 TCP-ACT 1684796158 76.187.107.231 22497 typ srflx raddr 192.168.5.202 rport 22497 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:V3t/5o7extwaXiGLPWyLIAWE/6fBnquKSSVxNTJ3|2^31|1:1
Page 44
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:0sGb8VadPu7yiaGeye54b72ffI3d5sINGMZRZKj3|2^31|1:1 a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:AsNRlY/nyhf6xyPhXsG0u4VB16VWAWS5islTMWeS|2^31 a=setup:active a=connection:new a=rtcp:57929 a=mid:1 a=rtpmap:127 x-data/90000 a=x-applicationsharing-session-id:1 a=x-applicationsharing-role:sharer a=x-applicationsharing-media-type:rdp a=x-capabilities:request-control="sendrecv" $$end_record The following sections are highlighted in the previous SIP message: The SIP URI in the TO: field matches the SIP URI in the FROM: field. The application sharing GRUU is included in the TO: field of the SIP INVITE. This is the initial INVITE to the focus for the conference join. The candidate list and additional information about the application-sharing session are highlighted. The set of IP addresses is the list of the ICE protocol candidates that the application-sharing server (Front End Server) can use to connect the user to the conference. This is part of the ICE protocol negotiation as described earlier in the ICE Protocol section of this chapter. The Edge Server relays this INVITE to the Front End pool where the application-sharing conference is hosted. The final highlighted section shows information about the application-sharing session, including the role of the user and the media type (Remote Desktop Protocol (RDP) or Persistent Shared Object Model (PSOM)).
2 SIP 200 OK
The Lync Front End Server responds with a SIP 200 OK, which is proxied through the Edge Server to the remote user. An example of a SIP 200 OK is as follows. TL_INFO(TF_PROTOCOL) [0]12B8.10E0::06/01/2011-02:12:42.968.002a5ed3 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record Trace-Correlation-Id: 856670062 Instance-Id: 00122B27 Direction: outgoing;source="internal edge";destination="external edge" Peer: 76.187.107.231:54385 Message-Type: response Start-Line: SIP/2.0 200 OK From: "bob"<sip:bob@contoso.com@contoso.com>;tag=10dc873e91;epid=3821b40476 To: <sip:bob@contoso.com@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR >;tag=f85b1659e9;epid=02F0FEEFCD CSeq: 1 INVITE Call-ID: b85cd18d9e074bdf8c5448ea279651cc ms-user-logon-data: RemoteUser
Page 45
Via: SIP/2.0/TLS 192.168.5.202:54385;received=76.187.107.231;ms-receivedport=54385;ms-received-cid=C56000 Authentication-Info: TLS-DSK qop="auth", opaque="70B881CC", srand="D00174F8", snum="305", rspauth="ab38d12d256a0a6a3e0e5a420fe5a6183deaa41f", targetname="SRLYNCFE1.Contoso.com", realm="SIP Communications Service", version=4 RECORD-ROUTE: <sip:pool1.contoso.com:5061;transport=tls;msfe=SRLYNCFE1.Contoso.com;opaque=state:T:Tc.YJV-vB_Ez1mgzTXyuB-xHckT:F:Fc.YJVvB_Ez1mgzTXyuB-xHckT:Eu;lr;received=192.168.32.102;ms-received-cid=B9F302> CONTACT: <sip:bob@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR>;isFocus;text ;audio;video;image;applicationsharing CONTENT-LENGTH: 1163 PRIORITY: Normal SUPPORTED: ms-dialog-route-set-update SUPPORTED: gruu-10 SUPPORTED: timer SUPPORTED: 100rel CONTENT-TYPE: application/sdp ALLOW: ACK P-ASSERTED-IDENTITY: <sip:bob@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR> SERVER: RTCC/4.0.0.0 applicationsharing Content-ID: eb81521c-a083-4ae5-b83a-00cc83e42b4e Ms-Conversation-ID: 81f325e91f424bbca3cb52198b9e9133 ms-diagnostics-public: 21009;reason="Media stack diagnostics info";CalleeMediaDebug="applicationsharing:ICEWarn=0x0,LocalSite=192.168.32.102:63731, LocalMR=97.75.78.122:52262,PortRange=49152:65535,LocalMRTCPPort=52262,LocalLocatio n=0,RemoteLocation=0,FederationType=0" ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet Allow: CANCEL,BYE,INVITE,MESSAGE,INFO,SERVICE,OPTIONS,BENOTIFY,NOTIFY,PRACK,UPDATE Session-Expires: 600;refresher=uas Min-SE: 90 Record-Route: <sip:access.contoso.com:443;transport=tls;opaque=state:Ci.Rc56000;lr;msroute-sig=bl4IlS52rOtgRa6CDZxpLNkdNFWmzGlB0qhP_PMYNO38EcRWYxcrEe0gAA> Message-Body: v=0 o=- 273 0 IN IP4 192.168.32.102 s=session c=IN IP4 192.168.32.102 b=CT:4294967 t=0 0 m=applicationsharing 52262 TCP/RTP/SAVP 127 c=IN IP4 97.75.78.122 a=x-applicationsharing-role:viewer a=x-capabilities a=x-applicationsharing-session-id:1 a=x-applicationsharing-media-type:rdp a=rtcp:52262 a=connection:new a=setup:active a=ice-ufrag:NIrR a=ice-pwd:KdRCdSSBXiGuG7ZHkFN0bpZx
Page 46
a=candidate:1 1 tcp-pass 2120613887 192.168.32.102 63731 typ host a=candidate:1 2 tcp-pass 2120613374 192.168.32.102 63731 typ host a=candidate:2 1 tcp-act 2121006591 192.168.32.102 61162 typ host a=candidate:2 2 tcp-act 2121006078 192.168.32.102 61162 typ host a=candidate:3 1 tcp-pass 6555135 97.75.78.122 52262 typ relay raddr 192.168.32.102 rport 59579 a=candidate:3 2 tcp-pass 6555134 97.75.78.122 52262 typ relay raddr 192.168.32.102 rport 59579 a=candidate:4 1 tcp-act 7076607 97.75.78.122 52262 typ relay raddr 192.168.32.102 rport 59579 a=candidate:4 2 tcp-act 7076094 97.75.78.122 52262 typ relay raddr 192.168.32.102 rport 59579 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:99Bb0azI7SNc13DQNynXxJFjPwt7OTwFBnuzNgJa|2^31|1:1 a=rtpmap:127 x-data/90000 $$end_record The P-ASSERTED-IDENTITY section in the previous trace shows the identity of the callee, which is displayed as the conferencing GRUU ID for conferencing scenarios. The candidate list, 192.168.32.102, is the IP address of the Front End Server. It also provides the appropriate relay addresses through the Audio/Video Edge service for application sharing traffic.

At this point, the client has validated connectivity to the Audio/Video Edge service and ultimately to the application sharing conference service on the Front End pool through a series of ICE protocol connectivity checks. (For details, see the Interactive Connectivity Establishment (ICE) Protocol section of this chapter. Note in the two candidate list (lines starting with a=candidate), only TCP candidates are supported. Application sharing uses RDP. It sends only traffic over TCP; UDP isnt used for this type of media.
4 SIP INVITE
The remote user then sends another SIP INVITE to join the conference, containing the following information: The modality (m=applicationsharing). The ICE protocol password used for authentication media connectivity. The remote users TCP candidates for media flow (a=candidate). The encryption type (a=crypto). The negotiated IP address of the Front End Server that has been validated for connectivity (a=remote-candidates). Remember that this request is being relayed through the Audio/Video Edge service to the Front End Server. The valid IP address of the Front End Server is displayed as the internal address.
The new ICE protocol information is displayed in the following trace and is highlighted.
Page 47
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="70B881CC", targetname="LYNCFE1.Contoso.com", crand="a5c7b267", cnum="386", response="27be4fe997af418e29789ef0f33ab51dc1ef46b9" Content-Type: application/sdp Content-Length: 788 Message-Body: v=0 o=- 0 0 IN IP4 97.75.78.122 s=session c=IN IP4 97.75.78.122 b=CT:53980 t=0 0 m=applicationsharing 57929 TCP/RTP/SAVP 127 a=ice-ufrag:MakE a=ice-pwd:7iJs2rWVUD5enazDfbf9nSJm a=candidate:5 1 TCP-PASS 6556159 97.75.78.122 57929 typ relay raddr 76.187.107.231 rport 22497 a=candidate:5 2 TCP-PASS 6556158 97.75.78.122 57929 typ relay raddr 76.187.107.231 rport 22497 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:0sGb8VadPu7yiaGeye54b72ffI3d5sINGMZRZKj3|2^31|1:1 a=remote-candidates:1 192.168.32.102 53638 2 192.168.32.102 53638
5 SIP 200 OK
The Front End pool responds with another SIP 200 OK message that contains the updated candidate information that was agreed to between the Front End pool and the remote Lync 2010 client. That candidate information is shown in the following SIP message. P-ASSERTED-IDENTITY: <sip:bob@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR> SERVER: RTCC/4.0.0.0 applicationsharing Ms-Conversation-ID: 81f325e91f424bbca3cb52198b9e9133 Session-Expires: 600;refresher=uas Min-SE: 90 Message-Body: v=0 o=- 273 1 IN IP4 192.168.32.102 s=session c=IN IP4 192.168.32.102 b=CT:4294967 t=0 0 m=applicationsharing 53638 TCP/RTP/SAVP 127 c=IN IP4 192.168.32.102 a=x-applicationsharing-role:viewer a=x-capabilities a=x-applicationsharing-session-id:1 a=x-applicationsharing-media-type:rdp a=rtcp:53638 a=connection:existing a=setup:active a=ice-ufrag:NIrR a=ice-pwd:KdRCdSSBXiGuG7ZHkFN0bpZx a=candidate:2 1 tcp-act 2121006591 192.168.32.102 53638 typ host a=candidate:2 2 tcp-act 2121006078 192.168.32.102 53638 typ host
Page 48
a=remote-candidates:1 97.75.78.122 57929 2 97.75.78.122 57929 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:99Bb0azI7SNc13DQNynXxJFjPwt7OTwFBnuzNgJa|2^31|1:1 a=rtpmap:127 x-data/90000 $$end_record In the previous SIP message, the remote users reflexive IP address is 97.75.78.122 (see line that begins with a=remote-candidates). From this trace, the Front End Server identified that the address is the IP address that the Front End Server can use to connect with the remote user through the Edge Server. This was established through a series of ICE protocol connectivity checks. For details on ICE protocol connectivity checks, see the ICE Protocol section earlier in this chapter.
6 Media
This traffic flows through the Audio/Video Edge service similarly to audio and video traffic. The Web Conferencing Edge service remains available for legacy clients that connect to the application sharing conference over PSOM traffic. However, the previous trace shows the connectivity process only for Lync 2010 clients using RDP through the Audio/Video Edge service. Encrypted media flows between the Lync 2010 client to the Audio/Video Edge service and ultimately relayed to the Front End Server. After the user leaves the conference, a SIP BYE is sent. An example of this message is as follows. TL_INFO(TF_PROTOCOL) [0]12B8.10E0::06/01/2011-02:12:54.527.002aec01 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record Trace-Correlation-Id: 2262276601 Instance-Id: 00122B40 Direction: outgoing;source="external edge";destination="internal edge" Peer: pool1.contoso.com:5061 Message-Type: request Start-Line: BYE sip:bob@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR SIP/2.0 From: <sip:bob@contoso.com>;tag=10dc873e91;epid=3821b40476 To: <sip:bob@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR>;tag=f85b16 59e9;epid=02F0FEEFCD CSeq: 3 BYE Call-ID: b85cd18d9e074bdf8c5448ea279651cc Via: SIP/2.0/TLS 192.168.32.105:65072;branch=z9hG4bK7019F513.D5532D383C251306;branched=FALSE Max-Forwards: 69 Via: SIP/2.0/TLS 192.168.5.202:54385;received=76.187.107.231;ms-receivedport=54385;ms-received-cid=C56000 Route: <sip:pool1.contoso.com:5061;transport=tls;msfe=SRLYNCFE1.Contoso.com;opaque=state:T:Tc.YJV-vB_Ez1mgzTXyuB-xHckT:F:Fc.YJVvB_Ez1mgzTXyuB-xHckT:Eu;lr;received=192.168.32.102;ms-received-cid=B9F302> User-Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.275 (Microsoft Lync 2010) Ms-client-diagnostics: 51004; reason="Action initiated by user" Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="70B881CC", targetname="SRLYNCFE1.contoso.com", crand="bdf65731", cnum="390", response="2f2d875ece441369aeb783d51bb78105ccf573d1" Content-Length: 0
Page 49
ms-edge-proxy-message-trust: ms-source-type=InternetUser;ms-epfqdn=srlyncedge1.contoso.com;ms-source-verified-user=verified Message-Body: $$end_record The previously highlighted text shows that this is a SIP BYE from the remote user. The Direction shows that this was sent from the external edge interface and is directed toward the internal network. The TO: line shows this message going to the conferencing URI for the application-sharing conference.
Audio and Video Conferencing

Call flow The Audio and Video Conferencing join experience is similar to the Application Sharing Conferencing join in that the call flow process is nearly identical. The user sends an INVITE to the A/V Conference Service URI, and then performs a series of ICE protocol connectivity checks. This establishes a media path and relays media through the Audio/Video Edge service to the Audio/Video Conferencing service that is hosted on the Front End pool or a dedicated A/V Conferencing Server. Because this process is the same as the Application Sharing Join process, this section highlights only the relevant differences. The major difference between this call flow and the Application Sharing call flow is that a user sends multiple sets of candidates both for audio and video. Figure 17 shows the call flow for audio/video conferencing.
Figure 17. Audio and video conferencing call flow
Page 50
The following numbered headings describe the audio and video conferencing call flow sequence that is shown in Figure 17. The heading numbers correspond to the sequence numbers (connectors) in Figure 17.
1 SIP INVITE
The beginning of the SIP INVITE is sent from the client to the Access Edge service, and then relayed to the A/V Conferencing Server. An example of the SIP message that shows the valid audio/video conferencing URI being sent in the INVITE is as follows. Direction: incoming;source="external edge";destination="internal edge" Peer: 76.187.107.231:54385 Message-Type: request Start-Line: INVITE sip:bob@contoso.com;gruu;opaque=app:conf:audiovideo:id:FZG8SYVR SIP/2.0 From: <sip:bob@contoso.com>;tag=75336413c0;epid=3821b40476 To: <sip:bob@contoso.com;gruu;opaque=app:conf:audiovideo:id:FZG8SYVR>;tag=a4f2e92356;epid=0B08BA10A9 CSeq: 3 INVITE The first highlighted section in the previous SIP message shows that the INVITE is for a conference. A GRUU always appears in SIP messages for conferencing INVITES. To determine the type of conference being joined, look for the app:conf: section. In the previous SIP message, this INVITE is for an audio/video conference. The second section that is highlighted is simply the sequence line, outlining that it is part of the INVITE sequence. The following trace shows the negotiated audio candidate list in addition to the initial candidate list that was sent in the SIP INVITE for the video conferencing join that was initiated by the user.
Page 51
m=audio 50743 RTP/SAVP 9 111 0 8 97 13 118 101

a=ice-ufrag:cGUT a=ice-pwd:eUrBEAMFNrwFGgroXuUMaLtS a=candidate:4 1 UDP 16648703 97.75.78.122 50743 typ relay raddr 76.187.107.231 rport 31602 a=candidate:4 2 UDP 16648702 97.75.78.122 55309 typ relay raddr 76.187.107.231 rport 31603 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:FU4Gl7hGYS894KJYhEvNq72Jo7ADq2e0gkLUzPV1|2^31|1:1 a=remote-candidates:1 192.168.32.102 53622 2 192.168.32.102 53623 a=maxptime:200 a=rtcp:55309 a=rtpmap:9 G722/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 RED/8000 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=encryption:required m=video 56786 RTP/SAVP 121 34 a=ice-ufrag:eQIo a=ice-pwd:Z3/6wUobk1Qc31qlG/s6yGr+ a=x-caps:121 263:1280:720:13.0:768000:1;4359:640:480:30.0:600000:1;8455:352:288:15.0:250000:1;1255 1:176:144:15.0:180000:1 a=x-caps:34 262:352:288:15.0:250000:1;4358:176:144:15.0:180000:1 a=candidate:1 1 UDP 2130706431 192.168.56.1 32600 typ host a=candidate:1 2 UDP 2130705918 192.168.56.1 32601 typ host a=candidate:2 1 UDP 2130705919 192.168.5.202 18340 typ host a=candidate:2 2 UDP 2130705406 192.168.5.202 18341 typ host a=candidate:3 1 TCP-PASS 6556159 97.75.78.122 55874 typ relay raddr 76.187.107.231 rport 32138 a=candidate:3 2 TCP-PASS 6556158 97.75.78.122 55874 typ relay raddr 76.187.107.231 rport 32138 a=candidate:4 1 UDP 16648703 97.75.78.122 56786 typ relay raddr 76.187.107.231 rport 30206 a=candidate:4 2 UDP 16648702 97.75.78.122 55003 typ relay raddr 76.187.107.231 rport 30207 a=candidate:5 1 UDP 1694235135 76.187.107.231 30206 typ srflx raddr 192.168.5.202 rport 30206 a=candidate:5 2 UDP 1694233598 76.187.107.231 30207 typ srflx raddr 192.168.5.202 rport 30207 a=candidate:6 1 TCP-ACT 7075839 97.75.78.122 55874 typ relay raddr 76.187.107.231 rport 32138 a=candidate:6 2 TCP-ACT 7075326 97.75.78.122 55874 typ relay raddr 76.187.107.231 rport 32138 a=candidate:7 1 TCP-ACT 1684796927 76.187.107.231 32138 typ srflx raddr 192.168.5.202 rport 32138
Page 52
a=candidate:7 2 TCP-ACT 1684796414 76.187.107.231 32138 typ srflx raddr 192.168.5.202 rport 32138 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:IPqQFXw5KeNZncP3jn18X3ccVbpY4lBG32b9MmkL|2^31|1:1 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:GGC92XqP/XspQyBPwn3zwX8JcUgjwcdFkGCyOYw4|2^31|1:1 a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:B/iK/8WHx4ftNi7IO7NIyfFumkCqM9W7n3jSidse|2^31 a=rtcp:55003 a=rtpmap:121 x-rtvc1/90000 a=rtpmap:34 H263/90000 a=encryption:required $$end_record Highlighted in the previous trace is the beginning of both the audio and video candidate list. Each section is designated by the keywords m=audio and m=video in the trace. This initial candidate list provides all possible candidate addresses. At this point, the ICE protocol connectivity checks will validate the candidate information.
2 SIP 200 OK
The Audio/Video Conferencing service then responds with a SIP 200 OK that contains validated candidate information for both audio and video connectivity for the A/V Conferencing Server. The candidate presentation is as follows. m=audio 53622 RTP/SAVP 9 111 0 8 97 13 118 101 c=IN IP4 192.168.32.102 a=rtcp:53623 a=ice-ufrag:S+P6 a=ice-pwd:HiG/xqpI6bWPwDomHHFTxwI5 a=candidate:1 1 UDP 2130706431 192.168.32.102 53622 typ host a=candidate:1 2 UDP 2130705918 192.168.32.102 53623 typ host a=remote-candidates:1 97.75.78.122 50743 2 97.75.78.122 55309 a=label:main-audio a=cryptoscale:1 server AES_CM_128_HMAC_SHA1_80 inline:rG25t+QeWR3lLjpXRgqPH3aDwnrNGMGj/KCSuSf4|2^31|1:1 a=rtpmap:9 g722/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 RED/8000 a=fmtp:97 red/8000 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=encryption:rejected m=video 63146 RTP/SAVP 121 c=IN IP4 192.168.32.102 a=x-sourceid:MainCamera a=rtcp:63147 a=ice-ufrag:IHEW a=ice-pwd:1XsEswTv2ltVumXN842sCLNJ
Page 53
a=candidate:1 1 UDP 2130706431 192.168.32.102 63146 typ host a=candidate:1 2 UDP 2130705918 192.168.32.102 63147 typ host a=candidate:2 1 tcp-pass 6554111 97.75.78.122 57822 typ relay raddr 192.168.32.102 rport 62590 a=candidate:2 2 tcp-pass 6554110 97.75.78.122 57822 typ relay raddr 192.168.32.102 rport 62590 a=candidate:3 1 UDP 16646911 97.75.78.122 55604 typ relay raddr 192.168.32.102 rport 58304 a=candidate:3 2 UDP 16646910 97.75.78.122 58776 typ relay raddr 192.168.32.102 rport 58305 a=candidate:4 1 tcp-act 7076863 97.75.78.122 57822 typ relay raddr 192.168.32.102 rport 62590 a=candidate:4 2 tcp-act 7076350 97.75.78.122 57822 typ relay raddr 192.168.32.102 rport 62590 a=candidate:5 1 tcp-act 1684797951 192.168.32.102 62590 typ srflx raddr 192.168.32.102 rport 62590 a=candidate:5 2 tcp-act 1684797438 192.168.32.102 62590 typ srflx raddr 192.168.32.102 rport 62590 a=label:main-video a=cryptoscale:1 server AES_CM_128_HMAC_SHA1_80 inline:mXvZr3ao/MWWp2ss939P3hATAoUxEzxoCiTIiPKN|2^31|1:1 a=rtpmap:121 x-rtvc1/90000 a=fmtp:121 CIF=15;VGA=15;PANO=15 a=x-caps:121 263:640:480:30.0:600000:1;4359:352:288:15.0:250000:1;8455:176:144:15.0:180000:1 a=encryption:rejected $$end_record The list of video candidates that was sent from the Audio/Video Conferencing service is highlighted in the previous trace.

At this point, STUN binding requests are sent for ICE protocol connectivity checks to the presented candidates. In the following trace, the media is relayed through the Audio/Video Edge service to the Audio/Video Conferencing service.
4 SIP INVITE
The following trace shows the SIP INVITE that was sent from the client after the client has validated the ICE protocol path for media connectivity. Direction: incoming;source="external edge";destination="internal edge" Peer: 76.187.107.231:54385 Message-Type: request Start-Line: INVITE sip:bob@contoso.com;gruu;opaque=app:conf:audiovideo:id:FZG8SYVR SIP/2.0 From: <sip:bob@contoso.com>;tag=75336413c0;epid=3821b40476 To: <sip:bob@contoso.com;gruu;opaque=app:conf:audiovideo:id:FZG8SYVR>;tag=a4f2e92356;epid=0B08BA10A9 CSeq: 4 INVITE The highlighted text in the previous trace is the conferencing type information as referenced in the initial INVITE. This section of the trace shows that this is for an audio/video conference with the ID FZG8SYVR.
Page 54
The second INVITE is similar to the initial INVITE; however, the candidate list contains the validated candidate information for video. This candidate list is as follows. The validated candidate list is highlighted. m=video 56786 RTP/SAVP 121 a=ice-ufrag:eQIo a=ice-pwd:Z3/6wUobk1Qc31qlG/s6yGr+ a=x-caps:121 263:1280:720:13.0:768000:1;4359:640:480:30.0:600000:1;8455:352:288:15.0:250000:1;1255 1:176:144:15.0:180000:1 a=candidate:4 1 UDP 16648703 97.75.78.122 56786 typ relay raddr 76.187.107.231 rport 30206 a=candidate:4 2 UDP 16648702 97.75.78.122 55003 typ relay raddr 76.187.107.231 rport 30207 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:IPqQFXw5KeNZncP3jn18X3ccVbpY4lBG32b9MmkL|2^31|1:1 a=remote-candidates:1 192.168.32.102 63146 2 192.168.32.102 63147 a=rtcp:55003 a=rtpmap:121 x-rtvc1/90000 a=encryption:required In the previous trace, 192.168.32.102 (see line that begins with a=remote-candidates) is the IP address of the Audio/Video Conferencing service; 97.75.78.122 is the IP address of the Audio/Video Edge service public interface.
5 SIP 200 OK
The Audio/Video Conferencing service responds with a SIP 200 OK message that contains the validated remote client candidate information. This trace is as follows; the validated candidate list is highlighted. m=video 63146 RTP/SAVP 121 c=IN IP4 192.168.32.102 a=x-sourceid:MainCamera a=rtcp:63147 a=ice-ufrag:IHEW a=ice-pwd:1XsEswTv2ltVumXN842sCLNJ a=candidate:1 1 UDP 2130706431 192.168.32.102 63146 typ host a=candidate:1 2 UDP 2130705918 192.168.32.102 63147 typ host a=remote-candidates:1 97.75.78.122 56786 2 97.75.78.122 55003 a=label:main-video a=cryptoscale:1 server AES_CM_128_HMAC_SHA1_80 inline:mXvZr3ao/MWWp2ss939P3hATAoUxEzxoCiTIiPKN|2^31|1:1 a=rtpmap:121 x-rtvc1/90000 a=fmtp:121 CIF=15;VGA=15;PANO=15 a=x-caps:121 263:640:480:30.0:600000:1;4359:352:288:15.0:250000:1;8455:176:144:15.0:180000:1 a=encryption:rejected
6 Media
Media flows between the remote user and the Audio/Video Conferencing service. This media is relayed through the Audio/Video Edge service. When the user leaves the conference call, or the conference call is ended, a SIP BYE message is sent to end the media stream.
Page 55
IM and Presence
This section describes the SIP call flow for IM sessions for various scenarios. These sessions include peer-to-peer, IM and a remote user, federation, and federation with public IM connectivity.
Remote Access
Call Flow When a remote user wants to communicate with another user in their organization by using instant messaging, a series of SIP messages are sent between the two users. In Figure 18, the user (Alice) who is initiating the IM conversation is remote (located outside the corporate network). The user (Bob) who Alice is communicating with is located on the internal network. When the user (Alice) sends the SIP INVITE, it is proxied through the Access Edge service, to the Front End Server (through a Director if one is deployed), and then finally to the Lync 2010 user (Bob). A diagram of this process is shown in Figure 18.
Figure 18. Peer-to-peer IM flow
The following numbered headings describe the peer-to-peer IM sequence that is shown in Figure 18. The heading numbers correspond to the sequence numbers (connectors) in Figure 18.
Page 56
1 SIP INVITE
The initial SIP INVITE is as follows. 06/01/2011|21:21:05.883 13C8:404 INFO :: Sending Packet - 97.75.78.120:443 (From Local Address: 192.168.5.201:54530) 3507 bytes: 06/01/2011|21:21:05.883 13C8:404 INFO :: INVITE sip:alice@contoso.com SIP/2.0 Via: SIP/2.0/TLS 192.168.5.201:54530 Max-Forwards: 70 From: <sip:bob@contoso.com@contoso.com>;tag=eb84d57b8b;epid=3821b40476 To: <sip:alice@contoso.com@contoso.com> Call-ID: 986c34eaf29f421ab3c3bcb888a6c573 CSeq: 1 INVITE Contact: <sip:bob@contoso.com @contoso.com;opaque=user:epid:PTRheATWGFKz3HXNaHc6gAA;gruu> User-Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.275 (Microsoft Lync 2010) Supported: ms-dialog-route-set-update Supported: ms-embedded-first-message Supported: ms-delayed-accept Supported: ms-renders-isf Supported: ms-renders-gif Supported: ms-renders-mime-alternative Ms-Conversation-ID: Acwgy7oLji0JmWA5RaaCJkLhVgF3lg== Supported: timer Supported: histinfo Supported: ms-safe-transfer Supported: ms-sender Supported: ms-early-media Roster-Manager: sip:bob@contoso.com@contoso.com EndPoints: <sip:bob@contoso.com@contoso.com>, <sip:alice@contoso.com@contoso.com> Supported: com.microsoft.rtc-multiparty ms-keep-alive: UAC;hop-hop=yes Allow: INVITE, BYE, ACK, CANCEL, INFO, MESSAGE, UPDATE, REFER, NOTIFY, BENOTIFY ms-subnet: 192.168.5.0 Supported: ms-conf-invite Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="6FB8C8B0", targetname="LYNCFE1.contoso.com", crand="8ae91d1b", cnum="218", response="8d99a6bbb26676d43474286ff96f4d1e776f6eb0" Content-Type: application/sdp Content-Length: 246 v=0 o=- 0 0 IN IP4 192.168.5.201 s=session c=IN IP4 192.168.5.201 t=0 0 m=message 5060 sip null a=accept-types:text/plain multipart/alternative image/gif text/rtf text/html application/x-msink application/ms-imdn+xml text/x-msmsgsinvite 06/01/2011|21:21:05.883 13C8:404 INFO :: End of Sending Packet - 97.75.78.120:443 (From Local Address: 192.168.5.201:54530) 3507 bytes
Page 57
In the previous SIP INVITE, the first highlighted text (v=0) in the SIP INVITE message is the header that shows that this is an INVITE to alice@contoso.com. The next highlighted text is the IP addresses of the sending client (192.168.5.201). The following highlighted text is the modality information that designates this as an instant messaging conversation (M=message) and the messaging types that are supported (a=accept-types). This informational content that is included in the SIP message tells the client the type of supported content and where communications is sent.
2 SIP 200 OK
The receiving user then responds with a SIP 200 OK message. It contains IP address (o=0 0 IN IP4 192.168.9.124) information for their Lync 2010 client and conversational capabilities similar to the initial SIP INVITE from the initiating user as shown in the following message. Highlighted first is the SIP header, showing that this is a SIP 200 OK message. The next highlight is the information content in the SIP message being sent back to the initiating user in preparation for subsequent instant messages. 06/01/2011|21:21:06.164 13C8:404 INFO :: Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 1793 bytes: 06/01/2011|21:21:06.164 13C8:404 INFO :: SIP/2.0 200 OK v=0 o=- 0 0 IN IP4 192.168.9.124 s=session c=IN IP4 192.168.9.124 t=0 0 m=message 5060 sip sip:alice@contoso.com@contoso.com a=accept-types:text/plain multipart/alternative image/gif text/rtf text/html application/x-msink application/ms-imdn+xml text/x-msmsgsinvite 06/01/2011|21:21:06.164 13C8:404 INFO :: End of Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 1793 bytes
3 SIP MESSAGE
At this point, subsequent instant messages are sent between the users. Because at least one user is remote, this traffic is relayed through the Access Edge service (see the following SIP MESSAGE trace). The encrypted message content is highlighted. (Some data has been removed to shorten the SIP message). 06/01/2011|21:22:32.249 17B4:17B8 INFO :: MESSAGE sip:alice@contoso.com;opaque=user:epid:PTRheATWGFK-z3HXNaHc6gAA;gruu SIP/2.0 Via: SIP/2.0/TLS 192.168.1.108:49535 Max-Forwards: 70 From: <sip:bob@contoso.com>;tag=97b1ebd6ef;epid=92a17ee2ce To: <sip:alice@contoso.com>;epid=3821b40476;tag=37dba6e2c9 Call-ID: f2d61b6c397942c1b246f206bb245b1d CSeq: 3 MESSAGE Route: <sip:access.contoso.com:5061;transport=tls;epid=3821b40476;lr;ms-keyinfo=AAEAAcpdRklxovgcNzHMAbuwfNfZKxVBsACzn3DFXxEsjbZR864SX7lL7bprXnnA5PeV02EQM3DXxG2UAZZ3sxDF4D7vd0h0YsalkgK1wBWCEwnGFsYEs3_ WVQNBRHKFOFktNCAcZdiYBJRVrYoBOg04snoJD7LtVIcaf0-qmtsiRiXavaOI9hsp11IPH6eR37aqJLEziGNmDb20gvm_XNzoDxO6QBjunV_ghu1NBDI_WemG0bvXGKe6_HJH
Page 58
1tMSATrnTCVGV765W4X3trDe2xatLkJpXbFMLNX8-huFEC1qLUP7KvxHW46vcMfjZ3h8iSkezSoppwZy6PFIqZJx7snNOg5NmAMXK8IIizUuEjjsFUcXKZU3Fc_enIdJYfxzPAqHb5ncPN2J6RPlDZ8wqg pvQxbmafqhcjuBLwHZ5vQKpNyM9KMcZBg3ujc9kuJAww5hTkwbebDF2IbzmBgnBa-wVi_nBPZGi6V0besLcylXI-T0Pe5uKWoWNjJBQ3Suc0BQsyXVplBHxsinlPluwOnNrFlfPhZMv5yPOVpIawQW_pwiLZeHEsHx6svVXWzttLXwiShDDgqO_ geRGeumWa3O3l5V-sSJ-PKsVNR_Y_DVMWDrJoDLbOYRcoRFo9QVLY4QU_k0tiqE9pBXtUoGjZECySIvi7txyuyFPbsEoidu9zurZoD2h8ehYa;ms-routesig=ebUo0ig18IvUuWD9u_ylv-wGgA11mpJhIfmHtYp5m0y7QiEpThcrEe0gAA> Route: <sip:pool1.contoso.com:5061;transport=tls;msfe=SRLYNCFE1.contoso.com;opaque=state:T;lr> User-Agent: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010)
4 SIP BYE
When either user closes the Conversation window, a SIP BYE message like the following is sent to the other client to signal the end of the conversation. 06/01/2011|21:22:02.291 13C8:404 INFO :: Sending Packet - 97.75.78.120:443 (From Local Address: 192.168.5.201:54530) 990 bytes: 06/01/2011|21:22:02.291 13C8:404 INFO :: BYE sip:alice@contoso.com@contoso.com;opaque=user:epid:0SRgoaqKO1yu7wK0M58UQAA;gruu SIP/2.0 Via: SIP/2.0/TLS 192.168.5.201:54530 Max-Forwards: 70 From: <sip:bob@contoso.com@contoso.com>;tag=eb84d57b8b;epid=3821b40476 To: <sip:alice@contoso.com@contoso.com>;epid=0c00cbaa35;tag=15daa2da36 Call-ID: 986c34eaf29f421ab3c3bcb888a6c573 CSeq: 3 BYE Route: <sip:access.contoso.com:443;transport=tls;opaque=state:Ci.Rd43c00;lr;ms-routesig=hlJ6QrewO6hBfLC3DodeRkrbdrph1hOP5109PThcZG_pvz0SXUcrEe0gAA> Route: <sip:pool1.contoso.com:5061;transport=tls;msfe=SRLYNCFE1.Contoso.com;opaque=state:T:F:Eu;lr;received=192.168.32.102;ms-receivedcid=D32902> User-Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.275 (Microsoft Lync 2010) Ms-client-diagnostics: 51004; reason="Action initiated by user" Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="6FB8C8B0", targetname="SRLYNCFE1.contoso.com", crand="52ca915c", cnum="239", response="546687917ad8b44263c7695c6ff5aff081ac7fca" Content-Length: 0
06/01/2011|21:22:02.291 13C8:404 INFO :: End of Sending Packet - 97.75.78.120:443 (From Local Address: 192.168.5.201:54530) 990 bytes
Page 59
Federation
Call Flow When a remote user wants to initiate an IM conversation with a federated partner, the SIP call flow is similar to the remote access call flow. The main difference is that the federation IM traffic is relayed from the initiating users Edge Server to the federated partners Edge Server before reaching the federated user. A diagram of this call flow is shown in Figure 19.
Figure 19. Federated instant messaging flow
The following numbered headings describe the federated instant messaging flow sequence that is shown in Figure 19. The heading numbers correspond to the sequence numbers (connectors) in Figure 19.
1 SIP INVITE
The initial SIP INVITE message looks almost identical to the remote access SIP INVITE.
2 SIP 100 TRYING

The SIP 100 TRYING message in Figure 19 contains information that specifies that this is a federated request. 06/01/2011|21:20:41.011 13C8:404 INFO :: Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 800 bytes: 06/01/2011|21:20:41.011 13C8:404 INFO :: SIP/2.0 100 Trying
Page 60
Authentication-Info: TLS-DSK qop="auth", opaque="6FB8C8B0", srand="50C12A0E", snum="208", rspauth="8edd7e8d20eb475862611dac7cfcc9668ec3247d", targetname="SRLYNCFE1.Contoso.com", realm="SIP Communications Service", version=4 From: "bob"<sip:bob@contoso.com@contoso.com>;tag=b3139c0af6;epid=3821b40476 To: <sip:alice@fabrikam.com> Call-ID: 49ccdc42027c4701a2f6df5443e7f4d1 CSeq: 1 INVITE Via: SIP/2.0/TLS 192.168.5.201:54530;received=76.187.107.231;ms-receivedport=54530;ms-received-cid=D43C00 Server: http%3A%2F%2Fwww.microsoft.com%2FLCS%2FDefaultRouting Content-Length: 0 ms-edge-proxy-message-trust: ms-source-type=AutoFederation;ms-epfqdn=srlyncedge1.contoso.com;ms-source-network=federation;ms-source-verifieduser=verified
06/01/2011|21:20:41.011 13C8:404 INFO :: End of Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 800 bytes In the previous trace, the proxy message is highlighted. Because the proxy message contains a source-type of AutoFederation (open federation with DNS SRV records), and contains the line ms-source-verified-user=verified, the SIP message shows that this is a validated user identity for a federated partner. This allows the request to be routed through the site default federation route. (The site federation route is defined in Topology Builder. For detailed configuration information, see the Deployment documentation in the TechNet Library, http://go.microsoft.com/fwlink/?LinkId=202714).
3 SIP 200 OK
The initiating user receives a SIP 200 OK response from the federated partner. This message contains information about all the servers that are involved in the federation routing path from both the Contoso, Ltd user and the federated (Fabrikam, Inc.) partner. This message also contains IP address information and message capabilities of the federated partner. Following is an example of a SIP 200 OK message. Highlighted in the first section of the following trace is the server information where this SIP 200 OK message has been sent from the federated partner (see Record-Route). Every time a message is sent through a SIP proxy (Front End Server, Director, Edge Server) a RecordRoute is created. FQDNs are displayed in the following message: Lyncfe.fabrikam.com: FQDN of Lync Server Front End pool for a federated user Lsaccess.fabrikam.com: Access Edge service for a federated user
Highlighted in the second section of the following trace is a base-64 encoded message. It is the contents of an instant message from the federated user to the corporate user (see Info=). 06/01/2011|21:20:50.901 13C8:404 INFO :: Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 2949 bytes: 06/01/2011|21:20:50.901 13C8:404 INFO :: SIP/2.0 200 OK ms-user-logon-data: RemoteUser
Page 61
Authentication-Info: TLS-DSK qop="auth", opaque="6FB8C8B0", srand="5666828D", snum="211", rspauth="5dbfe24396e6d5cd10d9b0bfdf3c6d70abb8f25d", targetname="SRLYNCFE1.Contoso.com", realm="SIP Communications Service", version=4 Via: SIP/2.0/TLS 192.168.5.201:54530;received=76.187.107.231;ms-receivedport=54530;ms-received-cid=D43C00 From: "bob"<sip:bob@contoso.com@contoso.com>;tag=b3139c0af6;epid=3821b40476 To: <sip:alice@fabrikam.com>;epid=92a17ee2ce;tag=1c17ec014b Call-ID: 49ccdc42027c4701a2f6df5443e7f4d1 CSeq: 1 INVITE Record-Route: <sip:LYNCFE.fabrikam.com:5061;transport=tls;opaque=state:T;lr> Record-Route: <sip:lsaccess.fabrikam.com:5061;transport=tls;epid=92a17ee2ce;lr;ms-keyinfo=AAEAAcxAKWijvTDXuyDMAZabLrnpL1e5ODZVKgDVxSI12E4wweqLydUFSfEGTkcgSBmTiz4 SFVMLf9UGPWFK9mDmrrxkjDB3rN3nj2Z82OWGKFdcE9jlmp5DkqgSDxROjsN9uiH9s3S_gTXIeLfJ Pbv8J20vmB0Chv_UGdL7GQWaR1KjHXuGi5WJL5BrbWo8T2FRYMKjUw3vEH8D0F1jXPALyQIk4x2 Fd4ht4G7Fhmrh0NtHGMHbUOgvav3BRqpqwwOfhqnSvJVPROaaY6Z7nXv2_w01x8_qREEIK7zNXgFLXmrgOWVhxt24uZtixOuEePLPKXUTk9 4dDxJwd5SA0t7fJ9R3_O1UM1wUzarQ2Z3nYHRV7okPzq_ZIWwTXSdgaDRvNohzE_GmQxm2h4Rc weNanbTelGBIUMbViflg4_zI86LIfSrA-wC-2K-xY4mbX8eKno1HcFDTPaObm3kYn2TWssP6SwtXyNf2Ut-yJRIFRqAthsS49jsU67SVVuaH2cem5cDjGh9R-YlxJNVpyb9zwZo9Fhw9qpM6u5M_T8UxtJUhOsQDk30ECnPQFC6cAGnGix5357leanVDvM162M7U3C wS1C3vNnNts4kNCVBhKkqZGmdHGi_nU8tkyh4HYA3BV7sVbHgyqj1fgXAkLt8p1Mk8eliboSOp0h nd1mYEHd-6v2xt2uWJzLpUd;ms-route-sig=bo6DSEdyaPMIcXxlXm_jEl9Iz00n75xbh4zRDcpQ44TMRuebQIRQw3wAA> Record-Route: <sip:lyncedge1.contoso.com:5061;transport=tls;lr> Record-Route: <sip:pool1.contoso.com:5061;transport=tls;msfe=SRLYNCFE1.contoso.com;opaque=state:F;lr;received=192.168.32.102;ms-receivedcid=D32902> Contact: <sip:alice@fabrikam.com;opaque=user:epid:1dRPOJppUlG-Qszig4EXYgAA;gruu> User-Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.275 (Microsoft Lync 2010) Require: com.microsoft.rtc-multiparty Supported: com.microsoft.rtc-multiparty Supported: ms-renders-isf Supported: ms-renders-gif Supported: ms-renders-mime-alternative Supported: ms-sender Supported: histinfo Supported: ms-safe-transfer Supported: ms-dialog-route-set-update Allow: INVITE, BYE, ACK, CANCEL, INFO, MESSAGE, UPDATE, REFER, NOTIFY, BENOTIFY Supported: ms-conf-invite Content-Type: application/sdp Content-Length: 271 Record-Route: <sip:access.contoso.com:443;transport=tls;opaque=state:Ci.Rd43c00;lr;msroute-sig=hl2D8Ilg3_VEqWzIzhjwl2MGAUy2V94PVpGVK34fBz6-WyinqscrEe0gAA> ms-edge-proxy-message-trust: ms-source-type=AutoFederation;ms-epfqdn=srlyncedge1.contoso.com;ms-source-network=federation;ms-source-verifieduser=verified v=0 o=- 0 0 IN IP4 10.255.253.182 s=session c=IN IP4 10.255.253.182
Page 62
t=0 0 m=message 5060 sip sip:alice@fabrikam.com a=accept-types:text/plain multipart/alternative image/gif text/rtf text/html application/x-msink application/ms-imdn+xml text/x-msmsgsinvite 06/01/2011|21:20:50.901 13C8:404 INFO :: End of Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 2949 bytes The third highlighted section in the previous trace contains the route information for the internal servers. As previously mentioned, for every SIP proxy that a message passes through, a Record-Route entry is created. This message displays the following FQDNS: Lyncedge1.contoso.com: internal FQDN of the Edge Server for the initiating user Pool1.contoso.com: Front End Server for the initiating user Access.contoso.com: Access Edge service for the initiating user
4 SIP MESSAGES
At this point, subsequent SIP messages contain instant messages like any other IM conversation.
5 SIP BYE
When a user closes the Conversation window, a SIP BYE message is sent to signal the end of the conversation.
Public IM Connectivity
Call Flow Similar to the Federation SIP call flow, public IM connectivity SIP messages are relayed through the Access Edge service. The key difference between a regular federated message and a message to a user on a public IM connectivity provider is that the SIP message relays to the public IM connectivity providers federation gateway. (This is similar to the Access Edge service in Lync 2010, both function as SIP proxies). Figure 20 shows using a live.com MSN account to federate with a Lync 2010 user.
Page 63
Figure 20. Public IM connectivity flow
The following numbered headings describe the public IM connectivity flow sequence that is shown in Figure 20. The heading numbers correspond to the sequence numbers (connectors) in Figure 20.
1 SIP INVITE
As with the previous sections, the initial SIP INVITE from the initiating user is identical in the information contained inside the SIP message.
2 SIP 100 TRYING

The SIP 100 TRYING message in Figure 20 contains information that describes the type of partner that the message is being routed to. Its trace can be seen as follows. 06/01/2011|21:21:58.638 13C8:404 INFO :: Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 737 bytes: 06/01/2011|21:21:58.638 13C8:404 INFO :: SIP/2.0 100 Trying ms-user-logon-data: RemoteUser Authentication-Info: TLS-DSK qop="auth", opaque="6FB8C8B0", srand="4EC56CBE", snum="235", rspauth="354de79d26cecef18c937d2cccf2263987809f23", targetname="SRLYNCFE1.Contoso.com", realm="SIP Communications Service", version=4 From: "bob"<sip:bob@contoso.com@contoso.com>;tag=1c291b0356;epid=3821b40476 To: <sip:<user1>@live.com> Call-ID: 3f8f4e12386d4f76ba8d286cc0857ca0 CSeq: 1 INVITE Via: SIP/2.0/TLS 192.168.5.201:54530;received=76.187.107.231;ms-receivedport=54530;ms-received-cid=D43C00
Page 64
Content-Length: 0 ms-edge-proxy-message-trust: ms-source-type=AuthorizedServer;ms-epfqdn=srlyncedge1.contoso.com;ms-source-network=publiccloud;ms-source-verifieduser=unverified The proxy message is highlighted in the previous trace. In this proxy message, the mssourcetype is set to AuthorizedServer. The section, MS-Source-Network=PublicCloud, indicates that this message is routing to a public IM provider network.
3 SIP 200 OK
The public IM connectivity user responds with a SIP 200 OK message that actually routes through the public IM connectivity federation gateway. In this case, the MSN Messenger gateway. That SIP 200 OK message is as follows. 06/01/2011|21:21:58.919 13C8:404 INFO :: Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 2129 bytes: 06/01/2011|21:21:58.919 13C8:404 INFO :: SIP/2.0 200 OK ms-user-logon-data: RemoteUser Via: SIP/2.0/TLS 192.168.5.201:54530;received=76.187.107.231;ms-receivedport=54530;ms-received-cid=D43C00 Authentication-Info: TLS-DSK qop="auth", opaque="6FB8C8B0", srand="4836CBAB", snum="236", rspauth="3a328e55565380473d6319f99cd45041ff2de574", targetname="SRLYNCFE1.contoso.com", realm="SIP Communications Service", version=4 FROM: "bob"<sip:bob@contoso.com@contoso.com>;tag=1c291b0356;epid=3821b40476 TO: <sip:<user1>@live.com>;tag=1_476_v51jink9 CSEQ: 1 INVITE CALL-ID: 3f8f4e12386d4f76ba8d286cc0857ca0 RECORD-ROUTE: <sip:federation.messenger.msn.com:5061;transport=tls;lr;ms-keyv=0 o=- 0 0 IN IP4 64.4.16.73 s=session c=IN IP4 64.4.16.73 t=0 0 m=message 5061 sip null a=accept-types:text/plain 06/01/2011|21:21:58.919 13C8:404 INFO :: End of Data Received - 97.75.78.120:443 (To Local Address: 192.168.5.201:54530) 2129 bytes The first highlighted section in the previous trace begins with Record-Route. It shows connectivity to the federation gateway for MSN. The second highlighted section shows the IP address of the federation gateway for MSN, not the public IM connectivity users computer.
4 SIP MESSAGE
Instant messages sent during the SIP TLS session are relayed through the Edge Server and the federation gateway for MSN.
5 SIP BYE
When either user closes the Conversation window, a SIP BYE message will be sent to signal the end of the conversation.
Ms-diagnostics
Ms-diagnostics is an extension of SIP, defined in MS-OCER Client Error Reporting Protocol Specification. It allows diagnostic information to be included in the header in SIP responses. By default, only internal, authenticated SIP traffic includes the diagnostic header
Page 65
information. The Windows PowerShell command Set-CsDiagnosticHeaderConfiguration can be used to include this diagnostic information in external and/or unauthenticated (or not yet authenticated) traffic. Ms-diagnostics uses categories with ID ranges to assign diagnostic IDs to the originating components.
Remote User Access (IM and Presence)

No specific category for IM and presence exists for remote access; however, some of the codes from the SIP stack (category 1, ID from 1000 through 1999) do apply (see Table 3).
Table 3. Codes from the SIP stack applicable to to IM and presence
Diagnostic ID
1010
Reason
Certificate trust with next hop server couldnt be established. Failed to connect to the local Edge Server. Failed to complete TLS negotiation with the local Edge Server. An error occurred routing the remote client connection.
Potential Resolution
This points to a Certificate issue; check certificate trust and certificate name entries. Connectivity issue with the Edge Server. Verify the server is online and configured correctly. There is a certificate/FQDN mismatch on the Edge Server. Connectivity has been lost by the remote client. Connection will be retried, if it fails, validate client connectivity to the Edge Server. Remote access is disabled on the server. Enable remote access on the server. Remote Access is disabled for this user. Assign this user an external access policy that allows remote access (use the EnableOutsideAccess parameter).
1042
1043 1058
1060
Remote user client access is disabled. From URI not enabled for remote access.
4003
Federation
Federation has been assigned ms-diagnostics category 27, meaning the diagnostic ID range is from 27000 through 27999. In addition to the federation specific codes, some of the codes from the SIP stack range (category 1, ID from 1000 through 1999) also apply to federated traffic (see Table 3). IDs that frequently occur are mentioned in Table 4.
Table 4. Common ms-diagnostics IDs for federation
Diagnostic ID
1002
Reason
From URI not authorized to communicate with federated partners. From URI isnt authorized to communicate with users outside the enterprise. Failed to connect to a federated peer server. Failed to complete TLS negotiation
Assign this user an external access policy that allows federation (EnableFederationAccess parameter). User isnt enabled for federation or public IM. Validate connectivity to the federated partner server. Certificate issue, check trust and
1012
1046 1047
Page 66
with a federated peer server. 1048 1049 1065 Connection to a federated peer server failed. Federated peer server pool is out of service. Federation is disabled.
FQDN. Validate connectivity to the federated partner server. Contact the partner and validate the peer server is online. Federation disabled on Access Edge service, correct with SetCsAccessEdgeConfiguration. Add the domain to the allow list on the sending side, NewCsAllowedDomain. Domain is on the block list on the sender side. Add the domain to the allow list on the receiving side, NewCsAllowedDomain. Domain is on the block list on the receiving side.
27000
To-Uri Domain isnt in the sendertenant allow list. To-Uri Domain is blocked by sendertenant block list. From-Uri Domain isnt in the receiver-tenant allow list. From-Uri Domain is blocked by receiver-tenant block list.
27001 27002
27003
Public IM Connectivity
There is no specific ms-diagnostics category for IM and presence; however, some of the codes from the SIP stack (category 1, from ID 1000 through 1999) do apply. Diagnostic codes that frequently occur are listed in Table 5.
Table 5. Common ms-diagnostics for IM and presence
Diagnostic ID
1001
Reason
From URI not authorized to communicate with public IM providers.
Assign this user an external access policy that allows public Internet connectivity (EnablePublicCloudAccess parameter). Validate connectivity to the public IM provider federation gateway. There is a certificate negotiation error between the Edge Server and the public IM provider federation gateway. Validate certificate trusts and certificate name entries. Validate connectivity to the public IM provider federation gateway. Contact the public IM provider to verify the federation service is online.
1050 1051
Failed to connect to a public IM provider. Failed to complete the TLS negotiation with a public IM provider.
1052 1053
Connection to a public IM provider failed. Public IM provider is out of service.
Application Sharing
There is no specific category for application sharing involving remote users. For troubleshooting the previously mentioned generic remote access ms-diagnostic codes can be used in addition to the internal ms-diagnostics for application sharing.
Audio and Video Conferencing

A/V conferencing has been assigned ms-diagnostics category 27 (IDs from 7000 through 7999). Some IDs from the common range (from 0 through 999) also apply to A/V
Page 67
conferencing. Diagnostic codes that frequently occur for remote A/V conferencing scenarios are described in Table 6.
Table 6. Common ms-diagnostics for A/V conferencing
Diagnostic ID
7001
Reason
NAT/Firewall traversal service is not available. Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote Call failed to establish due to a media connectivity failure when both endpoints are remote Call terminated on a mid-call media failure where one endpoint is internal and the other is remote Call terminated on a mid-call media failure where both endpoints are remote.
Check connectivity between the A/V Conferencing Server and the Audio/Video Edge service. This could indicate a network error or Audio/Video Edge service connectivity issues. This could indicate a network error or Audio/Video Edge service connectivity issues. This could indicate configuration issues with the Audio/Video Edge service. This indicates that there was a connectivity issue between the two users. Validate connectivity between the two users.
23
24
33
34
Media Relay Authentication Service (MRAS)

MRAS has been assigned ms-diagnostics category 9, meaning the diagnostic ID range is from 9000 through 9999 as shown in Table 7. These are Audio/Video Edge service authentication errors. Additional information from traces (Error Log Replayer tool for Lync Server) could be required to help identify the cause. (You can download this tool and other Lync Server Resource Kit tools, http://go.microsoft.com/fwlink/?LinkId=203466.)
Table 7. MRAS ms-diagnostic codes
Diagnostic ID
9000
Reason
Request is malformed.
The remote client request is malformed; use tracing for additional information. The client request is too large; no resolution. Check the Lync event log for additional information. The server is over-capacity; validate server capacity. The connection to the MRAS service has timed out; validate connectivity to the Edge Server. Could be a spoofing attempt; use tracing for additional information. The (remote) client version isnt supported. None. Only SIP SERVICE requests are allowed. None.
9001 9002 9004 9005
Request is too large Internal server error Server busy Timeout
9006 9008 9009 9010 9011
Request is forbidden Version not supported Other failure Unsupported message type Unsupported content type
Page 68
9012
Draining
An administrator has prevented new connections.
Page 69
Enterprise Voice
There are no remote Enterprise Voice/PSTN-gatewayspecific ms-diagnostic codes. For troubleshooting, the previously mentioned generic remote access ms-diagnostic codes at the beginning of the Ms-diagnostics section of this chapter can be used in addition to the internal ms-diagnostics for Enterprise Voice located in the Enterprise Voice chapter of the Microsoft Lync Server 2010 Resource Kit book, http://go.microsoft.com/fwlink/? LinkId=211003. For additional troubleshooting related to Enterprise Voice media connectivity in remote access scenarios, see the ICE Protocol section located at the beginning of this chapter.
Summary
In this chapter, the most common call-flow scenarios involving remote user access were described in detail: The core components of Lync Server remote access including ICE protocol/STUN/TURN and MRAS were covered in detail to provide an understanding of remote access functionality. The following scenarios were covered in detail: Instant Messaging: peer-to-peer, internal user to federated partner, and internal user to public IM connectivity user. Conferencing: application sharing conference (desktop sharing), and audio and video Conferencing. Enterprise Voice: peer-to-peer audio, involving two remote participants; peer-topeer audio, involving a federated partner; and a PSTN gateway audio call, involving a remote user. Each section provided a diagram of the call flow for each scenario, appropriate SIP messages, and descriptions of the call flow. Detailed ms-diagnostics information was provided for all applicable workloads. The ms-diagnostics section was provided as a reference for troubleshooting issues with each call flow scenario.
o o o
Additional Resources
For more information, see the following: Ms-diagnostics specifications, [MS-OCER]: Client Error Reporting Protocol Specification, http://go.microsoft.com/fwlink/?LinkId=226347.
Page 70

Chapter 09 External User Access

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Chapter 09 External User Access

Enviado por

Direitos autorais:

Formatos disponíveis

This document is provided as-is.

Microsoft Lync Server 2010 Resource Kit External User Access

Microsoft Lync Server 2010 Resource Kit External User Access

Microsoft Lync Server 2010 Resource Kit External User Access

Microsoft Lync Server 2010 Resource Kit External User Access

Microsoft Lync Server 2010 Resource Kit External User Access

External User Access Scenarios

Instant Messaging and Presence Scenarios

Remote User Access Scenario Overview

Federation Scenario Overview

Microsoft Lync Server 2010 Resource Kit External User Access

Public IM Connectivity Scenario Overview

Enterprise Voice Scenarios

Peer-to-Peer Calls Scenario Overview

Microsoft Lync Server 2010 Resource Kit External User Access

Remote Access User Call to PSTN Gateway Scenario Overview

Remote Access Call from a User to a Federated User Scenario Overview

Microsoft Lync Server 2010 Resource Kit External User Access

Interactive Connectivity Establishment (ICE) Protocol

Figure 1. ICE protocol

Microsoft Lync Server 2010 Resource Kit External User Access

3 STUN binding requests

Microsoft Lync Server 2010 Resource Kit External User Access

Table 1. Most important components of ICE protocol phases

ICE Protocol Phases

Unified Communications Client Platform (UCCP) Log Item

ICE Protocol negotiation address discovery

ICE Protocol Warning Flags

Actions for the Administrator

An attempt to allocate a UDP port on the TURN server failed.

An attempt to send UDP on the TURN server failed.

An attempt to allocate a TCP port on the TURN server failed.

Microsoft Lync Server 2010 Resource Kit External User Access

UDP TURN server connectivity failed.

TCP NAT connectivity failed.

TCP TURN server connectivity failed.

Message integrity failed in connectivity check request.

A policy server was configured.

Microsoft Lync Server 2010 Resource Kit External User Access

TURN server credentials have expired or are unknown.

Bandwidth policy restriction has removed some candidates.

Bandwidth policy restriction decreases the bandwidth.

Bandwidth policy keep-alive failed.

Bandwidth policy allocation failure.

No TURN server configured.

Multiple TURN servers configured.

Port range exhausted.

Microsoft Lync Server 2010 Resource Kit External User Access

HTTP proxy configured.

HTTP proxy authentication failed.

TCP-TCP connectivity checks failed over the TURN Server.

Use candidate checks failed.

Media Relay Authentication Service (MRAS)

Microsoft Lync Server 2010 Resource Kit External User Access

Figure 2. MRAS request sequence

Microsoft Lync Server 2010 Resource Kit External User Access

Microsoft Lync Server 2010 Resource Kit External User Access

4 MRAS RESPONSE to user

Microsoft Lync Server 2010 Resource Kit External User Access

Remote User to the PSTN Gateway

Figure 3. Remote user to PSTN gateway call flow

Microsoft Lync Server 2010 Resource Kit External User Access

Figure 4. Initial SIP trace