ICE Negotiation (Part 1) – MRAS Process

What is MRAS?
Media Relay Authentication Server
MRAS generates the credentials needed for external media by Lync users outside the local network. Before an external user can initiate any type of A\V traffic the Edge server will need to obtain credentials that will allow it to relay A\V internally on behalf of the external client.

MRAS is part 1 of the ICE process (Part 2 is the Candidate process, read about that here)
The following illustration depicts the MRAS process:

The MRAS Process is as follows:

  1. SIP Register
  2. MRAS Request
  3. MRAS Response
  4. MRAS Response (to user)

To have a closer look at these we will use snooper

In Snooper (client side logs) grab traces of a login and filter with “MRAS”
You should find 3 messages.

1. SIP Register

The First message (SIP 200 OK) contains all user settings, profile, URls etc etc (all in-band)

NB If the MRAS message is missing then there is no Edge Server defined in the Topology

2. MRAS Request

The Second MRAS message (SERVICE) shows the service request from the Lync Client to the Front End for credentials to chat to the Lync Edge.

This message shows sip uri, duration that credentials are valid and location (intranetl\external)

You will always see this second MRAS message once the first is seen as its simply the client responding.

3. MRAS Response

The Third MRAS message (SIP 200 OK) is a response from the Lync Front End providing credentials, location, and the HOST NAME of AV EDGE and the ports to use for media.


External clients need to get the External FQDN of the Edge Server here and internal clients need to get the Internal FQDN of the Edge Server – This is the server name that the client needs to connect to for establishing media.

If the 3rd message is present it reveals that the FE is able to communicate with the Edge on port 5062 (MRAS)

If there is an MRAS error in message 3 (eg Timeout) then there is a connectivity issue between Edge and FE (eg FW, DNS).

Make sure the client can Telnet to the FQDN shown in message 3 as this is the A\V path

For Reference


About Paul B

My name is Paul Bloem and I am employed at Lexel Systems in New Zealand as a Principal Consultant for Unified Communications. I have been working on enterprise voice solutions for over 20 years. My first 10 years were spent working for a Telco in South Africa (Telcom SA). This is where all the groundwork happened as I was exposed to just about every aspect of telecommunication you could imagine. I develop an interest in PBX technologies and eventually became the go-to guy. Next, I had a 10 year run at Siemens South Africa, most of my time there was as a Technical Trainer. During this time VoIP hit the world stage, I had the privilege of introducing VoIP both as H.323 and later SIP across the Siemens HiPath 4000 solution stack. In 2008 I immigrated to New Zealand with my newly attained MCSE, I was ready to go where no PBX Techie had gone before. I was employed to explore OCS 2007 and that was pretty much the beginning of the end for me. I have been working on OCS and Lync ever since. My current role focuses exclusively on Lync and associated technologies.. That includes pre-sales, consulting, architecture and design, training and support. I even get to play in the development space from time to time - focus on play ;-) I was nominated as a Microsoft VTSP for Lync early in 2013 and also awarded Microsoft's MVP award for Lync in 2014.
This entry was posted in MRAS. Bookmark the permalink.

One Response to ICE Negotiation (Part 1) – MRAS Process

  1. Pingback: ICE Negotiation (Part 2) – Candidate Process | UC Sorted

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s