Chapter 09 External User Access
-
Upload
khurramullah -
Category
Documents
-
view
269 -
download
3
Transcript of Chapter 09 External User Access
-
7/31/2019 Chapter 09 External User Access
1/70
-
7/31/2019 Chapter 09 External User Access
2/70
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 realassociation or connection is intended or should be inferred.
This document doesnt provide you with any legal rights to any intellectual property in anyMicrosoft 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 PowerShellare trademarks of the Microsoftgroup of companies. All other trademarks are property of their respective owners.
Microsoft Lync Server 2010 Resource Kit External User Access Page 2
-
7/31/2019 Chapter 09 External User Access
3/70
This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currently
being developed. Chapters will be available for download while this book is being completed.To help us improve it, we need your feedback. You can contact us at
[email protected]. Please include the chapter name.
For information about the continuing release of chapters, check the DrRez blog athttp://go.microsoft.com/fwlink/?LinkId=204593.
Microsoft Lync Server 2010 Resource Kit External User Access Page 3
-
7/31/2019 Chapter 09 External User Access
4/70
Contributors
Project Manager: Susan S. Bradley
Content Architect: Rui Maximo
Chapter Lead: Randy Wintle
Writer: Dustin Hannifin
Contributing Writer: Steven van Houttum
TechnicalReviewers: Byron Spurlock,Conal Walsh, Prasad Thota, William Looney
Lead Editor: Kelly Fuller Blue
Art Manager: Jim Bradley
Production Editor: Kelly Fuller Blue
Microsoft Lync Server 2010 Resource Kit External User Access Page 4
-
7/31/2019 Chapter 09 External User Access
5/70
Table of ContentsContributors ................................................................................................................ 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 .................................................................... 8Remote 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
Microsoft Lync Server 2010 Resource Kit External User Access Page 5
-
7/31/2019 Chapter 09 External User Access
6/70
Application Sharing ............................................................................................. 67
Audio and Video Conferencing ............................................................................ 67
Media Relay Authentication Service (MRAS) ........................................................ 68
Enterprise Voice .................................................................................................. 70
Summary .................................................................................................................. 70
Additional Resources ................................................................................................. 70
Microsoft Lync Server 2010 Resource Kit External User Access Page 6
-
7/31/2019 Chapter 09 External User Access
7/70
External User Access ScenariosMicrosoft 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 followingsections. 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 InteractiveConnectivity 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 byusing the Lync Server Access Edge service. The following scenario overviews describeremote 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. Remoteuser 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 betweentwo 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 orMicrosoft Office Communications Server deployment. Federation allows Lync 2010 users
to communicate with users in other organizations that have Lync Server or OfficeCommunications 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
Microsoft Lync Server 2010 Resource Kit External User Access Page 7
-
7/31/2019 Chapter 09 External User Access
8/70
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 instantmessages 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 aresupported by the Web Conferencing Edge service and the Audio/Video Edge service.
The following scenario overview describes audio and video conferences for users that workfor 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 thePSTN 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 involvethe PSTN gateway.
The following scenario overview shows that Bob and Alice are working from their respectivehome 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.
Microsoft Lync Server 2010 Resource Kit External User Access Page 8
-
7/31/2019 Chapter 09 External User Access
9/70
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 isan 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 afederated 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.
Microsoft Lync Server 2010 Resource Kit External User Access Page 9
-
7/31/2019 Chapter 09 External User Access
10/70
Interactive Connectivity Establishment (ICE) ProtocolAn 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 protocolconnectivity checks are referenced in all the call flows in this chapter. It is important tohave a general understanding of what is happening during an ICE protocol connectivity
check, including how the ICE protocol candidates are identified prior to performingconnectivity 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 inFigure 1. The heading numbers correspond to the sequence numbers (connectors) in Figure
1.
1 SIP INVITEFigure 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 issent. 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 followingcandidates:
Microsoft Lync Server 2010 Resource Kit External User Access Page 10
-
7/31/2019 Chapter 09 External User Access
11/70
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 pathpossible 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 betweenport 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.
Microsoft Lync Server 2010 Resource Kit External User Access Page 11
-
7/31/2019 Chapter 09 External User Access
12/70
Table 1. Most important components of ICE protocol phases
ICE Protocol Phases Unified Communications Client Platform (UCCP) LogItem
AVEdgeProvisioning Search mrasuri for a SIP 200OK provisioning response.Confirms that that pool is configured with the Audio/Video Edgeservice.
AVEdgeCredentials Search credentialsRequestID for SIP SERVICE.Confirms that the Audio/Video Edge service is running andreachable on TCP5062.
ICE Protocol negotiation The UCCP log Item.
address discovery 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.
Address exchange 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 Edgeservice.
Connectivity checks Check RE-INVITE (see Candidate promotion for the connectivitycheck result.Confirms that the connectivity check is complete.
Candidate promotion Search for a=remote-candidate.INVITE and 200OK should have only one candidate pair.Confirms that candidate promotion is complete and the path thatthe ICE protocol was negotiated.
Table 2 describes what happens when these ICE protocol warning flags occur. These flagsare 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 thefollowing 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 Description Actions for the Administrator
0x0 There were no failures or the ICEprotocol was not used.
None.
0x1 TURN server is unreachable. This flag is not expected.Administrator need to ensure that theright ports (443/3478by default)are open on the firewall or the TURNserver is running. This may result inan ICE protocol failure.
0x2 An attempt to allocate a UDP port onthe TURN server failed.
This flag may be expected if theclient is behind a UDP blockingfirewall. This may result in an ICEprotocol failure.
0x4 An attempt to send UDP on theTURN server failed.
This flag may be expected if theclient is behind a UDP blockingfirewall. This may result in an ICEprotocol failure.
0x8 An attempt to allocate a TCP port onthe TURN server failed.
This flag isnt expected. Theadministrator needs to check the
Microsoft Lync Server 2010 Resource Kit External User Access Page 12
-
7/31/2019 Chapter 09 External User Access
13/70
firewall policy, and ensure thatAudio/Video Edge service isreachable. If the client is behind anHTTP proxy, the administrator needsto ensure that the proxy isnt failingthe TLS attempt. This failure mayresult in an ICE protocol failure.
0x10 An attempt to send TCP on theTURN server failed.
This flag isnt expected. Theadministrator needs to check thefirewall policy, and ensure that
Audio/Video Edge service isreachable. If the remote client isbehind an HTTP proxy, the adminneeds to ensure that the proxy isntfailing the TLS attempt. This failuremay result in an ICE protocol failure.
0x20 Local connectivity failed. (local UDPfor audio/video and local TCP forapplication sharing and file transfer).
This flag can occur if the directconnection between clients isntpossible due to NAT/firewalls. Thismay result in an ICE protocol failure.
0x40 UDP NAT connectivity failed. This flag can occur if the direct
connection between clients isntpossible due to NAT/firewalls. Thismay result in an ICE protocol failure.
0x80 UDP TURN server connectivityfailed.
This flag can occur if one of theclients is behind a UDP blockingfirewall/HTTP proxy. This may resultin an ICE protocol failure.
0x100 TCP NAT connectivity failed. This flag is expected. If local-to-localconnectivity succeeded, the TCPNAT connectivity check may nothave been tried. Or there is no directTCP connection possible. TCP NATconnectivity failing may result in anICE protocol failure.
0x200 TCP TURN server connectivityfailed.
This flag is expected. If local-to-localconnectivity succeeded, the TCPTURN connectivity check may nothave been tried. Or one side didnthave TURN server allocation. Ifconnectivity checks were successfulfor the rest of the call, ignore this ICEprotocol warning. Otherwise,investigate why the TCP path wasnot possible. TCP TURN serverconnectivity failing may result in anICE protocol failure.
0x400 Message integrity failed inconnectivity check request.
This flag isnt expected. If the adminsees this flag, it indicates some
security attack. This may result in anICE protocol failure.
0x1000 A policy server was configured. This flag is expected if there is abandwidth policy configured on thecall link. If there is a call failure withthis flag, increase the allocatedbandwidth on the failed link. This flagisnt indicating any ICE protocolfailure, simply that there was abandwidth policy applied to this call.
Microsoft Lync Server 2010 Resource Kit External User Access Page 13
-
7/31/2019 Chapter 09 External User Access
14/70
0x2000 Connectivity check requested failedbecause of a memory problem orother reasons that preventedsending packets.
This flag is unexpected and mayindicate that a computer is overcapacity This may result in an ICEprotocol failure.
0x4000 TURN server credentials have
expired or are unknown.
This flag is unexpected and may
indicate that Audio/Video Edgeservice authorization service isdown. This may result in an ICEprotocol failure.
0x8000 Bandwidth policy restriction hasremoved some candidates.
If there is an ICE protocol failure withthis flag set, this indicates that thepolicy server topology ismisconfigured. In this configurationthe policy was configured to routeover another connection, but theother connection failed. (Possibilityof internal NATs in the org). This flagmay result in an ICE protocol failure.
0x10000 Bandwidth policy restriction
decreases the bandwidth.
This flag indicates that the bandwidth
being used on this call isnt optimalquality (may be using a narrow-bandcodec or may not be capable of HDvideo). This flag does not indicateany ICE protocol failure.
0x20000 Bandwidth policy keep-alive failed. This is unexpected. The callcontinues but the bandwidth used bythis call may not be reported properlyto the Bandwidth Policy CoreService. This can occur because thepolicy server or the TURN serverhave failed. This flag does notindicate any ICE protocol failure.
0x40000 Bandwidth policy allocation failure. This flag is indicating that the policy
server rejected the client to use amedia path through two Audio/VideoEdge services (relay to relay). Thismay result in an ICE protocol failure.
0x80000 No TURN server configured. This flag is indicating that there wasno TURN server configured or thereis a Domain Name System (DNS)resolution failure, resulting in acommunication issue between theclient and the TURN server. Thismay result in a protocol ICE failure.
0x100000 Multiple TURN servers configured. This flag is expected. This isindicating that there were multipleTURN servers configured (due to
DNS load balancing). This flag doesnot indicate any ICE protocol failure.
0x200000 Port range exhausted. This is indicating that theadministrator manually configuredports on the client or the mediaserver. A/V needs a minimum of 20ports per call to start the call.
Application sharing/file transferneeds a minimum of 3 ports. Theport range being exhausted may
Microsoft Lync Server 2010 Resource Kit External User Access Page 14
-
7/31/2019 Chapter 09 External User Access
15/70
result in an ICE protocol failure.
0x400000 Received alternate server .
This is indicating that the TURNserver is overloaded or preventingnew connections. This may result inan ICE protocol failure if thealternate server isnt running
0x800000 Pseudo-TLS failure. This is indicating that the HTTPproxy is performing deep SecureSockets Layer (SSL) inspection andfailing the connection with the TURNserver. This is not supported byMicrosoft and may result in an ICEprotocol failure.
0x1000000 HTTP proxy configured. This is indicating that the HTTPproxy is configured This flag doesnot indicate any ICE protocol failure.
0x2000000 HTTP proxy authentication failed. This is indicating that the HTTPproxy failed the authentication. Thisisnt expected and indicates that theHTTP proxy didnt recognize theusers credentials or authenticationmode. This may result in an ICEprotocol failure.
0x4000000 TCP-TCP connectivity checks failedover the TURN Server.
This is indicating that TURN TCP-TCP connectivity check was triedand it failed. The failure indicatesthat port 443 was not opened on thefirewall. If one of the TURN serverswas 2007 A/V Edge Server. Theadministrator needs to open portsfrom 50,000 through 59,999 TCP toall external Audio/Video Edgeservices in the environment. Thisflag isnt expected and may result inan ICE protocol failure.
0x80000000 Use candidate checks failed. This is indicating that after receivingsome packets the client didntreceive the rest of the packets. Thismay happen on a client because of athird Winsock layered serviceproviders (LSPs). These LSPsshould be removed. This flag isntexpected and may result in an ICEprotocol failure.
Media Relay Authentication Service (MRAS)
The Media Relay Authentication Service (MRAS) generates credentials required for externalmedia 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/VideoEdge 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. MRASgenerates 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
Microsoft Lync Server 2010 Resource Kit External User Access Page 15
-
7/31/2019 Chapter 09 External User Access
16/70
-
7/31/2019 Chapter 09 External User Access
17/70
02/09/2011|10:00:41.608 1B9C:A24 INFO :: Sending Packet - 208.115.110.XXX:443 (FromLocal Address: 192.168.1.138:54415) 1334 bytes:
02/09/2011|10:00:41.608 1B9C:A24 INFO :: SERVICEsip:[email protected];gruu;opaque=srvr:MRAS:v6H_I-uZa1irVldx3Z_CdgAA SIP/2.0
Via: SIP/2.0/TLS 192.168.1.138:54415
Max-Forwards: 70From: ;tag=6adfd24c1b;epid=92a17ee2ce
To:
Call-ID: 0ba8a0c30bf74534a7d94a182b4d72f8
CSeq: 1 SERVICEContact:
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
sip: @contoso.cominternet480
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 bytes3 MRAS RESPONSE
Stage 3 is an MRAS response. The MRAS service on the Edge Server responds to the Edgepools 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/VideoEdge service use this password for encrypting and decrypting media traffic.
The following example SIP message displays the password within the password tag. A singlemedia 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 externalFQDNs 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 withinthe hostname tag.
02/09/2011|10:00:41.873 1B9C:A24 INFO :: Data Received - 208.115.110.XXX:443 (To LocalAddress: 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;ms-received-cid=4113100
Microsoft Lync Server 2010 Resource Kit External User Access Page 17
-
7/31/2019 Chapter 09 External User Access
18/70
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";tag=6adfd24c1b;epid=92a17ee2ceTO: ;tag=109dbc90a0
CSEQ: 1 SERVICECALL-ID: 0ba8a0c30bf74534a7d94a182b4d72f8
CONTENT-LENGTH: 973
CONTENT-TYPE: application/msrtc-media-relay-auth+xmlSERVER: RTCC/4.0.0.0 MRAS/2.0
AgAAJEqlo9QBy8itWiOmR2d4zw8ZJqfwTPDagP7i95AAAAAAbdyNu23CueVPKAjFdxLksF0ihSk=
eulmSPLxOMZZAYZvkq78HBo2uSk=
480
internet
AVEDGEEXTERNAL.contoso.com
3478
443
02/09/2011|10:00:41.873 1B9C:A24 INFO :: End of Data Received - 208.115.110.143:443 (ToLocal 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 OKmessage through the Access Edge service.
Microsoft Lync Server 2010 Resource Kit External User Access Page 18
-
7/31/2019 Chapter 09 External User Access
19/70
Enterprise VoiceThis section provides details about call flows and the diagnostics codes for each EnterpriseVoice scenario that was described earlier in this chapter. These scenarios include peer-to-
peer 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 (SIPtraffic) 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 themedia, 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 inFigure 3.
Figure 3. Remote user to PSTN gateway call flow
The following numbered headings describe the remote user to PSTN gateway call flowsequence 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 caninitiate 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
Microsoft Lync Server 2010 Resource Kit External User Access Page 19
-
7/31/2019 Chapter 09 External User Access
20/70
completed the MRAS credential process, it first makes a STUN request to the Audio/VideoEdge 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 Serverstores this Username for future credential matches.
Because the initial allocation request didnt contain a Message-Integrity attribute, theEdge 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 isused 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 andpassword 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 requestand 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 requestpacket 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 requestthrough 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 thenew 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.
Microsoft Lync Server 2010 Resource Kit External User Access Page 20
-
7/31/2019 Chapter 09 External User Access
21/70
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 theremote 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 streambetween 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, aspart 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 isused to obfuscate the XORMappedAddress attribute. Figure 7 defines this attribute in moredetail.
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 specificallyfor 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.
Microsoft Lync Server 2010 Resource Kit External User Access Page 21
-
7/31/2019 Chapter 09 External User Access
22/70
o 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.
o 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 thereflexive 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/VideoEdge 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 theAudio/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 showsthe 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 Lync2010 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 mediaconnectivity. 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 protocolversion 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 theAudio/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 addressesare 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 negotiatedto 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 theseaddresses:
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 (FromLocal Address: 192.168.1.138:49383) 7473 bytes:
Microsoft Lync Server 2010 Resource Kit External User Access Page 22
-
7/31/2019 Chapter 09 External User Access
23/70
02/09/2011|09:29:53.518 17F8:14CC INFO :: INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.138:49383
Max-Forwards: 70
From: ;tag=38849ad51a;epid=92a17ee2ce
To:
Call-ID: b611ecca854b47c78b82aade563ef0d0CSeq: 1 INVITE
Contact:
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 1p6ws7wYJioXkgVwF0sQzyw UDP 0.830 192.168.1.145 2002
a=candidate:RVe1AuhxobPEwFDgYqBzJ8nl5vntofS4rnotr5E8Z1U 2p6ws7wYJioXkgVwF0sQzyw UDP 0.830 192.168.1.145 2003
a=candidate:kmclxGgIOHZ5uHpiwod6Paa7GuZhvObH9645kR57fJw 1vHMsvL8TfBDYplWUcT1Iaw TCP 0.190 208.115.110.145 51100
a=candidate:kmclxGgIOHZ5uHpiwod6Paa7GuZhvObH9645kR57fJw 2vHMsvL8TfBDYplWUcT1Iaw TCP 0.190 208.115.110.145 51100
a=candidate:ARSbz17KVDCKJsVk1FEI8yds49P7hdS7Pz7unidpn+0 1U8jWmquvW+usL6V4dRpPFw UDP 0.490 208.115.110.145 56796
a=candidate:ARSbz17KVDCKJsVk1FEI8yds49P7hdS7Pz7unidpn+0 2U8jWmquvW+usL6V4dRpPFw UDP 0.490 208.115.110.145 58970
a=candidate:hX1xn5LNhrXdUYZeJBi0TMahMVdn0YhYoO4xSgJIgSc 1
n3WhQS9pjzIdzKnSwUe2eQ TCP 0.250 69.193.68.231 19114a=candidate:hX1xn5LNhrXdUYZeJBi0TMahMVdn0YhYoO4xSgJIgSc 2n3WhQS9pjzIdzKnSwUe2eQ TCP 0.250 69.193.68.231 19114
a=candidate:FCn6Kmwij+Fzz87HpJ27MqlofJLD2iQwjO6pK+vKvd8 16MH8o37XC6WebAwkJ/zqmw UDP 0.550 69.193.68.231 20176
a=candidate:FCn6Kmwij+Fzz87HpJ27MqlofJLD2iQwjO6pK+vKvd8 26MH8o37XC6WebAwkJ/zqmw UDP 0.550 69.193.68.231 20177
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80inline:LdrtV/jRXmdUtT4B7q4wf0H2nnoULlwIYA3Pjesw|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80inline:Ov/D89GRsNLnGhLvmzKHBeZd4OgZaqaTsiGpGfFC|2^31|1:1a=crypto:3 AES_CM_128_HMAC_SHA1_80
inline:EWaGm7ejfZREz2lh678C3N4EGMj7lMeWx0AFQEYA|2^31a=maxptime:200
a=rtcp:58970
a=rtpmap:114 x-msrta/16000
a=fmtp:114 bitrate=29000a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:111 SIREN/16000
Microsoft Lync Server 2010 Resource Kit External User Access Page 23
-
7/31/2019 Chapter 09 External User Access
24/70
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/8000a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000a=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 hosta=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.231rport 23371
a=candidate:6 2 TCP-PASS 6556158 208.115.110.145 58943 typ relay raddr 69.193.68.231
rport 23371a=candidate:7 1 UDP 16648703 208.115.110.145 56825 typ relay raddr 69.193.68.231 rport19204
a=candidate:7 2 UDP 16648702 208.115.110.145 54147 typ relay raddr 69.193.68.231 rport19205
a=candidate:8 1 UDP 1694233599 69.193.68.231 19204 typ srflx raddr 192.168.1.138 rport19204
a=candidate:8 2 UDP 1694232062 69.193.68.231 19205 typ srflx raddr 192.168.1.138 rport19205
a=candidate:9 1 TCP-ACT 7074303 208.115.110.145 58943 typ relay raddr 69.193.68.231rport 23371
a=candidate:9 2 TCP-ACT 7073790 208.115.110.145 58943 typ relay raddr 69.193.68.231rport 23371
a=candidate:10 1 TCP-ACT 1684795391 69.193.68.231 23371 typ srflx raddr 192.168.1.138rport 23371
a=candidate:10 2 TCP-ACT 1684794878 69.193.68.231 23371 typ srflx raddr 192.168.1.138rport 23371
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80inline:LdrtV/jRXmdUtT4B7q4wf0H2nnoULlwIYA3Pjesw|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80inline:Ov/D89GRsNLnGhLvmzKHBeZd4OgZaqaTsiGpGfFC|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80inline:EWaGm7ejfZREz2lh678C3N4EGMj7lMeWx0AFQEYA|2^31
a=maxptime:200
a=rtcp:54147
a=rtpmap:114 x-msrta/16000a=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
Microsoft Lync Server 2010 Resource Kit External User Access Page 24
-
7/31/2019 Chapter 09 External User Access
25/70
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/16000a=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 thedial 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. Thefollowing 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 LocalAddress: 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;ms-received-cid=40C0A00
From: "bob";tag=38849ad51a;epid=92a17ee2ce
To: Call-ID: b611ecca854b47c78b82aade563ef0d0
CSeq: 1 INVITE
ms-diagnostics: 12006;reason="Trying nexthop";source="mediationfqdn.contoso.com";PhoneUsage="Local";PhoneRoute="ContosoAll";Gateway="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 (ToLocal 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 mustsend a STUN request to bind to the Mediation Server. The same STUN allocation process (aspreviously 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 containscandidate 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 LocalAddress: 192.168.1.138:49383) 2993 bytes:
Microsoft Lync Server 2010 Resource Kit External User Access Page 25
-
7/31/2019 Chapter 09 External User Access
26/70
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;ms-received-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=4FROM: "bob";tag=38849ad51a;epid=92a17ee2ce
TO: ;tag=6ec3e129b2;epid=E79516971F
CSEQ: 1 INVITECALL-ID: b611ecca854b47c78b82aade563ef0d0
RECORD-ROUTE:
CONTACT:;isGateway
CONTENT-LENGTH: 1467
SUPPORTED: replaces
SUPPORTED: ms-safe-transfer
SUPPORTED: ms-bypassSUPPORTED: 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:
Rseq: 1
Record-Route:
Record-Route:
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:57341a=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.72rport 51707
a=candidate:2 2 tcp-pass 6555134 208.115.110.145 54945 typ relay raddr 192.168.5.72rport 51707
Microsoft Lync Server 2010 Resource Kit External User Access Page 26
-
7/31/2019 Chapter 09 External User Access
27/70
a=candidate:3 1 UDP 16647679 208.115.110.145 58745 typ relay raddr 192.168.5.72 rport56854
a=candidate:3 2 UDP 16647678 208.115.110.145 58162 typ relay raddr 192.168.5.72 rport56855a=candidate:4 1 tcp-act 7076863 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport51707
a=candidate:4 2 tcp-act 7076350 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport51707
a=candidate:5 1 tcp-act 1684797951 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport51707
a=candidate:5 2 tcp-act 1684797438 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport51707
a=label:main-audio
a=crypto:2 AES_CM_128_HMAC_SHA1_80inline: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
3 STUN binding requests
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 ishappening, the Mediation Server sends an INVITE and an outbound call through the PSTNgateway 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 LocalAddress: 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;ms-received-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";tag=38849ad51a;epid=92a17ee2ceTO: ;tag=6ec3e129b2;epid=E79516971F
CSEQ: 1 INVITECALL-ID: b611ecca854b47c78b82aade563ef0d0
RECORD-ROUTE:
CONTACT: ;isGateway
CONTENT-LENGTH: 0
Microsoft Lync Server 2010 Resource Kit External User Access Page 27
-
7/31/2019 Chapter 09 External User Access
28/70
SUPPORTED: replaces
SUPPORTED: ms-safe-transfer
SUPPORTED: ms-bypass
SUPPORTED: gruu-10
ALLOW: CANCEL
ALLOW: BYE
ALLOW: UPDATEALLOW: PRACK
SERVER: RTCC/4.0.0.0 MediationServer
ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranetMs-Accepted-Content-ID:
Record-Route:
Record-Route:
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 2010client 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 LocalAddress: 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;ms-received-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";tag=38849ad51a;epid=92a17ee2ce
TO: ;tag=6ec3e129b2;epid=E79516971F
CSEQ: 1 INVITECALL-ID: b611ecca854b47c78b82aade563ef0d0
RECORD-ROUTE:
CONTACT:;isGateway
CONTENT-LENGTH: 1467
SUPPORTED: replaces
SUPPORTED: ms-safe-transferSUPPORTED: ms-bypass
SUPPORTED: ms-dialog-route-set-update
SUPPORTED: gruu-10
SUPPORTED: timer
SUPPORTED: 100rel
CONTENT-TYPE: application/sdp
ALLOW: ACK
P-ASSERTED-IDENTITY:
Microsoft Lync Server 2010 Resource Kit External User Access Page 28
-
7/31/2019 Chapter 09 External User Access
29/70
SERVER: RTCC/4.0.0.0 MediationServer
ms-diagnostics: 10032;source="mediationfqdn.contoso.com";reason="Media diagnosticinformation";component="MediationServer";ICEWarningFlags="Audio:ICEWarn=0x0,LocalSite=192.168.5.72:51707,LocalMR=208.115.110.145:54945,RemoteSite=69.193.68.231:23371,RemoteMR=208.115.110.145:58943,PortRange=49152:57500,LocalMRTCPPort=54945,RemoteMRTCPPort=58943,LocalLocation=2,RemoteLocation=1,FederationType=0"
ms-diagnostics-public: 10032;reason="Media diagnosticinformation";component="MediationServer"
ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet
Ms-Accepted-Content-ID:
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:
Record-Route:
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 hosta=candidate:2 1 tcp-pass 6555135 208.115.110.145 54945 typ relay raddr 192.168.5.72rport 51707a=candidate:2 2 tcp-pass 6555134 208.115.110.145 54945 typ relay raddr 192.168.5.72rport 51707
a=candidate:3 1 UDP 16647679 208.115.110.145 58745 typ relay raddr 192.168.5.72 rport56854
a=candidate:3 2 UDP 16647678 208.115.110.145 58162 typ relay raddr 192.168.5.72 rport56855
a=candidate:4 1 tcp-act 7076863 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport51707
a=candidate:4 2 tcp-act 7076350 208.115.110.145 54945 typ relay raddr 192.168.5.72 rport
51707a=candidate:5 1 tcp-act 1684797951 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport51707
a=candidate:5 2 tcp-act 1684797438 192.168.5.72 51707 typ srflx raddr 192.168.5.72 rport51707
a=label:main-audio
a=crypto:2 AES_CM_128_HMAC_SHA1_80inline:B+8cuezdQGjtYxuYMgwl+fsul/jXZ3UjDuk15eWm|2^31|1:1
a=rtpmap:0 PCMU/8000
Microsoft Lync Server 2010 Resource Kit External User Access Page 29
-
7/31/2019 Chapter 09 External User Access
30/70
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/8000a=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 valuablediagnostics 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, ifthere 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 diagnosticinformation";component="MediationServer";ICEWarningFlags="Audio:ICEWarn=0x0,LocalSite=192.168.5.72:51707,LocalMR=208.115.110.145:54945,RemoteSite=69.193.68.231:23371,RemoteMR=208.115.110.145:58943,PortRange=49152:57500,LocalMRTCPPort=54945,RemoteMRTCPPort=58943,LocalLocation=2,RemoteLocation=1,FederationType=0"
If the ICEWarningFlags attribute has any warnings other than 0x0, you can use Table 2 toidentify the cause of any connectivity issues.
To confirm that the Lync 2010 client is aware that the call was answered from the PSTNgateway 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 ishighlighted 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 (FromLocal Address: 192.168.1.138:49383) 1069 bytes:
02/09/2011|09:30:02.540 17F8:14CC INFO :: ACKsip:[email protected];gruu;opaque=srvr:MediationServer:ncplWOC7OlG_RwF7QhCWbwAA;grid=c10e6dbff3374014a10d91ac8c1a5f74 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.138:49383
Max-Forwards: 70
From: ;tag=38849ad51a;epid=92a17ee2ceTo: ;tag=6ec3e129b2;epid=E79516971F
Call-ID: b611ecca854b47c78b82aade563ef0d0
CSeq: 1 ACKRoute:
Route:
Route:
User-Agent: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010)
Microsoft Lync Server 2010 Resource Kit External User Access Page 30
-
7/31/2019 Chapter 09 External User Access
31/70
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 bytesWhen 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 ishighlighted 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 (FromLocal Address: 192.168.1.138:49383) 1134 bytes:
02/09/2011|09:30:06.395 17F8:14CC INFO :: BYEsip:[email protected];gruu;opaque=srvr:MediationServer:ncplWOC7OlG_RwF7QhCWbwAA;grid=c10e6dbff3374014a10d91ac8c1a5f74 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.138:49383
Max-Forwards: 70
From: ;tag=38849ad51a;epid=92a17ee2ce
To: ;tag=6ec3e129b2;epid=E79516971FCall-ID: b611ecca854b47c78b82aade563ef0d0
CSeq: 3 BYE
Route:
Route:
Route:
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 callinformation, 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 MicrosoftMessage 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 plaintext 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 (FromLocal Address: 192.168.1.138:49383) 5769 bytes:
02/09/2011|09:30:06.627 17F8:14CC INFO :: SERVICEsip:[email protected];gruu;opaque=srvr:HomeServer:i8hSASSjHFe4rJJ6SMmzzAAA SIP/2.0
Via: SIP/2.0/TLS 192.168.1.138:49383Max-Forwards: 70
Microsoft Lync Server 2010 Resource Kit External User Access Page 31
-
7/31/2019 Chapter 09 External User Access
32/70
From: ;tag=c8c8d1f7c6;epid=92a17ee2ce
To:Call-ID: 373cabd122e54082a9b751c129e013d7
CSeq: 1 SERVICE
Contact: 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+xmlContent-Length: 4921
sip:[email protected]:[email protected];user=phonetruesip:[email protected];opaque=user:epid:1dRPOJppUlG-Qszig4EXYgAA;gruusip:[email protected];gruu;opaque=srvr:MediationServer:ncplWOC7OlG_RwF7QhCWbwAA;grid=c10e6dbff3374014a10d91ac8c1a5f74UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync2010)RTCC/4.0.0.0
MediationServerfalse192.168.5.20falseFAILED0SRTPwiredfalse0192.168.1.13819204255.255.255.0208.115.110.1453478Headset Microphone(3- BUA-200M)Microsoft:
6.1.7600.16385Headset Earphone(3- BUA-200M)Microsoft:6.1.7600.1638533000018075
-
7/31/2019 Chapter 09 External User Access
33/70
Avg>0000PCMU8000-831.239027230123132610PCMU8000-64false150800StaticMax0000000000000000
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 bytesThe call ends with a 200 OK message from the Mediation Server, acknowledging that theuser ended the call.
02/09/2011|09:30:06.804 17F8:14CC INFO :: Data Received - 208.115.110.143:443 (To LocalAddress: 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;ms-received-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: ;tag=38849ad51a;epid=92a17ee2ceTO: ;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
Microsoft Lync Server 2010 Resource Kit External User Access Page 33
-
7/31/2019 Chapter 09 External User Access
34/70
02/09/2011|09:30:06.804 17F8:14CC INFO :: End of Data Received - 208.115.110.143:443 (ToLocal 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 thatcommunications 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 PSTNgateway 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 candidatesto 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
Microsoft Lync Server 2010 Resource Kit External User Access Page 34
-
7/31/2019 Chapter 09 External User Access
35/70
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 rport21890
a=candidate:4 2 TCP-PASS 6556158 97.75.78.122 53946 typ relay raddr 192.168.16.68 rport21890
a=candidate:5 1 UDP 16648703 97.75.78.122 54499 typ relay raddr 192.168.16.68rport 28180
a=candidate:5 2 UDP 16648702 97.75.78.122 50178 typ relay raddr 192.168.16.68rport 28181
a=candidate:6 1 TCP-ACT 7075839 97.75.78.122 53946 typ relay raddr 192.168.16.68 rport21890
a=candidate:6 2 TCP-ACT 7075326 97.75.78.122 53946 typ relay raddr 192.168.16.68 rport21890
a=candidate:7 1 TCP-ACT 1684796927 192.168.16.68 21890 typ srflx raddr 192.168.16.68rport 21890
a=candidate:7 2 TCP-ACT 1684796414 192.168.16.68 21890 typ srflx raddr 192.168.16.68rport 21890
Highlighted and in bold is the callers Audio/Video Edge service relay address that is beingsent 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+PGa=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 hosta=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 hosta=candidate:6 1 TCP-PASS 6556159 208.115.110.145 55726 typ relay raddr 69.193.68.231
rport 14824a=candidate:6 2 TCP-PASS 6556158 208.115.110.145 55726 typ relay raddr 69.193.68.231rport 14824
a=candidate:7 1 UDP 16648703 208.115.110.145 56517 typ relay raddr 69.193.68.231 rport3048
a=candidate:7 2 UDP 16648702 208.115.110.145 52305 typ relay raddr 69.193.68.231 rport3049
a=candidate:8 1 UDP 1694233599 69.193.68.231 3048 typ srflx raddr192.168.1.108 rport 3048
Microsoft Lync Server 2010 Resource Kit External User Access Page 35
-
7/31/2019 Chapter 09 External User Access
36/70
a=candidate:8 2 UDP 1694232062 69.193.68.231 3049 typ srflx raddr192.168.1.108 rport 3049
a=candidate:9 1 TCP-ACT 7074303 208.115.110.145 55726 typ relay raddr 69.193.68.231rport 14824a=candidate:9 2 TCP-ACT 7073790 208.115.110.145 55726 typ relay raddr 69.193.68.231rport 14824
a=candidate:10 1 TCP-ACT 1684795391 69.193.68.231 14824 typ srflx raddr 192.168.1.108rport 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 checksto determine the optimal path for the call.
3 STUN binding requests
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 callersAudio/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 theattempted 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/TURNmessages. The STUN binding requests are encapsulated in the tunneled packets. These
requests arent shown here; however, they are similar to other STUN/TURN bindingrequests.
Microsoft Lync Server 2010 Resource Kit External User Access Page 36
-
7/31/2019 Chapter 09 External User Access
37/70
The trace in Figure 11 shows the STUN binding request that is made to the reflexive IPaddress 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 updatedcandidate 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 rport28180
a=candidate:5 2 UDP 16648702 97.75.78.122 50178 typ relay raddr 192.168.16.68 rport28181
a=crypto:2 AES_CM_128_HMAC_SHA1_80inline: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 thecaller 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 rport28680
a=candidate:11 2 UDP 1862268414 69.193.68.231 28681 typ prflx raddr 192.168.1.108 rport28681
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:+WS9epy32zB3aXLCOxk9Uiks0QWocDY/TcceMWW+|2^31|1:1
Microsoft Lync Server 2010 Resource Kit External User Access Page 37
-
7/31/2019 Chapter 09 External User Access
38/70
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 serviceis 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 willbe 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 (FromLocal Address: 192.168.1.108:59067) 2383 bytes:
05/27/2011|10:51:17.946 2A54:2118 INFO :: BYE sip:[email protected];opaque=user:epid:PTRheATWGFK-z3HXNaHc6gAA;gruu SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:59067
Max-Forwards: 70
From: "" ;epid=92a17ee2ce;tag=8c4b1f7e5c
To: ;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, theICE 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 tworemote 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 itthrough 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.
Microsoft Lync Server 2010 Resource Kit External User Access Page 38
-
7/31/2019 Chapter 09 External User Access
39/70
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) inFigure 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 connectover 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 candidatesfor 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 (FromLocal Address: 10.180.181.223:62230) 7439 bytes:
05/31/2011|16:55:25.856 2D7C:1FF8 INFO :: INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 10.180.181.223:62230
Max-Forwards: 70
From: ;tag=c4a189acf6;epid=92a17ee2ce
To:
Call-ID: eb472e8ebc384c68a07b1e5beb70be38CSeq: 1 INVITE
Microsoft Lync Server 2010 Resource Kit External User Access Page 39
-
7/31/2019 Chapter 09 External User Access
40/70
In the INVITE, the user also sends the candidate list (like all other remote calls). In thefollowing 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 hosta=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.235rport 30907
a=candidate:6 2 TCP-PASS 6556158 208.115.110.145 50162 typ relay raddr 166.248.0.235
rport 30907a=candidate:7 1 UDP 16648703 208.115.110.145 55336 typ relay raddr 166.248.0.235 rport52259
a=candidate:7 2 UDP 16648702 208.115.110.145 54267 typ relay raddr 166.248.0.235 rport52282
a=candidate:8 1 UDP 1694233599 166.248.0.235 52259 typ srflx raddr 10.180.181.223 rport11252
a=candidate:8 2 UDP 1694232062 166.248.0.235 52282 typ srflx raddr 10.180.181.223 rport11253
a=candidate:9 1 TCP-ACT 7074303 208.115.110.145 50162 typ relay raddr 166.248.0.235rport 30907
a=candidate:9 2 TCP-ACT 7073790 208.115.110.145 50162 typ relay raddr 166.248.0.235
rport 30907a=candidate:10 1 TCP-ACT 1684795391 166.248.0.235 30907 typ srflx raddr 10.180.181.223rport 15645
a=candidate:10 2 TCP-ACT 1684794878 166.248.0.235 30907 typ srflx raddr 10.180.181.223rport 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 LocalAddress: 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-received-port=30906;ms-received-cid=73BB7D00
From: "bob";tag=c4a189acf6;epid=92a17ee2ce
To: ;epid=73f1df72ee;tag=ed247c795fCall-ID: eb472e8ebc384c68a07b1e5beb70be38
Microsoft Lync Server 2010 Resource Kit External User Access Page 40
-
7/31/2019 Chapter 09 External User Access
41/70
CSeq: 1 INVITE
Record-Route:Contact:
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 thefollowing 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.251rport 4523
a=candidate:2 2 TCP-PASS 6556158 208.115.110.145 55275 typ relay raddr 75.98.19.251rport 4523
a=candidate:3 1 UDP 16648703 208.115.110.145 57501 typ relay raddr 75.98.19.251 rport
32250a=candidate:3 2 UDP 16648702 208.115.110.145 56075 typ relay raddr 75.98.19.251 rport32251
a=candidate:4 1 UDP 1694235647 75.98.19.251 32250 typ srflx raddr 10.104.72.9 rport32250
a=candidate:4 2 UDP 1694234110 75.98.19.251 32251 typ srflx raddr 10.104.72.9 rport32251
a=candidate:5 1 TCP-ACT 7076351 208.115.110.145 55275 typ relay raddr 75.98.19.251 rport4523
a=candidate:5 2 TCP-ACT 7075838 208.115.110.145 55275 typ relay raddr 75.98.19.251 rport4523
a=candidate:6 1 TCP-ACT 1684797439 75.98.19.251 4523 typ srflx raddr 10.104.72.9 rport4523
a=candidate:6 2 TCP-ACT 1684796926 75.98.19.251 4523 typ srflx raddr 10.104.72.9 rport4523
3 STUN binding requests
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 (seeFigure 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. Thisvalidates the media path (see Figure 14).
Microsoft Lync Server 2010 Resource Kit External User Access Page 41
-
7/31/2019 Chapter 09 External User Access
42/70
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 amedia 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 generatingconferences, 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 URLassociated 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 browseruses to identify the conference to be joined, see the Conferencing and Collaboration chapter
of the Microsoft Lync Server 2010 Resource Kitbook, 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 thesimple URL.
Call Flow
When a user joins a conference with an application-sharing session, or a user wants toinitiate 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 thatscheduled 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.)
Microsoft Lync Server 2010 Resource Kit External User Access Page 42
-
7/31/2019 Chapter 09 External User Access
43/70
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) inFigure 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: INVITEsip:[email protected]@contoso.com;gruu;opaque=app:conf:applicationsharing:id:FZG8SYVR SIP/2.0
From: ;tag=10dc873e91;epid=3821b40476
To:
CSeq: 1 INVITE
Call-ID: b85cd18d9e074bdf8c5448ea279651cc
Microsoft Lync Server 2010 Resource Kit External User Access Page 43
-
7/31/2019 Chapter 09 External User Access
44/70
Via: SIP/2.0/TLS 192.168.5.202:54385
Max-Forwards: 70
Contact:
User-Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.275 (Microsoft Lync 2010)
Supported: ms-dialog-route-set-update
Supported: timerSupported: 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-inviteProxy-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=sessionc=IN IP4 97.75.78.122
b=CT:53980
t=0 0
m=applicationsharing 57929 TCP/RTP/AVP 127a=ice-ufrag:MakE
a=ice-pwd:7iJs2rWVUD5enazDfbf9nSJm
a=candidate:1 1 TCP-PASS 2120613887 192.168.56.1 5409 typ hosta=candid