Public Address (Paging) Options for Lync

This is part 1 of what’s (so far) a 3-part series:

Public Address (Paging) Options for Lync – this post
More Public Address (Paging) Options for Lync
Public Address (Paging) Options for Microsoft Teams – I

I recently had a customer with a retail presence ask if we could interface Lync to the paging / public address / PA / evac systems in their stores. “Sure”, I said, then thought I should POC it up to see just how we’d go about it.

Turns out there are a number of ways you can do this. Here are the ones I’ve found. Choose the option that suits your environment best!

“Traditional” Paging

Back in prehistoric days when PABXs roamed the earth we used to connect the PA system to an analog trunk circuit (an “FXO” port) or perhaps a tie-line circuit. This was a relatively neat interface, as it provided the audio on a single pair, and the inherent “supervision” of an FXO or E&M circuit meant it cleared as soon as the paging party hung up the line.

Not FXS?

FXS ports are UGLY. When you call an FXS port, a ringing signal of 90+V AC is sent out the line to ring the bells. [It *hurts*]. The PA interface needs to ‘trip’ this in order to answer the call, and at the same time prevent it from reaching the amplifier. There are real supervision problems with using FXS ports in this direction, as there’s no electrical indication provided to the PA system when the paging party hangs up. (My Telephone Intercom is effectively a pair of back-back FXS ports if you want to read some more).

Paging From Lync with an NET/Sonus/Quintum Tenor ASM200 & a 48V LIU

Here I’ve POC’d the entire solution using a Quintum Tenor ASM200 with an FXO interface. The only tricky bit is that you need a relatively fancy LIU – one that feeds 48VDC to the Tenor to simulate the presence of a telephone line. With just a basic transformer-only LIU the FXO port sees no voltage, so it thinks the port’s faulty. This is a basic level of supervision inherent in the gateway and unfortunately it can’t be overridden.

Shopping List

A Tenor with a spare FXO port. I’m using an ASM200 in this demo
A suitable LIU. I’ve used a “TIC2F2” from Batesford Electronics here in Australia, which cost AU$180 delivered. You’ll of course be able to find equivalents in your region. This LIU gives me 3500V DC isolation between Lync and the PA system, a 600:600 ohm transformer for the audio coupling, as well as a changeover relay contact that can be used for seize/clear indication if required

In the photo, the cream cable is the FXO port, whilst the black one is the feed to the PA system.
Of course your PA system needs to have a suitable input, and we need access to someone with the means & wherewithal to electrically interconnect it to the LIU

How-To

I’ll assume your Tenor is existing, so it’s already in the Topology as a Gateway. If not, add it and publish
Our interface here is a trunk, and to get to it we need to send it a call. I’ve chosen to set it up as an analog device. Even though that functionality is intended for FXS ports, it works well here!
```
PS > New-CsAnalogDevice -LineUri tel:+831234 -DisplayName "Paging Speaker" -RegistrarPool lync2010.contoso.com -AnalogFax $True -Gateway tenorasm200.contoso.com -OU "ou=RTC Special Accounts,dc=contoso,dc=com"
```
I’ve called it “Paging Speaker”, and given it the phone number of +831234. “+83” remains an unused country code, and it’s the one I use for all my testing and utility stuff. Feel free to use a suitably unallocated number in your own country if you prefer.
I thought I’d be clever, adding a photo as well. FWIW, I used the free version of Chris Wright’s “AD Photo Edit” software:
The Tenor isn’t too hard to configure. We need to create some new objects to help manage and configure this trunk.
Create a new Trunk Circuit Routing Group. The defaults should be fine for this one:
Now create a CAS Signaling Group. On the General tab, ensure the Orientation is “User/Slave”:
Un-check Dial Tone Detect on the Signaling tab. (This won’t appear if you’ve skipped Step 5):
Now create a new Channel Group & associate the new CAS and Trunk Circuit Routing Groups:
Edit the channels in both groups to rearrange them so the chosen channel is only in the paging group. In my config, Ch1 is my PSTN trunk to the outside world (no, not SIP here yet) whilst Ch2 is for our paging interface. Config Manager’s a big ambiguous here – the ‘tick’ is visible for both channels, but the de-selected channel is in a lighter shade to indicate it’s disabled/not chosen.
You’ll need to create a new Number Table to grab calls bound for the paging trunk. Here I grab everything starting with 83 (because all calls that make it to the Tenor are in E.164 format, and 83 is spare, as referenced in step 2). The “Outgoing Pattern” is blank because we don’t want any of the digits dialled being sent to the PA:
Now add it to the Routing Table:
My “DNIS Lync to PSTN” number table has a wildcard entry at the bottom of it, so to prevent it falsely catching calls bound for the paging trunk, I needed to re-order the table so that the Paging entry appears before the PSTN one. With the order wrong, your paging calls will go out the PSTN trunk instead!
Done!

Results / Summary

This config seemed fine on paper, but it has a few failings:

here’s no clear (audible) signal to the caller that they’ve cut-through to the trunk, so there’s no definite indicator you can start speaking. In testing, after I called the paging number I was presented with a burst or two of “jingle-tone” then silence: the relay went Click and we were connected. I fear this won’t fly in the real world – or will be fraught with problems. (“Is this thing on?”). If the caller is able to hear the PA, you might be able to address this by adding a single digit to the “Outgoing Pattern” in step 12. That will send a BEEP to the line to grab everyone’s attention (and you can even change the duration of it by varying the “DTMF On Time” in the CAS Signaling Group in step 6).
I also noticed an audible *click* to the amplifier when the LIU’s relay seized, and this might also manifest itself in a much more annoying and unacceptable glitch in a high-powered PA environment
because it’s an analog device, it’s able to be called by anyone, so you can’t restrict those users who can access it. The “fix” here is to delete the analog and rebuild it as a Contact (whether in AD, or just in your own Outlook). Now it’s just a number you’re dialling, so becomes subject to Lync’s Voice Policies, Usages and Routes, so you can bar it appropriately.

Despite my initial preference for the “simplicity” of the traditional paging interface, the lack of better audio supervision (the cut-through to the trunk) means I can’t recommend it.

I also think that for security and safety reasons if you’re going to implement this anywhere larger than a small office you’d want to take the Contact/trunk configuration option, rather than setting it up as a csAnalogDevice.

What it really looked like

This is what my Lab looks like. Honestly. The output of the LIU is feeding a tiny home-brew amp (sitting in the top drawer) that uses a Philips TDA1521A SIL amplifier IC to do all the work. It has a bulldog clip as a heatsink, is currently powered from the bench supply (on the bench’s shelf), and is driving the Bose 802 on the bookcase. My computer desk is opposite, and only marginally less cluttered.

UX1000 FXO

FWIW, I did initially try this with a UX1000 & an FXO card. The 4-port FXO cards for the UX1k sell here for around AU$500, and because it uses a trunk port we don’t need any SIP or Transcoding licences in the UX, making it a little easier to configure and deploy.

Unfortunately I had terribly distorted audio through the FXO port, and the UX wouldn’t calibrate the trunk port (not even with the Telstra PSTN line connected). I’ve put this down to a bug in v2.2. v181 (or some config quirk I missed). Next time I can get my hands on a UX with an FXO card I’ll have another go at it.