Shawn Harry | Configuring SIPREC for Microsoft Teams Direct Routing with SmartTAP
1599
post-template-default,single,single-post,postid-1599,single-format-standard,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,qode_popup_menu_push_text_top,qode-content-sidebar-responsive,qode-theme-ver-10.0,wpb-js-composer js-comp-ver-4.12.1,vc_responsive

Configuring SIPREC for Microsoft Teams Direct Routing with SmartTAP

SIPREC is an IETF SIP based protocol used for recording VoIP calls. As its an open standard it has common support among many PBX vendors and SBCs. AudioCodes SmartTAP product has supported the SIPREC standard for many years and SIPREC can be used for recording Microsoft Team calls too without the need for deploying Microsoft Teams policy based Call recording.

Whilst Teams supports Compliance based Call Recording using proprietary solutions that are supported by Microsoft through third party vendors such as Verba, NICE, ASC and more the focus of this post will be on leveraging SIPREC to record PSTN calls for Microsoft Teams Direct Routing users. With a few simple integration steps you could have a very simple topology deployed in a few hours!

Depending on your customers compliance requirements SIPREC can certainly be a good solution for Microsoft Teams Direct Routing and even more so if you’ve already deployed AudioCodes SBC’s as the focus of this post will be on AudioCodes SmartTAP product which supports the SIPREC protocol. Do note SmartTAP does also support native Teams Compliance based call recording but I will not be covering that in this post.

What I’m intending to cover is a very simple topology consisting of an AudioCodes SBC and AudioCodes SmartTAP.

My topology consists of an AudioCodes Virtual Edition SBC and a AudioCodes SmartTAP server both hosted in Azure with a SIP trunk to my ITSP Sipgate. The server components can be hosted anywhere, on-premises, public Cloud, private Cloud and so on but using ARM templates in Azure allows for a rapid turn up and provisioning of services for production use cases as well as proof of concepts or labs.

In my case the Session Recording Server (SRS) in the diagram above is my SmartTAP server and the Session Recording Client (SRC) is my VE-SBC. SmartTAP is capable of recording encrypted or non-encrypted traffic. But to keep the topology nice and simple I’ve deployed the SmartTAP into the same subnet as the SBC so there’s no firewalling, and rather than ‘wire-tap’ the line side to Microsoft Teams which is encrypted I’m going to demonstrate how you can tap the PSTN trunk which in my case is in the clear. Do bear in mind as the SBC is forking the media this topology could be used with any PBX. So this is certainly not a configuration that’s limited to just Microsoft Teams.

At its simplest all the SBC is doing is forking the media stream for a PSTN call to the SmartTAP and the SmartTAP records the call. In that respect SmartTAP is functioning similar to the way WireShark does when sniffing network traffic.

Preparing the SmartTAP server

The steps for installing SmartTAP are pretty straight forward so I won’t be covering them here but there are a few steps that must be configured on the SmartTAP before the server will be properly operational.

Deploying SmartTAP in Microsoft Azure Marketplace – config guide.

  • Configure the SmartTAP to listen on SIP UDP.

By default the SmartTAP ARM template has been configured to use TLS for its communication between the SRS and the SRC. This is obviously a securer configuration but does require additional configuration on the SmartTAP for the certificate exchange with your SRC. As mentioned earlier I’m attempting to keep this topology nice and simple, and as both the SRS and SRC are in the same flat trusted network I’m happy for SIP traffic to remain in the clear.

Unfortunately its not possible to change the listening port of the SmartTAP from via its web portal. Instead we need to dip into some config files and modify some values. By default the SmartTAP listens on SIP/UDP 5068 and SIP/TLS 5069. To change the listening port 5068 browse to “C:\Program Files (x86)\AudioCodes\SmartTAP\CD-SIPREC\Config\CdSipRecConfig.xml”

Locate the following lines in the beginning of the file and delete them.

You need to replace these lines with the following.

Your CdSipRecConfig.xml file should look like this now.

Note the remarked out TLS config in the file, so if you ever needed to enable TLS again all you’d need to do is copy and paste those lines.

Open services and look for the AudioCodes CD-SIPREC service and restart it.

From the SmartTAP web portal wait for the status of the Call Delivery-SIPREC to settle and it should show as Green after a few minutes.

  • Edit the RTP receiving IP Address.

The ARM template is configured to use its loopback address for media which if left as is will cause recordings to fail as the SBC can’t send media to a 127.0.0.1 address. The loopback address must be replaced with the actual IP address of the SmartTAP.

Browse to “C:\Program Files (x86)\AudioCodes\SmartTAP\MS\Server\Bin\ac-hmp20.ini”. Edit the Data_IP=127.0.0.1 to the internal IP address of the SmartTAP.

Restart the AudioCodes MS (Media Server) service.

Configure SmartTAP to record a user

SmartTAP expects to see the TEL URI in the Invite metadata for a recorded user so the TEL URI must be populated.

In my case my users are being imported from AzureAD. See blog post here.

If using imported AAD users ensure the TEL URI is populated.

We now need to map the TEL URI attribute so that this attribute is included when SmartTAP imports AAD users. In the SmartTAP portal add the TEL URI mapping.

When a user is imported you’ll now see the TEL URI populated for that user.

For the purpose of testing you could also add a user manually from Add User and entering the desired TEL URI that’s delivered to your SBC/SRC.

Create a new recording policys with the values below. As this is for recording inbound and outbound PSTN calls only the below values needs to be selected. The other settings can be left at their system defaults.

This policy needs to be applied to the user you’re going to test with.

If you browse to User Status you’ll now see the recorded user is showing as ‘unknown’.

During a recording you’ll see their status change to red. The traffic light will update the status of the user if the user is idling, available and so on.

Configure the SBC to communicate with the SmartTAP

Ensure your SBC is licensed for SIPREC.

Add a new proxy set that points to the IP address of your SmartTAPs internal IP address including the port number 5068. Ensure options pings are enabled so you can verify the SIP trunk is up.

Add a new IP Group for the SmartTAP

You can use Wireshark or the Syslog to verify that the SBC and the SmartTAP are exchanging options pings. Or browse to Topology View and you should see a green tick against the new SIP trunk.

Create a new SIP recording rule with the values below. You can be quite granular with what calls you want to send to your SmartTAP but to keep the configuration simple I created a rule to send all calls to the SmartTAP with both the recorded party and the called party being recorded. The “*” indicates all number patterns source and destination are sent to the SmartTAP.

Make an inbound call to your Teams DID or a PSTN call from Teams and you should be able to see the recording in SmartTAP where you can either play the recording back in the portal or download it to your PC.

Conclusion

Both the Virtual Edition SBC and SmartTAP include demo licenses in Azure. With both installed into the same Azure vNet its easy to spin up a rapid lab to test SIPREC for Teams Direct Routing, and could also be a great POC if all your customer requires is PSTN recording only.