chapter 09 external user access

7/31/2019 Chapter 09 External User Access

1/70


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


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.



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



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



6/70

Application Sharing ............................................................................................. 67

Audio and Video Conferencing ............................................................................ 67

Media Relay Authentication Service (MRAS) ........................................................ 68

Enterprise Voice .................................................................................................. 70

Summary .................................................................................................................. 70

Additional Resources ................................................................................................. 70



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



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.



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.



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:



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.



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



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.



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



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



16/70


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



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.



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



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.



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.



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:



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



24/70


a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:116 AAL2-G726-32/8000



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:9 1 TCP-ACT 7074303 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=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=rtpmap:111 SIREN/16000






25/70

a=rtpmap:116 AAL2-G726-32/8000



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


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:



26/70

02/09/2011|09:29:54.242 17F8:14CC INFO :: SIP/2.0 183 Session Progress



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: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



27/70


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=label:main-audio

a=crypto:2 AES_CM_128_HMAC_SHA1_80inline:B+8cuezdQGjtYxuYMgwl+fsul/jXZ3UjDuk15eWm|2^31|1:1





a=rtpmap:13 CN/8000

a=rtpmap:118 CN/16000


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 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 :: SIP/2.0 180 Ringing



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


RECORD-ROUTE:

CONTACT: ;isGateway

CONTENT-LENGTH: 0



28/70

SUPPORTED: replaces

SUPPORTED: ms-safe-transfer

SUPPORTED: ms-bypass

SUPPORTED: gruu-10

ALLOW: CANCEL

ALLOW: BYE

ALLOW: UPDATEALLOW: PRACK


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 :: SIP/2.0 200 OK



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


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:



29/70


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 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: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=label:main-audio

a=crypto:2 AES_CM_128_HMAC_SHA1_80inline:B+8cuezdQGjtYxuYMgwl+fsul/jXZ3UjDuk15eWm|2^31|1:1




30/70




a=rtpmap:13 CN/8000

a=rtpmap:118 CN/16000


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 :: 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:




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 :: 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:


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 :: SERVICEsip:[email protected];gruu;opaque=srvr:HomeServer:i8hSASSjHFe4rJJ6SMmzzAAA SIP/2.0

Via: SIP/2.0/TLS 192.168.1.138:49383Max-Forwards: 70



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


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 :: SIP/2.0 200 OK



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




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



35/70







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




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: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:8 1 UDP 1694233599 69.193.68.231 3048 typ srflx raddr192.168.1.108 rport 3048



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


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.


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.



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=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



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.



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



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: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: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


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


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



41/70

CSeq: 1 INVITE

Record-Route:Contact:


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: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: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


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



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



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



44/70

Via: SIP/2.0/TLS 192.168.5.202:54385

Max-Forwards: 70

Contact:


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

chapter 09 external user access

Documents