FreePBX paging

We’ve never written about paging technology before, and this is one of those areas of VoIP telephony where it certainly paid to wait. What a difference a few years makes! At least in the Asterisk® context, SIP-based paging traditionally involved issuing a Page command with a list of extensions in your dialplan. The wrinkle was that each VoIP phone manufacturer had its own SIP header to trigger autoanswer on its phones. And, without autoanswer, paging becomes next to worthless with desktop phones. Then came FreePBX®. It took all the pain out of the process by using the *80 prefix to issue a page to almost any type of SIP phone. The one wrinkle was that Grandstream and a few other phones require that autoanswer be enabled for paging in the device configuration. Aside from that, any user can pick up a phone on a PBX in a Flash system and dial *80707 to page extension 707 with duplex voice communications through the speakerphones, meaning both parties can talk and listen to each other, the perfect VoIP intercom. And, there’s more good news. Paging works with almost all of the major phone manufacturers’ phones: Aastra, Digium, Grandstream, Linksys/Sipura, Mitel, Polycom, SNOM, and Yealink. In addition, the SIP-compatible Cyberdata ceiling speaker and Cyberdata POE Doorphone/Intercom with Keypad function just like a SIP phone.
For small groups of phones, paging now works equally well using the FreePBX Paging Module which allows an administrator to preconfigure a group of phones, specify whether to skip busy extensions, barge into busy extensions and place existing callers on hold, or whisper the page to the busy extensions. You can even enable or disable duplex communications during the page. Think of it as instant conference. The module also provides the flexibility for individual phone users to block pages from one or more extensions or even all extensions. Finally, the module lets you create and save multiple configurations for different purposes, and you can designate an Announcement message that plays to every page recipient. For organizations that need additional functionality including Page Scheduling and Automatic Page Alerts on Outbound Routes, take a look at the Schmooze PagingPro module. And, for a historical look at the evolution of paging on the Asterisk platform, see Chapter 11 of Asterisk: The Definitive Guide (4th edition). Better yet, buy the book!
So why do we need paging? In the corporate setting, it provides a perfect emergency broadcast service for fires, earthquakes, patient escapes from the loony bin, etc. In a school setting, it could inexpensively replace costly public address systems requiring dedicated wiring, speakers, and amplifiers. The Asterisk paging solution has the added benefit of letting anyone broadcast from anywhere by simply picking up a nearby phone and dialing some (hopefully password-protected) extension number. Separate RTP streaming IP addresses also could be configured on departmental phones to allow automobile dealership zone paging for parts, sales, or service. So a receptionist could park a call and then announce it to a particular department by pressing a softkey on the sidecar. And you still could have an additional emergency channel that reaches everybody. Just set up a different number to page each zone as well as the entire organization.
So that’s where we were until a week ago when Brian Kelly of PIAF Forum fame began exploring Multicast RTP Paging with Asterisk and AirPlay. Think of Multicast RTP as a radio station that streams data on a particular IP address and port. If you happen to have Multicast-aware SIP phones, they can “tune in” to particular channels of interest. And, whenever a stream is broadcast on one of the channels the phone device is preconfigured to listen to, it will go off hook just as if it had received a page as outlined above. The major advantage to RTP streaming is that there is only a single stream of data on a single channel whereas paging to multiple extensions requires a channel of data for every extension. If you want to follow along with today’s project, just configure one of the Multicast RTP streams on your phone with the port and IP address shown below.
The wrinkle is your phone devices must support Multicast RTP streaming, and many current models do not. Our VoIP Phone of the Year, the Yealink T46G, qualifies. So do some of the Aastra, SNOM (v7), and Linksys/Cisco phones (with quirks!). And the Cyberdata speaker and doorphone (above) support Multicast RTP streaming as well. Digium Phones currently do not. If you know of other phones that support Multicast RTP streams, please post a comment. You’ll know if your particular phone supports it if it has a configuration section in the manual that looks something like this:
The good news is current versions of Asterisk including 1.8, 10, and 11 support Multicast RTP Streaming and PIAF-Purple and PIAF-Green come preconfigured for RTP Multicast Streaming. A single line of dialplan code is all you need to initiate a broadcast:

exten => 1234,1,Dial(MulticastRTP/basic/224.0.0.1:1234)

This would cause the Multicast RTP Stream broadcast to begin on port 1234 of IP address 224.0.0.1 as soon as someone on your PBX in a Flash server dialed extension 1234 and began to speak. Every phone or SIP device listening for broadcasts on port 1234 from IP address 224.0.0.1 would receive the listen-only page on their speakerphone.
Of course, Brian was not content to merely issue a page from Asterisk to his SIP phones. He wanted all of them to be able to listen to his iTunes music collection using his iPhone or iPad. This required AirPlay, but AirPlay can only stream to iOS devices. Well, not so fast. An enterprising guru on SourceForge created his own AirPlay emulator called Shairport4w. This is a Windows application that works just like an AirPort server. It “listens” for content from an iPhone or iPad that has designated Shairport4w as its AirPlay device. iTunes has the ability to stream music to any AirPlay device including the Shairport4w. So that was half of the puzzle. That got iTunes music playing great on the Windows desktop.
But we needed the other piece of the puzzle. We needed to push the music from the Windows machine to the SIP phones using Multicast RTP streaming. Brian found the missing piece of the puzzle for that as well. It’s called Multicast Streamer for Windows and it’s available at no cost from CodeProject. Simply download and unzip the bundle of goodies and run Multicast Streamer on your Windows desktop together with Shairport4w. Shairport4w captures the incoming AirPlay stream and pushes it to the sound card.
Now we simply need to configure the sound card as the input device for Multicast Streamer and make the appropriate settings to broadcast the RTP stream to port 1234 on IP address 224.0.0.1. This was the listening port and IP address we configured on our SIP phones. Be sure to also adjust the Samples per second to 8,000 and the Bits per Sample to 16.
Your mileage may vary but in our case the only output device showing on Multicast Streamer was Microphone. What we needed was Stereo Mix to capture data from the sound card rather than the microphone. If yours is missing, do the following. Right-click on the Speaker icon and switch to the Recording tab. If you don’t see Stereo Mix, then Right-click on an empty area and make sure that both “Show Disabled Devices” and “Show Disconnected Devices” are checked. When the Stereo Mix option appears, Right-click on it and check Enable. Set the level to 100. Now it will also appear as an input device when you restart Multicast Streamer. Choose it as the default input device, make sure all your other settings match what we outlined above, and then click Start to begin the stream. Now stroll over to your iPod music player app on your iPhone or iPad, choose Shairport4w as the AirPlay output device, and play away. To cancel the stream on any phone, just hangup the speakerphone. Enjoy!