Blog Archives

What happens when you’re A/V Edge Is Misconfigured: STUN/TURN

Ran into a very interesting issue recently at a customer. Below is the scenario:


OCS 2007 R2

Two pools, each with an associated edge pool.


Associated Edge Pool : EDGEPOOL01

Audio/Video Edge Public Interface: AV1.CONTOSO.COM


Associated Edge Pool: EDGEPOOL02

Audio/Video Edge Public Interface: AV2.CONTOSO.COM

First, the issue: External users homed on POOL02 cannot make/receive calls through the Edge.

We took Wireshark/Network Monitor traces from the external client when the client attempted to make an audio call. While reviewing traces of the call flow, the following error was thrown during the attempted allocate request(To see more details on the expected behavior of this process, check out the Lync Resource Kit Edge Chapter):


The Username Supplied in the request is not known.

The user was sending an allocate request with all required information, Username, Nonce, Realm and Message-Integrity however the A/V Edge Service was rejecting the authentication request stating that the username was unknown.

Next, we reviewed the client UCCAPI log (located at %userprofile%\tracing\Communicator-uccapi-0.uccapilog). When reviewing for the initial SIP INVITE from the user, the candidate list is incomplete. External users must also send Reflexive (Home router public IP Address) and Relay (A/V Edge Interface) IP and port combinations that have been allocated for media.

The initial thought was to attempt a connection to the A/V Edge Public Interface on 443. When users initiate calls they must be able to contact the server on 443 TCP and 3478 UDP to allocate ports. A quick telnet test proved that these connections were open. This proved the theory that the user could not allocate ports with the edge, although it could contact the edge on the proper ports.

m=audio 54614 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101




a=candidate:1 1 UDP 2130706431 54614 typ host

a=candidate:1 2 UDP 2130705918 54604 typ host

a=candidate:4 1 TCP-ACT 1684798463 54614 typ srflx raddr rport 54614

a=candidate:4 2 TCP-ACT 1684797950 54614 typ srflx raddr rport 54614

a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:nMf0n5KQE7L+fajVqoWo+DCMzKj7lHLfwskTMOTt|2^31|1:1

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:XykNc+3nFqRWu3l5IJJs/cAFvsUqaL5/ZaVdRhoa|2^31|1:1




The next step was to review the MRAS request during sign on to validate that it was actually receiving valid media relay credentials, and this is where the issue was spotted. To do this, we opened the client UCCAPI log and searched for MRAS(Detailed Information on this process, and tracking these processes can be found in the Lync Resource Kit Edge Chapter): In the MRAS request the client receives a valid 200 OK From the server, with what would be assumed are valid credentials and server information:


<?xml version=”1.0″?>

<response xmlns:xsi=”; xmlns:xsd=”; requestID=”80980176″ version=”2.0″ serverVersion=”2.0″ to=”;gruu;opaque=srvr:MRAS:k44hfHH-N0O1pJWhN9MnEwAA” from=”” reasonPhrase=”OK” xmlns=””>

  <credentialsResponse credentialsRequestID=”80980176″>

















Because the user is associated with POOL02, it should have received AV2.CONTOSO.COM as its public A/V Edge for Media Relay. However, due to a misconfiguration on the edge pool, the MRAS service was handing back the POOL01 A/V Edge Service. Because of this, the user would connect to that edge pool, but when attempting to allocate ports, the edge server had no idea who that user was.

The fix for this issue was to validate the R2 Edge External Interface configuration, we found that AV.CONTOSO.COM was configured as the public DNS name for POOL02, when it should have been AV2. CONTOSO.COM. As soon as this was updated, the issue was resolved.

Below is a reference diagram to help understand the issue.