Microsoft Lync Edge Deep Dive by huanghengdong


									 Microsoft Lync Edge Deep
Randy Wintle- Lync Server MVP
SR UC Consultant– Unify Square
About Me
Two time Lync Server MVP
Author: Lync Resource Kit External
User Access
Primarily involved in large enterprise
deployments of OCS and Lync as
Enterprise Voice Solutions
Proud father of a 1 year old boy (Rylan)
What is the Edge Server?
Important Terms and Definitions
What Makes the Edge Work- SIP Access Proxy (Access Edge)
What makes the Edge Work- Media Relay (details on call process)
The 50K Port Range
Security Considerations
Links and Resources
What is the edge server?
Connects users to Lync Services without VPN
  SIP Access Proxy (IM and Presence)
  Media Traversal for Audio/Video Calls(STUN/TURN/ICE)
Provides Federation to federated partners
Provides Public IM Connectivity to AOL,Yahoo and MSN
Access to Online Meeting Services to external and anonymous users.
What Doesn’t the Edge
Anything that is a web site
  Access to Address Book and Distribution List Expansion Services (Web
  site on front end/director)
  Landing Pages for Simple URLs( and on front end/director)
Terms to Know
MRAS- Media Relay Authentication Service- A/V Authentication
Service on the edge server
ICE – Interactive Connectivity Establishment
Candidate – Possible combination of IP address and port for media
Turn – Traversal Using Relay NAT
STUN – Simple Traversal of UDP through NAT
NAT – Network Address Translation
SDP – Session Description Protocol
TURN: TURN is an Internet Engineering Task Force (IETF) draft proposal
designed to provide a mechanism to enable a user behind a network address
translation (NAT) to acquire a transport address from a public server and to use
the allocated transport address to receive data from a selected peer.
   This protocol is used as part of the Interactive Connectivity Establishment (ICE)
   Extensions protocol, as described in [MS-ICE] and [MS-ICE2]
ICE:ICE specifies a protocol for setting up Real-Time Transport Protocol (RTP)
streams in a way that allows the streams to traverse network address translation
(NAT) and firewalls.
Signaling protocols such as the Session Initiation Protocol (SIP) are used to set
up and negotiate media sessions. As part of setting up and negotiating the
session, signaling protocols carry the Internet Protocol (IP) addresses and ports of
the call participants that receive RTP streams. Because NATs alter IP addresses
and ports, exchange of local IP addresses and ports might not be sufficient to
establish connectivity. ICE uses protocols such as Simple Traversal of UDP
through NAT (STUN) and Traversal Using Relay NAT (TURN) to establish and
verify connectivity.
STUN:A protocol that enables applications to discover the presence of and types
of network address translations (NATs) and firewalls that exist between those
applications and the Internet.
What makes the edge work?
SIP Access Proxy

   SIP Access Proxy
     Very Basic, edge server Access Edge proxies SIP messages over TLS and
     Look for SIP INVITE and SIP MESSAGE
     Actual Message Content can show in MESSAGE or 200 OK
SIP Access Proxy- Message
Call Flow
Federation IM
Still a SIP Proxy, however it is sending to another edge server
How to tell it is a federation message? The SIP 100 TRYING will
contain federation information
All SIP Messages: Record-
For every SIP Proxy (Access Edge, Director, Front End) that a SIP
Message passes through a Record-Route entry will be created.
Great for troubleshooting SIP issues. Essentially shows where the SIP
message has traveled between clients.
What makes the edge work?
Media Relay

  Phases of Establishing a Media Path
     During Login
        TURN Provisioning and Credentials (MRAS)
     When Establishing a Call
        Address Discovery
        Address Exchange (SIP Invite, 183, 200 OK)
        Connectivity Checks
        Candidate Promotion
        Media Flow
When a user signs on, internal or external they make a request for
media relay credentials to the Media Relay Authentication Service,
which runs on the Lync Edge Server Internal Interface.
Provides user with the information to start any type of media involving
remote participants, including Audio, Video and App Sharing.
Conferencing servers also request MRAS credentials (AVMCU and
Web/App MCU)
Search for these in Snooper to
see the processes
ICE Protocol Phases        Unified Communications Client Platform (UCCP) Log Item

AVEdgeProvisioning         Search mrasuri for a SIP 200OK provisioning response.
                           Confirms that that pool is configured with the Audio/Video Edge service.

AVEdgeCredentials          Search credentialsRequestID for SIP SERVICE.
                           Confirms that the Audio/Video Edge service is running and reachable on
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 Edge service.

Connectivity checks        Check RE-INVITE (see Candidate promotion for the connectivity check
                           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 that the ICE
                           protocol was negotiated.
MRAS Call Flow
What the messages look like
MRAS Request from client
What the messages look like
MRAS Response
What this means
The user now knows it must contact
before initiating media sessions with Lync.
Next step is Address Allocation and Negotiation, this is where
ICE/STUN/TURN come in.
ICE Call Flow
Candidates, what the heck are candidates?
  Candidates are a combination of available IPv4 addresses and randomly
  allocated TCP/UDP ports within the configured port ranges for the Lync
There are three types of candidates:
  In the simplest scenario, a user at home behind a home router has the
  following candidates:
  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 user’s pool.
Remember, every IP address on the client is a candidate, including
VPN Addresses!
First I must Allocate
 Before the SIP INVITE is sent in a call, the user must allocate
 User will make allocate requests to the A/V Edge Server using TURN.
 The initial allocate request can be seen below.
Allocation Continued
This initial transmission from the client to the server contains
UserName. The Edge Server stores this Username for future
credential matches.
The initial request from the client will be invalid, and returned with an
allocate error. Message-Integrity is required for a valid request, this is
by design as a “connectivity check”.
Allocation Continued
After this message is received by the client, it now has to send a
proper allocate request packet to the Audio/Video Edge service that
contains the Message-Integrity attribute.
Allocation Continued
After the Message-Integrity attribute has been negotiated, the Edge
Server responds to the remote client with an allocate response

                               All of that for my edge address!
Some extra information
All of this happens BEFORE the SIP INVITE
The edge server validates the username and password attributes
based on the authentication information it presented to the user during
the MRAS Provisioning during sign on.
Although the edge server has just allocated those ports to the user, it
is ACL’d. This means that it is only accessible by that client IP address
and only with valid authentication information.
From this point the client sends a SIP INVITE to whatever it is calling
with the relay candidates as well as Local and Reflexive candidates it
determines on its own.
ICE: What it looks like
 The SIP INVITE contains allocated candidates from the caller

m=audio 55336 RTP/AVP 114 9 112 111 0 8 116 115 4 97 13 118 101
a=candidate:1 1 UDP 2130706431 33468 typ host
a=candidate:1 2 UDP 2130705918 33469 typ host
a=candidate:2 1 UDP 2130705919 15614 typ host
a=candidate:2 2 UDP 2130705406 15615 typ host
a=candidate:3 1 UDP 2130705407 31518 typ host
a=candidate:3 2 UDP 2130704894 31519 typ host
                                                                      Host IPs
a=candidate:4 1 UDP 2130704895 25800 typ host
a=candidate:4 2 UDP 2130704382 25801 typ host
a=candidate:5 1 UDP 2130704383 25742 typ host
a=candidate:5 2 UDP 2130703870 25743 typ host
a=candidate:6 1 TCP-PASS 6556159 50162 typ relay raddr rport 30907      A/V Edge Relay TCP
a=candidate:6 2 TCP-PASS 6556158 50162 typ relay raddr rport 30907
a=candidate:7 1 UDP 16648703 55336 typ relay raddr rport 52259
a=candidate:7 2 UDP 16648702 54267 typ relay raddr rport 52282       A/V Edge Relay TCP
a=candidate:8 1 UDP 1694233599 52259 typ srflx raddr rport 11252
a=candidate:8 2 UDP 1694232062 52282 typ srflx raddr rport 11253       Reflexive UDP
a=candidate:9 1 TCP-ACT 7074303 50162 typ relay raddr rport 30907
a=candidate:9 2 TCP-ACT 7073790 50162 typ relay raddr rport 30907       A/V Edge Relay TCP
a=candidate:10 1 TCP-ACT 1684795391 30907 typ srflx raddr rport 15645
a=candidate:10 2 TCP-ACT 1684794878 30907 typ srflx raddr rport 15645
                                                                                                       Reflexive TCP
I showed you mine, now show
me yours
Callee sends back their allocated candidates after following the same
Candidate Testing
Candidate testing is done through a series of STUN binding requests, essentially pings on the media
ports between the presented candidates to validate connectivity.
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 user’s computer IP addresses, testing direct
   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 isn’t available on UDP,
   TCP Relay would be a last resort.
The ICE protocol connectivity checks are sequences of STUN packets that are sent between port
pairs in the order shown in the previous list. A STUN response indicates connectivity. Connectivity
checks are stopped after a valid bidirectional path has been achieved.
Candidate Promotion
 Once the path is validated, media may start flowing before the
 Then a SIP INVITE is sent containing a validated remote
 candidate (Designated by a=remote-candidate in the SDP)
 The Callee responds with a 200 OK and a remote candidate
 similar to the Caller’s message.
 For each pair, one is for RTP, the other for RTCP(control
 messages for the RTP Stream)
 Media flows between that candidate pair for the duration of the
At this point, media is flowing, example below is an RTP Packet with
RtAudio passing between clients
At this point, media is flowing, example below is an RTP Packet with
RtAudio passing between clients
After the call
 Port allocations on the client and edge are cleaned up, meaning the
 ports are closed.
 If Monitoring Server is deployed, SERVICE message is sent through
 the Front End server to the Monitoring Server to log call data
The port ranges
     What about that 50k Port range??
     Used for federation + Desktop Sharing + File Transfer
Federation with                     Feature                       RTP/UDP 50.000-59,999K            RTP/TCP 50,000-59,999K

Windows Live Messenger 2011         Point to Point                Do not open in either direction   Open outbound

                                    Audio/Video (A/V)

Lync Server 2010                    Lync Server 2010              Do not open in either direction   Open outbound

Lync Server 2010                    Application sharing/desktop   Do not open in either direction   Open outbound
Lync Server 2010                    File transfer                 Do not open in either direction   Open outbound

Office Communications Server 2007   A/V                           Do not open in either direction   Open outbound
Office Communications Server 2007   Desktop sharing               Do not open in either direction   Open outbound
Office Communications Server 2007   File transfer                 N/A                               N/A
Office Communications Server 2007   A/V                           Open inbound                      Open inbound

                                                                  Open outbound                     Open outbound

Office Communications Server 2007   Desktop sharing               N/A                               N/A

Office Communications Server 2007   File transfer                 N/A                               N/A
A/V Edge Security Considerations
Home1                                                                     OC/Console
Lync                                                                      A/V MCU
                                                       UDP                ExchangeUM

 A/V Edge Requirements                                 TCP
      A/V Edge must have routable IPs                  443

      No NATs are allowed w/ HLB
      Firewall is okay and encouraged
 Protecting UDP3478 and TCP 443                      .
      128bit digest authentication                   .
      Token lifetime is eight hours              .   .
                                                 .   .
      Nonce and Salt prevent replays             .   .
 Protecting ports in 50,000 range                    .
      Dynamic (sparse) port allocation               .
      IP filter based on ICE candidates              UDP/TCP
 Media is protected via SRTP                         59999

                                      Outer FW        A/V      Inner FW
                                      (no NAT)        Edge     (no NAT)
Links and Resources
Lync resource kit- external user access :
MS-TURN Extensions
us/library/cc431504(v=office.12).aspx of course!
Contact Information
Randy Wintle

To top