UCMA Application & Firewall Rules

This post is about the firewall rules required on a Windows application server to host a UCMA based middle-tier application. The post describes how incoming media packets cross the firewall running on the UCMA application server.

To be able run a UCMA application in Lync Server environment you need to provision the application first. As part of the provisioning process you need to run the New-CsTrustedApplication cmdlet in Lync Management Shell where you specify the host/pool your UCMA application will be running on and the TCP port the application will be listening on to receive incoming TCP/TLS connections from Lync Front End Servers. This port will be referred as TrustedApplicationPort.

New-CsTrustedApplication ... –Port [TCP port UCMA application is listening on] -TrustedApplicationPoolFqdn [FQDN of the UCMA application server/pool] ...

On the UCMA application server you need to setup a firewall rule which allows your UCMA application to accept incoming TCP connections on TrustedApplicationPort. Otherwise, your application endpoints cannot be dialed; Lync Front End will return SIP 504 “Server time-out” error to callers.

The first time after I did all of these and started my application, I was just wondering how the hell my application receives incoming media packets (e.g. audio) if I just enabled TrustedApplicationPort on the firewall. This TCP port is just for SIP signaling and not for audio. Audio is received in RTP/RTCP packets generally on UDP; it is not TCP. Even if I did not set up firewall rules to receive incoming audio packets on UDP my UCMA application was working like a charm. It received an incoming call, accepted that and was receiving incoming audio stream without any problem.

Application environment

So I started to investigate this. Let us see what happens under the hood … The screenshots below are created on the UCMA application server using Process Explorer and Microsoft Network Monitor. The following table helps to understand what these screenshots show.

Lync Front End Server (Standard Edition) lync.msvoip.dev (lync)
UCMA Application Server (TrustedApplicationPoolFqdn) dev.msvoip.dev
UCMA Application Port (TrustedApplicationPort) 9100

UCMA application – no calls

When you start up your UCMA application (more precisely your UCMA CollaborationPlatform), it immediately starts listening on TrustedApplicationPort. This is TCP port 9100 in our case. This port remains opened until the application is running. Its purpose is to receive incoming TCP/TLS connections from Lync Front End e.g. when call comes to an endpoint hosted by the application. Moreover, the application opens and keeps a pool of outgoing TCP/TLS connections to the TCP port 5061 on Lync Front End. These connections are opened by your UCMA application when application endpoints are registered.

Idle.PNG

UCMA application – single audio call

When an audio call is connected to an application endpoint then a few additional incoming TCP/TLS connections are opened between the application server and the Front End to pass SIP signaling messages back and forth. Moreover, 2 UDP ports are opened on the UCMA application server to receive incoming audio packets belonging to the call (UDP ports 30540 and 30541 on the screenshot below).

OnCall.PNG

One UDP port (35040; the even one) is to receive incoming RTP packets, the other (35041; the odd one) is to receive RTCP.

Audio call establishment under the hood

As part of the call establishment procedure, the UCMA application (RTC layer) and Lync Front End exchange SDP in SIP messages. UCMA application allocates 2 local UDP ports (30540, 35401) to receive RTP/RTCP on, constructs SDP and sends that either in SIP INVITE or SIP OK depending on the direction the call is being established. Lync Front End also sends the UDP ports UCMA application is expected to send RTP/RTCP to (opened on AV MCU/Mediation Server/Lync/Edge). UCMA application uses symmetric RTP/RTCP (RFC 4961) so it uses the same UDP port to send and receive RTP (30541) and the same UDP port to send and receive RTCP (30541) for the same call. Moreover, before sending any audio packets the RTC layer sends STUN binding requests (RFC 5389) from the local UDP ports allocated for RTP/RTCP to the remote UDP ports it is received during call establishment (it acts as a STUN client).

StunOut.PNG

These STUN requests sent by the application actually open port bindings on the local firewall. So UCMA application can receive incoming RTP/RTCP packets on these ports afterwards. This means that there is no need to open UDP ports on the firewall running on the application server. The work is done by the RTC layer under the hood.

After STUN binding requests are sent, incoming RTP and RTCP packets can cross the firewall on the UCMA application server and can reach the application endpoint.

RtpOut.PNG

Summary

So, there is no need to have firewall rules to open a range of UDP ports for incoming RTP/RTCP on. The facts that UCMA application uses symmetric RTP/RTCP and sends STUN binding requests before sending media ensure that required ports are opened on Windows firewall automatically.

It is enough to have a single rule which allows incoming TCP/TLS connection to TrustedApplicationPort:

netsh advfirewall firewall add rule name="Rule to allow incoming TCP on TrustedApplicationPort" protocol=tcp dir=in action=allow localport=[TrustedApplicationPort] profile=any